Greetings,

I want to add error logging to a system. Due to space restrictions I can only log binary messages, say 1 byte for the error code and a variable number of bytes for the payload. 

Is there an example out there of such a system? The messages need to be buffered as the log messages would come from time critical routines, and then read out by a low priority task & written to Flash.

TIA

<c...@gmail.com> wrote in message 
news:4...@googlegroups.com...
> Greetings,
>
> I want to add error logging to a system. Due to space restrictions I can 
> only log binary messages, say 1 byte for the error code and a variable 
> number of bytes for the payload.
>
> Is there an example out there of such a system? The messages need to be 
> buffered as the log messages would come from time >critical routines, and 
> then read out by a low priority task & written to Flash.

That's the way we do that in our RTOS. Any task could write a message to 
common FIFO list. Message coud be an object of any kind. When message is 
written to FIFO,  task id and time stamp added to it automatically. 
Dedicated low priority task reads from FIFO and writes to log file. The file 
is clipped to max. length. The events of FIFO overflow are recorded also.

Vladimir Vassilevsky
DSP and Mixed Signal Consultant
www.abvolt.com
 

On Sunday, October 7, 2012 4:02:16 AM UTC+11, Vladimir Vassilevsky wrote:
> <c...@gmail.com> wrote in message 
> 
> news:4...@googlegroups.com...
> 
> > Greetings,
> 
> >
> 
> > I want to add error logging to a system. Due to space restrictions I can 
> 
> > only log binary messages, say 1 byte for the error code and a variable 
> 
> > number of bytes for the payload.
> 
> >
> 
> > Is there an example out there of such a system? The messages need to be 
> 
> > buffered as the log messages would come from time >critical routines, and 
> 
> > then read out by a low priority task & written to Flash.
> 
> 
> 
> That's the way we do that in our RTOS. Any task could write a message to 
> 
> common FIFO list. Message coud be an object of any kind. When message is 
> 
> written to FIFO,  task id and time stamp added to it automatically. 
> 
> Dedicated low priority task reads from FIFO and writes to log file. The file 
> 
> is clipped to max. length. The events of FIFO overflow are recorded also.
> 
> 
> 
> Vladimir Vassilevsky
> 
> DSP and Mixed Signal Consultant
> 
> www.abvolt.com

Thanks Vladimir, at least I know that I am on the right track. The FIFO has to be able to handle overwrites in the occasional case where the reader cannot keep up with the data. I was thinking of including an auto-incrementing  sequence number with every message, so that if messages were dropped the fact would be apparent as there would be a jump in the sequence numbers.

On 2012-10-07, c...@gmail.com <c...@gmail.com> wrote:
>
> Thanks Vladimir, at least I know that I am on the right track. The FIFO has to
> be able to handle overwrites in the occasional case where the reader cannot
> keep up with the data. I was thinking of including an auto-incrementing 
> sequence number with every message, so that if messages were dropped the fact
> would be apparent as there would be a jump in the sequence numbers.

Just as a suggestion, perhaps you should drop data instead of overwriting
existing data when the FIFO is full.

I've found that recording the start of a set of errors instead of the end
of a set of errors usually helps me identify the triggering event for the
errors more easily.

Simon.

-- 
Simon Clubley, c...@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

I've done something similar in the past to log input and output data for a
particular task (that I was responsible for) within an embedded system. I
had a small buffer that would be periodically flushed when reasonable,
appending to a log in a filesystem (it wasn't until the advent of an
onboard sort of general-purpose filesystem that this became feasible).

The end result logged days/weeks of data that until then were somewhat
theoretical, and being able to record the progress of the system *in
real-world use* was a real eye-opener. Whenever a problem was reported, I'd
send instructions of how to enable the logging and get a log back in return
that told me everything I needed to know. It reduced the ambiguity to zero,
and cut the number of problems (typically misconfigurations by a given
product team) that ended up shipping in the final product to a tiny
fraction of what they were.

Fun times. Anyway...

>On 2012-10-07, c...@gmail.com <c...@gmail.com> wrote:
>
>Just as a suggestion, perhaps you should drop data instead of overwriting
>existing data when the FIFO is full.
>
>I've found that recording the start of a set of errors instead of the end
>of a set of errors usually helps me identify the triggering event for the
>errors more easily.

I'd definitely second this for an error log. For other types of logging,
perhaps not so much, but I've also found that it's often more instructive
to see where an error began rather than to see the tail end of all the
fallout.

It's also far simpler to just stop adding records to a buffer and record
that an overrun occurred than to maintain a circular buffer and have to
worry about overwriting records at the head of the list.

Besides, this is a last-ditch fail-safe operation. In reality, you'll
probably end up selecting a buffer size that won't overflow under normal
(or even most abnormal) circumstances.	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com