Nokia set-top box: example of *dreadful* embedded design

having my share of experience in doing this type of thing...

> Drivers - Generally the best parts of the software (if written by 
> professionals!). Fast, efficient, they work.

actually, this is the hard part.  companies like ST (when asked, say
they only make hardware, not software; or if asked on a different day,
only make software, not hardware) put out "demo" code for their chips
which is a large package of software.  these code drops, aside from
being #ifdef'd for years and years to support every chip ever made
and every errata ever encountered, are usable in general for okay
performance.  until you hit that corner case.  and then it's game over.

most of the really solid STBs and IRDs i've seen rewrite the entire
chipset code from the ground up.  problems also lie with conexant chips,
for example, that have special DSP-like or reprogrammable codec-cell
structures that you have to load a "firmware" into.  i saw one project
languish in the fun of instability for a long time before one chip
company said, "oh, hold on, we compiled that for the wrong configuration!"
when the new release arrived, all was well.

so, drivers you take with a grain of salt.  especially if you're 
foolesh enough to believe the "reference" code provided by the
chipset vendor.  and of course, that "we have 6 weeks to make this 
work" factor creeps in here.  because the code that ran just fine
on the 4744 should just need a tweak or two to run on the 4754, right?

> Middleware - Mostly utter garbage. No, really. Which means that the 
> application layer is in trouble before it even starts ...

this is the part i see most often written by those with the least
experience, where the senior developers spend their time trying to
understand why that function takes 50 arguments but only received
40 and the compiler didn't complain... or why i can pass a string to
an int and not get a warning/error...

> App layer - Often poorly written by college grads being paid sixpence per 
> hour. Usually then hacked by more senior engineers to get around the faults 
> in the middleware. Doomed to failure. Not to worry, we can upgrade with an 
> off-air download if anyone complains ...

heh.  don't forget those handy utilities that they write to convert
from one code type to another, never document, and promptly leave for
some other job... leaving the main team with fragile support tools
that are poorly understood.
 
> Not forgetting the good old bootloader - This is the bit everyone hates to 
> write or maintain - No fame, no glory. Often just a hacked set of drivers 
> done by the most junior member of the team. And boy, does it show.

this can be the most fun.  it's also the part where you spend all your
time on the phone with the hardware part makers finding out that "oh,
chip R1-AB/D-V7 has this special bug, you need to do <xyz> to work
around it.  and no, it's not in the errata.  sorry."

-j

>> Drivers - Generally the best parts of the software (if written by 
>> professionals!). Fast, efficient, they work.
> actually, this is the hard part.
> until you hit that corner case.  and then it's game
> over.

Unless they are written by *professionals*. Chipset manufacturers haven't 
got a clue. I used to make a very decent living from writing drivers that 
actually worked! ;-)

>> Not forgetting the good old bootloader - This is the bit everyone
>> hates to write or maintain - No fame, no glory. Often just a hacked
>> set of drivers done by the most junior member of the team. And boy,
>> does it show. 
> this can be the most fun.

Your idea of 'fun' is slightly displaced from mine ;-)

> "oh,
> chip R1-AB/D-V7 has this special bug, you need to do <xyz> to work
> around it.  and no, it's not in the errata.  sorry."

Ah. A kindred spirit!

I gave up on dealing with this sh1t a few years ago. I'm too old and wise 
to deal with the same mistakes on every contract that I do these days ;-)

Nice reply Josh - I'm glad I'm not alone!

Al.