MC9S08 GT60 : SCI BAUD RATE

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MC9S08 GT60 : SCI BAUD RATE

2,291 Views
ehestigoni
Contributor III
Hi Guys,

I've been doing some tests with the baud rate configuration of the SCI using a MC9S08 GT60.
All the setup was made, and I'm now only changing the value of the register SCI1BDH and SCI1BDL...

In the board, I'm using an FTDI chip to do the USB stuff and them send data to the PC...

My application on the PC is a C++ software, and the communication is just fine (using FTDI drivers) when I use baud rates lower than 34800. That means, I send one byte on the board and get it imediately on the C++ app.

However when I use higher Baud rates, what is happening is a sort of "buffering"... I still don't loose any byte, but the C++ app sees something on the queue only after 3968 Bytes. That means that I keep reading queue=0 and then sudenly I get queue=3968!!


Neither the mcu nor the FTDI chip is supposed to limit the baud rate to 34800... And I already tested in 2  PCs,  being one of them a Dell dual core brand new...


Does anybody have a clue of what that could be?

Thanks in advance,

Ed.
Labels (1)
0 Kudos
3 Replies

420 Views
Bloodhound
Contributor I
If you are using FTDI devices here's a trap.
We had all sorts of problems getting stable connections with them on an AVR based project, we asked FTDI support and was told it must be our software etc.
Anyway, I just happened to stumble on a forum post where someone was having the exact same issues as us. Turns out FTDI did release an application note and in it they mention that you need to fit some small ceramic caps on the Tx / Rx pins on the USB side of the device to help with noise immunity (not shown in the data sheet revision we had at the time). Once we did that all USB comms was rock solid (without a software change I might add).
It's a very hard thing to find on the FTDI website though as it's actually some "note" in a non related application doc.
Well, hopefully I might save someone some headaches!
 
Cheers,
Ross
0 Kudos

420 Views
bigmac
Specialist III
Hello Ed,
 
It seems this issue might be one of latency within the FTDI device.  The attached FTDI application note should provide further explanation.
 
Regards,
Mac
 
Message Edited by t.dowe on 2009-10-27 01:36 PM
0 Kudos

420 Views
ehestigoni
Contributor III
Hey BigMac!
 
Just perfect mate! Problem solved.
 
The FTDI chip sends the data to the PC under 2 conditions only:
 
1) If there was a "timeout" of an internal clk and the number of bytes on the queue is lower then 64;
 
or
 
2) When the number of bytes reaches the limit specified by the "USB Block Request".
 
 
This by default is set to 4096 Bytes.
Being known that in every 64 Bytes, 2 of them are USB headers, we have 128 bytes in these 4096 that aren't "real data".. So 4096 - 128 = 3968, exactly what I was reading before.
 
 
Now I've set this size to 256, and the reading is being done in real time:
 
ftStatus = FT_SetUSBParameters (ftHandle, 256, 0);
 
As simple as that.
 
 
Thanks mate,
 
 
 
Cheers,
 
Ed.
0 Kudos