Maximum interrupting current and voltage are important specs for protection devices. The car battery probably violates the first one unless there is significant additionall series resistance somewhere else in the circuit.
It's more spectacular to exceed the 10kA maximum on big fuses....
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
At least that comment is relevant to embedded engineering. Here's something I find vaguely interesting, but unsure how it fits in with the rest of the article:
Skimpy budgeting is another factor in failures, as seen most clearly in civil-engineering disasters. In 1940, officials found a way to build the Tacoma Narrows Bridge for half an initial estimate and did so, but the bridge famously collapsed in high winds after just four months in service. Likewise, the MGM Grand Hotel in Las Vegas saved $200,000 by not using sprinklers but paid out more than $200 million in court and rebuilding costs after a disastrous fire, Ganssle said.
I rarely use any salt when cooking. I finally finished off a two ounce bottle I bought over five years ago. Its processed foods that have too much salt as a preservative, or to improve the flavor to a barely acceptable level. The only time I add any salt is during very hot weather, where you lose more salt due to sweating.
As far as Potassium goes, you have to be careful about too much of it in your diet.
--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
If you must use the broken google interface to Usenet you sould at least set up the reply properly. The Google reply button is borken and only works correctly fore the small minority who use Google.
If you read what he said you would understand. He has made it clear in his embedded muse this month.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
As I've said, C is a feature-neutral language. It won't do the software design for you, and won't protect you from doing dangerous things - you have to bring your own knowledge, experience and discipline to the party. Which is (as I understand it) what Jack was saying (in context) - and I agree with him.
To rephrase something I've said before: software *design* exists irrrespective of the language one uses to implement it. One can code well or badly in any language - but the language is not the design.
A soldering iron is dangerous - in the wrong hands.
This reminds me of an incident many years ago when I was a lad. I returned to the study, where I was building some gadget, with a cup of tea to find my young sister (~3-4 yo) holding my soldering iron by the wrong end. Her expression was extremely pained but her injuries were remarkable minor.
And yes, I learned a very important lesson. I must have been 15 or 16.
Certainly. But the way C is taught and usually practiced is a scandal, and the fact that the majority of mid/large programming projects are total failures , and most embedded stuff is shipped with bugs, is the result.
And some languages *are* much worse than others.
But most soldering irons, in the hands of someone with a couple hours practice, quickly produce reliable solder joints almost every attempt. Most C compiles, performed by people with 4-year CS degrees, produce crap that doesn't work.
Yes, that is the reason. The problem is that this is exactly the way you want to use the part. The fact that you have to elsewhere limit the current makes the part practically useless in many applications.
I did it once to a 3AG sized one. It went off like a photoflash with red hot metal splattered about. I hope you won't consider me non-adventurous when I suggest that I not try it on a 10kA part.
The current limiter could indeed be a mirror in a lot of applications. But to be useful, it would need a very low saturation voltage and, say, a 1000:1 mirror ratio. Know of anything like that?
Burning up an amp to achieve a current limit of an amp isn't very appealing.
I can't argue with that. In fact, I'd generally agree. But my view is that it's not C that's to blame - it's the lack of s/w engineering skills out there. As I've said elsewhere, I'm pretty shocked at how poor *most* s/w design/coding is.
However: *my* embedded stuff does not ship with bugs ;). That's mainly from building up an experience-base over many years, and very little to do with the language per se, and very little to do with anything I learned in college.
I tend to think my approach to s/w design has more to do with my experience as a vintage motorcycle restorer in my late teens and twenties, working with guys who wouldn't let me get away with anything substandard. "If a job's worth doing, it's worth doing properly" etc. The thing that I sometimes have trouble convincing others about is that doing the job properly takes less time overall. So I convince them by delivering working code on time and on budget, and with no bugs.
Ok, I'll agree with that one too. Although I'll qualify that by saying that C takes some unfair stick simply because it is feature-neutral. Some folks argue that e.g. C++ is better in that respect - my experience has been the exact opposite. As the saying goes, C gives you enough rope to hang yourself - C++ gives you enough rope to rig the entire ship *and* hang yourself.
See above re experience. I suspect the best way to learn C is the same as learning hardware design - work with a good team, with frequent peer reviews, who won't let you get away with bad practice. Craftsmanship is maybe not something one can learn in college - and for some (maybe most) people, it's not something one can learn - period. It's an attitude. I have vivid memories of a somewhat sloppy colleague banging his head on his desk in frustration, yelling "my compiler doesn't understand me!".
Only when it's necessary, when it improves rather than degrades clarity. And only if you consider a subroutine call or a macro or a symbolic index into a structure to be "abstraction"; even then, the gory details are readable on a nearby page of the listing.
What do you make of this?
formatting link
Looks to me that
a) the probability of programming failure increases exponentially with program complexity, limited only by the number 1.0.
and
b) there's no limit to how much complexity can be brought to bear on any given problem.
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.