Question on using CCS FAT.C

cbarberis · Posted: Mon Feb 11, 2019 3:59 pm

I am trying for the first time to integrate the capability to allow me to log captured data onto an SD card. I already have the correct hardware interface on my board to support the SD card. I am using a dsPIC33EV256GM106, but the problem I am facing is that I have never used the FAT file lib support and the correct way to use it. I have FAT.c and MMCSD.c. I take it one works with the other where FAT.C handles file management and MMCSD.c handles the actual interface to the SD card.

My SPI is setup as follows to talk to the SD card:

jeremiah · Joined: 20 Jul 2010 Posts: 1354

Have you looked at the example that comes supplied with the compiler: ex_fat.c?

It shows the various steps of managing a file, including calling mk_file() to make it. You might glean through some of that.

Ttelmah · Joined: 11 Mar 2010 Posts: 19538

as Jeremiah says, the example is ex_fat.c
However add to this, that you need to use the modifications from here:
<http://www.ccsinfo.com/forum/viewtopic.php?t=53787>

There is one issue with the original CCS code that has to be fixed, and then
a couple of improvements that are required to support MBR formatted
cards, and later SD's.

empty · Joined: 13 Jan 2018 Posts: 15

This topic contains some useful links with test example of ex_fat.c:
http://www.ccsinfo.com/forum/viewtopic.php?t=57741

The modified versions also support SD cards with MBR.

temtronic · Posted: Tue Feb 12, 2019 6:27 am

Years ago for a datalogging project I looked at SD but decided on the 'vinculum' product. Yes more money up front but it worked 'right out of the box', so maybe 1/2 day of R&D time. By storing the data in CSV formatted files, clients get to see the data instantly in Excel.
There are several other options, like 'openlog', that kinda do the same thing.
If this is a 'personal project', you'll spend a lot of time getting it 'up and running' but you'll learn a lot. In my case I needed an 'out the door' solution in a week's time. Millons of readings later, it's still running fine.

Jay

dluu13 · Joined: 28 Sep 2018 Posts: 395 Location: Toronto, ON

But before you can create/modify files, you will need to run fat_init().

fat_init() initializes your SD card into SPI mode and reads the FAT table and MBR.

Tallarico · Joined: 11 Feb 2019 Posts: 1

cbarberis · Posted: Tue Feb 12, 2019 8:47 am

Thank you all for the good info. Yes I had looked at ex_Fat.c but I still had some questions on the usage. Based on your info I found the modified files (MMCSD.C and FAT_PIC.C) from: https://simple-circuit.com/pic18f4550-datalogger-sd-card-dht11/
I believe the above files support the MBR and will work with SD cards > 2MB there is a data logging example at this same location that basically answers most of my questions.
I have also looked at the "OpenLog" module which seems to be a neat way to get around this. While I am on the subject, I would like to ask for your opinion about using serial EEPROM for data logging, is that a crazy idea? My board has a 1Mb I2C serial EEPROM but I know for a fact that a 2Mb (256K X 8) is available in SPI mode based on my calculations I could store over 15000 data logs. The only problem I see with that is how to manage and index the data logs. I believe that the larger EEPROM's like this one have page mode read/writes as well.

newguy · Joined: 24 Jun 2004 Posts: 1909

EEPROMs are suitable for a datalogger but beware the write limit and the write speed. If your application needs to write over and over, consider an FRAM or MRAM. Either is rated for basically unlimited writes*, and write speed is pretty much instantaneous. Trade-off: neither of these technologies is particularly cheap.

FRAM: https://www.digikey.ca/product-detail/en/fujitsu-electronics-america-inc/MB85RC1MTPNF-G-JNERE1/865-1268-1-ND/5456442

MRAM: https://www.digikey.ca/product-detail/en/everspin-technologies-inc/MR25H10CDF/819-1039-ND/3471116

Alternative: have you considered a flash memory instead? Decent number of writes, good speed, cheap. Trade-off is that an entire block/sector must be written at once, which means you have to buffer quite a bit of data in RAM before you can write.

Flash: https://www.digikey.ca/product-detail/en/microchip-technology/SST25VF010A-33-4C-SAE-T/SST25VF010A-33-4C-SAE-TCT-ND/5169587

*Despite their claims to the contrary, I have actually had to deal with a bad batch of FRAMs which started to exhibit "sticky bits" that couldn't be flipped.

temtronic · Posted: Tue Feb 12, 2019 5:37 pm

As newguy points out 'write speed' may be an issue.. normally you buffer readings into a 'page' sized chunk of RAM, then write the page worth of data to EEPROM. One problem is that if (when..) there's a 'glitch', you'll lose a page worth of data.
As for organizing the data, it depends upon the 'update' or 'sample' rate. 1,000s of reading per second or 1 per hour ? BIG diffenece in how it's handled. If 'timed', say every 1/4 hr, then you already have a reference point. Simply save the time at midnight, 4 readings/hr....easy. You could pack the time offset into 1 byte (7 bits actually).
You should look at Viniculum...uses USB flash for storage, any size works, and transportable to any PC or laptop.Not the cheapest hardware solution BUT no software to cut and really what's YOUR time worth? You've probably spent 2-3 hrs minimum fighting 'code' when buying a v2 for $50 gets you 'up and running' in less thn an hour. Food for thought.

Jay