What benefit does this add over the normal serial transport, based on System.IO.Ports.SerialPort?
In its current implementation, there seem to be several missed opportunities:
--Latency timer not set. FT_SetLatencyTimer is never called, so the chip's 16 ms default (or whatever a site tech left it at) still governs delivery. This is the main reason to use D2XX for MS/TP and the class only reads the value.
--No device-identity opening. FT_OpenEx by serial number or description would survive COM re-enumeration. Instead FindAndOpenByComNumber matches on COM number, so the device still has to be VCP-exposed and saved config still breaks when Windows reassigns the port.
--USB transfer size left at default. FT_SetUSBParameters could shrink the 4096-byte in-transfer size to cut latency further.
--No purge on open. FT_Purge would discard stale RX bytes sitting in the chip, avoiding the first frame or two being lost to RemoveGarbage.
--No device-removal notification. D2XX offers FT_SetEventNotification / FT_GetStatus for clean detection of unplug, rather than surfacing it as a generic -1 from Read.
--BytesToRead is dead weight. Implemented via FT_GetQueueStatus, but the MS/TP transport never calls it. It also throws out of a property getter, unlike Read, which catches.
--No RS-485 direction control. FT_SetBitMode / CBUS TXDEN configuration isn't touched, so transmit-enable timing is left entirely to the adapter hardware.
It appears the only benefit to your implementation is avoiding a dependency on System.IO.Ports.SerialPort. I'm not sure that's enough of a benefit to add into Yabe's code base?
By the way this was straight from an analysis, assisted by Claude Opus 5.
Cheers
Lance
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
FTDI is not the only IC to access an RS485 line. Silicom Lab CP210X and certainly a lot of others can be used. So such a code cannot be used in a generic Yabe implementation.
But maybe it can be given for example in a specific directory such as /CodeExamples/BasicReadWriteFTDI_MSTP ?
Bye.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
in testing has less dropped frames....
needs fdti usb dongle. ftdi latency 1 ms.
Last edit: Christopher Günther 4 days ago
Hi Christopher,
What benefit does this add over the normal serial transport, based on
System.IO.Ports.SerialPort?In its current implementation, there seem to be several missed opportunities:
--Latency timer not set.
FT_SetLatencyTimeris never called, so the chip's 16 ms default (or whatever a site tech left it at) still governs delivery. This is the main reason to use D2XX for MS/TP and the class only reads the value.--No device-identity opening.
FT_OpenExby serial number or description would survive COM re-enumeration. InsteadFindAndOpenByComNumbermatches on COM number, so the device still has to be VCP-exposed and saved config still breaks when Windows reassigns the port.--USB transfer size left at default.
FT_SetUSBParameterscould shrink the 4096-byte in-transfer size to cut latency further.--No purge on open.
FT_Purgewould discard stale RX bytes sitting in the chip, avoiding the first frame or two being lost toRemoveGarbage.--No device-removal notification. D2XX offers
FT_SetEventNotification/FT_GetStatusfor clean detection of unplug, rather than surfacing it as a generic -1 from Read.--
BytesToReadis dead weight. Implemented viaFT_GetQueueStatus, but the MS/TP transport never calls it. It also throws out of a property getter, unlike Read, which catches.--No RS-485 direction control.
FT_SetBitMode/ CBUS TXDEN configuration isn't touched, so transmit-enable timing is left entirely to the adapter hardware.It appears the only benefit to your implementation is avoiding a dependency on
System.IO.Ports.SerialPort. I'm not sure that's enough of a benefit to add into Yabe's code base?By the way this was straight from an analysis, assisted by Claude Opus 5.
Cheers
Lance
Hi,
FTDI is not the only IC to access an RS485 line. Silicom Lab CP210X and certainly a lot of others can be used. So such a code cannot be used in a generic Yabe implementation.
But maybe it can be given for example in a specific directory such as /CodeExamples/BasicReadWriteFTDI_MSTP ?
Bye.