Hi, Do you have faced with this problem ? The USB debug adapter runs but the IDE debugger not. I can put breakpoint on the first line of the main but no break, no timer it generated too, when i stop running no stop on the code line executing. It seems there is a problem just before the main call.
thx
Pre-initialized data "initialized variables at file level" is prone to errors
[Huge explanation follows}
As far as I can interpret from what you have written your fears seem to boil down to two things: faulty hardware or incompetent programmers. Neither of these things can be fixed by rules.
"I have no idea what you thought I meant, but I can assure you you've got it wrong."
You wrote: "I doubt that Erik's ability to explain his own house rule will reveal much about his intelligence. At least I hope not."
The second sentence sounds very much like: "I hope that he will not be able to explain ..."
"faulty hardware or incompetent programmers"
Correctly built and screened hardware can still get into troubles if subjected to a big enough jolt on the power supply lines or strong enough electric or magnetic fields. It isn't always practical or economical to galvanically separate all signals, using a huge transformer with a saturated iron core on the power lines and screen all electronics inside a layer of iron and one layer of copper.
Redundancy or checksumming isn't something you do because you think you are a sloppy or untalented programmer. It is something you do because you do not want your embedded unit to behave like a desktop PC that reboots if someone touches the machine and zaps it.
When the equipment is used in important infrastructures, such as controlling street lamps, traffic signs, pump stations for supplying a city with fresh water, ... you do not want a broken contactor sparking a kV arc affecting your equipment.
A watchdog is good to have when the processor locks up, but there are quite a number of problems that can happen without trigging the hw watchdog or any external or built-in brownout hardware.
It is often very important for the equipment to know when it can auto-repair and continue, or when it must switch to fault mode and request immediate attention.
Whew! Thanks Per. I'm glad there are embedded engineers out there who know about mitigating risk, and actually want to build systems that are robust.
For a while there, I kept thinking that there were too many 'engineers' out there who just want to bang out a widget that was just good enough to fool the customer into paying for it.
And then, to add insult to injury, these 'deploma mills' make the embedded world even more dangerous. (I'm hoping the industry culls them out).
But when a graduate of Jackus Spratus University starts hacking out unruly code, I realize my kids, my wife, my dog, my neighbor's pet hampster, and myself are all in peril.
You see, JSU graduates *think* they have a good system, and are ever so confident of it. Whereas people like erik, Per, Tamir, and Dunn, think they can do better, and TRY to by evaluating, incorporating, rejecting new ideas ('rules') that lend toward a more robust system.
Raise your hand if you want your pacemaker built by erik muland.
Raise your hand if you would rather have a sardine build it.
Okay, I thought so.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
Vince, You should be a lawyer. Case closed.
"Raise your hand if you want your pacemaker built by erik muland."
Look, no hand here!
If there were ever a need for me to have a pacemaker, I would be very worried if I found that Erik Enterprises had anything to do with it.
Any recipient would no doubt have a large data cable protruding from their chest so Erik could carry out his post release debugging on the live code that he finds so necessary.
And when the recipient finds that they have a constant pulse of 120bpm, there would be no point in that recipient complaining to Erik. He would just insist that he chose it, it was therefore the right decision, and a suggestion of any other was just an indication of the recipients stupidity.
You have one from him if you want ... Just allow the free-thinkers the opportunity to choose an alternative!
No, quite the opposite. It seemed clear to me that being able to offer up an explanation of a house rule would be a straightforward task offering little insight into the explainer's intelligence, whereas an inability to do so would be somewhat worrying. I had hoped that the former would be true.
[Big explanation of environmental difficulties with budget hardware]
Sure, but I was trying to get to the bottom of why a house rule would exist that would prevent the initialisation of static data.
I'm amused by your use of the word 'hack', when hacking is precisely the thing I try to avoid. Perhaps you haven't noticed, but I do rather go for the 'read the manual and get it right' approach instead of the 'hack and debug until it seems to work' method.
Sure, but I was trying to get to the bottom of why a house rule would exist that would prevent the initialisation of static data. static data is "outlawed" simply because static data occupy both code and data space, 'code' data occupy only code space.
you clearly did not read my post, there is, of course, no rule against initializating code data and thus no such was stated in the rule"
Erik