Hello all,
I am not sure if you remember me, but I did use to post here a couple of years ago and was quite active. But since then, my life needed some extra attention so I kind of stayed away from it.
I am currently looking for work right now and one of my areas of interest as a potential career would be as an embedded systems engineer. I would be very interested in an entry level position in the Greater Toronto Area. Though relocation generally will not be a problem for me.
My thesis project was in fact an embedded system. Allow me to go into detail:
We were tasked with the development of a payload camera subsystem for a cube satellite subsystem. This work was not under the Electrical Engineering faculty but under the Aerospace Engineering faculty.
The base function/responsibility of this system was to take pictures and store them in non-volatile storage on demand from a host (whether that be a main microprocessor on the overall satellite bus or over some form of wireless communications). In addition, there were also commands to read the temperature sensor, erase pictures, format the storage, etc..
In order to do this we would need the following components:
-A microcontroller on the board
-A wireless communications method (this was because the main satellite bus specs were not finalized)
-Some non-volatile memory
-A temperature sensor (they want this on all boards in the satellite to detect temperature gradients)
We had multiple choices for the microcontroller, such as ARM7 based MCU's (NXP LPC, AT91 SAM, etc.) and the AVR but we ultimately went with Microchip's PIC24. The reason being that it was compatible with the development tools that were present in the Aerospace faculty lab and it has a ready use IDE with a C compiler. Since I have had previous development experience with the MPLAB IDE (using PIC16F's) from my personal projects it was a no brainer.
Here are some other reasons why we chose this particular MCU:
-16-bit core (headroom)
-2 I2C, 2 SPI, 2 UART in the PIC24FJ64GA004, all independent
-Reasonable power consumption (~80 - 100mW @ 32MHz or 16 MIPs)
For the wireless communication, we used the radio units in the Aerospace lab. These units have a 9600 bps baud rate.
For non-volatile memory storage, we had originally chosen the AT25F641 I believe. This is a 64Mbit flash memory module. It communicates using the SPI memory bus. We used 2 of these sharing a similar set of SPI lines. Each individual memory chip was addressed by using their chip select pins. So in total 16MB of storage
For the temperature sensor, the TC1047A from Microchip was selected. It gives a voltage that is proportional to the ambient temperature (with a bias to allow for -ve centigrade temperatures). We just connected its output to an A/D convertor input on the PIC24F to obtain sampling from the sensor and converting the sample reading (10-bits) to an actual centigrade reading.
For the camera, the C328R from Co-media was selected. This module is very popular in the Aerospace engineering arena because of its relatively low power, simple UART interface and onboard JPEG compression ASIC. (We were not completely pleased with the image quality). We had power gating on this thing, because it drew close to
60mA @ 3.3V . This was accomplished by putting a PFET in between the 3.3V rail and the power input of the camera.We had to keep the power consumption of the device under 330mW.
FIRMWARE
I was responsible for architecting the firmware, we split the development work evenly amongst us. In essence, what I tried to achieve here was a software architecture that would keep the MCU in a sleep state as much as possible. The software was written in C and divided into the following components:
Camera Interface:
This code was responsible for interfacing with the Camera UART. UART receive interrupts were used to acquire data bytes from the camera.
In addition to this, initialization, power gating control and picture acquisition code is also included in this module. This module interfaced quite extensively with the file system to store image data obtained from the camera.
(~1000 lines C)
Radio Interface:
This code was simply responsible for interfacing with the UART that the radio was connected on (the radio is fully transparent). It also controlled the RESET line of the radio during power on. This module was used to receive/transmit data through the radio (offering a centralized way to do it throughout the code base).
This code also hooked the interrupt service routine for this particular UART to intercept bytes and determine whether a full command has been received. If one has it will add it to the message queue (along with parameters that accompany the command).
(~200 lines C)
File System/Flash Interface:
This module was responsible for managing the data on the flash memory. In addition it was also responsible for interfacing with the flash memories on the SPI bus (sending commands, reading return values, polling their status registers).
The file system works with the concept of a slot. Essentially, a slot is a storage "hole" for an image. A slot represents the following information with an image:
-Base Pointer in memory
-Size in bytes
-Time stamp (in ms since system boot-up)
The file system offered methods to write data to, read data from and delete slots. In addition, it can also format the filesystem.
(~1300 lines C)
Temperature Sensor:
This module simply sets up the A/D convertor for use and then on a subroutine invocation performs a A/D sample and then uses the sample value to return a signed integer that would be a centigrade reading of the ambient temperature.
(~50 lines C) Timer/Periodic Wakeup:
This module managed both the periodic wake-up interrupt and the time stamp interrupt (100ms resolution). The timestamp is a 32-bit unsigned integer.
Now that I think about it, it may have been redundant to have 2 interrupts.
(~ 50 lines C)
LED Indicator Interface:
The LED indicator module provided a way to toggle the LED's on the design to indicate activity of the various components. This was EXTREMELY useful to us in the debug stages.
(~ 70 lines C)
Message Queue:
This module manages the message queue and provided subroutines to access the queue (Add, Remove, Empty, IsEmpty, etc.)
(~200 lines C)
Debug:
This is a simple module that has subroutines that takes a string and dumps it to the radio UART (to be displayed on the HyperTerminal or RealTerm). This module was also VERY useful in debugging, so we could see the internal variables as the MCU was running through some code. In addition, simply setting a switch in the header file, would disable this.
(~ 30 lines C)
Now with all this in mind, this self-contained system would be somewhat useless on its own. You would need some way to view the pictures on the flash memory and send commands to the system to get it to perform a function. So it was necessary to make a GUI on a Windows computer.
Visual Basic was chosen for this. We had a full GUI working that could send commands and display JPEG data from the camera on the screen.
A Printed Circuit Board was also designed. I was responsible for the lay out of this one. I had used the ExpressPCB software. I know its not the most professional software suite (OrCAD? Eagle?), but it works and they do make damn good PCBs!
PROBLEMS/ISSUES AROSE:
Now I would be lying to you if I told you everything worked perfectly without a hitch. There were a number of problems that had arisen.
One of the first problems we arrived at was the camera. We were unable to take pictures consistently. Sometimes the camera would take pictures, sometime it would not respond correctly to the commands. After some investigative work and consulting another engineer working on the camera, it was found that after initialization (we would do it once on power-up), the camera would enter a power-down state and would need to be re-initialized. Once we modified the firmware to do this, it took pictures consistently!
No mention of this was made in the camera modules datasheet.
The next set of problems came about when we got back the PCB and soldered the components and tried to do bring-up on the PCB. The first problem that was realized was that all the data sent through the radio was corrupted. So we double checked the routing on the PCB to make sure it was correct and it was. Then we tried to disable components selectively to see what the problem was. Once we disabled the flash memory. The radio was working perfectly!
Well what exactly could the problem have been? Looking at this, I immediately thought SPI clock frequency. We had it at 8MHz, so I changed the initialization routine to clock it at 1MHz and lo and behold, it worked. So I chalked this up to poor isolation of the clock signal on the printed circuit board design (my bad, I did route the signals by hand though, so I have some excuse).
NEXT STEPS:
Currently, I go into the Aerospace lab and help with the continuation of the project. I recently helped the person continuing the project to implement some form of error checking on the JPEG data coming in from the system to the PC.
It uses a XOR checksum for the bytes and divides the data stream into n byte chunks. It works quite well and has improved the reliability of the system.
This is just an explanation of the project that we did. Any questions/ clarifications can be made here and I will try to answer as soon as possible.
Regards!