Code Compiled, linked, downloaded but not running

 Code Compiled, linked, downloaded but not running

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 would be helpful if you would tell us

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 would be helpful if you would tell us
Which chip
which USB adapter
which IDE debugger

Erik

 RE: it would be helpful if you would tell us

Hi,
C8051F50XDK, Silicon Labs USB Debug Adpater, Keil A51, C51, BL51, Silicon Labs IDE.

Richard

 RE: it would be helpful if you would tell us

do0 you disable the watchdog INMMEDIATELY after startup:

 RE: it would be helpful if you would tell us

Hi, i don't think about the watchdog because i even never arrive at the first instruction in the main. what do you think about the watchdog ?

 RE: it would be helpful if you would tell us

i even never arrive at the first instruction in the main
that is ECACTLY what happens when you do not disable the watchdog.

 RE: it would be helpful if you would tell us

I have to disable the watchdog in the IDE or in the code ?

 RE: it would be helpful if you would tell us

I think you have a very serious problem and it requires careful analysis.

Post all the code here and we will check it for you.

 RE: it would be helpful if you would tell us

I think you have a very serious problem and it requires careful analysis.
yes, he does:
I have to disable the watchdog in the IDE or in the code ?
but no "careful analysis" needed

What on earth does the ide have to do with the watchdogs operation???

the watchdog must be disabled AT THE START OF startup.a51

Erik

 RE: it would be helpful if you would tell us

Post the code.

Erik will then spend some time looking at it and he will advise you as to what must be modified.

 RE: it would be helpful if you would tell us

I don't really understand all requests for code in this and other threads. Is it in the hope that the posted code - after correction - will be possible to turn in as a school assignment?

 RE: it would be helpful if you would tell us

Erik will then spend some time looking at it and he will advise you as to what must be modified.

already done

 RE: it would be helpful if you would tell us

Hi,
Thx for your quick responses, indeed it seems to be the watchdog, before main call, which reset.
But do you know how what to write in the WATCHDOG macro in INIT.A51 file ?

here is my current watchdog reset macro.
but seem to not work. however LST file show the macro at right place.

User-defined Watch-Dog Refresh.
; ; If the C application contains many initialized variables uses a watchdog
; it might be possible that the user has to include a watchdog refresh into
; the initialization process. The watchdog refresh routine can be included
; in the following MACRO and can alter all CPU registers except
; DPTR.
; WATCHDOG MACRO MOV 0CFH,#78H ENDM

 RE: it would be helpful if you would tell us

mister orange,

have you disabelled the macro's in the ide?

thanx

 RE: it would be helpful if you would tell us

hi, i'm using the silabs IDE with Keil compiler.
so there is no macro options.

here part of LST file..
003B 156 ?C_START:
003B 900000 F 157 MOV DPTR,#?C_INITSEG
003E 158 Loop:
159 WATCHDOG
003E 75CF78 160+1 MOV 0CFH,#78H
0041 E4 161 CLR A

i mean it's the watchdog reset method that not working..

 'demacronize' and show your code

it is 100 times easier to see what it is if you do not show code using macros
BTW why are you even using a macro for something you only do once?

Erik

 RE: 'demacronize' and show your code

Hi,
See Cx51.chm, "searching" with keyword: "watchdog" and you will see why ?

Thx

 RE: 'demacronize' and show your code

CX51 has no idea in the world how a SILabs watchdog works.

WHY do you REFUSE to do what i suggest?

THE END

Erik

 RE: 'demacronize' and show your code

WHY do you REFUSE to do what i suggest?

It is fortunate that in a free society people have choices!

 RE: 'demacronize' and show your code

Some choices are better than others...

 RE: 'demacronize' and show your code

WHY do you REFUSE to do what i suggest?

WHY do you REFUSE to read what he writes?

THE END

What a relief!

 RE: 'demacronize' and show your code

THE END

What a relief!

It would be if it were true. But just wait ... He'll be back with his usual 'style'!

 RE: 'demacronize' and show your code

Erik,

in this project, we must use standard startup files from compiler. (mandatory for our customer)
If Keil define one Macro to refresh WDT... why modify directly the code ?
this method of work is better for futur upgrade of startup files. we don't have to modify the code.

i can try your idea but i don't see what is different than by macro.. macro principle is to replace keyword by some instructions. Macro is generaly defined in top of file to easily identify changeable portion of code.

but i'll try your suggestion now.

 RE: 'demacronize' and show your code

?C_START:
          MOV     DPTR,#?C_INITSEG
Loop:
          MOV     0CFH,#0H
;         WATCHDOG
          CLR A

 this very issue has been discussed ad nauseam at the SIlabs forum

in this project, we must use standard startup files from compiler. (mandatory for our customer)
then tell you customer "we can't" and show him the silabs knowledge base articles

the issue:
https://www.silabs.com/support/knowledgebase/Pages/McuKB.aspx

howto:
https://www.silabs.com/support/knowledgebase/Pages/McuKB.aspx

so, is THAT enough to get you to do what you need to do instead of trying to do something else that you 'prefer' but does does not work

in the preview I see both links are the same you need to type watchdog into the search window that comes up and find the two articles.

Erik

PS to the sardine:
if you would takr the time to verify that I was wrong (which I am not) before you spewed your bile, there woould be a whole lot less of it

 RE: this very issue has been discussed ad nauseam at the SIlabs forum

if you would takr the time to verify that I was wrong (which I am not) before you spewed your bile, there woould be a whole lot less of it

Where did I say you were wrong?

The poor chap is merely trying to explain why he's doing what he's doing (following the instructions in the documentation) yet you just keep yelling at him before finally flying into a sulk and saying you're not playing any more. Sadly your sulks don't seem to last very long.

 RE: this very issue has been discussed ad nauseam at the SIlabs forum

Hi,
Simply, is someone able to answer why with instructions above the watchdog never reset ?
A piece of code which work with c8051F500 would be cool... or INIT.A51 file which work

Thx

 RE: this very issue has been discussed ad nauseam at the SIlabs forum

A piece of code which work with c8051F500 would be cool...

howto:
https://www.silabs.com/support/knowledgebase/Pages/McuKB.aspx
you need to type watchdog into the search window that comes up and find the article

INIT.A51 file which work
what is an INIT.A51 file?

Erik

 RE: this very issue has been discussed ad nauseam at the SIlabs forum

what is an INIT.A51 file?

You are joking, aren't you?

Perhaps not - it would explain some of your misplaced arrogance in this thread.

Time to read the C51 manual I think...

 RE: this very issue has been discussed ad nauseam at the SIlabs forum

Hi,
Thx Erik for your answer but we are searching the way to reset (refresh) the watchdog during startup and init sequence (before main call).
During this sequence, writing to PCA0CPH5 doesn't work and so doesn't refresh the Watchdog ! It's a little bit strange, isn't it ?

 RE: this very issue has been discussed ad nauseam at the SIlabs forum

During this sequence, writing to PCA0CPH5 doesn't work and so doesn't refresh the Watchdog ! It's a little bit strange, isn't it ?
what sequence?
the issue is NOT 'refreshing' but 'disabling'

Erik

for the f12x it looks like this, you find out how to do it for your chip (hint; it is in the documents I mentioned)

STARTUP1:
; disable watchdog
           mov   SG_WDTCN,#0DEh        ; kill the puppy
           mov   SG_WDTCN,#0ADh        ; takes 2 writes

 no joke

what is an INIT.A51 file?
You are joking, aren't you?

Yes, there is an init file build by the tools (the one between statup and main), but if that is 'user modifiable' I do not know of it. Since it is built by the tools how can it be .a51

Erik

 RE: no joke - Oh dear!

Erik,

Read and learn ...

On my system (where the base directory is "C:\Keil") a file was written BY THE INSTALLER to:

C:\Keil\C51\Lib\INIT.A51

Unless you went for a very strange custom install, it is highly likely that you have a copy in the corresponding location of your system.

 mystery solved

I have such a file in that location but it is not part of my builds.

from the file:
; INIT.A51: This code is executed, if the application program contains
; initialized variables at file level.

it is 'house standard' here not to have "initialized variables at file level" thus I have never seen it. So, yes, Mr Sardine and Mr. Bratwurst, I asked a question and finally got an answer, is that not what the forum is for (oh, sorry, you act as if it is for ridicule, not for information)

Anyhow it will do no good to kill the puppy there, it will already have bitten

Erik

 RE: mystery solved

Mr. Silly Sausage and Mr. Jack Sprat,
I hate to take sides but this time I agree with Erik. Your latest arguments were abusive, non-technical and deliberately offensive. What were you trying to prove actually? Yes Erik made a couple of contentious claims in the past (I raised an eyebrow or two when he claimed to have "no bugs" at all) and I know he is not always right (who is, for god's sake) but seriously guys - keep it down to business, and down to earth!

 RE: mystery solved

Tamir,

It would seem that your threshold for opinionated arrogance is higher than mine.

Anyway ... I understand what you say, and will try to refrain.

 RE: mystery solved

I hate to take sides but this time I agree with Erik. Your latest arguments were abusive, non-technical and deliberately offensive.

First off, if you agree with Erik you will be agreeing that I treated his behaviour with ridicule. This is correct. 'Abusive' and 'offensive' are quite a different matter. I would suggest that the use of profanity would be classed as offensive, this is quite typical of Erik's behaviour on this forum. I have also noticed that you are not averse to using language that would be considered blasphemy by at least one of the major global religions.

What were you trying to prove actually? Yes Erik made a couple of contentious claims in the past

The things that irritate are his barracking arrogance, refusal to follow his own advice, refusal to read and understand what others write, inability to understand that there are alternative approaches to many problems rather than the one deemed correct by him, inability to ever follow any discussion through to its conclusion if that conclusion reveals him to be wrong and so on.

and I know he is not always right (who is, for god's sake) but seriously guys - keep it down to business, and down to earth!

I think you need to put your own house in order before you start to dictate who should say what on this forum.

 RE: mystery solved

I have also noticed that you are not averse to using language that would be considered blasphemy by at least one of the major global religions

I don't know if you meant it like that, but you made me laugh...if I hurt your religious feelings I apologize.

I think you need to put your own house in order before you start to dictate who should say what on this forum.

Ouch. What a punch line! Do you mean me trying to make a hit on Marleen (ops. my girl is not going to like this post hahahahaha) :-) :-) or the religious stuff?!!?!?!?

 RE: mystery solved

I have such a file in that location but it is not part of my builds.

Every time you build you link with that code. I would be amazed that you didn't know this if it were not for your apparently blanket refusal to read any documentation associated with software.

it is 'house standard' here not to have "initialized variables at file level"

How strange. Why would anyone impose such a rule?

I asked a question and finally got an answer, is that not what the forum is for

Yes, it is. There is also, however, an expectation that someone who has been using these tools for as long as you might have read the manual.

Anyhow it will do no good to kill the puppy there

The intent is that you strobe the watchdog in INIT.A51, not disable it.

it will already have bitten

Will it? How long does 'the watchdog' take to time out?

 RE: mystery solved

Hi,
The issue is NOT 'refreshing' but 'disabling'
If we can not refreshing the watchdog, i 'm afraid for the use of this chip...

 RE: mystery solved

If we can not refreshing the watchdog, i 'm afraid for the use of this chip...

I'm sure you can, and INIT.A51 is one of the right places to refresh it. Unfortunately I'm not familiar with this device, and neither, it would seem, is anyone else, so I guess you're just going to have to read the datasheet carefully to establish how to do it.

 RE: mystery solved

Hi,
The issue is NOT 'refreshing' but 'disabling'
If we can not refreshing the watchdog, i 'm afraid for the use of this chip...
The handling of this issue (sorry Mr. Sardine) commonly accepted by all SILabs users (that have commented on this issue) is to disable the watchdog in startup.a51 and then enable it at the top of main().

now:
Every time you build you link with that code

if not exist aoc.lib goto usliex
del aoc.lib
:usliex
c:\%DDIR%\c51\bin\lib51 c aoc.lib                                       >..\trash\trashbin
c:\%DDIR%\c51\bin\lib51 a OCmain.obj     to aoc.lib     >..\trash\trashbin
c:\%DDIR%\c51\bin\lib51 a OCutil.obj     to aoc.lib     >..\trash\trashbin
c:\%DDIR%\c51\bin\lib51 a OCautil.obj    to aoc.lib  >..\trash\trashbin
c:\%DDIR%\c51\bin\lib51 a OCkbpr.obj     to aoc.lib     >..\trash\trashbin
c:\%DDIR%\c51\bin\lib51 a OCtool.obj     to aoc.lib     >..\trash\trashbin
c:\%DDIR%\c51\bin\lib51 a OCusb.obj      to aoc.lib     >..\trash\trashbin
c:\%DDIR%\c51\bin\lib51 a OC485.obj      to aoc.lib     >..\trash\trashbin
c:\%DDIR%\c51\bin\lib51 a OCcmd.obj      to aoc.lib     >..\trash\trashbin
c:\%DDIR%\c51\bin\lib51 a OCvfd.obj      to aoc.lib     >..\trash\trashbin
c:\%DDIR%\c51\bin\lib51 a OCnummsg.obj   to aoc.lib     >..\trash\trashbin
c:\%DDIR%\c51\bin\lib51 a OCupdata.obj   to aoc.lib     >..\trash\trashbin


if "%MUSDIR%"=="0" goto lnkdir
rem linking for boot required
c:\%DDIR%\c51\bin\bl51 OCstart.obj, OCintent.obj, OCisr.obj, OCxdata.obj, \ 
BOOTbit.obj, aoc.lib TO aoc.omf CODE(0x4000 - 0xFFFF) RS(256) IX >protl.log
goto lnkdon

I do???

Erik

Note
This message was edited to reduce width.

 I do???

Slowly breathe in.

Slowly breathe out.

Relax.

Ahhhhhh.

 the watchdog discussed here

Slowly breathe in.
Slowly breathe out.
Relax.
Ahhhhhh.
the watchdog discussed here is an electronoic device, not a sleeping collie

Erik

PS
Every time you build you link with that code was never the issue, the issue was init.a51. yes, there is a C_INIT or some such (I could look, but if you need the specific, look yourself) in the .m51 file which I have known for years, but AGAIN the issue was init.a51.

Erik

 RE: the watchdog discussed here

Every time you build you link with that code was never the issue, the issue was init.a51. yes, there is a C_INIT or some such (I could look, but if you need the specific, look yourself) in the .m51 file which I have known for years, but AGAIN the issue was init.a51.

The key point is this: What code is contained in INIT.A51?

 RE: mystery solved

I do???

Yes.

 NO, confound it, NO

I do???

Yes.

NO, confound it, NO
from the .m51:

INPUT MODULES INCLUDED:
  MKSTART.OBJ (?C_STARTUP)
  MKINTENT.OBJ (MKINTENT)
  MKINTVEC.OBJ (MKINTVEC)
  MKISR.OBJ (MKISR)
  MKIIC.OBJ (MKIIC)
  MKXDATA.OBJ (MKXDATA)
  BOOTBIT.OBJ (BOOTBIT)
  AMK.LIB (MKMAIN)
  AMK.LIB (MKJ1708)
  AMK.LIB (MKTOOL)
  AMK.LIB (MKUTIL)
  C:\TOOLS\KEIL\C51\LIB\C51S.LIB (?C?CCASE)
  C:\TOOLS\KEIL\C51\LIB\C51S.LIB (?C?ICASE)

Erik

I added an initialization of a variable and then

C:\TOOLS\KEIL\C51\LIB\C51S.LIB (?C_INIT)

popped up

 RE: such a rule?

Although there aren't any Stupid Questions, some questions can reveal a questioner's level of competence. Its not that we thought that sardines were smart to begin with, but this insight into the Shoals of Sardine Thought is priceless...

How strange. Why would anyone impose such a rule?

(in reference to: it is 'house standard' here not to have "initialized variables at file level")

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 think that erik should provide the reason, since that would show that erik is smarter than your average fish).

</stir>

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 some answers might not be so bright :-)

ok captain, the first thing that pops into my mind is that you cannot guaranty their order of initialization...? Am I now an new member of the sardine family?

 RE: some answers might not be so bright :-)

further clarification: that matter IF there are dependencies between global variables.

 RE: such a rule?

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.

 RE: such a rule?

"At least I hope not."

Pride and prejudice? I thought you preached that people should have an open mind...

 rule and reason

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.

 RE: rule and reason

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.

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)?

 RE: such a rule?

Pride and prejudice? I thought you preached that people should have an open mind...

I have no idea what you thought I meant, but I can assure you you've got it wrong.

 RE: such a rule?

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!

 RE: such a rule?

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.

 RE: such a rule?

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?

 RE: such a rule?

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

 RE: such a rule?

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.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 RE: such a rule?

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.

 additions

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

 Any psychologists around?

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!!??

 RE: such a rule?

Well said Per.

(Once again, I was too verbose in *my* explanation).

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 RE: such a rule?

How many cliques would there be?

Two cliques would exist: The Biguns and The Littluns.
(http://en.wikipedia.org/wiki/Lord_of_the_flies)

Please don't post your answers. It might cause offence!!??
Okay.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 RE: such a rule?

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.

 RE: such a rule?

"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.

 RE: such a rule?

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

 RE: such a rule?

Vince,
You should be a lawyer. Case closed.

 Just too frightening a thought to ignore!

"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!

 RE: Just too frightening a thought to ignore!

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.

a) post release - where did you get that from.
b) if you never need to debug - you are lying.
c) I want efficient, speedy debug, you do not care, is that your form of job security.

Erik

 Showing your true style again!

"you do not care, is that your form of job security"

Care??? Security???

You know nothing about me or my work!

You know nothing about my design and debugging procedures!

Re: post-release - Read your previous posts!

Like: http://www.keil.com/forum/docs/thread10196.asp

 back at you

Mr Bratwurst

You know nothing about me or my work!
You know nothing about my design and debugging procedures!

so how come you comment on them.

That I discuss some aspects does not make a bratwurst or sardine know about my work, debugging procedures etc. You seem to conclude that because I try to use efficient methods, I have more bugs than anyone else, that conclusion is both false and made on the wrong premises. Of course, you can criticize all you want the aspects I discuss here but even a bratwurstbrain should be able to understand that the fact that I eat pie does not mean that I eat nothing else.

re 'post release' most, if not all I have discussed re post release bugs refer to 'inherited' products, and, if you never have had a post release bug in your life I pity the people you work for.

If you want to discuss my statements, limit yourself to the statement, do not expand them to areas they have nothing to do with.

Erik

 I checked your link re 'post release'

you would have read (parapharsing) "a thing that works perfectly till someone provides input that does not follow the standard (to which extent and how, is unknown) and insist that the system accept it"

The case rferred to her was that 3 (at that time known) manufacturers provided god data that we processed faultlessly at 'release time'.

Then a 4th manufacturer connected and sent data that did not follow the standard so, since I do not have a crystal ball that data could not be processeed.

Erik

 RE: back at you - And bounced again!

You know nothing about me or my work!
You know nothing about my design and debugging procedures!

so how come you comment on them.

Wrong - I have NEVER commented (here) on what I have written about myself, my work, my design or my procedures.

You seem to conclude that because I try to use efficient methods, I have more bugs than anyone else...

Very wrong - Just hope you don't use buggy follow-throughs like that in your code! Everyone has bugs, but careful design and experience should reduce them.

should be able to understand that the fact that I eat pie does not mean that I eat nothing else.

Pardon - I can honestly say that I've never given your dietary requirements any thought!

... if you never have had a post release bug in your life I pity the people you work for.

Simply extraordinarily - In my book, the lack of the need is something to aspire to. (Who was it that mentioned job security?)

If you want to discuss my statements, limit yourself to the statement, do not expand them to areas they have nothing to do with.

Fine - Pot, kettle, black! Just don't say such silly things - Huh?

Anyway, I'm still not going to have a pacemaker from you - Yah Boo Sucks!

 RE: back at you - And bounced again!

should be able to understand that the fact that I eat pie does not mean that I eat nothing else.

Pardon - I can honestly say that I've never given your dietary requirements any thought!
so paraphrasing is beyond your comprehension

... if you never have had a post release bug in your life I pity the people you work for.

Simply extraordinarily - In my book, the lack of the need is something to aspire to. (Who was it that mentioned job security?)
I have no idea what you mean with that

Erik

 RE: back at you - And bounced again!

"so paraphrasing is beyond your comprehension"

Normally no - But when it is done in such a weak manner it deserves to NOT be taken seriously.

"I have no idea what you mean with that"

LOL - Why am I not surprised by that - Explanation would be wasted.

And I'm still not going to have a pacemaker from you.

 RE: back at you - And bounced again!

Explanation would be wasted
then do not explain just answer

the lack of the need is something to aspire to
The lack of the need of WHAT?

Erik

 RE: back at you - And bounced again!

Erik: "then do not explain just answer"

Your comment:

"[...] if you never have had a post release bug in your life I pity the people you work for."

implies that it is bad to not have had a post-release bug, and that it is good to have had post-release bugs.

 RE: back at you - And bounced again!

Your comment:

"[...] if you never have had a post release bug in your life I pity the people you work for."

implies that it is bad to not have had a post-release bug, and that it is good to have had post-release bugs.

No such intent, but let me expand

We all (at least I hope so) do our darndest not to have post release bugs but in the real world (I get a sneaky suspicion the the sardine and the bratwurst are academians) you have to deliver before you want to.

Anybody can have a lower risk of post-release bugs if te company they work for allow them to spend 5 years to develop 500 lines of code.

Thus "if you never have had a post release bug in your life I pity the people you work for" means that they either only make 'blinky' and such or deliver everything too late, too expensive.

Do I find the existence of post-release bugs acceptbble, yes and no, no because I do not want them to exist and yes because the fact that delivery is 'yeaterday' makes them exist.

REAL WORLD, not academic treatises.

Erik

 RE: back at you - And bounced again!

Now, it's time to quote one of your own statements: "More words do not make you appear stupid, they make you appear thorough."

or to paraphrase it: Make sure that you are explicit enough, so that people don't have to guess your intent.

 in this case

Make sure that you are explicit enough, so that people don't have to guess your intent
in this case, it was deliberate since both the sardine and the sausage seems to believe that such should not happen and never happens to them.

soory that it got you, Per.

Erik

PS
I get a sneaky suspicion the the sardine and the bratwurst are academians
and I still do. Academia is the only place I know of that believe in ideal situations.

 RE: in this case

"I get a sneaky suspicion the the sardine and the bratwurst are academians"

I cannot speak for the person you refer to as 'the sardine', but I can speak for myself ...

NO - You are, once again, sooooooo wrong!

And I'm still not going to have a pacemaker from you.

Have a nice weekend everybody.

 RE: The Pace Makers...

The Murmur-Maker 2000 (by Malund Medical Industries)

vs.

The Systole Snubber v7.39e (by Smoked Sprat & Fish Hatchery)

 RE: The Pace Makers...

Vince,
You wrote
The Systole Snubber v7.39e (by Smoked Sprat & Fish Hatchery)

No no no... :-)

This should have been

The Systole Snubber v1.00000000000000000000 (by Smoked Sprat & Fish Hatchery)

 RE: in this case

Silly Sausage,
I trust you know that even pacemakers have the feature of software updates (these are genuinely the most ingenious devices). I don't understand why you cringe when faced which the shear possibility of a post release fix. Does such a release mean you were sloppy? Not necessarily. complex machines tend to have a huge number of different states, and it is impossible to cover all possibilities by testing. When management style schedules are added along with tight budgets for development, tools and testing - such updates might be essential. I regularly find bugs in my mobile phone, my digital camera etc.

 RE: in this case

I hope they do not need to replace the pacemaker firmware because of bugs. But they need to be able to configure them, depending on varying requirements.

I think they would go for a version number 3.141592653.. just to show the perfection. Actual release will have to wait until someone have managed to find room for printing the full version number...

 RE: in this case

Tamir,

"I trust you know that even pacemakers have the feature of software updates (these are genuinely the most ingenious devices)."

Of that, I have no doubt.

"I don't understand why you cringe when faced which the shear possibility of a post release fix."

Actually, they don't! It is not (normally) a specific subject that makes me cringe. However, Erik's responses do sometimes have the effect - Purely because of their extraordinary 'style'.

I would find it hard to believe that others do not know what I mean - Even if they choose not to state it.

"Does such a release mean you were sloppy? Not necessarily. complex machines tend to have a huge number of different states, and it is impossible to cover all possibilities by testing. When management style schedules are added along with tight budgets for development, tools and testing - such updates might be essential."

You're preaching to someone who is well aware of these things - The saying "Been there, done that" springs to mind.

"I regularly find bugs in my mobile phone, my digital camera etc."

Yes - And if there is no fix it's *#^%ing annoying!

I find it interesting that people picked up on first point regarding Erik's pacemaker and none for the second!?

 RE: in this case

But they need to be able to configure them, depending on varying requirements.

Sure. This may not be exactly what you mean, but some devices allow the patient to move a small metal (?) bar in front of his/hers chest to automatically increase the bpm to allow sports activities. Another one of these lowers the bpm back to normal. No "large data cables protruding from their chest" here, Silly Sausage...

 RE: in this case

No "large data cables protruding from their chest" here

Good - A device free from the influece of Erik Enterprises ;)

 Whoops ...

Good - A device free from the influence of Erik Enterprises ;)

 RE: in this case

Yes, I was thinking about RF or similar configuration of the pacemaker from outside the chest.

Not just end-user switching between two profiles, but the actual configuration of what the profiles should be, and for example requesting the battery status.

So, not impossible that they have a full post-release debugging interface. Not because they don't trust the hardware/firmware, but because they don't trust the host hardware.

 RE: such a rule?

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.

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.

 RE: such a rule?

The second sentence sounds very much like: "I hope that he will not be able to explain ..."

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.

 that is just too nsimple

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

 RE: that is just too nsimple

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"

Look, I was replying to a post by Per Westermark, you've waded in after missing the point on so many levels I don't think I can quite face trying to explain to you what is going on. Maybe when I have more time.

 well,

Look, I was replying to a post by Per Westermark, you've waded in
well, tha basis for the 'rule' discussuion is a post of mine re initialization, so if I "waded in" by replying I am happy since that makes me wear tall boots which makes it easier to get through your stuff.

Erik

 RE: well,

well, tha basis for the 'rule' discussuion is a post of mine re initialization, so if I "waded in" by replying I am happy since that makes me wear tall boots which makes it easier to get through your stuff.

Oh dear. Ok, I'll try and explain a bit:

1) I wasn't asking Per Westermark, or you, for an explanation of the reasons behind your rule. I was trying to point out to Per that while the points that he raised were valid they were not entirely relevant to the discussion in hand.

2) static data is "outlawed" simply because static data occupy both code and data space, 'code' data occupy only code space.

'static data' was with reference to 'data with the storage duration class static'

3) 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"

I did not mention data stored in code space *at all*. That is a figment of your imagination, not an indication that I did not read your post.

 RE: Under-ruled

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.

Great.

Sounds like you are on the right track. Too many code-monkeys simply 'hack and debug until it seems to work' method.

It is nice to know that you have design documents and a process that prevent the monkey cage environment from banging out hacker type code. As with most caged animals, having a set of rules should help the code-monkeys from stinking up their cages.

The design documents are not likely to state mundane things like "do not implement dynamic memory," or "Thou shall write thy own printf routine."

These kinds of things end up in the a official "The Care and Nurturing of Your Code-Monkey" book of rules. You might even find a rule about not pre-initializing data stores. Or when doing an evaluation, especially in a control flow statement, always be explicit: if( x ) is bad, while if( x != 0 ) is good. That kind of base-line coding practice is what separates the pros from the hackers. (I'm guessing that reading the manual is such a given to the pros that it isn't worth mentioning, much less touting as proof of non-hacker status).

To me, and I'm sure others, if you don't have such a book of rules, then 'hacking' is likely to occur.

So, when I see that you seem to be oblivious of "erik's rule" and seemingly unwilling to investigate, digest, and accept/reject that rule is an indicator to me that you don't have such a book -o- rules.

Hence, it is an indicator that hacking lurks just below the surface... (insert sardine reference here).

It is not that I think everybody would automatically know why such a rule would exist, but upon hearing about it I'm guessing a person who states "How strange. Why would anyone impose such a rule?" hasn't thought too deeply about the rational. Especially when the question is directed at erik.

But, I guess I took your question has an un-thoughtful rejection of the rule simply due to the context in which you posed it: hostile.

Like I said, your question did reveal your level of competence, but then again, I might be wrong.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 RE: Under-ruled

(I'm guessing that reading the manual is such a given to the pros that it isn't worth mentioning, much less touting as proof of non-hacker status).

So what are we to make of Erik's insistence that reading language manuals is strictly beneath his dignity?

I'm guessing a person who states "How strange. Why would anyone impose such a rule?" hasn't thought too deeply about the rational

You're being a big unfair there. It's at least as likely that that person simply never saw anything resembling a rationale for that particular rule. So he has nothing to think about, deeply or otherwise. In such a situation, any other reaction than "How strange!" would be worrying.

And frankly, I can't say any of the rationales Erik presented for this particular rule made sense to me.

 you got that one wrong

So what are we to make of Erik's insistence that reading language manuals is strictly beneath his dignity?

If you carefully read whatever gave you the above impression you will see that I have said no such thing.

HOWEVER whether I do or don't is no business of the sardine thus you may have gotten that impression based on my response to the canned fish.

Erik

 RE: well,

Oh dear. I'll bend it in neon, hopiung that will do, I have lost my scissors and can thus not cut it in cardboard

first you state 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.
then you say I wasn't asking .. for an explanation of the reasons behind your rule
so "trying to get to the bottom of why" is not "asking .. for an explanation"

'static data' was with reference to 'data with the storage duration class static'</i?
which is excaltly what I referenced

I did not mention data stored in code space *at all*. That is a figment of your imagination, not an indication that I did not read your post.
I never stated you mentioned that, I mentioned that as the reason for "no static data"