MMC/SD AND PIC16F876

[ALCION]

Hi, I know there are many post about it, but I dont know why it dont work. I use the mmc_spi.c driver but I have alot of erros. I have pcm ver 3.222 is a problem this? somebody have an example. thanks alot.

[asmallri]

If you want to write to the SD/MMC card with this PIC then you need to be aware that you must write in 512 byte blocks. These is very challenging when using a PIC that has only 384 bytes of RAM. If you want to write to the card then a PIC18F series controller, such as a PIC18F2620 (virtually pin compatible with the PIC16F876), with 3900 bytes of RAM is a better choice.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[ALCION]

Ok, Thanks asmallri

I will check that.

[Guest]

if i may i would like to ask if i wanted nevertheless use the 16f pic is it possible to do so? can i use the EEPROM memory? or the only solution is to change to a 18f pic?

Thank you

[Douglas Kennedy]

Well the restriction imposed by the card is that you must write 512 bytes each and every time you write. Now this often is interpreted as needing 512 bytes of ram. This comes from the fact that if a sector (512 bytes) is to be updated then it must be read in and then modified before writing out. So 512 bytes of storage are needed to prevent loss of data. Now if you are writing a new sector or erasing and re-writing an existing sector all that matters is that you write 512 bytes. If you chose to write "x" to every byte then you wouldn't need the RAM but it would be of little practical use. The 512 byte restriction doesn't apply to a read reads have a modifiable block size. MMC SD cards work well with the PIC small pin count , built in SPI but the nice thing is the controller on the card automatically keeps track of bad sectors so physical bad sector differences between cards are hidden by the cards controller and the PIC programmer can ignore them. Something to wish for would have been for the cards controller to have added embedded logic for a file system. That way we wouldn't need Microsoft patent permission as we do with FAT when placing FAT code on a PIC and it would free up code space on the PIC.

[ckielstra]

[Guest]

thanks for your answer but i have another one

I want to write some data from the pic to the sd card using SPI but i want the written data to be acessible from a card reader. to do this i must write a fat32 code and a spi transfer code or if i just write the spi transfer code to write in each 512 bytes of the sd card this will be readable in the card reader? don't know if i made myself clear?

thanks

[Douglas Kennedy]

Data is data so if you write it to the card it will be on the card. Now having it read and understood by a card reader depends on the software attached to the card reader. This software is often called a driver. It's purpose is to relieve some higher level operating system from gaining too much knowledge about hardware. In the case of Microsoft and the FAT file system usually the Microsoft OS sends primitives ( like open close read write erase format) to the driver and driver in turn deals with the firmware/hardware ( MMC card and controller). If the card reader uses FAT drivers the card will need a FAT format. Now you could format the card using a PC operating system and place a single very large file on it.
You could write with a PIC (using very stripped down PIC code) to that file. You still have to read the FAT cluster tables to get the physical address for the sectors within this large file. You could develop your own file system always keeping it wrapped by your single large file. Your PC would using your own c code open the file and access your file system.
Remember Microsoft has a patent and you should not see this post in anyway as encouraging you to violate this lawful patent.

[ckielstra]

[radiocode]

I have started work on a GPS datalogger at home - one solution I have been toying with is to hook a Ramtrom Ferrite RAM to the PIC 16F and use that to cache the 512 byte blocks prior to writing it to the SD/MMC.

The FRAM devices are cheap and reasonably fast - they don't suffer the write delay problems of FLASH EEPROM either. They are a lot slower than using external RAM, but at least I can use a 16F device and not have to upgrade my compiler

Having the FRAM on the board might have a positive impact on power consumption too - cache several blocks then write them to the SD/MMC in one hit.... Hmmm, something to try.

Lee

So little time... so many hobbies!

[ckielstra]

[asmallri]

[radiocode]

[radiocode]

[ckielstra]