6-2-09

Last Thursday was spent debugging (trying to fix) the I2C interface for the uorc. Unfortunately an issue prevented me from receiving a proper response from the sensor. I spent the entire day working on this. I used the oscilloscope to view the transmission as a digital signal. I was able to directly view the transmit and receive and see what the issue may be. The sensor would always respond with random values, which appeared as a series of 8 random voltage states of either 0V or 5V.


Sunday I met with Akash as he showed me the LED beacons and what they were supposed to do. The LED beacons that he provided information for is intended to output a pulse on the LED which give a camera the beacon's ID number. This ID number allows the camera to locate and track each robot, along with providing other robots with an idea of which robot it is looking at. I took the string of 1s and 0s that make up the pulse and output it at a frequency of 10Hz. Chris, another member of April, is currently working on implenting support for these beacons on a PC.


Yesterday, Monday, I finally discovered the issue that was preventing I2C from working. In a microcontroller everything is defined by register values. Registers simply hold a binary number and define the behavior of a microcontroller. In this case, I was giving a value to one register before another in the wrong order, which caused the first register to reset. This caused the frequency of the I2C interface to rise substantially higher, which meant the sensor I was communicating with did not have enough time to respond. By simply switching the order in which I was modifying the registers, everything started to work perfectly. I also began to work on the LED beacons. I programmed one of the beacons with a small program I made and gave it to him to work on. Unfortunately the other LED beacons were not accepting any programming requests from the programmer.


Today the first thing I did was finish up the I2C interface and started to work on the LED beacons. After talking with Akash, the person who designed/made the boards, I discovered that the voltage I was programming at was too high. I set the voltage just slightly high enough to overcome the voltage drop of the resistor and LED which caused the programmer to think a short was occuring. By lowering the voltage from 5.1V to 3.7V, the beacons began working perfectly. I spent the rest of the day building 7 beacons. Thankfully my technician background and work experience last summer afforded me an easy time soldering the SMD components.

5-27-09

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.