I would like to check something before getting started. This Is the situation.
I've been developing a 'arduino-based' master-slave network together with a friend of mine. I'm doing the hardware, and he's coding.
In the network one arduino is acting as a master and other arduino's act as a slave.
The system works with a master 'polling' the slaves. This poll triggers an 'Serial-interrupt' on the slave.
Now, here's the thing; with one of the slaves we're gonna read a motor encoder, and we would like to use the external hardware interrupts on pin 2 and 3.
Now, would these interrupt interfere with each other?
I'm not sure, but isn't the 'filling the serial buffer' triggered by an interrupt? My question is if that interrupt could interfere with an external interrupt? Or are they always; 'one after another'? Basically my question is, what happens if interrupt1 is doing it's thing and interrupt2 is called at exact the same time?
Or are you reimplementing all of the serial communication?
No, we're using the serial-lib as is in combination with RS485 hardware and a self-written message center which handles all the data flow.
Isn't checking for data in the input buffer sufficient?
The data received tells the slave to receive more data and to deal with it, or not. But because the poll is called so often the interrupt is called very often.
If you read the datasheet for e.g. the ATmega328, you will find that there are 'interrupt flags' that are set in some registers.
There are basically two types of interrupts. The first type is triggered by an event that sets the
Interrupt Flag. For these interrupts, the Program Counter is vectored to the actual Interrupt Vec-
tor in order to execute the interrupt handling routine, and hardware clears the corresponding
Interrupt Flag. Interrupt Flags can also be cleared by writing a logic one to the flag bit position(s)
to be cleared. If an interrupt condition occurs while the corresponding interrupt enable bit is
cleared, the Interrupt Flag will be set and remembered until the interrupt is enabled, or the flag is
cleared by software. Similarly, if one or more interrupt conditions occur while the Global Interrupt
Enable bit is cleared, the corresponding Interrupt Flag(s) will be set and remembered until the
Global Interrupt Enable bit is set, and will then be executed by order of priority.
So if 2 interrupts 'fire' = 2 interrupt flags get set, everything is still OK and will be processed according to priority (see datasheet as well). If e.g. one interrupt fires too fast it may 'get lost', as the 'queue length' is just the one flag bit. In your case, if you send data too fast and the 2nd byte arrives before the interrupt that was triggered for the 1st byte has been executed (moved the content of UDR into the input buffer), one byte will be lost. This would only happen if the serial interrupt were 'blocked' by something more important. And at that point the whole program would probably appear to be frozen.
It all depends on the interrupt frequency. As the external interrupts (int0, int1) have high priority, they will at one point interfere with serial I/O. You can test that by spinning your motor up until it happens. If you have a logic analyzer this could be visualized nicely.
Just to make it clearer: the hardware UART will always receive at least one byte of data, the question is whether it gets copied to some input buffer fast enough before the next byte arrives.
I would like to check something before getting started. This Is the situation.
I've been developing a 'arduino-based' master-slave network together with a friend of mine. I'm doing the hardware, and he's coding.
In the network one arduino is acting as a master and other arduino's act as a slave.
The system works with a master 'polling' the slaves. This poll triggers an 'Serial-interrupt' on the slave.
Now, here's the thing; with one of the slaves we're gonna read a motor encoder, and we would like to use the external hardware interrupts on pin 2 and 3.
Now, would these interrupt interfere with each other?
The execution of one of the ISRs may be delayed by the time taken to execute the other. Provided you keep the interrupt service routine for the motor encoder short and fast, you should be OK.