#123

I agree. That would be the most stable option. Thanks for chiming in!

#124

do you want to post the makefile here? i can update the repo.

#125

Will do tomorrow. Just now shut down for the day :slight_smile:

1 Like
#126

The file attachment provided by sam was uploaded with the short-url feature of lines and mangles the name. It is better if we uploaded the file avr32.patches.tar.gz to an avr32-toolchain repo and link to it in the Makefile. Also, the Makefile is for the avr32-toolchain and not libavr32 itself. So, I think we gotta just have a stable fork of the avr32-toolchain (which could be yours or could be a fork of yours by monome org), in which we update the Makefile.

#127

sounds good. should i pull the latest into my fork first or do we want that specific commit?

#128

Your fork in its current shape worked well for me with that file. I think you could just pull latest (to cover for anything new from denravonska) and add the attached file at the root level (or under some folder, whatever you think is the best way to keep it). Then we can just update the Makefile to something like:

…
AVR32PATCHES_ARCHIVE = avr32-patches.tar.gz
AVR32PATCHES_URL = $(CURDIR)/$(AVR32PATCHES_ARCHIVE)
…

avr32-patches.tar.gz (379.9 KB)

1 Like
ADDAC221 i2c
#129

thanks, will do it this weekend!

1 Like
#130

What’s the story with this patch zipfile? Is it only necessary for 3.4.2?

The Docker container I made last year incorporates avr32-gnu-toolchain-3.4.3.820 and doesn’t need any patches. I haven’t had any issues building with that version. Might be easier to just update the official Makefile to 3.4.3.

2 Likes
ADDAC221 i2c
#131

i haven’t updated my fork yet - do i need to do anything there?

docker is probably a much better way moving forward (thank you for putting it together!). should we just recommend that in the libavr32 readme?

#132

Been sometime since I worked with docker on windows. The only option still is vagrant? That might be the only downer, since working with WSL on windows 10 (and launching vscode right from the command line) has been super awesome.

#133

I use Docker Toolbox on Windows (which runs the Docker daemon and containers inside a VirtualBox-hosted linux VM) and I use this dockerfile to successfully compile libavr32 and the Teletype and Ansible firmwares this way. In the WSL you may just be able to install Docker normally for all I know? Haven’t used the WSL hardly at all.

1 Like
#134

I think there’s value in having both approaches, not everyone can/wants to use docker in all situations (I’m not going to install docker on norns, but I might install the avr toolchain.) But yeah, the readme could mention both, and they probably ought to be on the same version of the avr toolchain.

1 Like
#135

In the teletype repo readme, both the docker and toolchain approaches are documented. So, that looks alright. Only in the toolchain repo readme, it goes through the whole nine yards, which when executed fails with this dead reference to an atmel avr32 patch.

1 Like
#136

so sounds like i should keep my fork at the commit it’s at right now?

do you mean the libavr32 one? i can copy the one from teletype.

#137

Sorry about the vagueness :slight_smile:. I am referring to the following repos:

  1. Teletype repo - main teletype code. Describes both libavr32 build approach and docker approach, providing documentation on both.

  2. Libavr32 repo - main libavr32 code. If you choose the libavr32 build approach, you will come here. Before you build libavr32, you need to build the toolchain first. In the windows section of readme, it points to…

  3. Your fork of the avr32 toolchain - this and other forks of avr32 toolchain all have the same problem. Their config.mks refer to atmel patch url that doesn’t exist anymore and instead need to be replaced with a new url or have the file manually added to the folder so that the build can pass.

Hope that helps explain what I have seen so far.

1 Like
Multipass - a framework for developing firmwares for monome eurorack modules
#138

thank you - this is very helpful.

i’ve added the atmel patches file to my fork - could you let me know what else needs to be changed (makefile / instructions)?

#139

My rec for libavr32 and forks would be to modify the Makefile & readmes to consume avr32-gnu-toolchain-3.4.3.820 and drop the patch zip completely. And then also mention the docker option in the readmes.

3 Likes
#140

As a long term fix, this is the best option. I will try to rebuild libavr32 this weekend with this toolchain and see what mods need to be done on config and readme.

1 Like
#141

once you get a chance to do it, could you submit a PR to update the readme/makefiles? and let me know if i need to do anything else in my fork of avr32-toolchain

1 Like
#142

Another bit of labour saving advice that I’ve just started using…

There is a function is the ASF called reset_do_soft_reset()1, that will soft reset an AVR32 (not that suprisingly!).

You can use this to avoid having to power cycle your whole modular system to flash the AVR32. In fact if you use a very very long press on the front panel button to activate the soft reset, the device automatically comes up in DFU mode by virtue of the front button still being held.

Combined with the autoflash.py script I posted earlier, you can get a pretty smooth development workflow.

The only thing that would make it even better is if @scanner_darkly’s two > one worked with the DFU cable as one of the devices.

1 see libavr32/asf/avr32/drivers/cpu/avr32_reset_cause.h

5 Likes