I inherited some code that includes what is essentially a customized version of the UsbSerial 4.x codebase for an FTDI chip. I'm trying to move it to use a standardized version of the library. However, it relies on a very strange mechanism for setting the baud rate, which is equivalent to calling setOldBaudRate() on FTDISerialDevice. Essentially, to set the baud rate correctly, I have to call:
setControlCommand(FTDI_SIO_SET_BAUD_RATE, 0x000c, 0);
I think that this baud rate is 250000, but I'm not certain (but it should be near that). Using 6.0.6 I can just run that command in place of calling setBaudRate() and everything works. In 6.1.0, I need to call setBaudRate(250000) first, and then issue this command (I think this is to set clock timings correctly or something).
In any case, if I set the baud rate in the "normal" way with setBaudRate(250000) it mostly works, but fails at critical times (the data transfer is long and complicated, and I have not teased out exactly where the problem lies). But if I call setBaudRate(250000) and follow it up with setControlCommand(FTDI_SIO_SET_BAUD_RATE, 0x000c, 0), then, as far as I can tell, it is working correctly.
In any case, is this a standard feature worth adding to the library, or is my case special enough that I should just use reflection to call setControlCommand after setting the baud rate?
The specific chip I am using is VendorId 1027 / ProductId 24597, which googling tells me is a "FT230X".
I just looked at the data sheet, and it seems that the baud rate is set to 3000000 / VALUE. Since the value is 0x000c (12), that does yield 250000.
So, I guess, is it possible to route setting the baud rate through this mechanism in the public API? Is it worth adding?
I'm not entirely sure why the new method isn't working and the old one is, but that is what is happening with this chip.
I inherited some code that includes what is essentially a customized version of the UsbSerial 4.x codebase for an FTDI chip. I'm trying to move it to use a standardized version of the library. However, it relies on a very strange mechanism for setting the baud rate, which is equivalent to calling setOldBaudRate() on FTDISerialDevice. Essentially, to set the baud rate correctly, I have to call:
setControlCommand(FTDI_SIO_SET_BAUD_RATE, 0x000c, 0);
I think that this baud rate is 250000, but I'm not certain (but it should be near that). Using 6.0.6 I can just run that command in place of calling setBaudRate() and everything works. In 6.1.0, I need to call setBaudRate(250000) first, and then issue this command (I think this is to set clock timings correctly or something).
In any case, if I set the baud rate in the "normal" way with setBaudRate(250000) it mostly works, but fails at critical times (the data transfer is long and complicated, and I have not teased out exactly where the problem lies). But if I call setBaudRate(250000) and follow it up with setControlCommand(FTDI_SIO_SET_BAUD_RATE, 0x000c, 0), then, as far as I can tell, it is working correctly.
In any case, is this a standard feature worth adding to the library, or is my case special enough that I should just use reflection to call setControlCommand after setting the baud rate?
The specific chip I am using is VendorId 1027 / ProductId 24597, which googling tells me is a "FT230X".
I just looked at the data sheet, and it seems that the baud rate is set to 3000000 / VALUE. Since the value is 0x000c (12), that does yield 250000.
So, I guess, is it possible to route setting the baud rate through this mechanism in the public API? Is it worth adding?
I'm not entirely sure why the new method isn't working and the old one is, but that is what is happening with this chip.