MSP430 delay-Funktion mit µsec Auflösung

[Dominik S. (sleepingiq)]

Hallo
hat vielleicht schon mal jemand eine delay-Funktion für den MSP430 
geschrieben mit einer µsec genauen Auflösung. Benutze einen 8MHz Quartz.

MFG
Dominik

[Timo (Gast)]

HI,
wenn du nen genauen delay brauchst, dann nehme am besten einen timer, 
der dann eine funktion aufruft oder so
gruß timo

[Dominik S. (sleepingiq)]

Timo wrote:
> HI,
> wenn du nen genauen delay brauchst, dann nehme am besten einen timer,
> der dann eine funktion aufruft oder so
> gruß timo

Hi
ich brauch eine delay Funktion der ich beim aufruf die Zeit in µsec 
(dword) übergebe und nach ablauf dieser wieder zurück kehrt. Was ich 
schon weiß das ich allein durch das aufrufen und zurück kehren schon 
1µsec brauche. D.h. bei sehr kurzen zeiten wird es nicht hinhauen.
Wenn ich einen Timer verwende soll, wie ist da das vorgehen?
Timer laufen lassen und CCR anpassen (Dann müsste ich vorher TAR 
auslesen) oder erst beim aufrufen anlaufen lassen?
Und Wie sorg ich für das zurück kehren (in der ISR ein Flag setzen und 
in der delay Funktion pollen?) oder was giebt es noch für Methoden?
Und was mach ich wenn ich länger warten will als der Timer zum 
überlaufen braucht?

Gruß
Dominik

[Christian R. (supachris)]

Mit einem 8 MHz Quarz ist es einfach:

//-------------------------------------------------------------------------------------------------------
//  void halWait(UINT16 timeout)
//
//  DESCRIPTION:
//    Runs an idle loop for [timeout] microseconds.
//
//  ARGUMENTS:
//      UINT16 timeout
//          The timeout in microseconds
//-------------------------------------------------------------------------------------------------------
void halWait(UINT16 timeout) {

    // This sequence uses exactly 8 clock cycles for each round
    do {
        _NOP();
    } while (--timeout);

} // halWait

Ist aus dem TI-Code für den CC2420.

[Fabio (Gast)]

überprüf wie viele clockcycles der ASM NOP befehl für deinen MSP 
braucht! dann kannst du es herunterrechnen!

[Stefan (Gast)]

@supachris

1.) Auch wenn der Code von TI kommt (oder gerade deswegen...) kriege ich 
immer Bauchschmerzen, wenn mir jemand einen C-Code vorlegt und sagt, 
dieser braucht genau xy Taktzyklen. Das geht nur in Assembler!

2.) Im Übrigen braucht das Ding 5TZ pro Durchgang + 7/8TZ für den 
Funktionsaufruf u. Rücksprung (7/8 je nach Funktionsargument)

[Dominik S. (sleepingiq)]

@Fabio
der Befehl braucht 1 clockcyle

@Christian R.
danke das ist genau was ich gesucht habe. Ist das aus einer von TI 
mietgelieferten header? wenn ja welche?

Funktioniern tuts soweit ganz gut bei angabe von 100 braucht es 716 
Zycklen was einer zeit von 89,5µsec entspricht muss also noch was 
aufaddieren.

Gruß Dominik

[Christian R. (supachris)]

Das ist aus der AN033, die Software für den CC2420 Funk-Chip.

Klar kann man das nur mit Bestimmtheit in Assembler machen. Aber dann 
hast du wieder das Problem, dass du das mit Inline Assembler machen 
musst, denn ASM-Funktionen werden je nach Kompiler auch verschieden 
aufgerufen und dann weiß man wieder nicht genau, was passiert.

Ich glaub, in der oben geposteten version fehlt das volatile vor dem 
UINT16. Ich hab gerade gesehn, dass ich das bei mir drin hab, damit das 
auch mit Optimierung noch stimmt. Naja, TI-Bugs halt. Kennt man ja.

[Joul (Gast)]

Falls Du den IAR Compiler verwendest, kannst Du mit der Intrinsic 
Function "__delay_cycles()" mit relativ wenig Aufwand eine Funktion 
ähnlich der _delay_us() aus der avr-libc konstruieren.
MfG

[Bertram S. (bschall)]

also ich würde ad hoc den Inline Assembler nicht als "ungenauer" als das 
entsprechende C Pendant hinstellen. In solchen Fällen hilft wirklich nur 
eine exakte Analyse des Assemblercodes um eine Aussage über eine 
Genauigkeit treffen zu können!

Ich würd das ganze über einen Timer lösen bei dem ich als 
"funktionsaufruf" das run Bit setze und dann in einer Schleife das auf 
ein entsprechendes CCR Bit warte.