[ale] Wandering into the OT tar pit (was RE: Wanted: trivial minicom-type function)

[Christopher Fowler]

On Mon, 2006-03-13 at 13:33 -0500, Mills, John M. wrote:

> I've had a couple of cases where I straightened up a design as part of
> implementing one or a series of customer requests in a previously
> "standard" product. Another occasion is handing the mess off to a
> hapless colleague who is better off to re-do than to fix the ^&%(!!.
> (_NEVER_ with _my_ work, of course ... &8-)
> 

We've got some code that is a _mess_.  It all started with the same
statement that started this thread.  "If just need this feature and I'll
clean it up later...".  Now we've got working code but a mess.  It is
even so bad as there is no standard among the apps as to how they handle
data.  One may use strcat() to append to a string while one will build
the whole string with snprintf().  

Just tonight I added another module in the code and simply just copied
what was there.  There are no naming conventions either.  

So when we developed another item the question came up should we use
what we got and strip it or start from scratch.  I started from scratch
and basically it took me 3 weeks working about 10+ hours a day to get
the embedded device working right and clean.  The only problem with
starting from scratch is that I took a few roads that were dead ends and
had to back track.  Of course that is the nature of the game.

One problem I experienced in the past that was a bad idea is binary only
config.  We had many devices in the past use this method. It was
required on those devices with slow processors, anemic flash, and little
memory.  On this device we had a bit more room.  The problem with binary
config is that any additions or subtractions meant the previous version
of config was no good.  Very bad.  On that device we are at rev 7 and I
do not intend to see rev 8 :).  The reason why I brought up Mini-XML is
that I now use it on the new device to store the config in XML format
when not in use.  

XML -> struct {} -> Shared Memory.

save: Shared Memory -> XML -> Compression -> Encryption -> Flash. 

The benefit here is that I can throw more items in the struct and never
lose my original config.  Requires more cycles but works great.