Hello, I have come across SoftwareSerial which allows you to designate two pins to be used in Serial comms, I have just tested it using pins D11 and D12, connected to RxD and TxD (pins D0 and D1).
My query is, when I do SoftwareSerial::listen() how does it wait for incoming data? This sort of checking for highs and lows on a pin and determining the start of a sequence is the realm of UARTs which do it in hardware. How does it listen then? Does it use some Atmega328 functionality or is it looping like crazy polling the pin?
It doesn't. It has a method to tell you whether it has received any, just like Serial.
How does it listen then?
Any pin that supports pin change interrupts can be used for SoftwareSerial. The process of receiving data is then very similar to Serial, except using slower pin change interrupts instead of the faster hardware interrupts.
Does it use some Atmega328 functionality or is it looping like crazy polling the pin?
PaulS:
It doesn't. It has a method to tell you whether it has received any, just like Serial.
Any pin that supports pin change interrupts can be used for SoftwareSerial. The process of receiving data is then very similar to Serial, except using slower pin change interrupts instead of the faster hardware interrupts.
That's not an either/or question.
A quick look at the source code for software serial
It uses PCINT (a feature of the Atmega chip) to notice the change in the bits. Then it goes into a loop with delays in it while it waits for and reads each bit, and then stores the result in the buffer.
In non-software serial, it enables receive and the receive interrupt on the hardware UART module on the chip, and that module (in hardware) listens for characters arriving. The receive interrupt fires once the whole byte has been received, and the ISR just has to copy it into the buffer.
So among other things - with software serial, while it's receiving, the chip is totally focused on watching that pin, from the time it gets the first start bit until the end of the character.
With hardware serial, the part of the chip you program only has to grab a byte from a register and throw it into a buffer, and the hardware UART handles the rest in the background, signaling interrupts in response to received characters (and sent characters).
The same sort of deal happens with sending too - with software serial, the chip is busy the whole time, precisely writing out bits with the right timing, while hardware serial, the UART module does that - you just give it a byte, and when it's done sending it, it fires an interrupt.
That said, the software serial API is nearly identical to the hardware serial one.
"It uses PCINT (a feature of the Atmega chip) to notice the change in the bits. Then it goes into a loop with delays in it while it waits for and reads each bit, and then stores the result in the buffer. "
Ahh I did not know about the PCINT and was wondering how on earth could it possibly receive control. But then it goes into polling, which is bad. Well, depending on what else you may be doing. It may be perfectly OK if you have no other choice.