Hello,
I would like some assistance with storing information on a SD card in the format of a text file. This SD card is connected to a 8051 microcontroller. Communication with the card is done via the SPI. I'd really appreciate some sort of #include file or anything that lets me have access to functions such as fprintf and fscanf, fopen, fclose. Also if anyone can tell me weather FATfs (elm-chan.org/.../00index_e.html) files are ok to compile on a 8051.
It's really not that complicated - once ChaN has done most of the work for you!
FatFs gives you just a couple of dozen functions - and, as already noted, many (most?) of those are not relevant to your simple application.
The functions you requested are there: f_open, f_close, f_write, f_putc, f_puts, f_printf, etc...
If you do it all yourself, you will still end up having to write equivalent functions anyhow.
And you will have to delve into the arcane world of the SD Card SPI protocol, and implement that yourself.
"I need the 8051 (C8051F040 specifically) for its ADC"
But why an 8051? Plenty of microcontrollers have on-board ADCs these days!
Since the SD Card part seems to be the big obstacle to you, why not look for a board that comes complete with SD Card socket & examples, and work from there...?
While that is becoming a more and more obvious solution, I've only had experience with the 8051 uC and have already purchased it. Originally I had hoped for an easy way to add extra storage space to it as the rest is solvable (interfacing UART and such). The SD approach was also a suggestion from an aquaintance and I've come here in hopes of finding if there are other more convenient and easy to implement ways to store data.
"Since the SD Card part seems to be the big obstacle to you, why not look for a board that comes complete with SD Card socket & examples, and work from there...?"
I'd second that. You can go to plenty of on-line stores and buy really good little STM32 based boards for really small amounts of money. A lot have SD slots, extra memory, plenty of connectors, examples etc.
So it sounds like this is a 1-off?
Is it a student project?
The most logical approach for storing your data in case you do not want to use a memory card with a file system on it, is to use a SPI-connected EEPROM. They have much simpler SPI protocol than the SPI protocol used for SD memories.
But if you have already fixed the required hw for interfacing with a SD card, please go ahead with the referenced library. SPI in itself is not complicated, and it is mainly the SPI that must be mapped from the original processor.
you cn get directly addressable 2Mbyte flash chips for <$3. with data banking it will be a matter of straight writes, no FAT, no ..., no ....
Erik
Thank you for your answers. I will definitely look into those flash chips as they seem to be exactly what I need.
Also I'd greatly appreciate a link to a site that vendors or offers further assistance with using such devices. I will search myself, but if you already know of such a site, please post a link to it.
ww1.microchip.com/.../S71243.pdf
as an example
SST (now microchip) has some good chips for this. When I needed to find a suitable chip for the then purpose, I actually called SST regarding the chip erase time which for SST is in milliseconds what others want in seconds.
Anyhow the datasheet should tell you all you need to know, BUT be sure you choose a chip you can get. Code for one flash does not necessarily work for another flash.
"you cn get directly addressable 2Mbyte flash chips for <$3"
Depends on the actual volume of data involved - you'd probably have to look quite hard to find an SD card smaller than 2Gbyte these days!
"no FAT, no ..., no ..."
That's not exactly true, is it?
You will have to devise some scheme for erasing the flash, determining what space is free, wear levelling, etc, ...
You will also have to devise some scheme to get the data off the embedded device and onto the PC.
For wear-leveling, it's possible to use a 2MB memory as a single ring-buffer where the writes not only contains the measurements + time stamps but also (if the time stamps aren't strictly increasing) record sequence numbers that allows the program to know where the current position is for read and write.
For wear-leveling, it's possible to use a 2MB memory as a single ring-buffer where the writes not only contains the measurements + time stamps but also (if the time stamps aren't strictly increasing) record sequence numbers that allows the program to know where the current position is for read and write
struct { whatever else used }
set 'used' to zero when the place is used (it will be 0xff after erase) at power up transfer first empty to ram
struct { whatever else used read }
if you have no other means of determining which records have been transferred to the PC, expand as the above