Hi in folgendem Thread wurde mir bezüglich des Kaufes eines STM32 toll geholfen: Beitrag "STM32 Blue Pill bei eBay: Original oder Fälschung?" Gekauft wurde letztendlich dieser: https://robotdyn.com/stm32f303cct6-256-kb-flash-stm32-arm-cortexr-m4-mini-system-dev-board-3326a9dd-3c19-11e9-910a-901b0ebb3621.html Vielen Dank dafür. Ich verwende den uC zusammen mit einem ST Link V2 Clone und kann den uC damit wunderbar programmieren und auch debuggen. Im Prinzip habe ich also alles, was ich fürs Hobby Programmieren benötige. Ich bin allerdings neugierig und bräuchte nun ein wenig Hilfe, die weiteren Begriffe und Zusammenhänge besser zu verstehen, wie man Programme auf den uC laden kann, weil ich Anleitungen und Videos gesehen habe, aber den dahinterliegenden Grund nicht verstanden habe (nach dem Motto: Warum so umständlich, wenn man auch einen ST Link für das gleiche Geld kaufen kann?): 1. Möglichkeit: Man verwendet einen USB to Serial (FTDI) und kann damit das Programm auf den uC draufspielen. Diese Möglichkeit nennt man flashen und wird z.B. über USART, I2C, SPI mit dem uC kommuniziert. Man kann nicht debuggen. Diese Möglichkeit den Bootloader zu verwenden wird von STM32 von Haus aus unterstützt. 2. Möglichkeit: Auf Youtube habe ich Videos gesehen, dass man mittels FTDI den Bootloader umprogrammieren kann, um anschließend Programme direkt mittels USB auf den uC zu flashen. Man umgeht also nachfolgend den USB to Serial Wandler und verwendet direkt USB. Diese Möglichkeit unterstützt ebenfalls KEIN debugging. Man programmiert den uC nicht, sondern flashed ihn. Egal ob Möglichkeit 1 oder 2, man kann immer mittels ST Link V2 den uC Programmieren und anschließend auch Debuggen. Hat man Möglichkeit 2 realisiert, kann man trotzdem anschließend Programme mittels FTDI seriell auf den uC laden? Ist das korrekt zusammengefasst und verstanden? Fragen über Fragen... :) Danke und Gruß,
Guten Morgen. Flashen ist der Vorgang, der ein Binary in einen Programmspeicher schreibt, wenn dieser ein Baustein in Flash-Technologie gefertigt ist. Das geht sowohl per RS232 als auch per JTAG. Auch das Umprogrammieren des Bootloadersi st ein Flashprozess. Es ist halt nur eine spezielle Software. Debugging geht nur mit JTAG. Dazu kann man derzeit nur den St-Link verwenden. Sicher existieren noch andere Adapter. Die entsprechende Artikelseite hier nennt einige Möglichkeiten. Gruss Robert
R. F. schrieb: > Debugging geht nur mit JTAG. Dazu kann man derzeit nur den St-Link > verwenden. Das stimmt doch garnicht! Debuggen kann man auch mit SWD oder per UART und printf() ... Es gibt auch Programmierwerkzeuge anderer Anbieter, namentlich Segger.
Alex schrieb: > nach dem Motto: Warum so umständlich, wenn man auch einen ST Link für > das gleiche Geld kaufen kann? Manche Leute haben es gerne umständlich. Manche verweigern sich gegenüber Debuggern aus quasi-religiösen Gründen ("echte Schotten machen keine Fehler und müssen nicht debuggen"). Wer einen Debugger a la ST-Link, JLink o.ä. hat kann damit alles machen und kann sich die anderen Möglichkeiten sparen. Viele Arten von Fehlern findet man mit Debuggern sofort, an denen man sonst ewig suchen kann, weshalb ich immer Debugger nutzen würde. Alex schrieb: > Hat man Möglichkeit 2 realisiert, kann man trotzdem anschließend > Programme mittels FTDI seriell auf den uC laden? Ja, aber die überschreiben dann den USB-Bootloader. Das ganze ist übrigens nicht FTDI-spezifisch, es geht mit beliebigen USB-Serial-Adaptern. Die größeren STM32 haben übrigens USB-Bootloader eingebaut, können also direkt ab Werk per USB-DFU programmiert werden.
ST hat da auch noch eine Meinung zum Flashen der STM32 : AN2606 https://www.st.com/resource/en/application_note/cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf neben JTAG, SWD, USB, SPI, I2C, CAN ud UART kann man natürlich auch noch einen eigenen Bootloader ins Flash schreiben wie z.B. bei Arduino üblich.
Es gibt bei den STM32 grundsätzlich zwei Wege wie man sein Binary in den Flash-Speicher schreiben kann. 1. über die Debug-Schnittstelle (für gewöhnlich SWD, prinzipiell geht auch JTAG) 2. über einen Bootloader Die Begriffe "flashen" und "programmieren" (manche älteren Semester sprechen noch gerne von "brennen") bedeuten dabei das gleiche, egal auf welchem Weg man das macht. Die STM32 haben ab Werk alle mindestens einen UART-Bootloader und viele haben darüber hinaus noch andere Bootloader für andere Schnittstellen, z.B. USB oder CAN. Diese Bootloader kann man nicht überschreiben. Aktivieren kann man sie über die BOOT-Pins, die z.B. auf den Bluepill-Boards auf Stiftleisten herausgeführt sind, so dass man die mittels Jumper aktivieren kann. Dein Board von Robotdyn mit dem F303CC kommt von Haus aus mit einem USB-Bootloader, während die F103C8 auf den Bluepills diesen nicht haben. Da besteht dann die Möglichkeit einen eigenen Bootloader "nachzurüsten". Zum Entwickeln sehe ich gegenüber einem Debugger ehrlich gesagt keine Vorteile aber im Feld ist ein Firmwareupdate eines Gerätes sicherlich einfacher mittels USB, UART oder CAN zu machen, statt irgendwo einen Debugger anzuschließen.
Programmierer schrieb: > Ja, aber die überschreiben dann den USB-Bootloader. Nein. Der unveränderliche Bootloader des STM32F303 unterstützt UART, USB (und bei einigen anderen Modellen auch I²C). Einen selbst geschriebenen Bootloader (im Arduino Style) im Flash braucht man da nicht. Debugging (im Sinne von: Haltepunkte setzen und in die Register gucken) geht über die SWJ Schnitstteelle, die zwei Protokolle Unterstützt: JTAG und SWD Wobei man bei JTAG ergänzen sollte, dass das keineswegs so standardisiert ist, wie es klingt. JTAG definiert nicht viel mehr, als wie man Daten seriell rein und raus schiebt. Wo genau die Daten hin müssen und wie sie interpretiert werden, ist wieder bei jedem Hersteller anders. Insofern ist die JTAG Schnittelle fast genau so Hersteller-Spezifisch wie SWD. Siehe http://stefanfrings.de/stm32/stm32f3.html#proginterfaces
Stefan ⛄ F. schrieb: > Nein. Der unveränderliche Bootloader des STM32F303 unterstützt UART, USB > (und bei einigen anderen Modellen auch I²C). Einen selbst geschriebenen > Bootloader (im Arduino Style) im Flash braucht man da nicht. Ich meinte natürlich den selbst gebrannten Bootloader aus der Frage. Dass sich dieses selbst brennen bei Modellen mit USB-Bootloader erübrigt ist klar.
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.