Groups | Search | Server Info | Login | Register
Groups > comp.arch.embedded > #32215
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Diagnostics |
| Date | 2024-10-12 12:58 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <veekcp$9rsj$1@dont-email.me> (permalink) |
Typically, one performs some limited "confidence tests" at POST to catch gross failures. As this activity is "in series" with normal operation, it tends to be brief and not very thorough. Many products offer a BIST capability that the user can invoke for more thorough testing. This allows the user to decide when he can afford to live without the normal functioning of the device. And, if you are a "robust" designer, you often include invariants that verify hardware operations (esp to I/Os) are actually doing what they should -- e.g., verifying battery voltage increases when you activate the charging circuit, loopbacks on DIOs, etc. But, for 24/7/365 boxes, POST is a "once-in-a-lifetime" activity. And, BIST might not always be convenient (as well as requiring the user's consent and participation). There, runtime diagnostics are the only alternative for hardware revalidation, PFA and diagnostics. How commonly are such mechanisms implemented? And, how thoroughly?
Back to comp.arch.embedded | Previous | Next — Next in thread | Find similar
Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-12 12:58 -0700
Re: Diagnostics antispam@fricas.org (Waldek Hebisch) - 2024-10-18 20:30 +0000
Re: Diagnostics George Neuner <gneuner2@comcast.net> - 2024-10-18 17:42 -0400
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-18 15:30 -0700
Re: Diagnostics antispam@fricas.org (Waldek Hebisch) - 2024-10-19 01:50 +0000
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-18 19:38 -0700
Re: Diagnostics antispam@fricas.org (Waldek Hebisch) - 2024-10-19 03:53 +0000
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-18 21:17 -0700
Re: Diagnostics antispam@fricas.org (Waldek Hebisch) - 2024-10-24 17:52 +0000
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-24 14:49 -0700
Re: Diagnostics David Brown <david.brown@hesbynett.no> - 2024-10-19 14:07 +0200
Re: Diagnostics George Neuner <gneuner2@comcast.net> - 2024-10-19 15:25 -0400
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-19 14:32 -0700
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-23 05:53 -0700
Re: Diagnostics Nioclásán Caileán de Ghlostéir <Master_Fontaine_is_dishonest@Strand_in_London.Gov.UK> - 2024-10-20 19:15 +0200
Re: Diagnostics antispam@fricas.org (Waldek Hebisch) - 2024-10-19 01:25 +0000
Re: Diagnostics David Brown <david.brown@hesbynett.no> - 2024-10-19 13:57 +0200
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-18 15:15 -0700
Re: Diagnostics antispam@fricas.org (Waldek Hebisch) - 2024-10-19 03:00 +0000
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-18 21:05 -0700
Re: Diagnostics antispam@fricas.org (Waldek Hebisch) - 2024-10-19 13:53 +0000
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-19 09:55 -0700
Re: Diagnostics antispam@fricas.org (Waldek Hebisch) - 2024-10-24 16:34 +0000
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-24 14:28 -0700
Re: Diagnostics George Neuner <gneuner2@comcast.net> - 2024-10-19 15:58 -0400
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-19 16:26 -0700
Re: Diagnostics Nioclásán Caileán de Ghlostéir <Master_Fontaine_is_dishonest@Strand_in_London.Gov.UK> - 2024-10-20 20:08 +0200
Re: Diagnostics Nioclásán Caileán de Ghlostéir <Master_Fontaine_is_dishonest@Strand_in_London.Gov.UK> - 2024-10-20 19:11 +0200
Re: Diagnostics George Neuner <gneuner2@comcast.net> - 2024-10-20 15:44 -0400
Re: Diagnostics Nioclásán Caileán de Ghlostéir <Master_Fontaine_is_dishonest@Strand_in_London.Gov.UK> - 2024-10-20 23:14 +0200
csiph-web