After a couple of hours getting the new display setup, I realised that I had come across a rather serious problem. The screen refreshing was hogging the processing power of the limited ATMEGA328p microprocessor that I am using, and was slowing things down so much that the output signals were not working properly. Things seemed to be ok up to about 100bpm, but after that outputs started getting messy and triggers were overlapping where they shouldn’t be, effectively throttling the speed and accuracy of the device.
I had a chat with my brother who is a software engineer to see if he could help me optimise my code, and he pointed out that I was being hideously inefficient with the display! My code was writing the entire screen’s contents for that moment into RAM and then sending this to the display each and every cycle, meaning that unchanged parameters were being needlessly refreshed. I ended up rewriting my display code from the ground up, this time checking to see whether anything had changed, and then only updating those parameters which required an update.
This fixed my lagging problem, but there are still a few bugs left in the software which need to be resolved:
- Parameters sometimes not updating when knobs turned or mode changed – possibly something to do with the selected mode?
- Highlighted current step issues when the length of a sequence is reduced below the currently active step.
- Highlighting of active parameters in the bottom left corner of the display not always working.
- Probably other bugs yet to be found once testing within a modular system is done!
However, the code now seems to be completely functional apart from some display issues, so I can happily move across to the hardware side of things and return to these issues later!
