I’ve been tinkering with the MIDIpal source and got it to build on the Mutable Dev Environment, however I did notice some problems after transferring that build to the device. So it’s nice to find this thread
I’m not very experienced when it comes to gcc or avr so apologies if some things I say here don’t make sense. However I am eager to learn so any help is appreciated.
I thought it would be beneficial to use a preconfigured environment so set up the Mutable Dev Environment from here - https://github.com/pichenettes/mutable-dev-environment - when I run
avr-gcc --version on the dev vm I see that it returns 4.8.2 for the version number. Is 4.8.2. actually 8.2? Probably not, but I felt it worth asking to clarify.
I understand the MIDIpal was originally compiled with avr-gcc version 4.3.3 and that it the code needs updating to build with newer versions. I was able to get the code to build with avr-gcc 4.8.2 after making a couple of updates, although I can see that the compiled firmware does not work quite as expected, for example the arpeggiator doesn’t seem to process any notes and I suspect that settings are not being saved to the device as bpm on the arp settings always reverts to 1, even after changing it. Another, more obvious issue is that I see some strange characters on the version page of the MIDIpal display.
Here’s what I did so far…
- Installed the dev environment.
- Cloned the repo - https://github.com/pichenettes/midipal including submodules (avril).
- Updated some lines in
resources.cc relating to PROGMEM (compiler errors were
must be const in order to be put into read-only section) - changes can be seen here https://github.com/jobf/midipal/commits/feature/sysex-mapping
#include <string.h> to
avrlib/base.h to overcome compiler errors relating to memcopy (if I remember correctly)
- Converted the built hex to syx using the command
python tools/hex2sysex/hex2sysex.py --syx --page_size=64 --device_id=3 --output_file build/midipal/midipal.syx build/midipal/midipal.hex
- Upload to MIDIpal as normal
I’m going to attempt to edit the vagrant scripts to install avr-gcc 4.3.3 because that seems to be a way forwards I can imagine, even if it isn’t possible I am happy to try If this is not a good idea then I’m happy to abandon that strategy. I’d offer to help bring the code up to date with avr-gcc 8.2 but I fear this is a little out of my depth right now!