I wanted to understand if it is possible to attach interrupts to the serial ports or at least to one of them.
You can set up a pin change interrupt on any pin, including those used for serial data reception/transmission. The question is why you want to do that. Checking for the presence of serial data on each pass through loop is usually often enough. Serial data transmission and reception is relatively slow, so triggering an interrupt when a character arrives is usually not necessary or desirable.
Can you give me a fast example of how i can set up a pin change interrupt on any pin.
Normally using interrupts is cleaner, but i agree that in cases brings a world of pain and some more stuff.
I´m going to take into consideration what you said, maybe i don´t really need it
LuisSoares:
...
I wanted to understand if it is possible to attach interrupts to the serial ports or at least to one of them.
The Arduino core HardwareSerial library (that's what you are using when you execute Serial.begin() (or Serial1.begin(), etc., for Mega boards) already uses interrupts for the UART receiver. The library code puts received bytes in a circular buffer that are accessed by Serial.read(), etc.
You can check the code in HardwareSerial.cpp in your Arduino installation tree (in the arduino-0022/hardware/arduino/cores/arduino directory for example).
The NewSoftSerial library implements pinchange interrupt service routines for its receivers. When the receiver is in its "idle" state, a change on the indicated pin causes the class recv() method to shift the bits into a byte and store into a circular buffer.
You can check the code in NewSoftSerial.cpp
Regards,
Dave
Footnote:
It is my understanding that the NewSoftSerial library will (glory be!) replace the creaky old non-interrupt-driven SoftwareSerial library that has (up to now) been supplied with the Arduino distribution.
If i understood right the buffering of the Data on the software side is done seamlessly by interrupt? Is that it.
But if this is the case i continue to have the same problem (you only avoid exceeding the maximum serial port buffering capacity) you still don´t have the capacity of responding instantly to some request on the serial port, unless you constantly check for new data on your software buffer.
But if this is the case i continue to have the same problem (you only avoid exceeding the maximum serial port buffering capacity) you still don´t have the capacity of responding instantly to some request on the serial port
True. On the other hand, requests are usually multi-byte constructs. Knowing immediately that a character in the middle of the request has arrived would benefit you how?
What is it that you think you need to provide an immediate response to?
One way to think of serial data is like posting on the forum. You don't need to take action each time I type a letter. That's what you would be doing if serial data arrival triggered an interrupt that your program responded to.
You may, or may not, need to take action when I hit the post button, though. The only way you know I have hit the post button is to check the forum to see if there are responses to your posts.
Since I can't see where you need to care about each character I fat-finger, I can't see where interrupt driven serial data checking is useful, either.
There are some cases where it could be useful and feasible.
For example if you use very small codes like "ATK". You can use the serial port in assynchronous way (interrupt driven behaviour) and might not need to check constantly for new characters, since you already know your codes are small.
For example if you use very small codes like "ATK".
Even in this case, you'd have an interrupt after the 'A' arrived, in which you wouldn't have to do anything, since the end of packet marker hasn't arrived.
You'd have another interrupt after the 'T' arrived, in which you wouldn't have to do anything, since the end of packet marker hasn't arrived.
You'd have another interrupt after the 'K' arrived, in which you might have to do something, if you expect only/exactly three characters per request.
The interrupt handler needs to be very fast, since it must complete before another interrupt arrives. So, it can't send a reply, since Serial.print() and Serial.write() take too long to be used in an interrupt handler.
So, the interrupt handler would just set a flag that loop() (or some other function) checks to see if is necessary to react to the serial data that has been received.
How checking that flag is more effective/faster than checking that Serial.available() is greater than 0 escapes me.
I can´t really remember a real world application but imagine the absurd of a one letter code "A".
The only real reason i´m seeing for using interrupts, is for example if you have a really big sketch of code, that takes really long to be executed.
You might end up having timeout in the comunications, if the block of code takes more then 3 seconds to execute or something, and you don´t reply in time.
But in this case you can put some line of code to check the serial data, in the middle of the really big block of code, so ...
I´m sure there should be some crazy use for the interrupts , but in the major part i´m with you on this