I modified the setup files for SimpleFTPServer to work with QNEthernet, and SdExFat/ExFile. However, when downloading files, I rarely got the whole file unless the file was very small.
My solution was to replace the call to file.write( buf, nb ) in bool FtpServer::doRetrieve() to file.writefully( buf, nb ).
Modified Command
I don't know if this is unique to QNEthernet, but it sure seems like the FTP server should have a more robust routine for ensuring data is sent. I generally prefer keeping libraries unmodified so I don't need keep track of my own mods, but it seems necessary in this case. Perhaps a TFTP server would take care of this issue, but I don't want the speed reduction of constant replies.
On a side note, when programming on platforms that don't have multithreading capability, I like having the option of using non-blocking functions. To that end, I'm going to modify both QNEthernet and SimpleFTPServer to accommodate this. My project requires that CAN data, and other I/O are monitored and updated without interruption.
My solution was to replace the call to file.write( buf, nb ) in bool FtpServer::doRetrieve() to file.writefully( buf, nb ).
Modified Command
I don't know if this is unique to QNEthernet, but it sure seems like the FTP server should have a more robust routine for ensuring data is sent. I generally prefer keeping libraries unmodified so I don't need keep track of my own mods, but it seems necessary in this case. Perhaps a TFTP server would take care of this issue, but I don't want the speed reduction of constant replies.
On a side note, when programming on platforms that don't have multithreading capability, I like having the option of using non-blocking functions. To that end, I'm going to modify both QNEthernet and SimpleFTPServer to accommodate this. My project requires that CAN data, and other I/O are monitored and updated without interruption.