my code is 110% correct; eg no errors and runs properly. see.
int _val; int myfunc2(int val) { _val = val; return _val; }; int Bar(int val) { return _val + val + 1; }; void myfunc1(int val) { _val += Bar(val); }; etc etc etc
it doesnt give me the right answer sometime.
HEEEEEEEELLLLLLLPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
my code is 110% correct; eg no errors and runs properly.
You're deluding yourself. Even setting aside the pure lunacy of claiming an above-unity percentage of correctness for anything, that code is clearly not 100% correct.
No. That code cannot give you any answer qualifiable as "right" or "wrong" at all, for the simple reason that it doesn't do anything, by itself.
The bandwith wasted for that nonsense could have been put to much better use if you had actually stated a question, instead of just dumping some unrelated shards of code and expecting people to read you minds regarding what you think is actually wrong with it.
Hmmm ...
http://www.keil.com/forum/16227/
which code is better? Please vote: [ ] Totally bug free code [ ] 100% bug free code [ ] 110% bug free code
(I made such a mistake 1.5 years ago only to fix it 3 weeks ago!).
That's nothing. I've fixed a bug like that in a subroutine which had successfully gone through more than 10 years of continuos re-use all across the company. Then mine happened to be the project where all the external conditions (speed of CPU, speed of peripheral device, etc.) were just right to trip the lurking bug. The central code sequence had been exactly the wrong way round all that time.
Yes, that sounds pretty nasty. Mine lived on for a long time undetected. Then, starting at a particular release, it was relatively easy to reproduce (reason remains a big mystery, still). The timing margins addressing an external analog output via the SPI bus were not conservative enough, so that some (one?) of the 12 bits heading towards one of the DAC's banks ended up nowhere or at an identical, separate DAC (there is a chip select there). Because the DAC have a shift register to input the data, even the loss of 1 bit meant huge swings! That was fun to watch :-) but much more fun to see with a scope and solve...
The false (but very widely-held) belief that, because the stuff "works" (sic), it must, therefore, be right...
It has happened to all of us . Here is my 'war story'. http://www.keil.com/forum/docs/thread15893.asp - 8.6K - Nov 8, 2009 Bradford
And Per's even better story. Bradford
"Then mine happened to be the project where all the external conditions (speed of CPU, speed of peripheral device, etc.) were just right to trip the lurking bug."
I am not convinced that it is a bug.
I think it is practically impossible to write completely bug-free code that works under all circumstances.
Instead, we all write code pieces that have "limitations" that unravel under certain conditions. it is our job to document such limitations so that when we are in a circumstance where the limitations become reality, we know that we need to fix the code for that particular application.
You have no idea.
Except this was actually the exact opposite case: blatantly buggy code that still appeared to work under quite a number of circumstances.
If you want details, suffice it to say that when a chip's datasheet says it takes at least time {T} after the falling edge on pin X before pin Y has settled on valid data, what you not do is read Y immediately after pulling down X. You delay it as long as feasibly possible, typically until immediately before pulling down X again.
"when a chip's datasheet says it takes at least time {T} after the falling edge on pin X before pin Y has settled on valid data, what you not do is read Y immediately after pulling down X. You delay it as long as feasibly possible, typically until immediately before pulling down X again."
that's slightly different. here you have a case of a moronic programmer writing a moronic piece of code that would NOT work regardless of cpu frequency, peripheral speed, or any other external conditions, as it is in direct contradiction to the datasheet.
basically, the programmer has no idea of what s/he is doing and that's in direct contradiction to the early statement of the bug being exposed only under the right combination of cpu frequency, peripheral speed / etc.
The programmer just admitted to having written bad code that should never have worked - and yet it did!!
I think most experiences programmers have been in the position, at some point, of looking back at their code and thinking, "how on earth did that ever work??!"
here you have a case of a moronic programmer writing a moronic piece of code that would NOT work regardless of cpu frequency, peripheral speed, or any other external conditions, as it is in direct contradiction to the datasheet.
Sorry, but you still don't get it.
That code does work in its original surroundings. It works by coincidence rather than by design, but still...
The CPU was, in fact, so slow that even a read "immediately" after pulling down the clock was still happening long enough after the clock edge that valid data was available by then.
"That code does work in its original surroundings. It works by coincidence rather than by design, but still..."
not sure about that. sounds like 1) whether it had worked had nothing to do with a) cpu frequencies; b) peripheral speeds; or c) external devices, and 2) the only reason it worked is that the cpu was NOT functioning as it should per the datasheet.
that contradicts the notion that the bug is the result of a) cpu frequencies; b) peripheral speeds; or c) external devices.
"The CPU was, in fact, so slow that even a read "immediately" after pulling down the clock was still happening long enough after the clock edge that valid data was available by then."
that's irrelevant to this discussion, had the cpu worked as described in the datasheet. so the bug here is really the hardware bug, not a software one, except that the moronic programmer couldn't realize it.
the only reason it worked is that the cpu was NOT functioning as it should per the datasheet.
What on earth are you talking about? Hans-Bernhard Broeker presented a perfectly logical explanation for the observed behavior.
except that the moronic programmer couldn't realize it.
Such mistakes are rarely related to one being a moron. Everybody makes mistakes, and as specified already- sometimes it the environment, not the code itself!
On the contrary - it is entirely pertinent!
It is actually quite a common type of mistake - especially when using a "slow" CPU with a "fast" peripheral.
And it is exactly the type of problem that can give the situation of the OP; viz, the code builds fine, works most of the time - but occasionally fails.
It's even likely that the code would work fine in an instruction set simulator like the one in uVision.
"Then mine happened to be the project where all the external conditions (speed of CPU, speed of peripheral device, etc.) were just right to trip the lurking bug." I am not convinced that it is a bug.
Well, I am - unless the "speed of CPU, speed of peripheral device etc." was in combination with code reuse on anoter processor. I have had cases where a bug only showed its ugly face when a peripheral within specs ran slow.
I think it is practically impossible to write completely bug-free code that works under all circumstances. maybe, but not an excuse
Instead, we all write code pieces that have "limitations" that unravel under certain conditions. it is our job to document such limitations so that when we are in a circumstance where the limitations become reality, we know that we need to fix the code for that particular application. this is either total BS or something that refer to reusability of code.
Erik
Remember that datasheet limits just tell you where the behaviour & performance is guaranteed; they tell you nothing about the behaviour & performance outside those limits - other than that it is undefined.
"Undefined" means that anything could happen - including appearing to work for 10 years, and then "suddenly" not working...
"Remember that datasheet limits just tell you where the behaviour & performance is guaranteed; they tell you nothing about the behaviour & performance outside those limits - other than that it is undefined.
"Undefined" means that anything could happen - including appearing to work for 10 years, and then "suddenly" not working..."
are you suggesting that the "slow" speed at which the cpu was running is outside of the spec defined in the datasheet?
or you are speculating on that? as the poster clearly didn't provide that piece of information.
Llllooooooootttttssss of stupid replys and arguments and no answer!!!!!!!
yu people got too much loose time.
thanks guys.
You seem to be as helpless as your code. 110% clueless.
and no answer!!!!!!!
... says the person who asked the original question, and couldn't be bothered to react to any of the answers he got, for 6 full days. Get a life.
No, I'm not speculating - I'm generalising.
"yu people got too much loose time."
For tightening up loose time, tools are not normally on display for the unskilled to just pick up and check out with, but at http://www.mcguckin.com/ you can ask a staff member along with a wink-wink, nudge-nudge, say-no-more type of behavior and they'll get you fixed up in no time flat -- at least that's where I went the first time my time had gone a bit slack -- I think.
I say "I think", because once time got all loose and wobbly, I have vague memories of going to the hardware store to pick up a time-tightener, tightening, then I'm back at the hardware store.
"No, I'm not speculating - I'm generalising."
you are generalizing in a discussion about a specific bug?
have you thought about maybe generalizing somewhere else?
No - it's not a discussion about a specific bug!
Ashley Madison,
Is this your thing? You know, arguing in order to argue? Why not become a philosopher, them?
"No - it's not a discussion about a specific bug!"
is that your generalization again?
GIRLZ.
SIT DOWN AND BE QUIET.
You all do not know to answer my question. You all think you must answer so you look clever. You all hijak my thread. You all think you are the cleverererest. You all score null point only.
All you write tells me you are crazy and you must learn to be quiet.
"You all do not know to answer my question."
You have not asked any question.
Of course that must be "Why not become a philosopher, then?"
You did not ask any question!
Again:
You just showed a few function definitions; you didn't shown how you combine all that into a real program.
You didn't explain what you think should be the "right" answers.
You didn't explain what answers you get - and why you think they are "wrong".
"You all hijak my thread"
Actually, you abandoned your thread!
You showed no interest whatsoever for 6 days - so is it any surprise that it wandered off-topic?!
If you want to keep the thread on-track, it's up to you to engage with the discussion!
View all questions in Keil forum