This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi everyone!
Long time! Finally some time for projects now that I am in vacation from University! Let's see how my coding is (and also how my english is too).
So I am now trying to finally use SD cards (I am probably saying for the past 2 years that I should do that).
Been successful using the FATFS with the port that comes with tivaware.But I am not liking the write times so I want to optimize that for data logging. This might be a bit more related to the third party software so it's probably more directed to the forum users and their experience rather than TI employees.
Been reading up in the best ways to log data into the sd card, but there's still an issue. A write will always take a couple milliseconds (sometimes a bunch of milliseconds). Basically f_write will block the code while that happens. Could implement DMA on the SPI or something similar but it seems f_write tries to read/write more stuff from/to the sd card. This means that f_write will still block the code for some milliseconds. Am I correct? This seems a bit weird because it seems the FATFS functions shouldn't be touched, only the port functions - so even when using an OS this seems unsolvable! (if I don't edit the FATFS functions and actually use them).
Before going and implementing DMA on the SPI I of course want to know if this will actually help.
I've seen suggestions to when actually logging data to avoid FATFS and write directly into the sectors (and previously having a file with pre-allocated size). Here DMA on the SPI would help avoid blocking the code for a long time.
I hope some of you can give me a boost and/or point if any of my line of thought is wrong.
I hope you have a continuation of a good day!
Luís
*** Noted *** After TWO YEARS - The much hoped/desired, "Return of Luis!" (might it be that poster Bruno left the dungeon (pardon) "work-place" door (bit) awry - enabling your escape?) Your English is fine - but for the "Brazilian accent, cadence & phraseology."
Welcome Luis - beyond "help" from those here - might your investigation into the "means/methods of (top flite) commercial products" using such "SD card storage media" - describe/define "What is "reasonably" achievable/possible?" Such should provide the "top end" - should be well marked w/in their Tech Lit. - and should save you substantial time/effort.
In general - might a boost (or point) result from your "writing such data into SRAM (first on chip) and later (off chip) as/if/where required?" Once the essential data has been captured - it may (then) be logged to the "slow" SD card (without great speed concerns) - for later analysis and/or processing...
Should (other) answers arrive - yet not to your liking - I'll contact via our (standard) means. (never mentioned - the "effectiveness of our hack-saw blades" - which embedded among tech shipment - strived to free you from your servitude...and B's claims that you "enjoyed" bread & water.)
Still sleepy zzz. I will answer here for future people that actually search forum.
I've seen it take 4ms and sometimes 100ms btw.
"Is there some sort of "I'm ready" message which is part of FAT protocol? I know for a fact that it ain't done by additional GPIO logical signals."
It does as far as I've seen. There is "wait_ready" in the port.
"Something that is certainly not useful is a "freezing" loop inside the SDCard library, some sort of "while(CARD_IS_STILL_BUSY){}", that throws your MCU to the trash bin not allowing it do anything else during the wait period. Again, does anyone here know if such happens?"
This does happen. This would easily solved with OS actually. Dunno how to solve without editing fatfs instead of just the port otherwise (besides what I am trying right now that is so far working).
"As for the physical transfer itself, indeed that is a phase where DMA can be useful. A properly sized buffer and a flip-flop-ping-pong-zig-zag smoothly implemented RAM to SPI engine would certainly alleviate the CPU burden for those byte hauling actions."
It might not help because of how fatfs works. Not sure if it's in certain conditions (cluster miss, cluster update and stuff like that) or always.
Luis Afonso said:This does happen. This would easily solved with OS actually.
I'm not sure this would be "easily solved with OS" - except if the OS actually slices time, automatically calls the taks for a period, and after a while regains control of the main system despite of what that transfer task was doing. Still, whatever period that is, the cpu will be doing nothing, stuck in that loop.
I assume it would be more efficient to have a brief call to something like
BackGroundLoop()
{
if (!CARD_IS_STILL_BUSY)
{
EnableDMATransferOfSomeMoreDataToCard();
}
ContinueDoingOtherThingsNotRelatedToSDCard();
}
Not too creative this morning to explain the idea, but I hope it makes sense.
Bruno
Mes Amis,
Is it possible that TWO Central Objectives - at minimum - (should) be "in play" here?
The posting (seems) to "skimp over" the requirement to, "Capture LIVE Data" at the highest possible rate! MCU and Analog vendors make every effort to "maximize such ADC rates" - any data logging system should NOT (hold hostage) data conversion rates to a flawed storage medium! Again - this critical point appears to have escaped notice (but for here) w/in this thread - it has (some) importance - does it not?
The suggestion to review the efforts & achievements of "top cabin" commercial vendors (still) appears a valuable source of insight (i.e. provides a storage time "benchmark") into what rates may be achievable via "SD card." Yet - most always - this is (very) much secondary to, "Capture of acquired data at the highest possible rate!"
Note too - certain "pro data loggers" write captured data "directly into RAM" - and then transfer that RAM data to a separate, attached device (PC usually) via Ethernet or USB - completely avoiding the "slow-down" and extra time/effort enforced by the SD card! (perhaps they "know" something...)
Hi again, Luis,
So good to have you back. As to your "use of SD card" - it's fine for non-volatile storage - AFTER the "Live Data" has been captured into the fastest memory available. (which - as you well know - is "never" an SD card!)
Firm/my belief (garnered during years "in the trenches") is that, "Capturing Live Data at the Highest possible data rate" is (always) JOB #1. If data capture is voluminous - external RAM can be deployed - the alternative (capturing into ... S L O W ... SD card is (rarely) seen on any "pro/serious" such Data-Logging System. "Blocking the MCU" as you note - should be "avoided at all costs" - which disqualifies the SD card as the (sole) data storage medium w/in such a system...
Luis Afonso said:I guess it's more of me always trying to push the hardware and software to see where it breaks and why.
That's "well & good" - but should "never" compromise the mission. Your subject: "Write/Read Optimization" flies in the face of "High Speed Data Capture." (i.e. Applying even the latest/greatest "lip gloss" to a "pig" - cannot insure "high finish" in the pending, "Ms. America" contest - even when the lips are (nicely) colored & glossed...) Indeed you may be able to "improve" SD card transfer rates - but to "What purpose?"
Your, "Pushing HW/SW to "tease out" learning is one means - yet further developing of your "investigative skills" - may prove faster, even better! This is so as there is "much to be gleaned" from reading the specs & product reviews provided by "market leaders." Such review may "save you" from techniques and/or implementations which have been properly found to be, "ineffective" - and which may have "eaten" substantial amounts of (your) time/effort.
Luis - sometimes "Choosing what to do" may prove more advantageous than, "Charging forward - minus a proper investigation..." (i.e. perhaps your "pushing the investigation" - before HW & SW - warrants your consideration...)