As Sapieha said, 1/1.5/2 are standard; I added 3 for extra spacing at extremely high baud rates. It might get us 10-50mbps with some of the newer USB/serial chips.
I agree with David . Also, wouldn't you have to at least clear or flush before you try communicating with the buffer, device etc ?
Are 1/1.5/2/3 stop bits for serout" industry standards? If so, couldn't none conforming industry standards end up causing additional problems and confusion?
I think you have hit it on the head, and based on your findings, I now think that the precise nature of the problem is the uart within the FTDI chip not being able to lock on to the start bit when the data stream is back to back, with no inter-character gap.
I'll admit, it never occurred to me that you might be plugging into a live data stream !!
Even fractional stop bits will only help a little, in that some lottery will occur as to how many chars it takes to 'lock'.
As Sapieha said, 1/1.5/2 are standard; I added 3 for extra spacing at extremely high baud rates. It might get us 10-50mbps with some of the newer USB/serial chips.
I'm curious, do 2 or 3 stop bits work? I would have thought they might have the same problem since the spacing between characters is a multiple of the bit time. I can see how 1.5 or 1.25 might work since an extra edge not on a bit boundary might let the UART resync.
The reason why 1.5 and more bit periods for the stop bit work is that the uart will get a framing error on the first or second byte it finds, but the extra spacing will help it find a "proper" start bit.
Not having an easily discernible stop/start bit transition is what stopped the FTDI's uart from locking onto the data stream.
Granted, starting up a USB/serial link in the middle of a full-blast 1 stop bit back-to-back character stream is definitely a torture test...
I'm curious, do 2 or 3 stop bits work? I would have thought they might have the same problem since the spacing between characters is a multiple of the bit time. I can see how 1.5 or 1.25 might work since an extra edge not on a bit boundary might let the UART resync.
0.125 stop bits is NOT enough, and we get unsynchronized reception by the FTDI again.
Perhaps the configurable stop bits for serout should be 1/1.25/1.5/2 ?
But surely this is a very rare usage ? - anyone who really expects a system to swallow "no-gaps-at-al" data arriving with any phase from cold-boot, can just use an extra stop bit ?
More relevant testing, would be to push UP the baud settings, and see where the FTDI has streaming issues (not sync issues)
I have tested FTDI & SiLabs parts on Loop-back, and find above ~ 500k baud, they start to add stop bits themselves.
(ie they cannot pump the data around, as fast as it arrives)
No data is lost, but the sustained byte data rate is lower than Baud/10.
The FT232H series, can stream well over 1MBd with no gaps.
I did one streaming test with 921k data, and that seemed to be ok, I did not test above that.
Silabs claims ~2MBd and FTDI ~3MBd so it would be worthwhile seeing what size packets they can tolerate, and if any extra stop bits are needed approaching those upper limits.
I think both parts have virtual Baud cocks of 24MHz, so valid bauds are 3M, 2.66M, 2.4M, 2.18M, 2M, 1,84M etc
eg 3MBd with 3 or 4 stop bits, may still be faster than 1.5MBd with 1 stop bit.
I'd guess they should accept data up to the FIFO size ok, but above that the time to empty & process may push down the sustained speed a little.
2 and 3 work just fine.
Granted, starting up a USB/serial link in the middle of a full-blast 1 stop bit back-to-back character stream is definitely a torture test...
This can still be data content dependent. One stop bit, with some 0FFH data should be ok.
I tried it, sending a $FF (before Hello World), and the FTDI chip re-syncs then even with one stop bit quite nicely
Ray & evanh
My experiments show that using 1.5 stop bits allows re-syncing on every byte
Hypothesis:
FTDI samples every quarted bit period (or less), so the extra half stop bit gives a large enough gap to "notice" the stop bit / start bit even on back to back byte transmissions entered mid-stream.
I suspect that there will be a lot of uarts out there that will have issues with back to back streams at high bit rates that can be compensated for by supporting 1/1.5/2/3 for serout.
Today I'll mount one of my Logic Sniffers on my P2 test rig, using one earlier would have saved me a lot of time on this issue.
This morning I went into the assembler code and saw that I had already made provisions for resolving # and @ addresses properly for branches. So, my previous advice about needing to do '>>2' after the #address was wrong. I hadn't been in there for a while and I had forgotten this was already solved. At least, it seems to me to be solved. I will run this problematic code presented and try to find the other problem.
This morning I went into the assembler code and saw that I had already made provisions for resolving # and @ addresses properly for branches. So, my previous advice about needing to do '>>2' after the #address was wrong. I hadn't been in there for a while and I had forgotten this was already solved. At least, it seems to me to be solved. I will run this problematic code presented and try to find the other problem.
I suspect that there will be a lot of uarts out there that will have issues with back to back streams at high bit rates that can be compensated for by supporting 1/1.5/2/3 for serout.
Did you test streams of varying sized blocks, at 3MBd on the FTDI ? ( or 2MBd on the Silabs CP210x if you have them )
From how the device behaves in loop-back tests, it may be that more than 3 stop bits are needed to keep up with the data pump.
If the SerDes has granular control over Data length in a 32 bit field, then any stop bits from 1..23 can be managed in SW on Send.
(Certainly 9 bit modes and parity options need to be supported in there somehow.)
Did you test streams of varying sized blocks, at 3MBd on the FTDI ? ( or 2MBd on the Silabs CP210x if you have them )
From how the device behaves in loop-back tests, it may be that more than 3 stop bits are needed to keep up with the data pump.
If the SerDes has granular control over Data length in a 32 bit field, then any stop bits from 1..23 can be managed in SW on Send.
(Certainly 9 bit modes and parity options need to be supported in there somehow.)
or users can use a timer-pacing method.
I have found the FTDI chip on the PropPlug to be good for 1M baud. When you do an F11 download, it is going 1M baud. I tried 2M baud, but it would blow up after something like six bytes. Stop bits could help, but I figured it was conservative to just run at some speed that doesn't have any caveats.
From experience years ago, the UART problems seem to me to be caused by starting mid-stream. ie I mean that you are outputting data when the FTDI chip is powered up.
This is easily solved (and is not a UART problem, nor a P2 problem, its a timing problem) by setting the TX pin 1=stop (normal ttl value) and then enabling the output pin, and now waiting 1 character time (10 bits). This should ensure the UART will correctly sense the start bit. You are now ready to go, and the UART should sync correctly to the start bit every time. If not, then the speed is likely too high.
IIRC we found that FDX on the P1 was returning after only 1/2 stop bit had been transmitted and this caused a problem if the sw was too quick to send another character. I think this was resolved with a later rev ???
Adding stop bits (1/2 +) while seeming to resolve the problem, is not necessarily a cure. I do recall that some older UARTs used to be set to send 2 stop bits to help slower machines. Depending on the character combination, these will resolve sooner, but may not prevent incorrect characters being received, and these incorrect characters can cause all sorts of erroneous results at the other end.
So, its better to delay sending until you are sure the other end is connected. I always allow a delay to get PST (or whatever) connected and running. You could even wait for a character from the other end, although this may be impractical in some cases.
Lastly, as I mentioned when the SERx was added, I thought that sw could easily add the start and stop bits to the character and use the UART to send that char. That is why I asked for a mode to not include start/stop bits. Normally 10 bits would be sent, but since you now have a UART capable of sending up to 32 bits, you could send any combination. The only issue would be to change the UART Tx so that it knows how many bits need to be sent before setting the clear/sent flag. This way, the UART could also be used to send SYNC data, variable length characters, and even 3 characters including respective start and stop bits in one go (30 bits, or 28 + auto start and stop at each end, with sw providing the two intermediate pairs).
BTW I would rather get SERDES working, and then see what if anything, can be combined with the current SERx.
I have found the FTDI chip on the PropPlug to be good for 1M baud. When you do an F11 download, it is going 1M baud. I tried 2M baud, but it would blow up after something like six bytes. Stop bits could help, but I figured it was conservative to just run at some speed that doesn't have any caveats.
I'd agree for downloads 1M is fine, and usually I'd expect one-way From-PC streaming to be somewhat self-pacing.
but there are likely to be some P2 applications where users may want to push data flows as far as they can, without going to the FT232H series.
SiLabs have a new CP2130 (sub $2) which is SPI, which they spec as between 2.6 and 5.8Mbps sustained averages on 64KB Blocks & 12MHz SPI clocks, so that would use the SPI mode coming in SerDes.
I suspect that there will be a lot of uarts out there that will have issues with back to back streams at high bit rates that can be compensated for by supporting 1/1.5/2/3 for serout.
Here are some loopback streaming tests, 100000 blocks, with a Frequency counter and Char counter Terminal.
( This terminal has been crafted to have low overhead, and quiet modes, so the PC SW side does not set the ceiling.)
Propeller Project Board Tests FT231X (20p) Loopback
FT231X File of [U......U] Shift-Ctr-V. Right-click Paste.
Block Size Baud Set TxSend RxBack FreqAv FreqAv
100000 3Mbd n,8,1 100000 99128!* 1.49989M Qm Overrun errors 1.49985MHz Overrun errors
100000 2.4MBd n,8,1 100000 100000 1.00001M Qm 1000.018MHz Solid << 2MBd alias
100000 2Mbd n,8,1 100000 100000 1.00001M Qm 1000.018MHz Solid
100000 1.5Mbd n,8,1 100000 100000 750k quiet mode, less in hex 750.007KHz Solid
100000 1Mbd n,8,1 100000 100000 380~500KHz variable(hex) 500.0062KHz Solid
100000 500kbd n,8,1 100000 100000 243.KHz sometimes 250KHz (hex) 250.0045KHz Solid
100000 3Mbd n,8,2 100000 99577!* fewer Overrun errors 1.49985MHz Overrun errors
100000 3Mbd m,8,2 100000 99949!* Better Rx Yield, still < 100%
* in 3MBd case, external edge TX count is correct, so it is RX side which is dropping chars
It seems the FT231X can sustain 2MBd duplex, (with good PC sw) and at 3MBd can send to that with no added stop bits, but it stutters a little on 3MBd Duplex, on the Receive side.
expanding to 2 Stop bits, and mark parity both help, but are not quite enough to make duplex without over run.
(SW works to well above this on a FT232H, but that uses different frame speed and drivers)
I think FTDI have somewhat mangled their Baud formula in my data sheet, tests show more correct is
FT231X Virtual Baud Clock of 24MHz, with legal divisors of 8,12,16,17,18,19,20,21...
ie above 16, single digit steps are supported, below 16 it is 8,12
Comments
I'll admit, it never occurred to me that you might be plugging into a live data stream !!
Even fractional stop bits will only help a little, in that some lottery will occur as to how many chars it takes to 'lock'.
The reason why 1.5 and more bit periods for the stop bit work is that the uart will get a framing error on the first or second byte it finds, but the extra spacing will help it find a "proper" start bit.
Not having an easily discernible stop/start bit transition is what stopped the FTDI's uart from locking onto the data stream.
Granted, starting up a USB/serial link in the middle of a full-blast 1 stop bit back-to-back character stream is definitely a torture test...
But surely this is a very rare usage ? - anyone who really expects a system to swallow "no-gaps-at-al" data arriving with any phase from cold-boot, can just use an extra stop bit ?
More relevant testing, would be to push UP the baud settings, and see where the FTDI has streaming issues (not sync issues)
I have tested FTDI & SiLabs parts on Loop-back, and find above ~ 500k baud, they start to add stop bits themselves.
(ie they cannot pump the data around, as fast as it arrives)
No data is lost, but the sustained byte data rate is lower than Baud/10.
The FT232H series, can stream well over 1MBd with no gaps.
I did one streaming test with 921k data, and that seemed to be ok, I did not test above that.
Silabs claims ~2MBd and FTDI ~3MBd so it would be worthwhile seeing what size packets they can tolerate, and if any extra stop bits are needed approaching those upper limits.
I think both parts have virtual Baud cocks of 24MHz, so valid bauds are 3M, 2.66M, 2.4M, 2.18M, 2M, 1,84M etc
eg 3MBd with 3 or 4 stop bits, may still be faster than 1.5MBd with 1 stop bit.
I'd guess they should accept data up to the FIFO size ok, but above that the time to empty & process may push down the sustained speed a little.
This can still be data content dependent. One stop bit, with some 0FFH data should be ok.
That's what was thinking. Sending $FF results in ..10111111111.. which should cause any receiver to re-register the next start bit properly.
Yes, resyncing a diffirent frame timing needs a full frame of stops. After that, single stop bits in contiguous frames will work.
But be sure to precede the WAIT with a PASSTXA instruction, so that when you start the WAIT, the serial output will have already completed.
I tried it, sending a $FF (before Hello World), and the FTDI chip re-syncs then even with one stop bit quite nicely
Ray & evanh
My experiments show that using 1.5 stop bits allows re-syncing on every byte
Hypothesis:
FTDI samples every quarted bit period (or less), so the extra half stop bit gives a large enough gap to "notice" the stop bit / start bit even on back to back byte transmissions entered mid-stream.
I suspect that there will be a lot of uarts out there that will have issues with back to back streams at high bit rates that can be compensated for by supporting 1/1.5/2/3 for serout.
Today I'll mount one of my Logic Sniffers on my P2 test rig, using one earlier would have saved me a lot of time on this issue.
I have not needed >>2 in any code, as a matter of fact, the code would not work when I added >>2 :-)
I did not even need it when I did something like: (unless my memory is wrong)
mov reg,##hublabel
which I think SHOULD require >>2, as most of the time I'd use ## (AUGS/D) would be if I wanted a byte pointer ro a 32 bit constant.
Did you test streams of varying sized blocks, at 3MBd on the FTDI ? ( or 2MBd on the Silabs CP210x if you have them )
From how the device behaves in loop-back tests, it may be that more than 3 stop bits are needed to keep up with the data pump.
If the SerDes has granular control over Data length in a 32 bit field, then any stop bits from 1..23 can be managed in SW on Send.
(Certainly 9 bit modes and parity options need to be supported in there somehow.)
or users can use a timer-pacing method.
I have found the FTDI chip on the PropPlug to be good for 1M baud. When you do an F11 download, it is going 1M baud. I tried 2M baud, but it would blow up after something like six bytes. Stop bits could help, but I figured it was conservative to just run at some speed that doesn't have any caveats.
This is easily solved (and is not a UART problem, nor a P2 problem, its a timing problem) by setting the TX pin 1=stop (normal ttl value) and then enabling the output pin, and now waiting 1 character time (10 bits). This should ensure the UART will correctly sense the start bit. You are now ready to go, and the UART should sync correctly to the start bit every time. If not, then the speed is likely too high.
IIRC we found that FDX on the P1 was returning after only 1/2 stop bit had been transmitted and this caused a problem if the sw was too quick to send another character. I think this was resolved with a later rev ???
Adding stop bits (1/2 +) while seeming to resolve the problem, is not necessarily a cure. I do recall that some older UARTs used to be set to send 2 stop bits to help slower machines. Depending on the character combination, these will resolve sooner, but may not prevent incorrect characters being received, and these incorrect characters can cause all sorts of erroneous results at the other end.
So, its better to delay sending until you are sure the other end is connected. I always allow a delay to get PST (or whatever) connected and running. You could even wait for a character from the other end, although this may be impractical in some cases.
Lastly, as I mentioned when the SERx was added, I thought that sw could easily add the start and stop bits to the character and use the UART to send that char. That is why I asked for a mode to not include start/stop bits. Normally 10 bits would be sent, but since you now have a UART capable of sending up to 32 bits, you could send any combination. The only issue would be to change the UART Tx so that it knows how many bits need to be sent before setting the clear/sent flag. This way, the UART could also be used to send SYNC data, variable length characters, and even 3 characters including respective start and stop bits in one go (30 bits, or 28 + auto start and stop at each end, with sw providing the two intermediate pairs).
BTW I would rather get SERDES working, and then see what if anything, can be combined with the current SERx.
I'd agree for downloads 1M is fine, and usually I'd expect one-way From-PC streaming to be somewhat self-pacing.
but there are likely to be some P2 applications where users may want to push data flows as far as they can, without going to the FT232H series.
SiLabs have a new CP2130 (sub $2) which is SPI, which they spec as between 2.6 and 5.8Mbps sustained averages on 64KB Blocks & 12MHz SPI clocks, so that would use the SPI mode coming in SerDes.
Here are some loopback streaming tests, 100000 blocks, with a Frequency counter and Char counter Terminal.
( This terminal has been crafted to have low overhead, and quiet modes, so the PC SW side does not set the ceiling.)
It seems the FT231X can sustain 2MBd duplex, (with good PC sw) and at 3MBd can send to that with no added stop bits, but it stutters a little on 3MBd Duplex, on the Receive side.
expanding to 2 Stop bits, and mark parity both help, but are not quite enough to make duplex without over run.
(SW works to well above this on a FT232H, but that uses different frame speed and drivers)
I think FTDI have somewhat mangled their Baud formula in my data sheet, tests show more correct is
FT231X Virtual Baud Clock of 24MHz, with legal divisors of 8,12,16,17,18,19,20,21...
ie above 16, single digit steps are supported, below 16 it is 8,12
Thought I would post in case others get caught.
'''' cognew $52C, rx_pin << 10 + tx_pin << 2 'this is incorrect cogrun monitor_pgm,#0 'relaunch cog0 with shutdown or monitor monitor_pgm long rx_pin<<24+tx_pin<<16+($1B0+$37C)>>2 'monitor parameter (conveys pins)