Charles Bannister wrote:
-------------------------------
I read your response to and article in EDN and I can't understand what you are talking about. Can't you explane in simple language what you are trying to say? Also keep to the objective and don't let personal things get in the way by saying you are going to give this article the BOZO arward. Keep it simple and professional.

- - - - - - - - - - - - - - - - - -
The objective you advise me to "keep to" is of my own making, so how could I have diverged from it? I'm not writing an executive summary so I need not keep it simple and professional. I can keep it jargon-packed and irreverent. Also, while English is the predominant language of this forum, its not the first language of most participants, so simple language is a biased criteria and largely unattainable worldwide.

That being said, let's entertain the article issues for awhile:

WARNING! THIS IS A LONG FREE-FORM WRITEUP THAT MAY SHOCK THE SYNTAX SENSIBILITIES OF ENGLISH LITERATURE GRADUATES.

EDN ARTICLE SERVED A PURPOSE:
-----------------------------------------------
The EDN article was mentioned because it served one purpose: It introduces the concept of EEProm write-cycle lifetimes. I've twice written an explanation on this topic to people posing the question, "Can EEProm be used as RAM?" I recommend reading the article to illustrate the particular characteristics of EEProm that answer the question.

ENGINEERS CAN GET TOO INVOLVED SOLVING THE WRONG PROBLEM
-----------------------------------------------
Now, as to the author... it sounds like he got so caught up in solving his problem entirely within EEProm constraints that he missed the obvious proper solution. Did he miss it in his actual project or did he create this project to illustrate his solution? We can give him the benefit of the doubt, though I don't think he earns favorable probabilities.

However, it does illustrate something else common in engineering. That is the "engineer's trap" of becoming so involved in solving a particular defined problem that they waste time working it and fail to recognize the better solution. Is the defined problem the right problem?

RTC COMMONLY HAVE NONVOLATILE RAM - DUH
-----------------------------------------------
In this case the failure to recognize that common self-battery-powered RTCs have nonvolatile RAM perfect for storing long pointers into his EEProm datalogs.

Using a commonly available RTC with RAM for pointer storage, the pointer can address the very byte required for the next update. This avoids the block erase he suggests (halfs the required number of byte writes per datalog and hence doubles the lifetime). Additionally the rolling pointer scheme of 16 pointers becomes an unnecessary limitation upon the system.

OK LETS DROP THE RTC TO MAKE THE ARTICLE USEFUL
-----------------------------------------------
If we design his project omitting an RTC, then we have a situation for a rolling record and pointer system for which he writes. The author's linear thinking leads him to a comon definition that the next block must be cleared with the reserved byte 00 before anything is written to it so that the lower addressing can be deduced by the break in continuity.

Actually, a better technique is power up and fiind the next write location as the next/first 00 byte in the pointed block or page, and when writing the datarecord, merely concatenate a single 00 behind the last byte. If you write that byte first, before the datarecord, you are less vulnerable to losing sync should power fail or be switched off during the write operation. Since we're talking about fixed-length records (which I consider highly inefficient) the next starting point can always be found when the micro powers up again. This still takes 2 writes for each record, one for the marker and then one for the later datarecord overwrite of that marker.

The suggestion to erase the entire block is unnessary and only safe with a single block erase command. If its done in a simple loop, you have to deal with the case when power goes away during the middle of the block erase. Does the code sense the first is erased and assume the entire block is? Does it know how to deal with running into the unerased block? These are often considered to be bugs of unknown origin but are just caused by carelessness and not thinking through what was assumed to be trivial. I doubt the author gave the block erasure any thought. Beware of assuming something trivial.

FIXED LENGTH RECORDS ARE FOR AMATEURS - RTC REVISITED
-----------------------------------------------
Now, shall we talk about compressing his datalogs? Figure 2 looks like a byte-for-byte dump of the RTC registers. Considering that he is timestamping via the RTC at one second intervals, he's waisting EEProm space incredibly.

I understand that he expects units to only be powered up 8 hours a day and thus they are apparently want time discontinuities to be represented by the traversing datarecords to find the disjoint time. His simple system achieves that.

Lets give the datarecords a payload to make it more interesting. Lets say each event measures an ADC to a 2 byte value.

Instead of using a fixed length records with a timestamp for each record, I'd get into Microsoft Excel and investigate the expanded memory capacity by using a simple enhancement and charge the customer for the memory enhancement (heheeh, using the same chip).

GET ALMOST THREE TIMES THE STORAGE IN THE SAME CHIP EASILY
-----------------------------------------------
If you allow a small level of complexity over the fixed length datarecords to the following, you'll get a significant boosting of storage.

Using Pareto Ordering, (do first that which improves things most) redefine your datarecord as one timestamp of prevous form (I won't bother compressing it here) and then 60, or 120, or 300 datapoints, each added during subsequent seconds. Since the author current throws away four bytes for timestamp for every datapoint, the savings or extension to memory storage are easily computed. Assuming the datarecord payload was a 2 byte ADC value, switching to one timestamp every five minutes, changes the memory required from 5*60*(4+2)=1800 bytes to 4+(5*60*2)=604 bytes. You've almost tripled your storage and you've reduced the time spent writing to the EEProm. Statistically you've also reduced by a factor of 300 the chances of getting glitched in the middle of a RTC timestamp datarecord write.

Note that a powerdown withing the 5 minute interval causes no problems because the 00 marker (if not using RTC RAM) still marks the break after the last valid datarecord.

DON'T THINK NICE ROUND NUMBERS JUST BECAUSE YOU'RE HUMAN
-----------------------------------------------
There is no need to powerup and wait for an even minute boundary before writing either. Its just as valid to timestamp [15:23:43] and later [15:28:43] as nice round numbers.

Of course we are talking about the images inside the EEProm. How we report that information through a datalink for printout or analysis later, can be in a time formated form. You have to write your routines for taking raw time into human time and that includes leapyear, newyears rollover, military time and daylight savings time if you know your business. These are not that difficult; the hardest thing was finding out daylight savings time (non)standards in the US. Searching the web CAN uncover this. As I recall, Arizona and parts of Indiana don't use daylight savings time. The days to switch forward and backwards I found buried on a Federal Trade Commision (FTC) homepage after much looking.

INTERNAL TIMESTAMP FORMAT
-----------------------------------------------
Personally, I prefer to convert RTC register images into raw form, multibyte seconds or milliseconds from a date reference depending upon the application. That way adding a second, day or whatever is an simple multibyte addition/subtraction and the data is compressed well enough when timestamped one for many records. Internally, using a raw form for time makes things easier until you eventually have to export or display the data. Supporting all the time formats previously mentioned, you'll have to invest the time to do this anyway and its not much harder than dealing with the RTC register form.

TIMEOUT
-----------------------------------------------
Oh well, enough of this for now. If I talk anymore on this topic now I'll have to write some firmware. Come to think of it, I will be writing some new datalogger datastructure soon for EEProm.

aka J --- been there, done that