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 ...
Super Sache, mache gerne mit. Hab grad noch nen Link zu der Getting startet Appnote dazugefügt. Gruß Tom
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
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=/com.arm.doc.ddi0406b/index.html"; 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
Hi Leutz, hab's mal überarbeitet :-) Ich denke mal ich werde noch so das eine oder andere ergänzen. VG, /th.
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.
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&action=gruppe&id=22) 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
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!!!!
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
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.
Die Frage ist doch, ob man sich beim STM32 dank der firmware-lib wirklich so sehr quälen muss wie bei den anderen ;-)
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.
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)
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! :)
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...
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
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.
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
@ 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
@ berndl (Gast) Zu 1) Nachtrag Die Grafik war bei mir angenehm sichtbar. Ich habe einen Laptop mit 1900 Pixel Bildbreite :)
> 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).
Ich habe mal den Link in de Artikel genommen: http://www.mikrocontroller.net/articles/STM32#STM32_Programmiertool: 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)
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 :-)
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.
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.
@ 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.
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.
Ich habe einen Eintrag unter "Nachteile gegenüber LPC1700" rein geschrieben. Damit sollte die Sache gerecht sein.
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.
>> 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)
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.
>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.
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".
>> 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.
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/year2010/t2477.htm
@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?
>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?
>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.
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.
>>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.
MCUA schrieb: > ... aber dann muss ST die JMP-Befehle streichen. Das haben sie bereits. Es gibt keine.
... und die Konstanten im Flash dürfen auch nicht mehr programmiert werden, also keine Texte mehr schreiben, die auf einem Display ausgegeben werden sollen.
... 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 ...)
>> ... 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)
>... 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.
>Dann wärs kein arbeitendes Programm mehr, sondern nur noch ein simpler >Durchlauf. Dafür mit optimaler Ausnutzung der FLASH-Zugriffe ohne Waits
>>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
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 ;-).
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.
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:
1 | monitor reset halt |
2 | set mem inaccessible-by-default off |
3 | monitor soft_reset_halt |
4 | monitor stm32x unlock 0 |
5 | monitor stm32x mass_erase 0 |
6 | monitor reset halt |
7 | monitor flash write_image main.elf 0x08000000 elf |
8 | 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)
>falsch, : B, BL, BLX, BX, CBNZ, CBZ........ u.s.w. (alle nichtlinearen >Befehle) also mit JMP-Befehle waren alle nichtlinearen Befehle gemeint
@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.
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.
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.
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:
1 | monitor reset halt |
2 | set mem inaccessible-by-default off |
3 | monitor soft_reset_halt |
4 | monitor stm32x unlock 0 |
5 | monitor stm32x mass_erase 0 |
6 | monitor reset halt |
7 | monitor flash write_image main.elf 0x08000000 elf |
8 | tbreak main |
X bei Resume
1 | monitor reset run |
2 | continue |
Habe einen neuen Punkt hinzugefügt: http://www.mikrocontroller.net/articles/STM32#Tipps_f.C3.BCr_Umsteiger_von_Atmel.2FPIC.2F8051 "Tipps für Umsteiger von Atmel/PIC/8051" Falls noch jemand was einfällt
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?
Angehängte Dateien:
-
reset_load_debug.png
41 KB
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:
1 | monitor reset halt |
2 | set mem inaccessible-by-default off |
3 | monitor soft_reset_halt |
4 | monitor stm32x unlock 0 |
5 | monitor stm32x mass_erase 0 |
6 | monitor reset halt |
7 | monitor flash write_image main.elf 0x08000000 elf |
8 | tbreak main |
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).
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.
Wird da in naher Zukunft noch auf die Pherpherie z.B Timer -> PWM eingegangen? Eventuell Tutorials? Mfg
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.
Sicher das Ride7 nur bis 32kB Code funktioniert? ich hatte das so verstanden, das man nur bis 32kB debuggen kann, aber uneingeschränkt programmieren?!
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_Standard_Peripherals_Library Da hab ich einen neuen Artikel begonnen Gruß Tom
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
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
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!
Thomas Burkhart schrieb: > Hoffe es ist ok, wie ich den GPIO-Artikel überarbeitet habe > Tom Ja Natürlich :) Verbesserungen sind immer gut :)
@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...)
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.
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.
Kann man sehen wie man mag. Der Controller bietet die Möglichkeit und ich selbst nutze sie gern. Geht ja nur um Vollständigkeit.
Matthias, wenn Du Dich damit auskennst, dann schreib doch was dazu in den Artikel. Gruß Tom
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:
1 | Warning: /cygdrive/C/gccfd/projects/stm32f_test/stm: No such file or directory. |
2 | Warning: /cygdrive/C/gccfd/projects/stm32f_test/ntrx_primer: No such file or directory. |
3 | Warning: /cygdrive/C/gccfd/projects/stm32f_test/ntrx_avr: No such file or directory. |
4 | Warning: /cygdrive/C/gccfd/projects/stm32f_test: No such file or directory. |
5 | mi_cmd_break_watch: Missing <expression> |
6 | No registers. |
7 | target remote localhost:3333 |
8 | hardfault_handler () at sensorknoten_init.c:31 |
9 | 31 } |
10 | symbol-file main.out |
11 | monitor soft_reset_halt |
12 | requesting target halt and executing a soft reset |
13 | monitor flash erase_sector 0 0 31 |
14 | erased sectors 0 through 31 on flash bank 0 in 1.030015s |
15 | monitor flash write_image main.bin 0x08000000 |
16 | not enough working area available(requested 8192, free 8144) |
17 | flash writing failed with error code: 0xfffffc7a |
18 | thbreak main |
19 | Hardware assisted breakpoint 1 at 0xf2: file main.c, line 104. |
20 | cont |
21 | main () at main.c:104 |
22 | 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:
1 | target remote localhost:3333 |
2 | symbol-file main.out |
3 | monitor soft_reset_halt |
4 | monitor flash erase_sector 0 0 31 |
5 | monitor flash write_image main.bin 0x08000000 |
6 | thbreak main |
7 | cont |
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%20-%20notes.txt
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.
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
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?
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)
8 MHz 14,7456 MHz 25 MHz externer Clock für USB-Einsatz, steht bei STM32F105 im Datenblatt
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.
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.
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
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.
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..
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.
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.
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.
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?
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.
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_10-polige_JTAG_Stecker_von_mmvisual Dann hast du mit 10 Pins alle Debug/Update-Möglichkeiten. Lies das mal durch was ich da geschrieben habe.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.