What’s the before and after here?
2.0b9, or from
2.0b9 to your newer changes?[quote=“scanner_darkly, post:298, topic:6939”]
what i have: ansible, 2x TXi, 4x TXo on i2c bus. 10ms metro reading from ansible and updating 24 TXo outputs. 6 audio rate triggers from just friends, 4 of them each updating 2 teletype outputs and 2 TXo outputs.
You’re sure there is no danger from nested interrupts? Even so, keep the functions for encapsulation. It will make it easier to change the behaviour in the future.
Don’t forget to test on Ansible.
Is there a typo in there? And does this change improve performance or stability?
The event change (
cpu_irq_restore) was the one that brought the biggest stability win when I was playing with it. Part of me taking the extreme approach was to keep that code safe no matter what else changes, in any module. None of us are full time AVR32 coders. Some of us (me) aren’t even that experienced with embedded systems. I think it’s best to take an approach that whoever contributes changes, that code is always secure.
Are these changes online anywhere? I’ve only got today (Friday) left for playing with this low level stuff. Tomorrow my modules all go back in the rack and I can’t easily gain access to the serial port. (It’s half term soon, and a few weeks after that the new baby arrives…)
edit: one more thing.
I’ve been wondering if we should limit the metro to a more conservative speed, perhaps 20 or 25ms?
The idea I had was to add an extra
M! op that was allowed to set the speed faster (back down to 10ms).
M 10 # only sets the metro to 25ms
M! 10 # does set the metro to 10ms
It’s really just to indicate that you’ve turned it up to 11, and you’re into uncharted and dangerous territory.