New Graduate Looking for work -DETAILS INSIDE (LONG read during lunch break)
- From: "Isaac B." <x86asm@xxxxxxxxx>
- Date: Mon, 29 Jun 2009 14:10:13 -0700 (PDT)
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!
.
- Prev by Date: Re: Looking for help! Accessing SD card using SPI mode
- Next by Date: Looking for simple board to run linux
- Previous by thread: Re: Guarantee Critical Regions in Portable code. Portable Semaphores?
- Next by thread: Looking for simple board to run linux
- Index(es):
Relevant Pages
|
