From: Joe Chisolm on
Silvar Beitel wrote:
> On Mar 24, 2:16 pm, D Yuniskis <not.going.to...(a)seen.com> wrote:
>> Hi Silvar,
>>
>> Silvar Beitel wrote:
>>> Custom datalogger circuit using SD card, running on switched
>>> automotive power.
>>> It's cheerfully writing data to the card and the power quits (user
>>> turns key off, accidently pulls off power connector, engine stalls,
>>> car crashes, whatever - this could even be the preferred method for
>>> stopping it if it's robust). Up to three blocks worth of cached data
>>> need to be saved in the card (data block, FAT block, block w/
>>> directory entry) before the system can die cleanly.
>> Presumably, that is because you "just" want the user to
>> (later) plug the SD card into a "PC" and read an intact
>> filesystem? (i.e., you aren't planning on having any
>> "special" application that can read the card *specifically*).
>> Otherwise, you could just update the data in an "expected"
>> manner and have that special application find it and
>> respond accordingly (e.g., even "fixing up" the SD card
>> to make everything look like a typical filesystem). Cuts
>> this down to a single block update (?)
>
> Excellent observation. "Special" application to read the card would
> be OK, narrowing down the write to a single block (that is in fact
> what is happening in the prototype - real file system support within
> the unit is "on the table".) But even that one-block write consumes
> some significant juice.

Since a special app to read the card is OK you could treat the SD card
has one big circular buffer. This becomes trivial if the data to be
logged is some fixed size. Include a time stamp and perhaps some form
of checksum with the data. On power up read the SD card entries and
find the one with the newest date. The next entry is your current
write point. Just keep the write pointer in ram, no need to update the
SD card since you can always figure out the write point from the time
stamp. If the power fails and the write fails the crc will be bad
and the PC can detect this as well as your startup code. Your init
code will need to handle the case where you have a new SD card with
a fat file system or other unknown data on it and take necessary steps
to initialize the card to some known state for the circular buf.

[snip]

>
> --
> Silvar Beitel


--
Joe Chisolm
Marble Falls, Tx.
From: Silvar Beitel on
On Mar 24, 1:50 pm, Silvar Beitel <silverbee...(a)net1plus.com> wrote:
> Custom datalogger circuit using SD card, running on switched
> automotive power.
>
> It's cheerfully writing data to the card and the power quits (user
> turns key off, accidently pulls off power connector, engine stalls,
> car crashes, whatever - this could even be the preferred method for
> stopping it if it's robust). Up to three blocks worth of cached data
> need to be saved in the card (data block, FAT block, block w/
> directory entry) before the system can die cleanly.
>
> Easy solution if there's a connection to unswitched (battery) power
> too, but that makes using the device as a consumer plug-in impossible.
>
> So, you need some short-term energy storage.

Well, no you don't! :-)

Thanks for all the ideas. Taken together, a solution.

1) I don't absolutely have to have all the records up to the last
second, so a few corrupted or missing ones at the end is OK.

2) Along with an index number (in this case, time is an integral part
of the record so I can use that), inclusion of a check-sum or other
verification field can be used to find the end of good data (or at
least *an* end of good data, which is OK).

3) File system isn't absolutely necessary, but the above works with or
without one (I can pre-force the file size).

So now the thing doesn't need auxiliary power at all, a nice cost
savings. The startup code (and PC reader code) can use the same
mechanism for finding the end of stored data so that data logging can
continue when power returns (vehicle on - data logging, vehicle off -
not) and that happens automagically to the user.

(I don't really need a circular buffer - I'm not expecting any data
logging session to overflow the capacity of, say, a 1 GB SD card.)

Thanks again.

--
Silvar Beitel