#5

really appreciate the help!

within the environment variable(advance system settings), i can see that the PATH variable is at C:\Program Files (x86)\Atmel\AVR Tools\AVR Toolchain\bin.

when i try make in the main.c folder, i encountered this,

a.jpg971×318 82.5 KB

#6

hmm not sure about this one… it builds okay for me. one thing to try though, you don’t really need to run it from git bash, just use the regular command line (cmd) and maybe run it as admin just in case.

#7

Thanks scanner. I went back trying on the regular cmd and still having the same error.

will try further after more reading and searching around.

#8

i’ll check if i documented the toolchain setup later too and will post here if i find anything that might be related. and hopefully somebody more familiar with avr32 can comment as well.

maybe also try a different firmware and see if you get the same error?

#9

maybe you’re missing the avr/avr32 headers? which are a separate download from the toolchain (licensing reasons i’m sure)
http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORWINDOWS.aspx

1 Like
#10

Thanks z and sc,

@zebra, i have downloaded the header file and include it in environment path but most likely its not the correct way to do it. The compiling of ansible still having the same error.

@scanner_darkly, interestingly, after seeing your suggestion on trying the other firmwares, i had success with building earthsea, whilewhale and meadowphysics hex file.

Ansible and teletype are the 2 that didnt work out. For teletype, the error was that there is no make target and missing makefile in src folder.

I tried re cloning the teletype repository and somehow the process was successful but within the src folders, makefile was missing.

Will try again with some other non monome module firmware building and see what i can learn from there.

#11

and include it in environment path

of course i am not sure that this is the culprit, but your output is consistent with errors from missing headers that i have seen.

the paths where GCC searches for headers (with -I flags, usually defined in makefiles) are not the same as the paths where the windows environment searches for executables

it’s just something to consider

[re-edit] sorry, the explicit include paths added in the makefiles aren’t actually relevant for the toolchain headers. sam has the correct location (for linux) below (and header installation is also covered in the aleph README.)

#12

Ah yeah, that make sense,

Pardon on my noobness. I have just started on trying to do this sorta thing couple days back with no programming background.
Prolly gonna take a while to understand the basic. In the mean time, gonna be more reading and trying out

#13

For teletype only you need to be in the module directory. If you spot any incorrect docs please let me know and I’ll get them corrected.

For ansible, is the libavr32 directory there and populated? I’ve just noticed that the .gitmodules file is using ssh rather than http which can cause problems, especially on Windows.

#14

@sam,

Ahhh, that module folder! I was confused by it via teletype github and the rest. Mixed up on cd module vs cd src during initial build.

The libavr32 folder within ansible iirc were populated.

Iam at the other side of the world and going to leave for work soon. Will try again when i get home.

1 Like
#15

No worries, I’ve just woken up :slight_smile:

@scanner_darkly and @pathein, once you’ve got this all figured out would you be able to add some Windows instructions to the readme on the [libavr32][] repo?
[libavr32]: https://github.com/monome/libavr32

And would it be worth updating the dev docs on the Monome site to point there too?

2 Likes
#16

Yeah, that was the plan i was thinking of doing.

Hope to sort out ansible and teletype build and i can do a simple guide one it

1 Like
#17

and after some doodling, cloning of the ansible and teletype repository via ssh have been successful with the submodules files all populated.

when going through the make process, similar errors encountered as the picture posted earlier.

Next thing to do will be on the header files. I have downloaded the header files via atmel site and wondering where should this folder of header files be used?

#18

This isn’t for Windows, but the Linux the headers go in $AVR32TOOLS/avr32/include, see this .travis,yml file that is used to set up the build environment for testing.

Going by the earlier Windows path C:\Program Files (x86)\Atmel\AVR Tools\AVR Toolchain\bin, the header files probably need to go into C:\Program Files (x86)\Atmel\AVR Tools\AVR Toolchain\avr32\include. Does that work?

#19

cool! Will go try that out now. Report back in a while :grinning:

#20

tough luck. I have tried with unzipping the folder and leave it as is, replacing individual files etc. So far its not working out yet and having the same errors. Somehow it felt so close but still far. Will prolly try out after catching up on some rest first.

#21

i couldn’t find any notes from installing the header files (to be honest don’t even remember doing that step). but: i can build ansible, and if i remove the folder C:\Program Files (x86)\Atmel\AVR Tools\AVR Toolchain\avr32\include i get a bunch of errors.

i have a feeling maybe your PATH is pointing to wrong header files. can you try executing PATH and see what it returns and then check if you have the include folder under the same parent folder?

my PATH has C:\Program Files (x86)\Atmel\AVR Tools\AVR Toolchain\bin and the headers that are used by make are located in C:\Program Files (x86)\Atmel\AVR Tools\AVR Toolchain\avr32\include

#22

thanks sc!

after some rest and reading your reply, i went back checking the header path. All seem normal initially till i saw that compared to the header files that i have downloaded from atmel site and the header files in my installed AVR Tools folder, the one from atmel site are more updated than the one i have originally installed.

I replaced all the older header files with the updated ones and running make again with ansible and teletype, both are able to build the hex file successfully!

One thing that i noticed though, is that the hex files that i have tried building, when compared to the ones ready build from monome github, the size of the hex file seem to differ by couple kb. Not too sure if its any indication of “wrong” build. But i will try flashing the module with my built ones and check if the funtions are working ok after work tonght

#23

i think i have found the way to do the building with no files swapped needed in the toolchain and all the modules firmware should build correctly.

I was doing comparison of of the installed avr32 toolchain folder(older version, v3.4.2.1573) with and the most current version on atmel site(v3.4.3.22)

theres were differences in the number of folders and files(between the old and latest toolchain) and certain files which are needed to build the hex file are missing from the latest version of the avr32 toolchain.

some pics to show the differences, left side is the older version toolchain folder and and right is the latest installed version.

1st pic- comparison of the main installed folders

2nd pic- comparison of the header files folder in which the latest version tool chain in missing an avr32 folder(which should contain the actual header files)

3rd pic- comparison of the bin folder which should have a “make.exe” file needed to build the firmware

in short, the older toolchain seem to be working over the latest one,

avr32 toolchain comparison.jpg1336×573 151 KB
avr32 toolchain comparison3.jpg1293×738 219 KB
avr32 toolchain comparison2.jpg1296×741 247 KB

#24

interesting… the version of Atmel AVR GNU Toolchain i have installed on my machine is 3.4.1067 (23bit) and 3.4.1061 (8bit). my folders look slightly different from both of the versions you posted, but i do have avr32 subfolder under avr32\include.

it’s a little worrisome that it didn’t work with the latest version, i’ll see if i can reproduce the issue and find more information about the changes. how did you point it to the previous version, updating PATH? also, where did you find the older version, was it still available from the Atmel site?

good you got it working though! the size difference could be due to the different toolchain version being used and likely shouldn’t cause any issues. i never actually compared the size of my builds vs the official releases.