0

I'm new in embedded electronic/programming but I have a project. For this project, I want to write raw data provided by sensor in 512b buffers on a SD card (SPI mode) with no filesystem.

I'm trying to do it by using the low level functions of the FATFS library. I've heard that I have to create my own format and rewrite functions to do it, but I'm lost in all those lines code... I suppose that I have first to initialize SD by using a command sequence (CMD0, CMD8, CMD55, ACMD41...).

I'm not sure for the next steps, if I have to open a file with the fopen function and then use the fwrite function...

If somebody can explain me how it work for a non filesystem SD card and guide me in the steps to follow I would be very grateful.

Clifford
  • 88,407
  • 13
  • 85
  • 165
Thomas
  • 11
  • 2

2 Answers2

0

If you don't want to use a file system, then fopen, and fwrite are irrelevant. You simply use the the low-level block driver. If you are referring to http://www.elm-chan.org/fsw/ff/00index_e.html, then the API subset you need is :

  • disk_status - Get device status
  • disk_initialize - Initialize device
  • disk_read - Read data
  • disk_write - Write data
  • disk_ioctl - Control device dependent functions

However, since you then have to manage the blocks somehow so you know which blocks are available and where to write next (like one large file), you will essentially be writing your own filesystem (albeit a very simple and limited one). So it begs the question of why you would not just use an existing filesystem?

There are many reasons for not using FAT in an embedded system but few of them will be resolved by implementing your own "raw" filesystem without you doing a lot of work reinventing the filesystem! Consider something more robust and designed for resource constrained embedded systems with potentially unreliable power source, such as littlefs.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • Thanks for your answer ! The reason why I can't use the FATFS lib is because I have a 512GB SD card using EXFAT. FATFS allows to use EXFAT format but you have to be in C99, what I can't do because of a compiler compatibility problem... – Thomas Dec 14 '21 at 10:35
  • @ Sounds like a XY problem. Surely the solution is to fix the code to be compatible with your toolchain. What is the toolchain/platform that does not support C99, and what feature of C99 is so essential? That might be an easier problem to solve than writing your own filesystem, and with 512GB to wrangle, you'll probably need one. That said littlefs can cope with 2TiB I believe. – Clifford Dec 15 '21 at 20:46
  • The problem of compatibility is a little tougher... I have to implement the code on an existing system that performs other tasks. This system is working with the TI V6.0.31 compiler with COEFF output format. If I want to use C99, my compiler have to be V8 or + and those versions no longer support COEFF, it use EABI output format. So if I wan't to resolve the problem, I should recode my DSPBios (a hell of a job...). I do not know Littlefs, is it natively compatible with EXFAT ? – Thomas Dec 21 '21 at 08:51
  • @TomoBiDiK : no it is not at all EXFAT compatible - generally a good thing since FAT is not power-fail safe. However surely that is not an issue since your proposal to write raw sectors is also not EXFAT. You remain unclear about what it is that won't work with your antique compiler. You said it was the FatFs code that needed C99; but now you are suggesting a need to recode DSPBIOS; that does not follow. What I am suggesting is modifying the ELM code to work with your existing compiler. – Clifford Dec 21 '21 at 15:57
  • @TomoDiDiK : As I said, it is an XY problem, and your solution to Y is not a good solution for your real problem X. Ask a question about X - i.e. how to build ELM FatFs EXFAT support with your specific (presumably C90?) compiler. Include details of what specifically does not compile. – Clifford Dec 21 '21 at 15:59
  • @TomoBiDiK : You appear to ne referring to this part of the ELM documentation regarding exFAT : _"Note that enabling exFAT discards ANSI C (C89) compatibility and wants C99 because of need for 64-bit integer type."_ If that is the only dependency then there is an easy and trivial solution; but you have to ask the question - it is not appropriate to provide an answer to an unasked question. You need to be clearer about what compiler and target you are using TI do not make just one compiler for one architecture - TI V6.0.31 is ambiguous. Not being C99 does not bean not having 64 bit support. – Clifford Dec 21 '21 at 16:52
  • @TomoBiDiK : I took a quick look at the ELM FatFs code. For pre-C99 compilers ff.h omits a definition for `QWORD` but your compiler supports 64-bit `long long` by extension, so simply add `typedef unsigned long long QWORD; /* 64-bit unsigned integer */` in ff.h You should then be good to go. – Clifford Dec 21 '21 at 18:12
  • hello @Clifford, thx for answering, I tried to change the type of QWORD var but without success... I will try to be clearer about my goals : I wan't to write raw binary datas on my SD card without using FS. Globally, I wan't to fill the SD card with 512bytes Buffers. Currently card initialization seems to work (using cmd sequence). I wan't now to write on the SD with the low level fonction "disk_write" : DRESULT disk_write (BYTE drv, const BYTE *buff, DWORD sector, BYTE count). I don't know what parameters "drv" and "sector" must be. What should be the location of the place to write. – Thomas Jan 03 '22 at 15:00
  • _"What should be the location of the place to write[?]"_ that is kind of why you need a files system and should not be ding this unless you are writing a file system and know what you are doing. It remains and X-Y problem - you are stuck on your solution to the problem of not being able to build EXFAT support - so have simply swapped one easy to solve problem for a harder to solve and inappropriate problem - tough your resilience in pursuing this ill-advised solution is impressive ;-). – Clifford Jan 04 '22 at 14:48
  • _"change the type of QWORD var but without success"_ You should be asking about that perhaps (in a separate question). Clearly you are not making the change correctly because you specifically need to _add_ the definition of `QWORD` rather then "_change_" the type of an existing definition, because for your compiler, there _is no definition_ - that is exactly the problem. I could tell you exactly what to change in an answer to a specific question, but not in a comment to a different question. – Clifford Jan 04 '22 at 14:52
  • re: _"What should be the location of the place to write[?]"_ (against my better judgement) [`disk_ioctl()`](http://www.elm-chan.org/fsw/ff/doc/dioctl.html) provides commands to retrieve write sector and erase block sizes and count necessary to answer that question.`drv` is the drive number. If you have only one drive it will presumably be zero (0), but you could read the documentation as well as I, and are in a position to try it. – Clifford Jan 04 '22 at 15:05
  • To be clear here though I have _answered_ your question - if the answer is not useful, then perhaps it is the wrong question or you need to ask additional questions - but you should not be asking them in the comments. SO is not a discussion forum - ass new questions if you wish to proceed with this folly, or ask about a different and better solution. It is most often better to ask for a solution to a problem than to ask about problems with your solution! – Clifford Jan 04 '22 at 15:09
0

Keep in mind that cards with a memory capacity > 2Tb are not supported in SPI mode (Physical Layer Simplified Specification.

Matt Andruff
  • 4,974
  • 1
  • 5
  • 21