www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik STM32 - Erster Artikel


Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe einen Artikel über STM32 verfasst.

http://www.mikrocontroller.net/articles/STM32

Es ist mein erster. Ich denke ich habe das mit der Formatierung 
einigermasen hin bekommen. Schreibfehler dürft Ihr gerne korrigieren.

Schreibt, wenn was fehlen sollte ...

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super Sache, mache gerne mit. Hab grad noch nen Link zu der Getting 
startet Appnote dazugefügt.

Gruß
Tom

Autor: Jörg Rupprecht (ruppi66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Markus,

kann mich Thomas nur anschliessen. Habe paar Schreibfehler
entfernt. Bitte Thomas -> PERIPHERIE ;-)))))

Da ich auch beruflich den STM32 einsetze, werde ich versuchen den
Artikel auch mit meinen Erfahrungen zu ergänzen.

Momentan quäle ich mich mit einem PIC24FJ64GB004 herum (da dieser 
einen kleineren Strombedarf hat) und das war ein extremer Abstieg nach 
den letzten STM-Projekten.
Auch Microchip hat eine Lib, allerdings nicht so perfekt wie die von STM 
und enthält auch noch einige unschöne Fehler.
Außerdem sind die Chips zum Teil sehr fehlerträchtig, unbedingt die
Erratas beachten.

Werde, soweit möglich, wieder ein Derivat aus der STM32-Familie in das 
nächste Projekt einplanen. Da ST auch nicht nur Däumchen dreht, kann man 
auf die kommenden Derivate gespannt sein. Hier sollen ja auch noch laut 
ST-Website Low-Power-Derivate kommen.

Für die Hobbybastler gibt es mitlerweile viele kleine Adapter- bzw. 
Headerplatinen, so dass auch dieses "Mango" nicht mehr die große Rolle 
spielen sollte. Der große Vorteil ist, wie Thomas in seinem Artikel auch 
schon hinweisst, die phantastische Library, die jedem viel 
Registerkleinarbeit abnimmt. So kommt auch ein Neuling recht schnell zu 
lauffähigen Programmen mit starker Peripherienutzung.

Gruß Ruppi66

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank. Das ist schonmal ein guter Anfang.

Markus Müller schrieb:
> Schreibt, wenn was fehlen sollte ...

Nur ein paar Kommentare:

"Der STM32 ist ein Mikrocontroller mit einer 32-Bit Cortex CPU von 
ST[...]"

Natürlich wissen wir alle, dass die CPU nicht von ST, sondern von ARM 
stammt :-) Würde ich daher etwas umformulieren.

Außerdem handelt es sich nicht um eine beliebige "Cortex CPU", sondern 
um den Cortex-M3, wie ja auch später geschrieben wird. Oder einen 
Cortex-M, falls es allgemeiner bleiben soll. Die Unterschiede zwischen 
den Cortex Familien sind einfach zu groß, als dass man sie alle über 
einen Kamm scheren kann.

"Hier gibt es den Opcode wenn man ihn in Assembler programmieren möchte: 
http://infocenter.arm.com/help/index.jsp?topic=/co...

Der Link zeigt auf das Architecture Reference Manual der Cortex-A und 
Cortex-R. Der korrekte Link für Cortex-M müsste zum Dokument DDI0403 
verweisen.

Weiter so.

Gruß
Marcus

Autor: thorstendb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leutz,

hab's mal überarbeitet :-)
Ich denke mal ich werde noch so das eine oder andere ergänzen.

VG,
/th.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum ich den Artikel angefangen habe: Ich hatte einfach keine Lust mehr 
immer wieder zu schreiben warum man den STM32 nehmen sollte. Jetzt 
brauche ich bei Fragen nur noch auf den Artikel verweisen :)

Die Infocenter Arm Links habe ich geändert.

Vielen Dank euch allen, ich sehe hier wurde schon sehr viel ergänzt.

Autor: brott (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, danke fuer den Artikel, ueberlege auch schon laenger, mal auf STM 
umzusteigen \ mich zu erweitern.

Eine Frage dazu: laeuft der USBprog von Bendeikt Stauter
(http://www.eproo.de/index.php?module=artikel&actio...)
auch mit ST-Controllern?

Ich verstehe das so, dass mit der entsprechenden Firmeware (OpenOCD) 
laufen sollte.

Wenn da jemand was weisz, waere ich fuer eine Ergaenzung im Artikel / 
Thread sehr dankbar.

thx
brott

Autor: Phil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen sehr, sehr großen Nachteil, vor allem für Hobbyisten, hast du 
vergessen.

Die nicht vorhandene Internetcommunity.

Sollte man heutzutage auf JEDEN fall mit bedenken!!!!

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die entsteht allerdings gerade hier :-)

Autor: Christoph Budelmann (Firma: Budelmann Elektronik GmbH) (christophbudelmann) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Phil schrieb:
> Einen sehr, sehr großen Nachteil, vor allem für Hobbyisten, hast du
> vergessen.
>
> Die nicht vorhandene Internetcommunity.
>
> Sollte man heutzutage auf JEDEN fall mit bedenken!!!!

http://www.stm32circle.com/hom/index.php

Autor: Phil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Burkhart schrieb:
> Die entsteht allerdings gerade hier :-)

Hmm... na gut. Damit das Erfolg hat müssen nur noch sämtliche AVR 
Freaks, Arduinoisten und was weiß ich nich für Boards überzeugt werden.

So als Anhaltspunkt.

Google findet bei STM8 400k Einträge, STM32 400k, Atmega 900k..

Google Video findet bei STM8 41 Videos, STM32 132, Atmega 3310.

Jo. Jetzt kann jeder selbst schlussfolgern, ob man sich als Hobbyist 
wirklich damit rumplagen sollte.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frage ist doch, ob man sich beim STM32 dank der firmware-lib 
wirklich so sehr quälen muss wie bei den anderen ;-)

Autor: Christoph Budelmann (Firma: Budelmann Elektronik GmbH) (christophbudelmann) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Phil schrieb:
> Hmm... na gut. Damit das Erfolg hat müssen nur noch sämtliche AVR
> Freaks, Arduinoisten und was weiß ich nich für Boards überzeugt werden.
>
> Google findet bei STM8 400k Einträge, STM32 400k, Atmega 900k..
>
> Google Video findet bei STM8 41 Videos, STM32 132, Atmega 3310.

Was möchtest du uns damit jetzt sagen? Für viele Projekte reichen 8bit 
Controller völlig aus, für manche andere braucht man eher 32bit bzw. 
macht sich damit das Leben einfacher. Du vergleichst hier Äpfel mit 
Birnen, wer mit den AVRs zufrieden ist, soll die ruhig weiterhin 
einsetzen. Niemand soll hier bekehrt werden.

Christoph - der je nach Anwendung AVR8, MSP430 oder STM32 einsetzt.

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
prima Idee!

2 Bemerkungen/Wuensche von mir:
1.) Kann man die Grafik im Artikel halb so gross machen? Ich muss den 
Browser hier auf Fullscreen stellen und immer noch horizontal 
scrollen...
2.) Bzgl. Tools/Compiler/Programmieradapter: Kann da ein Spezi was bzgl. 
Linux beitragen? Es ist immer ziemlich muehsam, sich auf den verlinkten 
Seite diese Infos rauszuholen (fuer manche Hersteller/Shops scheint 
Linux nicht zu existieren...)

Wie gesagt, kein Gemecker, nur Wuensche :o)

Autor: Lasse S. (cowz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Spricht das nicht für den STM32, dass es dort weniger fragen zu gibt, 
sondern nur 400k Links auf fertige und funktionierende Projekte?

Glaube immer nur der Statistik, die du selbst gefälscht hast.

Ansonsten: Gut, dass es mal nen Artikel dazu gibt. Mir gefallen die 
Prozessoren auch richtig gut! :)

Autor: rechner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Phil schrieb:
> Google findet bei STM8 400k Einträge, STM32 400k, Atmega 900k..
>
> Google Video findet bei STM8 41 Videos, STM32 132, Atmega 3310.
>
> Jo. Jetzt kann jeder selbst schlussfolgern, ob man sich als Hobbyist
> wirklich damit rumplagen sollte.


http://en.wikipedia.org/wiki/Atmel_AVR
> The AVR is a modified Harvard architecture 8-bit RISC single chip
> microcontroller (µC) which was developed by Atmel in _1996_


STM32 gibt es ca. seit 2007(?)


AVR = 3310 Videos / 14a = 236 V/a
STM32 = 132 Videos / 3a = 44 V/a

AVR = 900k / 14a = 64 k/a
STM32 = 400k / 3a = 133 k/a


...mal sehen wie es weiter geht...

Autor: Thomas R. (tinman) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cypress PSOC3 gibts noch nicht wirklich (ES nur), denoch 400k Einträge 
im Google (PSOC5 sogar 270k - und das ist auch Cortex M3 - und den PSOC5 
gibts nicht mal als sammple) ... so viel zum thema statistik

Autor: Phil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich hab ich kein Bock auf digitalen Schwanzvergleich, aber bitte.

Arduino. Seit 2005

Google Video 17.300 Videos...
Google 2.090.000 Einträge

So. Meiner is länger.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin gerade dabei meine erste Schaltung mit dem STM32F103 in Betrieb 
zu nehmen. Ich werde einfach mal berichten, wie schwierg sich das ganze 
darstellt.

Gruß
Tom

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ berndl (Gast)
Zu 1) ist gemacht.

Zu 2) hab leider kein Linux. Sollte mit Eclipse/GCC prinzipiell auch 
gehen
Wenn jemand was weis, bitte erweitern, wenn möglich mit Links wo man die 
SW bekommt

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ berndl (Gast)
Zu 1) Nachtrag
Die Grafik war bei mir angenehm sichtbar. Ich habe einen Laptop mit 1900 
Pixel Bildbreite :)

Autor: diskutator (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Der 10-Polige JTAG-Stecker:
>
> Ich habe einen 10 Poligen Debug-Stecker entworfen, der alle Varianten
> sowie einen UART Anschluss enthält:

Ich würde das nicht so stehen lassen "der alle Varianten enthält" was 
soll das bedeuten? Ich denke die größte Schwäche an deinem JTAG Adapter 
ist die fehlende Möglichkeit den internen Boot Loader direkt 
anzusprechen, d.h. ohne Jumper stecken oder Taster drücken. Es fehlt 
zumindest BOOT0. Eine elegante Lösung gibt es z.B. hier:
Beitrag "STM32 Programmiertool"

Vielleicht kann dieser Thread noch auf den Artikel verlinkt werden, oder 
es wird noch eine Dikussionsseite erstellt (ich weiß nicht wie das 
geht).

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal den Link in de Artikel genommen:
http://www.mikrocontroller.net/articles/STM32#STM3...

Wenn Du Dich damit auskennst kannst Du jetzt diesen Part mit Text 
füllen.


Meine Intension des Debug-Steckers war folgende:
- Debuggen mit OpenOCD/JTAG
- Debug-Ausgaben über UART auf Hyperterminal

Ich habe mir einen eigenen Bootloader geschrieben, der kommt ohne das 
Interne Boot-ROM aus. Ich habe den in die ersten 8KB Flash programmiert. 
Das PC-Programm senden über den UART den Befehl "GoTo Bootloader", damit 
wird mein Bootloader angesprungen. Dann sendet das PC Programm die 
Update-Daten.
Wenn fertig, dann geht es zurück in die Applikation.
Mein Bootloader ist immer beim Einschalten des Boards aktiv. Sobald eine 
Tastenkombination gedrückt wird, bleibt er "hängen" und irgend welche 
LEDs blinken. Also wenn das Flash "Zerschossen" sein sollte kann man mit 
einem Restart/Tasten den Bootloader aktivieren und erneut den Update 
ausführen.
Der ST Eigene Bootloader hat mir nicht gefallen, weil da keine LED's 
Blinken und dem User sagen, "Hallo ich lebe".
Daher brauche ich die BOOT-Pins nicht.
(Wenn die Tasten nicht gedrückt werden, dann springt der Bootloader in 
die Applikation)

Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Phil schrieb:
> Die nicht vorhandene Internetcommunity.

Ähhm, die Foren des Herstellers kennt ihr nicht (oder liegt's am 
Englisch)??

www.st.com > my.st.com > STe2eCommunities > Microcontrollers

Ok, angemeldet muß man schon sein (wie bei TI, Analog und vielen 
anderen), aber das tut nicht weiter weh :-)

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei STM32F1... Controller geht das Flash aber nur bis 24 (evtl 36) MHz. 
darüber muss Waitstates. Angeblich sind gegen JahresEnde 100 bzw 120 MHz 
Flash-Versionen geplant.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, die STM32F103 können bis zu 72MHz
Nur die "kleinen", z.B. STM32F100 bis 24MHz, dafür sind diese eben 
günstiger.

Ja, der Flash benötigt bei mehr als 24MHz waitstaits.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Martin Thomas
Sorry, ich habe nicht ignoriert, dass Sie den OpenOCD Teil gelöscht 
haben, im Gegenteil, ich dachte ein anderer User hat Zeitgleich den Part 
geändert und nach meiner Änderung gepostet und somit den OpenOCD Teil 
wieder (ausversehen) gelöscht.

Bitte poste hier im Forum, dann weiß ich Bescheid wenn es Dir nicht 
gefällt, dass ich ein Link auf Deine Seite setze, dann tu ich den nicht 
mehr "Restaurieren".

Heute wurden mehrmals Änderungen von mir "überbügelt", denn der Artikel 
gibt es seit heute und ohne mein Zutun wurder der bereits doppelt so 
groß.
An diese Stelle auch ein Dank an alle Sub-Autoren :)

Wenn Sie den OpenOCD Teil nicht einfach gelöscht hätten, sondern einfach 
nach Ihren Vorstellungen angepasst hätten (oder hier gepostet), dann 
hätte ich diese Änderung verstanden.

Es ist mein erster Artikel, ich verstehe auch nich nicht ganz wie das 
ganze drum herum funktioniert. Ich habe zufällig einen Eintrag unter 
"Diskussion" von Dir gefunden, mit dem Hinweis auf yagarto.de. Ich habe 
jetzt den OpenOCD-Link entsprechend angepasst und Dir dort geschrieben, 
habe aber keine Ahnung ob es bei Dir ankommt.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Müller schrieb:

> Nein, die STM32F103 können bis zu 72MHz
> Nur die "kleinen", z.B. STM32F100 bis 24MHz, dafür sind diese eben
> günstiger.

MCUA scheint (auch in anderen Threads) der seltsamen Ansicht zu sein, 
dass ein 72MHz STM32 mit 2 Waitstates für praktische Belange zu langsam 
sei, eben aufgrund dieser Waitstates.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe einen Eintrag unter "Nachteile gegenüber LPC1700" rein 
geschrieben. Damit sollte die Sache gerecht sein.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Müller schrieb:

> Ich habe einen Eintrag unter "Nachteile gegenüber LPC1700" rein
> geschrieben. Damit sollte die Sache gerecht sein.

Und ich habe es etwas grade gebogen. Waitstates haben sie beide und 
Bandbreitenproblem hat der STM32 bei seinen 2 Waitstates bei 72MHz 
praktisch keines (8 Bytes alle 3 Takte ist für Thumb-2 noch ungefähr 
ausreichend, beim LPC1700 sind es 16 Bytes alle 5 Takte). Der LPC1700 
kann pro Takt schneller sein, weil er einen kleinen Cache dort sitzen 
hat, der STM32 hat den nicht.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Nein, die STM32F103 können bis zu 72MHz
>> Nur die "kleinen", z.B. STM32F100 bis 24MHz, dafür sind diese eben
>> günstiger.

>MCUA scheint (auch in anderen Threads) der seltsamen Ansicht zu sein,
>dass ein 72MHz STM32 mit 2 Waitstates für praktische Belange zu langsam
>sei, eben aufgrund dieser Waitstates.

nein, wollte nur auf die nötigen waits hinweissen, da das ja nicht 
gerade von Vorteil ist. ST hat diesen wichtigen Punkt (schliesslich ist 
es ein absolutes Leistungsmerkmal) auf Datenblatt auf 1. Seite bei 
Features bewusst vertuscht!

Ansonsten gefällt mir der STM32 auch gut. Aber RX macht dem evtl auch 
grosse Konkurenz. Da gibt es (momentan) den günstigsten Baustein für ca 
2eu.(und das Flash ist schneller)

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RX?
mal Link bitte Posten.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:

> ST hat diesen wichtigen Punkt (schliesslich ist
> es ein absolutes Leistungsmerkmal) auf Datenblatt auf 1. Seite bei
> Features bewusst vertuscht!

Etwas krasse Formulierung. Richtig ist, dass es bei ST im Handbuch zur 
Flashprogrammierung steht und nicht jeder ausgerechnet dort danach 
sucht. Dass sie nicht auf die erste Seite drucken "Leute, nehmt was 
anderes, der hier hat auch gewisse Nachteile" wundert mich weniger. 
Erwartest du das ernsthaft?

Zum Vergleich das, was NXP beim LPC1700 schreibt: "Enhanced flash memory 
accelerator enables high-speed 100 MHz operation with zero wait 
states.". Das sind nun die Waitstates aus Sicht der Programm und die 
stimmen auch nur dann wenn der Cache perfekt funktioniert. Denn das 
Flash selbst braucht bei 100MHz 5 Takte. Das wiederum steht nicht auf 
Seite 1.

NXP hat auf Seite 1 vom Datasheet auch nicht stehen, dass der 10-Bit ADC 
vom LPC1300 keine 8 exakten Bits liefert. Das steht leicht verschlüsselt 
hinten.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Etwas krasse Formulierung. Richtig ist, dass es bei ST im Handbuch zur
>Flashprogrammierung steht und nicht jeder ausgerechnet dort danach
>sucht.
Also wenn das Flash nur mit 1/3 der f lauft, dann muss das meiner 
Meinung nach zumindest irgentwie auf der 1. Seite zu erkennen sein. bsp 
Tabelle oder ähnl, mit Hinw. auf waits bei 72 MHz .o.ä
aber die schreiben gross und breit 72MHz und 1.nochwas DMIPS/MHz, also 
sieht das für einen Betrachter klar danach aus, dass das Flash genauso 
schnell sein muss.(Denn es steht sonst nichts gegenteiliges da)
(Wenn man ein Auto kauft mit xxxPS erwartet man auch, dass der Rest AUCH 
entsprechend ausgelegt ist)

So'nen Zeug gibts bei Renesas (bsp RX) nicht. Wenn da xx drauf steht ist 
auch xx drin, und nicht xx/3 !

(aber kein prg läuft linear)

aber nichtsdestotrotz, wenn das ja stimmt mit den 120MHz geg. Jahresende 
(habe ich vom Distri) wärs halb so schlimm.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:

> Also wenn das Flash nur mit 1/3 der f lauft, dann muss das meiner
> Meinung nach zumindest irgentwie auf der 1. Seite zu erkennen sein.

Es würde einen falschen Eindruck erwecken. Die 2 Waitstates bei 
nichtsequentiell Zugriff zu erwähnen wäre korrekt. Von 1/3 der Frequenz 
zu reden würde jedoch einen schlechteren Eindruck erwecken, als es 
tatsächlich der Fall ist.

Dann ist ST ausserdem harmlos gegenüber NXP, denn die hätten demzufolge 
geradezu kriminell gelogen, indem sie auf Seite 1 von 0 Waitstates 
schwadronieren, statt zu erwähnen, dass das Flash-Mem nur bei 1/5 der 
Taktfrequenz liefe.

> aber nichtsdestotrotz, wenn das ja stimmt mit den 120MHz geg. Jahresende
> (habe ich vom Distri) wärs halb so schlimm.

Jau. Das sind ebensolche 120MHz, wie es bei NXP 100MHz sind. Mit 
soundsoviel Waitstates und etwas Gimmick vorneweg, damit die nicht allzu 
sehr ins Gewicht fallen: "The Adaptive Real-Time (ART) flash accelerator 
enables zero-wait program execution up to 120MHz".

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> aber nichtsdestotrotz, wenn das ja stimmt mit den 120MHz geg. Jahresende
>> (habe ich vom Distri) wärs halb so schlimm.

>Jau. Das werden ebensolche 120MHz sein, wie es bei NXP 100MHz sind. Mit
>soundsoviel Waitstates und etwas Gimmick vorneweg, damit die nicht allzu
>sehr ins Gewicht fallen.

Distr sagte, dass das Flash dann Echte 100 bzw 120 MHz hätte (also dann 
keine Gimmicks nötig sein ). Obs stimmt weiss ich nat. nicht.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:

> Distr sagte, dass das Flash dann Echte 100 bzw 120 MHz hätte (also dann
> keine Gimmicks nötig sein ). Obs stimmt weiss ich nat. nicht.

Guckst du hier. ST wird es wohl wissen: 
http://www.st.com/stonline/stappl/cms/press/news/y...

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MCUA (Gast)

Nur mal so grob überschlage ich mal das ganze....

- ST Flash Zugriff = 64 Bit Laden in den Puffer.
- Max-Speed 24 MHz für diesen Zugriff (FLASH darf nicht schneller 
laufen)
- Aber 64 Bit sind dann im Buffer
- Die CPU läuft mit 72 MHz, ein Befehl ist 16 Bit breit.
- Also sind im Buffer 4 * 16 Bit Befehle drin.
- Ja ?
- Also kann die CPU mit vollen 72 MHz arbeiten, denn es hat ja 4 Befehle 
verfügbar.
- Während dem wird aus dem Flash der nächste 64 Byte Block (= 4 16Bit 
Befehle) geholt.
- STM könnte mit dieser Technik sogar mit 96 MHz arbeiten.

Somit wartet die CPU nicht bei linearem Programmablauf! Kein einziger 
Wait. Es sind immer genügend Befehle im Zwischenspeicher.

Jetzt kommt die Ausnahme:
- JUMP in eine andere Adresse, weiter weg als diese 64 Bits, dann wird 
gewartet.
- Befehl, der 16 Bit-Variablen in ein Register kopieren möchte und davon 
2 hintereinander. Dann gibt es für den dritten Befehl keine Daten mehr.

Ich kenne zwar die Internas von ST nicht, aber dies ist die logische 
Schlussfolgerung, denn wiso sollte ST sonst ein 64 Bit breites Flash 
haben?

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Jetzt kommt die Ausnahme:
>- JUMP in eine andere Adresse, weiter weg als diese 64 Bytes, dann wird
>gewartet.
>- Befehl, der 16 Bit-Variablen in ein Register kopieren möchte und davon
>2 hintereinander. Dann gibt es für den dritten Befehl keine Daten mehr.

>Ich kenne zwar die Internas von ST nicht, aber dies ist die logische
>Schlussfolgerung, denn wiso sollte ST sonst ein 64 Bit breites Flash
>haben?

Ja, natürlich haben die deswegen ein 64 Bit breites Flash.

Aber sind 10 Läufer 10x schneller als einer, wenn sie nebeneinander 
laufen?

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Aber sind 10 Läufer 10x schneller als einer, wenn sie nebeneinander
>laufen?

Jeder Läufer trägt 16Bit Wassereimer. Also sind am Ziel 10 mal so viele 
Wassereimer, die dann genutzt werden. Also können die Läufer ruhig auch 
bummeln.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Müller schrieb:

> Nur mal so grob überschlage ich mal das ganze....

Yep, so ungefähr läuft das ab, mit 2 8-Byte Puffern im Prefetcher. 
Worst-Case für Codezugriffe case ist wohl, wenn das Sprungziel das 
letzte Wort eines 8-Byte Blockes ist. Daher sollte man, wenn es eilig 
ist, Schleifen entsprechend alignen.

> 2 hintereinander. Dann gibt es für den dritten Befehl keine Daten mehr.

Yep, es gibt Sequenzen wo es eng wird und auch mal ein Takt draufgeht.

Härter dran sind Datenzugriffe auf das Flash. Die haben immer die 
Waitstates an der Backe. Bei Thumb-2 sind die allerdings nicht mehr ganz 
so häufig und teilweise eine Frage der Optimierungseinstellung des 
Compilers.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Aber sind 10 Läufer 10x schneller als einer, wenn sie nebeneinander
>>laufen?

>Jeder Läufer trägt 16Bit Wassereimer. Also sind am Ziel 10 mal so viele
>Wassereimer, die dann genutzt werden. Also können die Läufer ruhig auch
>bummeln.

... aber dann muss ST die JMP-Befehle streichen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:

> ... aber dann muss ST die JMP-Befehle streichen.

Das haben sie bereits. Es gibt keine.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... und die Konstanten im Flash dürfen auch nicht mehr programmiert 
werden, also keine Texte mehr schreiben, die auf einem Display 
ausgegeben werden sollen.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... Nur noch ein Programm, 4GB groß von Adresse 0x00000000 bis 
0xFFFFFFFF, denn gehts automatisch wieder bei 0 los. Und blos kein 
jmp/call/Interrupt/Return oder sowas drin, alles Spaghetti-Code :)

Wisst Ihr wo man so Programmiert?
- In einer SPS Steuerung. Alles logische Verknüpfungen die immer 
durchlaufen... (Siemens S7, Bechhoff ...)

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> ... aber dann muss ST die JMP-Befehle streichen.
>Das haben sie bereits. Es gibt keine.
falsch, : B, BL, BLX, BX, CBNZ, CBZ........ u.s.w. (alle nichtlinearen 
Befehle)

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>... Nur noch ein Programm, 4GB groß von Adresse 0x00000000 bis
>0xFFFFFFFF, denn gehts automatisch wieder bei 0 los.
Dann wärs kein arbeitendes Programm mehr, sondern nur noch ein simpler 
Durchlauf.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Dann wärs kein arbeitendes Programm mehr, sondern nur noch ein simpler
>Durchlauf.
Dafür mit optimaler Ausnutzung der FLASH-Zugriffe ohne Waits

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Dann wärs kein arbeitendes Programm mehr, sondern nur noch ein simpler
>>Durchlauf.
>Dafür mit optimaler Ausnutzung der FLASH-Zugriffe ohne Waits
toll, da brauchst auch keine CPU dafür

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich muss in die Kiste und kontrollieren ob meine Frau noch da ist...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:

>>> ... aber dann muss ST die JMP-Befehle streichen.

>>Das haben sie bereits. Es gibt keine.

> falsch, : B, BL, BLX, BX, CBNZ, CBZ........ u.s.w.

Eben. Kein einziger JMP dabei ;-).

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Martin Thomas

Hast Du das gelesen?
Beitrag "Re: STM32 - Erster Artikel"

Autor: Martin Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja aben. Ich verfolge das Wiki schon. Eigentlich fast jeden Tag 
(irgendwie "Pflicht", wenn man zu den Wiki-Mitadmins gehört). Artikel 
sieht doch schon ganz gut aus. Ist noch etwas Hardwarelastig (denn 
"Software makes Hardware work" - nicht von mir) aber das wird ja 
bestimmt noch. M.M. ist der selbst entwickelte JTAG-Anschluss zu sehr 
hervorgehoben. Bei allem Stolz darauf, sollten im Haupttext eher die von 
ARM definierten Anschlüsse erläutert werden (20-pol 2.5mm, 10-pol 
1.3mm), die man auf den allermeisten Boards findet (den 10poligen spez. 
für SWD glücklicherweise noch selten). Der selbst entwickelte Anschluss 
ist eher etwas für den Anhang.

Würde gerne noch etwas zur Verwendung von Eclipse/gdb/OpenOCD/JTAG 
beitragen, allein es fehlt die Zeit und eigentlich war mein Plan, eine 
Art "generelles" Tutorial dazu für verschiedene Controller mit ARM-core 
zu scheiben und nicht nur für die CM3 von STM. Bei dem regen Interesse 
an dem Artikel macht das vielleicht bald ja schon jemand anderes.

Betr. vorkompiliertem OpenOCD: Ich habe im Kommentar zur Löschung schon 
geschrieben, dass ich keine "Deep-Links" möchte. Die Kommentare sieht 
man, wenn man im Menü oben links "Letzte Änderungen" anklickt. Da es 
beim ersten Mal nicht übergangen wurde, habe ich die Binaries auf 
"meinem" Server gelöscht und etwas mehr Information auf die 
Diskussionsseite geschrieben. Diskussionen zu Wiki-Artikeln sollten eher 
auf der zugehörigen Diskussionsseite erfolgen und nicht in einem 
Foren-Thread. Der geht irgendwann im Datenwust "verschütt".

Da das mit meiner Löschung etwas radikal war, etwas Geschreibsel dazu 
von mir zum Hintergrund: OpenOCD steht unter GPL und der 
FTDI-Herstellertreiber halt nicht. Daher gibt es Probleme mit der 
Bereitstellung von Binarys mit Abhängigkeit zu diesen Treibern 
(Hersteller DLL im gleichen Speicherbereich wie Executable aus 
GPL-Code). Da ich noch in den Anfängen von OpenOCD gelegentlich mit dem 
Schöpfer des Programms in Verbindung stand und er es - so schien mir - 
sogar sehr begrüßt hat, dass jemand fertige "gut vorgekaute" 
Binärversionen für MS Windows bereitstellt und die Lizenz dahingegehen 
nicht so streng auslegte, habe ich Binärversionen mit und für 
FTDI-Treiber angeboten. Seinerzeit in meinen WinARM-Packet (als es noch 
"gelebt" hat). Wenig später hat auch der Yagarto-Packer Packete 
bereitgestellt. Ich habe dann noch unregelmässig für WinARM "Updates" in 
Form aktueller OpenOCD Packete auf den Server gelegt. Da einige der 
jetzigen OpenOCD-Programmierer die Lizenz aber dogmatisch auslegen, 
werde ich langsam aber sicher alle OpenOCD-Binärpackete auf "meinem" 
Webserver löschen, sind aber so viel Querverweise, dass ich das mit 
Sorgfalt und Zeit machen wollte. Bei Yagarto hat M.F. schon schneller 
reagiert. Link im Artikel auf "winarmtests" kam ungelegen, da ich dort 
noch nicht augeräumt hatte (wahrscheinlich habe ich nun ein paar "broken 
links" - einerlei).

Eigentlich lässt die neue GPL explizit zu, dass exterene 
nicht-GPL-Treiber von GPL-Programmen genutzt werden aber diese müssen - 
soweit ich das verstanden habe - zum Lieferumfang des OS gehören und die 
FTDI-Treiber sind halt, zumindest bei MS Windows XP, nicht dabei. Ich 
finde, es wäre im Interesse der OpenOCD-Entwickler, dass man an dieser 
Stelle eine Ausnahmereglung für Hardwaretreiber in die Lizenz aufnimmt. 
Damit wird das Programm leichter installierbar, die Anzahl der 
Supportanfragen sinkt und die Anzahl der potetiellen Nutzer steigt. Aber 
so dogmatisch und ellenlang die Diskussion auf der 
OpenOCD-devel-Mailingliste dazu geführt wurde, wird das wohl nie 
geschehen. Ich habe irgendwann aufgegeben, diese Diskussion mitzulesen.

Habe sebst nie OpenOCD mit dem libftdi-Treiber ausprobiert, der 
Herstellertreiber funktioniert hier unter MS Windows einfach gut und ist 
m.W. auch zügiger. Die "Kabelhersteller" (Olimex, Amontec u.v.a.m) 
bieten auch auf ihren Webseiten Treiberpackete auf Basis der 
FTDI-Treiber (Amontec inzwischen sogar signierte). Für den normalen 
Anwender liegt es viel näher, diese Treiber zu installieren. Aber es 
gibt ja inzwischen auf der nunmehr im STM32-Wiki-Artikel genannten Seite 
OpenOCD Binärversionen, die mit einem freien Treiber (nicht dem von 
FTDI) arbeiten und scheinbar gut zu installieren sind. Damit sollte 
Leuten, die nich selbst kompilieren wollen oder können erstmal geholfen 
sein.

O.k., mal wieder eine ellenlange Ausführung. Eigentlich off-topic. Hoffe 
aber, es erklärt dennoch ein wenig die Hintergründe.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Ausführliche Erklärung.
Ich habe den OpenOCD Verweis gestern Nacht so abgeändert wie Du 
vorgeschlagen hast.

Ja, der 10-Polige JTAG-Stecker gehört eigentlich in die Abteilung JTAG. 
Dafür gibt es ja ein Artikel.
Ich wollte dazu eigentlich auch nicht sooo viel schreiben, aber es 
tauchte die Frage auf warum die Boot-Pins nicht drauf sind.
Ich finde nur schade, dass der Stecker nicht schon früher so oder mit 
ähnlichen Features festgelegt wurde. Ich meine ganz zu Beginn, denn 
irgend jemand muss das doch festgelegt haben.
(Und erst mal wollte ich selbst einen Artikel schreiben bevor ich in 
anderen rumpfusche...)

Links neben dem Artikel gibts "Diskussion", damit habe ich mich ein 
wenig durchgeklickt. Ich denke jetzt habe ich es verstanden.

Zwei Punkte fehlen noch in diesem Artikel:
"Codesammlung"
In dem einzelne Codeteile veröffentlicht sind, die nicht bereits in den 
STM FW-LIB Demos drin sind.

"Einrichtung Eclipse"
- External Tools Configuration
- Debug-Configurations
(Bzw. Links auf Seiten wo das gut und in Deutsch beschrieben ist)

Ach ja, wenn ich Dich gerade hier treffe:
In dem Demo-Projekt, das ich Verlinkt habe "ChaN's FAT-Module", da gibt 
es 5 "Debug Configurations...". Wenn im STM32 die "Read-Out-Protection" 
gesetzt ist, dann klappt hier der "load" eines neues Files nicht mehr in 
den Prozessor. (Ja, mein Bootloader setzt natürlich die 
Read-Out-Protection)
Folgendes habe ich unter "Reset Load Run" drin, dann gehts richtig:
monitor reset halt
set mem inaccessible-by-default off
monitor soft_reset_halt
monitor stm32x unlock 0
monitor stm32x mass_erase 0
monitor reset halt
monitor flash write_image main.elf 0x08000000 elf
tbreak main
Also der unlock und nach dem mass_erase muss noch ein Reset sein.
(Im "Reset Load Debug" das gleiche..., ich denke den unlock könnte man 
auch weg lassen)

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>falsch, : B, BL, BLX, BX, CBNZ, CBZ........ u.s.w. (alle nichtlinearen
>Befehle)
also mit JMP-Befehle waren alle nichtlinearen Befehle gemeint

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Martin Thomas

Ich habe jetzt das msi Paket von www.freddiechopin.info mal geladen und 
versucht zu starten (nach Installation).

Befehl: OpenOCD -f arm-usb.ocd.cfg -f stm32.cfg

Resultat:
Error: unable to open ftdi device: device not found

In Deiner arm-usb.ocd.cfg steht das gleiche drin wie in der von 0.4.0. 
Also die gleiche USB-ID. Nur steht als Variante ein "A" mit drin. (Hab 
ich getestet)
Alles ist richtig eingesteckt, denn wenn ich wieder auf Dein OpenOCD 
0.3.1 wechsle, dann geht es.

Auf der Seite www.freddiechopin.info steht "Details: #1, #2.". Aber die 
Links gehen nicht :(

Kannst Du mir einen Tipp geben warum der andere OpenOCD nicht geht?
Ich weiß, Du hast keine Zeit, es würde dennoch vielen Usern sehr helfen.

Autor: Martin Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Betr. CRP & GDBs load: Ja, kann gut sein, dass load bei gesetzter CRP 
nicht funktioniert. Ich nutze die Sicherung ebenfalls in einem 
Bootloader (zum Update von SD-Karte) aber schalte sie nur in einem 
"Release"-Build an. Bei der Entwicklung bleibt CRP aus und daher sind 
die vorkauten Tagets aus meinem Packet alle nur mit gdb-load ohne 
Berücksichtigung der CRP. Eigentlich sollte das gdb-load nach monitor 
mass-erase, monitor reset und damit Deaktivierung der CRP funktionieren 
und man müsste monitor flash write_image durch load ersetzen können. 
Mglw. ist es geschickter, angelehnt an das "reset load run"-Targe ein 
weiteres Debug Target zur Löschung der CRP zu erstellen und die anderen 
Targets damit nicht zu "belasten."

Betr. OpenOCD von F.C.: Wie oben geschrieben: ich habe diese 
vorkomplierten Versionen nie ausprobiert. Der einzige wirkliche 
Unterschied zwischen den ehemals von mir angebotenen Binaries und denen 
von F.C. ist die Methode, mit denen FTDI2232-basierte Adapter 
angesprochen werden. Bei den Packeten von F.C. muss als Treiber für den 
JTAG-Adapter libusb/libftdi-win32 verwendet werden. Man muss also den 
vermutlich jetzt noch installierten Herstellertreiber von FTDI irgendwie 
gegen den für libftdi/libusb austauschen. Mglw. kann man das einfach im 
Gerätemanager mittels "Treiber aktualisieren" machen. Wenn alle Stricke 
reissen: ftclean von ftdichip herunterladen und ausführen, damit werden 
die FTDI-Treiber gelöscht und man kann - hoffentlich - mit 
libftdi/libusb neu installieren. Ja genau: das ist Gewurschtel und 
kostet nur Zeit ohne irgendwelche Vorteile bei der Anwendung zu bringen. 
Dient nur dazu, der Lizenz genüge zu tun. Daher kompiliere ich mir 
OpenOCD für die FTDI-Treiber zur eigenen Anwendung mit mingw/msys oder 
Cygwin auch selbst. Ist zwar auch Aufwand, die Build-Umgebung erstmal 
aufzusetzten aber diese habe ich ohnehin für andere Projekte auf einem 
Rechner installiert.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das mit der Read-Out-Protection gemerkt als ich meinen 
Bootloader in Betrieb nahm. Dann kam ich nicht mehr mit OpenOCD/GDB 
dran.
Ich hatte schon angst ich muss den Chip runterlöten...
Dann habe ich mit OpenOCD/Telnet diverse Befehle aus probiert, dann ging 
es wieder. :)

Der OpenOCD /F.C. geht jetzt.Ich musste folgendes machen:
- Olimex ARM-USB-OCD einstecken
- Alle 3 Gerätetreiber von Hand deinstallieren
- Olimex ARM-USB-OCD aus- und einstecken
- Dann den Treiber vom Zip 
"drivers\libusb-win32_ft2232_driver-100223.zip"
manuell installiert (3x kommt der Install-Dialog)
- Bei der Installation hat der zwar gemeckert dass irgend was fehl 
geschlagen sei, aber in der Systemsteuerung zeigt er kein gelbes 
Ausrufezeichen, also ist doch allen OK und es tut auch.

Dann hat es geklappt mit der OpenOCD Version von F.C.

Einziger Nachteil der F.C. Version: Man kann die Exe nicht mit UPX 
kleiner machen.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mit dem OpenOCD/GDB noch ein anderes Problem. Der "reset load 
debug" geht nicht richtig. Da hängt der Debugger sich auf.

Ich muss immer "reset load run" und dann "reset debug" machen, dann geht 
es.

Ganz am Anfang als mein Programm kleiner war, ging es, jetzt ist es über 
100K groß und es geht nicht mehr.

Es betrifft beide Versionen von OpenOCD, bzw. Ich weiß nicht genau ob es 
an der Konfiguration liegt.

Hier die Konfiguration von Reset Load Debug:
monitor reset halt
set mem inaccessible-by-default off
monitor soft_reset_halt
monitor stm32x unlock 0
monitor stm32x mass_erase 0
monitor reset halt
monitor flash write_image main.elf 0x08000000 elf
tbreak main
X bei Resume
monitor reset run
continue

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe einen neuen Punkt hinzugefügt:
http://www.mikrocontroller.net/articles/STM32#Tipp...

"Tipps für Umsteiger von Atmel/PIC/8051"

Falls noch jemand was einfällt

Autor: STM32F10x (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich benutze das OpenOCD Tool von olimex um einen STM32f-controller zu 
programmieren. Wenn ich im Debugger einen Breakpoint setzte, der 
Debugger am Breakpoint hällt und ich auf "Resume" drücke hängt er am 
Breakpoint fest. Früher war das nicht so.

Ich kann dieses Problem umgehen indem ich den Breakpoint einfach weg 
mache, aber das ist auf Dauer umständlich. Wo muss ich denn die 
Konfiguration von Reset Load Debug hinmachen?

Autor: Markus Müller (mmvisual)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Dieses Käfer-Symbol mit dem Pfeil nach unten, dann "Debug 
Configurations..."

Anbei ein Bild dieser Einstellung. Im Demo-Projekt von Martin Thomas 
sind diese alle drin.

Hier der Code, der im Screenshot abgeschnitten ist:
monitor reset halt
set mem inaccessible-by-default off
monitor soft_reset_halt
monitor stm32x unlock 0
monitor stm32x mass_erase 0
monitor reset halt
monitor flash write_image main.elf 0x08000000 elf
tbreak main

Autor: Thomas R. (tinman) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab noch H-JTAG hinzugefügt, die Pro die ich habe ist zwar teuer, dafür 
die Personal um so günstiger (am ca 60eur). Bald wird noch eine 
abgespeckte Personal version geben (aber mit M3 support).

Autor: Cahya W. (cahya_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
brott schrieb:
> Hi, danke fuer den Artikel, ueberlege auch schon laenger, mal auf STM
> umzusteigen \ mich zu erweitern.
>
> Eine Frage dazu: laeuft der USBprog von Bendeikt Stauter
> (http://www.eproo.de/index.php?module=artikel&actio...)
> auch mit ST-Controllern?
>
> Ich verstehe das so, dass mit der entsprechenden Firmeware (OpenOCD)
> laufen sollte.
>
> Wenn da jemand was weisz, waere ich fuer eine Ergaenzung im Artikel /
> Thread sehr dankbar.

Dafuer gibt's jetzt neue firmware, schau mal in diesem thread:
Beitrag "Neue OpenOCD-Firmware für USBProg (18x schneller)"
zusammen mit dem neuen openocd 0.4.0 funktioniert die neue firmware
auch sehr gut mit STM32.

Autor: apfel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wird da in naher Zukunft noch auf die Pherpherie z.B Timer -> PWM 
eingegangen? Eventuell Tutorials?

Mfg

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jeder darf gerne die Artikel erweitern.

Mir (als erfahrener Programmierer) reichen die Demo-Codes der FW-LIB von 
ST vollkommen aus. Da gibt es zu fast allem eine passende Demo. Für den 
Timer sind hier 17 Demos dabei.

Es gibt dennoch einige Tipps und Hinweise zu allen möglichen 
Pheriperiemodulen. So wie mir diese einfallen, trage ich sie unter Tipps 
in dem Artikel ein.
Falls der Tipp länger als ein Abschnitt sein sollte, dann ist schon zu 
überlegen ob man dafür nicht ein Artikel anfügt.

Der STM32 Artikel kann jeder nach belieben erweitern. Ich schaue immer 
wieder mal vorbei ob es Änderungen gab.

Wenn ich mal viel Zeit habe mache ich ein Tutorial über die Eclipse 
Einrichtung. Bisher ist diese sozusagen in dem Projekt von MT drin und 
meine kleine Install/Download Anleitung.

Autor: funky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sicher das Ride7 nur bis 32kB Code funktioniert?
ich hatte das so verstanden, das man nur bis 32kB debuggen kann, aber 
uneingeschränkt programmieren?!

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
apfel schrieb:
> Wird da in naher Zukunft noch auf die Pherpherie z.B Timer -> PWM
> eingegangen? Eventuell Tutorials?
>
> Mfg

Kuck mal unter

http://www.mikrocontroller.net/articles/STM32F10x_...

Da hab ich einen neuen Artikel begonnen

Gruß
Tom

Autor: Jörg Rupprecht (ruppi66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Markus, hallo Thomas,

euch beiden erstmal besten Dank für eure Artikel. Mit diesen Artikeln 
hat die STM32-Fangemeinde große Chancen gewaltig zu wachsen.
Besonders die tieferen Erklärung in dem von Thomas. Wenn Du das komplett 
durchziehst, kannst Du das als deutschsprachiges STM32-Buch drucken 
lassen.
Wenn Markus auch noch seine "Androhung" wahr macht und einen Artikel 
über das Installieren der Eclipse-Umgebung erstellt, dann denke ich 
werden selbst eingefleischte 8-Bit-Freaks (nicht negativ verstehen) über 
den Tellerrand spitzen und den STM32 probieren.

Wäre es nicht langsam an der Zeit den Grundartikel (STM32) von Markus in 
die Navigationsleiste der Webseite aufzunehmen als Unterpunkt bei den 
ARM´s liebe Betreiber ??? !!!.

Gruß Jörg

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Blumem :-) Aber da ist auch ne ganze Menge von Heddie, der 
wohl leider nicht als benutzer angemeldet ist drin.

@Markus: Können wir den STM32 Artikel etwas aufräumem/umstrukturieren?

Ich würde alles was mit JTAG, bzw. die Erklärungen zur Configuration der 
einzelnen Entwicklungsumgebungen in einzelne Artikel auslagern, da die 
ja eigentlich in einem Übersichtsartikel nichts zu suchen haben.

Gruß
Tom

Autor: Claudio H. (hedie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Burkhart schrieb:
> Danke für die Blumem :-) Aber da ist auch ne ganze Menge von Heddie, der
> wohl leider nicht als benutzer angemeldet ist drin.

Vielen Dank...

Die Blumen übernehme ich gerne :)

Ja die beiden Artikel über die Clock Steuerung und die GPIO's sind von 
mir...
das war damals ne heiden arbeit... Ich hab Sie von 
www.mikrocontroller.tk übernommen... hatte sie damals dort 
eingestellt...

Hab auch noch ein Beispiel projekt gepostet... Beispiel für Timer2 im 
Interrupt betrieb!

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hoffe es ist ok, wie ich den GPIO-Artikel überarbeitet habe
Tom

Autor: Claudio H. (hedie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Burkhart schrieb:
> Hoffe es ist ok, wie ich den GPIO-Artikel überarbeitet habe
> Tom

Ja Natürlich :)

Verbesserungen sind immer gut :)

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg: Vielen Herzlichen Dank!!!

Das mit der Navi-Leiste habe ich auch schon vorgeschlagen, hier gibts 
einen Thread:
Beitrag "Home / ARM >> STM32 @Andreas Schwarz"
Leider wird der von den Admins/Moderatoren nicht beantwortet. Ist halt 
ein AVR-Forum, damit muss ich mich nun mal abfinden...
Man könnte ja schreiben, nein oder kommt später oder so, aber nichts.

@Thomas:
Ja, der JTAG-Teil gehört eigentlich in den Artikel JTAG als neuen 
Unterpunkt.
Ich wollte damit noch warten bis ich einen neuen Selbstbau-JTAG fertig 
habe. Platine ist bestellt, braucht wohl noch 3 Wochen bis es Spruchreif 
ist.
Es gibt auch ein Thread dazu:
Beitrag "JTAG-Adapter für ARM/Cortex-M3 (STM32) mit UART"

Die Eclipse-Install-Anleitung kommt noch. Ich habe vor dies für einen 
ARM-USB-OCD und einen JLink zu schreiben, denn die beiden hab ich. 
Gerade bin ich nur sehr eingespannt. (Das Haus baut sich und es sind 
viele Handwerker da die alle irgend was entschieden haben wollen...)

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ein bisschen vermisse ich in dem Artikel einen Hinweis auf die 
Trace-Möglichkeiten mittels ETM. ETM ist zumindest auf den "grossen" 
STM32 immer mit drauf.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnte dran liegen, dass Debugging mit ETM ein ziemlich grosses Loch 
reisst und dieses Forum eher jene anspricht, die sich dafür lieber ein 
kleines Auto leisten.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann man sehen wie man mag. Der Controller bietet die Möglichkeit und 
ich selbst nutze sie gern.
Geht ja nur um Vollständigkeit.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias, wenn Du Dich damit auskennst, dann schreib doch was dazu in 
den Artikel.

Gruß
Tom

Autor: Jerry (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Also ich benutze den ARM-USB-OCD von Olimex. Da war eine CD bei, in der 
komplett eingerichtetes Eclipse mit Treibern für 
ARM-USB-OCD,Beispielprojekten und die ganzen makefiles, linkscript und 
.cfg Dateien sind. Bis jetzt hat es gut geklappt aber wenn ich versuche 
eine .bin Datei, die größer als ca. 31kb ist, zu flashen spuckt er mir 
einen Fehler aus, mit der Aussage das Flashen sei fehlgeschlagen.

Also ich denke mal die .cfg Datei ist richtig und der Linker meckert 
auch nicht über irgendwelche Speicheroverflows. Der Controller hat einen 
Flashspeicher von 128kb ...

Ich habe es getestet indem ich die größe des Programms durch ein Array 
schrittweise vergörßert haben und bei ca. 31kb wollte er nicht mehr 
flashen...

Hier die Konsolenausgabe:
Warning: /cygdrive/C/gccfd/projects/stm32f_test/stm: No such file or directory.
Warning: /cygdrive/C/gccfd/projects/stm32f_test/ntrx_primer: No such file or directory.
Warning: /cygdrive/C/gccfd/projects/stm32f_test/ntrx_avr: No such file or directory.
Warning: /cygdrive/C/gccfd/projects/stm32f_test: No such file or directory.
mi_cmd_break_watch: Missing <expression>
No registers.
target remote localhost:3333
hardfault_handler () at sensorknoten_init.c:31
31        }
symbol-file main.out
monitor soft_reset_halt
requesting target halt and executing a soft reset
monitor flash erase_sector 0 0 31
erased sectors 0 through 31 on flash bank 0 in 1.030015s
monitor flash write_image main.bin 0x08000000
not enough working area available(requested 8192, free 8144)
flash writing failed with error code: 0xfffffc7a
thbreak main
Hardware assisted breakpoint 1 at 0xf2: file main.c, line 104.
cont
main () at main.c:104
104    *NVIC_CCR = *NVIC_CCR | 0x200; /* Set STKALIGN in NVIC */

Hat einer eine Idee woran es liegen kann? Wie gesagt: es funktioniert 
nur ab der Dateigröße 31kb nicht, sonst ging es ganz gut ...

Im Anhang ist die armusbocd.cfg Datei.
Run command:
target remote localhost:3333
symbol-file main.out
monitor soft_reset_halt
monitor flash erase_sector 0 0 31
monitor flash write_image main.bin 0x08000000
thbreak main
cont

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
monitor stm32x unlock 0
monitor stm32x mass_erase 0

Autor: Jerry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, ich habe diese Zeilen bei mir eingefügt, aber er sagt mir: failed 
to unlock device

Im wiki Artikel steht, ich solle nicht den Treiber von Olimex für 
ARM-USB-OCD benutzen, sondern den von OpenOCD. Was ist der Grund dafür?

Hier noch die Info was in der CD von Olimex dabei war:
http://www.olimex.com/dev/soft/arm/OpenOCD%20rev.G...

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Artikel STM32 habe ich geschrieben was und wo man laden sollte.
Hier steht die OpenOCD Version 0.4.0.

Diese OpenOCD Version nutzt nicht mehr den USB-Treiber von FTDI sondern 
den freien LibUSB Treiber.

Daher muss man den USB-Treiber der von Olimex mitgeliefert wurde 
deinstallieren und den vom OpenOCD Setup installieren. Dazu die Datei 
"libusb-win32_ft2232_driver-100223.zip" entpacken und beim Installieren 
dieses Verzeichnis angeben. In diesem Thread weiter oben habe ich mal 
das gleiche Problem gehabt und ein bischen mehr geschrieben.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf STM32 USB-FS-Device Lib hab ich mal mit der Beschreibung des 
Virtual COM Ports für den STM32 begonnen und auch ein Beipielprojekt 
hochgeladen.

Gruß
Tom

Autor: STM32 Beginner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich finde den Artikel sehr hilfreich. Er gibt gerade für den Einstieg 
einen schönen, breiten Überblick. Danke!

Nur eine Frage von meiner Seite:

*Für USB Betrieb muss die CPU mit 48MHz oder 72MHz betrieben werden.*

Im Referenz-Handbuch zur STM32F-Reihe findet sich dazu kein solcher 
Hinweis. Es gibt anscheinend einen internen 48MHz Takt, mit dem der 
USB-Teil des Controllers betrieben wird (Seite 581) .
Auf Seite 585 geht es dann weiter mit:
Due to USB data rate and packet memory interface requirements, the APB1 
clock frequency must be greater than 8 MHz to avoid data 
overrun/underrun problems.

Ich habe das so verstanden: mit mindestens 8 MHz geht USB.
Das paßt auch zu Produkten wie STM32 value line Discovery, die USB 
anbieten und den STM32 mit 8 MHz takten. Oder liege ich falsch?

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Chip kann mit 48 MHz oder 72 MHz bei Nutzung von USB betrieben 
werden. (Stichwort Teiler :1 oder :1,5)

Mit dem internen RC Oszillator kann maximal 48 MHz (für USB) erreicht 
werden.
Um die CPU mit 72 MHz betreiben zu können wird ein externer Quarz 
verwendet werden. (z.B. 12MHz oder 8MHz)

Autor: STM32newbie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
8 MHz
14,7456 MHz
25 MHz
externer Clock für USB-Einsatz,
steht bei STM32F105 im Datenblatt

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß jetzt zwar nicht wie man von 14,7456MHz aus mit dem Mul/Div 
Register der PLL exakt 72 MHz oder 48MHz erreichen kann, aber meine 
Rechenkünste lassen sicher auch schon nach.

12MHz * 6 = 72 MHz, also geht
8MHz  * 9 = 72MHz, als geht

Auch bei 25MHz weiß ich jetzt nicht wie man auf 72 MHz kommt.

Autor: Flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das geht nur für die 105/107er, die haben einen komplexeren Clocktree. 
Die 14,7456 MHz sind für I2S optimiert, damit kommt man nicht exakt auf 
48/72 MHz.

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Müller schrieb:
> Auch bei 25MHz weiß ich jetzt nicht wie man auf 72 MHz kommt.

Hinzu kommt, das wenn ich mich nicht täusche, max. 16MHz als externer 
Takt erlaubt ist.

Gruß
Rainer

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kenne die Clock-Striktur der STM32F103.
Bei den 25MHz Typen hat man eher das Problem dass die meistens auf den 
2. oder 3. Oberton schwingen müssen und dafür vermeide ich die wenn es 
geht. Lieber kleinere Quarz-Frequenzen, spart auch Strom.

USB sollte eine ziemlich genaue Quarz-Frequenz haben, sonst tut das 
nicht oder nur halb.
Es geht zwar auch mit dem internen RC, wird aber nicht empfohlen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM32 Beginner schrieb im Beitrag #1948127:

> Im Referenz-Handbuch zur STM32F-Reihe findet sich dazu kein solcher
> Hinweis. Es gibt anscheinend einen internen 48MHz Takt, mit dem der
> USB-Teil des Controllers betrieben wird (Seite 581) .

Der Clock Tree deutet an, dass man USB via PLL mit 48MHz betreiben kann, 
aber Core, AHB und die APBs mit 8MHz HSE/HSI. Bissel exotisch ist diese 
Betriebsart aber wohl schon.

> *Für USB Betrieb muss die CPU mit 48MHz oder 72MHz betrieben werden.*

Soll wahrscheinlich eher heissen, dass man sich sowas wie 25/36MHz in 
die Haare schmieren kann und nicht den schrägen Fall ausschliessen, dass 
man den Core langsamer taktet als USB.

> Ich habe das so verstanden: mit mindestens 8 MHz geht USB.

8MHz was? Quarz? CPU-Takt? Bustakt? ... Aus 8MHz Quarz kann man per 
PLL 48MHz USB ableiten, weniger geht nicht weil die PLL nur x16 kann.

> Das paßt auch zu Produkten wie STM32 value line Discovery, die USB
> anbieten und den STM32 mit 8 MHz takten. Oder liege ich falsch?

Nö, passt schon, 8MHz scheint bei STM32 <= 103 eine Art Standardfrequenz 
zu sein. Beim 107 wird es durch die nötigen 25MHz fürs Ethernet ein 
bischen komplizierter, wenn man nicht noch einen weiteren Quarz 
dranhängen will..

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Müller schrieb:

> Bei den 25MHz Typen hat man eher das Problem dass die meistens auf den
> 2. oder 3. Oberton schwingen müssen

Beim 107 mit Ethernet hat man wohl keine Wahl. Höchstens die zwischen 
Quarz und externem Oszillator. Aber dank Dingern wie dem ENC28J60 sind 
25MHz Grundtonquarze auch im Bastelversand nicht mehr so exotisch wie 
früher. Man muss aber genau aufpassen was man bestellt.

Ist dir tatsächlich schon mal ein Quarz für den 2. Oberton über den Weg 
gelaufen? Gewöhnlich geht sowas nur ungrad.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

> Der Clock Tree deutet an, dass man USB via PLL mit 48MHz betreiben kann,
> aber Core, AHB und die APBs mit 8MHz HSE/HSI. Bissel exotisch ist diese
> Betriebsart aber wohl schon.

PS: Bei HSI hätte so meine Zweifel, ob die fehlende Synchronität des 
Taktes das zulässt. Auch bei HSE würde deshalb ich nicht blind drauf 
wetten, dass ST diese Betriebsart auf der Rechnung hatte. Auch wenn es 
sich möglicherweise so einstellen lässt.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ist mir. Einer mit 24MHz, der lief dann mit 6 MHz. :(
Hab ihn in die Ecke geschmissen weil der CY7C68013 damit keine USB 
Verbindung machen konnte. (Cypress)
Damals hatte ich kein gescheites Oszi zum messen, daher brauchte ich ein 
wenig mehr Zeit.

Autor: STM32 Beginner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, es mag euch trivial erscheinen. Aber mir war nicht klar, daß der 
externe Quarz-Takt intern über einen Multiplikator auf die 48 MHz oder 
72 MHz vervielfacht wird.
Ich habe den Satz:

*Für USB Betrieb muss die CPU mit 48MHz oder 72MHz betrieben werden.*

eben so verstanden, daß der externe Takt so groß sein muß. Vielleicht 
geht es auch anderen Lesern so.
Dann könnte helfen, in dem Artikel zu ergänzen, daß der CPU-Takt über 
einen Multiplikator aus dem internen RC-Takt oder externen Quarz-Takt 
abgeleitet wird.
Oder habe ich etwas überlesen?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM32 Beginner schrieb im Beitrag #1948994:

> Dann könnte helfen, in dem Artikel zu ergänzen, daß der CPU-Takt über
> einen Multiplikator aus dem internen RC-Takt oder externen Quarz-Takt
> abgeleitet wird.

Korrekt. Schreib es rein.

Autor: STM32 Beginner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe eine Ergänzung in 'Features' vorgenommen.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast den Text mit "Eingebautem Bootloader" mit hinzugefügt, dafür 
habe ich noch eine Anmerkung:

Wenn du den 10-Poligen JTAG Stecker auf Deiner Platine verwendest:
http://www.mikrocontroller.net/articles/JTAG#Der_1...
Dann hast du mit 10 Pins alle Debug/Update-Möglichkeiten. Lies das mal 
durch was ich da geschrieben habe.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.