Awesome! Things are still running great for me with that fix in place, and I've even switched my focus back to working on gameplay.uze6666 wrote:I've done the fix and while at it some refactoring, optimizations and cleanup. Though it seems I introduced a regression regarding the PCM channel some time ago. I will fix it before I commit everything back.
That's weird. I really don't want to sidetrack you, but if you do end up using a newer version of GCC then you may want to verify if using the __flash qualifier, rather than the PROGMEM macro, generates better code. As a bonus, you no longer need to use any special pgm_read_* macros when accessing the variables:uze6666 wrote:One other thing I noticed is the code generated in TriggerFx,TriggerCommon is far from efficient specially when there is pgm_read_byte macros. For some reasons the compiler will not use LPM with displacement to efficiently address structrure members. Well, on my version of GCC at least. If will test on 4.9.2. If I still get the same, I may just rewrite those function is assembler. Since they are called a lot of calls to those functions, that could add up to a lot of cpu savings, specially when music is playing. And it will assure the compiler wont reorganize things.
Code: Select all
#ifdef __FLASH
const __flash int var = 1;
int read_var (void)
{
return var;
}
#else
#include <avr/pgmspace.h> /* From AVR-LibC */
const int var PROGMEM = 1;
int read_var (void)
{
return (int) pgm_read_word (&var);
}
#endif /* __FLASH */
Disclaimer: I have not used the __flash qualifier myself, I only know about its existence.
With that said, the thought of getting a lot of CPU cycles back from a full assembly implementation makes my mouth water. (I have not yet programmed an AVR in assembly before; my experience is limited to examining the generated code only.)