Menu
▾
▴
1 Attachments
#60 FTDI Delays
I have an interestting bug I believe. This is seen on a Windows 7 PC, I don't know if that makes a difference.
If using an FTDI FT232R (official) cable and dumping a text file to it, the transfer is done in 120 Byte chunks at 50 millisecond intervals. It feels like some sort of timeout or timeslice issue. Once you run above about 19200 Baud, the actual transfer takes the same time due to all the delays.
This is checked with an oscilloscope.
However, if something is recieved on the same cable (like an ACK etc) then the delays disappears.
I have tried different FTDI cables, I've tried changing the settings within the FTDI using F-PROG. I've tried XP compaitiblity. And many mnore things....
None of the above happens with the built in COM1 port.
This also doesn't happen if using TeraTerm, Hyperterminal etc on either COM1 or the FTDI cables.
I am guessing it is possibly something in the APRO Sync libraries?
I am aware of the FTDI and the way it works. It doesn't happen with other serial comms which is why I suspected a Realterm issue. I did try the settings in the FTDI driver anyway to see if it influenced anything, it didnt.
I had version 2.0.0.57 first then did actually fetch the latest to make sure if it would help. It hasn't. I'm rnning 2.0.0.70 now.
The time is between 50ms and 52ms, usualy around 51ms. Thats as near as I can get on a 'scope.
For example at 921600 I get 1.3ms of active transfer then a pause of ~49ms. It is always after about 120 bytes.
Interesttingly, your suggestion of using the send numbers is OK. I can send 1000's of characters or strings and all the bytes are sent back-to-back with no pauses or gaps. It seems to be just the "dump file to port" that has the problem.
For your information the file I am sending (and I have tried others) is a regular text file with CR and LF endings. It is stored directly on the root of the local C drive which I would imagine is a SATA hard drive. Attached is an example file that is used when dump sending.
I don't know what you mean by INI file, I run it from a shurtcut with the following parameters:
"C:\Program Files (x86)\BEL\Realterm\realterm.exe" baud=115200 display=0 00 display=0 scanports=0 port=20 HALF
Related
Can you test and confirm the current V3.0.0.26 version (www.i2cchip.com) still does it.
I expect this is a function of the protocol component I use to do file sends.
Same behaviour
Hi,
I haven't been able to check it with a scope but if I set "Char delay" to -8 it certainly goes faster. I sent a large ascii text file and by my calculations it sent it in about the right time for the baud rate with 8N1.
Many thanks, Lyndon
From: Simon Bridger crun@users.sf.net
Sent: 29 June 2017 03:00
To: [realterm:bugs]
Subject: [realterm:bugs] #60 FTDI Delays
Dispatcher rate increased fom 20Hz to 100Hz in 3.0.0.27+
Does this fix your problem, or should rate be higher?
[bugs:#60]https://sourceforge.net/p/realterm/bugs/60/ FTDI Delays
Status: awaiting-testing
Fixed_in_Version: V3.0.0.27
Version: v2.0.0.70
Created: Wed May 20, 2015 11:08 AM UTC by Lyndon Amsdon
Last Updated: Thu May 21, 2015 12:15 PM UTC
Owner: nobody
Attachments:
I have an interestting bug I believe. This is seen on a Windows 7 PC, I don't know if that makes a difference.
If using an FTDI FT232R (official) cable and dumping a text file to it, the transfer is done in 120 Byte chunks at 50 millisecond intervals. It feels like some sort of timeout or timeslice issue. Once you run above about 19200 Baud, the actual transfer takes the same time due to all the delays.
This is checked with an oscilloscope.
However, if something is recieved on the same cable (like an ACK etc) then the delays disappears.
I have tried different FTDI cables, I've tried changing the settings within the FTDI using F-PROG. I've tried XP compaitiblity. And many mnore things....
None of the above happens with the built in COM1 port.
This also doesn't happen if using TeraTerm, Hyperterminal etc on either COM1 or the FTDI cables.
I am guessing it is possibly something in the APRO Sync libraries?
I am aware of the FTDI and the way it works. It doesn't happen with other serial comms which is why I suspected a Realterm issue. I did try the settings in the FTDI driver anyway to see if it influenced anything, it didnt.
I had version 2.0.0.57 first then did actually fetch the latest to make sure if it would help. It hasn't. I'm rnning 2.0.0.70 now.
The time is between 50ms and 52ms, usualy around 51ms. Thats as near as I can get on a 'scope.
For example at 921600 I get 1.3ms of active transfer then a pause of ~49ms. It is always after about 120 bytes.
Interesttingly, your suggestion of using the send numbers is OK. I can send 1000's of characters or strings and all the bytes are sent back-to-back with no pauses or gaps. It seems to be just the "dump file to port" that has the problem.
For your information the file I am sending (and I have tried others) is a regular text file with CR and LF endings. It is stored directly on the root of the local C drive which I would imagine is a SATA hard drive. Attached is an example file that is used when dump sending.
I don't know what you mean by INI file, I run it from a shurtcut with the following parameters:
"C:\Program Files (x86)\BEL\Realterm\realterm.exe" baud=115200 display=0 00 display=0 scanports=0 port=20 HALF
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/realterm/bugs/60/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Bugs: #60
Dispatcher rate increased fom 20Hz to 100Hz in 3.0.0.27+
Does this fix your problem, or should rate be higher?