JeremiahRose
Member
I've been working on some new effect objects using the Teensy Audio Library and have run into an annoying problem. Sometimes, if I've made a mistake in my code somewhere, it causes the Teensy to become completely unflashable.
Here's a firmware to illustrate my point:
This contains a mistake: the constructor should be
The result is if this code is allowed to enter the main loop() function, it completely freezes up the Teensy to the point where it no longer accepts commands over serial and cannot be flashed. The only way to fix it is to do a factory reset by holding down the button for 15 seconds. This is an un-workable solution for me as my teensies are hidden inside a case with a fair bit of disassembly required to get to the button.
Merely trying not to make any mistakes in my code is also not a workable solution. Mistakes are a normal part of development! What I really need is a way to be able to test my code without fear of accidentally placing the Teensy in an unflashable state.
As a work-around, I've placed a 10 second delay in the setup() function, which gives me time to flash the Teensy after resetting power in the case that I make a mistake in my audio library development. However, that's not ideal either.
Any suggestions? Is this a bug in the audio core? Could it be made more resilient?
The other thing I'm wondering is what affect (if any) AudioNoInterrupts() vs AudioInterrupts() would have on this problem.
Here's a firmware to illustrate my point:
Code:
#include <Audio.h> // Teensy audio library
#include "AudioStream.h"
const bool DEBUG = true; // Debugging over serial
class AudioEffectCrashTeensy : public AudioStream
{
public:
AudioEffectCrashTeensy() : AudioStream(0, NULL) {}
virtual void update(void) {
audio_block_t *block;
block = receiveReadOnly();
if (!block) return;
transmit(block);
release(block);
}
private:
audio_block_t *inputQueueArray[1];
};
// Initialise audio objects
AudioSynthWaveform waveform1;
AudioEffectCrashTeensy effect1;
AudioOutputI2S i2s1;
AudioConnection patchCord4(waveform1, effect1);
AudioConnection patchCord2(effect1, 0, i2s1, 0);
AudioConnection patchCord3(effect1, 0, i2s1, 1);
void setup() {
if (DEBUG){
Serial.begin(9600);
while (!Serial);
Serial.println("Debug enabled. If overwriting bad firmware, do it now.\n10 seconds until main loop begins...");
delay(1000);
for (int i=9; i>0; i--){
Serial.println(i);
delay(1000);
}
Serial.println("Audio on.");
}
AudioMemory(10);
waveform1.frequency(440);
waveform1.amplitude(1.0);
waveform1.begin(WAVEFORM_TRIANGLE);
}
void loop() {
AudioNoInterrupts();
AudioInterrupts();
}
This contains a mistake: the constructor should be
Code:
AudioStream(1, inputQueueArray)
Merely trying not to make any mistakes in my code is also not a workable solution. Mistakes are a normal part of development! What I really need is a way to be able to test my code without fear of accidentally placing the Teensy in an unflashable state.
As a work-around, I've placed a 10 second delay in the setup() function, which gives me time to flash the Teensy after resetting power in the case that I make a mistake in my audio library development. However, that's not ideal either.
Any suggestions? Is this a bug in the audio core? Could it be made more resilient?
The other thing I'm wondering is what affect (if any) AudioNoInterrupts() vs AudioInterrupts() would have on this problem.