ER101: Custom Firmware / Success / Issues etc

Hi All,

Haven’t been on here for a while and noticed the firmware is now open source.

Wondering if anyone has developed custom firmware and if so, what did you change / improve etc?

Ive got a few ideas myself but was curious to see what others might have already done.

Cheers
C

Running through the process demonstrated in the GitHub repo, I’m faced with this issue:

When running ‘make firmware’, all compiles until this step:

LINK release/avr32/er-101-firmware-2.10.elf

avr32/bin/ld: cannot find -ldsp-at32ucr3fp-dspspeed_opt

Any ideas?

Looks like I forgot to check that file in to the repo. It should be there now.

I guess this also indirectly answers your first question :wink:

Perfect. Thanks Brian.

I’m interested in contributing to the firmware, and possibly developing my own version.

Already submitted a PR with some typical testing stuff: Add github actions CI by wtholliday · Pull Request #3 · odevices/er-101 · GitHub

in particular, I’m interested in increasing the snapshot count: could snapshot count be increased by dynamically allocating nvm pages? · Issue #2 · odevices/er-101 · GitHub

1 Like

I have successfully altered the firmware to test some custom functionality. The initial stage was to customise the toolchain / environment to work with my current operating system. I’m on Mac OSX Big Sur and utilising VM’s, I compiled on Ubuntu, then using the programmer on Windows to flash as the programmer isn’t supported on later versions of Mac. Despite this being tedious and slow, it works and I have working 2.10 firmware.

Increasing the snapshot count, is on my list of improvements, amongst others. Curious to hear what others might want as well.

3 Likes

Do you have a public fork of the repo?

Not at this stage. I’m adding small tweaks, compiling and flashing to familiarising myself with the codebase and its architecture.

@odevices Curious to hear your debugging process… Do you use an AVR debugger / hardware programmer with an AVR supported IDE?

I did but I’m in the middle of moving the ER-101 development away from Windows to Linux. The ER-101 Programmer app just uses dfuprogrammer under the hood to flash firmware so I’m pretty confident that will work in Linux too. JTAG debugging in Linux Is what I’m not so confident about yet.

To be honest though, the majority of time I just have the ER-101 hooked up to USB for quickly uploading the firmware. I seldom step through code and if I need some kind of debug output I will often resort to just flashing an LED or similar. I understand that is not for everyone :relaxed:

2 Likes

Thanks Brian.

I’ve done a bit of initial coding on the snapshot count increase (nothing works yet): er-101/test.c at snapshots · wtholliday/er-101 · GitHub

The approach is to copy out the necessary data structures and supporting functions into a test program so I can thoroughly test the code before running on the device. I’m assuming from what @odevices wrote here that I can abstract reading and writing to the non-volatile memory (including the dynamic allocation of pages) as stream operations (am I right about that?). That would make the code pretty easy to understand and maintain.

One significant issue is upgrading the existing snapshots to the new format. This may be challenging to do in-place, considering the case in which the user has used much of the snapshot storage. So an external update utility would be needed (perhaps a new version of the programmer app?).

One could punt on that though by accepting that updating to the new format will delete existing presets, perhaps by holding down a button on startup, so it’s an entirely optional procedure.

Thanks Taylor, I’ll be sure to go through it.

If you are unable to flash the MCU on your end, I can do this on my end. Just let me know the type of results you are expecting.

1 Like

One thing I was looking at was filesystems for the AVR32. I assume the ER-102 has filesystem code to deal with the SD-card slot. Wondering if some small filesystem could work for the 101, to eliminate the work of manually dealing with the flash memory? I suspect @odevices knows the answer to that question :slight_smile: