Serial.read() conflicts with FrequencyTimer2?

[i-make-robots]

I have a timer interrupt running at 1000us while the main loop is calling serial.read() and serial.print() to echo back what it receives. print() appears to work fine. Random characters are being dropped from the read(). If FQ2 is on timer2 and serial is on timer1, what's going on? How do I fix it? I'm considering adding a checksum to my serial.read() to see if that'll help.

I'm running on a Mega 2560, haven't tried it with uno or the other boards yet.

Thank you!

[rookie]

Without seeing the code I am guessing it has to do with being in the timer interrupt when the serial port tries to interrupt to process the incoming read()

Two things come to mind for fixes for this.

1. if you are using setOnOverflow() make sure you are doing as little as possible in it.
2. try making the timer longer, unfortunately that will also make the problem less likely to happen even if it is still happening.

and one for good luck.
3. If you want to share some code that is causing this, I could take a quick look at it. Send me a message through github.

also of note, it looks like the original project has been updated(and now this copy is the out of date one) so this project isnt needed anymore.

[i-make-robots]

Is there another github I should be posting to?

What I'm hearing is there's no way to really fix the problem by jimmying with the timer itself. Therefore I will add a checksum to the incoming data. if the checksum fails, resend the message. I am hard pressed to find a way to do less in the innermost loop (the interrupt) but I will dig a little deeper :)

Thank you for your prompt answer!

[rookie]

Yeah, interrupt service routine coding can get complicated. As long as the code is in that function, serial might lose something. Usually you just want to do something like i++ or i=1 just to let the main code know that something happened.

You can see some more info here. Under 'Note'
http://arduino.cc/it/Reference/AttachInterrupt

kind of an example:

isr(){
    trigger = 1;
}

loop(){
    if(trigger == 1){
        trigger = 0;
        doSomething();
    }
}

[i-make-robots]

Sadly I'm using the timer interrupt to do a lot of work (robotic motion control) much like in the GRBL. Somehow they avoid serial problems. ...because they run at a much lower baud?

[rookie]

maybe, is this for drawbot? push the code to a branch (or send me an email through github) and i can take a quick look at it.

ill go take a look at grbl and get back to you.

[rookie]

ok it looks like grbl is setting up some stuff in the isr then resetting the interrupt so that the rest of the function can be interrupted and then using the busy flag to signal when its done with the second part.
line 150 in ISR(TIMER1_COMPA_vect)
https://github.com/grbl/grbl/blob/master/stepper.c#L150

and yes, they are using a slow baud rate, 9600.

a couple other ideas.

• what was outlined above, allow the second part of your function to be interruptable. you will need a busy flag to make sure your function is not interrupting itself endlessly.
• since im not sure what has changed, maybe update the latest version of this (http://www.pjrc.com/teensy/td_libs_FrequencyTimer2.html)
• modify the FrequencyTimer2.cpp directly to not call a separate function in the ISR. pushing and popping registers to call a function takes time (not sure how much)

[i-make-robots]

Pushed to experimental branch. added the sei(), doesn't seem to help.

On Fri, Mar 30, 2012 at 11:33 AM, rookie <
reply@reply.github.com

wrote:

ok it looks like grbl is setting up some stuff in the isr then resetting
the interrupt so that the rest of the function can be interrupted and then
using the busy flag to signal when its done with the second part.
line 150 in ISR(TIMER1_COMPA_vect)
https://github.com/grbl/grbl/blob/master/stepper.c#L150

and yes, they are using a slow baud rate, 9600.

a couple other ideas.

• what was outlined above, allow the second part of your function to be
  interruptable. you will need a busy flag to make sure your function is not
  interrupting itself endlessly.
• since im not sure what has changed, maybe update the latest version of
  this (http://www.pjrc.com/teensy/td_libs_FrequencyTimer2.html)
• modify the FrequencyTimer2.cpp directly to not call a separate function
  in the ISR. pushing and popping registers to call a function takes time
  (not sure how much)

---

Reply to this email directly or view it on GitHub:
#2 (comment)