@ mcalsyn - I guess there are several ways to compensate the limitations of the NETMF file System.
All I wanted to say is that writing logs to SD is not a trivial Task.
2 Likes
So, I needed to solve the logging problem for a couple different projects and this is what I came up with… This will all be packaged and published in nuget shortly. I will post here when it is available.
You can set the minimum severity to log:
You can establish categories (maybe you only want to log events in certain parts of your program) :
```cs]Logger.CategoriesToLog = (UInt32)(MyCategories.Comms | MyCategories.TempSensor);[/code
You can add listeners which record your events to memory, the network, Debug.Print, SD card or any combination.
```cs
Logger.AddListener(new DebugPrintListener());
Logger.AddListener(new SdCardListener( ... ));
And then you log like this:
That weird looking first arg is an event tag that just needs to be unique throughout your program. You can generate them manually, but I run a script that generates these as a pre-compile step. Also, used correctly, you should not include descriptive strings in your log events. They take up too much space. Instead, the pre-compile step generates a database of event tags and descriptive strings. The pre-compile step uses a least-flow algorithm so as not to change event tags once they are assigned so that your code does not churn needlessly in your source-code repo.
```cs
//Event: At time {0} There was an error reading sensor {1}. The error is {2}.
Logger.Info((AutoTag)0xcb35a25e, MyCategories.TempSensor, currentTime, sensorId, error);
The pre-compile code matches up event id’s with the comment on the preceding line. Then, by combining the database of event tags and messages with your event stream, you can post-process log events to get nice output. The events get logged in a more space and time efficient fashion and your compiled code is smaller.
Yes, this is a teaser, but I will post the nuget package and source code shortly.
[Modified to reflect some updates to the logger syntax]
7 Likes
Code and information on nuget package posted here : https://www.ghielectronics.com/community/codeshare/entry/1030
4 Likes
Having now gotten into sd operations, I can see what you are saying, though most of the volume inconsistencies that I have encountered are all explained by unwritten buffers. Flushing a file writes it’s content, but not the directory entry that points to that file. After calling VolumeInfo.GetVolumes()[0].FlushAll(); everything seems consistent. All of the anomalies I have experienced have occurred between making changes to the volume catalog and the next volume flush. Of course, you can’t go calling FlushAll all the time, but any SD app would seem to need UI to close open files, then force a flushall and then unmount the card before advising the user that it is safe to remove the card. Any other pattern seems to lead to potential file or volume corruption.
@ mcalsyn - That is exactly the problem. You can’t FlushAll all the time, because its not performant.
But without it, a sudden reset (happens a lot during development, and also from time to time in the field) can corrupt the file system.
During development you can fix it manually by plugging the SD card into a PC, but because it happens quite often this is time consuming.
In the field this might lead to a non functioning device, what is really, really bad. One of the benefits of µ-Controllers should be to allow a reset at any time, and then be ready again within seconds.
1 Like
Rgd. SD card filesystem instability and corruption: When is someone making a stable logger module with battery backup that cannot make this mess?
This looks really awesome, will investigate and try it out soon. Well done! Thanks Martin.