Read/Write SD/MicroSD Card with Picaxe 08M2 or 18M2

L

lewisg

Senior Member
Not really what you asked for but the SparkFun OpenLog board is very nice for development work. Teamed up with a RTC you can do some serious testing.

011_2611A.jpg

For life in the real world the micro SD is a little small. I'm waiting on some SD OpenLog boards from seeedstudio.com. Should be easier to mount and use through the side of an enclosure.

I don't think there is a way to read from these.
 
M

MFB

Senior Member
I also found the SparkFun OpenLog board to be very easy to use with PICAXE. No need to SM a bare socket, or other messy things, you just have to wire four wires to a 0.1 inch connector. Have flown it many times on an RC electric aircraft and Its been completely reliable.
 
hippy

hippy

Ex-Staff (retired)
Here's some early work I did with an 18X and MMC card which will be good background for SD cards as well ...

http://homepage.ntlworld.com/the.happy.hippy/picaxe/picaxemc.htm

I also did an SD card project with a 28X2 as that has at least 512 bytes of RAM (scratchpad) which can hold a block of SD card data - I wouldn't consider using anything less than a 28X2 / 40X2.

I don't know if I released any code and never completed the project. It is possible but not a project for a novice or someone who doesn't enjoy reading datasheets and trawling for information on the web.
 
M

MFB

Senior Member
It seems to me that, unless you are designing a product and need to shave off every penny (and would then probably use a native PIC anyway), its not worth the trouble to mount a basic SD socket for connection to a PICAXE. For the cost of a breakout board you get easy of connection and a dedicated controller. Even if a pretty good programmer would have trouble interleaving main PICAXE tasks with background SD card interfacing. Even hippy didn't complete the project.
 
J

Jeremy Harris

Senior Member
I've just (this afternoon) hooked up an OpenLog to a Picaxe with the intention of building a stand-alone datalogger that doesn't need to be hooked up to a serial cable to programme it. My plan is to put a small text file on the uSD card with a PC, which has the date and time setting for the RTC, plus the desired sample rate. The Picaxe will read that text file, set the date and time (the time needs to be some time ahead when written to the card and synced with the turn-on time of the Picaxe to get the right clock setting) and then set the sample rate. The Picaxe will then put the OpenLog in "Command Mode" (ctrl Z three times), send an "append" command to create a new file name and open it for writing continuously, then just sit there sending measured values to the file.

Getting the OpenLog to work with the Picaxe was childs play, really simple. It just worked straight away (which is more than I can say for the blasted Vdrive2 that I struggled with for the best part of a day!). The OpenLog has to be about the cheapest and simplest way to create a uSD card interface, unless someone knows better...............
 
M

MFB

Senior Member
Yes, and its easy to read the SD card in MS WordPad and then paste the data into a spreadsheet.
 
S

saunj

Senior Member
I have looked, but not found a more easy way to interface to a SD card for PICAXE projects than the Rogue Robotics uMMC, which uses an RS-232 simple syntax. I have used 4, but don't like the $50 (CAD) price.
 
P

pyrogaz

Member
Tx, the PIC can write to, or read from, the Openlog although I've only ever written to it which of course only requires the use of three wires.
 
J

Jeremy Harris

Senior Member
If you read from the OpenLog, as well as write (which needs 4 wires, 0V, +V, Tx and Rx), then you can pretty much use it like a read/write device to talk directly to a uSD card. Handy if you want to do things like read settings into a Picaxe at start up, for example. Relatively cheap, too, at around £18. Be nice if it used SD, rather than uSD though, as I'd prefer the larger card format
 
M

moxhamj

New Member
SD cards need 6 wires - Gnd, 3V, Chip Select, Data in, Data Out and Clock. 10k pullup resistors on the last 4 so that the SD card is disabled if the microprocessor pins are inputs/high Z.

Micro SD and Standard SD are the same electrically and I have designed boards where the pad for the micro SD fits inside the pad for the standard SD. You can pick up microSD sockets for only a couple of dollars and the card itself is not much more. There are some great advantages to using SD cards.

The hard part is the code. In a nutshell, you need a lot of code space. It is encouraging to see the N8VEM group taking CP/M code from the 1970s and writing SD card drivers in Z80 assembly language, so if it can be done with an ancient microprocessor it ought to be possible to do it with a picaxe.

How many lines of code can you fit in one of these newer picaxe chips?
 
M

MFB

Senior Member
SD cards do indeed need 6 connections but the OpenLog controller interfaces with the PICAXE via serial UART. Therefore, just Data Out, Data In and two power wires.

Although the PICAXE may well be able to undertake the work of the SD interface controller (an AVR in the case of the OpenLog) it would probably have little processing power left for other tasks.
 
hippy

hippy

Ex-Staff (retired)
The main issue with SD Card is having a memory buffer to be able to store a page of data while that's being manipulated and that requires 512 bytes. That really limits PICAXE choice to 28X2 and 40X2. That also brings access to HSPI and background serial receive which can get interfacing speed up.

The hardest software part ( once the basic reading and writing of pages is done ) is in handling the FAT of the SD card and particularly calculating which page to write, and also updating the directory structure.

The biggest problem I had was in initialisation, determining what type and size of card is present. There are a number of different types ( beyond MMC, SD and SDHC ) of card and they require different initialisation and you cannot tell what type they are visually. Do that initialisation wrongly and it appears possible to render a card completely unusable - That's the only explanation I have for the SD card I killed. That and FAT32 complexities were the reasons I never completed the project - for cards it could initialise it worked as perfectly as I would hope for.

Ultimately it's probably best and easiest to design a PICAXE SD Card interface as a slave device, something controlled by another PICAXE ( probably serial ), and if you have a separate interface there's no great advantage over using a commercial offering; the cost of developing a PICAXE solution from scratch ( in time and effort ) will far exceed the cost of a commercial unit.

Reading is easier than writing, and it's possible to do that using less memory, so it might still make sense to use a PICAXE for reading configuration data and similar.
 
P

Pekari

Senior Member
Ok. Thanks all replyes!
So, maybe main issue is memory size. That's why we must use chip which have pins like horse to eat.
Maybe it can do also with some extra memory chip too? With 18M2 chip?
 
hippy

hippy

Ex-Staff (retired)
Pekari said:
Maybe it can do also with some extra memory chip too? With 18M2 chip?
Click to expand...
Possibly but that makes it far more complicated. You can't use HSPI commands, you can't have the same capabilities of background receive, and the code I have ( admittedly including debugging capabilities ) is nearly 4000 bytes long and uses 38 byte variables. You may do better at using less resources but would likely have to start compromising on software to make it fit and it would be much harder to code and debug.

If only wanting to read a card and pass its data on then it might make sense but I think it would be false economy not to use a 28X2 which is far better suited to the task. The small extra cost would quickly be eaten up by extra development time and effort.
 
You must log in or register to reply here.
Top