#115

Thanks a lot Sam!
I have tried with the source code from the following link but something went wrong. with your file everything works :slightly_smiling_face: thank you
https://www.microchip.com/mplab/avr-support/avr-and-sam-downloads-archive
http://ww1.microchip.com/downloads/archive/avr32-gnu-toolchain-3.4.0.332-source.zip

1 Like
#116

Hi!

I’m trying to build the simulator for the Teletype firmware on Arch Linux using the Docker image as described in the repository.

I can build the firmware without problems, but when I run make in the /simulator folder, I get the following error:

…/src/teletype.o: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
Makefile:23: recipe for target ‘tt’ failed

Does anyone maybe have an idea how this problem could be solved? I would really apprecieate any help!

#117

I believe if you have built the firmware, you need to make clean before building the simulator or tests, because the object files target a different architecture for the same filenames.

3 Likes
#118

Of course, I forgot removing the cross-compiled object files! Thanks, now it works!

1 Like
#119

Just sticking this up here for anyone that might be interested (or comes via Google).

If you happen to be silly enough to run nix or NixOS (like me), the following derivation works for the Atmel provided binaries:

{ stdenv, fetchFromGitHub, unzip }:

stdenv.mkDerivation rec {
  name = "av32-toolchain";

  src = fetchFromGitHub {
    owner = "samdoshi";
    repo = "avr32-toolchain-linux";
    rev = "ac4fe6f831ffcd026147ce88bf8427df1678737b";
    sha256 = "0mj7pp9masp6fycl3g4sp7mji4pdpyksvvcxywp6c0kfrv54d4mb";
  };

  buildInputs = [ unzip ];

  phases = [ "installPhase" ];

  installPhase = ''
    tar xvfz $src/avr32-gnu-toolchain-3.4.3.820-linux.any.x86_64.tar.gz
    mv avr32-gnu-toolchain-linux_x86_64 $out
    unzip $src/avr32-headers-6.2.0.742.zip -d $out/avr32/include
  '';
}

(If the Atmel binaries stop working I’ll have a think about porting over the DIY compiled version, though I may seriously think about rewriting that Makefile…)

2 Likes
#120

A Python helper script for anyone doing module development on Linux whose modular is on the other side of the room from your computer (like me)…

This script automatically runs flash.sh whenever you connect your module via USB in DFU mode, it’s Linux only and needs pyudev installed.

autoflash.py:

#!/usr/bin/env python3
from pathlib import Path
import subprocess
import sys
import pyudev

flash = (Path(__file__).parent / 'flash.sh').absolute()

def main():
    monitor = pyudev.Monitor.from_netlink(pyudev.Context())
    monitor.filter_by(subsystem='usb')
    monitor.start()

    for device in iter(monitor.poll, None):
        vendor = device.get('ID_VENDOR_ID')
        product = device.get('ID_MODEL_ID')
        if (device.action == 'add' and vendor == '03eb' and product == '2ff6'):
            subprocess.run([str(flash)])

if __name__ == '__main__':
    try:
        main()
    except KeyboardInterrupt:
        sys.exit()
4 Likes
#121

@scanner_darkly, @sam - it would be great if you could update the Makefile at https://github.com/scanner-darkly/avr32-toolchain since that is being referred to in the main readme at https://github.com/monome/libavr32 and it is referring to the non-existant atmel file for avr32 patches. It was a bit of a head-scratcher until I read through this thread fully and stumbled upon @sam’s attachment. Thanks!

#122

yep, i can do that - but looking at my fork it looks like it’s just that, a fork with no local modifications. might be a better idea to update the instructions on libavr32 repo and add a proper makefile there?

1 Like
#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