Why are receivers so hard to program?

[AppliedAggression]

I have to ask, if newer receiversuse linux, then why are they so hard to program? What language is used?

I would figure that since the hardware is exactly the same, that it'll be a lot easier to program for than PCs which have many different configurations. That isn't the case, so I must ask, why are the newer linux receivers not as easy to program as computers are?

 

[James Long]

I have to ask, if newer receiversuse linux, then why are they so hard to program? What language is used?

I would figure that since the hardware is exactly the same, that it'll be a lot easier to program for than PCs which have many different configurations. That isn't the case, so I must ask, why are the newer linux receivers not as easy to program as computers are?

I wouldn't blame linux. Anyone can write a poor user interface on even the best platform.

I've had linux running on 'PCs' that were too slow to run Windows 98. linux is a nice base to work on, and can support a lot of hardware combination. It saves the hassle of writing your own operating system. Something to go between the program and the bits and pieces that make up a 'PC'.

JL

 

[AppliedAggression]

Oh believe me, I'm not blaming linux. I'm actually praising it. With an OS like linux it should be a lot easier to program for. Which is exactly what I don't get. With all the same hardware, how is it that there are bugs in some receivers and not in others. And why does it take them so long to fix them or add features. The receivers interface does not seem that difficult to program. Am I wrong? Is it more complicated than just simply programming something on a PC?

 

[Mike_H]

Integrating computer display technology with television display technology is significantly complex. Let alone supporting multiple output input/output streams yet ensuring a near real time operation for the user interface (i.e. record 2 independant HDTV streams while playing back 1 HDTV stream, and pop up a guide with a pip display). Then allow a layer of security and a high level of specialized hardware integration of which there may or may not be drivers already written.

 

[AppliedAggression]

So you're telling me it's more difficult to program a box that the hardware that is inside is known exactly, rather than programming something like SnapStream which the hardware varies?

Btw Snapstream for the PC is great PVR software with an awesome interface.

 

[mike123abc]

The satellite boxes also have the issue of hardware cards that are custom made and have their own set of bugs (er quirks). It looks like the 921 has some FPAs in it so they can rewrite some of the chip functions with updates. A lot of the bugs being seen are probably interactions between various boards and their drivers.

There is probably a high level system being used for the DVR functions, but it interfaces to a ton of device drivers.

 

[Mike_H]

What I'm trying to say (and doing so poorly) is that programming for descrete components is not the same as programming with high level languages on industry standard hardware. Keep in mind also that these systems need to operate in a real time situation. I'm not sure how they are managing that with Linux which, as far as I'm aware, does not have a real time version as of yet.

 

[cdru]

I'm not sure how they are managing that with Linux which, as far as I'm aware, does not have a real time version as of yet.

Actually, yes Linux does have a Real Time Linux. The entire system doesn't have to be truely real time. With specialized hardware and buffers, all you would basically would have to do is have some type of mechanizm to move data between the different subsystems (tuners, hard drive, decoders, program guide). But were're getting off topic.

You can't really compare a modern PC with a set top box. While both are a computer and have similar components, a PC will have significantly more power to throw at the problem. People expect to pay $1000 for a PC. They don't expect to pay $1000 for a receiver (921 crowd aside that is). Dish/DirecTV have to have just enough power to get the job done without having too much wasted. Wasted power means extra cost and lower margins. Changing one little thing in an embedded system can throw off the entire system.

 

[AppliedAggression]

Good responses. Thanks, it makes a lot more sense now. What language are some of the Dish receivers written in?

 

[Mike_H]

Most likely they don't use a language per say, but a development environment. Surely some of the 721 or other linux box stuff may be in C, but most is likely some sort of assembly or 4gl specfic to the hardware platform they use.

 

[Smith P.]

At least DVR921 software created using C/C++ and ASM - just take a look into LIBs.

 

[cdru]

I would say low level stuff like decoding and controlling hardware is in assembly. Higher level stuff hooks in to low-level asm code and adds in the program guide and menus. It's probably implemetned in lower high level language such as C or C++. You can probably safely rule out Java, Lisp, Pascal, and Cobol.

 

[bsic]

Platform and programming language are not the same thing. Linux is not "easier" per se than any other platform -- C is C, Perl is Perl, etc... The compiler for that platform is what "translates" the program to machine code.

Just because the platform is linux does not mean in any way, shape, or form that this makes programming harder or easier. My company ports its products to Opteron, IA32, Linux, SparcOS5, Sparc64... all from the same exact source code.

And dont begin to think that programming the UI for a set top box is EASY. Not by a long shot. As someone stated before this, the intricacies of AV processing is extremely complex, even if the hardware is in a static configuration.

 

[John Kotches]

cdru says:

You can't really compare a modern PC with a set top box. While both are a computer and have similar components, a PC will have significantly more power to throw at the problem. People expect to pay $1000 for a PC.

A receiver doesn't need the same amount of horsepower either. There are ASICs which do all the work. The ASIC is far more efficient at any given task than a general purpose computer.

However, ASICs aren't as flexible, which is one of the trade offs you make.

PeeCees require far more horsepower because they have a lot of overhead that an ASIC won't have.

Cheers,

 

[bsic]

cdru says:

PeeCees require far more horsepower because they have a lot of overhead that an ASIC won't have.

Absolutely true. PC's have only EIGHT general purpose registers (compared to >> 100 in more modern architectures, and many ASICs). Makes assembly code an absolute nightmare- this requires register-renaming and out-of-order execution functionality that has a huge overhead to implement "on a chip"... its very bloated circuitry and is usually the speed-limiter in CPU's

 

[James Long]

Just because the platform is linux does not mean in any way, shape, or form that this makes programming harder or easier. My company ports its products to Opteron, IA32, Linux, SparcOS5, Sparc64... all from the same exact source code.

The libraries would differ, unless you company builds operating systems too.

JL

 

[bsic]

LoL thanks justalurker. My point was as far as the program developer is concerned, the task of programming for linux when using, say, C as a language... isnt really true. A simpler OS architecture doesnt mean an easier C program to write.