Hardware And Firmware

[meadish_sweetball]

Most electronic gadgets run their own operating system, which is called firmware. This can often be upgraded to newer versions.

My question is, how do the hardware developers know that their hardware is going to work unless they have developed their own firmware to test things? And if they have, howcome so many gadgets are sent to consumers with inferior, buggy firmware these days - for example mobile phones and routers, to mention but a few.

Would it not be smarter to just use the same firmware the manufacturer used when testing the gadgets? Or is there something flawed in my reasoning?

[kelvinj]

Any gadget using firmware is microprocessor based, the microprocessor will have an instruction set associated with it i.e. it's own programming language. The manufacturer of a gadget, has to write an operating system of his own which is specific to the application, this is called firmware. Microprocessors are used in everything from washing machines to communication sattelites, I think you'll find that the prgrammes ( firmware ) in the sattelite are more complex than the programme in the washing machine.

For testing purposes the microprocessor manufacturer will write a diagnostic program, this is a specific application, it's of no use for any other purpose.

[meadish_sweetball]

Thank you kelvin, that clears up a bit even though I am still a bit confused in that I assume that if a diagnostics program manages to test all possible functions of a microprocessor, or chipset, then how come so much firmware is full of bugs?

Is it the graphics part in a graphical user interface that causes most bugs?

My DVD player, for example, uses a chipset that can read several different movie formats, and rarely will it freeze or cause me any trouble - if it cannot do something, it usually just tells me so. But my PDA phone that, admittedly, tries to do a lot more than the DVD player, keeps freezing and acting up.

[endure]

Because to test anything other than trivial software costs a lot of money. It depends on what the gadget is going to be used for. If you're designing a microprocessor that going to sell in the millions and on which other machines are going to rely you put a lot of effort into debugging it. If you're designing the navigation system for an A380 ditto. A 5000bt mobile is not as critical. Don't forget that firmware updates often add extra features as well as sorting out bugs.

[paulfr]

One of the reasons you see so many buggy SW designs is the pressure to get to market fast.

The engineers always want more time to test and the marketing guys want to release to manufacturing and sell now.

Another point a layman may not appreciate is how many different states a system

can have. Every clock pulse puts the system in a new state and this must be tested for

every possible next state. Almost statistically impossible to test every possible "state space".

Finally there is the logistics of team SW design. There are usually 3 to 25 SW engineers all

working on different pieces of code. Putting each of the versions of the individual modules

together yields a different overall SW design that needs testing. The next change of any module

can take a stable system and make it buggy.

[endure]

Anyone interested in the process of computer design might want to try and get hold of a (fairly old) book called 'The Soul of a New Machine' by Tracey Kidder. It tells the story of Data General's attempts to design a rival for the DEC VAX. Yes, I know that's ancient history but it's brilliant illustration of all the problems of hardware/firmware/software design.

[kelvinj]

Thank you kelvin, that clears up a bit even though I am still a bit confused in that I assume that if a diagnostics program manages to test all possible functions of a microprocessor, or chipset, then how come so much firmware is full of bugs?

Is it the graphics part in a graphical user interface that causes most bugs?

My DVD player, for example, uses a chipset that can read several different movie formats, and rarely will it freeze or cause me any trouble - if it cannot do something, it usually just tells me so. But my PDA phone that, admittedly, tries to do a lot more than the DVD player, keeps freezing and acting up.

The dianostic programme will test the microprocessor functions, it's the end user that writes the firmware, it's his responsibility to properly test and debug the code. A complex piece of firmware will have many thousands ( millions? ) of lines of code, it's simply not possible to predict every single combination of events that a complex system will encounter and therefore not possible to test for correct handling of them by the firmware.

I spent 30 years mainting mainframe computer systems, a large part of the workload was updating firmware to deal with problems encountered in the field which had not been foreseen in the factory. This is not due to incompetence in the factory, just the enormous number of permutations of events in a complex software environment.

[Crushdepth]

Fact is that not much attention is paid to quality control of firmware, drivers and utility programs that accompany consumer electronics and bits of hardware. There's no good reason for it, its just poor practice.

[jstumbo]

Spending several years at Microsoft as a Software Tester and Lab Manager, I see this all the time. When it gets closer and closer to the scheduled ship date, you start having meetings to figure out which bugs you can fix, which you do not have time to fix and which ones that you will not fix even if you did have the time.

When you make changes, it restarts the testing all over to make sure the fix did not break anything else. So at some point you say that a bug is not serious enough to fix and cause the delay. You figure you will fix it at a later date and maybe put it into a service pack.

I remember one time when I was working on the webserver software and we had a problem were the service that would send out targeted email would hang after a certain number of emails were sent. Many developers tried to fix it, and we never could really figure out why it was doing it. The final solution was to just keep track of the number of emails that were sent and then when it reached a number that was lower than the number where it would hang, it would stop the service and restart the service. All fixed.