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
It might be that you haven't thought about it much before you posted that question, so I'll let you think about that one for a bit.
I can imagine situations where it may be undesirable or impossible to initialise variables before execution of main, but cannot imagine why it would be a 'house rule'.
I think that erik should provide the reason, since that would show that erik is smarter than your average fish
I doubt that Erik's ability to explain his own house rule will reveal much about his intelligence. At least I hope not.
"At least I hope not."
Pride and prejudice? I thought you preached that people should have an open mind...
Jack, Could you please to us WHY you keep on launching these personal attacks. What is it with you? You don't have to preach me about freedom of expression - I believe I vehemently resisted proposals that were made here about curtailing that right. But what you are doing is the abuse of the freedom of expression - you are bullying Erik and you do so intentionally. Whether you respect his opinions or not, I believe everybody here would be much happier you just stopped. And you still did not provide an answer to his build log. You see: I'm trying to shift the discussion to where it belongs - the proper, technical realm!
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?
he rule of no variables initialized at the declaration:
It has been there 'forever', and I recall there were many reasons, but do I remember them all, I doubt it.
First, the origin of 'the rule' has nothing to do with software. A board made for the company before the company had any engineering could not do a straight movx (the latch had to be set manually - ARGH) and thus any 'automatic code' referencing xdata would fail. We then discussed whether to have the rule just for this project or global and decided for many reasons to make it global. as I recall: One I do remember was that there were state machines with 'idle' defined as all kinds of values, the 'rule' forced all idle's to be zero which saved a whole lot of lookups. The rule forces anyone to make 'inactive' a zero, again saving a whole lot of lookups. The only case where I can see a justification for 'inactive' being anything else than zero is a SFR or port bit, I have not investigated that, but I doubt you can write sbit 0x83 = 1 and come up with p0.3 a one. also it forces 'value tables' to be 'code', again an advantage. Oh, also it allow the use of #define UC xxx unsigned char where xxx is defined as extern in all modules but one.
So, what does 'the rule' buy us? consistency
of course some feel that this is restrictive, but when you want 'program responsibility' to be transferable, you need consistency.
Erik
PS Mr. Sardine owes me an apology for his bile about init always being included, but that, I am sure would be too much to ask.
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.
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.
Not at all - I apologise. I was sloppy.
A precompiled version of the code contained in init.a51 is always linked into your project unless you avoid two fairly fundamental features of the 'C' language:
1) Explicit initialisation of variables declared at file scope 2) Explicit initialisation of local variables with static storage duration
I understand you have a rule based on some ill-remembered premise preventing 1) - do you also have a rule preventing 2)?
I have no idea what you thought I meant, but I can assure you you've got it wrong.
Could you please to us WHY you keep on launching these personal attacks.
I don't know why you've taken on this 'personal atttack' thing. Beyond being able to hazard a guess at maybe age and country of origin of a poster I know nothing whatsoever about anyone who posts on this forum. The only 'attack' I can possibly make is towards the content and apparent tone of a post.
You don't have to preach me about freedom of expression - I believe I vehemently resisted proposals that were made here about curtailing that right.
Absolutely, and I agreed with your position. I disagreed with your apparent change of heart.
But what you are doing is the abuse of the freedom of expression - you are bullying Erik and you do so intentionally.
Oh, what utter rubbish. That would make me the most unsuccessful bully on the block - years of it seem to have had absolutely no effect.
And you still did not provide an answer to his build log. You see: I'm trying to shift the discussion to where it belongs - the proper, technical realm!
Topicality policing is always in danger of being seen as hypocrisy. If you do it you actually have to abide by your own rules.
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.