by support »
Hello,
To begin with, streamwrite.c sends data from standard input to the chosen output file in chunks of 128 bytes each, and not 1 byte at a time. Not top-notch efficiency, but keeps the code simple.
Either way, it copies all data in any case. Why things got messy when the desired data was longer than 1020 bytes I can only guess. Actually, my primary guess is that the logic fetches the data faster than it arrives to the FPGA, and it expects it to arrive continuously. If you're writing to an SDRAM, it's impossible to keep pace with the rate the SDRAM consumes data.
As for "int" vs. "long int": On a 32-bit machine, "int" is a 32-bit signed integer, ranging from -2G to +2G. So changing it to the 64-bit "long int" didn't make any difference, because you weren't remotely near the 2G limit anyhow.
Regards,
Eli
Hello,
To begin with, streamwrite.c sends data from standard input to the chosen output file in chunks of 128 bytes each, and not 1 byte at a time. Not top-notch efficiency, but keeps the code simple.
Either way, it copies all data in any case. Why things got messy when the desired data was longer than 1020 bytes I can only guess. Actually, my primary guess is that the logic fetches the data faster than it arrives to the FPGA, and it expects it to arrive continuously. If you're writing to an SDRAM, it's impossible to keep pace with the rate the SDRAM consumes data.
As for "int" vs. "long int": On a 32-bit machine, "int" is a 32-bit signed integer, ranging from -2G to +2G. So changing it to the 64-bit "long int" didn't make any difference, because you weren't remotely near the 2G limit anyhow.
Regards,
Eli