1. You know how to get debugging messages out of the system during development. Otherwise countless nightmare will wait for you.
2. Always place a "failsafe" code inside your brand new code so that the system would always recover to a point where you would be able to restore the system back to previously known working condition.
Now, let me explain point 1. Because not all embedded system contains a display, the debugging messages usually forwarded to an UART. The reason is simple, UART is a very simple digital device to initialize. In present day x86 systems, UART usually resides in the SuperIO chip or in the southbridge chipset. A display is far more difficult to initialize compareed to UART and sometimes does not available in the target system. By using an UART, it is also easier to do debugging once the system is deployed.
Let's move to point 2. In some systems, you have to remove some sort of flash chip and flash it somewhere else to recover from a bad software. Therefore, in order to reduce the hassle, it's better to provide "failsafe" code whenever possible.
Post a Comment
2 comments:
Mr. Salihum,
I was taking a look at your March 7th post and I completely agree with your points. However, since my background is electronic hardware with (what I call "limited") experiance on firmware, would you care to go into point number two a bit more? I understand that some flavores of BIOS have such a failsafe built in, now depending on the apliocation. I think that as I complete my CS degree and head back into the world between software and hardware (BIOS and enbedded design), building failsafes into all of my BIOS's would allow me less worry as I tinker with them. How would you go about designing a failsafe into existing BIOS, to be flashed back into the chip? By the way, any plans on selling softcopies of your book? :) Thank you for your time.
-Ross
failsafe for "legacy" BIOS exists as boooblock recovery code.
Post a Comment