#101

Have you customised your Makefiles?

It wouldn’t be to “freeze” the changes per se, but more to have everyone on a standardised install that is guaranteed to work. In theory we could update it as time goes on if we wanted to.

Which is a legitimate worry. But there is nothing to stop us going down the Docker route when it breaks.

The question is, do we want to make pre-emptive changes now based on some worry that may or may not happen.

#102

no, but my question was will i need to replace python with python3 in any of the build files? or is it just for steps that i would run manually?

right, but say if something stops working when we update we can always rollback to the last working version. much more difficult if you update your own machine.

but it did break already, no? we have to use the latest denravonska for this very reason. and a separate point is making it easier to set up for others.

#103

Agreed 100%. Docker is not a great solution for everyone. I think I am close to having a good Docker option to add to the toolbox, and people can use it if it saves them time. If we can take it further and build some automation around Docker, then it will get exercised and not bitrot. Then, if the manual instructions do run into issues, we’ll have the continuously-tested Dockerfile to refer to.

2 Likes
#104

No, all the build scripts should explicitly use python3, if they don’t then that is an error and I’ll fix it.

On Mac/Linux/WSL there are 2 ways to manually run the Python scripts:

cd utils
./docs.py

or

cd utils
python3 docs.py

The first method will automatically use python3 as it is on the #! line (i.e. the very first line of the script).

In the second example, then yes you must explicitly make sure that you are using the correct Python binary.

That’s true.

As it stands new users need help getting the toolchain up and running, which sometimes requires us to figure out which fork is most up to date.

If we switch to Docker, then most of our support will instead be about getting their Docker installations up and running. IMO if we ask them to install Docker then we’re a little obliged to help them out with their follow up questions (e.g. where has all my disk space gone, why is this VM always running).

@Dewb, I had a look at your Dockerfile. A few pointers if I may…

If you can, don’t bother trying to build the toolchain. See if you get it working with the Atmel provided binaries instead. See the .travis.yml file in the Teletype repo for how to do this, and ask me if that’s not obvious. Unfortunately those binaries have stopped working on my up to date Arch Linux, my guess is that a recent glibc update finally broke them.

I’m pretty sure you’ll end up with root owned files as it stands on Linux. I’m don’t know what the idiomatic solution to that is though.

1 Like
#105

If we switch to Docker, then most of our support will instead be about getting their Docker installations up and running.

True, but that sounds better than having to support issues around glibc, LaTeX, Python, utf-8, and a dozen other things, doesn’t it? And all that stuff takes up space on disk if you install them one by one, and it’s harder to clean up afterwards.

Oh, I didn’t know there were Atmel-provided binaries, yeah, that would be a time-saver. Takes about 22 minutes to build the whole Dockerfile locally, and an hour on the Dockerhub cloud build. It is nice to be able to have the container run a recent security-patched Ubuntu, though.

Yeah, I need to address the Linux ownership issue, I’ll do a Linux desktop test tonight.

For anyone else wanting to take a look, here’s the Dockerfile and the image on the hub:
https://github.com/Dewb/monome-build
https://hub.docker.com/r/dewb/monome-build/

1 Like
#106

Apart from Latex, the others aren’t that bad. The toolchain can just be rm'd.

Cool. If you ever do figure out what the “proper” way to do it is, I’d love to know, most of the ways I’ve seen (and used) involve setting ENV variables to uids.

#107

I think the solution is to use fixuid, need to research if there’s a newer solution.

#108

not bad :slight_smile: but it adds up, there is ragel and clang-format as well.

having a container would also allow us not to worry too much about using any additional tools

2 Likes
#109

I tried the prebuilt Atmel Linux x86_64 binaries and it didn’t go too well. They don’t like the explicit utf-8 locale stuff I had to do to get the LaTeX process running. That version is here if you’re curious: https://github.com/Dewb/monome-build/blob/prebuilt-cross/Dockerfile

#110

Hello all, and a special thanks to @sam and @scanner_darkly for their work and valuable instructions : )
I trying to add some OPs in Aleph’s BEES, particularly I would like to expand the integration with Arc… everything works, but not for math.h. lib. seems that there is no way to include the lib and use functions like sin, floor, etc.
I use Kubuntu 18.04. I searched info, but what I found isn’t clear for me
thanks in advance

#111

What’s the compiler error you’re getting?

The most probable answer is that you’re not linking against libm.

I think the following line:

Will need to be changed to be:

LIBS += -lm

FYI there is no FPU on the AVR32, so you might be better of with a lookup table anyway…

1 Like
#112

sorry for the delay and thanks for the answer… I studied Ansible’s sw, and I have found solutions that can help me to workaround the problem.
: )

#113

hi all, unfortunately I have reimaged my Mac and I tried to rebuild the toolchain too, but seems that the some files like:
http://distribute.atmel.no/tools/opensource/Atmel-AVR32-GNU-Toolchain/3.4.2/avr32-patches.tar.gz
doesn’t exist anymore. that’s the warning:
Failed to connect to distribute.atmel.no port 80: Network is unreachable make: *** [downloads/avr32-patches.tar.gz] Error 7

any idea?
thanks in advanced

#114

avr32-patches.tar.gz (379.9 KB)

You should be able to drop them into: ./downloads

2 Likes
#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