This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nid help on LED blinking

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!

Parents
  • 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.

Reply
  • 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.

Children
No data