Testing the FTDI USB Serial

General discussion about anything related to Ultibo.
User avatar
Ultibo
Site Admin
Posts: 2280
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: Testing the FTDI USB Serial

Postby Ultibo » Sat Oct 08, 2016 12:00 am

pjde wrote:I noticed that the get string descriptor functions are yet to be implemented ... Below is my version of this.

Thank you! One of those items that is slowly working its way up the list.
Ultibo.org | Make something amazing
https://ultibo.org
dieselnutjob
Posts: 18
Joined: Wed Jun 26, 2019 12:48 am

Re: Testing the FTDI USB Serial

Postby dieselnutjob » Wed Jul 17, 2019 11:10 am

I have been trying to use an FTDI USB serial device on a Pi Zero W without success.
I also have a Pi 1 Model B which I am currently using but still without success.
I switched on the console logging but all that appears in the right side of the screen are references to MMC, Storage and SDHCI0.
I have three different devices including a genuine FT232R.

The other thing is that plugging in a USB memory stick produces nothing in the console log either; so maybe the problem is at the USB layer rather than FTDI?

In the left window I get continuous "Serial device is nil"

My complete code is below:-

Code: Select all

program SerialConnection;

{$mode objfpc}{$H+}

uses
  GlobalConfig,   //Add the global config unit
  GlobalConst,
  GlobalTypes,
  Platform,
  Threads,
  Console,
  Framebuffer,
  BCM2835,
  BCM2708,
  SysUtils,
  Logging,      //Add the logging unit
  FTDISerial,
  Serial;   {Include the Serial unit so we can open, read and write to the device}

{We'll need a window handle plus a couple of others.}
var
 Count : LongWord;
 Character : char;
 Characters : string;
 WindowHandle : TWindowHandle;
 SerialDevice : PSerialDevice;


begin
  WindowHandle := ConsoleWindowCreate (ConsoleDeviceGetDefault, CONSOLE_POSITION_LEFT, true);

  //Register console logging
  CONSOLE_REGISTER_LOGGING:=True;
  LoggingConsoleDeviceAdd(ConsoleDeviceGetDefault);
  LoggingDeviceSetDefault(LoggingDeviceFindByType(LOGGING_TYPE_CONSOLE));

  ConsoleWindowWriteLn (WindowHandle, 'Welcome to Example 13 Serial Connection - FTDI v2h');
  ConsoleWindowWriteLn (WindowHandle, 'Serial Responder');

  SerialDevice := SerialDeviceFindByDescription ('FTDI USB to Serial');
  while SerialDevice = nil do
   begin
    ConsoleWindowWriteLn (WindowHandle, 'Serial device is nil');
    Sleep(1000);

    SerialDevice := SerialDeviceFindByDescription ('FTDI USB to Serial');
   end;
  ConsoleWindowWriteLn (WindowHandle, 'Serial device is available');

  if SerialDeviceOpen (SerialDevice, 9600, SERIAL_DATA_8BIT, SERIAL_STOP_1BIT, SERIAL_PARITY_NONE, SERIAL_FLOW_NONE, 0, 0) = ERROR_SUCCESS then
    begin
      {Opened successfully, display a message}
      ConsoleWindowWriteLn (WindowHandle,'Serial device opened, type some text in your terminal program and press Enter');
      {Setup our starting point}
      Count := 0;
      Characters := '';

      { Loop endlessly waiting for data }
      while true do
        begin
          SerialDeviceRead (SerialDevice, @Character, SizeOf (Character), SERIAL_READ_NON_BLOCK, Count);
          if Count > 0 then  // non blocking so count may be 0
            begin
              {Check what character we received}
              if Character = #13 then
                begin
                  {If we received a carriage return then write our characters to the console}
                  ConsoleWindowWriteLn (WindowHandle, 'Received a line: ' + Characters);
                  Characters := 'You said ' + Characters + Chr (13) + Chr (10);
                  SerialDeviceWrite (SerialDevice, PChar (Characters),Length (Characters), SERIAL_WRITE_NONE, Count);
                  Characters:='';
                end
              else
                begin
                  {Add the character to what we have already recevied}
                  Characters := Characters + Character;
                end;
            end;
          sleep (100);
        end;
    end
  else
    begin
      { Must have been an error, print a message on the console }
      ConsoleWindowWriteLn (WindowHandle, 'An error occurred opening the serial device');
    end;

  {Halt the thread if we exit the loop}
  ThreadHalt (0);
end.

dieselnutjob
Posts: 18
Joined: Wed Jun 26, 2019 12:48 am

Re: Testing the FTDI USB Serial

Postby dieselnutjob » Wed Jul 17, 2019 12:59 pm

I found the problem.
I had removed uses RaspberryPi3, because I don't have a Pi3. It seems that to recognise these device uses RaspberryPi, is necessary.

I don't know yet if the FTDI device fully works as I need it to, but it does now open the device so I suspect that it will.
dieselnutjob
Posts: 18
Joined: Wed Jun 26, 2019 12:48 am

Re: Testing the FTDI USB Serial

Postby dieselnutjob » Wed Jul 17, 2019 2:42 pm

Now tested on both a Pi 1 model B and a Pi Zero W.

I have a multithreaded program with one thread talking to the UART on the GPIO header pins and another thread that so far opens the FTDI serial port on an FT232R that's connected with an OTG cable.

Nice.
User avatar
Ultibo
Site Admin
Posts: 2280
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: Testing the FTDI USB Serial

Postby Ultibo » Wed Jul 17, 2019 11:25 pm

dieselnutjob wrote:I found the problem.
I had removed uses RaspberryPi3, because I don't have a Pi3. It seems that to recognise these device uses RaspberryPi, is necessary.

One of the "downsides" to the flexibility of Ultibo is that you have to remember to include all of the components you require ;)

Excellent that you have it working, thanks for the update.
Ultibo.org | Make something amazing
https://ultibo.org
dieselnutjob
Posts: 18
Joined: Wed Jun 26, 2019 12:48 am

Re: Testing the FTDI USB Serial

Postby dieselnutjob » Thu Jul 18, 2019 8:35 pm

I have hit another problem.
When my PC program talks (through the FT232RL) to the processor inside my device the processor responds, but when the Ultibo program sends the same packet sequence through the same FT232RL I don't get a response.
One difference that I can see is that with the PC program talking to the FT232RL that there is 0V on pin 3 of the FT232RL (RTS).
With ultibo there is 5V on pin 3 of the FT232RL.
I think that this is probably why the device isn't responding.
Unfortunately the developer of the firmware running in the processor is ill so I can't ask him but I know that he implemented hardware flow control and so my guess is that with RTS at 5V his firmware won't reply.

I am using this to open the port

Code: Select all

if SerialDeviceOpen (SerialDevice, 115200, SERIAL_DATA_8BIT, SERIAL_STOP_1BIT, SERIAL_PARITY_NONE, SERIAL_FLOW_NONE, 0, 0) = ERROR_SUCCESS then


A second thing which is is a bit of a comment/query.
With Freepascal on Windows (using the ftd2xx.dll driver) or Linux/MacOS (using /dev/ttyUSB or /dev/cu.usbserial0) I can open a serial port with hardware flow control turned off, and then once I have received one valid packet I can on the fly reconfigure the port to turn on flow control.
The reason I did this is that if I try to talk to a device that isn't there (USB plugged on so FT232R present, but no power on the processor of the device) then the thread stalls for a very long time whilst it tries to send a packet. Therefore I send the first packet without flow control and once I have a valid response then I switch on flow control.

With ultibo the flow control seems to be specified in the deviceopen. Is it possible to change flow control on the fly with an already open port?
dieselnutjob
Posts: 18
Joined: Wed Jun 26, 2019 12:48 am

Re: Testing the FTDI USB Serial

Postby dieselnutjob » Thu Jul 18, 2019 9:40 pm

If I query device status using

Code: Select all

alongword:=SerialDeviceStatus(SerialDevice);

I get $0000006 if my device is powered up and $00000004 if it is not.
The difference is because the RI pin (pin 6 of FT232RL) is connected to the processor power supply on my device. On the PC software the state of the RI pin can be queried by doing

Code: Select all

fpioctl(ser, TIOCMGET, @ModemStatus);

This allows us detect that the device isn't powered and send an appropriate user warning.

This doesn't seem to match the values under "Serial Status Flags" in serial.pas
dieselnutjob
Posts: 18
Joined: Wed Jun 26, 2019 12:48 am

Re: Testing the FTDI USB Serial

Postby dieselnutjob » Thu Jul 18, 2019 9:49 pm

in the log window I have idVendor=0403 and idProduct=6001

this doesn't seem to match these lines in ftdiserial.pas

Code: Select all

 {FTDI Vendor and Product ID constants}
 {Devices using FTDI VID}
 FTDI_VID = $0403; {Vendor Id}
 
 {Original FTDI device PIDs}
 FTDI_8U232AM_PID = $6001; {Similar device to SIO above}
 FTDI_8U232AM_ALT_PID = $6006; {FTDI's alternate PID for above}
 FTDI_8U2232C_PID = $6010; {Dual channel device}
 FTDI_4232H_PID = $6011; {Quad channel hi-speed device}
 FTDI_232H_PID  = $6014; {Single channel hi-speed device}
 FTDI_FTX_PID   = $6015; {FT-X series (FT201X, FT230X, FT231X, etc)}
 FTDI_SIO_PID = $8372; {Product Id SIO application of 8U100AX}
 FTDI_232RL_PID  = $FBFA; {Product ID for FT232RL}             


The log does call it an FT232R USB UART.
dieselnutjob
Posts: 18
Joined: Wed Jun 26, 2019 12:48 am

Re: Testing the FTDI USB Serial

Postby dieselnutjob » Thu Jul 18, 2019 11:16 pm

I see that from https://ultibo.org/forum/viewtopic.php?f=13&t=1279&start=20 that there have been some updates since Beetroot which is what I have installed.
It looks like I need to update from github and try again.
dieselnutjob
Posts: 18
Joined: Wed Jun 26, 2019 12:48 am

Re: Testing the FTDI USB Serial

Postby dieselnutjob » Fri Jul 19, 2019 10:12 am

I have updated from GitHub and I am seeing an improvement (though I'm not 100% there).
If my device is powered I receive packets very slowly, one byte at a time, and they don't make too much sense. It's as if the processor is sending packets faster than they can be processed or maybe the FTDI chip is rate limiting what the processor can send to a rate that's unusable.
The moment I unplug the power (to the processor) and so RI changes these seems to suddenly "flush" the data from the FT232R into the ultibo application.
I can see that the packet that appear on the console is the packet that I was looking for all along.

is it possible that 5V on the RI pin of the FT232R is somehow messing up the ability of the FT232R to send packets to ultibo?

has ultibo put the FT232R into a "mode" that means that 5V on the RI pin stops it from sending the data?

My RI pin is attached to 5V processor power through a 10K resistor so later on I will try to short it to GND (it shouldn't do any harm) and see if it suddenly starts working.

Return to “Discussion”

Who is online

Users browsing this forum: No registered users and 3 guests