@ksltd: I agree with most of what you are saying and that goes for any references to FDS as well I don't believe however that it is necessary to do statistical sampling of the data bits as any noise that bad IME will have to be dealt with at the hardware or frame level.
Now my 2 cents worth:
I think that the start bit should be verified because start bit edge detection can always be triggered by noise and if a sampling in the middle of the start bit indicates it is false then the receive should be restarted. The stop bit should also be sampled as there may be a framing error or a break in which case I count up the number of consecutive framing errors that result in data=0 to detect a break and reboot the Prop which is very handy over remote links.
Sampling at x3 or more only makes sense if you are testing for a start bit by timed sampling whereas the next sample would verify it.
FDS and Spin contribute to gaps between transmit characters which effectively means that it can't transmit at full throughput at higher baud rates anyway, so 1, 1.5, or 2 stop bits make no difference whatsoever. Resynchronization can only be achieved if there is a gap of at least one character and maybe the lack-luster performance of FDS is a "feature" in this regard.
As for multiport objects they are nice to have but IMO I wouldn't rely on them for any higher speed operation. The idea that the cores of the Prop can be soft peripherals is good in theory, it's just that they could have been augmented with a little hardware support such as edge detection and shifters otherwise they compare poorly to real peripherals. At higher speeds to do a UART properly in respect to bit timing you really need one cog for receive and one for transmit and that is a terrible waste of resources although I do something similar in Tachyon except the transmitter is bit-banged directly in the VM cog.
Now there are many many applications and also in this forum that are using full-duplex when in fact they are simple command/response or master/slave and could just as easily use half-duplex so that one cog could provide reliable high-speed transmit or receive. It's also evident too that there is usually no need most of the time to buffer transmit data, only for it to be unbuffered as the application has to wait for a response anyway. It is just as easy then to bit-bash the transmit data directly and get it right although within the Spin cog itself this is only possible at slower baud rates. Bit-bashing transmit data directly without buffering also makes a lot of sense at higher baud rates.
So FULL-DUPLEX is overrated and misused and ends up most of the time as effectively HALF-DUPLEX.
To help compensate for the hub latencies during receive buffering I find it helpful to write the data to the hub when the last data bit is sampled and then only write the write index if the there was no framing error during the stop bit. My receive start bit timing is not exactly half the bit-time but adjusted so that it does sample at half bit-time.
BTW, if all asynch transmission always had a start bit followed by a complementary start bit (low then high say) then auto-baud would be a lot easier, all you would have to do is measure the start bit which would work with any character any time and allow for character by character timing. So even without crystal locked timing it would be possible to communicate reliably.
jmg,
The nice thing about industry standard terms is that the reader can determine their meaning without the writing having to explain..
Again you have failed, and rather poorly, to answer the question.
- but hey, I did get a wry smile at this nugget:
"can determine their meaning without the writing having to explain.."
So FULL-DUPLEX is overrated and misused and ends up most of the time as effectively HALF-DUPLEX.
Agreed, which is why CAN Transceivers offer a good HW solution to medium distance comms, even with UARTS (Half Duplex).
However, whilst mostly"FULL-DUPLEX is overrated and misused and ends up most of the time as effectively HALF-DUPLEX." it is actually not easy for users to know all their transactions are half-duplex.
A 'CAN' HW layer gives a partial peek at such half-duplex failings, as it can catch when Rx <> Tx during the send phase. (ie not as half-duplex as the user thought )
I guess a prop could measure the turn-around time, and report if it goes under some threshold.
Most of the implementations of which I'm aware do a good job of disambiguating industry standard rates. None synchronize to random rates.
Another sweeping statement, that falls on its face.
The Autobaud systems that I code (and most I know), are limited by the timing precision of the MCU they are on, and they have no idea of what "industry standard rates" even is. They think only in SysCLK terms.
A number I have tested fail to correctly round, but that is a technical implementation error.
To the receiver, that variable latency is seen as jitter, but it is not the only source of jitter at the receiver.
Which was exactly the point I was making.
Perhaps if you paused to read what you typed, and refrained from sweeping claims, this thread might be more productive.
I am interested in pushing the HW limits in speed, I do that every day.
I am less interested in incorrect claims and generalities.
I am surprised at the number of times I see people using multiple copies of FullDuplexSerial instead of one of the versions of the FullDuplexSerialFourPort object. Not only does this require a cog for each copy, it is at least as complicated if not more so than using the four port object.
I've just have a very strange thing trying to debug two propellers talking to each other. The code is pretty simple - listen on a pin, transmit on another pin, but at times there could be data going both ways - so receiving data, transmitting it, and receiving on another port and transmitting it as well.
I thought the 4 port object would be perfect for this. Ok, not quite the 4 port one, a modification of that which is 2 ports but with 256 byte buffers. I've used it for over 5 years in various projects, but I couldn't get it to work properly. Some bytes were being missed and some were coming through as zeros.
Yet - go back to the old original fullduplexserial, and create two copies, and it works fine.
Re the original question, I wonder if others have found this, then simply gone back to having two objects? And maybe in my case it is the modified 4 port object that is the problem, not the original 4 port one? Or maybe it is because I have never actually pushed it to the limit with having data going all directions at once? Mind you, only at 9600 baud.
I would like to debug this further, but I'm in the middle of another project at the moment, so I'm going to stick with the simple solution of having multiple instances of fullduplexserial.
Comments
Now my 2 cents worth:
I think that the start bit should be verified because start bit edge detection can always be triggered by noise and if a sampling in the middle of the start bit indicates it is false then the receive should be restarted. The stop bit should also be sampled as there may be a framing error or a break in which case I count up the number of consecutive framing errors that result in data=0 to detect a break and reboot the Prop which is very handy over remote links.
Sampling at x3 or more only makes sense if you are testing for a start bit by timed sampling whereas the next sample would verify it.
FDS and Spin contribute to gaps between transmit characters which effectively means that it can't transmit at full throughput at higher baud rates anyway, so 1, 1.5, or 2 stop bits make no difference whatsoever. Resynchronization can only be achieved if there is a gap of at least one character and maybe the lack-luster performance of FDS is a "feature" in this regard.
As for multiport objects they are nice to have but IMO I wouldn't rely on them for any higher speed operation. The idea that the cores of the Prop can be soft peripherals is good in theory, it's just that they could have been augmented with a little hardware support such as edge detection and shifters otherwise they compare poorly to real peripherals. At higher speeds to do a UART properly in respect to bit timing you really need one cog for receive and one for transmit and that is a terrible waste of resources although I do something similar in Tachyon except the transmitter is bit-banged directly in the VM cog.
Now there are many many applications and also in this forum that are using full-duplex when in fact they are simple command/response or master/slave and could just as easily use half-duplex so that one cog could provide reliable high-speed transmit or receive. It's also evident too that there is usually no need most of the time to buffer transmit data, only for it to be unbuffered as the application has to wait for a response anyway. It is just as easy then to bit-bash the transmit data directly and get it right although within the Spin cog itself this is only possible at slower baud rates. Bit-bashing transmit data directly without buffering also makes a lot of sense at higher baud rates.
So FULL-DUPLEX is overrated and misused and ends up most of the time as effectively HALF-DUPLEX.
To help compensate for the hub latencies during receive buffering I find it helpful to write the data to the hub when the last data bit is sampled and then only write the write index if the there was no framing error during the stop bit. My receive start bit timing is not exactly half the bit-time but adjusted so that it does sample at half bit-time.
BTW, if all asynch transmission always had a start bit followed by a complementary start bit (low then high say) then auto-baud would be a lot easier, all you would have to do is measure the start bit which would work with any character any time and allow for character by character timing. So even without crystal locked timing it would be possible to communicate reliably.
- but hey, I did get a wry smile at this nugget:
"can determine their meaning without the writing having to explain.."
However, whilst mostly "FULL-DUPLEX is overrated and misused and ends up most of the time as effectively HALF-DUPLEX." it is actually not easy for users to know all their transactions are half-duplex.
A 'CAN' HW layer gives a partial peek at such half-duplex failings, as it can catch when Rx <> Tx during the send phase. (ie not as half-duplex as the user thought )
I guess a prop could measure the turn-around time, and report if it goes under some threshold.
The Autobaud systems that I code (and most I know), are limited by the timing precision of the MCU they are on, and they have no idea of what "industry standard rates" even is. They think only in SysCLK terms.
A number I have tested fail to correctly round, but that is a technical implementation error.
?? Is then directly contradicted by this Which was exactly the point I was making.
Perhaps if you paused to read what you typed, and refrained from sweeping claims, this thread might be more productive.
I am interested in pushing the HW limits in speed, I do that every day.
I am less interested in incorrect claims and generalities.
I've just have a very strange thing trying to debug two propellers talking to each other. The code is pretty simple - listen on a pin, transmit on another pin, but at times there could be data going both ways - so receiving data, transmitting it, and receiving on another port and transmitting it as well.
I thought the 4 port object would be perfect for this. Ok, not quite the 4 port one, a modification of that which is 2 ports but with 256 byte buffers. I've used it for over 5 years in various projects, but I couldn't get it to work properly. Some bytes were being missed and some were coming through as zeros.
Yet - go back to the old original fullduplexserial, and create two copies, and it works fine.
Re the original question, I wonder if others have found this, then simply gone back to having two objects? And maybe in my case it is the modified 4 port object that is the problem, not the original 4 port one? Or maybe it is because I have never actually pushed it to the limit with having data going all directions at once? Mind you, only at 9600 baud.
I would like to debug this further, but I'm in the middle of another project at the moment, so I'm going to stick with the simple solution of having multiple instances of fullduplexserial.
Apparently, my PBnJ_serial.spin (Precision, Basic no Jitter) full-duplex serial driver solved the OP's problem and worked at up to 115.2 kBaud.
-Phil