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

This is excellent thank you, big improvement not having to power cycle every update, gonna try it out. I have a two > one but was afraid to test it with this workflow, sad to hear it doesn’t work, I wonder why that is? Maybe powering it by usb?

1 Like
#144

Ah. I guess I wrote that as a statement rather than a question. I don’t own a ‘two > one’ and so have no idea if it works or not!

#145

this is a great tip!

you still have to powercycle to make it exit DFU mode, right, unless i’m missing something?

re: two > one, is it the fact it’ll send power to the DFU cable? i wonder if using it with a cable that has power cut off would work.

#146

Ack, can’t remember. I’ll try again next time I’ve got the case out (hopefully this evening).

And I think it’s not to exit DFU mode, but to switch the USB port back into host mode from device mode.

It’s still on my todo list to see if I can get runtime switching between host and device mode working…

1 Like
#148

Finally got back to this…

I also have this recollection that you had to power cycle to make host USB devices work properly, but…

Just went back to test this on Meadow Physics and I had no problems reconnecting my grid after flashing, didn’t need to reboot at all.

I’ve got a firmware that I’ve been messing about with here (it’s just a 16 step trigger sequencer).

If you want to test the workflow, then:

  • first connect the USB A-A cable to the computer and module
  • second hold the front button down for 10+ seconds. Once it reboots (LEDs lit) it should show up on your computer in DFU mode
  • finally flash.sh
  • et voila, reconnect grid!

I might have a play with White Whale and Ansible and see if the same can work on those too, like I said, I could have sworn you needed to reboot to fix the USB mode…

2 Likes
#149

Looks to me like using dfu-programmer ... launch, Teletype works without a power cycle. The docs and released firmware update scripts use dfu-programmer ... start rather than launch, as far as I can tell start is equivalent to launch --no-reset. Using start Teletype’s screen comes on / displays a prompt but it is not responsive to keyboard input until a power cycle, if I launch then the keyboard works right away.

3 Likes
#150

Yeah, that was my sneaking suspicion too, that was the one obvious difference I noticed in the flash.sh scripts.

I think you need a newer version of dfu-programmer to use launch, but I think dfu-programmer reset will work on older versions instead.

Probably worth patching the flash scripts for both Ansible and Teletype.

1 Like
#151

Hello,
I am having issues installing the avr32 toolchain for the monome. I am trying to follow the instructions provided via GitHub but the libraries seem to be unavailable. What do you suggest to do as a workaround for this type of issue?

brew install mpfr gmp libmpc texinfo dfu-programmer
git clone https://github.com/monome/avr32-toolchain.git
cd avr32-toolchain
PREFIX=$HOME/avr32-tools make install-cross

I get the following error:
[ -d stamps ] || mkdir stamps ;
touch stamps/extract-binutils;
cd downloads && curl -LO http://distribute.atmel.no/tools/opensource/Atmel-AVR32-GNU-Toolchain/3.4.2/avr32-patches.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:–:-- 0:00:04 --:–:-- 0
curl: (7) Failed to connect to distribute.atmel.no port 80: Network is unreachable
make: *** [downloads/avr32-patches.tar.gz] Error 7

#153

Hi, try to clone this repository