Shop OBEX P1 Docs P2 Docs Learn Events
SD card to Stamp — Parallax Forums

SD card to Stamp

krokikroki Posts: 21
edited 2005-02-12 03:04 in BASIC Stamp
Hi!

I just figured, that my project need more data space then a 24LC512 (64Kb), and found an SD card and a socket.
I found the documentation of the SD, and am curious, if anyone had tried to use it with a Stamp.cry.gif
So can anyone help me to use it with a BS2sx or P24?blush.gif
Best regards:
Kroki
«1

Comments

  • GadgetmanGadgetman Posts: 2,436
    edited 2005-02-09 10:52
    Where is the documentation?
  • krokikroki Posts: 21
    edited 2005-02-09 11:08
    Sorry!
    I forgot, but now here it is.
    pdf
    pdf
    Product ManualSDCardv1.7.pdf
    1M
  • GadgetmanGadgetman Posts: 2,436
    edited 2005-02-09 11:22
    I've looked it over somewhat....
    (I'm a fast reader ...)

    It seems that it is supposed to be written to in chunks of 512Bytes at a time, and that will probably be the biggest problem as you'll have trouble setting up so much data.

    How much data space do you need?
    Can't you just use a couple more 24LC512 chips?
    Just hook the Enable pins to either a 74xx138 3-to-8 demultiplexer and reserve 3 pins on the BS2 to do the chip-select, or possible a row of shift-registers.
  • krokikroki Posts: 21
    edited 2005-02-09 11:26
    Or simply use 8 pcs. of 24LC512 tongue.gif (Because the I2C line supports 8)
    I fantasized about a replacable storage, even in a closed box. But it's a dream smhair.gif
  • upand_at_themupand_at_them Posts: 61
    edited 2005-02-09 13:26
    I've used a PIC with an MMC card (same as SD and uses the same SPI protocol, but thinner), but as someone already pointed out you have to write to it in 512 byte chunks.· Stamps don't have that much RAM and only a couple top-end PICs do.

    A bunch of 24LC512s should be good, no?· Jameco also sells 24C1024 (128Kb) chips in both DIP and SMD.

    Mike

    ·
  • steve_bsteve_b Posts: 1,563
    edited 2005-02-09 13:34
    I know I've seen those little card 'modules' for data logging.· Looks about the size of those 'siteplayer' modules but with the SSD/MMC/LMNOP slot in the side.

    Is that an option?· Would be easier on the code too....lets the device handle the protocol and you send it TTL/RS232.



    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·

    Steve
    http://members.rogers.com/steve.brady
    "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
  • upand_at_themupand_at_them Posts: 61
    edited 2005-02-09 14:21
    The modules I've seen use an EEPROM to hold the 512 bytes before writing to the MMC/SD card.· Which doesn't make sense, because the EEPROM has a limited number of write cycles (usually 100,000).

    In fact, a 128MB card has 262,144 blocks of 512 bytes.· So if you just fill up the 128MB card once you exceed the life expentancy of the EEPROM.

    Mike
  • steve_bsteve_b Posts: 1,563
    edited 2005-02-09 14:33
    You sure it's that small?

    I thought the stamps own Eprom had a MTBF of 1million writes.· But is that writes AND rewrites....cuz it has to erase it before it writes it....or does it (I'm still a magnetic tape guy! haha).

    Anyhow, it's like cars these days....they build them so they'll last for 150kms.· If they built them to last longer, then the industry wouldn't be as strong.· BUT, some people can get 200-300km's out of them.· I know a guy that just flipped to 400km last summer.

    Anyways....it's not like you can duct tape a bumper to your Eprom to get it to go the distance either.

    Those Eprom's surface mount?·· buy some extra's and replace on your own (~$5 item).

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·

    Steve
    http://members.rogers.com/steve.brady
    "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
  • krokikroki Posts: 21
    edited 2005-02-09 14:39
    Meanwhile i read a bit in the manual, and found, that:

    "Another SPI common characteristic, whitch is implemented in the SD Card as well, is·byte transfers. All data tokens are multiples of 8-bit bytes and always byte aligned to the CS signal. The SPI standard defines the physical link only and not the complete data transfer protocol. In SPI Bus mode, the DS Card uses a subset of the SD Card protocol and command set."

    Do i read correct, that i can use it in 8 bit cycles, and it can be controlled with the CS signal?

    ????????shocked.gif

    p.s.: I'm from Hungary, so forgive me, but I think I need a little help in the understandig of the manual. Or is it not just me, who doesn't understand every sentence of it?blush.gif
  • steve_bsteve_b Posts: 1,563
    edited 2005-02-09 14:47
    Sounds like my union book....written in lawyer-ese!

    Certainly from the first sentence, you'd think it's possible.

    Just have to figure out how to do it and if there are 'consequences' of any sort. confused.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·

    Steve
    http://members.rogers.com/steve.brady
    "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
  • krokikroki Posts: 21
    edited 2005-02-09 15:13
    I'll try then
    in a few days.

    if it's working, i'll keep U up to date!
  • upand_at_themupand_at_them Posts: 61
    edited 2005-02-09 15:21
    kroki said...

    Do i read correct, that i can use it in 8 bit cycles, and it can be controlled with the CS signal?
    I haven't read the SD manual, but I do know that it uses the same SPI protocol as MMC.· And I have read the MMC manual.

    The "8 bits" being referred to is part of the communication protocol, not the storage of data.· An SPI command is made up of several bytes (each 8-bits).· And it takes many commands to fill a block.· Even though you send data to it byte-by-byte, you're not writing individual bytes.· There's no way to start writing in the middle of a block.

    -Mike

    ·
  • upand_at_themupand_at_them Posts: 61
    edited 2005-02-09 15:34
    steve_b said...

    You sure it's that small?

    Microchip's datasheet says 1,000,000 write cycles.· Atmel's says 100,000.· If you buy from Jameco you can't be sure which manufacturer you get.· Are they using a different process or is Atmel just more cautious in its estimate?· I don't know.

    Only Atmel makes the 1024Kbit 24C1024, though.

    -Mike
  • krokikroki Posts: 21
    edited 2005-02-09 15:44
    I know thet the data must be continous, but i need to store continous data stream, so it is possible to use an SD Card and a Pulsout comman smile.gif
  • Paul BakerPaul Baker Posts: 6,351
    edited 2005-02-09 16:05
    If your generating a data stream you shouldn't have any problems (as long as you adhere to timeout rules), quite a few SXers use the SD/MMC interface without much trouble. I know that its not quite the same as interfacing it with a stamp, but its do'able. If single byte write is desired, a small sram can be used which has unlimited rewritability, and if data retention is critical, there are sram power monitors which automatically supply back up power.
  • krokikroki Posts: 21
    edited 2005-02-09 16:13
    Yes!

    U just mentioned the idea i have:

    I will use some SRAM module, to store the data till the 512 bytes are "full", and then i shift it to the SD Card.

    But it's only possible, if the data is not continous.



    Now I have many ideas, and some of they may work:-)
  • BobNBobN Posts: 11
    edited 2005-02-09 16:48
    Here's a site that might help you out.

    http://www.ghielectronics.com/ALFAT.htm

    - Bob -
  • Tracy AllenTracy Allen Posts: 6,658
    edited 2005-02-09 17:32
    The Atmel AT45DBxxx series contains its own RAM buffers that shadow the flash pages, so you don't have to add one externally. These work with SHIFTIN/SHIFTOUT on the Stamp and they come either as chips (up to 512kbytes in 8 pin SOIC) or as cards (up to 32 Mbytes) that have the MMC form factor. You can write a single byte, but to do so you have to read the flash page into RAM, modify the byte in RAM, and then write the whole page back to the flash.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
  • SPENCESPENCE Posts: 204
    edited 2005-02-09 22:14
    HEY BobN WWWWOOOOOWWWW!!!!!!!!!!!!!!

    THAT IS THE TIP I HAVE BEEN WAITING FOR. HAVE SUGGESTED THEY ADD I2C I/O ALSO.....

    NO I WONDER IF THE ALFAT DEV BOARD WOULD WORK THRU THE IDE INTER FACE TO IOMEGA 100,250 AND 750 IDE DRIVES. SINCE THEY CLAIM IT WILL WORK WITH HARD DRIVES, IT SHOULD.

    THIS COULD DEVELOPE INTO A VERY BIG BOONE FOR MICROPROCESSOR USERS OF ALL TYPES........

    73
    SPENCE
    K4KEP
  • upand_at_themupand_at_them Posts: 61
    edited 2005-02-10 01:41
    I just read this interesting little sentence on the website that had the PIC-to-MMC example that I used.

    "Writing to the MMC can be at any speed (i.e. 1byte per hour), but the "sector" is only saved if 512bytes were transmitted. "

    I like that.· I'll have to try it out.· It means that you don't have to worry about buffering·512 bytes in RAM.

    -Mike
  • upand_at_themupand_at_them Posts: 61
    edited 2005-02-10 03:47
    Okay, I tried this and it worked.· I had delays of·about 5 minutes between bytes and once the 512 byte sector was written it read back everything correctly.· I'll do an overnight test, but I don't see there being a problem.

    No need for a buffer now.· Cool.

    I'll see if I can get my code to work for a Stamp this weekend.

    -Mike
  • Jim McCorisonJim McCorison Posts: 359
    edited 2005-02-10 05:25
    The only issue is how sensitive to data loss is your application. I would guess, but don't know for sure, that the data that is stored but not yet written is volatile. If you lose power, you lose data. Perhaps that would be something to test as well.

    Jim
  • kelvin jameskelvin james Posts: 531
    edited 2005-02-10 07:43
    This looks like what you are trying to do. UMMC
    www.roguerobotics.com/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=5&MMN_position=6:2:5
  • upand_at_themupand_at_them Posts: 61
    edited 2005-02-10 14:49
    Jim McCorison said...
    The only issue is how sensitive to data loss is your application. I would guess, but don't know for sure, that the data that is stored but not yet written is volatile. If you lose power, you lose data. Perhaps that would be something to test as well.

    Jim
    I haven't tried cutting power on a half-full block, but I'd guess the same thing...that it's volatile.· The same problem exists with an external RAM buffering the data, though.· If the data is vital, Maxim makes a backup power chip that monitors main power and switches to backup when necessary.· For my application - a high altitude balloon - I'm not worried about losing the last block.

    Mike

    ·
  • Jim McCorisonJim McCorison Posts: 359
    edited 2005-02-10 15:57
    Mike said...
    The same problem exists with an external RAM buffering the data, though. If the data is vital, Maxim makes a backup power chip that monitors main power and switches to backup when necessary.

    Yeah, the DS1210. I'm traveling down a similar path with my project. I too had settled on using an MMC card, but for me the loss of a block would be more critical. I was planning on accumulating data into an SRAM using the DS1210 to protect against data loss. I have an Atmel AT45DBxxx MMC card, but had completely missed that you could buffer the data into the card before doing the write. Thanks Tracy!!! So now the question is, can the DS1210 be used to provide battery backup for the volatile portion of the MMC card? I haven't read the datasheet on it or the card about that possibility. But if it could be done it would be nice as it would remove another component from the design.

    Jim

    Edit: Forgot to mention that another prototyping option for MMC cards is from BiPom. I ordered their MMC-RTC-1 card www.bipom.com/periph_boards.shtm. It is pretty straight forward and includes a DS1307 RTC chip. It does not provide FAT support. It is basically a hardware interface, you do your own data structuring. OTH, it's half the price of the Rogue unit. It also has, in my opinion, a much better MMC card mounting for embedded applications. Just my $0.02

    Post Edited (Jim McCorison) : 2/10/2005 4:09:53 PM GMT
  • upand_at_themupand_at_them Posts: 61
    edited 2005-02-10 17:04
    Does the DS1210 have an output pin to indicate that it's running on backup?· There's one of them that does that.· And once your program determines that you're running on backup battery you could then fill up the rest of the block and write it to the MMC.· That's what I'm considering.

    My application isn't critical to have the last block, but I'm going to have a button on my circuit that commits the partial block to the MMC.

    -Mike
    ·
  • Jim McCorisonJim McCorison Posts: 359
    edited 2005-02-10 17:58
    As I understand it, the DS1210 is used to provide NVRAM capabilities in the event of a loss of Vcc, either accidental or intentional. As such, the processor is already in a low voltage situation and likely can not perform the sector write. The whole purpose is to just maintain status quo until power is applied again.

    Jim
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-02-11 15:07
    upand_at_them said...

    The modules I've seen use an EEPROM to hold the 512 bytes before writing to the MMC/SD card.· Which doesn't make sense, because the EEPROM has a limited number of write cycles (usually 100,000).

    In fact, a 128MB card has 262,144 blocks of 512 bytes.· So if you just fill up the 128MB card once you exceed the life expentancy of the EEPROM.

    Mike

    Mike,

    ·· The write cycles are per cell...So you would need to write the entire card over 100,000+ times to deplete it's life span.· Writing to an individual cell or block repeatedly would be the same thing.· Hence, you should use this type of memory as a RAM substitute.




    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    --==<{Chris}>==--
  • Paul BakerPaul Baker Posts: 6,351
    edited 2005-02-11 16:36
    Chris is right, each block has a MTBF of 100K writes, the control logic in the card will greatly effect a block's lifetime. If its a stupid controller that just times the write sequence, a block of the card could fail rather quickly, but cards have a bad block map (just like a hard drive) and that block would just be skipped, eventually the card will be filled with mostly bad blocks to the point of uselessness. But if the controller employs a wear-leveling technique it will distribute the writes evenly across the memory and you wouldn't experience failures until every block had been written 100k times, the only drawback to this approach is the memory tends to catostrophically fail about the same time and provided little warning to its eminence, with the non wear-leveling method the capacity of the memory gradually decreases, giving you some indication how soon the memory will no longer be usable. The smart controllers typically use virtual memory addressing, so if you specify (write this data to block #253) thats the virtual block address, the actually block address it's written to is determined by the controller, and it keeps track of how each block is mapped from a physical block·to a·virtual block. (this stuff is my forte, I examine patents on ths topic frequently, and Im not giving out any trade secrets here, there are hundreds of patents already on this topic)

    Post Edited (Paul Baker) : 2/11/2005 4:43:55 PM GMT
  • Tracy AllenTracy Allen Posts: 6,658
    edited 2005-02-11 20:07
    Yes, it is important to spread out the wear. For the Stamp interface, I keep two pointers in the battery-backed clock RAM, one being the base address of the current log file, and the second being the current offset into that file. When starting a new run, the base address moves up past the offset to point to a new stretch of memory, and the offset starts off at zero. Everything is done modulo the length of the memory array, of course. That way, the flash array is excersized evenly in a circle.

    The 3 volt power for the AT45DBxxx can be left on and battery backed to maintain the RAM buffers. Or, even if the power goes off, a few bytes can be added in the middle of a flash page by shadowing the whole page into the RAM buffer, writing the bytes at the appropriate address, and then writing the RAM back to the flash page. The engineers at Atmel recommend doing an erase before write to be sure that all the cells are solidly set, even if that means a few more writes to an individual page.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
Sign In or Register to comment.