Midipal firmware now compiles and runs with AVR-GCC 8.2

Hi all,

I have finally been able to (successfully) run the MIDIpal using firmware, compiled using AVR-GCC 8.2. There’s no problem with code size.

After several days of debugging I uncovered several bugs in the avrlib / midipal code which were causing me issues like the display not working. They were undefined behaviour (like not having a return statement in the function) which may explain why things worked on older versions of GCC but not newer ones.

So that’s all fixed now. I also took the opportunity to refactor out the deprecated prog_ types (replacing with PROGMEM) and do some other fixes.

But the real problem was this: all the compiler warnings were disabled in the makefile!!!
@pichenettes this must have made firmware development so much harder, it’s like running with a blindfold on!

Anyway, for those interested, you can find my code at on Github. Let me know if you have any issues.

Note that the resource compiler still needs updating, and there may be more bugs that I haven’t yet found.


Let me know what are the mistakes you’ve found (In particular what is the function without return).

The functions missing return values were:


  • definitions of operator=() in the IORegister and friends #defines

devices/hd44780_lcd.h: [I think it was these ones that were causing most problems]

  • WriteData()
  • WriteCommand()
  • Write(char)
  • Write(const char *)


  • struct SerialOutput::Requested() [I wasn’t sure what to do for this so I just returned v unconditionally, but this may be wrong]


  • Delay()

There were also a few variables used before initialization in places, but the rest of the changes were mostly squashing more benign warnings. Although, I have just recently fixed some of the inline assembly in op.h because apparently the ‘&=r’ constraints should be ‘=&r’.

After some device testing, there are still a few niggling bugs that I haven’t fixed yet, for example:

  • MIDI output in intensive apps (delay, arpeggio) seems not to work well, even though monitor and general midi through works fine.
  • In the CC knob app, the CC value is stuck at 0
  • Sometimes the BPM parameter starts at zero even though it should be a minimum of 40

So I’ll keep on looking :wink:

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 :smile:

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.h and 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
  • Added #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 :sweat_smile: 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!

Hi Jamlid,

The problem is that the official midipal source relies on several quirks and default settings of gcc 4.3.3 that were changed in later versions. I spent a lot of time fixing all these issues, and have also refactored the code myself. It now works with AVR-GCC 8.2+ (yes, major version 8, minor version 2).

I should say that I didn’t really do anything to make it ‘releasable’. In particular, you’ll need to edit the makefile in avrlib to find your compiler and avrdude. Also, I think I still haven’t fixed the resources compiler, but the existing resources.c and resources.h should work.

Anyway, If you want to give it a try, my (unofficial) v1.4.1 is here: https://github.com/MachFour/midipal :slight_smile:

Hi @machfour thanks for writing :smiley:

I have just built your fork with avr-gcc 8.3 :tada: thank you so much! :smile:

I had some funny business with git when cloning your fork so ended up cloning your fork of avrlib directly instead of using the submodule, if you want to reproduce you can with

$ git clone --recurse-submodules https://github.com/MachFour/midipal.git

Fetched in submodule path 'avrlib', but it did not contain ebacd748ac154b2bf73d47e7f2df4ee311195058. Direct fetching of that commit failed.