----- Ursprüngliche Nachricht ----- Von: Frédéric Sureau Gesendet am: 23 Aug 2010 21:39:51
> I compile my blink led program code (attached) for the msp430f5529 > using mspgcc4 with option mmcu=msp430x5418. > The result is that the led is blinking too fast. I thought it was that > the delay was too short so I tried to change the delays in "for" > loops, but it's still blinking too fast. The typical FOR delay loop is dead code. Any good optimizing compiler will detect that the loop does nothing. The usual hint to use a volatile variable for the loop won't work for local variables. Because the compiler can still detect that nobody else can possibly have a reference to this variable and therefore the volatile keyword is void. 'volatile' does not mean 'don't optimize' or 'this variable has side-effects'. These are only side-effects. It originally means that this variable may be read or set from outside the program flow. Which it obviously cannot happen if nobody has the reference. The tip to use 'NOP()' inside the loop is far better. Since NOP is a volatile instruction, it ensures that at least the NOP command is executed the given number of times. The loop itself may still be optimized (e.g. dividing the loop count by 10 and executing 10 NOP instruction in a row each loop) It's by far better to use a timer for a loop. Once the timer is initialized properly (and on the 5x series you can always use the REFO clock as a known clock and usually DCO as 1MHz source, at least after some startup time), you can set delays of a really known length which does not depend on CPU speed or compiler optimization. With a plain vusy-waiting for-loop, there' sno way to say how 'fast' it will be. So even your statement 'blinking too fast' is void, as 'fast' is highly relative if you don't use any proper and stable reference. > When removing the main loop ( while(1) ), the led is just flashing one > time very shortly independently from the delay duration. > Then a friend using mspgcc3 with the patch for msp430f5529 tried to > compile my code and it works just fine. > He also tried to use mmcu=5418 and the same problem appeared. interesting. Do the two processors have the same memory layout? I can imagine that if the 5529 has no ram where the 5418 CPU setting assumes it, you might run your program with the stack in vacant memory or flash. This will probably incluence the loop - either the loop is always at its end or never, as you cannot increment/decrement the loop variable if it is placed on stack. it's also possible that you don't 'run' your code at all but instead experience repeated resets which let the LED appear flashing. > Maybe using msp430x5418 instead of msp430f5529 makes some incompatible > initialization ? I shouldn't. The cpu selection parameter does not have much influence to the CPU. It activates some CPU errata fixes and enables or disables the use of the hardware multiplier if the CPU is know to have/haven't one, but that's all. No initalisation of any CPU component is caused by this. It does, however, influence which header files are included by io.h and which memory mapping set is used by the linker. Nothing of this has influence on your code.
