Guten Abend zusammen, Ich bin noch einsteiger in der ARM-Szene und habe nun wirklich recht lange mich versucht in dem Wirrwar an Libraries zurecht zu finden. Gerne hätte ich eure Meinung dazu, welche Libraries ihr verwendet. Es gibt so viele Möglichkeiten anzufangen dass mich das erstmal leicht überfordert. Ich weiß zwar, was ich einstellen möchte, aber nicht über welchen Weg ich das am Besten vornehmen soll (z.B. SPI einstellen, aktivieren, nutzen..). Die HAL und die SPL bieten dazu natürlich funktionen. Aber nicht alles ist irgendwie gut dokumentiert (Oder ich kenne die richtige documentation dazu nicht). In meinem Fall habe ich das STM32F4 Discovery Board und habe die Möglichkeit, die Discovery Firmware einzusetzten in der die Standard Peripheral Libraries vorhanden sind, welche wohl auch nichtmehr weiterentwickelt werden. Zudem hab ich die Möglichkeit die CubeF4 Libraries zu nutzen, in der die HAL aufzufinden ist, welche wohl noch unterstützt wird. Irgendwie darin vergraben ist dann auch die CMSIS, wobei diese wohl nicht direkt eine Librarie ist sondern eher Registerdefinitionen beinhaltet und keine Abstraktion in dem Sinne zur Verfügung stellt, schnell mal einen GPIO Port einzustellen (Was dann ja die HAL / SPL übernehmen würde). Einem neueinsteiger machen diese scheinbaren "vereinfachungen" eher erstmal Probleme. Was empfiehlt ihr mir dabei? Ich habe zuvor ein paar Atmels programmiert und dabei die Register alle immer selbst gesetzt. Danke schonmal fürs Lesen :).
Raphael G. schrieb: > Einem neueinsteiger machen diese scheinbaren "vereinfachungen" eher > erstmal Probleme. ...nicht nur den Neueinsteigern. Der ganz große Nachteil ist, daß Du jetzt plötzlich 2 Dokumentationen lesen und verstehen musst: die des µC und die des "Abstraktions"layers. Das "Abstraktion" setze ich hier ganz bewusst in Anführungszeichen, weil das, was das ST-HAL und Cube machen, eigentlich keine wirkliche Abstraktionstiefe hat und einem nicht erspart die µC-Dokumentation genau zu lesen. Außerdem kommen dann noch Bugs in HAL und Cube hinzu... > Ich habe zuvor ein paar Atmels programmiert und dabei die Register alle > immer selbst gesetzt. Niemand hindert Dich daran das bei den STM32 genauso zu machen! Falls Du das nicht möchtest, würde ich mir als Alternative mal einen echten HAL-Layer anschauen, der den Namen auch verdient. Ich mag da das ChibiOS ganz gerne: http://chibios.org/dokuwiki/doku.php Da dort im HAL nicht alles umgesetzt ist was der µC kann, kombiniere ich das bei Bedarf mit ein paar Funktionen, die die nötigen Register direkt setzen. Aber auch da sollte man die nötigen Kapitel im Datenblatt, Reference Manual, Programming Manual und Errata Sheet von dem verwendeten STM32 gut kennen. Sonst stolpert man früher oder später.
Raphael G. schrieb: > Einem neueinsteiger machen diese scheinbaren "vereinfachungen" eher > erstmal Probleme. Was empfiehlt ihr mir dabei? Auf jeden Fall mit CubeMX anfangen. Grafische Oberfläche, es wird alles angezeigt was der ausgewählte Typ hat, ev. Konflikte werden sofort angezeigt, etc... Projekte für EWARM, Truestudio und andere werden automatisch erstellt. Als Anfänger (und auch als Fortgeschritener) kann man ganz einfach nicht alles über alle Ports, Timers usw. wissen und wenn man zuerst mit Reference Manual, Programming Manual und ähnlichem anfängt, hat man ganz schnell die Lust und Überblick verloren. Um das Lesen der ganzen Manuals wirst du sowieso nicht rumkommen, aber es muss ja nicht gleich am Anfang sein... Erst mal ein paar Erfolgserlebnisse, danach geht alles leichter.
:
Bearbeitet durch User
Marc V. schrieb: > (und auch als Fortgeschritener) kann man ganz einfach > nicht alles über alle Ports, Timers usw. wissen und wenn man zuerst > mit Reference Manual, Programming Manual und ähnlichem anfängt, hat > man ganz schnell die Lust und Überblick verloren. Äh? Ohne das verallgemeinern zu wollen, aber ich persönlich sehe das anders. Mir machen solche komischen Graphiktools wie CubeMX eher Sorgen, weil ich nicht nachvollziehen kann, was da gemacht wird. Von dem vendor-lock-in, der ja der strategische Hauptzweck dieses Danaergeschenkes ist, mal ganz zu schweigen.
Nop schrieb: > anders. Mir machen solche komischen Graphiktools wie CubeMX eher Sorgen, > weil ich nicht nachvollziehen kann, was da gemacht wird. Tja, ich sehe das anders. Cube sorgt dafür, dass nichts vergessen oder falsch eingestellt wird. HAL stellt nur die entsprechenden funktionen bereit. Alles andere ist ja dasselbe. Also, Grundgerüst mit Cube, Feineinstellungen von Hand...
Marc V. schrieb: > Cube sorgt dafür, dass nichts vergessen oder falsch eingestellt wird. Für die Kundschaft mit solchen "Sorgen" gibt's Arduino, da ist diese Philosophie konsequent umgesetzt. Keine erschreckenden Datenbücher lesen, einfach losprogrammieren. > HAL stellt nur die entsprechenden funktionen bereit. Von der halte ich auch nichts.
Nop schrieb: > Für die Kundschaft mit solchen "Sorgen" gibt's Arduino, da ist diese > Philosophie konsequent umgesetzt. Keine erschreckenden Datenbücher Ein Vergleich zwischen Arduino und STM32 hinkt aber gewaltig. Etwa wie Fahrrad und Rennmotorrad oder Auto und Flugzeug, nach dem Motto: ich kann Auto ohne Checkbuch fahren, also wird es auch mit Flugzeug klappen, sind ja nur ein paar Schalter und Instrumente mehr... Und ich will nicht erst stundenlang Datenbücher wälzen, um endlich rauszufinden, dass sich irgendein Pin mit irgendeinem anderem Pin beisst und diesen praktisch ausser Funktion setzt. Und im Endeffekt will ich ganz einfach nicht immer wieder die selben 150 Zeilen stumpfen Code schreiben, wenn ich das Gleiche mit einem Mausklick erreichen kann, ohne irgendetwas zu vergessen oder falsch einzustellen.
:
Bearbeitet durch User
Ich bin vor ein paar Jahren ganz frisch in C/C++ und gleichzeitig in die µC-Programmierung eingestiegen. Habe mit SPL angefangen, dann zu HAL gewechselt um dann festzustellen, dass nur eine eigene Lib meine Forderungen erfüllt. Für mich ist folgendes in Erinnerung geblieben: - SPL reicht für einfache Dinge aus - HAL hat ein paar recht nette defines - Fall man mehr machen will, als einfach nur ein paar IOs wackeln lassen, muss man das ReferenceManual und das Datasheet lesen - SPL sowie HAL setzen an manchen Stellen Register auf 0. Das macht dann richtig Spaß den Fehler zu finden :) Deshalb muss man so oder so die ST-Funktionen durchgehen Ich habe mir aus den Libs nur Anregungen für eine eigene Lib geholt.
Danke schonmal für eure Meinungen. Für all diejenigen die gerne über Grundsatzfragen diskutieren soll das hier aber kein Spielplatz werden :). Ich habe ja explizit nach persönlichen Meinungen gefragt und möchte nicht, dass wiederum andere darin herumstochern, so kommt man immerwieder schnell vom eigentlichen Thema ab und das Nachschlagen für andere wird mehr und mehr zur Qual. Es ist ja auch wiederum interessant zu sehen, dass alleine bei den paar Beiträgen schon starke unterschiede in der Herangehensweise vorliegen. ChibiOS, CubeMX, .. eigene Libs (inspiriert von HAL und SPL). Ich werde mir natürlich alles genauer anschauen. Ich bin gespannt ob noch weitere Herangehensweisen bzw. Empfehlungen von euch hereinprasseln! Ich habe auch schon irgendwo hier gelesen, dass vereinzelte nur den "core" nutzen (Ich denke den CMSIS core? Also letztendlich nur die Registerdefinitionen nutzen?) und darauf alles selbst aufbauen (finde den Beitrag nichtmehr).
In diesem Zusammenhang kann man auch mbed bzw. mbed OS erwähnen. Als Einstieg sehr gut geeignet, vollständig Open Source, die Eignung für komplexere Anwendungen: kommt darauf an. STM32Cube ist integriert und kann auch parallel genutzt werden, wenn man weiß, was man tut. Das F4 Discovery wird allerdings nicht von der Online IDE unterstützt. Nutzt man aber die offline tools, ist es voll benutzbar. Die Doku zum mbed cli ist recht brauchbar. Nicht unerwähnt sollte bleiben, dass eine weitere Software Schicht auch weitere Bugs hinzufügen kann. Allerdings wird sehr intensiv von ARM und etlichen herstellerspezifischen Gruppen daran gearbeit und gemeldete Bugs werden recht zügig gefixt.
> Ich bin gespannt ob noch weitere Herangehensweisen bzw. Empfehlungen von > euch hereinprasseln! Ich habe auch schon irgendwo hier gelesen, dass > vereinzelte nur den "core" nutzen (Ich denke den CMSIS core? Also > letztendlich nur die Registerdefinitionen nutzen?) und darauf alles > selbst aufbauen (finde den Beitrag nichtmehr). Dazu zähle ich mich :-) Die SPL verleitet meiner Meinung dazu zu glauben, die Software von der Hardware abstrahieren zu können. Dem ist aber nicht so. Wie bereits weiter oben gesagt wurde, muss man beim Einsatz der SPL ein ähnliches Verständnis der Hardware haben wie ohne SPL. Mit dem Unterschied, dass man nun auch noch die Doku für die SPL studieren kann. Zudem kapseln eine Vielzahl von SPL Routinen Berechnungen und Registerzuweisungen, die für die eigentliche Programmausführung gar nicht nötig sind. Das macht den Code größer und langsamer. Den einzigen Vorteil den ich in der SPL sehe, ist die Kapselung diverser Operationen in benamten Funktionen. Das bringt automatisch etwas Codedokumentation mit sich. Ein Tool was ich gerne benutze/benutz habe ist das Excel basierte ClockConfiguration Tool. Das war einfach zu benutzen und hat den Initialiserungscode für den gesamten Clock-Tree generiert. Dieses Tool wird seit CubeMX aber nicht mehr weiterentwickelt. Womit wir bei CubeMX sind. Lange habe ich mir ein grafisches Tool für die Pinzuordnung gewünscht. Das macht CubeMX für mich interessant, allerdings nur zu grafischen Dokumentationszwecken bei der Pinzuordnung. Da CubeMX selbst wieder SPL und HAL Code generiert hört der Workflow in CubeMX damit auch schon auf. Ausnahme bildet hier einzig noch der zwangsweise Umstieg vom ClockConfiguration Tool auf CubeMX. Das Clock Setup führe ich wie bei der Pinzuordnung auch wieder aus Dokumentationsgründen grafisch durch und übertrage den generierten Code dann wieder in nicht SPL basierten Code. Ich möchte die SPL oder CubeMX nicht schlecht reden, beides ist gut und schön gemacht. Summa summarum bringt es mir als Embedded Entwickler jedoch in Bezug auf Codegröße und Effizienz recht wenig. Sehr gut eignet sich meiner Meinung nach jedoch CubeMX für kleine schnelle Projekte und Einsteiger in die Materie, um ein erstes Grundgerüst zu erhalten.
Raphael G. schrieb: > Ich bin noch einsteiger in der ARM-Szene und habe nun wirklich recht > lange mich versucht in dem Wirrwar an Libraries zurecht zu finden. > > Gerne hätte ich eure Meinung dazu, welche Libraries ihr verwendet. Nur kurz zu sagen, man sei "Einsteiger", ist ein bissel wenig. Die Leute hier versuchen ja, zu helfen (ein jeder auf seine Art). Aber dazu ist es nötig, etwas von deinem tatsächlichen Vorwissen zu kennen. so. Ich verwende überhaupt keine von anderen vorgefertigten Bibliotheken. Natürlich bin ich schon einige Jahrzehnte in der Branche und habe deshalb mein eigenes persönliches Portfolio. Das besteht nur zum kleineren Teil aus Quellcodes, zum größeren Teil hingegen aus Erfahrungen und dem Wissen, wie man an dies und das herangeht oder lieber die Finger davon läßt. Aber Erfahrungen sind keine Handelsware. Ich kann dir aber einen Rat geben, sofern du selbigen überhaupt haben willst. Ich mach's mal an einem Beispiel fest, wie ich bislang an sowas herangegangen bin: - zuerst das Datenblatt des konkreten Chips gelesen, dabei mir angesehen, was der so alles kann, ob mir das gefällt, ob es für meim Vorhaben ausreicht. - dann bei den üblichen Verdächtigen (RS, Farnell und Konsorten) nachgeschaut, wie die Teile denn so im Preis liegen. Wenn da kein K.O. aufkommt, geht es weiter. - Referenzmanual durchgeschaut, also erstmal überflogen. Dabei festgestellt, ob mir der Stil dieses Manuals zusagt. Ich sag's mal so: Ein Chip kann rein technisch vom Silizium her so grandios sein wie er will, wenn die zugehörige Dokumentation jedoch Scheisse ist und einem nicht das erklärt, was man zum Einsatz des Chips erfahren muß, dann ist der Chip insgesamt eben auch Mist. - Referenzmanual nach den Interrupts durchgesehen und den Startupcode in Assembler für diesen Chip geschrieben. Natürlich habe ich da meine Vorlagen, denn ich mache sowas ja nicht zum ersten Mal. Das geht also ganz leicht über die Bühne. - Referenzmanual wieder durchgesehen, diesmal der Reihe nach alle aufgeführten Hardware-Register per Copy&Paste in eine "chipname.h" geeignet kopiert, so daß ich später drauf zugreifen kann. Ja, auch ich mache manchmal Copy&Paste ... Wenn es ein ARM-Cortex ist, dann nehme ich auch die Definitionen von ARM her, die zum betreffenden Core gehören, was nötig ist für Timertick, FPU freischalten, NVIC und so. Normalerweise hat man nach dem genannten Procedere durchaus einen gewissen Überblick darüber, was der Chip so kann und wie man mit ihm im Allgemeinen umgeht. Deshalb kommt jetzt: - Eagle anwerfen, Bibliotheks-Element für diesen Chip anfertigen. Man muß ihn ja auch in eine Schaltung und auf ne LP kriegen. Das ist hier auch zur Entspannung, denn immer nur in SW herumhampeln nervt auf Dauer. Das geht jetzt aber weiter: - Eine Konfigurations-Quelle schreiben. Zu allererst will man ja die Ports sinnvoll konfigurieren, die benötigte Peripherie einschalten und den Takt aufsetzen. Das Konfigurieren der Ports ist zumeist sehr chipabhängig - bei manchen geht es angenehm leicht, bei anderen ist es ein Zirkus. Gleiches gilt für das Aufsetzen des Taktes und der eventuellen Waitstates. - Einen im eigenen Portfolio vorhandenen lowlevel-Treiber für den/die serielle(n) Port(s) auf den Chip anpassen - ne erste main.c schreiben und den Chip programmieren. Da sollte normalerweise das erste Lebenszeichen kommen. Ab da hat man ne Basis für das eigentliche Projekt. W.S.
Um meine Vorkentnisse zu konkretisieren: Ich habe zwar Mechatronik studiert, jedoch kommt die Embedded Welt (trotz zwei belegter Embedded Systems Wahlfächer) recht kurz. Ich habe also einen allgemeinen grundlegenden Überblick wie Mikrocontroller funktionieren, auch Assember in dessen Grundzügen gelernt (C sollte ich intus haben :) ), jedoch keineswegs eine praktische 'Routine'darin - ARM wurde nur mit SPL oder HAL genutzt, bei denen man letztendlich auf vom Prof zur Verfügung gestellten Beispiele zugriff hatte und die einfach nur abändern musste (totaler quatsch meiner Meinung nach, da es nie wirklich low-level ging). Privat habe ich ein paar kleine Atmel-Projekte realisiert, nichts kompliziertes aber dennoch sehr lehrreich in bezug auf lesen von Dokumentationen und setzten von Registern etc. Aufgrund meines Studiums habe ich eben das Discovery STM32F4 board mir gekauft und ich werde dieses Board weiternutzen um mich weiter einzuarbeiten, da mir das Studium auch viel zu wenig geboten hat. @W.S.: Ich nutze aktuell ein fertiges Board, ich plane also keine eigene Platine aber danke für die Beschreibung deines vorgehens :).
Wenn du die Zeit hast, dann geh übernächste Wochr zur Embedded nach Nürnberg. Tickets gibt es umsonst, wenn man sich vorher per Internet anmeldet. Aber vergiß nicht, dir ein paar Visitenkarten einzustecken. IST WICHTIGST!! Gerade als junger Bursche hat man da ne gute Gelegenheit, nicht nur Informationen, sondern auch hie und da ein Stück Hardware zu ergattern. Wer nebenher jobben muß, um sein Studium zu finanzieren, wird das zu schätzen wissen. Aber das Zahlungsmittel ist die Visitenkarte. Vergiß das nicht. Ansonsten habe ich so einiges gegen die diversen Eval- und Discovery-Boards. Die sind zumeist eben nur dazu da, den etwaigen Kunden an die jeweilige Firma zu binden - mal ganz generell gesagt. Eine echte gute Basis für Eigen-Entwicklungen sind sie nicht. Guck dich stattdessen bei Ebay um, die Chinesen lieben den STM32F103... und bieten auch billige Minimal-Boards damit an. Sowas ist weitaus besser für dich, denn diese Boards haben so ziemlich alle Pins auf Steckkontakte geführt, so daß man so einen Modul auch auf eine selbstgefrickelte gröbliche Leiterplatte setzen kann und so zumindest einige eigene Projekte damit machen kann. Ich will jetzt keine übertriebene Werbung für die STM32F103xx machen, denn es gibt bessere Chips, aber für Feld-Wald-Wiese sind die Dinger recht brauchbar. So, noch ein Wort zu sowas wie ST-Lib, HAL, Cube und Konsorten: Ich halte davon ganz und gar nichts, weil all dieses Zeugs eben keinerlei echte Hardware-Abstraktion darstellt, sondern nur eine Aufblähung ist, oder den Benutzer nicht wirklich lernen läßt, mit der HW umzugehen. Kurzum, es ist ein Tool zum Kunden-Verblöden. Wenn so einer, der seine ganzen Einstellungen noch nie begriffen hat dank Cube oder noch nie ein Register selbst mit den nötigen Bits beschrieben hat, mal auf einen Chip von ner anderen Bude trifft, ist er völlig hilflos, weil er eben nichts_ gelernt hat und folglich _nichts kann. Du solltest dir das für deinen Berufsweg merken - es selber zu können, also wirklich selbst potent zu sein, ist allzeit besser, als nur von vorgekautem Zeugs (oder dem "Gebumsten" von anderen..) zu leben. DIE DAMEN BITTE MAL KURZ WEGSCHAUEN.. W.S.
W.S. schrieb: > So, noch ein Wort zu sowas wie ST-Lib, HAL, Cube und Konsorten: Ich > halte davon ganz und gar nichts, weil all dieses Zeugs eben keinerlei > echte Hardware-Abstraktion darstellt, sondern nur eine Aufblähung ist, > oder den Benutzer nicht wirklich lernen läßt, mit der HW umzugehen. > Kurzum, es ist ein Tool zum Kunden-Verblöden. Wenn so einer, der seine > ganzen Einstellungen noch nie begriffen hat dank Cube oder noch nie ein > Register selbst mit den nötigen Bits beschrieben hat, mal auf einen Chip 90% der Anwendungen benutzen fremde Librarys und niemand stört sich daran, z.B. I2C, UART, LCD, SD-Card, um nur einige zu nennen. Alle nötigen Einstellungen werden meistens dort gemacht. Und das auch noch bei AVRs die bei weitem nicht so kompliziert sind. Jetzt auf einmal reden alle von low-level, eigenen Routinen zum Init, eigenen Bibliotheken etc. - und das gerade bei STM32 ? Es ist bestimmt nicht so, dass da ein bit in einem Register gesetzt wird und das wars dann - alles funktioniert wunderbar danach. Es sind ganz einfach zu viele Sachen auf die man aufpassen muss, nur Masochisten oder Hallo World und LED-Blinker tun sich so etwas an. SystemClock, ADC, SPI, I2C, DMA - wer von euch weiss auch nur einigermassen was und wie da alles eingestellt werden muss (ohne überhaupt auf ev. entstehenden Konflikte einzugehen) - ohne DaBla zu Hilfe zu nehmen ? CubeMX ist besser und weiss mehr über STM32 Familie (wenn man es so sagen kann) als Ihr alle zusammen, da könnt Ihr noch so viel auf ihrem Wissen bestehen... Wie gesagt, Grundgerüst mit Cube, ev. Veränderungen oder Feineinstellungen können dann immer noch von Hand gemacht werden. Und es kommen noch kompliziertere uC raus - wollt Ihr dann immer noch alles aus dem Kopf machen ? LOL.
Kann mich grundsätzlich anschließen, dass es einem die HAL in 99% der Fälle nicht erspart, das RefMan zu lesen. Dann kann man es auch gleich weglassen und effizienter programmieren. Dennoch ist CubeMX nett um vorher einen Controller auszuwählen, und nicht nachher festzustellen, dass alle Peripherals an Board sind aber die Pin-Muxes es verhindern die in gewünschter Konfiguration parallel zu betreiben.
Marc V. schrieb: > SystemClock, ADC, SPI, I2C, DMA - wer von euch weiss auch nur > einigermassen was und wie da alles eingestellt werden muss Ich zb.
Reginald L. schrieb: > Marc V. schrieb: >> SystemClock, ADC, SPI, I2C, DMA - wer von euch weiss auch nur >> einigermassen was und wie da alles eingestellt werden muss > Ich zb. LOL. Sicher. Ich will es gar nicht wissen, erst wenn mich der Cube warnt, geht es mit wälzen der Manuals los... Und in 10 Jahren wird es genauso sein... Weil es gerade dafür Computer gibt... Sind zwar dumm, können aber vieles speichern... Um auch nur 1/100 von dem zu behalten, was im CubeMX vorhanden ist, müsste ich Kopf wie einen Wassereimer haben... Und ich kann mein Gehirn für andere Sachen benutzen und dumme Computer dumme Sachen merken lassen... Du kannst es natürlich machen, wie es dir beliebt... Und dann auch noch behaupten, dass das mit Kreativität oder mit Kunst des Programmierens gleichzusetzen ist...
:
Bearbeitet durch User
CubeMX ist super für Pin Mux und Clock und um ein Projekt neu aufzusetzen. Ich packe da aber auch immer meine eigene Lib mit ins Projekt rein und passe die dann jeweils an die neue MCU an - dabei ist die "HAL" Lib aber durchaus hilfreich. Ich muss da erstmal nicht unbedingt ins Ref Man oder die HAL Doku schaun, nur in den Code. Wenn es nicht direkt zur eigenen Anwendung passt - dann den relevanten Teil kopieren und anpassen. Das ist meist ein recht brauchbarer Startpunkt. Ja das ginge wesentlich schöner und es wäre besser gewesen ST hätte das anders aufgezogen, aber es könnte auch schlimmer sein. Nein, man muss nicht jedes Register in der MCU auswendig kennen. Man darf natürlich wenn man möchte - das bringt aber nur was wenn man das Wissen dazu öfter als 1x im Jahr auch nutzt ;-)
Marc V. schrieb: > Und es kommen noch kompliziertere uC raus - wollt Ihr dann immer > noch alles aus dem Kopf machen ? Ja. Das Gute an der Sache ist, wenn man Projekte mit heftigeren Anforderungen wie z.B. code coverage und noch ein paar mehr Dingen hat, dann kann man gutes Geld verdienen, wenn man diese Dinger selber programmieren kann. Mit "ich kann aber in CubeMX was zusammenklicken" braucht man da nämlich gar nicht erst anzukommen. Natürlich ist das für Hobby völlig irrelevant. Aber wenn man sowas in Hobby-Projekten macht, wo man keinerlei Zeitdruck ausgesetzt ist, dann hat man das Wissen erarbeitet und ist im Vorteil. Zudem kann man sich nicht mit allen Chips graphisch was zusammenklicken - und die Fähigkeit, sich das nach technischen Unterlagen selber zurechtzusuchen, wird auch gut bezahlt. Wobei ich bei Dir mal davon ausgehe, daß Du das ausreichend gemacht hast und das daher im Ernstfall auch kannst. Aber Einsteiger, die gleich den bequemen Weg gehen, erwerben durch die Abkürzung diese Fähigkeit nicht.
Zoltan schrieb: > Ich packe da aber auch immer meine eigene Lib mit ins Projekt rein und > passe die dann jeweils an die neue MCU an - dabei ist die "HAL" Lib aber > durchaus hilfreich. Ich muss da erstmal nicht unbedingt ins Ref Man oder > die HAL Doku schaun, nur in den Code. Wenn es nicht direkt zur eigenen > Anwendung passt - dann den relevanten Teil kopieren und anpassen. > Das ist meist ein recht brauchbarer Startpunkt. Genauso machen wir es hier. > Nein, man muss nicht jedes Register in der MCU auswendig kennen. > Man darf natürlich wenn man möchte - das bringt aber nur was wenn man > das Wissen dazu öfter als 1x im Jahr auch nutzt ;-) Ich würde sogar wietergehen und behaupten, dass dieses "Wissen" schon nach ein paar Wochen oder Monaten weg ist oder man zumindest nicht mehr 100% sicher ist. Es sei den, man schreibt tagaus, tagein immer wieder die selben, stupiden Initsequenzen rein und ist noch stolz darauf...
Nop schrieb: > programmieren kann. Mit "ich kann aber in CubeMX was zusammenklicken" > braucht man da nämlich gar nicht erst anzukommen. Wo soll man gar nicht erst ankommen ? Als Anfänger ? > und das daher im Ernstfall auch kannst. Aber Einsteiger, die gleich den > bequemen Weg gehen, erwerben durch die Abkürzung diese Fähigkeit nicht. Naja, ich sehe das gerade anders. Schau dir mal die Initsequenz für z.B. ADC an - 50% davon versteht jeder Anfänger, die anderen 50% schreien geradezu nach Manual um zu sehen, warum das so ist. Ohne irgendeinen Gerüst zum anfangen wird der Neuling von der Menge der benötigten Informationen ganz einfach erschlagen. So kann er wenigstens Schritt für Schritt vorgehen und sich langsam vorarbeiten. Und ich kann es nur noch einmal wiederholen: Schon bei einfachstem STM32 ist mit: Ich habe alles im Kopf Schluss. Das ist einfach lachhaft und unprofessionell. Und ob gerade HAL das Nonplusultra ist - da bin ich auch nicht gerade begeistert und benutze es kaum noch, ausser für etwas was auf die Schnelle ausprobiert werden muss. Aber CubeMX ist etwas ganz anderes, nach meiner Meinung gibt es zur Zeit nichts besseres.
:
Bearbeitet durch User
Marc V. schrieb: > Wo soll man gar nicht erst ankommen ? Als Anfänger ? Mit "ich kann keine Datenblätter lesen, embedded programmieren kann ich auch nicht, aber ich kann irgendwas zusammenklicken". Damit fliegt man im embedded-Bereich schon beim Bewerbungsgespräch raus, auch als Einsteiger. > So kann er wenigstens Schritt für Schritt vorgehen und sich langsam > vorarbeiten. Nö. Die Folge ist stattdessen eher "ich kann's zusammenklicken, wozu diese Datenblätter lesen, nachher beißen die auch noch". Naja, ich will mich nicht beschweren, diese Leute werden immerhin keine Konkurrenz. Für Hobby ist sowieso alles egal, da kann man meinetwegen auch nen Raspi für einen Blinky hernehmen. In Java natürlich. > Aber CubeMX ist etwas ganz anderes, nach meiner Meinung gibt es > zur Zeit nichts besseres. Ausgenommen das Reference Manual natürlich. ;-)
Marc V. schrieb: > Um das Lesen der ganzen Manuals wirst du sowieso nicht rumkommen, > aber es muss ja nicht gleich am Anfang sein... > Erst mal ein paar Erfolgserlebnisse, danach geht alles leichter. Danke Marc, das sehe ich auch so und ich finde die Idee mit der grafischen Software sowieso besser. Dass man irgendwann auch mal das ganze Datenblatt zum Controller liest, das ist wohl der normale Ablauf, aber ich sehe das auch so, dass man erst Erfolg braucht, um sinnvoll weiter zu machen. Um einen Pin als Ausgang zu benutzen einfach einen Schalter benutzen, statt kryptische Zeilen zu schreiben, die man im Anfang auch erstmal nur abschreibt, ohne sie unbedingt zu verstehen, halte ich für deutlich besser.
Bei einem solchen Thema haette ich eingenlich den Hinweis, zuerst einmal das Errata Manual zu studieren, etwas haeufiger anzutreffen erhofft. Waehrend andere Hinweise aehnlich einer Endlosspule sich immer wieder wiederholten, war dieser wichtige Hinweis nur einmal anzutreffen (Gerd E.) Also: bevor man eine MCU in die engere Wahl nimmt, zuerst einen Blick in die Errata werfen. Erst dann die anderen Entscheidungen und Schritte. Diese Vorgehensweise sich anzugewönen erspart einem sehr viel Aerger und Geld.
Mehmet K. schrieb: > Also: bevor man eine MCU in die engere Wahl nimmt, zuerst einen Blick in > die Errata werfen. Erst dann die anderen Entscheidungen und Schritte. Der TO hat sich schon ein Board besorgt, nix mit engere Wahl. Es geht um die Programmierung.
Raphael G. schrieb: > In meinem Fall habe ich das STM32F4 Discovery Board und habe die > Möglichkeit, die Discovery Firmware einzusetzten in der die Standard > Peripheral Libraries vorhanden sind, welche wohl auch nichtmehr > weiterentwickelt werden. Dann mache es doch so. Da muß auch nichts weiterentwickelt werden, wenn Du Dich weiterentwickelst. Aufbauend auf dem vorhandenen Code kannst Du Routinen ausklammern und eigene Konstrukte hinzufügen, bis Du dann an den Punkt kommst, daß Du direkt auf die Register zugreifen möchtest: damit die Ausführungsgeschwindigkeit auf 'Sollwert' kommt und Du selber entscheiden kannst, wo was wann passiert. Ansonsten ist ja schon Alles gesagt worden.
m.n. schrieb: > Aufbauend auf dem vorhandenen Code kannst Du Routinen ausklammern und > eigene Konstrukte hinzufügen, bis Du dann an den Punkt kommst, daß Du > direkt auf die Register zugreifen möchtest: damit die > Ausführungsgeschwindigkeit auf 'Sollwert' kommt und Du selber > entscheiden kannst, wo was wann passiert. Kommt man nicht irgendwann zwangsläufig dort hin?
F. F. schrieb: > Kommt man nicht irgendwann zwangsläufig dort hin? Das hoffe ich doch, wenn man nicht auf Kindergartenniveau stehen bleiben möchte. Nur sollte der TO nicht endlos nach dem Stein des Weisen suchen, sondern das verwenden, was er hat. Die entscheidenen Sachen müssen im Kopf passieren! Wenn hier von HAL und CUBE die Rede ist: ich träume nicht den Traum der (Schein-)Kompatibilität zwischen diversen Derivaten eines Herstellers. Spätestens wenn ich z.B. wegen Überschneidungen der IO-Pins SPI oder IIC per 'Wackelpins' in Software realisieren muß, ist es vorbei mit stupider Klickerei.
m.n. schrieb: > Wenn hier von HAL und CUBE die Rede ist: ich träume nicht den Traum der > (Schein-)Kompatibilität zwischen diversen Derivaten eines Herstellers. > Spätestens wenn ich z.B. wegen Überschneidungen der IO-Pins SPI oder IIC > per 'Wackelpins' in Software realisieren muß, ist es vorbei mit stupider > Klickerei. Sicher. Nur kreierst du die Initsequenz für diesen Pin mit stupider copy & paste Methode und die anderen machen es wieder mit stupidem Click. Gewaltiger Unterschied, indeed...
:
Bearbeitet durch User
Marc V. schrieb: > Nur kreierst du die Initsequenz für diesen Pin mit stupider copy & > paste Methode Ich brauche keine Initsequenz. Die Eingänge lese ich einfach so aus den GPIO-Registern.
m.n. schrieb: > Ich brauche keine Initsequenz. Die Eingänge lese ich einfach so aus den > GPIO-Registern. Bravo. Ohne Clock ?
m.n. schrieb: > Ich brauche keine Initsequenz. Logo. Aber du solltest aufhören, dich mit diesem Fanboy zu raufen - es bringt nix. Wenn einer mit allergrößtem Nachdruck sich darauf verlegt, nichts anderes zu können und zu wollen als die Benutzung eines Hersteller-Tools, dann ist Hopfen und Malz verloren. Rauf dich lieber mit mir... Marc V. schrieb: > Nur kreierst du die Initsequenz für diesen Pin.. Ah ja, die Initsequenz. Oder die InitStructur, oder oder oder. Was machst du eigentlich (oder würdest theoretisch machen) wenn du mal keinen STM32, sondern einen Chip von Nuvoton oder NXP etc. vor der Nase hast? Dann antwortest du deinem Chef, daß du schließlich ein Ingenieur für STM32 bist und nicht ein Ingenieur für LPC oder NUC120 - gelle? Haben wir's jetzt? W.S.
W.S. schrieb: > Was machst du eigentlich (oder würdest theoretisch machen) wenn du mal > keinen STM32, sondern einen Chip von Nuvoton oder NXP etc. vor der Nase > hast? Dann antwortest du deinem Chef, daß du schließlich ein Ingenieur > für STM32 bist und nicht ein Ingenieur für LPC oder NUC120 - gelle? Einen von Euch Genies zur Hilfe rufen ? Für einen Genie wie dich ist es egal, ob NXP oder ST oder Nuvoton - du hast von denen sowieso nur die Bilder gesehen und nicht einmal A von Ahnung. > Haben wir's jetzt? Ich hab's schon seit ein paar Jahren - ob du jemals weiter als LED blinken mit fertigem Program in BASIC weiterkommst, wage ich zu bezweifeln.
Wow das läuft hier ja gerade wieder komplett aus dem Ruder. Könnt ihr nicht mal beim Thema bleiben? Ich bin ernsthaft nicht interessiert an euren Schw**zvergleichen. Jetzt müssen sich wieder interessierte querbeet die haufen Beiträge durchlesen. Es interessiert dabei niemanden ob ein einzelner alle Register auswendig setzen kann oder nicht. Ich hoffe ihr habt verständnis. Danke an alle, die versuchen, ernsthaft was zum gefragten Thema beizutragen. Es geht hier auch tatsächlich weniger darum, wie man den geeigneten MCU auswählt sondern um die von euch empfohlene Herangehensweise beim Programmieren bzw. welche Libs ihr nutzt, mehr nicht. In diesem Fall ist es eben ein Board von ST, ich nutze es weil ich es eben habe. Es geht nicht um ARM > ATMEL. Ich habe nur einzelne Atmel CHIPs und werde für mein aktuelles Projekt nicht die Energie aufwenden eine eigene Platine zu designen, egal wie einfach und klein sie werden würde. Ich will auch die Programmierung von ARM Controllern lernen, egal ob das nun überdimensioniert für das aktuelle Projekt ist oder nicht.
:
Bearbeitet durch User
Raphael G. schrieb: > Ich bin ernsthaft nicht interessiert an > euren Schw**zvergleichen. > Danke an alle, die versuchen, ernsthaft was zum gefragten Thema > beizutragen. Du hast Meinungen erfragt, und verstehst sie offensichtlich nicht. Auch, wenn die Meinungen kontrovers sind, ernst gemeint sind sie trotzdem. Fang endlich an und warte nicht, daß Mama Dir sagt, was Du zu tun hast.
m.n. schrieb: > Du hast Meinungen erfragt, und verstehst sie offensichtlich nicht. Auch, > wenn die Meinungen kontrovers sind, ernst gemeint sind sie trotzdem. > Fang endlich an und warte nicht, daß Mama Dir sagt, was Du zu tun hast. Interessant woran du dingfest machst, dass ich etwas offensichtlich nicht verstehe oder gar nur dasitze und nichts tue. Du verstehst scheinbar -meine- Absichten nicht, dann ist es dir auch freigestellt nichts zu schreiben. [bearbeitet - reagiere zu empfindlich auf dummes geschwätz]. Ich will des einzelnen seine vorangehensweisen kennen lernen und nicht die Meinung anderer darüber, ob des anderen Vorangehensweise nicht mit seiner eigenen Überzeugung in einklang zu bringen ist.
:
Bearbeitet durch User
Ich habe doch schon nützliche Antworten erhalten. Es geht ja auch garnicht explizit um ein einzelnes Projekt sondern tatsächlich im Allgemein (sofern das überhaupt möglich ist) darum, welche Libraries (SPL, HAL, eigene..) genutzt werden, ob nur die CMSIS genutzt wird, oder ob der geschulte Hobby-/Berufsprogrammierer alles selbst programmiert von Startup über HAL bis zum eigentlichen Programm. Dazu hab ich schon reichlich antworten erhalten und dafür bin ich dankbar. Ich sitze hier nicht nur tatenlos herum, mir haben die Antworten schon sehr viel gebracht.
:
Bearbeitet durch User
Raphael G. schrieb: > Interessant woran du dingfest machst, Deine Reaktion ist ausfallend bezüglich der Wortwahl und anmaßend, da Du die angesprochene Problematik noch garnicht verstehen kannst. Die Textstelle mit dem Idioten hast Du ja wieder entfernt, aber wenn Du anderer Leute Meinung als dummes Geschwätz abtust, dann frage doch nicht danach. Der STM32 wird Dir schon zeigen, wer der Idiot ist ;-)
Raphael G. schrieb: > Es geht ja auch > garnicht explizit um ein einzelnes Projekt sondern tatsächlich im > Allgemein... ... um die Herangehensweisen der Leute. Ja, darum geht es. Manche suchen nach dem allerleichtesten Weg, ohne sich tatsächlich mit den Gegebenheiten abgeben zu wollen. Sie wollen das Pferd, was sie reiten, auch nicht kennen oder gar verstehen. Zitat: "Ich will es gar nicht wissen,.." Und die Folge dieses Nicht-Wissen-Wollens ist eben das Nichtwissen und das tatsächliche Nichtkönnen. Eben der STM32F103-Ingenieur, der sich schon beim STM32F302 als nicht zuständig empfindet und nur die bereitgestellten Tools "seines" Herstellers kennt. Solche Leute sind dann schließlich so hardwarefern, daß sie eben nicht mal mehr die vorhandenen Möglichkeiten ihres Chips wirklich kennen und benutzen können. Meine Art ist das nicht. Und es ist auch nicht die Art von anderen Geräte- und Hardware-Entwicklern. So, Raphael, nun kannst du selbst dir deinen Weg suchen. Denk aber gelegentlich an die diversen Volksmärchen, wo zwischen dem breiten und dem steinigen Weg unterschieden wird. W.S.
Danke für deinen abschließenden Kommentar. Ich habe mich wohl stellenweise offensichtlich falsch ausgedrückt, so ich das dem Zitat entnehmen kann, das tut mir leid. Generell möchte ich mich auch für die unangemesse Art und Weise entschuldigen, mit der ich versucht habe, die Threadbeiträge freizuhalten von jeglicher Diskussion, ich hab mir damit natürlich selbst ins Knie geschossen. Hätte ich kein Interesse und würde nur oberflächlich programmieren wollen, hätte ich mir einen Arduino oder einen RaspberryPI geholt. So geht meine Reise nun weiter, erste Ziele habe ich ja jetzt schon erreichen können (CubeMX -> HAL, jedoch mag ich die HAL jetzt schon nicht mehr, da man letztendlich alles in den docs nochmal nachliest und dann alleine schon die Registerbezeichnungen nichtmehr direkt nachvollziehbar sind. Beispiel SPI Bidirectional mode, Datenrichtung über BIDIOE festgelet, nennt sich in der HAL aber SPI_1LINE_TX / RX. So wurde es hier ja auch vorhergesagt, aber man lernt dadurch auch). In diesem Sinne. Grüße an Alle und schöner Abend.
:
Bearbeitet durch User
W.S. schrieb: > den Gegebenheiten abgeben zu wollen. Sie wollen das Pferd, was sie > reiten, auch nicht kennen oder gar verstehen. > Zitat: "Ich will es gar nicht wissen,.." Wenn wir schon beim Reiten sind: Hör doch endlich auf, darauf rumzureiten. TO hat sich ein Entwicklungsboard besorgt und will damit etwas anfangen - nicht mit NXP oder Nuvoton - sondern mit STM32. Fragt nach Erfahrungen und Meinungen, nicht nach vorhandenem Wissen, Können, Diplom, Gehalt usw. Ist das so schwer zu verstehen ? Niemand, aber auch niemand kann sich alle ARM Modelle merken, geschweige denn jeden einzelnen bit in jedem einzelnem Register kennen, geschweige denn alle ARM Modelle auf dem Markt auswendig bis auf den letzten bit in letztem Register kennen. Und genauso wie du (oder jeder andere) im Manual nachsehen muss und kann, tue ich (und jeder andere) das auch. Aber (im Gegensatz zu dir) lasse ich mir von Cube alle in Frage kommenden Modelle und ev. Konflikte zuerst anzeigen und meistens auch ein Gerüst erzeugen. Das wird dann je nach verwendeter Library noch angepasst (mit Hilfe der entsprechenden Manuals) und als Grundrojekt für dieses Modell abgelegt. Bei Bedarf wird entsprechendes Verzeichnis kopiert und damit wird dann weitergemacht. Selbstverständlich wird nach ein paar Wochen das meiste vergessen, deswegen mache ich mir gar nicht die Mühe, alles zu behalten. Das aber bei ARM jemand immer noch hartnäckig darauf besteht, alle Modelle auswendig zu kennen und die alle aus dem Kopf programmieren kann, grenzt an Debilität.
:
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.