Embedded Systems Design III is the culmination of my first four years as a Computer Engineering Technology student. Normally, this class would be taken in the Spring quarter of a student's final year at RIT, but as an MS/BS student, I opted to take it early in order to focus on my MS for my last year. The picture above is the result of spending too much time in lab =).

As the main senior design class in my undergraduate program, a lot is expected of the students. The class is a group project based course, where there is little direction from the professor, other than on a one-on-one basis. Four or five students are charged with the task of taking a first-rev board that consists of an Intel 486 processor, a Xilinx Sparten 2 FPGA, an asynchronous UART, a couple FIFOs and bus transceivers and getting it into some sort of functional state.

The board is connected to a host PC via an RS232 serial connection through the asynchronous UART. A terminal program such as HyperTerminal is then used to communicate with the board. The menu at left is what greets the user on our system after a Power On Self Test (POST) is performed to check the first 1 Mb of memory.

The system that is designed for this class usually consists of a main bus controller (for doing memory decode), a UART controller (to offer a synchronous interface to this asynchronous part), an SDRAM controller, a DMA Controller (DMAC), and a whole ton of C code that is either run from a Flash device that has been double-mapped at the top of memory, and within the first 1 Mb, or is copied down into SDRAM to execute from there. The board we work with has 32 Mb of SDRAM, but since the board starts up acting like an 8086, we only have access to the first 1 Mb of the memory space. Protected mode has been a holy grail of ESD3 groups for many years, especially since the compiler (Paradigm) that we use in the labs does not generate 32-bit code. Therefore, in order to get into protected mode, a different compiler platform (i.e. GNU GCC) must be used.

The DMA Transfer Menu shown at right is used to perform fly-by transfers using the DMAC that was coded in VHDL and sits in the FPGA. As can be seen by examining this menu, many different transfer sizes can be selected. Not shown is the capability to select different patterns to transfer, including transferring the data that is already in SDRAM. This DMA transfer copies the data to on-board FIFOs, which can later be read from the command line.

I worked on several parts of the system, but my main task was to focus on the RF transmitter and receiver that are on this board. This was an interesting task because no other group in the history of the course had gotten these devices working.

Just getting the board to send and receive data is interesting, but its better if there is an interesting application of that capability. I decided to create a chat program as that application. At left can be seen the main interface. Using terminal escape characters, text that you type ends up in the "Local" box, and text the other user types ends up in the "Remote" box.

There were several interesting challenges that had to be overcome to get this system working. The professor that put these boards together used the reference diagram from the data sheets for the part when the board schematic was drawn up. Unfortunately, there were some fairly severe problems with the reference design in that version of the documentation. Since this is a first rev board, I had become accustomed to finding problems, and performing board rework, but this took some extra investigation

The first problem that was discovered is that there were some resistors missing in the antennae tuning circuitry. This is not hard to fix, as they just had to be added in the appropriate place. The main difficulty was that the circuit was set to tune both transmitter and receiver to 315 MHz. At this frequency, a quarter wave receive antennae needs to be 8 inches long. The trace on the board that acted as the antennae was only 1 inch long. To fix this, an 8 inch long copper wire was taken straight off the board vertically. This was good, but it introduced another problem. The transmit and receive antennas in a system like this need to be in same plane. Since the receive antenna was now coming out of the board vertically, it was perpendicular to the transmit antennae that was still embedded in a trace on the board. To fix this, a transmit antennae shaped as closely like the originally loop antennae was created and brought out of the board surface. This was finally sufficient to get two boards relatively close to each other to see the same signal on their receive antennas when one board was transmitting.

Shown at right is a typical transmission in a communications system at the electrical level. Manchester encoding was used as a data format, since it has been shown to be successful. To create these waveforms, both the encoding and decoding had to be written in VHDL and implemented in the FPGA, since the RF transmitter and receiver did nothing but transmit and receive - no data encoding or decoding was provided. In order to synchronize the clocks on both the transmit and receive side, a known preamble with a start sequence is required. I used a transmission of four 1's, followed by an invalid sequence to indicate the start of data. To indicate the end of data, the opposite invalid sequence was used. In this manner, I was able to allow long or short transmissions, depending on the application. In addition to encoding and decoding the data, I had to use channel sensing in order to detect and avoid collisions.

A lot of code from my monitor program from ESD's I and II were ported to this project, as my code was deemed the most complete and adaptable to this project. This helped get the system up and running much more quickly. Shown at left is the first page of the help file for the commands available in command line mode. The second half is shown on the right.

As mentioned above, getting the 486 processor into protected mode is a goal that some of the most ambitious teams undertake. This was first accomplished by a team a few quarters before us, and we were able to use their notes in getting up the GNU tools to compile code for this platform. We still had to use the Linux knowledge and experience of some of our members just to get 16-bit code compiling and working on the board.

The I/O routines had to be re-written from scratch as inline assembly, as these had been provided to us before by the Paradigm compiler. Another nice feature of that compiler that we no longer had available is adding "interrupt" to the return type of a function to tell the compiler that returning from that function should generate an IRET instruction instead of the usual RET. To get around this, assembly wrapper functions were created to push the entire environment to the stack before the interrupt function gets called, make sure it gets restored from the stack, and the proper IRET instruction gets called.

After getting this new environment working, we had to try to get the processor into protected mode. While I was focusing on wireless functionality, Gordon was focused on the DMAC, and John and Dan worked on bursting from SDRAM, and other minor feature. Seck took this time to research protected mode. The interrupt table changes completely, and there are a whole new array of faults that start happening once you get a system into protected mode. We got very used to seeing the bus cycle on the logic analyzer that indicated a General Protection Fault =).

The screen shot at left shows a 32-bit data dump from the Flash chip, starting at the beginning of our C code. This is proof that protected mode was achieved, as 32-bit operations are only available when the system is operating in protected mode.

At the end of the quarter the sign off date was rapidly approaching, and our group still had fantastic features to polish off (such as the wireless chat mode and protected mode), so our lab time increased dramatically. By this point in the quarter, I was already spending from 9am to midnight on most days in lab. Our sign off date was scheduled to be first thing on Saturday morning, so Seck, Gordon and I pulled and all-nighter Thursday night to get some extra stuff done. Then Friday came around, and the first all-nighter was a success, so I decided to pull a second one. I'm not sure if anybody else made it, but I hit a new personal record of being up for 50 hours straight. Things started to get a little fuzzy, and things like the chair race at right started happening. It was a great time =).

All in all, it was a great quarter where many things were accomplished. My design and debugging experience has increased dramatically thanks to the tools available in our labs, and this Embedded Systems Design sequence. The picture above shows our team at the end of the quarter. The rest of the pictures from lab are also available.