i have problem with the led blinking. I using the exmaple program given by keil using uVision3. When i run the program, the LED on the development board didnt blink, it just stay on! wat should i do?
thanks!
#define N M+5 Always( always( always ) ) use parenthesis.
#define N (( ((M)) + ((5)) )) // (over) (use) (them) (!)
Its in the book; on page( PARENTHESIS ) to be exact.
It would be quite interesting the see the full code monkey rule set.
Its basically standard stuff; a racy jacket, a steamy intro, the main characters are shallow, has a thin plot line, lots of typos, and has a dry, monotone-ish narration.
In the end you are either a satisfied or you're left needing more.
<excerpts from "Rules for Code Monkeys"...>
Thou shalt not use Hungarian Notation. Thou shalt not use 'internet' code; unless an assignment is due, and the teacher can't tell the difference anyway. Thou shalt not kill (depending upon the project specifications) Thou shalt not use the closing bracket ']' symbol without first declaring allegiance to King Kong or saying several "Hail Fay Wray"s. Thou shalt not ramble-on-and-on in forums. etc.
You know, the standard stuff.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
Yes, I know that you hate macros.
I felt that I had to write that example just because the people in most need of good advice about symbol names and sw comments are quite likely to do produce such #define'd constructs.
A #define'd expression without parentheses is definitely one of the mortal sins of programming - it doesn't matter if it is production code or just some test code.
Another is to hide the #define'd symbol by not using capital letters.
Or having a conditional #define that mucks up a dangling else. Or writing code that has a dangling else.
A define that makes use of a parameter more than once is also quite high up on the no-no list. And code that does call a #define while using ++, -- or similar modifying accesses on one or more of the parameters.
I haven't really decided what is the best way to get good developers. - Huge quantities of information. - Give people a bit of help into all kinds of traps and then have them learn why they got into the trap and how to avoid at least that speficic pot-hole in the future.
In the end, hands-on experience with problems is quite efficient. People tend to remember a broken nose far longer than they remember the text in a school book. And they don't doubt the real pain that results from doing something the wrong way. The trick is to not produce permanent damage so they switch to another profession, and not to produce permanent monetary loss.
Thou shalt not kill (depending upon the project specifications)
captain, what about the three rules of robotics... ;-)
They will not be introduced until the positronic brain has been released.
By the way. Asimov later extended with a fourth rule about the good of the many, to avoid freezing and permanently destroyed positronic brains ;)
and, of course, he later introduced the "zero law" as well.
ho, you meant that one!