And without any further yammering, here is the video:

PIC16C558 magnified 100x

I’ve found this interesting blog by Flylogic Engineering, a company that focuses on hardware security analysis.  In their blog, they examine several popular microcontrollers and other ICs pointing out some interesting details in their design and possible attack vectors.  In their analysis, they take a look at security at the hardware level by extracting the IC die from its package and taking a look at the silicon under a microscope.  They then remove each metalization layer, one at a time, photographing each layer as they make their way down to the lower levels.  I find this fascinating and highly recommend that you take a look.

I thought I’d do a quick post about a project that I found a few days ago, the Toobo embedded linux project.  Vijay is using a TMS-7250 arm based SBC to build an MP3 player using the STA015 mp3 player chip and a graphic LCD display.  I plan on following his progress closely and maybe I’ll build my own Toobo after he’s got something workable.  I’ve also added a link to osembedded.com in my blogroll to the right.

I’ve always been interested in embedded Linux and one of these days I’d love for the chance to sit down and play with it in a bit more detail.  During my internship, I’ve tinkered a bit with porting newer versions of the Linux kernel to a custom Arm SBC and found it to be quite challenging; I was not able to port the latest kernel and ended up going as far as I could by porting the existing kernel patches I had from 2.6.8 to 2.6.12.  After 2.6.12 the differences in organization in the kernel was too much for the same patches to be worked in.

I’m writing this post as a proposal for an umIEEE student workshop project.  The project is my LED Pocketwatch, now renamed to become a Desktop Clock.   This project is meant as a fun excercise that will give participants some surface mount soldering experience and some knowledge on how a PIC operates and the design process used to create your own projects using EagleCAD to create both home-made etched PCBs and professional quality ordered PCBs.

The Image you see above is a 3D rendering of the latest design of the PCB.  The rendering is pretty much true to what I expect to build except for a missing inductor and the wrong capacitor in the PSU, which can be seen along with more details in the photo of the prototype after the jump.

The clock contains three basic subsystems; the power supply, microcontroller and finally the real time clock.  The  power supply draws its current from a single AA battery and uses a boost switching mode power supply to increase the output voltage from the 1.5V provided by the battery to an ample 5V that is used by the microcontroller.  The advantage of this type of power supply is that it can operate at very low voltages, down to near 0.7V which allows you to power the clock from AA batteries that other devices may consider to be already dead.  In order to conserve power, the clock will not always be displaying the time; after about a minute or so of display, the microcontroller will enter sleep mode and deactivate the power supply.  When the user pushes the middle button, it will awaken and display the time for another minute.  As an alternative to the AA battery, you can solder a short USB cable that will allow the display to be powered continuously.

The PIC16F877A microcontroller is the brains behind the clock.  The main responsibility of the PIC is to interface to the real time clock and drive the RGB leds.  The LEDs each have four connections; a common anode and a cathode for red, green, and blue.   The way the LEDs are multiplexed, each LED has its own anode that is connected to an output pin on the PIC.  The cathodes are then all tied together and connected through current limiting resistors to three more output pins.  The PIC controls the display by selecting an LED by pulling its anode high and then sending three pulse width modulated signals to the RGB cathodes.  By carefully choosing the duty cycle of the PWM signals, virtually any colour can be displayed.

The Real Time Clock is the time keeper for the clock.  It has its own independant 32.768kHz crystal that is divided and useed to accurately keep track of time.  It also has its own CR2032 3V lithium backup battery that is used to keep the time while the main power is not available.

With this clock design, each hand of the clock (hours, minutes, and secconds) will be assigned a colour.  The face of the clock will display each hand and as the hands gradually overlap, it will mix the colours to display the time.   The second and minute hands will also adjust their brightness between two LEDs on the clock to proportionately display the time when it is in between positions.

Now that you are a familiarized with the general idea of my project, I’ll get into some details on the propsed soldering workshop.   For the workshop,  participants would be given their very own kit of components, solder, PCB, and battery.  The workshop would start with a presentation where I go over the basic anatomy and design of the clock, and discuss the schematic and PCB.

Next, participants will be guided step-by-step through the procedure required to solder each of the components on the board, using several techniques along the way.   We will have to find enough fine-tipped soldering irons for everybody to use.   As the boards are assembled,  we will test independant subsystems with a multimeter and visual inspection. Experienced solderers will be on hand to assist with people who may have trouble with some of the smaller components.

Half-way through, we will break for pizza or subway lunch and return to the workshop in the afternoon.  Once the boards are assembled, we will begin programming the boards with pre-written source code.  The code will be made available and discussed during the process.  This time will also be used to troubleshoot and repair any boards that are not working.

Once the boards are assembled and working,  the floor will be opened for questions, ideas, and suggestions for future projects or improvements to this one.

As for cost, currently I have priced out the projects to be approximately $35 per unit, but I expect this to go down a bit if/when I find a cheaper source for a couple of the more expensive components.   At this price point, I would suggest that the cost for umIEEE members would be around $20 - $25 and for non-members $30 - $35.  For members, umIEEE would be expected to sponsor the remainder of the costs which would be $10-$15 per person (including the cost of Lunch).  I would expect to host the workshop on two consecutive Saturdays; the first of which will have 10 spots and the second with 15 spots available.

If you have any questions, please email me directly or post your comments to this page.

Ok, first of all, let me make this clear. I am not giving up on the MP3 Player just yet. I’ve decided to work on a simpler project for a while and take a bit of a break from the MP3 player. I’ve had the idea to make this pocketwatch for quite a while, and finally decided to act on it.

Here’s the jist of the project. 12 RGB LEDs in a clock face (originally I wanted 60, but this proved to be technically not feasible) pattern. If you dont know what an RGB LED is, its basically three LEDs in one package that share a common cathode. With this, you can send three PWM signals to each colour and effectively achieve any colour you can come up with (which is practically limited to around 255 colours).

So my plan is basically this, each hand of a clock will be represented by a different colour. As the hands move and overlap, the colours will be added. When a hand is in between numbers, different shades of the colour will be used (for instance, there will be 5 shades that represent the minute hand. At 12:00, the uppermost LED will be lit fully. at 12:01, it will dim a bit and the 1:00 LED will light by the same amount. This progresses until at 12:05 the 12:00 LED is off and the 1:00 LED is on completely).

I have four major goals that I wish to accomplish with this project:

1. First and foremost, I want to use this as a chance to design and implement a PCB. I think this PCB may be significantly simpler than my MP3 player, and is a good learning exercise.
2. Similarily, I will use this as a chance to practice my surface mount soldering. I swear, I’m getting better. =)
3. I want to finally get the damned MAX1675 DC-DC converter working. This thing has been causing me nothing but headaches, and I think I’ve figured out why. The silly inductor that is required to begin the resonation that increases the voltage is hard to come by. I’ve tried (and ordered) several different inductors and coils to test this with, none of which worked. Recently, I saw on a website another person using this device with an inductor that is nothing like the tiny ones I’ve been trying. It was a big obvious looking coil of wire. I’ve ordered some more inductors to play with, and I seriously hope I get this solved soon (for both the pocketwatch and the MP3 player).
4. I will use this as a chance to test out a few little tricks and ideas that I’ve picked up here and there, such as testing in circuit serial programming, the behaviour of ground planes on my PCB (hopefully it behaves nicely), i²c devices (such as the real time clock), etc…

Anyway, thats enough ranting for now. I’ll post more on this later, when I’ve got something cool to show. My first step, is to get a prototype working on a breadboard. I’ve rigged up 9 of the LEDs so far in a grid pattern and hope to get the pic multiplexing different colours to them at a reasonable speed with enough power left to do things like calculate hand positions and read the RTC. Unfortunately the PIC only has 2 PWM channels, which means that I’ll have to come up with my own PWM channels and bit bang them (substantially slower, but it should still be adequate).

School and work have really been consuming most of my life since September, but this past week or so I’ve found some time to pick up where I left off with the MP3 player.

My FAT16 driver is now working a bit better. I fixed a few annoying bugs and have updated my read method so that I can tell when I’m at the end of a file. I’ve been working on a newer version of the read method that is a bit more useful. Previously, in one method it would read the entire file and output the data directly to the LCD, 32 characters at a time (overwriting the previously read data every sector). This is nifty as a proof of concept but not really too useful.

Instead, I’m working on a new version of the read routine that reads a sector of the file, copies it to a user specified buffer, updates some indecies in the file structure, and then returns the total length of the data returned (which is always 512 bytes until the last chunk). So you call the read method multiple times until you’re at the end of the file. This will let me actually *use* the data instead of immediately throwing it away. I decided to use a second buffer (in addition to the physical layer buffer that stores data straight from the SD card) so that I don’t have to worry about overwriting data with future SD read requests. This isn’t so important now when I’m only doing one thing at a time, but in the final version I may want to be able to browse the SD card while playing an MP3 (for instance).

The MP3 decoder has been interfaced for a while, but I’m having a bit of difficulty configuring it. It requires a special sequence of writes to configure the decoder with details on the clock and other undocumented settings (over 2000 such writes). Right now I’m storing the file in the root directory of the SD card and will open the file, read its contents, and transfer it over to the decoder. Eventually I may just store this configuration data in ROM, but for now it’s a good opportunity to test my FAT driver. Once I’ve got the configuration file sent over, I’ll be able to send the RUN command and hopefully the decoder will start asking for data.

I’ve also been playing around with EAGLE a bit, drawing up my schematic and working on a PCB design. It’s really nowhere near ready yet, but I thought I’d mention it. I’ll post some images of the schematic and PCB layout in the next day or so.

As a test, I put a 4mb file on the sd card to try and read, and I can successfully read the entire contents of the file on the two line display, effectively making this the worlds worst eBook reader. =) I’ve also converted the fat16 code to use structs so that I don’t have as messy of an interface between the methods. My next step is to figure out when I’m at the end of a file and stop reading at the appropriate spot. Currently, I stop reading at the end of the last cluster in the file, but most files won’t fill up the entire last cluster.

On another front, I’ve managed to interface the STA013 to the pic. Unfortunately I couldn’t use the PIC’s serial module for both SPI and I2C as I had originally planned, so instead I am using the compiler to do software I2C. It is considerably slower, but still more than adequate for just configuring the decoder.

I’ve sampled (and purchased) a few more goodies for the project. Most importantly, I’ve sampled some new 18LF4585 PIC’s. The major difference with these PIC’s is that they have more RAM (roughly 3.3Kb as apposed to 368 bytes offered by the 16F877A), they run faster 40Mhz after enableing the Phase Lock Loop Multiplier, an internal 8Mhz oscillator (wow, that’s pretty cool), and few power saving features.
PIC18F4585 Datasheet

Next, I’ve sampled new Crystals (not pictured above) from Fox Electronics. Among my new crystals are two 10Mhz, two 20Mhz, and two 14.7456Mhz. The latter will be used for the STA013 MP3 decoder.

Read more for details on the new card slots, reading the new memory card, and my plans for tomorrow….

The nice SD Card slots above were sampled from the good people at Molex. These are much nicer than the ones that I paid for earlier, and I have more of them. They are very tricky to use in a prototype without soldering them onto a PCB, but it can be done by very finely soldering a 9 pin header to the leads (be very careful not to melt the plastic.. I ruined my first card slot that way). When you’re done soldering, wrap the whole mess in some black electrical tape to keep it sturdy. Finally, be very careful not to bend it any way that could result in breaking the connection.

At the bottom of the picture you will also see my new 2Gb SD card and USB card reader (no more reading/writing to my SD cards through the battery chewing monster that is my digital camera).

As for an update, I’ve finally managed to get my PIC16LF877’s to work at a lower voltage. The trick was to disable brown out detection. Now I’m able to run the PIC at 3.3Volts (or lower) so that I can avoid the unsavoury business of level conversion. Luckily the LCD is quite happy to pick up 3.3V signals. A quick rewire of the power circuitry on my wirewrap board and it was happily humming away.

On another note, I’ve bumped the frequency up to 20Mhz with the new crystals I’ve sampled (they are much nicer small package crystals that will look good on the finished project). At this new frequency, my peak transfer rate should be around 610Kb/s.

I tried my new SD card right away in my apparatus, only to find that it wouldn’t properly read. Instead of recieving 0×01 to CMD0, the SD card seemed to be sending 0×80. After a while of pulling my hair out I realized that 0×80 is just 0×01 shifted left one (note that the bus idle is high, so it would capture one more high on the far left and one less high on the far right bit cells). A quick change to make the PIC read on the falling edge instead of the rising edge of the clock, and the problem was fixed. Theres a bit of other strange behaviour with the new card. For some reason it only sends data on a read command when the block length is set to 512. This would be a bit annoying if I were still using the 16F877, but since I’m switching, it shouldn’t be a problem for long.

Tomorrow I will be switching to the new PIC and putting the finishing touches on my FAT driver. If time permits, I may also begin to wire up the MP3 decoder, which will be my next step.

Drag the circle around to see the other side of the board. Click outside of the circle to “flip” the board.
Progress has been booming the past couple of days (or weeks for that matter). I’ve finally gotten around to taking a couple more pictures of my new wirewrap version of the board (pictured above). As can be seen in the photo I’ve got my FAT driver to work for the most part. What you see is the LCD displaying the contents of the root directory on the SD card. When you click one of the two buttons, it displays the next entry in the directory, and the other button, “opens” the selected item (currently it can only open directories).

One achievement that I’ve had that I am quite proud of is support for long file names. You may recall back in the days of DOS and early versions of Windows, you could only have an 8 character filename and a 3 character extension with considerable restrictions on characters (must all be upper case, etc…) They added a bit of a hack to the standard to allow for longer filenames as used and loved by all of us today.

I thought I’d post a couple links to invaluable resources that I’ve found that detail the FAT filesystem (ordered by usefulness).

1. Fat16 Structure Information
2. File Allocation Table - Wikipedia
3. Microsoft’s FAT32 File System Specification

On another note, I really should have researched the PIC16F877A more thouroughly before embarking on my adventure. In the datasheet, it says 368×8 bytes of Ram. I foolishly interpreted this as 2944 bytes of RAM. Upon closer inspection of the datasheet (the memory map region specifically), it turns out that it is actually just 368 bytes of ram. After running through the compiler and leaving space for its own scratch pad’s and temporary variables, I only have enough space left for a 64 byte buffer. After deciding to support long file names, I had to cut this in half so that I could have some room to store the long file names. Suffice it to say, that space is scarce and as such, performance is taking a hit (smaller buffer means more frequent memory calls). Because of this serious limitation I’ve decided to switch to the PIC18F4585 which is very simmilar except that it has around 4Kb of RAM and can run at 40Mhz.

Until my newly sampled PICs arrive, I’ll have to continue to suffer with memory management issues. I’m hoping for a serious speed increase when the new chip arrives (I’ll use a 512byte buffer instead of a 32byte buffer and will be able to store more information at once).

Well, sorry that I haven’t posted lately, but I’ve been really quite busy. I’ve had quite a bit of success and the mp3 player project has gone through several key changes.

First, and most importantly, I’ve successfully (and reliably!) interfaced to the SD card. This took some work. On the breadboard pictured in one of the previous posts, I was getting some strange interference on the data line of the SD card. Because of this, I decided to switch to wire wrapping for my prototyping. It’s my first time wire wrapping so its still a bit sloppy, but is still leagues ahead of the breadboard in terms of expandability and neatness. After a few more headaches, I realized the problem; the first couple hundred bytes of my SD card are 0×00. I chose a more suitable address to read and it appeared to be working. After a few more tweaks it was reading consistantly and I was able to bump up the peak rate to around 305Kb/s.

Now I am on to the challenge of writing a FAT16 driver. Expect another post on details of this in a day or two.