Roger Ivie wrote:> >On 2005-02-10, Guy Macon <_see.web.page_@_www.guymacon.com_> wrote: >> >> Neil Kurzman wrote: >> >>>1. Crashing is always a software problem. >> >> Only if you define "crashing" as a subset "software problem." >> >> Your code can be perfect, but if the crystal oscillator stops >> it *will* crash. > >No it won't; it just won't get anywhere. > >I mean, even if the DRAM disappears because it's not getting refreshed >anymore, the software won't crash because time has stopped. It's frozen.Like I said, only if you define "crashing" as a subset of "software problem." If you *by definition* say that only software problems are crashes, then you can of course conclude that only software problems are crashes - a tautology. If you define crashing as a certain class of undesirable system behaviors (as I do), then it doesn't matter whether the described behavior is caused by an infinite loop with interupts turned off or a bad RAM chip.
Self restarting property of RTOS-How it works?
Started by ●February 7, 2005
Reply by ●February 10, 20052005-02-10
Reply by ●February 10, 20052005-02-10
"del cecchi" <dcecchi.nojunk@att.net> writes:>Like hardware doesn't have bugs or "errata". Go check Intel's web site.Yeah, let the software guys figure out how to work around it :-) It does point to one thing: hardware errors are really hard to fix you need to ship new, physical, product. Software can be fixed after it was shipped at little extra expense for the manufacturer (but potentially a lot for the customer). Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
Reply by ●February 10, 20052005-02-10
Casper H.S. Dik wrote:> > It does point to one thing: hardware errors are really hard to fix > you need to ship new, physical, product. Software can be fixed > after it was shipped at little extra expense for the manufacturer > (but potentially a lot for the customer).Therefore, it would be foolish, from a business point of view, to build software to the same standards of correctness as hardware. And sure enough, it doesn't happen. Whether software companies are getting the cost/quality balance right is debatable, but the idea that they should aim for the same balance point as hardware companies is surely wrong.
Reply by ●February 10, 20052005-02-10
In article <110m9m2a0lrusd8@corp.supernews.com>, _see.web.page_@_www.guymacon.com_ says...> > Roger Ivie wrote: > > > >On 2005-02-10, Guy Macon <_see.web.page_@_www.guymacon.com_> wrote: > >> > >> Neil Kurzman wrote: > >> > >>>1. Crashing is always a software problem. > >> > >> Only if you define "crashing" as a subset "software problem." > >> > >> Your code can be perfect, but if the crystal oscillator stops > >> it *will* crash. > > > >No it won't; it just won't get anywhere. > > > >I mean, even if the DRAM disappears because it's not getting refreshed > >anymore, the software won't crash because time has stopped. It's frozen. > > Like I said, only if you define "crashing" as a subset of "software > problem." If you *by definition* say that only software problems are > crashes, then you can of course conclude that only software problems > are crashes - a tautology. If you define crashing as a certain class > of undesirable system behaviors (as I do), then it doesn't matter > whether the described behavior is caused by an infinite loop with > interupts turned off or a bad RAM chip. >Let me add another example of a HW problem leading to a crash. Putting a quickly re-occuring interrupt on the NMI input. If an interrupt burst lasts long enough it will bring the micro to a halt. Even a short burst can cause a large stack depth as context is save repeatedly overwriting areas of memory used by other parts of the program causing problems later in execution. I'd call that a crash and it's not solvable in software. There are a number of harware solutions of greater and lesser acceptability. Robert
Reply by ●February 10, 20052005-02-10
Ken Hagan wrote:> >Casper H.S. Dik wrote: >> >> It does point to one thing: hardware errors are really hard to fix >> you need to ship new, physical, product. Software can be fixed >> after it was shipped at little extra expense for the manufacturer >> (but potentially a lot for the customer). > >Therefore, it would be foolish, from a business point of view, to >build software to the same standards of correctness as hardware. >And sure enough, it doesn't happen.I disagree on both counts. Software *on a PC* can be fixed after it ships, but PCs are only a small but visible part of the total worldwide production of computer hardware/software. I have produced toys that sold more units per year than all the PC manufacturers combined, and the software was in masked ROM. It was also built to the same standards of correctness as the hardware. Over on the other end of the price/quality spectrum, I have worked on aircraft parts, and here too the software was built to the same standards of correctness as the hardware. This is true of nearly all embedded systems. -- Guy Macon <http://www.guymacon.com/>
Reply by ●February 10, 20052005-02-10
Guy Macon <http://www.guymacon.com/> writes:>>Therefore, it would be foolish, from a business point of view, to >>build software to the same standards of correctness as hardware. >>And sure enough, it doesn't happen.>I disagree on both counts. Software *on a PC* can be fixed after >it ships, but PCs are only a small but visible part of the total >worldwide production of computer hardware/software. I have produced >toys that sold more units per year than all the PC manufacturers >combined, and the software was in masked ROM. It was also built >to the same standards of correctness as the hardware. Over on the >other end of the price/quality spectrum, I have worked on aircraft >parts, and here too the software was built to the same standards >of correctness as the hardware. This is true of nearly all embedded >systems.There's no proof that embedded systems are not engineered to a higher standard; I'm certain they are (well, not for small household electronics things or not even cars; I've encountered bugs in all of my embedded electronics devices, including my car, tvs, dvd player, etc) Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
Reply by ●February 10, 20052005-02-10
Ken Hagan wrote:> Casper H.S. Dik wrote: > >> It does point to one thing: hardware errors are really hard to fix >> you need to ship new, physical, product. Software can be fixed >> after it was shipped at little extra expense for the manufacturer >> (but potentially a lot for the customer). > > Therefore, it would be foolish, from a business point of view, to > build software to the same standards of correctness as hardware. > And sure enough, it doesn't happen. > > Whether software companies are getting the cost/quality balance > right is debatable, but the idea that they should aim for the same > balance point as hardware companies is surely wrong.That's why the historical succession from masked ROMS to PROMS, EPROMS, EEPROMS, flash, etc. is important. They all eased the fixing process. Another similar area is PLAs replacing random wired logic. -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson
Reply by ●February 10, 20052005-02-10
del cecchi wrote:> > Like hardware doesn't have bugs or "errata". Go check Intel's web > site. > > Especially new hardware. sheesh >First of all, I dare to say this kind of hardware is mostly if not totaly software as these processors are synthesized from (Verilog? VHDL?) building blocks. Therefore some or most of software engineering applies I guess. I think Ganssle meant much more the mindset than the knowledge/expertise area itself. Hardware design and development also carries its own set of "bugs" and bad practices though (I wonder how many engineers design based only on components typical figures.) Regards. Elder.
Reply by ●February 11, 20052005-02-11
Hi, Thanks for your reply.My inference from your reply is that better avoid using taskrestart when working on critical areas and use it only on noncritical tasks. But only one doubt reminds still to me: I agree that its not possible to resume a task,when it crashes.But when I restart it,How do we make sure that we are in synch with the current status of the application,the same dosage problem as stated in your posting?What if the task which is restarted requires a semaphore or a message which is held by some other task at the time of restarting?How do we make sure that the application reaches safely with out causing any trouble to the current situation? Regards, s.subbarayan
Reply by ●February 11, 20052005-02-11
