Re: Help required

larwe wrote:
Isaac Bosompem wrote:

You haven't lived until you've debugged code like this (there are NO
errors on my part in this code, it's pseudo representation of ACTUAL
code I've been called upon to fix in the past):

What the hell is that code supposed to do? That is just downright nasty

I'm still not entirely sure. I mean, what do you do - besides maybe
resign - when you see a piece of code with comments and structure like

if (flags && FLAG_1) // is FLAG_1 clear?

// select thing to do based on FLAG_1
if (flags & FLAG_1)
else if (flags & FLAG_1)

special_setting = 0x80; // uint8_t type
special_setting = special_setting << 1; // multiply by 2 for louder

// do things 123 times
for (i=0;i<123;i++);

Reminds me of some C code on the internet that I saw in which someone
decided to use a base 2 log to determine if a bit in a variable was
set!! I mean, why do these complicated things if there is a much
easier, simpler (and MUCH faster) way to accomplish it?

(those errors are not typos - at least not on MY part). And since there
is no written specification for the product, the only way to "debug" it
is to go to the QA department and ask them to demonstrate how a similar
product ("gold standard") that made it through QA some years ago

You then go back to your computer armed with some guesses as to what a
few of the comments mean, and perhaps some info from the QA tech about
the history of a few behaviors, to give you a clue as to the cryptic
tangle of special-case code.

Timers never initialized. Timers initialized with magic numbers based
on obsolete clock module settings, leading to bizarre race conditions
and out-of-spec communications. Watchdogs turned off with comments that
the unit inevitably resets if the WDT is enabled. A structure that's 32
bytes long being written to nonvolatile memory with code like this:

yikes, I never knew anyone that would not use a device simply because
it served its purpose.

write_eeprom(&structure, 67); // structure is 67 bytes long
and worse, read back to RAM with:
read_eeprom(&structure, 117); // structure is 117 bytes long

(as it happens, by amazing total whacked-out luck everything in the
100-odd bytes after "structure" in RAM just happens to be noncritical).

Again, you'd think people would not do things like this to make
debugging easy. I just cannot imagine why something like you described
above would be a good idea.

Oh, and I forgot to mention that "structure" is not actually a
structure, it is just a pointer to a variable named, say, fred - the
code RELIES ON THE FACT that fred is followed in RAM by a few other
variables that need to be saved to EEPROM - never mind the fact that
they are all in different object files and there's no explicit linker
setting made to put those variables in the right place (and not even a
comment in the source saying "don't add variables here"). Probably the
67 and 117 "sizes" were calculated by the difference in address between
(first variable of interest) and (last variable of interest) in some
specific build(s).

Reminds me of some Amiga based code I was reading about in which a demo
programmer (using I think a loader) overwrote some critical OS data
structure and still managed to run without a hitch!! Perhaps he should
take a shot at the slot machines ;).
I could go on and on like this for hours. I never thought of the
logical operators in C as weapons of mass destruction, but this
person's coding proves it to be the case. People have been executed for
lesser offenses than all this. The thing you don't see is that 80% of
these errors are buried in code paths that never get executed because
of code like this:

if (!something)
something = FALSE;
if (something) { // doubly impossible to reach this point
You'd think that the developers working on this stuff would go out of
their way to make debugging the firmware of these products much simpler
and easier, rather than obfuscating simple logic testing structures
like that!
How do they debug code like that?!

way of coding. I don't know if the person who wrote that was still
working there when you were called upon to fixed the code, I would

Yes. But that person can't answer the question either. It needs more
than a seminar to fix; I think electroconvulsive therapy might be the

hahaha, It might do everyone else some good too.

Also Akshay, you can basically take the examples Iarwe posted as
pitfalls to avoid when coding for an embedded system. Not only will you
save yourself headaches and stress, you will have a lot more fun doing
your project :).