Hello. Pardon if this is common knowledge but does the IDE have any background interrupts going on while a sketch is running? I am running the ADC in continuous sampling mode (9615Hz) and have a pin toggle at the beginning and end of the ADC ISR. I can see about 10% jitter on the scope. Am assuming some other higher priority interrupt is causing this as the ADC is pretty far down for interrupt priority. Maybe a serial comm. interrupt? Serial monitor is turned off and there are no other interrupts enabled.
Oh and when I hit the reset button the jitter goes to zero and I get a stable sample rate as expected for a second or two while the processor goes into reset.
As I understand it, the main() of a sketch does stuff related to the USB - looking to see if another sketch is coming down the pipe - in between each call to loop().
PaulMurrayCbr:
As I understand it, the main() of a sketch does stuff related to the USB - looking to see if another sketch is coming down the pipe - in between each call to loop().
That's part of the bootloader process and only active for a few seconds after reset. Below the main function
int main(void)
{
init();
initVariant();
#if defined(USBCON)
USBDevice.attach();
#endif
setup();
for (;;) {
loop();
if (serialEventRun) serialEventRun();
}
return 0;
}
As can be seen, in an endless loop loop() is called followed by execution of the if statement.
You can find serialEventRun in the HardwareSerial files; it will call serialEvent() if serialEvent is defined by the user and serial data is available.
mholin:
Serial monitor is turned off and there are no other interrupts enabled.
Switching serial monitor off does not stop the sending of serial data by the main micro. On a standard Uno e.g., data will still be send from the 328 to the 16U2 (USB chip). The 16U2 will receive that data but discard it (and not flash the TX led).
If anyone is interested, I believe I found the problem or at least I know how to fix it.
First of all to answer some questions, I was not using millis() or delay() but I am using Timer 0 for a PWM but not in interrupt mode, none the less I see the TOIE (Timer 0 Overflow Interrupt Enable) bit of TIMSK0 (TC0 Inerrupt Mask Register)register was set by default (perhaps for the delay() function). By clearing TIMSK0 at the very beginning of the sketch, the ADC ISR now occurs with no jitter.
mholin:
I see the TOIE (Timer 0 Overflow Interrupt Enable) bit of TIMSK0 (TC0 Inerrupt Mask Register)register was set by default (perhaps for the delay() function). By clearing TIMSK0 at the very beginning of the sketch, the ADC ISR now occurs with no jitter.
Yes, TIMSK0 = 0 ; will turn off timer0 overflow interrupts. These are used for millis(), micros() and delay(), which will stop working properly.
These are used for millis(), micros() and delay(), which will stop working properly.
An interesting side effect of shutting off TC0 interrupts is the Serial Monitor "Send" no longer works. Any data sent from the IDE to the Uno does not appear to be read by the Uno but "Receive" serial data over the Serial Monitor does appear to be sent/received okay.
Anybody have any insight into this? Apparently the Serial Monitor must require TC0 interrupts in order to function. Related question, are these Arduino functions documented in detail anywhere other than the Reference page? Is the source code around somewhere even?
All the source code is included as part of an IDE install.
Are you saying Send from the PC stops working? That could be, if interrupts are off there is no way for the incoming buffer to let anybody know to empty it & make room for the next byte.
CrossRoads:
Are you saying Send from the PC stops working? That could be, if interrupts are off there is no way for the incoming buffer to let anybody know to empty it & make room for the next byte.
That is correct, Send from the IDE Serial Monitor no longer works. Note that not ALL interrupts are turned off, just TC0 (timer/counter 0) overflow interrupt. All the serial comm. interrupts remain whatever the default setting is.
However, if Send uses TC0 that would explain it. That is why I wanted to see the source code for Serial.readString().
readString uses a timeout based on millis(). You can find the source code (on a Windows system) in the file C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\Stream.cpp
It can easily be fixed by using the normal Serial.read() function and implement your own version; see Robin2's Serial Input Basics - updated how to read into a byte array and process.
