Some things have to run continuously, with microsecond response to inputs, so can't be periodically reset. Most of my products have long startup times, too, as long a 5 seconds, so a true system reset is pretty traumatic.
The reliability of a good digital system should be dominated by classic hardware MTBF, not by bugs or glitches. It should have *no* bugs or glitches.
John
Power supply rails shouldn't glitch, and a decent system will either work correctly through a brownout, or reset/restart properly if it can't.
We (me and my guys) have had this discussion, about whether we should try to anticipate/sense/fix states that "can't happen", in the sense that there's no logical path to the bad state. Our concensus is that such sensing/fixing is fruitless, since any non-trivial system has astronomically more hazardous states (like the enormous state space of a uP program and its variables, or the megabits of configuration ram in an FPGA) than can even be analyzed, much less repaired. If a counter botches its state sequence, find out why and fix it. If a uP program crashes, ditto. And don't design asynchronous state machines that have small, lurking probabilities of screwing up. Things like watchdog timers hide the design errors, so you neither fix things nor learn.
Because it may fix a system hangup caused by who-knows-what, things that analysis and a few months of running didn't reveal, huge ESD shots or something.
I've never seen a watchdog timer cause a problem by malfunctioning on its own. I did recently code a diagnostic routine that, given a request to take and average zero ADC samples, would divide by zero, hang, and trip the watchdog. I found the bug after some units had been shipped, by reading the code, and as far as I know the bug was never tripped. Cases like that justify enabling a watchdog *after* considerable testing has not found provokable bugs that might trip it.
When my opinions differ from yours, you like to explain it by conjecturing some sort of emotional crisis on my part. Do you treat everybody that way?
John
-- You read my stuff don't you? Answer your own question. Being miffed is hardly an emotional crisis, and it seems whenever you get your feathers ruffled you like to start using vaguely derogative words like 'kluge' in order to secure what appears to be a technical advantage in order to keep from having to admit that you made a technical blunder.
Disagreeing with you on a design point is hardly "miffed." And, not being a chicken, I don't have feathers.
Adding a circuit to find and fix a presumably impossible state is worthy of "kluge" if anything is. Your circuit brought up the interesting and, I think, important question of whether we should incorporate such catcher/fixer things into our hardware and software. Pardon me for caring about ideas like that.
Technical blunder? In a newsgroup? A technical blunder is a mistake that fries thirty NMR probes, or blows up jet engines, or makes us recall a hundred instruments. Newsgroups don't matter.
John
Content-Transfer-Encoding: 8Bit
John Lark>The reliability of a good digital system should be dominated by
Certainly none caused by the hardware itself, and things like ESD and EMI can be shielded against, but what about the occasional cosmic ray flipping a bit?
From _Soft Errors in Electronic Memory ? A White Paper_ [
"Even using a relatively conservative error rate (500 FIT/Mbit), a system with 1 GByte of RAM can expect an error every two weeks; a hypothetical Terabyte system would experience a soft error every few minutes."
-- Guy Macon
One of my programming rules is that data should never be able to crash code.
John
If you're using deep sub-micron technology, like modern dram, whose soft errors compromise reliability, then something like ECC becomes mandatory. What scares me is stuff I can't do anything about, like FPGA config ram.
Things like using redundant data storage, with background checks and checksums, can be done, but that seems like more trouble than the device density is worth.
John
On Sep 9, 1:48 pm, John Larkin wrote: [....]
The assignment statement is more dangerous than a GOTO.
-- Turkeys do, though ;), and it wasn\'t a disagreement on a "design point" that got you miffed, your attitude seemed to change when your rather cavalier assessment of the operation of the circuit was pointed out as flawed and the proper sequence of events explained to you. Kind of a "David and Goliath" thing, you being the mighty Goliath, of course.
-- Why not let your client be the judge of that?
Assignments don't crash in assembly, since assembly is untyped. The only math error possible is a divide-by-zero trap, or a stupid pointer. What's important is that program flow doesn't bomb just because some cal table is trashed.
There's nothing wrong with GOTO; hell, Dijkstra didn't even have regular access to a computer, and didn't actually program much. I think in state machines, so GOTO is perfectly logical. In assembly, a conditional branch, or a computed/table driven jump, are the primary control structures.
Nested curly brackets are just as dangerous, or moreso.
John
I have many customers. Sometimes I conferr with them as regards product performance or interface; I almost never discuss internal design issues with them. Few of them ever see schematics or source code.
John
I think you missed the point. What I mean is that an assignment can change all of the future operation of the program so it can (if you don't code carefully) lead to hang up states and the like.
I certainly agree. Quite a lot of my coding contains GOTOs in the form of jump instructions. When you write on an 8051 you often do things like this:
SqrtFastOut: RET
Sqrt: MOV A,Work1 ORL A,Work1+1 ORL A,Work1+2 ORL A,Work1+3 JZ SqrtFastOut
Zero is a special case that my sqrt routine would get wrong otherwise.
As are the declares of any soft of array.
Well, that's bad code. The point of coding in state machines, or at least thinking in them, is that all possible cases are accounted for.
C doesn't encourage subroutines that have multiple entry and multiple exit points. Pity.
I's occurred to me, more than once, that C was invented to run on a PDP-11, and that a $400 Dell has 10,000 times the memory and a thousand times the speed of an 11. So why doesn't somebody invent a language (and a methodology) that produces/forces reliable code and requires less debugging, and does rudimentary stuff like data and code separation, at some expense in runtime resources?
John
What in the world are you talking about?
Oh. I don't like circuits that do accidental things.
None at all. The issue is a serious one.
You might want to work on the "fearless" part.
Sometimes it's interesting, and I don't watch TV.
No. But I might be looking for people.
John
Multiple exit points are no problem - you can easily
return;
from a function wherever you like.
Multiple entry points to a *function* are a bit more awkward - but you can enter other types of block at multiple points. If you know C you might enjoy this:
They have, of course - not many people use C to write applications for desktop machines any more. They use C#, java, all sorts of other languages and frameworks that do most or all of what you are asking.
However, to take up your analogy, todays microcontroller *is* similar in power to a PDP-11, so C is now in fact quite a good fit!
-- John Devereux
[...]
Im not just thinking of the indexes of state machines and I'm certainly not defending code that has this sort of problem. I am pointing out is that this is an area where people must be careful. Just coding without GOTOs is no insurance against any problem that GOTOless code is supposed to prevent.
There are lots of limitations you accept when you code in C.
This is hard to do in C:
IntRoutine:
Ooops heres the rest of what I was saying:
On Sep 10, 8:12 am, John Larkin wrote: [....]
In C it is hard to do things like this:
AnotherReti: RETI
Interrupt0: ... stuff ... CALL AnotherReti
; Code runs as non-interrupt code ... stuff ... RET
This is handy because it lets you deal with a process that may take longer than the shortest time between interrupts. You have to keep track of how many interrupt pulses there have been and react correctly but it isn't too tough.
I also write a lot of multi entry routines that look a little like this:
DoSomethingWith17: MOV A,#17 DoSomething: ; Process the number in A ... stuff ... RET
I put the comment: ;******* Fall Through *********************************** in to make it really obvious what I'm doing.
[....]They did partly. It is called Pascal. Specifically the Borland flavor of Pascal. Pascal has run time checking and very strict type checking. This helps a lot to prevent the common "type related" errors such as losing the signedness of a number.
Pascal generally doesn't allow you to express anything that requires mixing of code and data spaces.
In the OO version of Borland Pascal, they check an object's VMT for being likely to be valid before they dispatch a virtual function.
This seems to be a good start. The places where it falls short is in working with floating point values. In ordinals, you can specify the valid range that the number can be. For floats you can't. Also since the exponent of the float can change, there can be problems with lost bits.
I think it would be better if the accuracy and range was stated and the compiler made the choice about the right type (float, double, or extended) to be used.
I think it was Godel that proved that no compiler could out smart a stupid programmer, but at least it could check for the obvious stuff.
On Sep 10, 10:55 am, John Devereux wrote: [....]
I disagree. Many programs today are written using MFC which ensures that it is a hopeless morass of bugs.
Good thing i kept my backup HD as well as my OithRink subscription. Copper.net plainly "offers" newsgroups, but more plainly DOES NOT support them.
It is *NOT* possible to calculate a random number sequence; any such foolish attempt will result in a (perhaps long) repeating sequence. Even a "short" (say 1-10%) sample of a loooong sequence will fail one test of a truly random sequence of the same length. If you want random, start with (or re-seed from) a table of random numbers, similar to what was used by the military ages ago. Or..take a tested random process (eg: nuclear decay, brownian motion), digitize that for either random values or a "lookup table". Oh...you were asking about one of those tests? Any given value can and will repeat - - - randomly!
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.