Last week, I was only able to verify that the CRC16 feature in the SD card is working. The data will only be written into the SD card when the CRC16 given is correct. If the CRC16 isn’t correct, the SD card will not contain the data in the respective sector and a CRC error will be returned from the SD card and the writing process cannot be continued. The CRC is hardcoded within the code to send the same CRC for every single sector and every upload because my objective is just to verify that the CRC feature is working.
Now, it is time to change the code and instead of writing 512 bytes of data from the uploaded data and write two hardcoded CRC bytes, the program will now write 514 bytes from the uploaded data assuming that the data uploaded will have the correct CRC16 after every 512 bytes of actual data. It is soon realized that this program cannot be tested because that the CRC bytes might not be in ASCII characters and the Base64 decoding needs to be implemented as well.
Continuing from where I left off last week on working on implementing the Base64 decoding, I replaced the function “AestePIC18_Optimized_SPI_Write_Packet” because I am trying write 3 bytes by 3 bytes into the SD card instead and that function would be unfavorable to do this. In short, the program will now take 4 bytes from the TCP socket, decode it and write 3 bytes into the SD card.
It is soon to realize that there more changes needed to be made. There are two separated counters in the program, ioInfo.wNumBytes and blockCounter. The first one counts the remaining bytes of data still in the TCP socket and the latter one counters the remaining bytes in the SD card before a block boundary is reached. Originally, the ioInfo.wNumBytes will be subtracted from the blockCounter because the number of bytes received will be the same with the number of bytes to be written in the SD card. But, after the Base64 decoding, 4 bytes of data received from TCP socket will only result in 3 bytes of data written into the SD card. Two different decreament process is used to track the exact bytes of these counters are used to solve this problem.
There is also a possibility that the number of bytes left in the sector is smaller than decoded data (3 bytes). A counter is used to track how many bytes had not been written and will be used as a condition to start the next loop of receiving data, decoding and writing after the process to initialize the next sector for writing. It is a similar implementation to the one that is used to solve the problem when the data in the TCP socket is larger than the remaining bytes left in the blockCounter in the previous version of this code.
After fixing various other minor bugs, the program can upload multiple sectors of Base64-encoded CRC-included data. A dummy file with the size of 320 KB (this is the file size of the Base64-encoded data with CRC, not the size of the actual bitstream for FPGA programming, which will be smaller) with the same repeating sector data is created, using this site to decode/encode between ASCII, hex and Base64 and this site to calculate the CRC16. The time for uploading this 320 KB file is 37 seconds. This is a lot slower compared to the one without Base64 decoding implemented and needs to be optimized.
My next task would be study and learn about bootloader which will be used to toggle between the Master and Slave mode of the PIC18, and to put both of the programs together. The other objective is to make sure that both of the modes will be using the PIC18 RAM fully and not sharing it with one another.
0 Comments