The week was spent trying to look for ways to optimize the file upload time to suit the required objective having made some strides on that path during the previous week. Apart from that, a few modifications were made to the MBR editing function.
MBR Partition informations
It is important to notice that before the SD card is used with the board, it may have already been formatted for use. This means that the SD card may have partitioning informations stored onto the MBR which needs to be preserved when it is used on the board. For the purpose of the “AESTE” footprint and the information regarding the read/write addresses, the space for the informations regarding Partition 2 and Partition 3 are being used. Under the current functions, the MBR is cleaned out with “NULL” characters before the new information is calculated and rewritten onto the MBR. So if the card does have information on Partition 1, it will be erased when the MBR is edited. The information of Partition 0 is calculated and rewritten onto the MBR.
So modifications were made to carry over the information when the MBR is rewritten. The information on the MBR regarding partitions are the Number of Sectors in the partition, the First Sector address for the partition, the File System Description as well as Boot Description for the partition. So before the MBR is erased in preparation of being re-written, these information for Partition 1 are held temporarily and rewritten when the MBR is written with the information for Partition 0 as well as the “AESTE” footprint and the Read/Write addresses.
There is one cause for concern with this approach though. As the CRC is activated for the SD card, writing data to the MBR will also require 2 bytes of CRC-16 for the 512 bytes being written to the MBR. Currently, the CRC for this write process is fed into manually, but if the user’s MBR contains different information, the MBR will not be written into as the CRC value would be wrong. A solution to this must be found.
Modifying the Base64 Decoder
Following the results of the previous week, it is clear that the Base64 decoder is a bottleneck for the file upload process. The network transfer the data at a rate of 20kB/s, so for now, this speed can’t be improved upon. Even with the optimized Base64 decoder, it takes ~15 seconds to decode all the data and write it to the SD card. Some research was done to try and find a more efficient Base64 decoder.
A different version of a simpler decoder was found which utilized a more elaborate look-up table than the previous implementation. The new implementation makes away with pointer calculations and simply shifts the bits around from the values obtained using the look-up table. The new implementation was tested with only the upload and Base64 decode operation (without writing to SD card). The following were the results of the new implementation compared to the previous function used as seen in last week.
Old Decoder —–> 32.084s
New Decoder —–> 30.28s
As can be seen from the times obtained, the new decoded does improve the writing by ~1.8 seconds. The drawback for implementation however is that the lookup table takes up more space on the Flash memory of the PIC then the previous implementation. The search for a better decoder is still in progress.
Study on the TCP/IP stack
Some research was done on how the TCP/IP stack works with the PIC to understand how the network protocol works during the File Upload. The network transfer for the whole bitstream still takes about 23 seconds which is far too slow for the required objective. Documentation from Microchip was used to try and understand how the stack works. The references used were AN833 The Microchip TCP/IP Stack(http://ww1.microchip.com/downloads/en/appnotes/00833b.pdf) & Microchip TCP/IP Stack Help (http://www.egr.msu.edu/classes/ece480/capstone/fall11/group03/TCPIP%20Stack%20Help.pdf)
The week was quite slow in terms of progress in the optimization stage of the project. It is hoped that the coming week will show an improvement in terms of results and fruitful progress in the overall project. As for now, the main focus still lies on optimizing the writing stack for the file upload mechanism.
0 Comments