Announcement: there is an English version of this forum on Hallo Leute, Ich bin auf der Suche nach einer neuen MCU famile. Bisher habe ich vorwiegend mit MSP430 gearbeitet aber 25 MHz max. Clock sind für einige Anwendungen einfach nicht genug Leistung. Ich habe mich zwischenzeitlich mal am STM32L4 versucht aber mit dem bin ich nicht wirklich warm geworden (ARM Cortex ist nicht wirklich Einsteigerfreundlich). Was ich bräuchte wäre ein MSP430 mit min. 100 Mhz. Den gibt es aber leider noch nicht. Anforderungen: - >= 100 MHz CPU Takt - Low Power (ähnlich oder besser als MSP430) - Einfach zu programmieren (also bitte kein ARM Cortex) Was wäre eurer Meinung nach eine Alternative? Bin sehr gespannt Danke Gerd
Was war denn am Cortex so schwierig? Ich finde die sind so einfach zu programmieren das es fast schon langweilig ist.
Hi torusle, torusle schrieb: > Was war denn am Cortex so schwierig? Ich finde die sind so einfach zu > programmieren das es fast schon langweilig ist. Ich vermute, weil ich bevorzuge alle meine Bibliotheken selber zu schreiben und alle Register selber zu kontrollieren, fällt mir lediglich der Einstieg sehr schwer. Ich bin halt in mancher Hinsicht ein wenig "old school". D.h. die Basics fehlen. Vieleicht war (wie auch schon in einem anderen Post zum STM32L4 erwähnt) die Wahl des STM32L4 zum Einstieg in die ARM Cortex Welt auch die falsche Wahl. Gruss Gerd
Gerd K. schrieb: > - Einfach zu programmieren (also bitte kein ARM Cortex) Die STM32 sind eher komplex und ohne HAL schwer verdaulich. Schau Dir mal Nordicsemi NRF52xxx oder Silabs EFM32 an. Die sind "stromsparend" und haben IMHO einfacher zu verstehende Peripherials verglichen mit STM32. Cortex-M >100 MHz ist eher auf "Performance" denn "Stromspar" ausgelegt.
Hi Jim M. Jim M. schrieb: > Cortex-M >100 MHz ist eher auf "Performance" denn "Stromspar" ausgelegt. Daher ja der STM32L4. Der L4+ ist recht low power und kann bis zu 120 MHz. Gruss gerd
:
Bearbeitet durch User
Gerd K. schrieb: > Ich vermute, weil ich bevorzuge alle meine Bibliotheken selber zu > schreiben und alle Register selber zu kontrollieren, fällt mir lediglich > der Einstieg sehr schwer. Ich bin halt in mancher Hinsicht ein wenig > "old school". D.h. die Basics fehlen. Ich denke, das ist das Problem. Geht mir ja nicht anders. Wenn ich den HAL Code sehe, dann juckt es mich auch in den Fingern den Kram lieber für meinen Anwendungsfall neu zu schreiben. Ich bin mittlerweile aber vernünftig geworden und nutze einfach die HAL. Falls dann wirklich mal die Performance nicht reicht kann ich immer noch optimieren. Passiert allerdings nie, weil es bislang immer schnell genug war. Ich bin übrigens Fan der LPC17xx MCUs von NXP. Da sind die Peripherie Blöcke gut beschrieben und beherrschbar (wenn man von USB und Ethernet mal absieht).
Gerd K. schrieb: > - >= 100 MHz CPU Takt > - Low Power (ähnlich oder besser als MSP430) beides ist leider nicht leicht miteinander vereinbar. Ich verwende zwei Plattformen: 1) MSP430G (ohne BS) für periphere, hardware-nahe Anwendungen und 2) den Raspberry (mit Linux) für komplexe Anwendung, wo meist auch Power verlangt wird. Reicht die Leistung eines MSP's nicht aus, dann verteile ich die Aufgaben oder Last auf mehrere MSP's.
GEKU schrieb: > Gerd K. schrieb: >> - >= 100 MHz CPU Takt >> - Low Power (ähnlich oder besser als MSP430) > > beides ist leider nicht leicht miteinander vereinbar. Äh doch? Wenn man die Rechenleistung kurz braucht taktet man hoch um danach wieder zu schlafen. @ Gerd K: Wo hats denn beim L4 Einstieg genau gehapert? Jede Peripherie ist im RefMan doch ausführlichst erklärt mit Schrittanleitungen wie diese zu nutzen ist. Danach kommen dann die Register und Bitdefinitionen. Ansonsten immer das gleiche Schema: Takt einschalten für die Periph GPIO Einstellen (wenn diese raustelefonieren will) Periph Einstellen.
Man könnte auch MCU's mit FPGA's kombinieren. Schnell Aufgaben lasse ich FPGA's erledigen, komplexe, wie zum Beispiel IP Kommunikation vom Raspberry. Der Raspberry sorgt dann auch die Updatefähigkeiten des FPGA's aus der Ferne.
GEKU schrieb: > Man könnte auch MCU's mit FPGA's kombinieren. Man könnt jetz auch langsam mal aufhören Murks zu labern ;) FPGA sind jetz wirklich nix für Lowpower. Guck dir die Powerstates der L4 an und sei leise.
Hi Mw E. Mw E. schrieb: > @ Gerd K: > Wo hats denn beim L4 Einstieg genau gehapert? > Jede Peripherie ist im RefMan doch ausführlichst erklärt mit > Schrittanleitungen wie diese zu nutzen ist. > Danach kommen dann die Register und Bitdefinitionen. > > Ansonsten immer das gleiche Schema: > Takt einschalten für die Periph > GPIO Einstellen (wenn diese raustelefonieren will) > Periph Einstellen. Ja, so hatte ich mir das auch gedacht. Dann hatte ich zuerst mit dem CubeMX und Inkompartibilität zur frühen Version des TrueStudios zu kämpfen. Ausserdem konnte ich einfach nicht herausfinden, wie die dieversen HAL Funktionen zu nutzen sind. Möglicherweise habe ich aber auch zu früh aufgegeben. Welches ist eigentlich die beste IDE für den Einstieg? Ich denke, ich sollte es nochmal versuchen. Gruss Gerd
Diese HAL nutzt man ja auch nicht, die ist einfach nur gruselig und aufgeblasen. Aus dem CubeMX kann man sich die CMSIS Header ziehen und schon haste alle Bits aus dem RefMan zur Verfügung. Der CubeMX ist ganz gut um die Pinbelegung zu bauen, denn die Peripherie IOs kommen an mehr als einem Pin raus.
Gerd K. schrieb: > Bisher habe ich vorwiegend mit MSP430 gearbeitet aber 25 MHz max. Clock > sind für einige Anwendungen einfach nicht genug Leistung. Ich habe gemerkt, daß mangelnde Performance oft an ungenügender Programmplanung liegt. Wenn man die Programme nochmal überarbeitet, dreht die CPU nur Däumchen, wo sie vorher am Anschlag lief und Tasks verzögert hatte. Sehr wichtig ist ein sauberes Profiling, d.h. welche Tasks müssen wirklich wie oft ausgeführt werden. Die Compiler sind zwar schon sehr gut, aber denken können sie noch nicht. Daher muß man ihnen auf die Sprünge helfen und z.B. selten benötigte Berechnungen aus Schleifen herausziehen und deren Ergebnisse zwischenspeichern. Ich lasse oft einen Timer mitlaufen, der mir die maximale Zeit eines Mainloop Durchlaufs in einer Variable speichert, die ich auslesen kann. Ich staune oft, wie lächerlich klein dieser Wert ist.
:
Bearbeitet durch User
Man könnte auch MCU's mit FPGA's kombinieren. Schnell Aufgaben lasse ich FPGA's erledigen, komplexe, wie zum Beispiel IP Kommunikation vom Raspberry. Der Raspberry sorgt dann auch die Updatefähigkeiten des FPGA's aus der Ferne. Mw E. schrieb: > Guck dir die Powerstates der L4 an und sei leise. Schaut wirklich gut aus. Aber wie sieht es mit der Lötarbeiten für "Bastler"? Was kosten komplette Board?
FPGAs sind nur für extreme Spezialanwendungen sinnvoll. Meistens ist ein MC dicke ausreichend. Ich hab aber auch schon gesehen, daß Leute Relais mit FPGAs ansteuern.
Peter D. schrieb: > FPGAs sind nur für extreme Spezialanwendungen sinnvoll. Ist schon auf Grund des Stromverbrauchs nicht sinnvoll. Außerdem benötigt es neues Knowhow, z.B. VHDL Da ist der Umstieg auf eine neue Prozessor Familie mit Sicherheit leichter.
Was an den FPGAs nervt, ist der ständige Generationswechsel. Wir haben auch ein Gerät, wo der FPGA nur noch über Broker erhältlich ist. Ob da überhaupt ein FPGA nötig war, bezweifle ich, der macht nur über USB ein paar DAC-Ausgaben und liest ADCs ein. War eine Fremdentwicklung an einer Uni.
GEKU schrieb: > Aber wie sieht es mit der Lötarbeiten für "Bastler"? Eigentlich recht gut. TQFP mit 0,5mm Pinabstand ist noch recht gut zu löten. Eben nach der Standardmethode "Lötwulzt drüber und dann mit Entlötlitze abziehen".
Peter D. schrieb: > Was an den FPGAs nervt, ist der ständige Generationswechsel. Wir > haben auch ein Gerät, wo der FPGA nur noch über Broker erhältlich ist. > Ob da überhaupt ein FPGA nötig war, bezweifle ich, der macht nur über > USB ein paar DAC-Ausgaben und liest ADCs ein. War eine Fremdentwicklung > an einer Uni. Solle Mitarbeiter mit akademischer Arbeitsweise hatten wir auch. Da ging in erster Linie ums Kennenlernen neuer Produkte und Technologien. Die Wirtschaftlichkeit war zweitrangig.
Mw E. schrieb: > TQFP Mich haben nur die Ball Grid Arrays abgeschreckt. Da haben wir für die Qualitäts kontrollieren ein Röngengerät benötigt. TQFP sind kein Problem, die habe ich wohl übersehen.
GEKU schrieb: > TQFP sind kein Problem, die habe ich wohl übersehen Gibt es das Gehäuse auch für *STM32L4+*
GEKU schrieb: > Gibt es das Gehäuse auch für *STM32L4+* Ja, 100 und 144 Pin TQFP. Habe direkt bei STM nachgeschaut.
Gerd K. schrieb: > Ich vermute, weil ich bevorzuge alle meine Bibliotheken selber zu > schreiben und alle Register selber zu kontrollieren, fällt mir lediglich > der Einstieg sehr schwer. Ich bin halt in mancher Hinsicht ein wenig > "old school". D.h. die Basics fehlen. > > Vieleicht war (wie auch schon in einem anderen Post zum STM32L4 erwähnt) > die Wahl des STM32L4 zum Einstieg in die ARM Cortex Welt auch die > falsche Wahl. Wo genau ist dein Problem? Wirklich bei dem ARM Cortex-M Core? oder doch eher bei der ST-Herstellerspezifischen Peripherie? Dir sollte klar sein der der Cortex-M nur den CPU-Kern und einige kleiner "Anbauteile" wie den Interruppt handler und den Systick einheitlich definiert. Bei der ganzen Peripherie drumherum kocht jeder Hersteller sein eigenes Süppchen. Die ist z.B. bei ST völlig anders als bei NXP die wiederum anders ist als bei Atmel usw. Schau dir eventuell mal den MSP432 an: https://en.wikipedia.org/wiki/TI_MSP432
EFM8 haben bessere Peripherie, sind billiger, und noch einfacher zu programmieren. STM8 haben sich inzwischen auch deutlich verbessert.
Ich denke, dass an ARM Cortexe in mancher Hinsicht sogar einfacher anzuwenden sind, als 8bit Controller. Zum Beispiel weil sie 32bit Werte an einem Stück lesen und schreiben können ohne das Interrupts dazwischen funken. Kompliziert wird die Sache erst durch die Periperie drumherum. Bei STM32 fällt z.B. auf, dass die meiste Peripherie 16 bit breit angebunden ist. Versuche mal einen STM32F303. Ich habe hier etwas zusammen geschrieben, womit du Dir einen ersten Eindruck verschaffen kannst, wie man den ohne Cube HAL programmiert. http://stefanfrings.de/stm32/stm32f3.html
Mir gefallen die Microchip/Atmel SAM controller besser als STM32. Ist zwar auch ARM-Cortex, aber die Peripherals sind IMHO viel sauberer.
> aber die Peripherals sind IMHO viel sauberer
Und Erratas werden in Fünfjahresschüben abgearbeitet.
Da bleibt die Banane lange grün.
Gerd K. schrieb: > Anforderungen: > - >= 100 MHz CPU Takt > - Low Power (ähnlich oder besser als MSP430) > - Einfach zu programmieren (also bitte kein ARM Cortex) Mit der Blackfin-Architektur von Analog Devices hatte ich lange Jahre gute Laune. Punkto Leistung pro Stromaufnahme immer noch top, da kommt so mancher ARM nicht mit. Ist halt bei der ARM-Core-Flut und (unbegründbarer) Second-Source-Paranoia bisschen in die Nische gewandert, auch weil 'DSP' drübersteht. Bei allen Stromspar-Komplexitäten die man da ausreizen kann, ist der Chip relativ einfach zu programmieren und die Dokumentation ist top. Die offiziellen Tools allerdings weniger...
Hallo Mw E. Mw E. schrieb: > Diese HAL nutzt man ja auch nicht, die ist einfach nur gruselig und > aufgeblasen. > > Aus dem CubeMX kann man sich die CMSIS Header ziehen und schon haste > alle Bits aus dem RefMan zur Verfügung. > > Der CubeMX ist ganz gut um die Pinbelegung zu bauen, denn die Peripherie > IOs kommen an mehr als einem Pin raus. OK 1. Wie macht man das? 2. Und wie gehts dann weiter? Gruss Gerd
Ich verstehe die Probleme nicht so ganz. Mit dem Arm habe ich doch gar nichts zu tun. Ob da jetzt ein Arm im Hintergrund läuft oder ein Mips oder RiscV... das macht doch der Compiler für mich. Mit der CPU habe ich doch nichts zu tun. Ich habe letztens eine Sensorsteuerung zuerst auf einem Arm-A7 mit Linux geschrieben, und dann auf Arm-M0 portiert. Letztendlich waren fast nur die I2C Zugriffsroutinen anzupassen. Ich hätte auch einen Atmel nehmen können. STM hatte ich auch mal. Da waren die Hardware-Bibliotheken umständlich anzusprechen. Aber das hat nichts mit Arm zu tun. Meine Portierung läuft auf einem NXP-Arm. Die liefern sogar eine ROM-Bibliothek mit, die einem ein C-Interface für I2C/UART/etc Zugriff bereitstellt. Noch nie so etwas einfaches gehabt.
Martin schrieb: > Mir gefallen die Microchip/Atmel SAM controller besser als STM32. Ist > zwar auch ARM-Cortex, aber die Peripherals sind IMHO viel sauberer. Habe ich damals auch gedacht beim Einstieg in die Arm Cortex M Welt. Die Doku macht auf den 1. Blick einen tollen Eindruck, aber das Erwachen folgt. Allerdings versteht es Atmel, wichtige Infos zu verstecken, respektive an Stellen zu erwähnen, auf die man kaum kommt. Deswegen hatte ich bei der Treiberprogrammierung des SAM D10D14 einige Probleme. So musste ich in einigen Fällen im Codejungle namens ASF (=HAL) nach Antworten suchen, grausam! Auch in amerikanischen Foren hörte man in Sachen Atmel Doku oft den Satz: "Documentation sucks". Beim nächsten Projekt bin ich auf STM umgestiegen (STM32L431). Die Treiber habe ich in wenigen Tagen fertiggestellt ohne jegliche Probleme seitens STM. Seitdem nur noch STM! Man bekommt von denen fast zum Selbstkostenpreis die Nucleo Evaluationsboards, die Debugger für das SW Interface erhält man als chinesischen Nachbau für weniger als 5 €, Atmel verlangt um die 50 € für die nackte Platinenversion.
> Mit der Blackfin-Architektur von Analog Devices hatte ich lange Jahre > gute Laune. Selbiges hier mit TMS320C5XXX von TI. Besonders schnelle Exemplare mit 300 MHz Takt seit Jahren erhaeltlich. > Die offiziellen Tools allerdings weniger... Code Composer ist frei verfuegbar. Der einzige saure Apfel sind vielleicht die Preise fuer JTAGs wenn man mit den einfachen FTDI-Adaptern (XDS100) nicht auskommen will.
Vor vielen Jahren bin ich von Atmel-Controllern auf EFM32-Controller umgestiegen, "gleitend" :) Beruflich und auch privat. Habe es nicht bereut und mit den EFM32- und EFM8-Controllern und den günstigen Developmentboards mehr machen können, als es die Atmel-Controller je konnten. Blackbird
Blackbird schrieb: > Vor vielen Jahren bin ich von Atmel-Controllern auf EFM32-Controller > umgestiegen, Glückwunsch, aber auch die basieren auf der Arm Cortex M Familie, die der Gerd L. leider nicht mag! :-(
Uwe M. schrieb: > Blackbird schrieb: >> Vor vielen Jahren bin ich von Atmel-Controllern auf EFM32-Controller >> umgestiegen, > > Glückwunsch, aber auch die basieren auf der Arm Cortex M Familie, die > der Gerd L. leider nicht mag! :-( Na dann muss er eben auf MSP432 umsteigen und in dieser Liga bleiben. Blackbird
PIC32 gibts auch noch. Kein ARM drin, sondern MIPS. Ich bezweifle freilich auch, dass wirklich der Kern von Bedeutung ist Mit dem Drumrum von Microchip (8/16) bin ich allerdings nicht wirklich warm geworden.
:
Bearbeitet durch User
Lothar J. schrieb: > Na dann muss er eben auf MSP432 umsteigen und in dieser Liga bleiben. Das ist ein Cortex M4F. Gerd K. schrieb: > Ich habe mich zwischenzeitlich mal am STM32L4 versucht aber mit dem bin > ich nicht wirklich warm geworden (ARM Cortex ist nicht wirklich > Einsteigerfreundlich). Wo genau hing es denn beim Kern? Beim NVIC? Gerd K. schrieb: > Anforderungen: > - >= 100 MHz CPU Takt > - Low Power (ähnlich oder besser als MSP430) Wie kommen denn diese sehr konträren Anforderungen zu stande? Wieso müssen es gleich 100MHz (bei 32Bit) sein, wenn 25MHz (bei einem 16-Bitter!) nicht mehr ausreichen?
Christopher J. schrieb: > MSP432 hat nichts mehr mit der Architektur des MSP430 zu tun, der sich an die PDP11 angelehnt hat.
Lerne bitte korrekt zu zitieren. GEKU schrieb: > Christopher J. schrieb: >> MSP432 > > hat nichts mehr mit der Architektur des MSP430 zu tun, der sich an die > PDP11 angelehnt hat. Ja, denn: Christopher J. schrieb: > Das ist ein Cortex M4F. Stand im übrigen nur eine Zeile darunter.
Gerd K. schrieb: > Ich vermute, weil ich bevorzuge alle meine Bibliotheken selber zu > schreiben und alle Register selber zu kontrollieren, Ach so, du bist im letzten Jahrhundert stecken geblieben. Sag das doch gleich. Heutzutage benutzt man STM32 mit CubeMX, dad schreiben sich die Programme fadt von selbst.
I. C. Reader schrieb: > da schreiben sich die Programme fast von selbst. Aber nur solange man dem a) Marketing Blabla glaubt, b) den Zeitwaufwand für das das Lernen von doppelt so viel Doku nicht mit zählt (HAL Doku erstzt nicht das Referenzhandbuch), c) wenn man den Zeitaufwand für Reverse-Enginnering der HAL (mangels ordentlicher Doku) nicht mit zählt, und d) noch nicht mehrfach auf Bugs gestoßen ist, die einem ganze Wochenenden gekostet haben (wenn schon triviale Hello-World Projekte versagen, denkt man sich seinen Teil). Ich glaube ja gerne, dass erfahrende STM32 Spezialisten damit gut klar kommen. Für mich gibt es aber noch ein Leben jenseits von ST. Ich bin eher einer der Sorte, die mit Referenzhandbüchern und Datenblättern arbeiten. Meine Methode passt eher dazu, dass ich ST nicht unbedingt "heiraten" möchte. Auch andere Firmen haben tolle Mikrocontroller hervorgebracht.
Stefanus F. schrieb: > b) den Zeitwaufwand für das das Lernen von doppelt so viel Doku nicht > mit zählt (HAL Doku erstzt nicht das Referenzhandbuch), Stimmt, das Referenzhandbuch braucht man trotzdm, aber von der doppelten Menge Doku kann nicht die Rede sein. Stefanus F. schrieb: > c) wenn man den Zeitaufwand für Reverse-Enginnering der HAL (mangels > ordentlicher Doku) nicht mit zählt Ordentliche Doku gibts zu Hauf, aber du hast die offenbar nicht gefunden. Jedes Framework benötigt eine Einarbeitung, aber die Zeit ist gut investiert, da man die später vielfach einspart, und die Namensgebung ist bei HAL weitgehend so konsistent, daß man bereits nach kurzer Zeit ganz intuitiv die richtigen Funktionen findet. Stefanus F. schrieb: > noch nicht mehrfach auf Bugs gestoßen ist, die einem ganze > Wochenenden gekostet haben Und du glaubst wirklich selber weniger Bugs zu produzieren? - ich nicht! Sieht man u.A. daran, daß du dich immer noch mit so elementaren Dingen wie Takt-Konfiguration herum ärgerst, die CubeMX weitgehend fehlerfrei auf Knopfdruck generiert, und während die CubeMX-User schon längst an ihrer eigentlichen Aufgabe arbeiten. Wie lange hast du daran herumgefummelt? Beitrag "STM32 läuft mit Debugger schneller als er soll" Kratzt das an deiner Programmierer-Ehre, daß eine Software sowas besser und schneller kann als du oder bist du nur zu faul oder unfähig Neues zu lernen?
Man sollte eines nicht vergessen: Wenn man einmal alle wichtigen Funktionalitäten grob beispielhaft durchgespielt hat (kostet ev. 1 Woche) dann kann man alle seine Projekte darauf basieren lassen. Ich fand es nicht sehr schwer. Es gibt viele Beispiele im Netz. Ich nutzte immer die peripheral Lib zum initialisieren und wenn manche Funktionalitäten zu langsam waren, habe ich mir die betreffenden Register-Operationen einfach aus der Lib kopiert und etwas abgespeckt. Geht super!
Harry L. schrieb: > Sieht man u.A. daran, daß du dich immer noch mit so elementaren Dingen > wie Takt-Konfiguration herum ärgerst, die CubeMX weitgehend fehlerfrei > auf Knopfdruck generiert, und während die CubeMX-User schon längst an > ihrer eigentlichen Aufgabe arbeiten. > > Wie lange hast du daran herumgefummelt? > Beitrag "STM32 läuft mit Debugger schneller als er soll" Man soll ja nicht auf Boshaftigkeit was man adäquat durch Dummheit erklären kann... Wenn man den "läuft mit Debugger schneller" gelesen und verstanden hätte würde man nicht so einen "Angriff" reiten. Das Problem hatte rein gar nichts mit CubeMX ja oder nein zu tun und tritt bei einer CubeMX generierten Clock-Initialisierung genauso auf.
Hach der HAL Fanboy Harry ist wieder da... Harry L. schrieb: > Sieht man u.A. daran, daß du dich immer noch mit so elementaren Dingen > wie Takt-Konfiguration herum ärgerst, die CubeMX weitgehend fehlerfrei > auf Knopfdruck generiert, und während die CubeMX-User schon längst an > ihrer eigentlichen Aufgabe arbeiten. > > Wie lange hast du daran herumgefummelt? > Beitrag "STM32 läuft mit Debugger schneller als er soll" > > Kratzt das an deiner Programmierer-Ehre, daß eine Software sowas besser > und schneller kann als du oder bist du nur zu faul oder unfähig Neues zu > lernen? Wenn du den Fred ordentlich gelesen hättest, dann hätteste erkannt, dass da ein Debugscript zwischengefunkt hat. Wenn du den Fred ordentlich gelesen hättest, dann hätteste erkannt, dass ich da ein Gegenbeispiel gepostet habe mit der CubeMX macht das super mit dem Takt. Nur weil du nicht lesen kannst musste jetz nich auf Stefanus rumhacken.
rµ schrieb: > Das Problem > hatte rein gar nichts mit CubeMX ja oder nein zu tun Klar hat das nix damit zu tun, und ads hab ich auch nicht behauptet, weil Stefan ja grundsätzlich alles besser kann und besser weis als ST... Aber trotzdem wird er nicht müde, HAL in Grund und Boden zu schreiben, obwohl er davon -nachweislich- überhaupt keine Ahnung hat.... Mw E. schrieb: > Wenn du den Fred ordentlich gelesen hättest, dann hätteste erkannt, dass > ich da ein Gegenbeispiel gepostet habe mit der CubeMX macht das super > mit dem Takt. Ich kann schon richtig lesen, aber du hast scheinbar Verständnis-Probleme mit meinem Beitrag....s.o. Was seid ihr? Stefans persönliche Fanboys?
:
Bearbeitet durch User
... außer CubeMX gibts ja auch noch libopencm3. Irgendwie erschließt sich mir aus meiner Sicht der Dinge damit Funktionalitäten eines STM32 bei der Durchsicht der Sourcen schneller als mit HAL. Damit ist auch mein bevorzugtes Gespann, Editor + Makefile, schneller am funktionieren als mit HAL (was aber wohl zugegebenerweise auch daran liegt, dass ich mich mit libopencm3 deutlich länger beschäftigt habe als mit HAL). Grundsätzlich denke ich, wird es einem bei der Einarbeitung in einen Abstraktionslayer, genügend Zeit und graue Haare kosten, bis das flüssig geht. libopencm3 kommt mir in gewisser Weise entgegen, weil meine persönliche Arbeitsweise lieber mit Zeigern auf Register arbeitet, die ich dann bei Bedarf wie im Referenzmanual einfach beschreiben kann und keine struct verwenden muss. Wer lieber mit den structs arbeitet sollte dann die HAL nehmen. Meine Glaskugel jedoch sagt mir, dass der TO lieber mit den Zeigern auf Register arbeitet (weil er seine Bibliotheken selbst schreiben mag). Prinzipiell wäre für den TO eben doch noch einmal ein Blick auf ARM nicht schlecht, hier aber vielleicht dann doch auf NXP der - aus meiner Sicht der Dinge - logischer aufgebauten Peripherie... und das ganze mit libopencm3 ?!?
Harry L. schrieb: > Aber trotzdem wird er nicht müde, HAL in Grund und Boden zu schreiben, > obwohl er davon -nachweislich- überhaupt keine Ahnung hat.... Man braucht nicht viel Ahnung haben um die HAL zu hassen. Wer mal mit der StmPerfLib angefangen hat ist sicherlich geheilt. Will man ein altes Projekt auf einen neueren Chip portieren bei dem es nur noch HAL gibt, schreibt man es neu. Und übermorgen gibt es dann die natürlich viel bessere Hallali-Lib bei der man wieder von vorn anfängt. Aber so wie man immer mal wieder zum Arzt gehen sollte weil der ja auch leben muss, sollte man die STM Ergüsse von Libs auch verwenden damit die Praktikanten nicht arbeitslos werden... Wenn Harry L. die HAL wie Arduino benutzt hat er vielleicht recht. Wie man aber die Möglichkeiten z.B. eines HiRes-Timers aus dem STM32F334 auf die HAL in leicht verständlicher Form abbilden will erschließt sich mir nicht. Ohne das RefMan dazu fast auswendig zu kennen geht da nichts. Auch nicht mit der HAL. Die GPIO Funktionen sind ja z.T. noch selbsterklärend, die der Spezialtimer nicht. Und wenn man mit dem Debugger in die Register schaut muss man sie auch verstanden haben. Da investiere ich die Zeit lieber in das Verständniss der RefManuals als in diesen Brocken von HAL.
Harry L. schrieb: > Und du glaubst wirklich selber weniger Bugs zu produzieren? - ich nicht! Sicher nicht, aber ich habe meinen selbst erstellten Code besser im Griff, als fremden Code. > Sieht man u.A. daran, daß du dich immer noch mit so elementaren Dingen > wie Takt-Konfiguration herum ärgerst, die CubeMX weitgehend fehlerfrei > auf Knopfdruck generiert Eben nicht. Gleich mein erstes Projekt stürzte bei der Takt-Konfiguration ab, weil der Cube Code ein Bit falsch setzte. Der erste Eindruck zählt. Bei mir war der nicht so gut. Und der zweite auch nicht. Und der dritte wieder nicht. Tatsächlich benutze ich Cube Mx auch ab und zu als Inspiration, aber ich verlasse mich nicht darauf. > Aber trotzdem wird er nicht müde, HAL in Grund und Boden zu schreiben, > obwohl er davon -nachweislich- überhaupt keine Ahnung hat.... Korrekt, ich habe von der HAL keine Ahnung. Jedenfalls nicht genug, um anderen zu erklären, wie man sie richtig benutzt. Ich habe allerdings meine drei schlechten Erfahrungen genacht und ich habe auch in völlig anderen Umfeldern mit Frameworks Erfahrungen gemacht. Diese Erfahrung sagt mir: Benutze Frameworks mit Bedacht und übertreibe es damit nicht. Tut mir Leid, wenn meine Kommentare nach "Grund und Boden" klingen, so schlimm war es nicht gemeint.
> Wer mal mit > der StmPerfLib angefangen hat ist sicherlich geheilt. findest du die Lib schlecht?
Lothar schrieb: > EFM8 haben bessere Peripherie, sind billiger, und noch einfacher zu > programmieren. STM8 haben sich inzwischen auch deutlich verbessert. Ich weiß nicht, wieviel der EFM8 besser als der Vorgänger C8051 ist (auch wenn ich schätze, dass es da gar nicht nicht so viel Unterschied gibt), aber: Nach meiner Erfahrung ist STM8 in Bezug auf Codegröße und Geschwindigkeit deutlich besser als MCS-51. Einfacher zu programmieren sind sie auch. Die Architektur des STM8 passt insbesondere viel besser zu C als die meisten anderen Architekturen, die bei µC üblich sind. Vor einiger Zeit hatte ich Vergleiche mit SDCC 3.7.0 und ein paar Benchmarks gemacht. stdcbench 0.4 c90base Score. Jeweils mit Optimierung auf Geschwindigkeit kompiliert (damit liegt die Codegröße bei MCS-51 etwa beim doppelten von STM8): C8051F120@98Mhz: 95 STM8AF5288@16Mhz: 109 STM8S208MB@24Mhz: 147 zum Vergleich: Weitere µC mit SDCC 3.7.0 bzw. GCC 6.3.1: CY7C68013A@48Mhz: 12 STM32L073RZ@32Mhz: 717 STM32F051R8@48Mhz: 1141 STM32F103RB@36Mhz: 1158 STM32F302R8@64Mhz: 1693 Bei stdcbench 0.4 erhält man für den STM8 mit Cosmic und Raisonance ähnliche Scores wie mit SDCC 3.7.0. Aber IAR kann mehr (allerdings auf Kosten deutlich höhere Codegröße). Hier ein Ergebnis mit 3.10.1.102: STM8AF5288@16Mhz: 189 stdcbench erfordert Reentranz, was beim MCS-51 etwas umständlich ist. Aber selbst wenn man einen Benchmark nimmt, der ohne auskommt, wie Dhrystone 2.1, ist die Codegröße bei MCS-51 ca 30% höher als beim STM8, und der Score / Mhz beim STM8 etwa 10 mal so hoch wie beim C8051. Eigentlich sollte ich die Experimente wohl nochmal mit aktuelleren Compilern, mit dem aktuellen stdcbench 0.6, und unter Einbeziehung von weiteren Architekturen wiederholen, und dann die Ergebnisse auf eine Website stellen.
Philipp Klaus K. schrieb: > Die Architektur des STM8 passt insbesondere viel besser > zu C als die meisten anderen Architekturen, die bei µC üblich sind. Im Ernst jetzt? Das Ding hat eine Akkumulator-Architektur.
Wieder soviel Mist von der Fan-Antifraktion. Natürlich kann man problemlos mit CubeX und HAL den STM32 befeuern. Da hat man schnell was am Laufen und kann sich auf die echte Problemstellung konzentrieren. Wer anschließend vor Langeweile umkommt, kann das Ganze scheibchenweise von Hand nachbauen und sich seine eigene Makro-HAL gestalten. Der MSP432 ist zwar auch ein ARM, aber die Peripherie ist gleich dem MSP430. Genau für Umsteiger wie dich wurde der entwickelt. Lass dir von Stefan und seinem Boy nicht so einen Scheiss erzählen. Das sind halt keine Teamplayer. ?
Rudolph R. schrieb: > Philipp Klaus K. schrieb: >> Die Architektur des STM8 passt insbesondere viel besser >> zu C als die meisten anderen Architekturen, die bei µC üblich sind. > > Im Ernst jetzt? Das Ding hat eine Akkumulator-Architektur. Ja. Der STM8 hat einen effizienten Stackpointer-relativen Adressierungsmodus. Er hat einen Softwarestack. Einen einheitlichen Adressraum. Multiplizierer, Dividierer. Das macht ihn zu einer besseren Zielarchitektur für C-Compiler als z.B. MCS-51, PIC, HC08, S08, Padauk, Z80-Derivate.
:
Bearbeitet durch User
Stefanus F. schrieb: > I. C. Reader schrieb: >> da schreiben sich die Programme fast von selbst. > > Aber nur solange man dem > a) Marketing Blabla glaubt, > b) den Zeitwaufwand für das das Lernen von doppelt so viel Doku nicht > mit zählt (HAL Doku erstzt nicht das Referenzhandbuch), > c) wenn man den Zeitaufwand für Reverse-Enginnering der HAL (mangels > ordentlicher Doku) nicht mit zählt, und > d) noch nicht mehrfach auf Bugs gestoßen ist, die einem ganze > Wochenenden gekostet haben (wenn schon triviale Hello-World Projekte > versagen, denkt man sich seinen Teil). > > Ich glaube ja gerne, dass erfahrende STM32 Spezialisten damit gut klar > kommen. Für mich gibt es aber noch ein Leben jenseits von ST. > > Ich bin eher einer der Sorte, die mit Referenzhandbüchern und > Datenblättern arbeiten. Meine Methode passt eher dazu, dass ich ST nicht > unbedingt "heiraten" möchte. Auch andere Firmen haben tolle > Mikrocontroller hervorgebracht. Genau so sehe ich das auch, ich bin auch der Überzeugung das es keinen "besten Controller" gibt mit dem man Alles ultimativ erschlagen bekommt. Seit C-Compiler für die meisten Mikros problemlos zu haben sind gibts doch kaum noch relevante Unterschiede die einen Einsatz ermöglichen/verunmöglichen, man kann relativ problemlos nach benötigter Leistung skalieren, auch über Typen hinweg. Die größten Unterschiede macht dabei IMHO die verfügbare Peripherie oder welches RTOS (falls benötigt) benutzt werden kann. Natürlich sollte man keinen 8051 für Bildverarbeitung einsetzen wollen.. Früher wurde hier Atmel gehyped, jetzt ist es scheinbar STM..aber auch andere Mütter haben schöne Töchter. Gruß, Holm
@Holm Gut erkannt. Die jetzt die HAL verfluchen, haben vor ein paar Wochen noch den ARM verflucht. Es ist, wie es ist: Was der Bauer nicht kennt, ... @Philipp Wieviel GP-Register hat der STM8?
Rudolph R. schrieb: > Im Ernst jetzt? Das Ding hat eine Akkumulator-Architektur. Das verhindert lediglich eine schmerzarme Implementierung in Compilern-Baukästen wie GCC, die auf Architekturen mit ausreichend grossem Registersatz festgelegt sind. Es geht zwar, aber dann landet man bei Umgehungslösungen wie Pseudo-Registern im RAM. An sich ist Codegenerierung für Akkumulator-Architekturen eher einfacher als für Register-Architekturen, weil man sich ein paar Gedanken weniger machen muss. Es wird vergleichsweise langsamer, aber Tempo ist nicht unbedingt das Ziel solcher Architekturen, sondern Hardware-Aufwand. Interessanter sind die Adressierungsmöglichkeiten. C funktioniert besser, wenn die CPU Adressierungsarten relativ zu mindestens 1-2 freien und zu Rechnungen fähigen Adressregistern mit voller Adressraumbreite sowie zu einem Frame- oder Stackpointer verfügt. STM8S hat das, ebenso 68HC11/12. Die 8-Bit PICs vor der zweiten Version der PIC18 Architektur sowie 8051 können nicht damit dienen, was die Umsetzung komplizierter gestaltet. Hinderlich ist auch eine partielle (STM8S, M16C) oder vollständige (AVR, meistens) Adressraumtrennung. Allerdings mittlerweile eher für den Programmierer, der sich damit rumärgern muss, als für einen Compiler. MSP ist gut, schrieb: > Wieviel GP-Register hat der STM8? Jenseits kleiner praktisch nur statisch adressierender Programme sind Adressregister interessanter als Datenregister. STM8S hat davon 2, plus Stackpointer.
:
Bearbeitet durch User
Lothar schrieb: > Wie steht es eigentlich mit der SDCC Einbindung in Eclipse? Es gibt ein Eclipse-Plugin für SDCC, das wohl manche mit Erfolg verwenden (sogar mit Einbindung von on-Target-debugging für STM8 via gdb und OpenOCD); andere haben Probleme damit. Da müsste wohl jemand, der sich mit Eclipse und Java ein bischen auskennt drübersehen, und ein paar kleinere Aktualisierungen vornehmen. Zur Zeit hat wohl Code::Blocks die beste SDCC-Unterstützung, auch wenn es auch dort noch Verbesserungspotential gibt. Philipp
MSP ist gut, schrieb: > @Holm > Gut erkannt. Die jetzt die HAL verfluchen, haben vor ein paar Wochen > noch den ARM verflucht. Es ist, wie es ist: Was der Bauer nicht kennt, > ... > > @Philipp > Wieviel GP-Register hat der STM8? Es gibt den Akkumulator a und 2 Adressregister x und y (letztere lassen sich in vielen Fällen als 16-Bit-GP-Register nutzen, der Zugriff auf Y ist aber oft ineffizienter als auf X). Aber durch den effizienten Zugriff auf Variablen auf dem Stack ist die geringe Anzahl an Registern kein Problem. Philipp
Ich verstehe gar nicht warum hier STM8 in den Ring geworfen wird. Damit hat er ja gegenüber dem MSP430 gar nichts gewonnen. Er fragte ja nach deutlich mehr Leistung. Der STM8 kann ihm da nicht helfen. Mehr Leistung gibt es bei Cortex-ARM 4 und PIC32. Es gibt noch mehr 32bit Familien aber die sind bei weitem nicht so verbreitet.
@Philipp Das sehe ich anders. Wie nutzt der C Compiler den STM8? Kann und will der Compiler auf GP-Register verzichten? @Helmut Genau, daher der Hinweis auf MSP432.
Helmut S. schrieb: > Ich verstehe gar nicht warum hier STM8 in den Ring geworfen wird Weil die Diskussion sich lange vom ursprünglichen Thema entfernt hat. Und das ist auch gut so. Die Alternative wäre der Tod des Threads. Denn: Helmut S. schrieb: > Er fragte ja nach > deutlich mehr Leistung. Der STM8 kann ihm da nicht helfen. Auch sonst kann ihm da keiner helfen. Zumindest so lange nicht, wie er nicht bereit ist, über den Tellerrand hinaus zu sehen. Seine "Argumente" gegen Cortex-M deuten jedenfalls ganz stark in diese Richtung.
ich würde hier beim L4 oder so bleiben. Das bisschen HAL_ erklärt sich von allein ... irgendwann Zumindest findet man genug Beispiele zu irgendwelchen Themen. Ja ganz bugfrei ist das nicht. aber wenn ein Bug auftritt wurde das auch SO noch nie verwendet. Frage ist bist du der fehler oder die Lib ^^ Aber im grunde ist das alles recht einfach nutzbar. Cube haut was nutzbares raus und das kann man wenn man bock hat und seine applikation läuft auch gern noch in registern umfrickeln Wenn ich bei jedem Projekt erst anfangen würde die register zu zerlegen... Wann ist die Anwendung fertig? wenn es nur ein kleines progrämmchen wäre ... ok vieleicht. aber wenn ich ein M4F oder M7 nutze laufen da auch zig verschiedene applikationen.
Philipp Klaus K. schrieb: > Nach meiner Erfahrung ist STM8 in Bezug auf Codegröße und > Geschwindigkeit deutlich besser als MCS-51. Einfacher zu programmieren > sind sie auch. Die Architektur des STM8 passt insbesondere viel besser > zu C als die meisten anderen Architekturen, die bei µC üblich sind. Ich fand den 8051 schon sehr codeeffizient und gut für Steuerungen optimiert. Viele Befehle sind nur ein Byte lang. Er hat 8 Register, wovon 2 als Datenpointer benutzt werden können. Für Interrupts kann man die Registerbank umschalten. Die Bitbefehle sind auch sehr elegant, man kann z.B. das Carryflag in einen Pin laden und umgekehrt (für serielle Protokolle). Man kann bis zu 128 einzelne Bit-Variablen im RAM anlegen, d.h. auch den RAM sehr effizient ausnutzen. Der Keil C51 war auch sehr gut optimiert. Ich hab z.B. auf dem AT89C2051 (2kB Flash) auch float verwendet. Man darf nur nicht den Fehler machen, das Large Model auszuwählen. Dann landen alle Variablen default im externen RAM-Bereich, d.h. alles muß durch den Flaschenhals DPTR gequetscht werden. Als ich dann mal den AVR-GCC probierte, paßten alte AT89C2051 Projekte nicht mehr in den AT90S2313. Der kann nämlich nichts mehr direkt im RAM machen, sondern muß alles erstmal in Register laden. Und auch die Bitbefehle sind deutlich eingeschränkt. Atmel hat das leider erst sehr spät erkannt und dann die 8-Pinner mit 8kB, die 28-Pinner mit 32kB und die 40-Pinner mit 128kB Flash ausgestattet.
Hallo Leute, Erstmal ganz herzlichen Dank an alle für eure Anregungen. Ich werde mir den Hinweis von "I. C. Reader", dass ich Zitat: "im letzten Jahrhundert stecken geblieben" bin, sehr zu Herzen nehmen und mich intensiver mit den diversen ARM Cortex basierenden MCUs beschäftigen. Herzlichen Dank auch an "Stefanus F.". Der Link zu deiner Seite hat mich deutlich weiter gebracht. Ich denke auch, dass früher oder später der Zug in Richtung HAL gehen wird aber ich will zuerst einmal (gem. Stefanus F. Anleitungen) den Einstieg in die Materie ohne HAL versuchen. Übrigens, meine Forderung nach "low power" in Kombination mit 100 MHz begründet sich in der Idee, die MCU in einem kleinen Roboter mit einfacher VGA Kamera zu nutzen. Da Energie immer ein Problem bei Robotern ist -> low power und um was sinnvolles mit der Kamera zu machen braucht man schon ein wenig Rechenpower -> 100 MHz. Ich hoffe, ich darf mich wieder melden, wenn ich auf Probleme stosse? Gruss Gerd
:
Bearbeitet durch User
Für erste Experimente mit STM32L4 kannst du auch den Onlinecompiler auf www.mbed.com nutzen. Hier hast du dann ein komplett lauffähiges Framework. Ein angelegtes Projekt kannst du bspw. in ein Makefileprojekt (mit arm-none-eabi-g++) exportieren und offline weiter bearbeiten. Allerdings: mbed frisst schon gehörig Hardwareresourcen.
Helmut S. schrieb: > Ich verstehe gar nicht warum hier STM8 in den Ring geworfen wird. Damit > hat er ja gegenüber dem MSP430 gar nichts gewonnen. Er fragte ja nach > deutlich mehr Leistung. Der STM8 kann ihm da nicht helfen. Mehr Leistung > gibt es bei Cortex-ARM 4 und PIC32. Es gibt noch mehr 32bit Familien > aber die sind bei weitem nicht so verbreitet. Der STM8 mag nicht reichen (im Ursprungsbeitrag ist ja eine Vervierfachung der Rechenleistung gegenüber dem MSP430 gewünscht). Der STM8 dürfte zwar pro Takt deutlich mehr rechnen (nahezu alle wichtigen Befehle in einem oder zwei Takten), aber es gibt ihn nur bis 24 Mhz Takt. Was vermutlich in erster Linie daran liegt, dass ST dem STM32 keine Konkurrenz machen will. Aber er wurde halt zusammen mit MCS-51 erwähnt, und die Dikussion entfernte sich seither etwas vom ursprünglichen Thema. Wenn man keinen ARM will, wäre RISC-V eine naheliegende Alternative, wenn es auf Rechenleistung ankommt.
:
Bearbeitet durch User
MSP ist gut, schrieb: > @Philipp > Das sehe ich anders. Wie nutzt der C Compiler den STM8? Kann und will > der Compiler auf GP-Register verzichten? > > @Helmut > Genau, daher der Hinweis auf MSP432. Das hängt vom Compiler ab. Die meisten Compiler verwenden ein paar Speicheraddressen als Pseudo-GP-Register. SDCC macht das nicht. Er kommt mit dem 8-Bit Akkumulator a, und den beiden 16-Bit-Registern x und y aus; ansonsten landen lokale Variablen (auch vom Compiler eingeführte temporäre) auf dem Stack; meist generiert SDCC besseren Code als die anderen Compiler (ein etwas älterer Vergleich, auch im Hinblick auf Codegröße und Performanz findet sich auf http://www.colecovision.eu/stm8/compilers.shtml). Philipp
Hallo Mw E. Gerd K. schrieb: > Hallo Mw E. > > Mw E. schrieb: >> Diese HAL nutzt man ja auch nicht, die ist einfach nur gruselig und >> aufgeblasen. >> >> Aus dem CubeMX kann man sich die CMSIS Header ziehen und schon haste >> alle Bits aus dem RefMan zur Verfügung. >> >> Der CubeMX ist ganz gut um die Pinbelegung zu bauen, denn die Peripherie >> IOs kommen an mehr als einem Pin raus. > > OK > 1. Wie macht man das (CMSIS Header ziehen)? > 2. Und wie gehts dann weiter? Darf ich die beiden o.g. Fragen nochmal an dich richten? Gruss Gerd
:
Bearbeitet durch User
Gerd K. schrieb: >> OK >> 1. Wie macht man das (CMSIS Header ziehen)? >> 2. Und wie gehts dann weiter? > > Darf ich die beiden o.g. Fragen nochmal an dich richten? Du kannst keine Header Dateien einbinden? Dann ist die MCU Familie wohl nicht dein größtes Problem. Die Header sind in der StdPeriphLib und HAL lib enthalten und können dort einfach rauskopiert (vulgo "ziehen") werden. Wie es dann weiter geht? Man hat alle Register und Bits und kann diese nach Datenblatt setzen und lesen und sein Programm schreiben. Ohne StdPeriphLib und ohne HAL. Manche Fragen verblüffen mich schon ein wenig. Und das nach so vielen Jahren bei µC.net.
:
Bearbeitet durch User
möchte nur mal Renesas ins Spiel bringen, die bringen vielseitige Chips, gute Tools und super saubere Doku!
Cyblord -. schrieb: [..] > Manche Fragen verblüffen mich schon ein wenig. Und das nach so vielen > Jahren bei µC.net. ..mich nicht mehr. Seit Werkzeugen wie AVR-Studio oder auch Arduinos sind die Leute "rundum sorglos Pakete" gewöhnt und die eigentlichen Zusammenhänge werde nicht mehr verstanden. Da wird ein serieller Port angeclickt und die IDE hat sich drum zu kümmern das die entsprechenden Header eingebunden werden...doch nicht etwa der Programmierer.... Deswegen ist Kommandozeile ja auch "pö!". Gruß, Holm
Gerd K. schrieb: >> 1. Wie macht man das (CMSIS Header ziehen)? Du mußt dir bei ST die STM32Cube Firmware für deinen µC suchen. Einstiegsseite hier: https://www.st.com/en/embedded-software/stm32cube-mcu-mpu-packages.html Für die STM32F4xxx liegt der Krempel z.B. hier: https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-mcu-mpu-packages/stm32cubef4.html Dann packst du das Dingens aus. Das Package für die STM32F0 bei mir hat dann folgende Struktur: .../STM32Cube/Repository/STM32Cube_FW_F0_V1.4.0/Drivers/CMSIS/Device/ST/ STM32F0xx/Include Da liegen die Headerfiles, die du suchst. >> 2. Und wie gehts dann weiter? Du suchst dir ein Tutorial im Web, das deinen µC unter Verwendung der CMSIS Header (sprich: ohne HAL, ohne SPL) programmiert. Da siehst du dann, welches Headerfile du einbinden mußt, welches DEFINE du brauchst (um den µC festzulegen) und was du außerdem brauchst (Startup-Code, Linkerskript). Ich finde wegen seines Minimalismus das Beispiel von hier: http://eleceng.dit.ie/frank/arm/BareMetalSTM32F0Discovery/blinky.html sehr instruktiv. Das Zusammenspiel von Linkerskript und Startupcode sieht man besonders gut in dieser Variante: http://eleceng.dit.ie/frank/arm/BareMetalSTM32F0Discovery/cinit.html weil hier auch der Startupcode in C geschrieben ist. Durch Linkerskripte und Startupcode muß man sich halt einmal durcharbeiten. Ist aber alles recht geradlinig. Danach kopiert man den Krempel nur noch. Oder man verwendet ein Framework wie die schon angesprochene libopencm3. Im Prinzip zielt libopencm3 auf den gleichen Einsatzzweck wie HAL & Co. Ist aber herstellerunabhängig und kennt auch andere Cortex-M (nicht von ST).
Hi Cyblord, Cyblord -. schrieb: > Gerd K. schrieb: >>> OK >>> 1. Wie macht man das (CMSIS Header ziehen)? >>> 2. Und wie gehts dann weiter? >> >> Darf ich die beiden o.g. Fragen nochmal an dich richten? > > Du kannst keine Header Dateien einbinden? Dann ist die MCU Familie wohl > nicht dein größtes Problem. > Die Header sind in der StdPeriphLib und HAL lib enthalten und können > dort einfach rauskopiert (vulgo "ziehen") werden. Das hier ist alles ein gutes Beispiel dafür, wie wichtig der richtige Einstieg in so eine Sache ist. In der Zwischenzeit habe ich selbst herausgefunden, was das eigentliche Problem war. Da ich offensichtlich über die falsche Seite auf die ST Seiten gelangt bin, bin ich fälchlicherweise davon ausgegangen, dass STM32CubeMX das Softwarepaket ist, dass ich brauche. Jetzt weis ich aber, dass STM32CubeL4 das Softwarepaket incl. all der schönen Beispiele ist und STM32CubeMX nur das Konfigurationstool darstellt. Ich war also immer auf der Suche nach den vielen tollen Beispielen. > Wie es dann weiter geht? Man hat alle Register und Bits und kann diese > nach Datenblatt setzen und lesen und sein Programm schreiben. Ohne > StdPeriphLib und ohne HAL. Hier ist das Problem wohl eher, dass mir das "wording" der STM32-Welt noch nicht geläufig ist. Aber, dass werde ich schon noch lernen. > Manche Fragen verblüffen mich schon ein wenig. Und das nach so vielen > Jahren bei µC.net. Wieso? Wie schon oben erwähnt, sind es häufig die kleinen Dinge, die dich vom Erfolg abhalten. Und für genau solche Fragen ist das Forum doch da, oder? Gruss Gerd
Hi Axel S. Axel S. schrieb: > Gerd K. schrieb: >>> 1. Wie macht man das (CMSIS Header ziehen)? > > Du mußt dir bei ST die STM32Cube Firmware für deinen µC suchen. > Einstiegsseite hier: > > https://www.st.com/en/embedded-software/stm32cube-mcu-mpu-packages.html > > Für die STM32F4xxx liegt der Krempel z.B. hier: > > https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-mcu-mpu-packages/stm32cubef4.html > > Dann packst du das Dingens aus. Das Package für die STM32F0 bei mir hat > dann folgende Struktur: Danke dir, jetzt bin ich endlich auf der richtigen Fährte. Siehe vorheriger Post. Hab's zeitgleich mit deinem Post auch herausgefunden. Gruss Gerd
:
Bearbeitet durch User
@ Cyblord & Holm Ich bin dabei etwas anderer Meinung. Wenn eine moderne IDE alles bietet und man sich nur noch um sein Programm kümmern muss, dann ist das doch prima. Ansonsten müßte sich jeder Autofahrer mit allen Details vom Motor, Getriebe, Elektronik usw. auskennen bevor er überhaupt fahren darf. Warum darf eine IDE diese Vorarbeit nicht abnehmen? Ich denke auch das fette µC nur noch auf modernen Wege überhaupt programmiert werden können, weil die Hardware sonst gar nicht mehr beherschbar ist. Vom verlorenden Überblick ganz zu schweigen.
Veit D. schrieb: > Ich bin dabei etwas anderer Meinung. Wenn eine moderne IDE alles bietet > und man sich nur noch um sein Programm kümmern muss, dann ist das doch > prima. Klar. Nur wenn man sich darauf verlässt oder verlassen muss, hat man ein Problem wenn man mal was selbst machen muss. Und genauso war es dann halt auch. > Ansonsten müßte sich jeder Autofahrer mit allen Details vom Motor, > Getriebe, Elektronik usw. auskennen bevor er überhaupt fahren darf. Also diese Analogie hat echt nen riesen Bart. Und JA wenn jemand im Autoschrauberforum aufschlägt und extrem Tuning machen will, sollte er sich damit mehr auskennen als nur den Schlüssel umzudrehen. > Warum darf eine IDE diese Vorarbeit nicht abnehmen? Darf. Aber das Wissen um die Hintergründe schaden nicht. Oder man darf eben das bequeme Nest dann nie wieder verlassen.
Ja,ja den Autovergleich hört man immer wieder. Aber der hinkt. Ein Auto ist dafür gemacht, dass man nur die Bedienung beherrschen muss und nicht das Innenleben. Ein raspi hat oft ein Linux mit APIs und LIBs, das ist normalerweise der Schnittpunkt zum Anwendungsentwickler. Diese Zwischenschicht ist beim nackten Controller nicht vorhanden oder nicht Standard. Jeder Hersteller will über seine eigenen Libs die Entwickler an sich binden damit sie niemals auf die Idee kommen andere Chips zu verwenden. Jemand dem das Ref.Manual eines Controller nicht in Mark und Knochen steckt kann ich höchstens als Bastler bezeichnen. Aber jeder hat halt seine Meinung.
temp schrieb: > Jemand dem das Ref.Manual eines Controller nicht in Mark und > Knochen steckt kann ich höchstens als Bastler bezeichnen. Aber jeder hat > halt seine Meinung. Ist ja komisch. Andere haben mich Bastler genannt, weil ich lieber mit Ref. Manual anstatt Cube HAl arbeite. Wobei ich mich selbst als Bastler sehe, aber aus anderen Gründen. Elektronik ist nämlich nicht mehr mein Job. MSP ist gut, schrieb: > Lass dir von Stefan und seinem Boy nicht so einen Scheiss erzählen. > Das sind halt keine Teamplayer. Wer ist denn mein "Boy"? Natürlich darfst du meine Empfehlungen schlecht finden. Daraus abzuleiten, dass ich kein Teamplayer sei, finde ich aber unangebracht. In der Tat bin ich genau das Gegenteil. Ich habe mich vom Einzelgänger über Teamplayer zum Teamleiter hoch gearbeitet.
Veit D. schrieb: > @ Cyblord & Holm > > Ich bin dabei etwas anderer Meinung. Wenn eine moderne IDE alles bietet > und man sich nur noch um sein Programm kümmern muss, dann ist das doch > prima. > Ja. > Ansonsten müßte sich jeder Autofahrer mit allen Details vom Motor, > Getriebe, Elektronik usw. auskennen bevor er überhaupt fahren darf. Niemand verbietet Dir mit einer IDE zu fahren deren Wirkungsweise ..oder die des Prozessors Du nicht durchschaust. Du solltest nur dann die Klappe halten wenn sich Techniker über die Zündung unterhalten. > > Warum darf eine IDE diese Vorarbeit nicht abnehmen? Du kannst tun und lassen was Du möchtest und Du kannst auch Eggschberde sein für Deine IDE.. > > Ich denke auch das fette µC nur noch auf modernen Wege überhaupt > programmiert werden können, weil die Hardware sonst gar nicht mehr > beherschbar ist. Vom verlorenden Überblick ganz zu schweigen. Käse. Bei der nächsten IDE füre den nächsten Prozessor ist plötzlich das Lenkrad im Kofferraum und die Bremse auf dem Dach, ..und Alle außer Dir finden das völlig normal.. Du erhebst (wie Microsoft) die Dunkelheit zum Industriestandard. Glaubst Du Windows oder Linux wird mit einer IDE gebastelt? Gruß, Holm
Holm T. schrieb: > Glaubst Du Windows oder Linux wird mit einer IDE gebastelt? Aber selbstverständlich! Nur, daß da nicht "gebastelt" sondern gearbeitet wird. Sonst würde wir wohl heute noch mit einer Kommandozeile leben müssen... Daß du bei Linux-Code auf github meist keine IDE siehst, liegt daran, daß jede ernst zu nehmende IDE parallel immer auch ein Makefile generiert, mit dem sich der Code auch ohne die IDE weiter nutzen läst. (Attolic, CubeIDE & Co natürlich auch) Das ist einfach der kleinste gemeinsame Nenner der natürlich immer funktionieren sollte. Daraus abzuleiten, daß die Entwickler keine IDE nutzen ist einfach nur blauäugig. Und wenn man "liefern muß" weil einem der Kunde im Nacken sitzt, wird der wenig Verständnis dafür haben, wenn du ihm erklärst, daß du erst noch 2000 Seite Ref-Manual lesen und verstehen mußt, bevor du mit der eigentlichen Arbeit beginnen kannst, während deine Mitbewerber mit Hilfe der Hersteller-Tools (HAL & Co) bereits fertig sind. Natürlich braucht man als Entwickler das Ref-Man - aber zum Nachschlagen, wenn man Dinge nicht versteht. Unglaublich, was manche Leute für vollkommen praxisferne Vorstellungen vertreten.
Harry L. schrieb: > Holm T. schrieb: >> Glaubst Du Windows oder Linux wird mit einer IDE gebastelt? > > Aber selbstverständlich! > Nur, daß da nicht "gebastelt" sondern gearbeitet wird. Ja nee, is klar. > Sonst würde wir wohl heute noch mit einer Kommandozeile leben müssen... Du glaubst wirklich das sich da einer hinsetzt und mit der Maus Buttons drückt um einen Buildprozeß zu bewerkstelligen? :-)) > > Daß du bei Linux-Code auf github meist keine IDE siehst, liegt daran, > daß jede ernst zu nehmende IDE parallel immer auch ein Makefile > generiert, mit dem sich der Code auch ohne die IDE weiter nutzen läst. > (Attolic, CubeIDE & Co natürlich auch) > Das ist einfach der kleinste gemeinsame Nenner der natürlich immer > funktionieren sollte. > Daraus abzuleiten, daß die Entwickler keine IDE nutzen ist einfach nur > blauäugig. Deine Vorstellungen sind einfach nur völlig daneben.. > > Und wenn man "liefern muß" weil einem der Kunde im Nacken sitzt, wird > der wenig Verständnis dafür haben, wenn du ihm erklärst, daß du erst > noch 2000 Seite Ref-Manual lesen und verstehen mußt, bevor du mit der > eigentlichen Arbeit beginnen kannst, während deine Mitbewerber mit Hilfe > der Hersteller-Tools (HAL & Co) bereits fertig sind. Nein der Kunde wird begeistert sein das Du die Autopilot-Software seines Fahrezeugs mal fix mit drei Buttonclicks und 5 Arduino Sketches zusammenkleisterst, ohne das Du begriffen hast was das System überhaupt tut..ganz sicher. > > Natürlich braucht man als Entwickler das Ref-Man - aber zum > Nachschlagen, wenn man Dinge nicht versteht. Du verstehst ja nicht mal wie man Software macht. > > Unglaublich, was manche Leute für vollkommen praxisferne Vorstellungen > vertreten. Aber exakt! YMMD! Gruß, Holm
Holm T. schrieb: > Du glaubst wirklich das sich da einer hinsetzt und mit der Maus Buttons > drückt um einen Buildprozeß zu bewerkstelligen? :-)) Ein dezidierter Buildserver hat mit der Nutzung einer IDE nicht viel zu tun. Die IDE muss keinesfalls den Build Prozess übernehmen. Aber es gibt genügend andere Aufgaben. Denkst du die schreiben den Code in Notepad oder wie?
:
Bearbeitet durch User
Cyblord -. schrieb: > Holm T. schrieb: >> Du glaubst wirklich das sich da einer hinsetzt und mit der Maus Buttons >> drückt um einen Buildprozeß zu bewerkstelligen? :-)) > > Ein dezidierter Buildserver hat mit der Nutzung einer IDE nicht viel zu > tun. Die IDE muss keinesfalls den Build Prozess übernehmen. Aber es gibt > genügend andere Aufgaben. Sicher doch. Ich lehne den Kram ja auch nicht rundweg ab, IDEs sind aber dann eher kontraproduktiv wenn man mehrere verschiedene Targets zu behandeln hat und jede eine eigene Vorstellung davon mitbringt was wo wie zu funktionieren hat. Außerdem ist es erwiesenermaßen eine Fehlannahme das man damit (wie auch immer) schneller zum Ziel kommt, für das Blinky oder Helloworld Programm mag das stimmen, dann hört das aber schlagartig auf. BTW: Notepad kommt auf meiner Entwicklungsumgebung nicht vor. Gruß, Holm Los doch..für die die zu doof sind ohne Kommandozeile und Versionsverwaltung klar zu kommen, ich brauche noch Minuspunkte..outet Euch!
Holm T. du mußt es ja wissen.... Was du hier äusserst ist reines s/w-Denken. Es gibt nicht nur Hardcore-Bitscghubser, die selbst einen Button noch händisch als Array im Code definieren und die Arduidioten am anderen Ende. Wer sich in der heutigen Zeit bei der Komplexität der Hard- und Software den Tools der Hersteller verweigert, sollte mal langsam anfangen, über den Ruhestand nachzudenken! Wer nicht mit der Zeit geht, geht mit der Zeit. Ich programmiere seit >40J und davon >30 um meine Brötchen zu verdienen. Allerdings bin ich nicht in den 90er in einer Zeitschleife hängen geblieben, und bilde mich ständig fort. Den Blödsinn, den du hier verzapfst, kann ich wirklich nicht ernst nehmen.
:
Bearbeitet durch User
Holm T. schrieb: > BTW: Notepad kommt auf meiner Entwicklungsumgebung nicht vor. Es ging ja grad um das Microsoft Beispiel. Denkst du die entwicklen unter Linux? > Los doch..für die die zu doof sind ohne Kommandozeile und > Versionsverwaltung klar zu kommen, ich brauche noch Minuspunkte..outet > Euch! Ich denke der einzige der sich als ewig gestriger outet bist du. Prof. Software entwickelt man so ganz sicher nicht. Aber das ist schon so offensichtlich dass sie darüber keine weitere Diskussion mehr lohnt.
Harry L. schrieb: > Holm T. du mußt es ja wissen.... > > Was du hier äusserst ist reines s/w-Denken. > > Es gibt nicht nur Hardcore-Bitscghubser, die selbst einen Button noch > händisch als Array im Code definieren und die Arduidioten am anderen > Ende. > > Wer sich in der heutigen Zeit bei der Komplexität der Hardware den Tools > der Hersteller verweigert, sollte mal langsam anfangen, über den > Ruhestand nachzudenken! > oha, wie kommst Du nur auf diesen Trichter? Die Tatsache das unterscheidliche IDEs von unterschiedlichen Herstellern jeweils Einarbeitungszeit benötigt, geht Dir dabei scheinbar nicht auf. Das ich Unterstützund des Herstellers aber ablehne, hast Du Dir aus den Fingern gesogen, ich benutze sehr wohl Bibliotheken und ggf. Tools, aber keine IDE die mir die Arbeit eher erschwehrt, weil ich mich um deren Befindlichkeiten kümmern muß. > Wer nicht mit der Zeit geht, geht mit der Zeit. Ja, Da Du scheinbar Einbahnstraßenprogrammierer bist solltest Du Dir das mal hinter die Ohren schreiben. > > Ich programmiere seit >40J und davon >30 um meine Brötchen zu verdienen. > Allerdings bin ich nicht in den 90er in einer Zeitschleife hängen > geblieben, und bilde mich ständig fort. Nöö..Du bist nur dabei nicht schlauer geworden und nur noch Mausschubser. > > Den Blödsinn, den du hier verzapfst, kann ich wirklich nicht ernst > nehmen. Dann laß es und schubse Mäuse. Gruß, Holm
Cyblord -. schrieb: > Holm T. schrieb: >> BTW: Notepad kommt auf meiner Entwicklungsumgebung nicht vor. > > Es ging ja grad um das Microsoft Beispiel. Denkst du die entwicklen > unter Linux? Selbst Wenn die unter Fenster entwickeln, meinst Du die hätten nicht einen für Programmierer brauchbaren Editor? > >> Los doch..für die die zu doof sind ohne Kommandozeile und >> Versionsverwaltung klar zu kommen, ich brauche noch Minuspunkte..outet >> Euch! > > Ich denke der einzige der sich als ewig gestriger outet bist du. Prof. > Software entwickelt man so ganz sicher nicht. Aber das ist schon so > offensichtlich dass sie darüber keine weitere Diskussion mehr lohnt. Na zumindest lebe ich u.A. von der Entwicklung genau dieser Sorftware...für Mikrocontroller... Gruß, Holm
Holm T. schrieb: > Selbst Wenn die unter Fenster entwickeln, meinst Du die hätten nicht > einen für Programmierer brauchbaren Editor? Doch. Und zwar als Teil einer IDE. Bei Microsoft würde ich auf Visual Studio tippen.
Holm T. schrieb: > Nöö..Du bist nur dabei nicht schlauer geworden und nur noch > Mausschubser. > >> >> Den Blödsinn, den du hier verzapfst, kann ich wirklich nicht ernst >> nehmen. > > Dann laß es und schubse Mäuse. Da ist es wieder; das bereits genannte schwarz/weiß-Denken. Scheinbar kannst/willst du dir nicht vorstellen, daß man durchaus das beste beider Welten kombinieren kann... An selbst generierten Dogmen fest zu halten war noch nie zielführend.
Holm T. schrieb: > Na zumindest lebe ich u.A. von der Entwicklung genau dieser > Sorftware...für Mikrocontroller... Jaja, ein bisschen Microcontroller Blinky Zeug im 1-Mann Betrieb. Da ist es natürlich egal ob du damit VIM frickelst und ob dir Versionsverwaltung zu sagt.
Cyblord -. schrieb: > Holm T. schrieb: >> Selbst Wenn die unter Fenster entwickeln, meinst Du die hätten nicht >> einen für Programmierer brauchbaren Editor? > > Doch. Und zwar als Teil einer IDE. Bei Microsoft würde ich auf Visual > Studio tippen. Es wäre nicht das erste Mal das Microsoft intern die eigenen Produkte nicht nutzt, aber ich überlasse das auch gerne Denen. Wozu Notepad allerdings gut sein soll, weiß der Teufel, gibts einen dümmeren Editor irgendwo? ..ja edlin evtl.. Gruß, Holm
Harry L. schrieb: > Holm T. schrieb: >> Nöö..Du bist nur dabei nicht schlauer geworden und nur noch >> Mausschubser. >> >>> >>> Den Blödsinn, den du hier verzapfst, kann ich wirklich nicht ernst >>> nehmen. >> >> Dann laß es und schubse Mäuse. > > Da ist es wieder; das bereits genannte schwarz/weiß-Denken. > > Scheinbar kannst/willst du dir nicht vorstellen, daß man durchaus das > beste beider Welten kombinieren kann... > Ach, warst nicht genau Du es der gerade noch diese Meinung vertreten hatte? > An selbst generierten Dogmen fest zu halten war noch nie zielführend. Zieh Dir mal Deinen alten Latsch selber an. BTW: auch ich programmiere (für Geld) seit 1991), seit 12 Jahren auf eigene Rechnung. Gruß, Holm
Holm T. schrieb: > Es wäre nicht das erste Mal das Microsoft intern die eigenen Produkte > nicht nutzt, aber ich überlasse das auch gerne Denen. ist auch irrelevant für das Thema. Aber eine IDE werden sie nutzen. Bei Versionsverwaltung sind sie glaube ich vom eigenen CodeSafe weg. Aber natürlich nutzen sie trotzdem eine. > Wozu Notepad > allerdings gut sein soll, weiß der Teufel, gibts einen dümmeren Editor > irgendwo? ..ja edlin evtl.. Ach Gottchen, dir ist auch alles recht um dich zu entblöden.
:
Bearbeitet durch User
Cyblord -. schrieb: > Holm T. schrieb: > >> Es wäre nicht das erste Mal das Microsoft intern die eigenen Produkte >> nicht nutzt, aber ich überlasse das auch gerne Denen. > ist auch irrelevant für das Thema. Aber eine IDE werden sie nutzen. > Bei Versionsverwaltung sind sie glaube ich vom eigenen CodeSafe weg. > Aber natürlich sie trotzdem eine. Wenn der Compiler auf einem Buildhost läuft, ist das schon keine IDE mehr, sondern ein Batch System. > >> Wozu Notepad >> allerdings gut sein soll, weiß der Teufel, gibts einen dümmeren Editor >> irgendwo? ..ja edlin evtl.. > > Ach Gottchen, dir ist auch alles recht um dich zu entblöden. Meinst Du? Nimm mir doch mal bitte die Vokabel "entblöden" auseinander und erzähle einem Mitteldeutschen was das zu bedeuten haben soll. Gruß, Holm
Holm T. schrieb: > Cyblord -. schrieb: >> Holm T. schrieb: >> >>> Es wäre nicht das erste Mal das Microsoft intern die eigenen Produkte >>> nicht nutzt, aber ich überlasse das auch gerne Denen. >> ist auch irrelevant für das Thema. Aber eine IDE werden sie nutzen. >> Bei Versionsverwaltung sind sie glaube ich vom eigenen CodeSafe weg. >> Aber natürlich sie trotzdem eine. > > Wenn der Compiler auf einem Buildhost läuft, ist das schon keine IDE > mehr, sondern ein Batch System. Dachte ich mir doch. Du weißt ja noch nicht mal was eine IDE ist. Nochmal: Eine IDE bleibt eine IDE auch wenn sie NICHT für das bauen zuständig ist. Das Bauen erfolgt dann außerhalb. Über einen Buildserver oder Batch System oder sonst was. Die IDE darf trotzdem eine IDE bleiben. Außerdem nutzt man das auch oft dual, d.h. lokal baut die IDE schon, Releases macht der Build Server. Und jetzt frickel doch einfach auf deiner Kommandozeile weiter und erzähle uns nichts vom Pferd wie man in großen Firmen, innerhalb von verteilten Teams, Software entwickelt. Du hast jetzt deutlichst gezeigt dass du davon keinen Schimmer hast. Es wird nicht mehr besser für dich. Glaubs mir.
Cyblord -. schrieb: > Holm T. schrieb: >> Cyblord -. schrieb: >>> Holm T. schrieb: >>> >>>> Es wäre nicht das erste Mal das Microsoft intern die eigenen Produkte >>>> nicht nutzt, aber ich überlasse das auch gerne Denen. >>> ist auch irrelevant für das Thema. Aber eine IDE werden sie nutzen. >>> Bei Versionsverwaltung sind sie glaube ich vom eigenen CodeSafe weg. >>> Aber natürlich sie trotzdem eine. >> >> Wenn der Compiler auf einem Buildhost läuft, ist das schon keine IDE >> mehr, sondern ein Batch System. > > Dachte ich mir doch. Du weißt ja noch nicht mal was eine IDE ist. Soso. Dachtest Du. > Nochmal: Eine IDE bleibt eine IDE auch wenn sie NICHT für das bauen > zuständig ist. Das Bauen erfolgt dann außerhalb. ..unterhalb ..oder mehr seitlich? > Über einen Buildserver > oder Batch System oder sonst was. Die IDE darf trotzdem eine IDE > bleiben. Außerdem nutzt man das auch oft dual, d.h. lokal baut die IDE > schon, Releases macht der Build Server. Toll. Und was ist jetzt eine IDE? Ist ein PDF Reader, ein grafischer Debugger und ein Editor mit Syntax highlighting, der mit einer "F"-Taste make und program aufruft, auf einem Desktop evtl. auch eine IDE? ..oder fehlt der der Rahmen mit dem Name des Prozessorherstellers oben? Darf das Fenster des Debuggers auf einem anderen virtuellen Desktop liegen als der Editor mit der Source? ..und das serielle Terminal mit deem Output des Targets auf einem Weiteren? > > Und jetzt frickel doch einfach auf deiner Kommandozeile weiter und > erzähle uns nichts vom Pferd wie man in großen Firmen, innerhalb von > verteilten Teams, Software entwickelt. Du hast jetzt deutlichst gezeigt > dass du davon keinen Schimmer hast. Es wird nicht mehr besser für dich. > Glaubs mir. Labere Du einfach weiter von Dingen die Du gar nicht erfaßt, ich kenne schon Viele von dieser Sorte.. Gruß, Holm
Wenn es um Leistung geht ist ein Pi Zero oder TI Sitara viel billiger als ein STM32 M7 und mit RiscOS auch viel einfacher zu programmieren und als uC zu nutzen als mit der HAL und anders als mit Linux gibt es keinen Overhead und echte Echtzeit.
Holm T. schrieb: > IDEs sind aber dann eher kontraproduktiv wenn man mehrere > verschiedene Targets zu behandeln hat Warum das denn? > Außerdem ist es erwiesenermaßen eine > Fehlannahme das man damit schneller zum Ziel kommt. Ich hasse diese Frage, aber jetzt muss ich sie mal stellen: Kannst du den Beweis zeigen oder verlinken? Ich habe den Eindruck, dass du vielleicht Framework mit IDE verwechselst. Ich kenne das so, dass die Softwareentwickler lokal eine IDE benutzen. Sie enthalten viele Funktionen, die das Arbeiten beschleunigen und Fehler vermeiden. Zum Beispiel: - Automatische Eingabeergänzung - Refactoring (Umbenennen, Verschieben und Funktionsparameter im ganzen Projekt (oder gar vielen Projekten)) - Syntax Check - Plausibilitäts-Checks (z.B. wenn du eine Variable liest ohne sie vorher zu beschrieben) - Debugging (wer will das freiwillig an der Kommandozeile tun?) - Auflösen von Merge-von Konflikten (kennst du nicht, wenn du alleine arbeitest) - Und natürlich die umfangreichen Suchfunktionen Zur Erstellung einer Lieferung wird aber häufig ein Server mit einer stabilen Softwareinstallation und Build Scripten verwendet. Damit sichergestellt ist, dass jeder Build für jeden Entwickler 100% wiederholbar ist.
Die Fragen stellen sich doch so gar nicht. Viele von Euch arbeite nunter Windows uncd assoziieren die Arbeit auf dem Desktop mit einer IDE, denken damit mit Grausen daran was ihnen MSDOS auf der Kommandozeile zu bieten hat. Wenn ich das als Vorrausetzung der Diskussion ansehe, verstehe ich die Empörung. Die Sache liegt aber anders. Ich benutze nicht etwa einen Bildschirm mit einem Propt c:\>. Ich arbeite unter Unix seit den 90ern. Unix wurde gemacht von Programmierern für Programmierer und es gibt allerhand Tools die die Arbeit von Programmierer erleichtern. Dazu zähöt u.A. das Tool make das Buildprozesse automatisiert und Abhänggikeiten von Dateien untereinander berücksichtigt, also auch heraus bekommt wan was neu zu bauen ist, weil sich eine Komponente geändert hat. Umgebunsvariabeln nehmen Pfade auf, Streameditoren können Datenströme editieren, es gibt Tools die Quellen autoamtisch anhübschen und es gibt auch Compiler-Compiler, Tools zur lexikalischen Analyse und Reportgeneratoren. Merge Konflikte? Ich weiß nicht wie viele Versionskontrollsysteme es unter Unix gab/gibt, das fing wohl mit SCCS an..über CVS, Subversion und nun git..um die Bekanntesten zu nennen. Die ganze Funktionalität die Du darstellst ist nicht an eine "IDE" gebunden, es ist nur in einer IDE eine Sammlung von Utilities die das "unter einem Dach" zur Verfügung stellen will. Es ist mit nichten so, das ich auf irgend Etwas davon verzichten müßte, es gibt a) eine Grafische Oberfläche auf der das Ganze stattfindet, also auch die Kommandozeile(n!) und b) eine Anzahl Tools die nach vordefinierten Regeln miteinander Daten austauschen können und auch merken wenn sich die bearbeitete Datei (auf der z.B. ein Debugger hockt) geändert hat und die neu einlesen. Diese Komponenten kann man z.B. auch mit Eclipse unter Unix zu einer IDE zusammenfassen, sieht dann viereckig aus und auch ein Windws User begreift das als IDE. Ich bin aber nicht gezwungen dieses Framework zu benutzen das dazu tendiert je nach Gusto des Produzenten unterschiedlich zu funktionieren und Konfigurationen an verschiedenen Stellen zu verstecken. Ich habe eine Arbeitsumgebung mit einem mir geeignet erscheinenden Editor (vim) der acuh Syntax-higlighting unterstützt und mich bei Bedarf aus einer grafischen Benutzeroberfläche anglotzt, wiederkehrende Aufgaben wie eben Compilerläufe lassen sich von dort einfach und automatisiert aufrufen, der Debugger sieht auch grafich aus und läuft aus Platzgründen einen Mausklick entfernt in einem anderen virtuellen Desktop. Neben dem Editor(en) habe ich i.A. die Doku des Targets offen usw. Das Ganze ergibt ein Development Environment das hoch optimiert genau das tut was ich möchte und was für den gegebenen Zweck sinnvoll ist, ohne das ich morgen, wenn ich aus Spaß an einem Z80 oder einem MSP430 bastele, eine andere Umgebung dafür bemühen müßte. Ich muß mich nichgt umgewöhnen und bin deswegen effizient. Es ist nicht lange her das ich nach einem Build-Environment für AtXmega für einen meiner Kunden fragte, er wollte genau das haben was ich habe, aber unter Windows. Er wollte die von mir geschriebene Firmware vor Ort aus meinen Quellen übersetzen können mit einem einfachen "make", nach dem er die erforderlichen Schritte unter AVR-Studio mit dem verglichen hatte was ich zu tippern hatte. Schon das Laden eines Hex Files für EEPROM und Flash für den Xmega und das nachfolgende Programmieren mit AVR Studio ging ihm auf die Nerven ..Zip Archiv downloaden, auspacken, AVR Studio anwerfen, Files raussuchen und anclickern und Programmieren, anstatt Kommandozeile und "make program", er hats bekommen. Meine IDE integriert also die Utilities die mein System zur Verfügung stellt, azu gehören die Unix Tools aber auch irgendwelche 3rd Party Utilities und eigener Kram. Eine IDE als Solche bekomme ich z.B. von TI und die kann ich nicht vernünftig nutzen wenn ich keinen TI Prozessor sondern einen Arm oder einen AtXmega in der Mache habe, das genau ist es, was mir auf den Wcker fällt, weil jeder Hersteller seine eigene Suppe kocht. Drittanbieter machen auch immer mal schicke sachen..um dann plötzlich und unerwartet von der Bildfläche zu verschwinden. Mein Kram verschwindet aber nicht und ich kann das selbe Environment benutzen um damit einen 8051 zu behandeln. Da schleifts freilich mit dem Debugger.. BTW: Es gibt Leute die meinen EMACS sei ein hervorragendes Betriebssystem, es wäre nur traurig das es Unix zum Booten braucht (ist heute nicht mehr so). Ich behaupte hier das ist kein Betriebsssystem, das ist ne IDE! Man kann da Alles machen ohne den Editor zu verlassen. (J sag mal was dazu) ..ich benutze ihn nur nicht, war nicht mein Geschmack.. Während ich hier tippere läuft in einem Fenster in der Ecke seit Stunden der Buildprozess für FreeBSD auf einem Server eines Kunden..ein Update aus den Sourcen, remote mit Subversion vorher auf einem definierten Stand gebracht. Wie geht das mit einer IDE? Gruß, Holm
Holm T. schrieb: > Ich arbeite unter Unix seit den 90ern. Schön für dich! Andere aber auch - ich z.B. Holm T. schrieb: > Ich bin aber nicht gezwungen dieses Framework zu > benutzen das dazu tendiert je nach Gusto des Produzenten unterschiedlich > zu funktionieren und Konfigurationen an verschiedenen Stellen zu > verstecken. Gerade für das von dir zitierte Eclipse trifft genau das nicht zu. Eclipse ist nun mal ein komplexer aber prall gefüllter Werkzeugkasten, der viel Einarbeitungszeit erfordert, aber wenn man das hinter sich hat, hat man eine IDE für alles. Mit meinem Eclipse entwickel ich aktuell für. STM32, AVR (8bit), Linux (x86), Linux (ARM/RPi) etc. Ist ein wenig wie die gute alte Schreibmaschine im Vergleich zu Word. Wer mit der Schreibmaschine umgehen kann, ist noch lange nicht in der Lage, mit Word komplexe Dokumente mit komplexen Formatierungen zu erzeugen - das muß man auch erst lernen - selbst wenn man bereits den Literatur-Nobelpreis bekommen hat. Und das auch und sogar unter Linux. Holm T. schrieb: > Meine IDE integriert also die Utilities die mein System zur Verfügung > stellt, azu gehören die Unix Tools aber auch irgendwelche 3rd Party > Utilities und eigener Kram. Eine IDE als Solche bekomme ich z.B. von TI > und die kann ich nicht vernünftig nutzen wenn ich keinen TI Prozessor > sondern einen Arm oder einen AtXmega in der Mache habe, das genau ist > es, was mir auf den Wcker fällt, weil jeder Hersteller seine eigene > Suppe kocht. s.o.: wenn man Eclipse einmal verstanden hat, ist es kinderleicht, da weitere Ziel-Architekturen zu inetgrieren. Der Weg is dahin kann zugegebenermaßen für den Konsolen-zentrierten User steinig sein. Nur, weil du das nicht kannst, ist das nicht schlecht.
:
Bearbeitet durch User
Harry L. schrieb: > Holm T. schrieb: >> Ich arbeite unter Unix seit den 90ern. > > Schön für dich! > Andere aber auch - ich z.B. > > Holm T. schrieb: >> Ich bin aber nicht gezwungen dieses Framework zu >> benutzen das dazu tendiert je nach Gusto des Produzenten unterschiedlich >> zu funktionieren und Konfigurationen an verschiedenen Stellen zu >> verstecken. > > Gerade für das von dir zitierte Eclipse trifft genau das nicht zu. > > Eclipse ist nun mal ein komplexer aber prall gefüllter Werkzeugkasten, > der viel Einarbeitungszeit erfordert, aber wenn man das hinter sich hat, > hat man eine IDE für alles. > > Mit meinem Eclipse entwickel ich aktuell für. STM32, AVR (8bit), Linux > (x86), Linux (ARM/RPi) etc. Na dann Glückwunsch, mich hat das Zeug bisher nur genervt. > > Ist ein wenig wie die gute alte Schreibmaschine im Vergleich zu Word. > Wer mit der Schreibmaschine umgehen kann, ist noch lange nicht in der > Lage, mit Word komplexe Dokumente mit komplexen Formatierungen zu > erzeugen - das muß man auch erst lernen - selbst wenn man bereits den > Literatur-Nobelpreis bekommen hat. :-) Wie konnten nur Ohne Eclipse IDE vorher komplexe Softwareprojekte umgesetzt weren, einfach unverständlich ... > > Und das auch und sogar unter Linux. Das istm ir egal, ich arbeite nicht unter Linux. > > Holm T. schrieb: >> Meine IDE integriert also die Utilities die mein System zur Verfügung >> stellt, azu gehören die Unix Tools aber auch irgendwelche 3rd Party >> Utilities und eigener Kram. Eine IDE als Solche bekomme ich z.B. von TI >> und die kann ich nicht vernünftig nutzen wenn ich keinen TI Prozessor >> sondern einen Arm oder einen AtXmega in der Mache habe, das genau ist >> es, was mir auf den Wcker fällt, weil jeder Hersteller seine eigene >> Suppe kocht. > > s.o.: wenn man Eclipse einmal verstanden hat, ist es kinderleicht, da > weitere Ziel-Architekturen zu inetgrieren. Sortierst Du die Welt in Eclipse Versteher und Nichtversteher? was gibts dara nicht zu verstehen? Mir ist das Ding nur einfach zu fett und die Parameter an denen zu schrauben ist, sind mir zu Wgleichmäßig" verteilt. > Der Weg is dahin kann zugegebenermaßen für den Konsolen-zentrierten User > steinig sein. > > Nur, weil du das nicht kannst, ist das nicht schlecht. :.s/kannst/willst/ Lerne das zu begreifen. Gruß, Holm
Schon lustig, zu sehen, wie dir die Argumente ausgehen, und du versuchst mit Neben-Kriegsschauplätzen abzulenken....
Holm T. schrieb: > Viele von Euch ... denken damit mit Grausen daran was ihnen > MSDOS auf der Kommandozeile zu bieten hat. Also ich nicht, ich hatte bereits unter DOS mit einer waschechten IDE gearbeitet. > Diese Komponenten kann man z.B. auch mit Eclipse unter Unix > zu einer IDE zusammenfassen Ob die IDE aus einem Sammelsurium von Plugins oder einem Guss besteht, spielt (was den Begriff angeht) doch gar keine Rolle. > Ich bin aber nicht gezwungen dieses Framework zu benutzen Ich hatte also Recht, du verwechselst IDE mit Framework. Das sind normalerweise zwei völlig unabhängige Sachen. Es gibt wenige Ausnahmen, wo eine IDE mit einem Framework fest verheiratet ist. Das sind für mich aber Sonderfälle. > Ich habe eine Arbeitsumgebung mit einem mir > geeignet erscheinenden Editor (vim) Offensichtlich ist Dir nicht bewusst, was Refactoring ist, bzw. wie man das in diesem Jahrtausend effizient macht. Jedenfalls nicht mit sed Scripten.
Harry L. schrieb: > Schon lustig, zu sehen, wie dir die Argumente ausgehen, und du versuchst > mit Neben-Kriegsschauplätzen abzulenken.... Mir gehen die Argumente nicht aus, aber Du begreifst meine Arbeitsweise nicht und denkst ich stecke in der Steinzeit. Da kann ich nicht viel machen. Mach Dein Ding und laß mir meins. Gruß, Holm
Stefanus F. schrieb: > Holm T. schrieb: >> Viele von Euch ... denken damit mit Grausen daran was ihnen >> MSDOS auf der Kommandozeile zu bieten hat. > > Also ich nicht, ich hatte bereits unter DOS mit einer waschechten IDE > gearbeitet. > Ja, ich kenne Auch Keil und Ähnliches. Willich nicht. >> Diese Komponenten kann man z.B. auch mit Eclipse unter Unix >> zu einer IDE zusammenfassen > > Ob die IDE aus einem Sammelsurium von Plugins oder einem Guss besteht, > spielt (was den Begriff angeht) doch gar keine Rolle. Eben. > >> Ich bin aber nicht gezwungen dieses Framework zu benutzen > > Ich hatte also Recht, du verwechselst IDE mit Framework. Das sind > normalerweise zwei völlig unabhängige Sachen. Es gibt wenige Ausnahmen, > wo eine IDE mit einem Framework fest verheiratet ist. Das sind für mich > aber Sonderfälle Du siehst doch aber was passiert, mir wird hier die notwendigkeit eine IDE zu benutzen eingetrichtert. > >> Ich habe eine Arbeitsumgebung mit einem mir >> geeignet erscheinenden Editor (vim) > > Offensichtlich ist Dir nicht bewusst, was Refactoring ist, bzw. wie man > das in diesem Jahrtausend effizient macht. Jedenfalls nicht mit sed > Scripten. Doch, auch mit denen, aber nicht nur. Gruß, Holm
Holm T. schrieb: > Du siehst doch aber was passiert, mir wird hier die notwendigkeit eine > IDE zu benutzen eingetrichtert. Jeder kann ja so arbeiten, wie er will. Wenn ich dein Chef wäre, und würde bemerken, dass du ganz anders als deine Kollegen arbeitest, würde ich deine Leistung prüfen. Wenn die Ok ist, dann würde ich nicht eingreifen. Ich bin von drei aufeinander folgenden Firmen mit Schwerpunkt auf Qualitäts- und Effizienz-Verbesserung eingestellt worden. Der Erfolg wurde mir jedesmal schriftlich attestiert. Dabei bin ich stets ein Verfechter der freien Arbeitsmittel-Wahl gewesen. Erlaubt ist, was funktioniert und die anderen nicht behindert. Ein gewisses Maß an Abstimmung ist also doch nötig, aber bisher mussten wir uns noch nie auf eine bestimmte IDE oder Betriebssystem festlegen. Die Kommandozeile mit Build Script sollte auf jeden Fall immer zumindest als Fall-Back Lösung erhalten bleiben. Man macht sich damit unabhängiger, was langfristig Zeit und Kosten spart. Ich kenne allerdings keinen Entwickler, der freiwillig ohne IDE arbeitet. Du bist für mich der erste, der sich so äußert.
Stefanus F. schrieb: > Holm T. schrieb: >> Du siehst doch aber was passiert, mir wird hier die notwendigkeit eine >> IDE zu benutzen eingetrichtert. > > Jeder kann ja so arbeiten, wie er will. Wenn ich dein Chef wäre, und > würde bemerken, dass du ganz anders als deine Kollegen arbeitest, würde > ich deine Leistung prüfen. Wenn die Ok ist, dann würde ich nicht > eingreifen. Feine Sache, mein Chef macht das exakt genau so und deswegen arbeite ich genau so. > > Ich bin von drei aufeinander folgenden Firmen mit Schwerpunkt auf > Qualitäts- und Effizienz-Verbesserung eingestellt worden. Der Erfolg > wurde mir jedesmal schriftlich attestiert. Glückwunsch. > > Dabei bin ich stets ein Verfechter der freien Arbeitsmittel-Wahl > gewesen. Erlaubt ist, was funktioniert und die anderen nicht behindert. > Ein gewisses Maß an Abstimmung ist also doch nötig, aber bisher mussten > wir uns noch nie auf eine bestimmte IDE oder Betriebssystem festlegen. > > Die Kommandozeile mit Build Script sollte auf jeden Fall immer zumindest > als Fall-Back Lösung erhalten bleiben. Man macht sich damit > unabhängiger, was langfristig Zeit und Kosten spart. Es ist auch Zeit- und Kostensparend das Framework von einem vorhergehenden Projekt übernehmen zu können, selbst wenn dieses eine andere CPU verwendete. > > Ich kenne allerdings keinen Entwickler, der freiwillig ohne IDE > arbeitet. Du bist für mich der erste, der sich so äußert. Die Meisten bekommen Windows vorgeschrieben, aber selbst da gibts Leute die meinen ein zusätzliches cygwin zu benötigen. Microsoft baut mittlerweile WSL ein und hat vor ein "richtiges" Linux samt Kernel zu unterstützen..komisch. Ich möchte einfach die selbe, vertraute Umgebung zum entwickeln haben, egal was gerade das Target ist, ist das so schwer zu verstehen? Verschiedene IDEs verschiedener Hersteller unterstützen mich dabei nicht, sondern sind eher hinderlich. Warum darf ich also keine plattformübergreifenden Tools verwenden wenn mir danach ist? Mein Chef hat nix dagegen, denn das bin ich seit 12 Jahren selbst und bereits in der Firma vorher (die ich jetzt auch bin) habe ich so gearbeitet, auch in der Zeit davor als Sysop in der Uni. Meinst Du ich liege seit 28 Jahren völlig falsch? Gruß, Holm
Mw E. schrieb: > Wo hats denn beim L4 Einstieg genau gehapert? Siehe Beitrag "Einstieg in STM32(L4)" Offensichtlich ist er noch gar nicht so weit gekommen, dem Mikrocontroller zu programmieren, weil er mit der IDE nicht zurecht kam. Ich schlage vor, die Diskussion zum STM32L4 dort weiter zu führen, wo sie begonnen hat (also in eben diesem verlinkten Thread).
Stefanus F. schrieb: > Die Kommandozeile mit Build Script sollte auf jeden Fall immer zumindest > als Fall-Back Lösung erhalten bleiben. Fall-Back Lösung? Wie testet man seine Software automatisch ohne Build Script?
man kann auch die Eclipse IDE aus der Kommandozeile so aufrufen das ein oder meherere Projekte automatisch gebaut werden. Ich glaube aber den Kommandozeilenbandwurm beherschen nur ein paar Menschen auf diesem Planeten...
Beitrag #5876441 wurde vom Autor gelöscht.
Gerd K. schrieb: > Übrigens, meine Forderung nach "low power" in Kombination mit 100 MHz > begründet sich in der Idee, die MCU in einem kleinen Roboter mit > einfacher VGA Kamera zu nutzen. Da Energie immer ein Problem bei > Robotern ist -> low power und um was sinnvolles mit der Kamera zu machen > braucht man schon ein wenig Rechenpower -> 100 MHz. Tut mir leid das jetzt mal so direkt sagen zu müssen aber das klingt für mich etwas zu sehr nach Bodo Bach ("Ich hätt da gern emal e Problem") ;) Bei allem was ich als Roboter kenne (sowohl die kleinen Helferlein, die Staubsaugen, sowie die großen Teile, die bei VW im Werk Karosserien verschweißen) spielen die paar Milliampere von so einem Mikrocontroller absolut keine Rolle. Mein kleines chinesisches Helferlein (Xiaomi Roborock S50) hat beispielsweise sogar drei Mikrocontroller bzw. Mikroprozessoren an Board, ohne dass das jetzt die Ausdauer beim Saugen groß beeinflussen würde. Einen STM32 der sich um den Antrieb kümmert, einen DSP (ich meine TMS320), welcher sich (wie ich vermute) mit der Auswertung des LIDAR beschäftigt und einen Cortex-A auf dem Linux läuft und der sich wohl um die ganze Netzwerkkommunikation kümmert (d.h. der Zentralregierung meldet wie meine Wohnung aussieht und wie oft die gesaugt wird). Die große Frage ist ja, was genau du mit der VGA-Kamera anstellen willst. Willst du ein paar pixelige Bilder machen und die auf SD-Karte speichern? Wahrscheinlich nicht aber selbst wenn, dann ist ein Cortex-M mit 48MHz dafür immer noch schnell genug. Willst du Bilder/Videos per Funk an einen stationären Empfänger senden? Vielleicht schon eher aber dafür brauchst du im Prinzip überhaupt keinen Mikrocontroller, ein reiner Funksender reicht. Willst du das VGA-Bild in irgendeiner Form weiterverarbeiten, z.B. eine Bilderkennung durchführen? Dann ist ein Cortex-M eigentlich grundsätzlich die falsche Wahl und du solltest eher zu einer Lösung mit Cortex-A, a la Raspberry Pi greifen. Was mir dazu noch einfällt (und womit wir endlich wieder beim Thema wären) ist der K210 von Kendryte. Das ist ein RISC-V mit "AI-Coprocessor", der speziell für Bilderkennung und solche Dinge gedacht ist. Dev-Boards gibts beim Ali ab 25€ (inkl. Kamera).
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.