Deeper into the realm of SD cards
After scratching the surface into the world of SD cards and how they store data, almost all of the week was spent into trying to figure out as much as possible about the abilities of these storage devices. Admittedly, I was led astray by my own curiosity about the File system on the SD card and wasted a lot of time troubleshooting and studying up on something that is not relevant to what we are trying to do. Promptly I was reminded of this, and I was embarrassed and full of disappointment in myself. The supervisor reminded me that we are only interested in the Raw Read and Write capabilities of the SD card and not at all interested in how the file system works. The following is what I picked up about the SD card over the week:
Raw Reading & Writing:
Much work was done by my colleague on raw reading and writing and I had to find out what was done by him to understand what should be done to be able to write raw onto the SD cards we are using. I read up on his blog posts and particularly found the following to be quite enlightening on what was done on the SD card so far:
However, it was still quite hard to understand some of the changes in the code and I found myself referring to alot of different demo codes that have been done so far to get a grasp of it. By the end of the week , I was able to do some small testing to write raw onto the SD card and I was able to read out the sectors on Minicom via the UART (although some bugs still persisted). I’m hoping to build on this and try to find a way to speed up the writing process as much as possible. One particular piece of document I found enlightening while trying to understand how SD cards read/write using the SPI interface was:
Master Boot Record (MBR):
The Master Boot Record (MBR) is the boot sector at Sector 0 of the SD card. It contains information used to boot the card as well as information about the partitions on the card. One of the tasks assigned is to dictate where the raw data is stored on the SD card. After the data is completely written, an error check is used to ensure data is not corrupted. If the data is not corrupted, the MBR is to proceed by moving the data accordingly to boot the firmware. This is a pretty tricky process as the size of the data loaded need to be determined to be able to store it correctly in the allocated place as well as have a method to check whether the data is corrupted.
A bit of Assembly:
I was assigned to study up on Assembly coding on the PIC by the supervisor. I would have to deal with assembly coding later on as the bootloader for the project will need to be written and so I researched a bit on it. I personally had a bit of experience with assembly code at my university dealing with the Assembler for Motorola 68K microprocessor. However, I found subtle differences and with a bit of work, I was able to emulate the GPIO program I had written the previous week. I also tried to develop a USART functionality program similar to the one written in C earlier in the week, but failed ran into some bugs. I couldn’t find time during the week to come back to it and try to fix the errors. Hopefully, I can continue my understanding of PIC assembly coding as I work towards taming the SD cards.
It was a week of disappointment for me. I couldn’t achieve what I had set out to but I am hoping to make up for it in the coming week by implementing some of the things I learned so far.