5
« Last post by CharlesV on March 31, 2021, 09:40:29 am »
Hello Jan and Forum members,
I emailed Jan a few days ago, and she suggested I post my request on the forum for everyone's benefit.
Although I have been writing code solutions on a number of platforms for a long time, and have purchased 2 of Jan's books, I have not been able to afforded myself the time to really get to grips with USB. Recently I wrote 2 multi-threaded applications using C++ and Qt, one for sending data at 115200 baud, across an RF link, and one for receiving and processing this data. The RF transceivers I use are very high spec and expensive devices, and I do not for a moment doubt their ability. I have tested these using minimal code on STM32 platforms, and their data transfers are perfect.
The communication code on both the desktop applications execute in their own high priority threads, and these work very well for the most part. Although when my applications are connected using RS232 ports on a PC which has native RS232 ports, they operate very well, the issue is the loss of data packets and partial data packets when my applications are connected to the RF transceivers using devices such as the FTDI CHIPI-X. I get similar loss behavior irrespective of which USB to Serial converter I use, and have thus concluded that I have an issue with the non-deterministic behavior of the USB subsystem on the Windows platforms. I host the desktop applications on Windows 10.
Not knowing much about this topic other than what I have read in all the FTDI documents towards using their API and optimization of USB transfers as per their app notes, puts me at a disadvantage, and hence my post. Please see the attached file which presents some test data.
When this data is copied into an editor such as Notepad++ or similar, data patterns can be noticed. The left 3 digits and 3 spaces are not part of the data, I have added this for convenience. Some information about the test record.
55 7F 48 00 00 00 00 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 00 55 00 55 00 55 3A 80 AA
It consists of 72 x 8-bit numbers, given as spaced text for convenience. The 55 and 7F make up a pre-amble and start-of-record combination. Then 48 hex, which is 72 in decimal, being the length of the record. The next 4 hex numbers represent a record sequence number. These are useful when determining the size if record loss. The 80 and AA at the end of the record represent end of record and post-amble. Having a look at the data in a wide-screen editor clearly shows the losses.
I know that the underlying USB unit of transfer is 64 bytes, the first two of which are USB-controlled bytes. I have attempted to break my test data up into 62 byte blocks, and have also tried setting the USB receive buffer size to various multiples of 64, from 64 to 4096. In my reception application, I have optimized my code until I realized that the losses do not relate to how well I optimize the reception code. I also find that I notice the same data loss occurs while using either of the serial drivers, i.e. FTDI or Windows Serial Port. This is how I reached the conclusion that the losses were being caused by something that, at present, I have no control over. I am using USB2.0.
Given what I have presented, any wisdoms which may be on offer by members who are much more familiar with USB issues such as this, towards resolution of this issue, will be greatly appreciated.
Thank you.
Recent Posts