View previous topic :: View next topic |
Author |
Message |
ALCION
Joined: 31 May 2007 Posts: 16
|
MMC/SD AND PIC16F876 |
Posted: Thu May 31, 2007 7:08 pm |
|
|
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
Joined: 12 Aug 2004 Posts: 1636 Location: Perth, Australia
|
|
Posted: Thu May 31, 2007 9:46 pm |
|
|
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
Joined: 31 May 2007 Posts: 16
|
|
Posted: Thu May 31, 2007 9:51 pm |
|
|
Ok, Thanks asmallri
I will check that. |
|
|
Guest
|
|
Posted: Wed Jul 25, 2007 8:44 am |
|
|
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
Joined: 07 Sep 2003 Posts: 755 Location: Florida
|
|
Posted: Wed Jul 25, 2007 10:29 am |
|
|
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
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Wed Jul 25, 2007 4:34 pm |
|
|
Anonymous wrote: | 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? | No, you can't use the EEPROM as this will 'wear out' over time and corrupt your data.
As Douglas already hinted to there is a possible tweak to work around the 512 byte restriction. Writes to the MMC have to happen in 512 byte chunks but you could decide to only use let's say the first 100 bytes and fill the rest of the block with fixed zero values. On reading the data you have to take care only to read the first 100 bytes of every block.
This is a terrible waste of MMC memory capacity, but who cares anyway with the low MMC prices nowadays? |
|
|
Guest
|
|
Posted: Fri Jul 27, 2007 10:15 am |
|
|
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
Joined: 07 Sep 2003 Posts: 755 Location: Florida
|
|
Posted: Fri Jul 27, 2007 10:52 am |
|
|
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
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Sat Jul 28, 2007 6:59 am |
|
|
Anonymous wrote: | 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? | This same problem was discussed in http://www.ccsinfo.com/forum/viewtopic.php?t=27295&postdays=0&postorder=asc&start=15
I like Libor's suggestion of having the PC create one large file on the MMC card. This way all the FAT related stuff is left to the PC. In your PIC you only have to write some code to find the start address of the file and than you can start writing. |
|
|
radiocode
Joined: 26 Jun 2007 Posts: 4 Location: Chippenham, England, UK
|
|
Posted: Tue Jul 31, 2007 8:45 am |
|
|
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
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Tue Jul 31, 2007 9:04 am |
|
|
Quote: | They are a lot slower than using external RAM | True, but FRAM is faster than a 40MHz clocked PIC can write the data over SPI so this is not an issue. |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1636 Location: Perth, Australia
|
|
Posted: Tue Jul 31, 2007 9:16 am |
|
|
radiocode wrote: | 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. |
Why would you do this when you could plus a 2620 in your existing hardware cheaper than you can add the RAM and end up with a better solution? _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
radiocode
Joined: 26 Jun 2007 Posts: 4 Location: Chippenham, England, UK
|
|
Posted: Tue Jul 31, 2007 3:01 pm |
|
|
asmallri wrote: | Why would you do this when you could plus a 2620 in your existing hardware cheaper than you can add the RAM and end up with a better solution? |
I like the intellectual challenge! (Plus I have the PCM compiler which doesn't do the 18F parts!)
I'd agree that the 18F part would be a far nicer implementation though. I'd better start saving my pennies for an upgrade.
Lee |
|
|
radiocode
Joined: 26 Jun 2007 Posts: 4 Location: Chippenham, England, UK
|
|
Posted: Tue Jul 31, 2007 3:07 pm |
|
|
asmallri wrote: | Why would you do this when you could plus a 2620 in your existing hardware cheaper than you can add the RAM and end up with a better solution? |
I like the intellectual challenge! (Plus I have the PCM compiler which doesn't do the 18F parts!)
I'd agree that the 18F part would be a far nicer implementation though. I'd better start saving my pennies for an upgrade.
Lee |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Tue Jul 31, 2007 3:18 pm |
|
|
Quote: | 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. | Just wondering, how are you going to copy from the FRAM to the MMC card? You can't put them both on the same SPI bus because when you start the block write on the MMC card you are not allowed to de-activate the chip select line until the block is finished. Do you have the FRAM on a second SPI bus or on I2C?
I found this out the hard way. |
|
|
|