Warteschleifen für STM8-Controller?

[Third E. (third-eye)]

Hallo,

ich mache gerade meine ersten Gehversuche abseits der AVR-Welt mit einem 
STM8S Discovery-Board.
Bisher habe ich ausschließlich AVRs programmiert.
Ich verwende das ST Visual Develop in Kombination mit einem Raisonance 
Compiler.

Mein erstes "Hello World" in der Mikrocontrollertechnik (= blinkende 
LED) läuft schon.
Allerdings habe ich eine primitive Warteschleife selber programmieren 
müssen, weil ich kein Äquvalent zu "_delay_us" und "_delay_ms" gefunden 
habe.
Gibt es da sowas?

Gerade für Wartezeiten, wo die Genauigkeit unkritisch ist, habe ich 
bisher sowas immer verwendet.
Z.B. habe ich immer gerne eine Power-On-Wartezeit von z.B. einer halben 
Sekunde, sodass die angeschlossene Hardware garantiert eingeschwungen 
ist, bevor der Controller loslegt.

Wie könnte man sowas ähnlich einfach implementieren wie die 
"_delay_xx"-Funktionen?

Danke.
Third-Eye

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Beim STM32F4xx mit 168MHz wäre es das:

void uDelay(const uint32_t usec) {
  uint32_t count = 0;
  const uint32_t utime = (120 * usec / 7);
  do {
    if (++count > utime) {
      return;
    }
  } while (1);
}

void mDelay(const uint32_t msec) {
  uDelay(msec * 1000);
}

Für Deinen müsstest Du die Zahlen wohl etwas verringern. (Oder suchen 
nach "uDelay" in den Demos von ST.)

[Norbert M. (Gast)]

Im STM8-Circle hat sich jemand schon drüber gedanken gemacht:
http://www.stm8circle.com/forum/viewtopic.php?pid=57234

LG, N0R

[Falk B. (falk)]

@ Markus Müller (mmvisual)

>Beim STM32F4xx mit 168MHz wäre es das:

Einfach mal as schnell hinschreiben ist selten eine gute Lösung.
Schau dir an wie das der avr-gcc macht, nämlich zweistufig. Zu zwar in 
der Form, dass es Funktionen/Macros gibt, die mit konstanten Parametern 
zu exakten Zeiten führen. Auch bei kleinen Verzögerungszeiten. Denn 
deine Division gibt es auch bei den meisten STM32 nicht umsonst in 3 
Takten, das ist alles per Software gerechnet.

[Norbert M. (Gast)]

Norbert M. schrieb:
> Im STM8-Circle hat sich jemand schon drüber gedanken gemacht:
> http://www.stm8circle.com/forum/viewtopic.php?pid=57234

Hmm, da ist wohl etwas mit dem Link schiefgelaufen.
http://www.stm8circle.com/forum/viewtopic.php?pid=5723

[Michael K. (Gast)]

Bau Dir einen 1ms system timer und mach z.B sowas in der IRQ
--t_100ms;
if (!t_100ms) {t_100ms = 100; flag_100ms = 1;}

Das Flag wertest Du in der main aus und setzt das nach Bearbeitung
zurück.
So brauchst Du nur einen Hardwaretimer für beliebig viele Zeiten und 
kannst parallel beliebige andere Sachen machen.

Die Seite hat mir beim STM8 Einstieg geholfen.
http://benryves.com/tutorials/stm8s-discovery/
Erst da habe ich halbwegs verständlich erfahren wie ich mir alles das 
zusammensuche was ich brauche und wie man z.B. IRQ Routinen erstellt 
weil die ST Seite anscheinen von der Konkurrenz erstellt wurde, anders 
kann mich mir das nicht erklären.

Das ST.com Forum ist tot und dem Support zu mailen ist sinnlos.
Die 'STM8S_StdPeriph_Driver' sind teilweise ganz nützlich und teilweise 
ziemlicher Mist der überhaupt keine Arbeit abnimmt oder sogar falsche 
Einstellungen macht.
Manches geht ganz einfach nicht über die LIBs so das man ohnehin direkt 
auf den Registern rumackern muß was so gut oder schlecht geht wie bei 
jeder MCU.
Die Datenblätter sind ok.
Die Peripherie-Schaltbilder sind viel zu grobe Blöcke und dürften gern 
so detailiert wie bei Microchip sein, denn die Setting sind teilweise so 
umfangreich das sich der Sinn in Textform nur schwer erschließt.

Ich verwende den IAR in der kostenfreien 8K Version weil ich mich weder 
mit Raisonance noch Cosmic so recht anfreunden konnte.
Beim IAR geht einfach alles ohne Beanstandung auch der für mich so 
wichtige Debugger geht sehr komfortabel und zuverlässig.
Der SDCC kann jetzt wohl auch STM8, falls Du lieber Open Source 
verwendest.

Wechselt man den Footprint vom z.B. K3-Typ (QFN) auf dem Discovery Board 
auf z.B. F3 (tssop20) auf einem eigenen Board muß man die Software 
ändern bzw. spezielle Einstellungen in den Option Bytes machen.
Wenn man es weiß ist das nur ärgerlich, aber ST verliert kein Wort 
darüber.
Wollen wohl die Überraschung nicht verderben

Einige Hardware (TIM1 ...) wird erst auf die Pins geroutet wenn man die 
Option bytes ändert. Mit dem ST Visual Programmer hat das 'irgendwie' 
nicht geklappt aber dafür mit dem IAR.
Schön ist der Timer dann einfach nicht die Kontrolle über einige Pins 
erlangt was eine recht herzerfrischende Fehlersuche nach sich gezogen 
hat.

Über den ST Visual Programmer kann ich z.B. auch kein erase machen.
Ausgegraut, nicht herauszufinden warum.
Überschreiben kann ich alles, wobei der F3, K3 und einige andere 
Controllertypen nicht auseinander halten kann.
Es ändert sich zwar die Funktion der Option bytes, aber sonst ist alles 
die gleiche Suppe für diese komische ST Software.

So sehr sich ST auch bemüht hat den Einstieg zum STM8 möglichst steinig 
zu gestalten, wenn man das hinter sich hat und möglichst nicht mehr den 
kleinsten Fitzel Software von ST verwendet, dann macht der Chip Spaß.
Kann wirklich viel (für einen kleinen 8bitter), kostet wenig.

Wertung:
Billige Hardware dafür nicht so das flauschige wohlfühl Ambiente wie bei 
den AVRs sonder eher ein bisschen krank und nerdig wie bei den PICs nur 
ohne die gute IDE und die freien C-Compiler.