Is there any way to use c++ standard classes such as std::vector? My programs compiles and runs until it does the first call (besides the constructor). Then it crashes miserably.
The second part of the question is how to catch and report runtime errors like this. My monitoring involves using hw.seed.PrintLine(…) and screen /dev/ttyACM0
Thanks
Hi,
I’ve used std::vector in some of my code and don’t recall having to do anything special to make it work…
For debugging I’ve used the stlink with openocd and gdb to step through and create breakpoints etc.
Cheers
Could you provide any more details-info on what you mean by that? Such as error messages or symptoms such as looping, exception, etc?
Thanks to all who replied!
My stlink is in the mail, so the only way to see what is going on is via /dev/tty. I did a naive attempt to use try catch only to find out exceptions are disable in the compiler settings 
There are no error messages of any kind when the program crashes. It enters a looping state and none of the controls work. The only way to get out of that state is to reset.
I am thinking this may something to do with how the std::vector is allocated. I have tried declaring it both and static and non-static, but it doesn’t make any difference. I am wondering if declaring it as volatile would be the key,
I found the reason and it has nothing to do with using vectors. The program crashes when there are two or or more hw.seed.PrintLine() lines one after another in the audio callback.
The following code causes the app to crash:
hw.seed.PrintLine(“button 1 pressed”);
grain++;
hw.seed.PrintLine(“grain: %d”, grain);
It’s best to avoid putting anything in the callback which doesn’t absolutely need to be there.
1 Like
That is a great point and it brings another question. In all other embedded platforms I have worked with (Arduino, etc.) processing of any switches/pots usually happens outside of the timer interrupts. Most of the stuff I did before had that logic in the main loop (while (1) {…}).
In contrast, in all Daisy examples the switch/pot/encoder processing happens during the audio interrupt.
To add to that, none of the global variables are declared as volatile.
Any clues as of why the examples are written this was would be appreciated.
I was more concerned about the PrintLine code in the callback.