Great points Jim. Thanks.
I've seen a couple of places in the TI code where I didn't think the
functionality was well thought out, and after porting the code my intent
is to go back and refine some areas. On the other hand, there are a
couple of areas that I should change not, rather than later, as they are
causing me delays in my goal (for example, not using the
__even_in_range function for a single case statement will allow me to
move on to other more pressing issues).
BTW, I consider you like the old E.F. Hutton commercials (showing my
age) - when you speak, I listen.
Paul.
On 6/14/2010 6:12 AM, JMGross wrote:
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
