LOGGING - Time Stamps on records, stored to SD
prof_braino
Posts: 4,313
Timestamps have microsecond resolution, using cnt and 64 bit values. Collisions are possible, but don't happen (so far)
Double math is used to calculate time
After initial calculation of drift (about 1 day), the clock remains nuts dead on as long as the temperature doesn't change. No plan to add thermistor compensation until winter.
Could not damage an SD by relentless writes, 1 record per second for several days, still going after 50 meg of data, first test will run 45 days. E#ach new record is appended, the FILE HEADER is rewritten every time, we think that will go first.
This is all done in software, aside from the SD slot, no additional hardware is needed.
Could somebody familiar with logging take a look at this and make comments?
http://code.google.com/p/propforth/wiki/Logger1Simple
It is being added to Propforth.
Thanks!
Double math is used to calculate time
After initial calculation of drift (about 1 day), the clock remains nuts dead on as long as the temperature doesn't change. No plan to add thermistor compensation until winter.
Could not damage an SD by relentless writes, 1 record per second for several days, still going after 50 meg of data, first test will run 45 days. E#ach new record is appended, the FILE HEADER is rewritten every time, we think that will go first.
This is all done in software, aside from the SD slot, no additional hardware is needed.
Could somebody familiar with logging take a look at this and make comments?
http://code.google.com/p/propforth/wiki/Logger1Simple
It is being added to Propforth.
Thanks!
Comments
Didn't I read somewhere that the circuitry in the card itself will spread out writes of the entire memory to avoid making hot spots? If true, then while I'd still keep it as a concern, it may be one deferred a while by the card itself...
EDIT: Wear leveling! Just remembered the name!
Propforth writes to specific physical sectors. It skips a bunch of built in support, this is why its so fast and compact. And why we as embedded developers have to pay attention to low level details. Wear levelling is expensive in terms of time, throughput, and code size, and is really only mandatory when the system is not designed for economy and efficiency, for example windows. While the "bloatware" solution is fine for PC OS solutions, propforth explores the "small efficient" route.
As near as we can tell, the physical block that contains the file header is constantly being rewritten. Sal was examining buffering schemes, for example buffering multiple 64 pages before a write. In trying to establish a baseline, he noticed that the card wasn't failing, and decided to beat it to death. And is hasn't died. This is the cheapest, old 2 Gig card in his drawer (the most expendable). The current test is going to try to run 45 days. If it make it that far, Sal will try another test for 90 days, and so on until it croaks.