FT232R - USB to MCU UART Interface

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

Hello, i want to build a usb communication to an AVR(ATmega32) mcu via FT232R.
i have achieved a simple asynchronous communication (at 9600 baud rate) with only Tx and Rx lines. i send data from pc to avr, and it answers me back. also i can give commands from pc to mcu (via uart-ftdi) to do something.
So, the pc is master and AVR slave.
now, i want to set the AVR in master mode and to send data to pc when it wants to do that. The pc to reads when i send new data from avr in ft232 buffer.
it needs to use some of handshake signals? how that works?
How the pc may knows when the ftdi have a new data in its Rx buffer?

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

The program in pc is builded in visual studio (console app).

i found an example in Visual C++ (Console Application)
http://www.ftdichip.com/Support/...
and i use in this, the FTD2XX library.

i use this programer's guide
http://www.ftdichip.com/Support/...

and finally with ft_write and ft_read i send and read bytes from ft232r buffer.
but like i say beffore i want some way to read the ft232r buffer when the avr send NEW data in that.

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

Quote:
i want to set the AVR in master mode and to send data to pc when it wants to do that.

Just have the AVR send the data out the USART to the FTDI chip.

The FTDI chip will send the data to the PC.

It is up to the PC program to watch the serial port and read the incoming data. This is usually interrupt driven on the PC end.

Although one can do software handshaking with the PC, for most applications this isn't necessary.

One often puts the data in a "packet", to make it easier for the PC program to identify the start of a new data packet.

For exampe, send: < DB1 DB2 DB3 DB4 CS
Where "<" is a Start of Packet character to mark the beginning of the new packet.
DBn = Data Byte N
CS = a CheckSum, perhaps the sum of the Data Bytes, 8 bit value, ignoring carryout.

The PC looks for the <, then reads in the data bytes, then validates the data with the CheckSum.

If this isn't critical data one might even skip the CS, as FTDI data transmission to a PC over an approved USB cable is very reliable. One might, however, be tempted to keep the CS in case the PC was busy and the PC missed a byte or two, (again, rare with USB).

JC

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

The AVR will NOT be the mater. But, for a virtual COM port, that is not important.

"Master" refers to the USB relationship. It is just the transport medium for the virtual COM port which has no master. AVR just sends. The PC has to check the status of the virtual UAERT and read characters when they appear, That is all that it takes. Any terminal program does this.

Jim

 

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

 

 

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

Well, every terminal program can do it, but if you want to make some interactions between the PC and the avr, libraries or programs one wrote might be useful and easier :
http://todbot.com/blog/2006/12/0... has a simple c program that can make sequences automatic (I was satisfied with it, with minor changes -allowing it to store received data into a file, and to add the PCs date to lines one receives-; nothing is specific to arduino -which uses or emulates a FTDI chip-, as the PC only "sees" a serial line).
If you feel easier with python, it has been rewritten in Python, too .

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

so, all i can i do in this case its
to setup the pc to read always (for example),
100 times per second to see when the ftdi have
new data??
its the first thing when i thinking but i was hoping
for better way! anyway, if it works perfectly i dont
have problem!

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

The PC will buffer considerable amounts of serial data (and also buffers things at the USB level), so there's no need to poll so often. Most modern PC languages will have some support for serial interfaces, and allow "serial data received" as an "event" as well.

But if the PC is really a "slave", it can just do a blocking read of the serial port, and your program won't even wake up till data arrives. Thanks to the PC having a full multi-tasking OS, this won't prevent other PC tasks from running. (In fact, one "easy" way of handling serial interfaces on PC-class machines is to have separate threads for the "receive" and "transmit" tasks.)