stm32f103 1 us Systick-timer delay

also du meinst einen extra timer dafür zu verwenden ? ist der 
systick-timer nicht auch einfach nur ein timer ? ich habe mit dem TIM2 
mal n bisschen rum gespielt(hat auch funktioniert, allerdings habe ich 
nicht getestet, wie weit man runter gehen kann), da ich bei stm32 bisher 
noch nicht viel mit timern gemacht hab.

ein Datenbit ist physikalisch 80uS lang( nachgemessen). ganz genau muss 
es vermutlich nicht sein. ich hatte halt gehofft, dass ich das reltiv 
modular hinbekomme (also am besten als lib die man nur noch einbinden 
kann wenn man sie braucht, der uC soll am ende so variable wie möglich 
für evtl. verschiedene Temperatursensoren, ... verwendbar sein

Ich müsste also einen timer im Input Capture-Mode verwenden, der bei 
jedem flankenwechsel die zeit misst. allerdings müsste ich dann zu jeder 
messung wissen ob 1 oder 0

Ich habe mir vor einiger Zeit mal was gebastelt und es funktioniert 
bisher sehr gut. Hier für den STM32F103:

1

//********************** DWT_Delay_us ********************************

2

#define DWT_Korrekturwert 20 

3

uint32_t DWT_Scale;

4

inline static void DWT_Delay_us(uint32_t microseconds) {

5

  uint32_t DWT_Startwert = DWT->CYCCNT;

6

  uint32_t ticks = (microseconds * DWT_Scale) - DWT_Korrekturwert; 

7

  while ((DWT->CYCCNT - DWT_Startwert) < ticks);     

8

}

9

//********************** DWT_Delay_us ********************************

10

11

int main(void)

12

{

13

   //********************** DWT_Delay_us ********************************

14

  DWT_Scale = (HAL_RCC_GetHCLKFreq() / 1000000);   // Berechnung des "Vorteilers", für Takt pro Microsekunde

15

  CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;  // Initialisierung des DWT

16

  DWT->CYCCNT = 0;                  // Initialisierung des DWT-Counter

17

  DWT->CTRL = ENABLE;                // Initialisierung des DWT-Counter

18

  //********************** DWT_Delay_us ********************************

19

20

while (1)  {

21

22

   DWT_Delay(5);

23

}

24

}

Danke für den Tipp, werde ich noch einbauen.
Bisher hatte ich immer Glück :-)

Viele Wege führen nach Rom, aber von ASM habe ich keine Ahnung.
Die obige Lösung funktioniert bei mir bisher tadellos.

Ich habe mich natürlich verschrieben.
Das Delay wird natürlich so aufgerufen:

1

DWT_Delay_us(5);

Nachgemessen habe ich indem ich einen Pin getoggelt habe. Die Zeiten 
stimmen ziemlich genau.
Natürlich indem ich direkt das BRR und BSRR-Register beschrieben habe.
Verwendet man die HAL-Funktionen zum Pin toggeln, merkt man auf einmal 
wie langsam die sind.

Also den DWT kannte ich bisher noch nicht. Ich werde vielleicht erst mal 
kucken ob ich nicht einen der Timer im Input-Capture verwenden kann 
(wenn man sie schon hat).

Mir stellt sich nur die frage ob der Input-Capture-Mode der richtige 
ist. Ich habe da im Reference-Manual auch noch was von External-Trigger 
gelesen. Das gesamtbild wie dies alles zusammenhängt ist mir noch nicht 
ganz klar. ist der ETR ein extra mode/ eingang oder was soll das ganze.

Ich will mir einen Sensorknoten bauen, der über eine weitere serielle 
Schnittstelle mit anderen Sprechen kann(kleiner Linux-Rechner / andere 
uC). Dafür soll der Knoten mit verschiedenen Sensoren arbeiten können 
(was halt grad da ist). Die Abfrage sollen quasi über seriell von 
anderen Stellen kommen, so nach dem Frage-Antwort-Prinzip(die Abfrage 
des Sensors, muss also nicht in einer Endlosschleife immer wieder 
passieren)

Den DWT kann ich mir ja mal anschauen für was der denn überhaupt da ist

Die ARM kehren bei hoher Interruptlast nicht mehr zum Main zurück, das 
Main stoppt quasi.
Im Unterschied zu den 8051 oder AVR, wo nach jedem RETI mindestens ein 
Befehl des Main ausgeführt wird.

Ich bin eigentlich eher ein Fan von direktem verwenden der CMSIS. Das 
ist das was mir beim AVR früher immer gefallen hat. es war zwar etwas 
mehr einarbeitung erforderlich, aber dabei hat man das soweit verstanden 
wie die Dinge funktionieren.

Bei st geht es eher in die richtung sich alles generieren zu lassen. In 
letzter Zeit befasse ich mich wieder mehr damit direkt die Register zu 
beschreiben wenn möglich.

Vielleicht muss ich mir echt mal ein template-projekt pro stm32-typ 
basteln, dass nur das nötigste (makefile, startup, cmsis, ...) enthält 
und diese mit libs nach und nach erweitern, bei denen ich dann weiß was 
sie tun (und vor allem dass sie tun)

Roland H. schrieb:
> Also den DWT kannte ich bisher noch nicht. Ich werde vielleicht erst mal
> kucken ob ich nicht einen der Timer im Input-Capture verwenden kann
> (wenn man sie schon hat).
>
> Mir stellt sich nur die frage ob der Input-Capture-Mode der richtige
> ist. Ich habe da im Reference-Manual auch noch was von External-Trigger
> gelesen. Das gesamtbild wie dies alles zusammenhängt ist mir noch nicht
> ganz klar. ist der ETR ein extra mode/ eingang oder was soll das ganze.
>
> Ich will mir einen Sensorknoten bauen, der über eine weitere serielle
> Schnittstelle mit anderen Sprechen kann(kleiner Linux-Rechner / andere
> uC). Dafür soll der Knoten mit verschiedenen Sensoren arbeiten können
> (was halt grad da ist). Die Abfrage sollen quasi über seriell von
> anderen Stellen kommen, so nach dem Frage-Antwort-Prinzip(die Abfrage
> des Sensors, muss also nicht in einer Endlosschleife immer wieder
> passieren)
>
> Den DWT kann ich mir ja mal anschauen für was der denn überhaupt da ist

Hallo,

die DWT (Data Watchpoint and Trace Unit) ist im ARM Cortex Reference 
Manual dokumentiert.

Wie der Name schon impliziert, ist es eigentlich ein Submodul des Cortex 
Kerns, dass zum Debuggen und nicht zum normalen Programmablauf genutzt 
wird. Der Cycle Counter ist dazu da, einen Watchpoint nach einer 
programmierbaren Anzahl von Zyklen nach Auftreten eines Events (z.B. 
schreibenden oder lesenden Zugriffs auf eine definierbare 
Speicherstelle) auszulösen.

Der Cycle Counter ist allerdings der am feinsten granuliebare Timer, den 
der Kern bietet (genauer als auf Einzelzyklenbasis geht's nicht), 
weswegen er auch gerne zu Allen möglichen Anderen Zwecken genutzt wird.

Eines der Dinge, die man bei der Nutzung im Auge behalten muss ist dass 
der Cycle Counter von vielen IDEs und Debuggern genutzt und zuweilen auf 
0 gesetzt wird (um Time Stamp Deltas bilden zu können). Also nicht 
wundern, wenn sich ein Programm, das den DWT Cycle Counter nutzt, unter 
Debuggerkontrolle plötzlich Anders verhält als im Normalbetrieb!

STM Apprentice schrieb:
> Ruediger A. schrieb:
>> Eines der Dinge, die man bei der Nutzung im Auge behalten muss ist dass
>> der Cycle Counter von vielen IDEs und Debuggern genutzt und zuweilen auf
>> 0 gesetzt wird
>
> Genau das sollte gelinde gesagt eben niemand tun, so wie es
> viele andere ungeschriebene Regeln gibt. Was sollte es auch
> für einen triftigen Grund geben gerade diesen Zähler auf Null
> zu setzen? Kann mann ihn doch durch einfache Differenzbildung
> zum Auswerten für seine "eigenen Zwecke" nutzen.
>

Ja, wäre schön, wenn sich Alle daran hielten würden... leider aber hat 
sich auch in "seriösen" Kreisen die Folklore eingebürgert, von 0 aus zum 
Sollwert hochzuzählen, z.B. hier:

http://embeddedb.blogspot.de/2013/10/how-to-count-cycles-on-arm-cortex-m.html
https://stackoverflow.com/questions/36378280/stm32-how-to-enable-dwt-cycle-counter

mglw. auch mit dem Gedanken im Hinterkopf, dass sich damit auch der 
statistisch recht unwahrscheinliche aber mögliche Fall des wraparound 
praktisch elimineren lässt. Ich stimme aber mit Dir darin überein, dass 
sampling on the fly und Deltabildung die bessere Variante ist (zumal die 
Anzahl Zyklen zwischen faktischem Nullsetzen und Anfang des zu 
samplenden Codes auch zwischen Compilern und Optimierungsstufen variabel 
ist und damit das Ergebnis mglw. verfälscht).

> Auch ein Debugger sollte das schaffen. Der ST-Link z.B. verhält
> sich diesbezüglich korrekt, der J-Link (denke ich, gerade nicht
> überprüft) auch.

Ich schrieb von Debuggern, nicht debug probes... Je nach 
"Eigenintelligenz" leiten die probes die Registerzugriffe der Debugger 
mehr oder weniger 1:1 vom Debugger zum Target durch. M.W. nach (könnte 
da aber falsch liegen) hat der ST Link so gut wie keine autarke 
Registersteuerung.

Ist es denn wirklich notwendig, für irgendwelche simplen µs-Delays 
dermaßen in die "Trickkiste" zu greifen und die Debug-Resourcen 
anzuknabbern?
Der Controller hat ja nun wirklich auch ein paar "normale" Timer, die 
das problemlos leisten können. Da scheint es mir schon zweifelhaft, 
sowas wie die Nutzung des DWTs dafür hier Anfängern quasi als 
"Musterlösung" zu präsentieren...

Thomas E. schrieb:
> Ist es denn wirklich notwendig, für irgendwelche simplen µs-Delays
> dermaßen in die "Trickkiste" zu greifen und die Debug-Resourcen
> anzuknabbern?
> Der Controller hat ja nun wirklich auch ein paar "normale" Timer, die
> das problemlos leisten können. Da scheint es mir schon zweifelhaft,
> sowas wie die Nutzung des DWTs dafür hier Anfängern quasi als
> "Musterlösung" zu präsentieren...
Das wäre auch immer noch die Lösung die ich aktuell im Auge habe. Ich 
habe doch ein paar Timer. Wozu diese also nicht mal benutzen.

Der Input Capture mode nütz mir aber auch nichts wenn ich nur von 
steigender zu steigender flanke messen kann. Das entsprechende 
kapitel/register hab ich im Reference-Manual leider noch nicht gefunden

1.
Es scheint mir der DWT-Counter wird vom Debugger gestartet und wenn kein 
Debugger verwendet wird läuft der DWT-Counter garnicht.
Das schließe ich daraus, dass ich den DWT-Counter einmalig von Hand 
anwerfen muss. Sonst funktioniert die DWT_Delay_us-Funktion nur wenn der 
Debugger angeschlossen ist.

2.
Auch erscheint es mir sinnvoll den DWT-Counter nicht zu manipulieren 
(auf 0 setzten), sondern nur zu lesen und das Delay durch 
Differenzbildung zu realisieren.

3.
Interrupts von wenigen Takten machen nur Probleme.

4.
Eine vorgegebene Taktanzahl in einer Schleife zu vertrödeln mag ich aus 
folgenden Gründen nicht:
-Delay ändert sich bei Änderung des uC-Taktes
-Delay ändert sich je nach Optimierungsgrad

Darum verwende ich das DWT-Counter-Dalay solange ich keine bessere 
Lösung kenne:
Ich benutze einen (ansonsten ungenutzten?) geeigneten Counter den ich 
nicht einmal manipuliere, sondern nur lese.
Es werden keine problematischen Interrupts gebraucht und ich muss mir 
keine Gedanken um Optimierungslevel und Taktfrequenz machen. Ich 
"verbaue" mir keinen Timer, den ich vielleicht doch nochmal brauche.
Und es ist mit 2 copy und paste-Aktionen implementiert.


Roland möchte es gerne mit einer anderen Lösung versuchen.
Ich nutze in Zukunft auch gerne eine andere, "bessere" Lösung.

Dazu müssten aber auch Lösungsvorschläge kommen.

Ein: "...das kannst du so nicht machen, weil..."
ist ja gerechtfertigt und auch gewünscht.
Aber dann sollte folgendes kommen:
"... mach es lieber so, weil..."

Und dieses "... mach es lieber so, weil..."
vermisse ich leider immer öfter.

Ich freue mich auf Lösungs/Verbesserungsvorschläge.

Gruß Daniel

Roland H. schrieb:
> Der Input Capture mode nütz mir aber auch nichts wenn ich nur von
> steigender zu steigender flanke messen kann.

Doch. Man kann ja z.B. die Flanke nach jedem Capture Interrupt toggeln.
Oder eleganter: Den "PWM input mode" nehmen. Im Reference Manual Kapitel 
15.3.6, bzw. 14.3.7.

Wenn auf fallende Flanke getriggert wird, bekommt man im CCR1 der 
Zählerwert für die gesamte Bitlänge, und im CCR2 für die Low-Phase. Die 
High-Phase ist dann die Differenz (CCR1-CCR2).

Die Timerwerte können auch per DMA im RAM abgelegt werden und erst nach 
der kompletten Übertragung ausgewertet werden.

Daniel B. schrieb:
> Ich benutze einen (ansonsten ungenutzten?) geeigneten Counter den ich
> nicht einmal manipuliere, sondern nur lese.

Eben, das Fragezeichen setzt Du ja schon selbst - ich würde mal 
vorsichtshalber davon ausgehen, daß der Timer evtl. beim Debuggen 
verwendet und u.U. auch vom Debugger gelöscht werden könnte.

Daniel B. schrieb:
> Es werden keine problematischen Interrupts gebraucht und ich muss mir
> keine Gedanken um Optimierungslevel und Taktfrequenz machen.

Muss man bei einem TIMx auch nicht.

Daniel B. schrieb:
> Ich
> "verbaue" mir keinen Timer, den ich vielleicht doch nochmal brauche.
> Und es ist mit 2 copy und paste-Aktionen implementiert.

"Verbaut" ist der Timer ja auch nicht. Die 4 CC-Units kann man ja für 
andere Zwecke benutzen. Meist hat man ja sowieso mindestens einen frei 
durchlaufenden Timer in Benutzung, den man dann für ein µs-Delay einfach 
mitverwendet. Wenn der (16-bit)Timer zufällig eh auf 1 MHz Takt nach 
Prescaler eingestellt ist, ist usDelay dann einfach:

1

void usDelay (uint16_t us)

2

{

3

  uint16_t temp = TIMx->CNT + us;

4

  while((TIMx->CNT - temp) & 0x8000);

5

}

P.S.: wenn ich das richtig sehe, hat Deine Funktion oben übrigens ein 
Problem mit Timer-Überlauf...

Thomas E. schrieb:
> daß der Timer evtl. beim Debuggen
> verwendet und u.U. auch vom Debugger gelöscht werden könnte.

Kann schon sein. Aber stört das beim debuggen?


Thomas E. schrieb:
> P.S.: wenn ich das richtig sehe, hat Deine Funktion oben übrigens ein
> Problem mit Timer-Überlauf...

Das sehe ich genauso.
Seit zwei Wochen frage ich sekündlich zwei DS18B20 ab und gebe die Werte 
auf ein HD44780.
In beiden Routinen wird das DWT_Delay benutzt wird. Mich wundert auch 
ein wenig, dass ich noch keine einzige Fehlmessung hatte.


Es ist nicht MEINE Lösung.
Es ist nicht mal meine eigene Geistesleistung, den DWT-Counter für sowas 
zu verwenden.

Roland hat nach einer Lösung gesucht und ich habe ihm gesagt, wie es bei 
mir funktioniert.
Wenn er will kann er es verwenden bis er was Besseres gefunden hat.

Ich bin kein Profi, deswegen freue ich mich über jede lehrreiche und 
produktive Diskussion in der die Vor-/Nachteile der unterschiedlichen 
Delays zur Sprache kommen.

Ich probiere dein Timer-Delay auch aus, vielleicht wird es mein neues 
Standard-Delay :-)

Gruß Daniel

Naja, wie schon mehrmals hier erwähnt wurde, ist die Nutzung des DWT als 
"normaler" Timer etwas fragwürdig. DWT heißt Data Watchpoint and Trace 
und ist eigentlich ein fürs Debugging dediziertes Modul.

Es läßt sich wirklich jeder Cortex M Timer dafür verwenden, einen 
Zyklengenauen Zähler und Verzögerer zu implementieren. Dazu muß der 
Timer nur als freilaufend konfiguriert und periodisch der Zählerstand 
abgefragt werden. Es muss nicht die DWT sein, die wird im Zusammenhang 
mit aktiven Debuggern mit hoher Wahrscheinlichkeit Probleme bereiten.

temp schrieb:
> nur leider hat der STM32F103 nicht einen einzigen der 32bit breit ist.

Wenn Du eh die Zeit verwartest, dann reicht ein 16Bit-Timer dicke und 
den höherwertigen Teil erledigt eine profane Zählschleife drumrum.

Abgesehen davon treiben solche elend langen Delays die CPU-Performance 
in den tiefsten Keller, d.h. Dein 32Bit-Bolide wird von jedem 8Bitter um 
Längen geschlagen.

Der Systick Timer des F103 hat immerhin 24Bit.

temp schrieb:
> Die Entscheidung ob die paar Taktzyklen etwas ungenauer machen oder
> nicht kannst du auch mir überlassen. Also was soll dein Genöle? Die
> die's interessiert werden da raus nehmen können was wichtig ist

Weshalb gleich so pampig?
Der Hinweis auf diese Ungenauigkeit war sicher nicht bös gemeint und 
würde Anfängern, die das nicht sofort durchschauen, ja durchaus helfen.

temp schrieb:
> Weil ich Oberlehrer nicht ausstehen kann.

Und das sagt ausgerechnet der Oberlehrer vom Dienst.
Ich wußte nicht, daß Du nen uralten Thread ausgräbst, nur um andere zu 
beleidigen. Dann hätte ich mir meinen Beitrag natürlich verkniffen.
Belehre bitte andere.

temp schrieb:
> Peter D. schrieb:
>> Der Systick Timer des F103 hat immerhin 24Bit.
>
> Der wird aber in der Regel immer verwendet und läuft auch nicht durch.

Meistens steht ein krummer Wert im reload-Register, deshalb muss man den 
"Überlauf" extra behandeln. Oder bedeutet "läuft nicht durch" noch was 
schlimmeres?

Und vielen Dank für den Tipp mit dem Debugger!