mborgerson
Well-known member
I am working on a driver for the FLIR Lepton camera. As part of the testing, I send frames of 38400 bytes to a PC host for display. The driver is running on a custom T3.2 connected to the Lepton. It receives Lepton data over SPI using DMA, and transmits to the PC using the T3.2 USB Serial port. When sending to the PC, the T3.2 reports that the transmission of the frame takes about 49mSec. That's about 764KB/second--which is pretty good considering it is a full-speed link moving data at 12Mbits/second.
I am now trying to make a more portable system where the Lepton/T3.2 will send to a T4.1 for analysis and recording on SD card. (A thermal-imaging trail cam of sorts). The first major issue I have found is that the same firmware on the T3.2 that can send a frame in 49mSec takes about 330mSec when sending to a T4.1 running USBHost_t36. The transmission rate is more than 6 times slower! It seems that the transmitting T3.2 is spending a lot of time waiting for the T4.1 to suck up the incoming bytes. It seems that there must be a bottleneck in the CDC/ACM driver that keeps it from receiving at the maximum potential speed of the T3.2 transmission.
One potential clue is that when the T3.1 is reading data, it reports that usbserial1 has 128 bytes available (two times the 64-byte USB packet size).
Another possible problem is that I have the T3.2 set up for dual-serial output. Serial is used for command and status comms. USBSerial1 is used only for the transmission of binary data frames.
If anyone has some insight into the reason for the slow read speed of the T4.1 I'd appreciate your input. My experiments with the T4.1 as a receiver of USBTMC (Test and Measurement Class) data show that the T4.1 can reliably read more than 9MB/second (3+ MB/Second from three devices with 3 High Speed links), so I don't think the slow read performance with USB Serial full-speed links is an intrinsic hardware problem
I am now trying to make a more portable system where the Lepton/T3.2 will send to a T4.1 for analysis and recording on SD card. (A thermal-imaging trail cam of sorts). The first major issue I have found is that the same firmware on the T3.2 that can send a frame in 49mSec takes about 330mSec when sending to a T4.1 running USBHost_t36. The transmission rate is more than 6 times slower! It seems that the transmitting T3.2 is spending a lot of time waiting for the T4.1 to suck up the incoming bytes. It seems that there must be a bottleneck in the CDC/ACM driver that keeps it from receiving at the maximum potential speed of the T3.2 transmission.
C++:
uint8_t framebuffer[38400];
uint16_t Checkuserial1(void) {
uint16_t rd, n;
uint32_t numread;
uint8_t *buffptr;
numread = 0;
buffptr = framebuffer;
do {
rd = userial1.available();
if (rd > 0) {
LEDON
// put data from userial1 into frame buffer--checking for overflow
if((numread + rd) > sizeof(framebuffer)) buffptr = framebuffer;
n = userial1.readBytes(buffptr, rd);
buffptr+= n;
numread+= n;
// delayMicroseconds(1400);
}
} while (rd > 0);
// if(numread)Serial.printf("Read %lu bytes from userial1\n",numread);
LEDOFF
return numread;
}
One potential clue is that when the T3.1 is reading data, it reports that usbserial1 has 128 bytes available (two times the 64-byte USB packet size).
Another possible problem is that I have the T3.2 set up for dual-serial output. Serial is used for command and status comms. USBSerial1 is used only for the transmission of binary data frames.
If anyone has some insight into the reason for the slow read speed of the T4.1 I'd appreciate your input. My experiments with the T4.1 as a receiver of USBTMC (Test and Measurement Class) data show that the T4.1 can reliably read more than 9MB/second (3+ MB/Second from three devices with 3 High Speed links), so I don't think the slow read performance with USB Serial full-speed links is an intrinsic hardware problem