During the process of trying to write my own MDD stack, I found a comment in the code given by Microchip. It states: //Check if all attempts failed and we timed out. Normally, this won’t happen, //unless maybe the SD card was busy, because it was previously performing a //read or write operation, when it was interrupted by the microcontroller getting //reset or power cycled, without also resetting or power cycling the SD card. //In this case, the SD card Read more…
I2C is the last IO device going into our system, for now. I2C is more complicated than both UART and SPI. It’s complication is due to it’s ability to have many masters and slaves on the same bus. Moreover, having only one bidirectional line(SDA) for data transfer adds to it’s design complexity. The latest specification for I2C from NXP should be your main source for learning about I2C. I2c online guides like this and this can be very helpful. While Read more…
This week had a lot of testing going. First of all UART is 90% done. It has been tested by simulation and on FPGA communicating with the PC through Minicom. I’ve faced a very interesting issue while testing UART on Spartan 6 ATLYS board. My UART can transmit data to the PC but it doesn’t seem to be receiving any data sent by the PC except when I send a Break Signal. I’ve tried slowing down the PCs Baud Rate, Read more…
This is my last week interning at AESTE, what I have done were doing the final checking and making some modifications during the first three days of the week. I had to change the drivers into class templates whereas my colleague, Mostafa tested the ARC4 and ECDSA drivers on the hardware to check if they are working properly. Maybe the programs that I have written are not robust yet, but they are functionally working correctly now. So, at least I Read more…
Running to the bus-stop to try to catch the 9:00am UCSI bust before it runs away, all I could think was “God, I don’t want to be late on the first day!”. But the butterflies in my stomach gave me enough of a kick to get on the bus in time, and although some pretty terrible traffic tried to derail my hopes and dreams of the perfect first day at work, I managed to touch base at the front door Read more…
This is my last week at Aeste. I’m glad that I managed to complete the task assigned to me! Basically, this week is all about wrapping up all my works. I continued working on my sphinx documentation although there were not many things to add because I’ve put everything that I deem useful and essential to the documentation last week. This week I’ve been re-reading my documentation for any potential grammar or technical mistakes. Apart from improving my documentation, I corrected Read more…
In my final week, we wrap up with the PCB design of the product prototype and retrace & document the work completed in my nine weeks at Aeste. For one last time, click here to skip to the conclusion. Routing Completion The design of the circuit board is complete. Last week, it was suggested that it might be necessary to make compromises in the layout, perhaps in routing the RB1, RB2 or Port E pins to the Spartan-6. However, with Read more…
I recheck my functions to make sure that the three functions are doing the same thing as the one function. It turns it should be. Then, after some hacking and testing, I found out that the string I declared in the main function will be written into the SD card. I tried to declare the string declaration static, the string no longer is written in the SD card. I reported this finding to my supervisor, he told me that is Read more…
Here I am, finishing my 12th week at Aeste, doing documentation for my project. There is not much to tell this week because the only thing that I’ve been doing this is just documentation. For the documentation, my supervisor asked me to use Sphinx. Sphinx was initially developed for documenting python project, but then has evolved to support other programming languages as well. If you still can’t imagine what does it do, just imagine it as a wiki page. Every Read more…
This week I managed to finished my raspberry pi’s remoteproc driver. At first I thought my custom gpio bus was flawless, but after linking it with the remoteproc driver, and some harsh testings, it turned out to be buggy. Data sent by the remote processor (another Raspberry pi running a simple processor read write emulation program) are well copied but when I verify the host’s memory, the data are scattered as in they are not being copied continuously. After some Read more…
