Hey!
As further tests showed, the issue might be somewhere completely different (on the second MCU), so I will have to check deeper before it makes sense for you to invest time into reading and thinking here!
I am working on a Midi-Sequencer, and have an issue, that the Program freezes, but the Teensy itself seems to operate still. Now I try to find out, why.
What does the Device do?
There are tons of buttons (54) and encoders(19), that are handled by a second Microcontroller (for IO reasons as well as timing reasons for the encoders), that sends Input Data to the Teensy via Serial. The Teensy reads the input, updates data and renders the informations onto a Screen via the ILI9341_T4 Api, als well to RGB LEDs using Pauls WS2812Serial Library.
To have a tight and Main-Loop independent MIDI-Performance, I have a InterruptTimer with short intervals (100micos) running. it calls a method that checks the elapsed micros since the last MIDI-Execution, and if a value is reached, triggers a MIDI-Tick, that takes up to 60micros.
What happens?
Sometimes, when I chance values via the interface while the sequencing is running, the Interface freezes. No Input and/or output is occurring anymore. But the Sequencing happily continues, playing all the notes and modulations like it is intended, so its not the app itself crashing, but somehow the Main Loops seems to be freezed.
This does only occur, when the sequencing is running and I change values, but it is far from happening always. It has not occurred once, when the sequencing was running without me changing values, nor did it occur, when I changed values without the sequencing running.
I tried to "play" around with it (as good as I can do it considering the time every operation takes) and it seems, that, if I change values, the sequencing process does not use, everything is fine, but when I change values the moment, the sequencing process accesses the data, it can occur.
So from my experience with projects outside of the micro-controller-world, this might be a thread-safe-issue. I went into this, with the idea "Microcontrollers are single threaded, what can go wrong", but It seems as it can be a lot
Sadly I don't really understand, how interrupts are interrupting the execution of code etc. Is it interrupting in a way, that the next CPU cycle is already doing interrupt stuff? is it waiting for the current command has finished?
I have a few things in mind, I can test and change, but I am sure there are ways out there, that I don't know/think of?!
1. I will stop the interrupt timer every time I execute the midi process and restart it after it finished, to see, if the interrupt-tick freezes too at that moment
2. I will do some measurements to see if I can integrate the sequencing into the mainloop without having an unreliable midi clock
3. I will see if I can refactor the code in a way, to disable irq every time I change a value (right before I assign a value to the variable and enable it right after it) without having to do that all over the place.
Sorry for that long wall of text. I am thankful for every input I can get. Maybe I am looking at it wrong? Maybe my conclusions are wrong, and its no threading-issue?
Thanks, Jens
As further tests showed, the issue might be somewhere completely different (on the second MCU), so I will have to check deeper before it makes sense for you to invest time into reading and thinking here!
I am working on a Midi-Sequencer, and have an issue, that the Program freezes, but the Teensy itself seems to operate still. Now I try to find out, why.
What does the Device do?
There are tons of buttons (54) and encoders(19), that are handled by a second Microcontroller (for IO reasons as well as timing reasons for the encoders), that sends Input Data to the Teensy via Serial. The Teensy reads the input, updates data and renders the informations onto a Screen via the ILI9341_T4 Api, als well to RGB LEDs using Pauls WS2812Serial Library.
To have a tight and Main-Loop independent MIDI-Performance, I have a InterruptTimer with short intervals (100micos) running. it calls a method that checks the elapsed micros since the last MIDI-Execution, and if a value is reached, triggers a MIDI-Tick, that takes up to 60micros.
What happens?
Sometimes, when I chance values via the interface while the sequencing is running, the Interface freezes. No Input and/or output is occurring anymore. But the Sequencing happily continues, playing all the notes and modulations like it is intended, so its not the app itself crashing, but somehow the Main Loops seems to be freezed.
This does only occur, when the sequencing is running and I change values, but it is far from happening always. It has not occurred once, when the sequencing was running without me changing values, nor did it occur, when I changed values without the sequencing running.
I tried to "play" around with it (as good as I can do it considering the time every operation takes) and it seems, that, if I change values, the sequencing process does not use, everything is fine, but when I change values the moment, the sequencing process accesses the data, it can occur.
So from my experience with projects outside of the micro-controller-world, this might be a thread-safe-issue. I went into this, with the idea "Microcontrollers are single threaded, what can go wrong", but It seems as it can be a lot
Sadly I don't really understand, how interrupts are interrupting the execution of code etc. Is it interrupting in a way, that the next CPU cycle is already doing interrupt stuff? is it waiting for the current command has finished?
I have a few things in mind, I can test and change, but I am sure there are ways out there, that I don't know/think of?!
1. I will stop the interrupt timer every time I execute the midi process and restart it after it finished, to see, if the interrupt-tick freezes too at that moment
2. I will do some measurements to see if I can integrate the sequencing into the mainloop without having an unreliable midi clock
3. I will see if I can refactor the code in a way, to disable irq every time I change a value (right before I assign a value to the variable and enable it right after it) without having to do that all over the place.
Sorry for that long wall of text. I am thankful for every input I can get. Maybe I am looking at it wrong? Maybe my conclusions are wrong, and its no threading-issue?
Thanks, Jens
Last edited: