Personally, I strongly discourage the use of this function at all, as the delay depends on the current processor speed. If you port the code to a faster MSP (e.g. moving form the 8MHz 1xx to the 16MHz54xx series or even from the 54xx to the - else identical - 25MHz 54xxA), the delay will shorten and you''l have to check and adjust all the code (or it might break and you'll wonder why). If adjusting is possible at all (e.g. library code used on different CPUs) Using timers is way better, and that's why the MSP has so many :) If you define a system-wide timer that will always initialized to, say, 1MHz. Doing delays then is easy (a simple "TACCRx=TAR+delay;" and wait for the interrupt flag) and will always take the same time. As a side effect, CCR0 can be used for a system timer tick with ease. Normally, you need a certain TIME delay and not a certain CYCLE delay. Also, wehen using a small ISR for the CCR, you can even enter LPM during the delay - if it is long enough for the overhead.
It's a convenient thing when you start and still much better than these for-loops, but you'll get a bad habit with it and it might kill your code when you move on to more sophisticated projects later. JMGross ----- Ursprüngliche Nachricht ----- Von: Paul F. Sehorne An: [email protected] Gesendet am: 12 Jun 2010 06:37:45 Betreff: Re: [Mspgcc-users] mspgcc linking problems porting TI Sports Code to mspgcc Jim, I am taking your suggestion for the __delay_cycles intrinsic function. Thanks for the suggestion. Paul On 6/7/2010 6:00 AM, JMGross wrote: > > I suggest replacing the intrinsic functions by macros or inline-functions > with hand-crafted inline assembly code. > This way, you have full control over the generated assembly code and it can > be written as small as possible. > e.g. the delay function: take the parameter, shift it right by 3 bits and > generate a loop that takes exactly 8 cycles.... > > JMGross
