SD Cards anyone?
Posted: Wed Dec 28, 2011 6:49 pm
Has anyone tried interfacing some form of electronics to SD Cards? Shown below is my stab at doing so. However, I'm having one or two teething problems with it.
The idea behind it is to use the cards in one of two manners. Firstly as a huge great EEPROM, which in effect is all it is. This would make it non-removable as there would be no real distinct file system.
Second was then to add the FAT32 file-system such that files could be read/copied by any PC with a card-reader. FAT32 allows cards from 512MB up to 'really huge' to be used.
I'm frustrated by the fact I can read any sector of a 1GB card (I have two, different manufacturers) but any other card just fails, 16MB, 32MB, 256MB, 2GB and 4GB. Formatting in either FAT16 or FAT32 makes no difference...as one would expect when just reading raw sectors.
Now the 4GB is a SDHC card, so that does need handling differently, basically block-addressing rather than byte-addressing, so I'm not fretting over that.
So why the smaller cards refuse to work is confounding me! The cards work in a PC, camera...whatever, so there's nothing wrong with them.
I've trawled the 'net and only come across mostly conflicting 'solutions'. Even the SD Associations own data is vague in certain areas.
I have yet to address the next issue of writing to them. That will be fun for sure!!
Hardware is a PIC18F25K20, a MAX3232 and the SD card itself, all running at 3.3V so no 'fudging' of different voltage levels. Xtal is 12.288MHz using the x4 PLL so the instruction frequency is also 12.288MHz. (These PICs can run at 64MHz if need be, here after the PLL Fosc = 49.152MHz). The cards are clocked at just over 100kHz as they need to be in the initialization process. I have tried ramping up the speed for the cards to 12.288MHz after initialization and the 1GB cards are quite OK with that. But for now I have kept the SD card clock speed at 100kHz or so until I get this problem fixed.
Decoupling/bypassing is (as usual with me) quite thorough, in addition to what you can see in the photo, there's another 47uF cap right under the SD Card 'board' and another 100nF disc-ceramic cap right on the pins of the card connector (also out of view on the underside).
The TO220 package is a LM317 regulator for the 3.3V supply. It's all a bit rough and ready...a dummy SD card was fitted at the time the photo was taken. The only reason I used a 40-pin chip is that my supplier here was out of stock of the 28-pin variant which for this exercise is functionally identical (PIC18F25K20). My plan is eventually to squeeze this into a 20-pin package, something like a PIC18F14K50 perhaps?
This has many potential uses from data-logging (i.e. slow) to NBTV video recording and playback with the file being saved as either a 44.1kHz or 48kHz .wav file, hence my other posting regarding multiples of 44.1kHz crystals a few weeks back.
If the PIC internal A-D can be used all that's needed in addition would be some filtering. Advantage over mp3/wav recorders? It's DC coupled. (I'm not in any way suggesting using mp3 at all).
If any of you can help or know of others who might be able to, great! If not, never mind, I'll get there one way or another, I'm just trying to short-circuit a lot of iteration.
Steve A.
P.S. I have no intention of handling MMC (Multi-Media-Cards) which are physically and to a large degree electrically compatible...I've actually never seen one!
The idea behind it is to use the cards in one of two manners. Firstly as a huge great EEPROM, which in effect is all it is. This would make it non-removable as there would be no real distinct file system.
Second was then to add the FAT32 file-system such that files could be read/copied by any PC with a card-reader. FAT32 allows cards from 512MB up to 'really huge' to be used.
I'm frustrated by the fact I can read any sector of a 1GB card (I have two, different manufacturers) but any other card just fails, 16MB, 32MB, 256MB, 2GB and 4GB. Formatting in either FAT16 or FAT32 makes no difference...as one would expect when just reading raw sectors.
Now the 4GB is a SDHC card, so that does need handling differently, basically block-addressing rather than byte-addressing, so I'm not fretting over that.
So why the smaller cards refuse to work is confounding me! The cards work in a PC, camera...whatever, so there's nothing wrong with them.
I've trawled the 'net and only come across mostly conflicting 'solutions'. Even the SD Associations own data is vague in certain areas.
I have yet to address the next issue of writing to them. That will be fun for sure!!
Hardware is a PIC18F25K20, a MAX3232 and the SD card itself, all running at 3.3V so no 'fudging' of different voltage levels. Xtal is 12.288MHz using the x4 PLL so the instruction frequency is also 12.288MHz. (These PICs can run at 64MHz if need be, here after the PLL Fosc = 49.152MHz). The cards are clocked at just over 100kHz as they need to be in the initialization process. I have tried ramping up the speed for the cards to 12.288MHz after initialization and the 1GB cards are quite OK with that. But for now I have kept the SD card clock speed at 100kHz or so until I get this problem fixed.
Decoupling/bypassing is (as usual with me) quite thorough, in addition to what you can see in the photo, there's another 47uF cap right under the SD Card 'board' and another 100nF disc-ceramic cap right on the pins of the card connector (also out of view on the underside).
The TO220 package is a LM317 regulator for the 3.3V supply. It's all a bit rough and ready...a dummy SD card was fitted at the time the photo was taken. The only reason I used a 40-pin chip is that my supplier here was out of stock of the 28-pin variant which for this exercise is functionally identical (PIC18F25K20). My plan is eventually to squeeze this into a 20-pin package, something like a PIC18F14K50 perhaps?
This has many potential uses from data-logging (i.e. slow) to NBTV video recording and playback with the file being saved as either a 44.1kHz or 48kHz .wav file, hence my other posting regarding multiples of 44.1kHz crystals a few weeks back.
If the PIC internal A-D can be used all that's needed in addition would be some filtering. Advantage over mp3/wav recorders? It's DC coupled. (I'm not in any way suggesting using mp3 at all).
If any of you can help or know of others who might be able to, great! If not, never mind, I'll get there one way or another, I'm just trying to short-circuit a lot of iteration.
Steve A.
P.S. I have no intention of handling MMC (Multi-Media-Cards) which are physically and to a large degree electrically compatible...I've actually never seen one!