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
"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.
2) the only reason it worked is that the cpu was NOT functioning as it should per the datasheet.
Interesting how you assume to know whether or not my CPU here was functioning acccording to its data sheet. Particularly since you certainly don't have the slightest which CPU that might even was.
that contradicts the notion
The "that" you're referring is pure speculation on your part, so there's no way it can contradict anything.
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.