Go Down

Topic: Serial Communication and Interrupts (Read 866 times) previous topic - next topic

gerth2

Hello All!

I'm working on designing a robotics project, and was wondering if a triggering an interrupt on my Arduino Pro will mess up anything with the serial communication. I have two Arduino Pro's talking to each other over a simple Xbee network. I expect them to be exchanging data at least 50% of the time, and I wanted to know if triggering an interrupt on either end would potentially pose a threat to packet integrity. Thanks for any help you can provide!

PaulS

Quote
I wanted to know if triggering an interrupt on either end would potentially pose a threat to packet integrity.

No. During sending of a character, interrupts are disabled, so that all bits are send together. The are enabled again until the next character needs to be sent. Your interrupt can only fire when interrupts are enabled. It will cause serial data sending to be on hold while your interrupt does it's thing, so you need to make it quick.

Quote
I expect them to be exchanging data at least 50% of the time

No much margin for error, there. I think you need to reconsider this. What data are you exchanging? ASCII or binary?

gerth2

It's all ascii at this point,but either just single characters or a single character followed by four more characters which indicate how fast to run a set of motors.  The application is basically a remote-control, where i need to update motor values at least three or four times a second to ensure smooth operation.

I was intending to use the interrupts to count encoder ticks, but I'm not sure if I'll actually need to do that yet. I was just trying to see what options we had. However, if we only have 50% of those interrupts getting triggered, that's obviously not going to do much good. Especially for the robustness i'm looking for, it would be just as easy at that point to set up a second micrcontroller responsible for all sensor input data.

yesyes


Quote
I wanted to know if triggering an interrupt on either end would potentially pose a threat to packet integrity.

No. During sending of a character, interrupts are disabled, so that all bits are send together. The are enabled again until the next character needs to be sent. Your interrupt can only fire when interrupts are enabled. It will cause serial data sending to be on hold while your interrupt does it's thing, so you need to make it quick.


Interesting. Does this apply to the hardware serial port only or also to software serial ports (e.g. NewSoftSerial)?
While sending a byte, does the interrupt get lost or does the ISR automatically get called once the byte has been sent?
Chris

Location: Berkshire, UK
My Astro and DIY projects website: http://yesyes.info/

PaulS

Quote
It's all ascii at this point,but either just single characters or a single character followed by four more characters which indicate how fast to run a set of motors.

What are the 4 characters for? The Arduino PWM values only range from 0 to 255. Hey, look, that's the range of a byte, which is what can be sent over the serial port.

So, instead of 4 bytes to define the speed, only one byte is needed, so it gets sent in 1/4 of the time.

PaulS

Quote
Does this apply to the hardware serial port only or also to software serial ports (e.g. NewSoftSerial)?

NewSoftSerial uses interrupts, too. So, yes it applies to both.

Quote
While sending a byte, does the interrupt get lost or does the ISR automatically get called once the byte has been sent?

As interrupts, of a particular type, they get queued. When interrupts are re-enabled, the interrupt handlers for queued interrupts will be called. The queue can only hold one event of a given type, so if interrupts are disabled for any length of time, interrupts can be lost.

yesyes

Thanks a lot, that clears it up... ;-)
Chris

Location: Berkshire, UK
My Astro and DIY projects website: http://yesyes.info/

PeterH

I'm having trouble visualising how you're going to use this but I get the impression that you're planning to put control logic remotely and have that send motor demands to an Arduino that controls the motors.

In that case, rather than having all these elements screaming data back and forth, I'd suggest a different protocol consisting of a keepalive which just indicates what the current demands are, which could be sent at quite long intervals, and a 'delta' command telling it when the demand has changed. This fees up a lot of network and processing bandwidth on both sides which means you can afford to do a lot more other stuff, and will probably also be more responsive.
I only provide help via the forum - please do not contact me for private consultancy.

dc42

#8
Nov 24, 2011, 11:14 pm Last Edit: Nov 24, 2011, 11:18 pm by dc42 Reason: 1

No. During sending of a character, interrupts are disabled, so that all bits are send together. The are enabled again until the next character needs to be sent. Your interrupt can only fire when interrupts are enabled. It will cause serial data sending to be on hold while your interrupt does it's thing, so you need to make it quick.


True for software serial, but not for hardware serial. When sending serial data via the hardware serial port, interrupts remain enabled; but the hardware handles the bit timing, so interrupts do not affect it.

Interrupt service routines should be kept short and fast. If your ISR take more than one character time to execute, then you could lose incoming characters.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

Go Up