I wish to bring in GPS data from an Adafruit GPS shield. The demo code seems to explicitly avoid use of interrupts for UART on the Due. Not surprisingly there are comments in the code that say you can't do much of anything else while you're listening to the GPS chip for fear of losing NMEA sentences.
is there any library code available that supports interrupt driven serial input?
The serial ports ARE interrupt driven....
Yes, the serial code on the due is interrupt driven both for RX and TX. The receive buffer is only so large though - 128 bytes. So, let's say your GPS data is 40 bytes per transmission. That means you can buffer three of them with no data loss but if the fourth comes in and you haven't gotten to checking the serial buffer it will overflow. So, chances are the original code is saying not to neglect the serial buffer. It is accurate to say that your sketch will not normally be interrupted when serial data comes in so you have to explicitly check for data. The data itself came in interrupt driven but you didn't get the interrupt - the Arduino core did. So, you have to poll for the data but you don't have to poll right when the data are coming in. You just have to do it frequently. There is a way to get serial interrupts yourself but unless you have a very compelling reason to do so you shouldn't.
Thanks, I now understand fully. I'm by no means a rookie, and would have expected it the way you described, Collin80, but the words I read in the Adafruit GPS "due_parsing" demo suggested otherwise.
Now I think about it, the fact that the "due_parsing" has the timer interrupt code disabled should have been a clue that the Due had a rcvd char interrupt handler, but oh well, I know now.
Until fairly recently, Due had only RX interrupts for hardware serial. TX was done by polling.
Transmit buffering & interrupts were added only a several months ago.
Older tutorials and websites might mention Due's lack of serial interrupts. It was only for transmit. Since Due's release 3 years ago, it has always used interrupts for serial receive.
Thanks for that further clarification, Paul, that helps me a lot. I'll be doing some multi-threaded work with some bi-directional RS-485 communications, so it's good to know that.
Here's a very related question for you and other seasoned Arduino wranglers...
In my project the Due is a head-end unit, handling user interface via touchscreen TFT, receiving GPS data, performing SD logging, running a closed loop algorithm to produce a heating power command value, and being an RS-485 master to a remote slave. I can tell already that it's well capable of doing what I need.
The other (remote slave) end - for which I am targeting some other, smaller Arduino board such as the Arduino Pro ATmega328 - will accept the RS-485, generate two PWM signals based on the commands it receives, do three channels of A2D, and report back via RS-485. The communications load will be about 8 bytes payload plus nominal wrapper overhead every 10msec in each direction.
Will the ATmega328 do that for me (bearing in mind the need for reliable RS-485 comms), or do I need something more powerful, do you suppose?
Thanks in advance for advice.