I've been reading serial threads and one interesting point was that you can overpoll serialAvailable, especially at lower baud rates. Ok, makes sense.
So trick would then poll serialAvailable in loop() and just stick on whatever until EOL and then process. Well and good, but I'm still polling at the loop() iteration rate.
How much simpler to have an IRQ fire when serialAvailable comes TRUE instead of polling all the time?
Soo the bottom line Q is "Does a serialAvailable IRQ exist?" Specifically on a quad port Mega 2560
Even though it is not an IRQ, you could use serialEvent(). Or you could create your own IRQ to check for available data, even though this would make no real sense..
Someone on another serial thread said that the serialAvailable only comes true at the character rate when a COMPLETED char has been received. It doesn’t just rise and stay up until EOM, it toggles char-by-char so a simple while(serialAvailable ()) isn't going to cut it to RX a full string.
I don't wanna POLL, i wanna do other stuff and only when an IRQ fires when serialAvailable would test TRUE.
I've never used it, but I have seen references to USART_RX_vect. Maybe take a look and see if it suits your purpose.
What would the irq connect to? Is the hardware wired that way internally?
That makes very little sense to me. If you are talking about Serial.available(), it returns true if there is data in the buffer (which is filled by an IRQ).
EDIT: "true" is misleading in this regard; non-zero is what is correct!
It would be quite a stupid machine that signalled serial data was available when it hadn't finished receiving the byte and so by definition was not available.
Yes there is an interrupt vector that is triggered when the single byte UART buffer has a byte in it. That is what triggers the system to remove it from the single byte hardware buffer of the UART and to put it into a buffer stored in Static RAM.
So what would you replace this with?
Agreed. Nonsense.
Just poll. If one more characters are available, handle them then go on to do your "other stuff". If not, go straight to the "other stuff".
I dont want to poll serialAvailable inside loop() especially if ive got multiple serials active at once, MEGA 2560 has four. So instead of spending all day checking four different serialAvailable's.
It would be a LOT cleaner to have an IRQ routine that only runs when data has ARRIVED that appends and only runs at EOM, otherwise loop() is running other stuff.
I'd service the irq THEN instead of hanging around waiting on while(serialAvailable)
I don't think you understand polling. You don't have to "hang around". Just check it and if nothing is available, do nothing, do your "other stuff". It takes microseconds.
You are not! Why would you claim such nonsense? Have you tried to benchmark "Serial.available()"? Look at the source code (link posted earlier), it is quite fast to check for available data..
OK so do it, are you going to have a software buffer or are you confident you can handle what ever you have to do before the next byte arrives in any of the three other UARTs?
I see code examples where waiting on messages is blocking. In an busy asynchronous environment with four ports running different baud rates polling can get ... cumbersome. If the processing only occurs at EOM then I've got inter-message time to play.
This works like a charm, as @Danois90 suggested in post #3.
void serialEvent() {
Serial.print("Received: ");
Serial.println(Serial.read());
}
void setup() {
Serial.begin(9600);
Serial.println("Please type something.");
}
void loop() {}
Dunno what to connect to make it work. I don't know about the processing time, thats what this experiment is designed to test!
Why do you look at such bad code?
Ok, thats about what im looking for