On Monday I started working under Prof. Olson (of APRIL) for my Jack Kent Cooke fellowship. On Monday at 11:30AM I met up with Prof. Olson as he introduced me to the board I'd be working on. The board is called the uorc, and has its own webpage at www.orcboard.org. He showed me a quick demo of the uorc in action, including both programming it and interfacing with it using the ethernet cord. After finishing the demo, he let me work in the lab.
In the lab, I first soldered on a header (a socket for the programming cable). Afterwards, I covered the bottom of both the programming board and the orc board with an insulating tape to protect it from shorting and damaging it. I grabbed one of the available laptops and installed the necessary development files including the source code and toolchain (the programs that make the source code able to be programmed into the orc board). I programmed the orc board and repeated the demo that Prof. Olson showed me earlier.
The rest of the day was spent pouring over the entire source code of the orc board, which consisted of the operating system. I modified the operating system to include a new task that would send a string through the ethernet to the laptop. Typically you do slight modifications to source code to better understand what is going on. Having never worked on either operating system driven embedded electronics or 32 bit processors, this was a completely new experience for me. Thankfully my work with 8 bit microcontrollers were very applicable to many of the basics of 32bit embedded development. By the end of the day I felt that I had a pretty good understanding of what I was working with.
Yesterday, Tuesday, I spent the entire day implementing the I2C peripheral. I2C is a fairly simple peripheral, which works by having the master, in this case the orc board, send an address over the bus (the data lines) and subsequently either request a transmission or receive information. Having worked with the UART peripheral I felt fairly comfortable with this project. I used the skeleton source file provided by Prof. Olson and used the SSI peripheral source code as the basis for what to include in the I2C source. Since I am still unfamiliar with the details of working with an operating system, I really depended on the ISS source code as a reference on how to prepare the operating system for the peripheral. The major issues include interrupt handling and protecting the process from any undesirable interrupts that may occur which would cause a loss of information.
I ended Tuesday with a good basis for the peripheral, but unfortunately while compiling the actual peripheral showed no signs of working on the oscilloscope (instrument used to read voltage and frequency). It was only this morning that I realized that a simple mistake in the source was to blame. I accidently had the write variable length equal to the read variable length, and since the read variable length was set to 0 it automatically bypassed sending any data over the I2C periphearl.
Today, Wednesday, I spent fixing up the code, analyzing the output with the oscilloscope, and finishing the transmit and receive processes. As of now a rough version seems complete but I won't be able to tell until tomorrow if it actually works when Prof. Olson brings in a I2C device to test it with. I recently took pictures of my workspace and a friend and fellow APRIL member who is also working with the firmware that has been helping me recently.
