SD memory interface via the SPI?

2008-09-04
2013-05-30
  • Nobody/Anonymous

    Had anyone worked out SPI code to write FAT16 or FAT32 files to an SD memory card in GC BASIC?

    I know Microchip has some PIC18 libs for this, but it should be possible even on the smaller 4k or 8k PIC16 chips if some simplifications are made (like sequential access to a single non-fragmented file on a blank card).

    The idea would be to be able to write the sequential files in 512 blocks using the PIC, then read out the data on a PC (or even LINUX or MACs since they also support FAT16 on SD cards).

    I know there are buffer RAM issues on the smaller PICS because of the SD memory protocol's need to write out full 512 byte sectors to the SD card, but there sould be some fairly simple hacks to get around this.

    For example, the memory card could be SPI clocked very slowly using a software SPI drive routine in order to allow the PIC to generate all 512 needed bytes in real time, which would minimize the buffer space needed. 

    Or alternately, a smaller number of bytes (for example 64 or 128) could be written in each block to stay within the PICs buffer RAM limits, then the remainder could just be null padded with zeros.  Then the files could be easily un-padded by the code on the PC side.

    This would waste a lot of space, but an inexpensive 2Gig SD card would still be able to hold hundreds of megs of data.

    Other than a few hacks to deal with the hassles of writing out 512 byte blocks on a memory starved chip, the process of initializing and writing data to an SD card doesn't look much more difficult than the LCD routines that GC basic already supports.

    Has anybody made any progress on this?

     
    • Nobody/Anonymous

      if microchip has libs for the PIC18s, why not just use one of those?

       
    • Nobody/Anonymous

      >>if microchip has libs for the PIC18s, why not just use one of those?

      I agree in principle that doing many hours more software work just to avoid spending a few dollars more on a more powerful processor is silly, it's just that I am trying very hard NOT to migrate upscale with Microchip.

      I don't need the full functionallity of a complex FAT file system, and figured that someone might have addressed a simpler set of functions needed for limited reading/writing of simple files on the PIC16 series.

      That's why I said -

      >>"I know Microchip has some PIC18 libs for this, but it should be possible even on the smaller 4k or 8k PIC16 chips if some simplifications are made (like sequential access to a single non-fragmented file on a blank card). "

      I already have some inexpensive development boards and tools for 16F877 series, so if I can cobble something togeather with what I have on hand, fine, but if I was going to move upscale, frankly, I would DUMP Microchip and go with another option.

      The project I have in mind is to try to get around some of the limitations of the PIC16 microcontrollers, by using a 16F877 only as the RISC CPU in an interpreter based von neuman machine archetecture, with inexpensive SD card memory as the program storage.

      The idea is that you would have a PIC 16F877 cpu acting as a BASIC INTERPRETER which would be tied to a standard SD CARD for the byte coded program storage (kind of like a BASIC STAMP on Steroids). 

      This would not only be much more powerful than the original BASIC STAMP, but much more convienent as well, because you could simply write the program to the SD card on any PC using a common SD card writer, then run it without any changes to the PIC side FLASH code whatsoever.

      This type of interpreted code would be slower (like a basic stamp), but 90% of the time speed is not an issue, and unlike compiled code, or the original BASIC STAMP, you could have programs that were many megabytes long, on a simple easy to swap card that only cost a few dollars.

      The 16F877 may sound like a weak choice, but it is much much more powerful than the processors used to create the original BASIC STAMP, and with almost unlimited flash memory available for program and data storage, the mind boggles at the potential applications.

      There are undoubtedly some comercial STAMP like products which are going this direction, but it would be nice to have a byte code interpreted GC BASIC branch that anyone could download onto a 16F877 and use (hooking up an SD card socket to a PIC requires only 4 wires like any SPI interface, so you could just breadboard it).

      Thus, you can understand my interest in reading/writing SD memory using the PIC16 series . . .

       
  • ryan see

    ryan see - 2010-11-22

    Good day. Can you help me in displaying the sd memory card files in a 4x20 lcd.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks