Forum: Mikrocontroller und Digitale Elektronik MSP430 Taktfrequenz zu niedrig?

Ehm du must den DCO noch Zuweisen.
und den Resistor richtig setzen.
usw,

Der MSP430FR4133 dazu sogar extra Default Settings im Flash(Siehe Bild)
Deine Routine (Toggle) macht unterschiedliche Zeiten, nach jedem 6ten 
Clock
da ein Rücksprung passiert.

Du kannst ja den DCO direkt auf ein Pin Legen zum messen, dazu gibt es 
extra Appnotes von TI

Etwas mehr Angaben wären Hilfreich.
Es gibt übrigens ein Tool von TI womit man den DCO setzen kann.
Einiges findest du unter:
https://www.ti.com/lit/an/slaae38/slaae38.pdf?ts=1652832485339

Und es gibt für 16MHz auch Fertige Konfigurationen von TI Downloadbar.

Da der Chip mehrere Ozilatoren und Clock onboard hat musst du den 
richtigen noch der CPU Zuweisen(SMCLK,MCLK, usw)

Hast du den GCC Aktiv während du misst?

Der kann dir nämlich dazwischen Funken und dein Programm per Interrupt 
unterbrechen.

Das würde zu deinem Fehlerbild passen:

Tim Fuchser schrieb:
> Ebenfalls merkwürdig ist, dass die 6 Takte in einem Loop-Durchgang schon
> zeitlich variieren.


Hilfreich wäre wenn du das Assembler Listing welches der C-Kompiler 
macht posten würdest dort würde man sehen, was der Kompiler tatsächlich 
aus deinem Programm gemacht hat.
(ev Optimiert er dein Programm ja, je nach Einstellung)

Gruß

Nach dem POR sitzt die CPU auf dem LO und nicht auf dem DCO.
Das ist bei fast allem MSP430 so.
Müsste jetzt aber selber mal im DB nachschauen, und das ist mit dem 
Handy (Bin Unterwegs) etwas schwierig.
Aber ich kann wenn ich morgen wieder im Büro bin mal nachschauen.
Aber wie gesagt Default ist normalerweise der Clock der CPU auf dem LO 
Oszilator.
Auch wenn der DCO in den Fehlerinterrupt wegen falschem Setting läuft,
(Etwa 16MHz gesetzt aber nicht genügend Spannung auf der CPU), geht die 
CPU auf den LO zurück.
16MHz macht die CPU erst ab ca. 3.3V

Wenn dein Launchpad den ENERGIA mit drauf hat kannst du übrigens die 
Betriebsspannung des MSP430 setzen!

Welches Launchpad hast du?

PS: habe jetzt grad gelesen das die 1.xx MHz die Default Frequenz ist 
sieht nach Falsche, DCO und/oder FLL setting aus!

Tim Fuchser schrieb:
> In der CPU wird schon eine Instruction pro Taktflanke ausgeführt, oder?

Ja, wenn es ein NOP ist. Ansonsten siehe Abschnit 4.5.1.5 des User's 
Guide.

Tim Fuchser schrieb:
> Danke für die Hilfe. Ich habe es nun mit dem Codebeispiel von TI
> hingekriegt (msp430fr413x_CS_03.c).
Gerne :-)

> Der Hauptfehler war wohl die Messung per Pin-Toggle, statt den MCLK
> direkt auf einen Pin zu legen. Im Screenshot sieht man den Unterschied.
Das kann Tatsächlich zu Problemen Führen, weshalb ich dir dies auch 
Empfohlen hab.

> In der CPU wird schon eine Instruction pro Taktflanke ausgeführt, oder?
Kommt auf die Instrucktionen an. bei Imediate Adressing ja
Als Beispiel:
>     P2OUT = 0x20;
kann entweder vom Kompiler als Direkt adressing oder aber auch als 
Indirekt adressing oder sogar als Indexet usw kompiliert werden (Je nach 
Einstellung) so kann der selbe "C"- befehl entweder in 2 oder eben auch 
in 6 Cyclen ausgeführt werden. Aber auch hier gilt, wenn dumm gelaufen, 
kann es auch 4 x mehr sein (Also 24 Cycles)
Dies trifft dann aber in der FLAHS Version zu.
Da wenn es Zeitkritisch ist muss man beim Kompiler echt auf die 
eingestellten Parameter achten.
Es gilt grad speziell in den Extended Befehlen (werden leider aber nicht 
alle vom GCC-C-Kompiler unterstützt)
Es gibt da durchaus auch Befehle die mal bis zu 64 Taktcyclen brauchen 
können (ja wissen viele nicht)

Etwa der [POPM-A] wenn alle Register vom STACK geholt werden und der 
Stack auf das FRAM oder gar FLASH zeigt.
(Ja das kann man Missbrauchen , um alle Register auf einmal mit 
Festwerten zu Laden).
Dann kann die CPU tatsächlich im Dümmsten Fall 64 Taktcyclen Brauchen !
Es gibt noch andere Kniffels mit den Extendet Befehlen die aber nur 
die XV2 CPU unterstützt, die im  MSP430FR4133 nicht verbaut ist.

> Liegt das Problem daran, dass die GPIO-Peripherie nicht schnell genug
> ist?
Nein, das hat eine Andere Ursache.
Bei 16MHz muss die CPU mit dem Cache arbeiten, da das FRAM Maximal 8MHz 
ohne zu Cachen verarbeiten kann. Die Peripherie wäre eigentlich schnell 
genug.

Aber wie schon oben geschrieben:
>     P2OUT = 0x20;
als Beispiel 1,5xx MHz mit 16MHz MCLOK durchaus ein Resultat aus 10 
Taktcycen besteht der Befehl jeweils 4 Cycles x 2 (jeweils ein 
WaitState) + 2 Cycles für in die Pheripherie zum übertragen.

Zeitkritisches Programmieren ist eine Herausforderung und nicht nur bei 
den MSP430, ich kenne da auch Situationen aus ARM, PENTIUM, ATOM usw µC 
die bei I/O Befehlen mit 100 Cyclen zu buche schlagen.... (Ist aber 
natürlich Worst Case)

> Habe in Erinnerung dass das bei AVR oder PIC nie ein Problem war.
Ist beim MSP430FRxxx auch so, anders bei der MSP430Lxxxx oder 
MSP430Cxxxx oder MSP430Pxxxx Version, den diese sind auf Hyper-Lowpower 
ausgelegt, oder halt OTP usw, und wirklich keine Anfänger-µC's

Aber auch hier gilt, Kommt ganz auf die Programmierung und grad bei den 
MSP430 I/O's, halt auch auf die Beschaffenheit an. es gibt I/O's die im 
speziellen LPM Mode dann auch eine "Bremse" haben, sprich WaitStates 
auslösen. Aber halt auch wieder Sonderfälle.

> https://www.ti.com/tool/MSP-EXP430FR4133
Da gibt es auch noch Sonderfälle, es kann ganz dumm laufen, das dir der 
Debugger noch eine Bremse reinhaut, nämlich dann wenn er nach jeder 
Instruktion Register usw ausliest, oder ev auch im Energy Trace Mode 
ist.
Das EEM (ExtendetEmulationModul) kann ebenfalls Zeit in Anspruch nehmen.

Ist dann halt auch wieder alles Parameter, Setting usw. abhängig.
So wohl im Debugger als auch in der IDE, oder nicht zuletzt auch wenn in 
der CPU Situationen vorkommen, die sie Ausbremst, können auch Interrupts 
usw sein.(Siehe unter Virtual- oder Software- Breakpoints)

Ich arbeite nicht mit dem GCC, sondern vorwiegend mit dem IAR. deshalb 
kann ich dir da nicht mit Sicherheit sagen, was der GCC im µC alles 
setzt.
Aber aus der Erfahrung vom IAR, ist es ein großer Unterschied ob ich es 
im DEBBUG, oder LIBRARY, oder im EXECUTABLE-Mode kompiliere.

PS: Diese Angaben ohne Gewähr, habe mit dem Handy an Geslossener 
Barriere schnell geantwortet, keine Zeit zur Verifykation ...LOL

@[Tim Fuchser]

Kleines Experiment für dich:

Schreib das Programm so um dass es vom FRAM ins RAM Kopiert wird.
und führe es dan im RAM aus und vergleiche was heraus kommt. :-)

Kleiner Tipp:
RAM unterstützt 16MHz FRAM nur 8MHz!

Ganz extrem wird es wenn du einen 25MHz MSP430 mit Flash ferwendest, und 
das selbe Experiment machst. das können dann regelrecht "Welten" sein 
;-)
Vor allem dann wen das Programm zu groß für das Cache, des MSP430 wird 
:-)

73 55

Also bim kurz Drüberschauen:
1.) Tim Fuchser schrieb:
> Danke für die ausführliche Antwort, echt spannend!
Gerne :-)

2.)Tim Fuchser schrieb:
> Die Laufzeiten lassen sich jetzt abzählen: 3 Cycles high, 4 Cycles low,
> 6 für den jmp. Ich verstehe leider noch nicht ganz, wie diese zustande
> kommen, vorallem wieso das Setzen auf Null länger dauert.
Nein, eigentlich ist korrekt:
>  mov.b  #0x00, &0x0203 ->= [clr.b  &0x0203]
Braucht 3 Cycles
>  mov.b  #0x20, &0x0203
braucht 4 Cicles
Siehst du wen du das Listing ansiehst:
>    2018:       c2 43 03 02     mov.b   #0,     &0x0203 ;r3 As==00
ist eigentlich ein Registred MOV oder auch Emulatet CLR Befehl,und 
ist daher schneller
>    201c:       f2 40 20 00     mov.b   #32,    &0x0203 ;#0x0020
>    2020:       03 02
Ist der Tasächliche MOV Befehl
Daher rührt der Unterschied.

3.)Mann könnte das Ganze noch Optimieren wenn man z.B. P2.0 verwenden 
würde,
und nicht unbedingt den [MOV.B #XX,&YYYY] verwendete

Um Dir zu zeigen was wann Passiert mal ein Ausschnitt
Aus dem User's Guide:

1

Instruction      Cycle   Byte    Emulatet

2

MOV.B #00h,&TONI   3       2     CLR  &TONI-> MOV R3,&TONI

3

MOV.B #32h,&TONI   4       3

Und im Billd was wann Passiert.

Tim Fuchser schrieb:
> Das deshalb, weil dann auch der Constant Generator (also R3 mit As==01)
> verwendet werden kann? -> Register MOV (3 Zyklen)

Richtig, du lernst schnell :-)

Und wenn man es noch schneller machen will, nimt man nicht den MOV 
befehl, da man so beispielsweise mehr Programmstepps braucht.....

Kleine Denkaufgabe für dich:
1.)...Was wäre die Alternative zu 2 unterschiedlichen MOV befehlen?
2.)... kann ich den Befehl auch auf 2 Taktzyklen Verkürzen?
3.)... wäre es auch möglich Ohne den MCLK direkt auf einen Pin zu legen,
       ein MCLK/2 auf ein Pin zu haben,
       ohne dass die CPU keine Zeit mehr, für andere Aufgaben hat?.

73 55