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
Ho Jack, and PLEASE don't start to dig up dirt about me and post it proving that I contradict myself etc. I know there is enough of it as most of the usual contributes...But most of the time I try to provide useful information, with some success I think. Do you?
erik,
Ouch. That is a bad way to generate that rule. The rule does have its merits though. I *try* to stick with that rule as much as I can, but I generally don't make it a formal rule...
Pre-initialized data "initialized variables at file level" is prone to errors and can introduce operational risks. (Where 'data' means volatile RAM space, and not in non-volatile space).
1) The "initialize before use" rule adherence is stressed where the 'at file level' is typically not close to the "use" section of code, nor is it close to "use" with respect to the time-line.
2) The centralized access to all of these 'at file level' adds a single-point risk of error into the system.
3) No assurance that the data was explicitly initialized. Any such universal "INIT.A51" type code could group many data-stores into a block and fill that memory space to the 'initialized value' (such as zero), and your ability to point to a specific set of instructions that initialized THAT data-store to THIS value is diluted.
If that 'service' of 'initializing variables at file level' wasn't there (and thus not in the "C" standard), would you then implement such a centralized service in "C" ? I think not. And the rational for not doing so, is exactly the rational you shouldn't force the validity of your code to depend upon that service.
4) Reduces the potential of assuming that a 'variable' with a pre-initialized value, is still that value when it is used. Although you may think that the data-store has never been modified before, it could have been, and what assurance do you have that it hadn't been modified prior to its invocation? (Especially when separated by much time and space).
Secondary reasons include the initialization time that can vary depending upon the amount of code that is tacked on. If the base code is released--and well characterized--and later somebody adds some help menus, you may not want the boot time to be changing every time you add a new help screen.
Although you cannot get away with never-ever using 'initialized variables at file level' all of the time, the spirit of the rule should be adhered to. An example is the need for static data-stores within functions to be initialized [to zero] is expected.
It is just that too many code-monkeys will rely on the value of pre-initialized data and generate sloppy coding habits. Especially the initialize [just] prior to use rule.
When you know that these risk areas do exist, then you can either make it a policy (aka 'rule') to keep your code-monkeys from haphazardly instituting "initializing data-stores at the file level," or you can make them aware that there are such risks, and that they should be quick to question the validity of relying on such methods when debugging, or qualifying the code.
Such practice is like being leery of using malloc( ). If you need to use it, then that's what you have to do, but you need to know about the risks.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
Am I now an new member of the sardine family?
Mr. Tamir Michael... one word: No Way (just chumming the waters for ravenous sardines).
I've read your work, and you are too smart, too thoughtful, and too 'nice' to be swimming in same ocean. You're a land creature. Sardines are not.
But your first "guaranty their order of initialization" was not what I was thinking. That could be important if you had [x]data-space that was shared between autonomous sub-systems, like a DMA peripheral, or some mail-box, or a data-space cycle-stealing circuit. Then yes, it could be an order specific problem.
I have three reasons for being careful with the use of initialized file-level variables. Basically for fast boot times and for high availability.
1) In some situations, the power source may require extremely fast boot times or the reset may possibly be used as a kind of interrupt. Or the environment may be so noisy that it may affect the brownout logic, but requiring the system to recover fast enough that the reboot will not be noticed or at least harmful.
2) Self-healing in case of memory corruption. With constant data protected in flash, and important variables being validated and/or regenerated, the probability of malfunction can be reduced.
3) Variables initialized by the application are easier to group together into logical blocks and protected by checksums, or possibly redundantly stored.
3) No assurance that the data was explicitly initialized. Any such universal "INIT.A51" type code could group many data-stores into a block and fill that memory space to the 'initialized value' (such as zero), and your ability to point to a specific set of instructions that initialized THAT data-store to THIS value is diluted I should have included: Every build is set up so each and every (volatile) variable slot (except SFRs and ports which both are set to specific defaults) is ZERO when main() is entered. This process is dead simple when you are not afraid of assembler (all done in local versions of startup.a51)
also: as I said "as i remember" Per brings up a thing that was included in the considerartion (the boot was too slow, we got a blink of the sign) and I recall that the number of reasons was much higher that those I can recall.
Erik
Well said Per.
(Once again, I was too verbose in *my* explanation).
Reading through this thread makes me wonder what you guys would be like if you all were put into a childrens' playground!
What hierarchy would there be? How many cliques would there be? How many ostracized individuals?
Please don't post your answers. It might cause offence!!??
How many cliques would there be?
Two cliques would exist: The Biguns and The Littluns. (en.wikipedia.org/.../Lord_of_the_flies)
Please don't post your answers. It might cause offence!!?? Okay.
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.
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"