FTDI serial driver sloppy?

Kye

I just wanted to ask if anyone else who has developed a serial driver has had this problem.

For some odd reason in any terminal program I use on windows using the FTDI virtual serial port I can't transmit back to back serial bytes.

Back to back as in:

SBBBBBBBBSSBBBBBBBBS

Where S is the start·or stop bit and B is·a data bit.

I asking because I have to insert extra stop bits to fix the problem. This is even with the number of stop bits set to 1 in the FTDI·driver.

... The problem just seems odd, and is getting in the way of 100% optimization on my next version of my·serial driver.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Mike Green

I assume you're talking about sending the serial data from the Propeller and receiving it with Windows. In that case, the de-serialization is done in the FTDI chip at the Propeller end, then the information is repackaged into USB packets, sent to the PC, and reformatted into a series of bytes which is presented to the terminal program along with the status of the control lines which accompanied the data in the USB packets. Windows never actually sees the start or stop bits. The information on start and stop bits, Baud, parity, and number of data bits is actually sent from the PC to the FTDI chip where it's used to configure that for the serial mode used.

Could your routine be off somehow, perhaps transmitting one less stop bit than you think?

The receiving mechanism in the FTDI chip doesn't really care how many stop bits it receives as long as it's at least one.

Kye

Mmm, no I'm pretty sure my rountine works as I scoped it putting out the appropriate bits.

I have to actually add in an extra pre startbit stopbit to make sure windos doesn't receive corrupted data.

Best I can get is 11 bits per packet and not 10.

...

But the weird thing is that if I write the rountines in spin it doesn't matter at all and I can leave out the extra wait. Maybe the low speed makes the difference.

Thanks, for replying Mike.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Mike Green

If there's a mismatch in the Baud, the difference between the timing of the data and what the FTDI chip expects will accumulate. By the 10th bit, a 10% error in timing becomes a full bit-time error.

lonesock

Kye said...
Mmm, no I'm pretty sure my rountine works as I scoped it putting out the appropriate bits.

I have to actually add in an extra pre startbit stopbit to make sure windos doesn't receive corrupted data.

Best I can get is 11 bits per packet and not 10.

...

But the weird thing is that if I write the rountines in spin it doesn't matter at all and I can leave out the extra wait. Maybe the low speed makes the difference.

Thanks, for replying Mike.

I had to put a waitcnt for "bit_clocks" after setting the stop-bit value, to make sure my next byte send would not set the start-bit before the stop-bit had been read. This was only an issue when using fairly low baud rates in PASM, as my code would "lap" itself. There were no issues using the 1M-3Mbaud range.

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

Kye

Mmm, I guess 11 bit packets are fine. Full Duplex Serial transmits packets in that way (check how the stop and start bits are added to the packet to see this)

I can get arround ~300000 bps.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

localroger

Kye, I am pretty sure 11 bits per frame is standard for RS232. You have start, 8 data, stop, and then dead time so you can properly detect the following start bit separately from the preceding frame. I've bitbanged several interfaces, both receive and transmit to other standard devices, and that's how I've always seen it done.

You've got to remember in its original incarnation, the reason for the two stop bits setting was to give mechanical parts time to settle after striking a character at 110 baud

Phil Pilgrim (PhiPi)

Kye,

A stop bit doesn't need to be an integral number of bit times. It can be any fractional value > 1. Try using, say, 1.125 stop bits. Your baudrate may just be on the hairy edge of being too fast, so you could also try slowing your Propeller's baudrate by a fraction. For example if it's 9600, try slowing it to 9550.

-Phil

Dr_Acula

It may or may not be related, but I've spent a week trying to debug the zicog/triblade where if you type two characters quickly it misses the second one. Happens over all baud rates, even down to 110. I'm starting to think maybe it is the serial object code but there are still some other possibilities.

My setup uses serial straight into the PC with no USB involved, so that removes one possible source of problems.

PhiPi's suggestion of tweaking the baud rate - yes, great idea, and I'll try that when I get home.

Also, I'm going to try talking to another working CP/M board (rather than to a PC), just in case the PC is taking characters that are typed on a terminal program and bundling them up with no gaps between them.

My problem may or may not be related to this thread. But if the gap between two stop bits were too short it could explain the problems I'm seeing. It probably is time to get out the scope!

Addit: reading the waveforms about half way down this page: www.beyondlogic.org/serial/serial1.htm#40 This is 10 bits (not 11, intriguingly), and there is an interesting comment there about the status immediately after a stop bit - if it is low then this is the start of the next byte. No gap at all. I didn't know that. There is also mention of framing errors - I wonder if one was writing a uart emulation, whether it would be possible to code for all the errors you can get - eg parity error, framing error. I'm thinking back to my first computer in the early 80s where you had serial to parallel converters built with discrete chips and leds that lit for various errors like this. It did make debugging easier.

Kye - I'll be following this thread with great interest.

Post Edited (Dr_Acula (James Moxham)) : 8/12/2009 1:15:10 AM GMT

Kye

Well, I was just complaining on this post and trying to see if anyone else had this problem.

This thread should die.

But, have fun using my next serial driver release - this will be the final version (if it doesn't have problems)·and it pretty much is perfect.



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Dr_Acula

Re This thread should die.

No, no no!! [noparse]:)[/noparse] This thread should live on in perpetuity. Because, at the bottom of your last post is some lovely shiny new uart code that I just can't wait to get home and try! Thanks++

Addit - all working, this object is brilliant and has enabled the zicog/triblade to not only get wordstar working but also games and even xmodem file transfers. Worthy of a seperate Post of Thanks!

Post Edited (Dr_Acula) : 8/12/2009 9:35:57 AM GMT