Stellarcore.com

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).

The Master Boot Record of my SD card starting at address 0×1BE (the important stuff). Bonus points to anyone who replies with comments stating what each byte of this block means.

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.

MP3 Player Schematic

I decided to give a bit more details on my MP3 player today. Above is my original schematic that I designed back in January (I’ve really been lagging a bit on this project). The design remains basically the same today, with a few minor changes.


For instance, in the schematic I have the LCD backlight controlled through a transfer gate, but after looking at the PIC’s datasheet and measuring the current drawn by the backlight, I decided that I would be able to connect the LCD directly to the PIC. As an added bonus, I connected the LCD to one of the pulse width modulated pins on the PIC and now have fine control over the brightness of the backlight. This will allow me to fade the backlight on/off when the user hasn’t pressed any buttons in a certain time period (power saving feature, yay!).



On another front, the SD card still gives me problems, and I have sampled some 3.3V LM2936 voltage regulators from National Semiconductors¹. I’m hoping that when the regulators arrive I will have more success with the SD card; imprecise voltages can have a large effect on the SD card operation from what I have read online. Up until now I have been powering my SD card through a simple voltage divider.