My bad. It’s:

apt install build-essential

(no “s”)

that worked! but ran into a different issue, it says it can’t find avr-gcc even though this part worked previously. i’ll try redoing the toolchain setup using the instructions tonight and see if that helps (for now just wanted to try it quickly so simply pointed PATH to my existing toolchain).

You need the Linux version installed though!

You can use the .travis.yml file to crib the instructions for getting it set up (plus you can download the tools from my GitHub repo, rather than Microchip).

1 Like

thanks, will give it a try tonight! once i have it set up on my desktop successfully i’ll go through it again on my laptop, taking notes in the process and then we can add a section on windows toolchain set up.

1 Like

installed the toolchain (linux one from your repo) and now it finds avr-gcc but it just outputs CC ../module/main.o and then nothing happens.

i was able to build the firmware by just manually running ragel in bash and then using the old makefile so not blocked for now. if i can’t get bash to work i’ll have to try building ragel for windows - looks like there is no precompiled version available anymore (somebody has it in their repo but i’d rather build it myself)

I take it you mean avr32-gcc right?

Hmmmm, that’s a mystery.

Looks like there is a Rainmaker firmware update coming soon. Once that’s out I’ll need a Windows VM to install it (might as well go Windows 10). I’ll see if I can have a go at setting WSL up.


Just seen that Microsoft have evaluation VirtualBox images of Windows 10 Enterprise. 12.9gb download here we go! (It even includes Bash on Windows installed, how nice of them.)

1 Like

Success!

It’s made overly complicated by these 2 issues: #1048 and #1462.

So you need to compile you’re own toolchain. Which needs 8gb of free RAM due to Windows Defender going crazy. Also, it takes hours to build (which made the repeated out of memory errors even more fun).

I need to make some changes to the instructions and possibly patch one of the files before it will be ready for you.

The changes aren’t particularly hard, but given how long it takes to compile (about 4 hours in VM), it might take 24 to 48 hours to finish.

1 Like

thanks for investigating! thinking perhaps i should hold off until the environment is more stable…

what about the firmware itself - does it take longer to build it in WSL?

as a side note - looks like tracking is lost when a thread is split off another one…

From everything I gather it’s pretty solid. Static linked binaries like this are a bit of an edge case on Linux IMO. Hilariously (to me anyway), Bash on Windows encourages open source!

It is slower than on my Mac, but it’s inside a VM. So it’s hard to say…

make clean
time make

gives me 13 seconds on the host (OSX), and 25 seconds in the VM (W10/Ubuntu), that’s on my 2.0 branch with ragel, etc.

If you do get it working, you should be able to build the PDF docs using Latex with ease too.

i’ll give it a try.

i don’t mind a different workflow (if i switch to WSL) assuming i can automate/script most of the tasks, but if it increases compilation time i might just have to stick with windows - i recompile often, even a small increase in time will become an issue…

looks like latex is also available for windows, so shouldn’t be a problem either way.

Right solid instructions to build the toolchain and firmware…

The only issue is that our fork of the toolchain builder doesn’t work on newer versions of Linux. Instead we’re going to use this fork.

There are 2 major differences with the newer fork, it uses a slightly newer version of newlib (1.19.0 vs 1.16.0), plus it has some patches to remove C++ exceptions (which is irrelevant to us anyway).

I tried to backport the other changes which fix compilation on newer version of GCC, etc, but gave up. Later on today I’ll try compiling our toolchain on OSX and see if it still works.

Anyway instructions as follows…

# 1. install dependencies to compile the toolchain
sudo apt update
sudo apt upgrade
sudo apt install curl flex bison libgmp3-dev libmpfr-dev autoconf build-essential libncurses5-dev libmpc-dev texinfo 
# both unzip and gperf needed to compile toolchain, but aren't listed as dependencies in the README
sudo apt install gperf unzip

# 2. compile the toolchain
# this will take a few hours, the tar steps can take a while and won't print anything to screen
cd
git clone https://github.com/monome/avr32-toolchain
cd avr32-toolchain
PREFIX=$HOME/avr32-tools make install-cross

# 3. install ragel and compile the firmware
sudo apt install ragel
export PATH="$HOME/avr32-tools/bin:$PATH"
cd
git clone --recursive https://github.com/samdoshi/teletype  # change to repo of your preference
cd teletype
cd module
make

If you get a “low memory” warning from Windows, the toolchain compile will probably crash. In my VM with 8GB, I found that sometimes Microsoft Antimalware Service would consume over 4GB of RAM.

If it does crash then you need delete files and start again…

cd
rm -rf avr32-tools
rm -rf avr32-toolchain
# do step 2 again

If you’re trying to speed up firmware compilation, you can do something like make -j8, it will go a bunch faster. Because it’s not deterministic, there can be compilation failures if the Makefile doesn’t specify it’s dependencies perfectly (ours won’t), so for releases or final testing, best to do a make clean; make.

3 Likes

great, thanks for documenting this - this will help a lot. will give this a try!

2 Likes

finally have the time to do this! not sure about step #2, should i clone the monome repo or https://github.com/denravonska/avr32-toolchain?

Yes I think so, it looks like I mistyped the instructions with the wrong fork. (It’s been a while and it’s a bit hazy…)

1 Like

If there are changes to the avr32-toolchain needed for newer hosts it would be great to get those changes merged into the monome fork on GitHub.

I can’t remember exactly, but think it’s one of those daft things where one fork works on OSX and one works on Linux/WSL. It might be something to do with differing versions of gperf and/or texinfo on each OS. But again, I can’t remember now.

It’s also not helped by the fact that it takes hours and hours to test each change.

looks like everything worked fine - set up the toolchain on my windows 10 laptop following your instructions above and was able to successfully build teletype firmware. missed the step to install gperf and unzip first, recompiled the toolchain again after installing them and everything went smoothly.

thanks again for your help with this! i’ll add a section for windows setup to the repo (and will add instructions to install WSL and clang-format for completeness).

edit: updated the readme: https://github.com/monome/libavr32

2 Likes

ran into several issues…

it loses path to avr32-tools each time i close bash. is there a way to make export PATH="$HOME/avr32-tools/bin:$PATH" permanent?


running op_enum.py i get the following error:

` File “op_enums.py”, line 36
output += f" {prefix}{e},\n"
^
SyntaxError: invalid syntax```

(^ above is actually pointing at the closing ")
this is only from bash, if i run windows version of python it runs successfully and generates op_enum.h.


another problem is not being able to use my regular editor - it appears there is a known issue where editing ubuntu files externally makes them invisible to bash. i’ll play some more but it might be just easier to switch to pure windows workflow, i’d just need to build ragel for windows (which is the only part i don’t have working without using bash).

Sorry for missing this, I don’t always seem to get notifications in this topic…


If you add the line to your .bash_profile it will run it on every shell startup, but please read up on the .bash_profile and .bashrc files.

Yep, WSL python is 3.5, we need 3.6. I’ve updated the script to do the version check properly now, so it should at least spit out a more useful error message.

I’ll update the docs thread with potential workarounds if you don’t have python 3.6 as your default.

1 Like

thanks @sam!

i also found a workaround for files becoming invisible if edited in windows - i checked out the repository into a non bash folder and i do all the editing and git work there, and use bash only to build - it doesn’t have these issues with external files.

1 Like