STM32 in C programmieren wo anfangen?
-
Hallo @ME20001,
lass Dich nicht abschrecken.
Was die IT betrifft, handelt es sich um einen begrenzten Sprachraum. Meist sind die Übersetzungen von Fachbüchern gar nicht so schlecht. Mit ein wenig Übersetzungshilfe ist auch diese Hürde zu nehmen. Ansonsten besorge Dir ggf. die deutsche UND englische Ausgabe.
-
@Helmut-Jakoby Ich habe ja schon gesehen dass es das K&R Buch auch in Deutsch gibt, das wäre dann wohl ein guter Einstieg.
Noch eine Frage: Was denkt ihr wie lange es dauert bis man in der Lage ist, in C erste einfache Modifikationen an Quellcode zu machen, oder z.B. die oben verlinkte OS so aufzuräumen dass sie einigermaßen gut lesbar wird?
Oder z.B. die OS auf einen anderen µC zu porten?
Das habe ich nämlich vor. Ich will einen der Billig BLDC Controller nehmen, den original verbauten µC aus dem Jahr 2007 ablöten, und gegen einen modernen ersetzen, der dann auch einen FPU, einen Cortex M33 Kern, und noch ein Paar andere Sachen hat, die der jetzt verbaute nicht hat.Dazu muss man dann aber ja den Quellcode auch so modifizieren, dass er die FPU, usw. auch nutzt?
-
@ME20001 sagte in STM32 in C programmieren wo anfangen?:
Oder z.B. die OS auf einen anderen µC zu porten?
Hat dein Mikrokontroller überhaupt ein OS? Oder nutzt du ein Mikro-OS ala Softdevice? Oder bietet deinen IDE Source Code für UART, SPI, DMA,... an? Oder ist alles Bare-Metal?
Das ist alles eine Frage deiner Flash-Größe.
-
Oh, sorry, ich meinte mit OS Open Source Firmware.
Die hab aber nicht ich geschrieben (Wäre schön wenn ich soweit schon wäre)Die hat kein Operating System, das Ding ist Bare Metal, was anderes würde mit dem Chinesen BLDC Controller der ab Werk einen µC aus 2007 (STM32FEB) drauf hat auch nicht gehen, kannst es dir ja bei Github mal ansehen.
Ist eigentlich der Schreibstil wirklich so schlimm wie ein Professioneller Programmierer den ich kenne sagte? Der hat als er das gesehen hat nur gesagt "Katastrophe, reine Katastrophe" und den Kopf geschüttelt.
-
@ME20001 sagte in STM32 in C programmieren wo anfangen?:
Ist eigentlich der Schreibstil wirklich so schlimm wie ein Professioneller Programmierer den ich kenne sagte?
Nein, das ist nicht so schlimm, solange man ordentlich dokumentiert und sauber programmiert. Und ich habe schon auf allen Ebenen (C#, C++, C) grausamen Code gesehen.
Ich würde dir erst einen C Crashkurs empfehlen. Kaufe dir danach ein Eval-Board des Zielprozessors und spiele damit herum. Das Datenblatt des Prozessors ist dein ständiger Begleiter, da du Bare Metal programmierst.
Am Anfang kommt die Pin Konfiguration, danach die Ansteuerung der LEDs und danach die UART Ansteuerung, damit du mit dem PC kommunizieren kannst. Und danach kannst du mit anderen Funktionen der CPU herumspielen wie Timer, ADC, DAC, DMA,...
Und erst danach würde ich mir das OS-Framework ansehen. Mit ein wenig Glück unterstützt der Code den Prozessor. Ansonsten wird eine Anpassung notwenig.
-
@Helmut-Jakoby sagte in STM32 in C programmieren wo anfangen?:
Was die IT betrifft, handelt es sich um einen begrenzten Sprachraum. Meist sind die Übersetzungen von Fachbüchern gar nicht so schlecht.
Erstens ist es nicht wahr, dass die Übersetzungen nicht schlecht wären, und zweitens, viel wichtiger: Alle anspruchsvolleren Werke werden gar nicht erst übersetzt. Daher Profi-Tipp: Ohne Englisch schließt man sich selber von sämtlichem hochwertigen Wissen der Welt aus. Nicht nur IT, sondern allgemein, aber IT ganz besonders.
-
@ME20001 sagte in STM32 in C programmieren wo anfangen?:
oder z.B. die oben verlinkte OS so aufzuräumen dass sie einigermaßen gut lesbar wird?
Wie kannst du das beurteilen?
Und wie kommst du auf die Idee, du könntest das besser lesbar machen?Ich hab nur kurz 2-3 Dateien aufgemacht und mir ist nichts aufgefallen, was ich jetzt irgendwie schrecklich finden würde. Lesbar sieht der Code für mich schon aus. Aber um das richtig zu verstehen, braucht man viel Spezialwissen.
-
Ich kann es nicht aus der Sicht eines Profis beurteilen, aber wenn man den Code mit dem eines
"Profis" (Der das beruflich macht) vergleicht, sieht der der Profis viel "Ordentlicher" aus.Ich wüde auch nicht fast alles in die main.c schreiben sondern für jeden Programmabschnitt eine eigene .c Datei erstellen, dann findet gerade ein anderer sich in dem Code viel besser zurecht.
Auch sind da so sachen an dem Code die in meinen Augen keinen Sinn ergeben, z.B. gibt es in der Config.h eine Funktion um die Drehrichtung des Motors zu ändern (Reverse) deren Wert kann entweder 1 oder -1 sein, um die Funktion ein oder auszuschalten. Warum nicht 1 und 0 das würde doch mehr Sinn ergeben?
Aber wie lange wird man ungefähr brauchen, bis man an so einem Code rumcoden kann ohne dass gleich alles explodiert danach?
-
Ok, ja, die main.c ist etwas lang und vermutlich nicht optimal aufgebaut.
Ist aber auch nicht die einzige .c Datei.
Das ist noch ein relativ schwaches Kriterium, um die Qualität des Codes zu beurteilen. Ich hab mir das wie gesagt nicht genauer angeschaut, aber ich meine, ich habe schon sehr viel Code gesehen, der auf den ersten Blick wesentlich schlimmer ausgeschaut hat.Nur geraten - 0 bedeutet, der Motor steht, -1 und 1 geben eine Richtung an.
Ich denke, du solltest mindestens mit Monaten rechnen. Und dann kommts halt drauf an... Hardwareprogrammierung ist nicht ohne Tücken. Kann sein, dass irgendwas nicht/falsch dokumentiert ist, irgendwelche sporadischen Probleme auftauchen usw.
-
Ok, dann sehe ich mir mal das Buch von K&R an (ANSI C), und schaue wie weit ich damit komme.
-
@SeppJ sagte in STM32 in C programmieren wo anfangen?:
Der Standardanfang für solides C, wenn man noch gar nichts kann, ist das Buch von K&R.
Leider ist dieses Buch (meines ist die deutsche Übersetzung der 1990 Auflage - ANSI C) nicht mehr aktuell und strotzt vor kleinen Fehlern, die für Anfänger fatal sein können. Z.B. wird faktisch nie main() korrekt definiert. Immer wieder wird das implizite int für main genutzt. Das ist K&R C und kein ANSI C.
-
Leute, könnt ihr bitte mal aufhören, ständig widersprüchliche Aussagen zu machen?
Der eine sagt das ist gut, der adnere sagt nein ist es nicht, der nächste sagt das enthällt Fehler,
das ist genau der Grund warum ich mit dem Lernen von C bislang nicht weiter gekommen bin, weil immer jeder was anderes gesagt hat...
-
@ME20001 sagte in STM32 in C programmieren wo anfangen?:
Leute, könnt ihr bitte mal aufhören, ständig widersprüchliche Aussagen zu machen?
Es haben ja noch gar nicht alle geantwortet ...
Bekommst du sonst im Leben eindeutige Antworten von verschiedenen Leuten?
-
modules:composer.user_said_in, @manni66, STM32 in C programmieren wo anfangen?
Bekommst du sonst im Leben eindeutige Antworten von verschiedenen Leuten?
Nein, aber man sollte dich davon ausgehen dass Profis hier wenigstens in etwa wissen, was
da geeignet ist. So kommt man ja garnciht dazu mit irgendwas anzufangen, weil gerade wenn man es versucht kommt der nächste und sagt "Neinnein das ist nciht so gut dafür"
Genauso mit den Compilern. Der eine sagt Keil ist der beste, der nächste sagt nein Keil ist veraltet und kompilziert, Eclipse ist viel besser, dann kommt wieder einer und sagt nein weil Keil hat die bessere Codeoptimierung (Was meiner Erfahrung nach stimmt) als Eclipse, usw usf, da wird man ja verrückt dabei...
-
Vielleicht gibt es ja keine Lösung, die 100% richtig ist? Für den einen ist Kompromiss A) wichtiger als für den Anderen.
-
@ME20001 sagte in STM32 in C programmieren wo anfangen?:
Leute, könnt ihr bitte mal aufhören, ständig widersprüchliche Aussagen zu machen?
Das K&R Buch war einmal das Standardlehrbuch für C, und es war für die damalige Zeit auch ein gutes Lehrbuch. Ich kenne sowohl die K&R C Version als auch die ANSI C Version (die deutsche Übersetzung von 1990 steht bei mir im Regal inklusive Lösungsband von Tondo/Gimpel). Das Problem an der ANSI Auflage ist leider, dass das Buch kein ANSI C beschreibt sondern ein Mittelding zwischen K&R C und ANSI C. Das fängt schon damit an, dass „das erste C-Programm“ so formuliert ist:
#include <stdio.h> main() { printf("hello, world\n"); }
Das führt bei mir zu folgender Warnung
gcc-11 -std=c17 -Wpedantic -Wall -Wextra first_program.c -o first_program first_program.c:3:1: Warnung: Rückgabetyp ist auf »int« voreingestellt [-Wimplicit-int] 3 | main() | ^~~~
Abgesehen von der Formatierung, die würde ich anders machen, enthält schon dieses erste Programm einen substantiellen Fehler. Die
main
-Funktion muss entweder alsint main()
oder alsint main(int argc, char *argv[])
definiert werden. Ausnahmen gibt es nur bei Hosted Compilern, und bei denen steht das explizit im Handbuch. D.h. so kann man das mittlerweile nicht mehr vermitteln. Weil auch die aktuellen Compiler noch immer versuchen möglichst mit K&R C kompatibel zu sein, übersetzt es mein Compiler mit einer Warnung.Besser wäre es, das erste Programm so zu formulieren
#include <stdio.h> #include <stdlib.h> int main () { printf("hello, world\n"); return EXIT_SUCCESS; }
Dann besteht das Problem, dass das K&R Buch sich weitestgehend an ANSI C hält. Die erste ISO Norm von 1990 ist faktisch mit ANSI C identisch. Nur gab es in der Zwischenzeit einige Neuauflagen der ISO C Norm, bei denen sich nicht Unerhebliches in C geändert hat. Das kann natürlich nicht im K&R Buch enthalten sein.
-
@ME20001 Willkommen in der Welt der Softwareentwicklung
BTW: Eclipse ist kein Compiler
-
@john-0 sagte in STM32 in C programmieren wo anfangen?:
Das Problem an der ANSI Auflage ist leider, dass das Buch kein ANSI C beschreibt sondern ein Mittelding zwischen K&R C und ANSI C. Das fängt schon damit an, dass „das erste C-Programm“ so formuliert ist:
C89/C90 erlaubt implicit int, erst C99 verbietet es. Da ist also nichts falsch bei K&RII.
Und wenn du statt -std=c17 -ansi genommen hättest, wäre das auch sichtbar geworden.
-
@Wutz Das ist zwar formal richtig, ich finde es aber so oder so als besseren Stil den Rückgabewert explizit anzugeben.
-
@Wutz sagte in STM32 in C programmieren wo anfangen?:
C89/C90 erlaubt implicit int, erst C99 verbietet es. Da ist also nichts falsch bei K&RII.
Und wenn du statt -std=c17 -ansi genommen hättest, wäre das auch sichtbar geworden.Nicht falsch ist nicht gleich empfohlen und guter Stil. Bitte nicht vergessen aktuell ist C17 und kein ANSI C! D.h. das Compiler Flag für C17 war zwingend notwendig, um zu sehen was an diesem Buch nicht mehr empfehlenswert ist.