#21

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…

#22

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.

#23

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.

#24

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
#25

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

2 Likes
Aleph update - BEES 0.8.x
#26

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?

#27

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
#28

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.

#29

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.

#30

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
#31

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).

#32

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
#33

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
#34

I’d like to see if I can compile/modify the Teletype firmware before I buy one because I’ll need to make some modifications to it at least for Japanese keyboard support.

From what I’ve understood (and what’s in the github help), most people here are on either Mac or Linux, but I’m using Windows and I’m much more used to environments like Visual Studio (though I can manage working with other IDEs if needed). I think it was mentioned that at least one person is doing Teletype/Monome dev on Windows, so if that person reads this and can give pointers/info about what works and what doesn’t in terms of setup/etc., that would be awesome :slight_smile:.

Thanks in advance…

Teletype 3.+ feature requests and discussion
#35

Replying to myself as my thread/question was moved here, where it probably belongs :slight_smile:.

I’ve quickly read the doc at https://github.com/monome/libavr32 and I’ll try to do this at home when I have some time.

I forked the Teletype project, but I don’t need to do that for AVR32, right ? I can just use github.com/scanner-darkly/avr32-toolchain ?

I need to familiarize myself a bit more with Git though, Perforce and other source control tools I’m used to behave in a quite different way it seems…

Is it possible to compile using an IDE on Windows or is commandline the only option ?

#36

@scanner_darkly can advise you as to the best way to develop on Windows.

Options are:

  • Try to use Atmel’s Windows version of GCC, plus you’ll need to bring in your own Rygel and Python
  • Use WSL (as suggested in the libavr32 readme)
  • Use a virtual machine running Linux

Correct. Just git clone it.

Command line only if going via WSL or on Linux. Probably the same for the first option too.

FYI @scanner_darkly in the edit you made to the libavr32 readme you’ve moved the word “bash” onto a new line for several of the code examples, that’s supposed to be on the same line as the backticks as it’s a syntax highlighting hint.

#37

if you don’t plan to add new ops, you don’t need python / ragel bits. however you would still need to get the toolchain set up. i successfully set it up on my desktop computer but unfortunately didn’t take notes, and couldn’t get it going on my laptop, so bash was the only option (although it’s probably possible to have it set up on windows without using bash, which is really my preference, but i didn’t want to spend too much time fighting it, and i needed ragel anyway).

never tried setting up an IDE, would be nice, but notepad++ is sufficient for me. would be nice to have this option though…

if you put it on the same line bash doesn’t show up at all (tried it in firefox and chrome).

#38

It’s not supposed to show up (you’re not supposed to type in bash). It just tells the Markdown processor what syntax highlighting to use…

https://help.github.com/articles/creating-and-highlighting-code-blocks/

Same thing works on here:

def this_is_python():
    print "hello"

Is done using

    ```python
    def this_is_python():
        print "hello"
    ```
1 Like
#39

it’s fixed.
20 characters

1 Like
#40

Thanks!

(20 characters)