>> 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.

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

"Al" <alnews67@hotmail.com> wrote in message
news:Xns95E4EC6009418alnews67hotmailcom@130.133.1.4...
> > I don't know quite why it is that set-top boxes are so poorly designed
> > as a breed. I've had cable units, satellite units, and (now) freeview
> > (terrestrial digital) set-top boxes - almost without exception [1],
> > they've been flaky as hell.
>
> Having designed (and tested) a few in my time, I've got plenty of excuses
> ;-)
>
> Three parts to STB software (OK, 4 then) ...

Thanks for the insight. It is as I feared ;).

> Not to worry, we can upgrade with an
> off-air download if anyone complains ...

Heh ;). It would appear that Nokia don't have a mechanism for handling such
complaints. I've certainly tried, and given up in disgust.

> Never mind, at least these guys don't design aircraft ...

Many thanks for pointing me at the bright side ;).

Steve
http://www.fivetrees.com

> I don't know quite why it is that set-top boxes are so poorly designed
> as a breed. I've had cable units, satellite units, and (now) freeview
> (terrestrial digital) set-top boxes - almost without exception [1],
> they've been flaky as hell.

Having designed (and tested) a few in my time, I've got plenty of excuses 
;-)

Three parts to STB software (OK, 4 then) ...

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

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

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 ...

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.

> I have a Nokia Mediamaster 221T freeview unit which is an extreme
> example. It's always been flaky, but since upgrading the firmware
> recently, it's become virtually unusable

Hehe. Good job you haven't got a Pace DTVA - That's a barrel of laughs. 
Not. The EPG has been broken since September. Runs out of memory gathering 
SI and crashes. Great. Who tested this particular crock one asks?

Never mind, at least these guys don't design aircraft ...

Al.

Trevor Barton wrote:
> What's with that?  I wonder how many people have taken them back "broken"?  
> They sit on top of the TV, where else do people keep the remote control 
> and TV guide?  Duh.  (well, ours are generally in the middle of the 
> floor, or under a chair, or down the back of the sofa, because we have
> kids).

Wow - an example where having kids _improves_ the reliability of
a consumer appliance ? :)
-jg

"Steve at fivetrees" <steve@NOSPAMTAfivetrees.com> wrote
> "Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote 
> > Poor software checks and methods, which to my 
> > mind is typical of bad desktop application 
> > programmers doing embedded work with an embedded 
> > version of the desktop OS.
> Agreed - that's absolutely my take too.

Ditto.  But then where would we be without clients?

-- 
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
Remove spaces etc. to reply: n o lindan at net com dot com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/

Steve at fivetrees wrote:
> I can't think of any other product where poor signal could be used as an
> excuse for system freezes. What *is* going on? Presumably the RTOS is using
> up all its cycles trying to derive a clean signal, to the extent that the
> unit crashes. How can this possibly be justified?

Wow ... that was quite a leap. It *must* be the RTOS ;-)

Surely it *is* a poorly designed system.

Having had some exposure to the CATV business, I have
to say that given:

o all of the requirements to prevent "content" from
   being "stolen",

o a hodgepodge of non-standard and standard protocols,

o a large number of closed source third party libraries,

o large teams of embedded software developers working
   on a "feature rich" product, and

o the usual "ship-it-tomorrow" management style of a
   highly competitive market

I am neither surprised nor impressed ;-)

-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

On Thu, 20 Jan 2005 12:12:36 -0000, the renowned "Steve at fivetrees"
<steve@NOSPAMTAfivetrees.com> wrote:

>"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
>news:20050120.1131.306100snz@pcserv.demon.co.uk...
>> Poor software
>> checks and methods, which to my mind is typical of bad desktop application
>> programmers doing embedded work with an embedded version of the desktop
>OS.
>
>Agreed - that's absolutely my take too.
>
><sigh>
>
>Steve
>http://www.fivetrees.com

Part of the downside of upgradable firmware too. If it had to be made
with mask ROMs with a 10 week lead time and a $xxxK minimum order
they'd be more likely to make it (more) right. 

Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

On Thu, 20 Jan 2005 10:17:25 -0000, Steve at fivetrees wrote:
> I don't know quite why it is that set-top boxes are so poorly designed as a
> breed. I've had cable units, satellite units, and (now) freeview
> (terrestrial digital) set-top boxes - almost without exception [1], they've
> been flaky as hell.
>
> I have a Nokia Mediamaster 221T freeview unit which is an extreme example.
> It's always been flaky, but since upgrading the firmware recently, it's
> become virtually unusable - it's been known to freeze (requiring a full
> power cycle) 4 or 5 times within 5 minutes. I've had discussions with Nokia
> about it via email, culminating in a phone conversation with a "support
> agent" just now - she tells me I live in a poor signal area (which is kinda
> true), and that a poor signal can cause the unit to freeze - a statement
> which I take as a stunning admission of failure on the part of the Nokia
> designers.
>
> [1] One exception: my daughter bought a no-name freeview box for &#4294967295;30 or so
> from a local dealer, expecting little from it - and it's been superb. It's
> not frozen once, and the picture is fine (theoretically poor signal
> notwithstanding). I bought the Nokia unit for about &#4294967295;130 (over a year ago,
> sadly) because I thought Nokia knew what they were doing. Hah.
>
> I can't think of any other product where poor signal could be used as an
> excuse for system freezes. What *is* going on? Presumably the RTOS is using
> up all its cycles trying to derive a clean signal, to the extent that the
> unit crashes. How can this possibly be justified?

We have a freeview box (mitsubishi?  somthing like that) which is OK unless 
you leave the TV guide on top of it, because that blocks the top ventilation
holes and the whole thing overheats and dies until it's been left unplugged
from the mains for five minutes or so.  Actually, it's worse than that,
because if you leave the remote control on it and only partially block
the holes, it still overheats.  Even in normal operation the case is
quite warm to the touch, and it stays warm when it's in standby.

What's with that?  I wonder how many people have taken them back "broken"?  
They sit on top of the TV, where else do people keep the remote control 
and TV guide?  Duh.  (well, ours are generally in the middle of the 
floor, or under a chair, or down the back of the sofa, because we have
kids).

-- 
Trevor Barton