Hallo, Ich suche ein Einsteigertaugliches Tutorial/Buch zur STM32 Programmierung in C. Wisst ihr da was taugliches? Wenn möglich Deutschsparchig? Meine bisherigen Kenntnisse beschränken sich Hauptsächlich auf 8051er/AVR Assemblerprogrammierung.
O je, Diller... da schreibt mal wieder einer zu allererst sowas: " 1. IDE, Programmer & Eval-Boards" Wenn ich so eine Herangehensweise sehe (zuerst ne IDE, dann ein Evalboard mit ST-Link drauf, dann der Rest der Welt), dann dreht sich mir der Magen herum. Nein, solche Herangehensweise ist so ziemlich das Verkehrteste, wenn man etwas lernen will. Aber danach hast du "ich" ja garnicht gefragt, sondern: Ich schrieb: > ... Tutorial/Buch zur STM32 Programmierung in C OK, wenn du also nur lernen willst, wie man die STM32 mit einer in C geschriebenenen Firmware versieht, dann kannst du dir die o.g. Seite durchlesen und am besten ausdrucken. Dann exakt 1:1 nachmachen und fertig. Aber wenn du etwas lernen willst und eigene Fähigkeiten entwickeln, dann gehe lieber ganz anders heran: - Zu allererst solltest du dich damit abfinden, englische Texte zu lesen. Es gibt fast nichts anderes. Ist eben so, also klag nicht drüber - Dann sollest du mal querbeet diverse C-Quellen und was einfaches an C-Tutorials dir anschauen und dir dabei C beibringen. Da wirst du als erstes genug Frust kriegen. Zum einen wegen der Sprache als solcher, zum anderen wegen der ganz häufig miserabel geschriebenen Quellen, wo sich viele darin üben, möglichst "genial", also unverständlich oder maßlos über-verkompliziert und newdenglish zu schreiben. - Selber solltest du beim Schreiben deiner Quellen von allem Schnickschnack absehen, den du nicht UNBEDINGT benötigst. Also schreib du lieber bieder und auch ne Zeile mehr, das ist auf lange Sicht besser weil klarer. Negativbeispiel der klassischen Art gefällig: while(*d++=*s++); Man kann sowas auch ausführlich hinschreiben und den Compiler die Optimierung machen lassen. - Dann solltest du dir die Manuals und die Referenzmanuals zu verschiedenen Chips aus der Arm/Cortex-Klasse anschauen. Und zwar von Chips verschiedener Hersteller, nicht bloß von ST. Lies dir auch mal die Referenzmanuals zu den verschiedenen CPU-Varianten (Cortex M0, M0+, M3, M4F) durch. Bei alledem brauchst du nicht jede einzelne Zeile auswendig zu lernen, hier geht es erstmal nur um den Überblick und den Eindruck, den du von CPU und dem anderen Zeugs auf dem Chip gewinnst. Es geht aber auch darum, einen Eindruck von den Manuals als solchen zu gewinnen. Nicht jeder mag jeden Stil. Ich z.B. habe sehr etwas gegen die Manuals von Freescale, die gehen mir auf den Keks. Aber das muß jeder selbst für sich entscheiden. - Dann besorgst du dir ein Minimalboard für den Chip, den du dir inzwischen ausgesucht hast. Sowas wie die billigen Bluepill- Brettln aus China sind da erstmal am besten. Es ist fast nix drauf, was dich ansonsten bei all den Evaluation-Boards stören würde, du kommst an fast alle Pins heran und es ist auch noch billig. Aber guck lieber mal über'n Tellerrand, so z.B. bei NXP (LPCxxxx), Nuvoton und wenn du willst auch Texas und Atmel und Freescale (via NXP). Merke dir dabei, daß STM32 nicht das Maß aller Dinge sind, insbesondere stört mich bei denen, daß die Peripherie immer noch ziemlich weitgehend nur 16 bittig ist. Da sind andere viel besser. - Dann installierst du dir erstmal eine Toolchain deiner Wahl. Wer mit Linux lebt, der nimmt den Gcc, wer Windows hat, hat die Wahl zwischen Keil, IAR und Gcc. Vom Keil und vom IAR gibt es frei benutzbare Bastlerversionen, die bis zu 32K Code können. Laß dich davon nicht abschrecken, es gibt ne Menge Chips, wo garnicht mehr Flash drauf ist und mit der Codequalität vom Keil kommt der Gcc nicht mit. - So, und dann lerne erstmal, deinen Compiler+Assembler+Linker+Fromelf+Programmiertool zu Fuß aufzurufen, also von der Kommandozeile. Nicht verständnislos gucken, das ist wichtig um es können zu können und eben nicht vom Gewurschtel einer IDE sklavisch abhängig zu sein. Wer das kann und sich gegebenenfalls ne kleine .bat oder ein Script selber schreiben kann, der kann dann auch ne IDE benutzen und selbige wieder wegschmeißen, wenn sie ihm in die quere kommt, ohne dann aufgeschmissen zu sein. Und nochwas: Am lautesten schreien viele Leute nach dem Debugger. Insbesondere diejenigen, die nicht gründlich denken und ihren Code sauber strukturieren können oder wollen. Ich halte den Debugger für zweitrangig, das Verstehen der Hardware und das "biedere" Formulieren der Programmquellen ist viel wichtiger. Dann kommt man übrigens bei vielen Chips auch mit dem dort eingebauten residenten Bootlader aus und benötigt dafür eben kein besonderes Debug-Geschirre wie diversen -Link's (JLink, STLink, LpcLink oder weiß der Geier-Link). Und wenn schon, dann ist der JLink noch immer das Maß der Dinge. W.S.
Da du schon Vorkenntnisse hast brauchst du meiner meinung nach nicht mehr als eine kleine Einstiegshilfe und die Datenblätter des Herstellers. Schau mal: http://stefanfrings.de/stm32/index.html > Ich halte den Debugger für zweitrangig, das Verstehen der Hardware > und das "biedere" Formulieren der Programmquellen ist viel wichtiger. Dito. Wobei der Debugger bei STM32 (im Gegensatz zu AVR) fast verschenkt wird. Es wäre vielleicht auch ganz hilfreich, die Programmiersprache C erstmal auf einem PC ganz ohne Mikrocontroller zu lernen. Dazu könntest du QT Creator herunterladen und einfach loslegen. Tutorials dazu gibt's ja genug. Die Anleitungen von Diller beziehen sich auf die veraltete und schon lange nicht mehr gepflegte Standard Peripheral Library. Aktuell ist aber die Cube HAL. Ich würde zum Lernen aber erstmal auf solche Abtraktions-Libraries verzichten, und wirklich mit Datenblatt und Registern auf Bit-Ebene arbeiten. Das ist am Ende meiner Meinung nach kaum schwerer, als durch die HAL durchzusteigen.
Eins der Bücher gibt's kostenlos hier: https://www.eecs.umich.edu/courses/eecs373/labs/refs/M3%20Guide.pdf Der Mann beschreibt allerdings nur den ARM Kern. Mit dem Buch alleine kann man noch nichts anfangen. Ich kann es allerdings als Begleitlektüre zur Doku von STM sehr empfehlen.
Stefan U. schrieb: > die Cube HAL. Ich würde zum Lernen aber erstmal auf solche > Abtraktions-Libraries verzichten, und wirklich mit Datenblatt und > Registern auf Bit-Ebene arbeiten. Das ist am Ende meiner Meinung nach > kaum schwerer, als durch die HAL durchzusteigen. Arbeiten auf Bitebene ist erstens für normale Programmierer unnötig und zweitens ist das bestimmt schwerer und die Möglichkeit einen Fehler zu machen oder etwas wichtiges zu vergessen (Clock einschalten z.B.) ist ungefähr 1:100. HAL macht das alles per Mausclick und zwar ohne Fehler. Ob man: I2C_Init(I2C1, &I2C_InitStructure); selbst schreibt, oder: if (HAL_I2C_Init(&hi2c1) != HAL_OK) von Cube geschrieben wird, ist letztendlich egal. Aber um zu sehen was da wirklich passiert, müsste man tief in die Library einsteigen - wozu ? ARM wird immer schneller, da kommt es auf ein paar Takte wirklich nicht mehr an. Wenn es aber auf den Takt genau sein soll, nimmt man einen AVR oder PIC als Slave, programmiert diesen in Assembler und ARM steuert den ganzen Zirkus. Und 400MHz mit 32bit, 2MB Flash, 1MB RAM und 168 I/O Pins ist nicht gerade wenig, oder ?
:
Bearbeitet durch User
> da kommt es auf ein paar Takte wirklich nicht mehr an
Richtig. Aber es kommt darauf an, die Dokumentation der HAL zu lesen und
zu verstehen.
Ich persönlich beschäftige mich lieber zuerst mit dem Datenblatt des µC
und dem Reference Manual der Serie.
Aber das ist Geschmackssache.
W.S. schrieb: > - So, und dann lerne erstmal, deinen > Compiler+Assembler+Linker+Fromelf+Programmiertool zu Fuß aufzurufen, > also von der Kommandozeile. Nicht verständnislos gucken, das ist wichtig > um es können zu können und eben nicht vom Gewurschtel einer IDE > sklavisch abhängig zu sein. Wer das kann und sich gegebenenfalls ne > kleine .bat oder ein Script selber schreiben kann, der kann dann auch ne > IDE benutzen und selbige wieder wegschmeißen, wenn sie ihm in die quere > kommt, ohne dann aufgeschmissen zu sein. Prinzipiell stimme ich Dir zu, dass das nützliche Kenntnisse sind, auf die leider zu wenig wert gelegt wird. Allerdings halte ich es für gewagt das alles gleich am Anfang zu lernen. Da kann schnell die Lust vergehen. Marc V. schrieb: > HAL macht das alles per Mausclick und zwar ohne Fehler. Aktuelles Cube für STM32F407VG => USB Audio Device in Cube zusammenklicken. Fehler. Der Code Generator vergisst ein oder (|) bei der Initialisierung der Clocks. Soviel zu "ohne Fehler"... Marc V. schrieb: > Arbeiten auf Bitebene ist erstens für normale Programmierer unnötig > und zweitens ist das bestimmt schwerer und die Möglichkeit einen Fehler > zu machen oder etwas wichtiges zu vergessen (Clock einschalten z.B.) > ist ungefähr 1:100. Das würde ich nicht sagen. Gerade am Anfang kann es sinnvoll sein, recht tief anzusetzen. Man muss sein Linkerskript ja nicht gleich am Anfang selbst schreiben. Aber die Peripherie der STMs ist in der Regel recht ausführlich im Reference Manual beschrieben. Da er bereits AVRs programmiert hat, sollte er also mit Datenblättern zurechtkommen. Ich würde am Anfang, wenn STM, auf ein STM32F4 discovery setzen. Da ist einige Hardware drauf, um einfache Anfänge zu starten und es sind noch genug Pins herausgeführt, um eigene Hardware anschließen zu können. Programmer/Debugger ist on-board. Für den STM32F407 gibt es ebenfalls noch das Clock Config Tool, das leider in Excel mit Macros geschrieben ist. http://www.st.com/en/development-tools/stsw-stm32091.html Das generiert registerbasierten Code, der leicht eingebunden werden kann.
> HAL macht das alles per Mausclick und zwar ohne Fehler.
Als ich Cube HAL vor ein paar Monaten zum ersten mal benutzte, hat er
glatt die Clock Initialisierung so falsch gemacht, dass sich der µC
dabei aufhängte. Da brauchte ich schon ganz zu Beginn Hilfe von den
Profis. Und genau das war bei mir der Auslöser, es mal ohne HAL zu
versuchen. Dabei bin ich bisher geblieben, außer wenn ich USB benutze.
Das ist mir dann ohne fertige Libs doch eine Nummer zu hoch (noch).
Marc V. schrieb: > > ARM wird immer schneller, da kommt es auf ein paar Takte wirklich nicht > mehr an. Nein, die Aussage ist im Allgemeinen falsch. Wir hatten z.B. hier im Forum mehrmals sehr konkrete Fallbei(l)spiele, wo Interrupthandler für serielle Schnittstellen Zeichen auf der Rx Seite verloren haben, weil der Overhead für die HAL Aufrufe zu viele Zyklen verbraten hat. Und den Prozessor überdimensionieren, nur um sich Programmierkomfort zu erkaufen ist auch nicht immer die richtige Lösung. Wo zum Beispiel Stromverbrauch und Wärmeentwicklung im kritischen Pfad liegen, wird man notwendigerweise den am langsamsten getakteten Prozessor nehmen, den man kriegen kann, und dann muss man in den kritischen Pfaden anfangen auf Zyklenebene zu optimieren. Mal abgesehen davon, dass abhängig von der Stückzahl schon Centunterschiede zwischen verschiedenen PODs einen grossen Unterschied machen können, also in der Regel der kleinste Prozessor, der das gegebene Problem lösen kann, der attraktivste ist. Zurück zum topic - @"Ich": Wenn Du magst, kannst Du ja mal hier reinschnuppern (Vorsicht Eigenwerbung, setzt C Kenntnisse voraus): https://books.google.de/books?id=8ra8DQAAQBAJ&pg=PT344#v=onepage&q&f=false
:
Bearbeitet durch User
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.