FT232RL D2XXX drivers & atmega16

Go To Last Post
20 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear freaks,
I am freaking :lol: !
Although I searched a lot in the forum and I Googled
I cannot find an appropriate answer for my case.
I will explain you my application
and I hope someone can help me.

I use an atmega16, a DAC (12-bit) and an ADC (16-bit) that communicate with SPI.
I use FT232RL with D2XXX drivers, in order to communicate with the atmega16. For that purpose
atmega16 has enabled USART @ 250kbps (0% error @16MHz)

The PC side software (Delphi) tells the atmega16 to output a voltage and to start reading through the ADC.
The atmega16 outputs the voltage and then
enters a loop that continuously reads ADC and sends data over RS232 to the FT232RL.
The PC software reads the buffers and outputs the data to a Memo and then to a Chart.

The problem I am facing is that data does not come
as it should.
For example the uC sends repeatedly "345/n" (let's say ADC reads the same voltage) and the PC uses "/n" as a delimiter.
Instead of getting lots of "345/n" somewhere in the middle of data received, I get
"3345" or
"3
45/n"

What I guess, it is either a problem of speed,
or USB polling architecture, or buffering, or UART-USART compatibility, or missing flow control.
Please, if you have any clue, please give me a hint or any help.
Thank you a priori.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think you should slow the baud rate down to say 9600 baud and MAKE SURE THINGS WORK AT THAT RATE. If it does work, crank up the baud rate until it falls overagain & determine the weakest link in the chain.

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for your quick answer,
but I have already tried that with no improvement.
Is it a common practice for the uC to send data
over to rs232 and to expect that the ft232rl will receive all data?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Forget about the voltages, set it up so the Mega16 just echoes characters straight back to the PC.

Use a simple terminal program to send keyboard characters - if these come back garbled you probably have a software or timing issue (what is your clock source?)

Joey

Cheers,

Joey

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use a 16 MHz external crystal
A UBRR value of 3 gives a baudrate of 250000bps with 0.0% error!
I will try what you said but instead I will send a
file...and I'll tell you

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I have already tried that with no improvement.

Have you done basic loop back test at 250000 BPS?
Quote:
Is it a common practice for the uC to send data over to rs232 and to expect that the ft232rl will receive all data?

Absolutely...but at 250,000 baud you are giving everything thing a hard time
Quote:
A UBRR value of 3 gives a baudrate of 250000bps with 0.0% error!

And it probably does, but you would want to prove it first, by doing a loop back test.

At 250000, there are probably lots of other things to go wrong. If you don't know what they are, than the project is probably beyond your capability at this time.
Reduce the amount of unknowns and then do some testing.. testing.. testing.. testing..

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Think about the numbers:

250000 baud and 16MHz means that you ONLY have 16x4 = 64 clocks per bit. For a 10 bit byte, (start, 8 data, no parity, 1 stop), you have 640 clock cycles per character. For a 16 bit measurement framed by '/n', you have 3x640 = 1920 clocks per measurement. If you send as numeric ASCII (as opposed to ASCIIfied hex), then it will take 5 or more characters, and will be appropriately longer.

Do you reliably get data from your ADC once every 1920 CPU clocks? Do you service your DAC reliably in that time? Can you reliably write to the USART transmit buffer in that time? Can your code do all of that, reliably, in that time? (Do not forget to include your serial data transport time with your peripherals).

With care and appropriate hardware, you can probably do it. Have you taken appropriate care?

Also, there is a current thread about USB throughput that is appropriate. I think it is labeled "LUFA". It is worth reading because it does apply to this application. It is here:

https://www.avrfreaks.net/index.p...

Note Dean's comments at the end.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
For a 16 bit measurement framed by '/n', you have 3x640 = 1920 clocks per measurement. If you send as numeric ASCII (as opposed to ASCIIfied hex), then it will take 5 or more characters, and will be appropriately longer.

the 16-bit value from ADC is transformed to string and then it is send via rs232, so I guess it is
5 characters for ADC value and '/n'
total 6. So it is 6x640. Correct?

By the way, SPI, USART are interrupt driven

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
USART are interrupt driven

Then there is the latency getting to and from your ISR to consider..

So, why did it not work when you slowed things down? It suggests that you have additional underlying problems.

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I really appreciate your directions...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here are some results of tests I've made.
I made a new circuit using STK500, atmega16, 8.000MHz crystal and FT232RL.

I used a USB to Serial Converter with my laptop, on which I tested loopback at various speeds with 100% success! I used Termite 2.8 for terminal
So I connected it on Spare rs232 of STK500

1st Test
Basic loopback for atmega16.
100% success at 9600, 19200 & 38400 bps where datasheet says 0.2% error of baudrate.
0% success at everything else, even at 25000bps that has 0.0% error (UBRR = 9)!
Why? I don't understand at all why!

2nd Test
Basic loopback for ft232rl
100% success up to 89500 bps. My ft232rl board uses H11L1 optocouplers on RX & TX pins for isolation, perhaps, this is an issue for further investigation!

Tommorow I plan on testing the same things but using a real RS232 port on my desktop pc and not my converter.

I will inform you...
Any ideas until now?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I use a 16 MHz external crystal
A UBRR value of 3 gives a baudrate of 250000bps with 0.0% error!

Perhaps that means there is 0% calculation error :wink:
After that there are a few other hurdles to overcome!

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
So I connected it on Spare rs232 of STK500

The ft232r is specified to work up to 3 Mega baud. max232 isn't specified for more than 120kbaud. Do you run your mega16 at 40MHz and expect it to work flawlessly?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Whilst the ft232 can do 250kbit/s, it may not be able to sustain that data rate due to the various operations that go on behind the scenes. The ft232 has control signals to tell you to stop sending if things get backed up. Next thing to look at is your code. There could be atomicity problems, buffer overrun etc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The ft232r is specified to work up to 3 Mega baud. max232 isn't specified for more than 120kbaud. Do you run your mega16 at 40MHz and expect it to work flawlessly?

First of all STK500 has a MAX202 with the same specs as you imply, but this "40 MHz", I do not understand, could you please explain ?

@ KartMan
I tested it with the atmega16 only doing

Transmit(Receive())

With these conditions what is the maximum baudrate you have achieved?

I have seen on the forum that guys have achieved 921600 bps with the ft232rl, what kind of uC are they communicating with? :?:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just meant that that if you try to push 250kbaud through a 120kbaud device would be like over clocking a MCU. It may not work.

But I now see you actually wrote 25kbaud in that post. (Wouldn't that be UBRR=19 instead of 9, for F_CPU=8MHz?)

Btw, here's three bytes sent from an Arduino to my PC, and it seems to work fine. I happend to have a UNO so it's via a mega8U2 rather than a ft232.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are correct about the UBRR but it still sends back pure crap!
I guess the atmega16, based on the datasheet, can communicate at up to 1Mbps,
ok the max202 can withstand up to 120kbps, but why the atmega16 cannot pass the loopback test @25kbps?
Does it support only standard baudrates?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By loopback test, do you mean you send a character from your computer to the microcontroller and send back the same character to your computer? If so, are you sure the computer actually use 25kbps? (Is it even possible with standard hardware/drivers?)

I did a test.
- A mega640p@8MHz, UBRR=19 for 25kbps. Echo back received char.
- Tera term, type in 25000 in the baudrate box, no complain, it even say 25000 in the title bar.

It does not work.

If I send a 'U' from PC and echo back a 'U', regardless of what was received, and watch the signals with an oscilloscope I see that tera term is lying about the baud rate, it's using 28800.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear friends,
thank you for your help.
Here is what I found.
snigelen has a point.
The problem is the baudrate setting.
I have made a ft232rl breakout board myself, and after a loopback test (using D2XXX drivers) I saw that for some reasons, that I still investigate, my breakout board can achieve up to 89500 bps without errors.
On the other side, as snigelen said, the uC is capable of different baudrates, but I guess max202 (spare rs232 on STK500) is not capable of speaking at non standard baudrates!
I say this because if I use the terminal program with my USB to Serial converter (prolific) and I connect pins 2 & 3 of the RS232 cable everything works perfectly at any baudrate!

Right now communication is set at 83333 bps and I have zero errors on receiving and transmitting from and to uC!
Thank you for your directions and help.
I plan on ordering a more professional breakout board of ft232rl in order to try achieving greater baudrates!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear friends,
I have achieved 1Mbps with no errors at all, and no handshaking.
Although there has been a while, 1 year of inactivity, I managed to find that the problem I was facing had 2 faces.
The first thing I did was a code optimization. When the FT232RL receives data from uC and send it to PC driver,there had to be a connection of the string from the two different transactions.
That's because the string is incomplete for ex.
first "2134;2155;21"
second "46;2162;2139;2"
So a temporary buffer stores what is last but not delimited with a ";" and connects it to the next string. So I removed one headache...
The second thing I did had to do with the optocouplers I used.
After viewing the oscilloscope screen of both input an output of the H11L1s I noticed there was not a square (pulse) output but it was rather like a gaussian curve (at larger than 89500 bps speeds).
And I replaced them with 6N137s. After I made the proper PCB and soldered them, also making the right connections... Voila 1Mbps was achieved without error.
No illegal characters and everything is perfect. Thank you for your help. I can upload schematic and pcb in eagle format if anyone wants.