Erik,

Thanks for the reply. I apologize for the delay in responding (Friday off & the Labor Day holiday).

>The ONLY non-convoluted use of a circular buffer is ...
Since no one else has replied on the terminology it seems the best term for now is to call it a (convoluted) circular list.

>So, if you want to "update an occurence count" you do not "update" it, you just write the new count.
The idea we had was instead of logging (adding a new entry to the list) a frequently occurring error each time it happened, we might instead simply update the occurence count if we find that the particular error has occurred before. The benefit of course being that if we start encountering an error type that is very frequent we won't be using up lots of space to store that fact.

>>e.g. displaying only a screenful of entries somewhere in the middle of the list
>I do not see where your application would want to do so.
The idea here was to make the current contents of the error log visible to the user. When the user selects the "display log" option, the contents of the log would be displayed with the most recent first (reverse order). The user could then scroll down as far as desired, all the way to the start (head) of the list. Basically I'd like to be able to operate on a subsection of the list for displaying (read) even though the list is truly maintained as a circular buffer (writes).

>solutions
>1) as far as I can see the only thing you have that really warrants a circular buffer is the error logging. If so, why not store the rest in fixed locations and have a circular buffer for error logging only.
I'm not sure what you mean by the "rest" here. Basically what I've implemented (and looking for advice on) is a EEPROM based logging system consisting of a (convoluted) circular list of error entries and a header (head pointer, tail pointer, misc.) stored separately in the EEPROM in a fixed location. Is that the type of solution you mean?

>or
>2) make all records the same length
For now the records (entries) are the same length, but we are considering making them variable length based on the first byte of each record.

>or
>3) start all records with a "record mark" and when reading from the write pointer ignore info till a record mark is found.
I'm a little hazy on how this solution works and what the benefit is.

>Erik

Regards,
Jeff