mborgerson
Well-known member
I've tuned up my TA4.1 code and my PC image host program to speed up transfer of images from the PSRam image buffer to the PC. In fact, it seems to be working impossibly well! I'm getting a transfer rate of about 23MB/second. That seems impossibly fast when the PSRAM SCK is 88MHz. That clock would seem to limit the SPI transfer to about 11MB/second.
Here's the code for the T4.1 part of the transfer:
and here's the PC receiver routine:
The receive stalls occur when the PC requests an 8KB block but there are no bytes available in the PC receive queue.
How is the T4.1 able to send data from PSRAM at 23MB/Second? One possibility is that the USB transfers are really just a chain of DMA requests, which get queued up in the USB driver, and the actual transmission continues well after the end of the packet transfer function. I'll check that possibility by doing some timing checks on the PC end.
Here's the code for the T4.1 part of the transfer:
Code:
void SendPacket(uint8_t *bptr, uint32_t imagesize){
uint16_t num2send;
uint32_t bytesleft, uptotal;
cameraPause();
uptotal = 0;
do {
bytesleft = imagesize - uptotal;
if (bytesleft > 8192) {
num2send = 8192;
} else {
num2send = bytesleft;
}
uptotal += num2send;
Serial.write(bptr, num2send);
IMARKHI // for scope probing on pin 32
delayMicroseconds(50);
bptr += num2send;
IMARKLO
} while (uptotal < imagesize); // end of do loop
}
and here's the PC receiver routine:
Code:
readptr = (unsigned char *)&cambuff;
pktrcvd = 0;
errcount = 0;
pktdone = false;
do {
numread = ReadCommData(readptr, 8192);
pktrcvd += numread;
readptr += numread;
if(numread == 0){
errcount++; // keep track of RCV stalls
DelayUsec(200); // wait a while for more input
if(errcount > 2000) pktrcvd = pktsize;
}
if(pktrcvd >= pktsize)pktdone = true;
} while (!pktdone);
The receive stalls occur when the PC requests an 8KB block but there are no bytes available in the PC receive queue.
How is the T4.1 able to send data from PSRAM at 23MB/Second? One possibility is that the USB transfers are really just a chain of DMA requests, which get queued up in the USB driver, and the actual transmission continues well after the end of the packet transfer function. I'll check that possibility by doing some timing checks on the PC end.