This thread is a follow up to the lasts posts in this thread.
This is my understanding of how a the newSoftSerial library interacts with the programs that use it:
The newSoftSerial-library manages fetching of indidual bits from a stream of serial data coming into one of the pins on the ardino. It does this using interrupts, which means it gets noticed when the pin changes state from hight to low or vice versa, then collects the bit and puts it in a rather large buffer (64 byte) in system memory.
The programs that has to use the newSoftSerial library then only has to check the big buffer to see if new data has arrived (using the function Serial.available() ). In principle, this leaves the program in the same situation that made the software serial library use interrupts: One has to poll the buffer to know if it contains anything. This would have been just as problematic, had it not been for the fact that the buffer is significantly larger and thereby has to be polled less frequently, thereby putting less of a strain on the CPU.
While not being familiar with the new library of which you speak you can't be right because:-
which means it gets noticed when the pin changes state
is not sufficient to get all the bits in. This data is asynchronous, NRTZ (none return to zero) which means if you send three 1s in a row the line will stay high for three bit periods. There is no transition and therefore your understanding of this bit is wrong.
In other words, without the new soft serial library, the application has to check every bit to see if it has changed – if it misses one of the bits the data gets corrupted. With the new library, the data gets collected in the background and the application can wait hundreds of times longer between calls to the soft serial code with no loss of data.
If you describe the overall structure of your application and perhaps post the code in your loop, someone here can help you add the code to check for serial data.
This would have been just as problematic, had it not been for the fact that the buffer is significantly larger and thereby has to be polled less frequently, thereby putting less of a strain on the CPU.
I assume by polling you mean checking the newSS.available() function. This is not to keep from putting "a strain on the CPU". It avoids putting a strain on you, the programmer.
RS232 communications are typically glacially slow compared to the clock speed of the CPU. It takes a little over a millisecond to receive a byte at 9600 baud. During this time, the 16MHz ATmega on your arduino can process as many as 16,666 instructions!
What interrupt-driven software serial provides (using interrupts and the buffer) is non-blocking serial read capability. With earlier versions of software serial, your program stopped execution (i.e. blocked) until it read a byte. If you did much SoftwareSerial input, your program did pretty much nothing except wait for a byte to arrive. If the program took too much time processing that byte once it got there, it may well miss the next byte.
Instead, newSS uses the interrupt to allow the program to continue executing, at the cost of the program getting briefly interrupted every so often (I haven't looked at the code, but I suspect no more than once per bit-time, or about 0.1ms at 9600 baud). It also needs some buffer space to store its work until the program gets around to consuming the data. In return, you get to program as if your ATmega sprouted another UART, which is not a bad trade if you need another UART.
Here's how serial works. Your RX pin stays "high" when it's idle. The remote partner pulls it low to signal that you are about to receive some data. The line remains low (the "start bit") for 1/38400 or 1/1200 of a second -- determined by the baud rate -- and then you get the other bits of data at similar intervals immediately afterwards.
Now if you're using Software serial, you'd better be checking that line no less often than every 26 microseconds (for 38.4K baud -- 833us for 1200) or else you'll risk missing the start bit and get corrupted data. As kg4wsv notes, it's a difficult programming task to get anything done while making sure you don't miss anything important.
AFSoftSerial and NewSoftSerial monitor this pin with an interrupt handler. As soon as it goes low, the interrupt routine takes over, scoops up the byte of data, places it in the buffer, and returns control. This gives you much more flexibility, because it's a lot easier to check NewSoftSerial a few times a second than to check SoftSerial a few times a MILLESECOND. And if you screw up and your program can't keep up, well, at least the data in the buffer is still valid. The worse thing that can happen is that you lose a few bytes. If you miss with SoftSerial, your data is bad!
Grumpy_Mike, you are correct that within a byte there may be consecutive bits that do not cause a transition from hi to low or vice-versa. But once the interrupt is initially triggered, the whole byte is capture using timing. In other words, the collection of each bit doesn't depend on an interrupt, only the initial one.
This has some negative consequences. When you use 300 or 1200 baud, the amount of time spent in the interrupt handler gets too long -- 33ms for 300 baud. This starves the system clock and your millis() gets a little wonky.
