Hallo Ich mache gerade erste experimente mit dem STM32. Da die Programmiersprache verdächtig der der Arduino-Libraries ähnelt, frage ich mich ob man die Libraries bei STM32 auch nutzen kann, wenn man alle Hardware-Zeile (digitalread etc) anpasst? Geht sowas bzw. hat hier schonmal jemand sowas probiert?
Du hast den Hal (Hardware Abstraction Layer) Gedanken entdeckt. Theoretisch kannst du natürlich alle Funktionen die es bei den Arduino gibt portieren auf die Hardware des STM. Wenn sie sich gleich Verhalten, hat es den Vorteil dass du deine Applikationen direkt auf die andere Plattform übertragen kannst. Es wäre also egal welchen uC du nimmst.
Johnny S. schrieb: > Geht sowas bzw. hat hier schonmal jemand sowas probiert? Google kaputt? http://www.stm32duino.com/
Es gibt auch ein arduino Board mit ARM Chip drauf. Und das wird ebenfalls mit der arduino Umgebung programmiert. Damit brauchst du dann gar nichts zu ändern. Allerdings lernt man so auch nichts über ARM Prozessoren.
Frank schrieb: > Du hast den Hal (Hardware Abstraction Layer) Gedanken entdeckt. > > Theoretisch kannst du natürlich alle Funktionen die es bei den Arduino > gibt portieren auf die Hardware des STM. Wenn sie sich gleich Verhalten, > hat es den Vorteil dass du deine Applikationen direkt auf die andere > Plattform übertragen kannst. > Es wäre also egal welchen uC du nimmst. In den libraries gibt es relativ wenig was "Arduino" spezifisch ist, ausser natürlich zb. "digitalRead(pin)" das müsste man dan bei STM32 auf "HAL_GPIO_ReadPin(GPIOX, GPIO_PIN_XX)" umschreiben. Der Rest der Libraries ist ja meist "merken und rechnen" Googleistdeinfreund schrieb: > Johnny S. schrieb: >> Geht sowas bzw. hat hier schonmal jemand sowas probiert? > > Google kaputt? > > http://www.stm32duino.com/ STM32duino macht genau das Gegenteil, die Importieren den STM32 in die Arduino IDE damit man ihn dann gewohnt mit der Arduinos-Sprache programmieren kann!
:
Bearbeitet durch User
Chris K. schrieb: > Es gibt auch ein arduino Board mit ARM Chip drauf. Und das wird > ebenfalls mit der arduino Umgebung programmiert. Damit brauchst du dann > gar nichts zu ändern. Allerdings lernt man so auch nichts über ARM > Prozessoren. Das ist aber ein ATMEL und kein ST... wird wohl kaum funktionieren.. Wie gesagt, ich möchte STM32 direkt programmieren, aber alle Libraries komplett neu zu entwickeln macht doch wenig Sinn..
Johnny S. schrieb: > Wie gesagt, ich möchte STM32 direkt programmieren, aber alle Libraries > komplett neu zu entwickeln macht doch wenig Sinn.. Welche brauchst du denn? Bisher kam ich immer wunderbar ohne Arduino-Libs aus ... Für alles, was ein STM32 kann, kannst du die (CMSIS) StdPeriphLib verwenden. Für high-level Sachen wie MP3-Dekoder usw lassen sich auch Libs auffinden, die direkt auf dem STM32 mit Assembler-Optimierungen wunderbar laufen (Helix zB)
Mampf F. schrieb: > Johnny S. schrieb: >> Wie gesagt, ich möchte STM32 direkt programmieren, aber alle Libraries >> komplett neu zu entwickeln macht doch wenig Sinn.. > > Welche brauchst du denn? > > Bisher kam ich immer wunderbar ohne Arduino-Libs aus ... Für alles, was > ein STM32 kann, kannst du die (CMSIS) StdPeriphLib verwenden. > > Für high-level Sachen wie MP3-Dekoder usw lassen sich auch Libs > auffinden, die direkt auf dem STM32 mit Assembler-Optimierungen > wunderbar laufen (Helix zB) Ach da gibt es diverse :) hier mal die wichtigsten: - ClickEncoder - Adafruit NeoPixel - NeoGPS - TimeZone - TimerOne (gut auf die kann man verzichten) - Liquid Crystal
Johnny S. schrieb: > - Adafruit NeoPixel Zumindest dafür gibts effiziente Libraries, die die Dinger per DMA ansteuern. In der WS2812-Wordclock ist das zB eingebaut - glaube, die basiert nicht auf Arduino. Den Rest kenne ich nicht ?
Johnny S. schrieb: > Ich mache gerade erste experimente mit dem STM32. Da die > Programmiersprache verdächtig der der Arduino-Libraries ähnelt, Au weia. Das ist keine Arduino-Sprache, sondern C++. Wobei viele Arduino-Programme (und Libraries) nur den C-Teil von C++ nutzen. > frage ich mich ob man die Libraries bei STM32 auch nutzen kann, > wenn man alle Hardware-Zeile (digitalread etc) anpasst? Da es für die Cortex-M Prozessoren einen C(++) Compiler gibt (sogar den gleichen wie für AVR, nämlich den gcc) kannst du natürlich den gleichen C(++) Code auf beiden Systemen verwenden. Bis auf die harwareabhängigen Teile. ABER an dieser Stelle greift dir die Arduino-Umgebung bereits unter die Arme, indem sie die hardwareabhängigen Teile kapselt. Statt direkt auf einen IO-Port zugreifen zu müssen, kannst du einfach digitalRead() und Konsorten verwenden. Und nein, das ist keine neue Programmiersprache, sondern schlicht eine C-Funktion, die du da aufrufst. Und implementiert ist die in einer (bzw. der) Arduino-Library. > Geht sowas bzw. hat hier schonmal jemand sowas probiert? Für Anfänger (wie anscheinend du) ist die gesamte Arduino Umgebung bereits auf verschiedene Cortex-M portiert worden. Z.B. als STM32duino für STM32. Dann kannst du Arduino-Programme und (eingeschränkt) Arduino-Libraries direkt weiter benutzen. Wer das Anfänger-Stadium hinter sich gelassen hat, der kann zwischen Programmiersprache und Library unterscheiden. Und der wird sich auch recht schnell von der ineffektiven IO-Kapselung a'la Arduino verabschieden und entweder ein schlankeres HAL verwenden (für STM32 z.B. SPL oder HAL) oder gleich direkt auf die Hardware-Register schreiben.
Axel S. schrieb: > oder gleich direkt auf die Hardware-Register schreiben. Hast du ein Beispiel, wie das mit der Arduino IDE geht.
Siegfried S. schrieb: > Axel S. schrieb: >> oder gleich direkt auf die Hardware-Register schreiben. > > Hast du ein Beispiel, wie das mit der Arduino IDE geht. Was ist los? Gefallen dir die Antworten nicht, die du im Beitrag "stm32f103-bluepill-peripherie" bekommst? Die Antwort ist: in der Arduino-IDE geht das genauso wie in jeder anderen IDE (oder Editor), in der man C- bzw. C++ Code schreibt. Speziell für einen STM32 würde man sich vorher entscheiden müssen, ob man (per CMSIS Header) direkt auf die nackten Hardware-Register zugreift:
1 | #include "stm32f0xx.h" |
2 | ...
|
3 | // Power up PORTB
|
4 | RCC->AHBENR |= RCC_AHBENR_GPIOBEN; |
5 | // make bit 1 (PB1) an output
|
6 | GPIOB->MODER = GPIO_MODER_MODER1_0; |
7 | // set Port PB1 to H
|
8 | GPIOB->ODR |= GPIO_ODR_1; |
9 | delay(500000); |
10 | // and back to L
|
11 | GPIOB->ODR &= ~GPIO_ODR_1; |
12 | ...
|
(die Namen der Register und Bits findet man im Reference Manual, der Code ist für einen STM32F030, nicht den F103 auf dem Bluepill-Board) Oder ob man ein "Abstraktions" Framework des µC-Herstellers einsetzen will. Für STM32 hat man die Wahl zwischen SPL (wird nicht weiter entwickelt, nicht für neuere STM32 verfügbar) oder der HAL, die mit CubeMX kommt. Beide sind vergleichsweise fett und manchmal behäbig und manchmal auch fehlerhaft. Allerdings würde man die Arduino-IDE eigentlich gar nicht für so etwas verwenden wollen. Denn sie ist im Vergleich zu allen anderen C/C++ IDE sehr spartanisch. Der einzige Grund, die Arduino-IDE verwenden zu wollen, wäre wenn man auch den Rest der Arduino-Umgebung (vulgo: Core) verwendet. Das steht wiederum dem direkten Portzugriff diametral entgegen.
Zu STM32duino möchte ich noch ein paar Details hinzufügen (bin seit der Gründerzeit dabei, wenn auch sicher nicht das Superhirn). Mittlerweile ist das Projekt eine vielköpfige Hydra geworden. Die erste Core Version (auch "Rogers Core" genannt) basiert auf dem libmaple core, der vor einigen Jahren aufgelassen wurde. Dieser wurde weiterentwickelt und ist - zumindest für die F103 Serie - eine echte Alternative zu CMSIS, HAL bzw. StdPeriph. Grund: "Leichtgewicht" und im Laufe der Jahre ziemlich bugbeseitigt. Jetzt kommt es aber, dass sich mehrere Ableitungen bzgl. des Cores gebildet haben. Deren Grundlage ist zumeist CMSIS/HAL Die "offizielle" ST Version ist hier: https://github.com/stm32duino Immerhin beschäftigt ST einen(!) Mitarbeiter für das Projekt. Dementsprechend langsam ist die Entwicklung und der Funktionsumfang ist als "rudimentär" zu bezeichnen (um es nett zu formulieren). Interessanter, wenn auch davor veröffentlicht, war der "STM32generic" core von Danieleff. https://github.com/danieleff/STM32GENERIC Es hat vielversprechend begonnen und leider dürfte bei dieser one man show die Luft draußen sein. Jetzt kommt mein großes ABER: Der libmaple core macht durch seine Zuverlässigkeit und Optimierung durchaus Sinn für kleinere bis mittlere Projekte v.a. am Bluepill und man kann ziemlich viele "Arduino" Libraries mit wenig Aufwand einbetten. Warum man aber unter HAL noch eine "Arduino"ebene darauf klatscht, hm.. also den Sinn hab ich noch nicht ganz verstanden, da kann mal gleich "native" bleiben. Abgesehen davon, dass man bei Problemen ziemlich alleine dasteht, auch im STM32duino Forum sind ist die "alte Garde" beim libmaple core geblieben. LG Matthias/madias
Axel S. schrieb: > Was ist los? Gefallen dir die Antworten nicht Durch die Anworten, die es hier gibt, beantwortet sich deine Frage von alleine. Recht herzlichen Dank. Matthias D. (Firma: ESRA) (madias); auch dein Beitrag ist sehr aufschlussreich. Nach meiner Meinung geht es bei STM32duino sehr gemischt zu und ist für einen Anfänger schwierig zu verstehen. Wobei auch an einigen stellen Inkompatibilität zu Arduino entstanden sind. Da die STM32 Core Version von ST (Hersteller) unterstützt wird, habe ich mich für diese entschieden. Ein wenig kam noch die HAL Zukunft da zu. War aber mehr ein Gefühl. Schön wäre es, wenn die Macher vom STM32duino Forum die verschiedenen Plattformen von Anfang an trennen und nicht alles nach Thema mischen. Nochmals Danke an Axel und Matthias Bei mir geht es bei: >Arduino IDE mit STM32 Core Themen, BluePill, SPI 2< weiter. Nette Grüße Siegfried
>- ClickEncoder >- Adafruit NeoPixel >- NeoGPS >- TimeZone >- TimerOne (gut auf die kann man verzichten) >- Liquid Crystal STM32 Arduino-Frameworks gibt es einige. 1. von STM selber, aber noch nicht sonderlich weit entwickelt 2. STM32Duino 3. STM32 Generic Für die Frameworks gibt es jeweils angepasste Bibliotheken. Den Neopixel-Treiber dürfte es für alle geben. Timer-bibliotheken gibt es verschieden, sind aber Framework-spezifisch. TFT-Treiber gibt es für alle, Liquit Crystal vermutlich auch.
>Da die STM32 Core Version von ST (Hersteller) unterstützt wird, habe ich >mich für diese entschieden. So denke die meisten, werden aber dann von der Realität entäuscht. Die anderen Frameworks sind viel weiter und unterstützen mehr Peripherie.
Siegfried S. schrieb: > Schön wäre es, wenn die Macher vom STM32duino Forum die verschiedenen > Plattformen von Anfang an trennen und nicht alles nach Thema mischen. Tun sie, aber die User machen das nicht, darum kommt dieses Wirrwarr zustande und die wenigen Moderatoren (die das als Hobby betreiben) haben einfach nicht die Zeit die Beiträge, die unter falschen Schwerpunkten geschrieben werden zu sortieren. Das ST für ihren eigenen Core kein eigenes Forum haben verstehe ich auch nicht, sie sind ja quasi nur "Untermieter" bei stm32duino. Jeder neu registrierte Benutzer bekommt die "Einladung" diesen Beitrag zu lesen: http://www.stm32duino.com/viewtopic.php?f=2&t=3111 LG Matthias
>Jeder neu registrierte Benutzer bekommt die "Einladung" diesen Beitrag >zu lesen: >http://www.stm32duino.com/viewtopic.php?f=2&t=3111 Wobei dieser Absatz hier ja nicht stimmt: 3. An alternative generic core: *OUTDATED not under development anymore * edited: 23.08.2013 https://github.com/danieleff/STM32GENERIC Tatsächlich wird STM32GENERIC immer wieder weiter entwickelt und liegt auch weit vor dem "official core". Mit scheint der User "mburnette" kann den STM32Generic-Core nicht leiden ...
Doch, Ray hat das sogar auf meine Initiative ergänzt, STM32generic Core von Daniel ist jetzt fast ein Jahr brach gelegen, es wurden in den letzten Wochen ein paar Sachen "gemerged" das war es auch. Im Forum ist er komplett inaktiv seit langer Zeit. Ray hat ein klares Statement abgegeben, dass es einfach zu viele Cores gibt, das unterstütze ich auch. Kein User wird wirkliche Unterstützung für den generic Core mehr im Forum erhalten.
Matthias D. schrieb: > Zu STM32duino möchte ich noch ein paar Details hinzufügen Danke für die Aufklärung, das ist in der Tat sehr verwirrend weil im Boardmanager beide cores auf das stm32duino.com verweisen. Im Wiki sieht man auch nicht auf welchen core sich die Doku bezieht: http://wiki.stm32duino.com/index.php?title=Main_Page http://wiki.stm32duino.com/index.php?title=API Allerdings ist da auch sowieso nicht viel Info drin was die Software angeht. Die Boardbeschreibungen helfen gut weiter.
Matthias D. (Firma: ESRA) (madias) >Doch, Ray hat das sogar auf meine Initiative ergänzt, STM32generic Core >von Daniel ist jetzt fast ein Jahr brach gelegen, es wurden in den >letzten Wochen ein paar Sachen "gemerged" das war es auch. Im Forum ist >er komplett inaktiv seit langer Zeit. Ray hat ein klares Statement >abgegeben, dass es einfach zu viele Cores gibt, das unterstütze ich >auch. Kein User wird wirkliche Unterstützung für den generic Core mehr >im Forum erhalten. Tja, da gibt es dann noch den Unterschied zwischen Theorie und Praxis. Hier mal ein Beitrag aus dem STM-Forum: Thu Aug 23, 2018 1:28 pm But to stay on topic: I did some tests with my Black STM32F407VET board, with my "standard test equipment": ILI9341 SPI: Daniels core (STM32Generic): Works perfect. Huawei's core: Compiles, upload ok, but nothing, not even Serial output. It seems Huawei's core is totally broken for this board STM32 official core: Compiles, no USB output (not implemented yet), and incredible slow! I don't know if this occurs by wrong SPI speed or system clock. Was ist besser, ein Core bei dem nichts funktioniert oder ein Core bei dem alles geht und der langsam weiter entwickelt wird?
Schön, dass du meinen Beitrag aus dem Forum zitierst ? Wenn du weitere Beiträge bzgl. des GenericCores von mir liest, merkst du, dass leider nicht alles funktioniert. F4 ist bti allen Cores derzeit problematisch. Prinzipiell würde ich sagen, dass man bzgl. F1 beim Roger Core bleibt, da bekommt man auch Unterstützung durch die Community, F4 ist ein Bastelprojekt
zur Erklärung: Ich bin der User "madias" Im Stm32duino Forum
Sepp schrieb: > Was ist besser, ein Core bei dem nichts funktioniert oder ein Core bei > dem alles geht und der langsam weiter entwickelt wird? Besser ist: kein Core. Ganz ehrlich, was die Chiphersteller da seit Jahren fabrizieren ist ein schlechter Witz. Die wollen einfach nur ihre Chips verkaufen. Da viele Neulinge sich an der Verfügbarkeit bunter IDE's orientieren, nehmen sie dann das, was auf den ersten Blick oder Test gefällt. Wenn du dich erst z.B. für Cube MX entschieden hast, dann hat die Firma ST dich als neuen Kunden an sich gebunden. Und genau darum geht es. Wenn du erstmal so weit bist, hofft ST, dass du dir die Produkte der Konkurrenz nicht mehr anschaust. Die Probleme mit der Software von ST nehmen Dir auch die Zeit dafür weg. Bei Arduino muss man mal ganz klar sagen, dass der Fokus von Anfang an bei AVR Mikrocontrollern lag. Die Hardware Abstraktion dieses Systems war genau darauf zugeschnitten. Alle 32bit Varianten sind nur hässliche Balkone am Arduino Kern. Entweder akzeptierst du deren Einschränkungen, oder programmierst bare Metal (was bei ARM = CMSIS Header bedeutet). Zumindest bei ST kann ich Dir versichern, dass die bereitgestellte Doku alles enthält, was man dazu wissen muss. Noch etwas zu den STM32 Erweiterungen für Arduino: Schau Dir deren Quelltexte an. Kannst du bis zum Register-level herunter nachvollziehen, wie sie funktionieren? Wenn nicht, dann beunutze sie nicht, denn dann wirst du nicht imstande sein, Fehler zu korrigieren!
Verabschiedet euch doch mal endlich von der Arduino IDE, die ist Murks, PlatformIO und gut is. Alles drin für avr, stm32, espressif etc. Inkl arduino framework und natürlich auch bare metal sowie mbed und freeRTOS
Wenn schon STM32+Arduino, dann solltest Du in die Quelltexte dieser Libraries hinein schauen. Wenn du bis herunter zum Register nicht verstehst, wie sie funktionieren, dann lass die Finger davon. Denn dann wirst du nicht imstande sein, Fehler zu korrigieren. Aus diesem Grund blieb für mich nur noch das Werk von Roger Clark übrig. Dessen Code durchblicke ich so einigermaßen. Da ist es mir dann auch egal, dass er als Basis die Maple Libraries verwendet hat, die inzwischen tot sind. Roger Clark pflegt nicht nur seinen eigenen Code weiter, sondern auch den vom Maple kopierten Teil. Und er beantwortet Fragen dazu - das ist viel Wert. Das so ein One-Man Projekt funktional nicht so umfangreich ist, wie die anderen, damit kann ich gut leben. Den Code für externe Hardware kann ich mir selbst schreiben oder portieren (denn ich habe Zeit, da Hobby). Hauptsache der Arduino Core tut, was er soll. Aber insgesamt muss ich schon sagen, das ich Arduino eher nicht mag. Ich nutze es nur für den ESP8266 oder wenn ich mal eben schnell etwas unwichtiges hinsauen will. Die STM32 Chips bare-metal nur mit Hilfe der Register-Definitionen (CMSIS Header) in einer ausgewachsenen IDE zu programmieren, ist gar nicht so schwer, wie man auf den ersten Blickt denkt. Auch weil die Forums-Mitglieder W.S. und Niklas Gürtler großartige Hilfe bezüglich dem USB Port geleistet haben. Schau euch meine Notizen dazu an: http://stefanfrings.de/stm32/index.html Dort seht ihr, dass ich selbst noch Anfänger bin. Mit diesen Infos sollte jeder klar kommen, der schon einmal irgendeinen µC irgendwie programmiert hat.
Stefanus F. schrieb: > Ganz ehrlich, was die Chiphersteller da seit Jahren fabrizieren ist ein > schlechter Witz. Die wollen einfach nur ihre Chips verkaufen. Natürlich wollen die ihre Chips verkaufen, die produzieren soviele das sie es sogar tun müssen... Die Dinger sind so komplex geworden das es nicht reicht einen Chip und ein 1000 seitiges Handbuch dazu zu liefern. Der Markt ist heiß umkämpft und der Support seitens der Hersteller ist einfach ein Mehrwert für den Kunden, so kann man das auch sehen. Für die ganzen Tools und Libraries hat man noch vor wenigen Jahren mehrere k€ auf den Tisch legen müssen, heute kostet dich das nur noch eine Registrierung. Und das böse 'vendor lock-in' juckt da auch keinen mehr, die STM32 oder NXP Palette ist so gross das man gar nicht einen Hund aus jedem Dorf braucht. Das ist einfach erfolgreiches Marketing und da man auch als Bastler alles für Nüsse bekommt sind soche Beschwerden völlig unnötig. Zum Thema cores: das ist Open Source und da haben freiwillige Unterstützer viel Zeit reingesteckt. Die Projekte leben vom mitmachen, testen und Fehler melden, nicht vom beschweren über deren Fehler.
Johannes S. schrieb: > ist einfach ein Mehrwert für den Kunden, so kann man das auch sehen. Ja stimmt wohl. > Zum Thema cores: das ist Open Source und da haben freiwillige > Unterstützer viel Zeit reingesteckt. Die Projekte leben vom mitmachen, > testen und Fehler melden, nicht vom beschweren über deren Fehler. Allerdings. Der haken hier ist meiner Meinung, dass man nur mitmachen kann, wenn man deren Quelltext verstanden hat. Und wenn man so weit ei, darf man sich schon mal die Frage stellen, warum man überhaupt noch mit Arduino herum kaspert. Als Plattform für den Unterricht und für schnelle Basteleien ist Arduino sicher eine tolle Sache. Für die Italienischen Macher scheint es sich auch finanziell zu lohnen. Aber für die Hobbyprogrammierer, die ohne kommerziellen Beweggrund zusätzliche Cores entwickeln scheint es in meinen Augen nicht so lohnenswert zu sein. Das wird wohl auch ein Grund sein, warum daran nur so wenige Leute arbeiten.
masterfx schrieb: >Verabschiedet euch doch mal endlich von der Arduino IDE, die ist Murks, >PlatformIO und gut is. Alles drin für avr, stm32, espressif etc. Inkl >arduino framework und natürlich auch bare metal sowie mbed und freeRTOS Soso, und du meinst tatsächlich, PlatformIO funktioniert ohne Core?
Timmo H. schrieb: >>Verabschiedet euch doch mal endlich von der Arduino IDE, die ist Murks, Sepp schrieb: > Soso, und du meinst tatsächlich, PlatformIO funktioniert ohne Core? Ich habe mich nicht getraut zu widersprechen, weil ich PlatformIO noch nicht wirklich ausprobiert habe. Als ich mir dessen Konzept durchgelesen hatte, war mein erster Eindruck, dass es sich hier wohl wieder nur um ein weiteres Framework handelt, das auf ein Framework (Arduino) aufsetzt, dass wiederum auf ein Framework (HAL) aufsetzt, dass auf CMSIS aufsetzt. Das ist etwa so als ob ich mit meinem Motorrad auf die Ladefläche eines Pickup fahre, der auf einen Abschleppwagen geladen wird, der mit einem Autozug in den Urlaub fährt. Hey, ich bin 30.000km Moped gefahren und es sieht noch wie neu aus!
Stefanus F. schrieb: > Das wird wohl auch ein Grund > sein, warum daran nur so wenige Leute arbeiten. beim Rogerclark werden immerhin 71 contributors gelistet. Gute, nachvollziehbare bug reports helfen auch schon, die Quellen muss man nicht immer sofort verstehen. Und man muss erstmal mit git klarkommen, damit kämpfe ich auch noch, bin noch die Generation 'Version mit spärlichen Kommentaren zippen'. Im Informatikstudium sollte heute das erste Semester ausschliesslich Versionsverwaltung sein.
Stefanus F. schrieb: > dass es sich hier wohl wieder nur um > ein weiteres Framework handelt, das auf ein Framework (Arduino) > aufsetzt, habe auch noch nicht damit gearbeitet, aber so ein Framework Türmchen sehe ich nicht. Die Arduino IDE ist sehr generisch, genau wie Eclipse oder VS. Durch PlugIns werden Toolchain und Libs verfügbar gemacht. PlatformIO erweitert das und baut diese Komponenten in seiner Umgebung zusammen.
So schön diese Framework-auf-Framework-auf-Framework auch aussehen mögen, so schwer sind sie zu korrigieren und die Doku ist auch oft ungenügend. Ich habe mehrmals erlebt, dass der Entwickler obersten Turm-Abschnittes im Problemfall sagt "Die Fehlerursache ist weiter unten, wir müssen warten", sich dann aber nicht um die Lösung des Problem kümmert. Und der nächste Entwickler darunter sagt "Ich habe mein Projekt längst aufgegeben" oder "Ich habe einen tollen Workaround, den kannst du aber mit seinem Super-Framework oben drauf nicht anwenden". So zumindest habe ich es im Java Enterprise Umfeld oft erlebt, auch mit Frameworks die kommerziellen Support haben. Dann muss man selber Hand anlegen, das geht aber auch nicht, wenn der Turm so komplex geworden ist, dass ich ihn nicht durchblicke. Es geht auch nicht, wenn beim Buildvorgang automatisch Libraries dazu geladen werden, deren Quelltexte ich nicht ändern kann.
StefanUs schrieb: >Ich habe mich nicht getraut zu widersprechen, weil ich PlatformIO noch >nicht wirklich ausprobiert habe. Als ich mir dessen Konzept durchgelesen >hatte, war mein erster Eindruck, dass es sich hier wohl wieder nur um >ein weiteres Framework handelt, das auf ein Framework (Arduino) >aufsetzt, dass wiederum auf ein Framework (HAL) aufsetzt, dass auf CMSIS >aufsetzt. Hier ist das Repo von PlatformIO https://github.com/PlatformIO Interessant in der Übersicht: RiscV ist drinn ! Ihre Mission ist wohl, möglichst viele Mikrocontroller unter einem Dach zu vereinen. Die Qualität ist wohl deshalb hoch, weil auch Geld damit verdient wird. Es gibt Bezahlversionen. Vielleicht ist das die grundlegende Voraussetzung: Irgendwo muss Geld fließen, damit sich einer die Mühe macht, die Software aufzuräumen. So richtig ist mir deren Softwarestruktur und welchen Core sie nutzen, nicht klar. Hier sehe ich "maple": https://github.com/platformio/platform-ststm32/tree/develop/builder/frameworks/arduino
Angehängte Dateien:
-
platformio_stm32.png
19 KB
Sepp schrieb: > So richtig ist mir deren Softwarestruktur und welchen Core sie nutzen, > nicht klar. Kannst dir aussuchen, siehe Bild
Ah, danke, das wusste ich nicht. Hier ist die Diskussion, welche "Cöre" sie für die STM32 einbinden wollen: https://github.com/platformio/platform-ststm32/issues/76 PlatformIO ist damit sozusagen eine "Verwaltungsplatform".
Zusammenfassend muss ich sagen, dass es immer noch bei manchen Unterscheidungsprobleme zwischen der Arduino API und Arduino IDE gibt. Die API kann man einbinden, wo und wie man will: Arduino IDE, PlatformIO, Sloeber oder sich gleich ein Eclipse Einbettung selbst strickt. Anfangs würde ich eher davon abraten oder zumindest bei Problemen den Code auf der Arduino IDE ebenfalls testen. (v.a. Sloeber macht (machte?) noch einige Probleme mit den linker scripts) Zu Rogers Core: Libmaple hat nur fast ein Jahrzehnt am Buckel und wurde verbessert und weiterentwickelt. Ok, F4 ist rudimentär, F7 geht gar nicht. F1 ist dafür auf höchstem Niveau. V.a. ist es keine One-man-show, viele der ursprünglichen Mitglieder sind immer noch aktiv dabei und im Laufe der Zeit sind neue, durchaus helle Köpfe dazu gestoßen (und geblieben!). Dementsprechend ist der Support auf für Umsteiger und auch Anfänger: Ein "echter" Bug wird sofort erkannt und in Angriff genommen (ist nahezu ein Volkssport geworden)- für einfache Probleme gibt es ein gutes Wiki und nahezu sofortige Hilfestellung im Forum. Natürlich gibt es hie und da noch Problemchen (v.a. I2C - aber das dürfte auch einigen reinen CMSIS Benutzern Kopfschmerzen bereiten -> Bug in Hardware) Zu Arduino HAL hab ich mich ja bereits geäußert.
Kleine Offtopic Ergänzung: Die Chancen stehen erstmals gut, dass es ein "echtes" Community Board in Serienanfertigung geben wird. Als Hersteller hat sich ein Mitarbeiter von RobotDyn (chinesischer Hersteller, der u.a. Arduino kompatible Boards und Erweiterungen macht, jedoch auf besserem Niveau als der Rest) zu Wort gemeldet, der Interesse zeigt. Mehr dazu: http://www.stm32duino.com/viewtopic.php?f=3&p=48770#p48770
Hier mal eine Frage an die STM32-Experten: Der offizielle Core von STM und der inoffizielle STM32Generic Core sind beide HAL-bassiert. Die Struktur im Systemordner, wo sich diese Dateien vermutlich befinden sollen, ist völlig unterschiedlich. https://github.com/stm32duino/Arduino_Core_STM32/tree/master/system https://github.com/danieleff/STM32GENERIC/tree/master/STM32/system/ Jetzt frage ich mich, warum? Könnte es sein, das es bei STM irgendwann einmal einen Versionssprung in CubeMx gegeben hat, bei dem die Verzeichnisstruktur umgeordnet wurde? Eigentlich wäre es viel praktischer, wenn die Verzeichnisstrukturen gleich sind, dann könnte man vermutlich sehr leicht die Unterstützung für neue Architekturen hinzu fügen.
Sepp: Du hast völlig recht und das hat mich auch total narrisch (um es
wienerisch zu sagen) gemacht. Warum Frederik ("offizieller" Core) nicht
die Struktur von libmaple/genericcore übernommen hatte, weiß ich nicht.
Das ist einer der Gründe, warum es kaum Mitglieder gibt, die beide HAL
cores unterstützen, weil es zuviel Aufwand ist mit zwei völlig konträren
Strukturen zu arbeiten.
Die Frage ist nur: welchen Grund hat es? Irgend was muss die Umsortiererei ja bringen.
Es muss keinen Grund geben, weil es diesbezüglich keine Vorgaben gibt. Wenn der STMCore von der Picke auf neu geplant wurde (was ich denke), dann kann es sein, dass den Programmieren (bzw. Frederik) seine Struktur "logischer" vorgekommen ist. Darüber hinaus gibt es zwischen generic und STMcore doch Unterschiede: Ansätze dazu gibt es hier zu finden: http://www.stm32duino.com/viewtopic.php?f=48&t=2098 No more static libraries for the HAL. By modifying the stm32YYxx_hal_conf.h in the variant, it is possible to enable or disable HAL features. CMSIS is no more include in the source, it a package dependency and use the one package by Arduino: CMSIS 4.5.0. ARM gcc toolchain has been updated to 6-2017-q1-update version to support F7 family (cortex-m7) but for other families the 4.8.3-2014q1 version still valid.
Dazu der Vergleich von DanielEff (genericcore): http://www.stm32duino.com/viewtopic.php?f=51&t=1966 * Highlight is that USB Serial was working on 103s, on the 407VE, and on L0538-disco (did not test other boards), using the same code. * tools and a few generic files shamelessly copied from stm32duino * HAL from STM32 for every series, selecting the right one is with simple ifdefs. Blink should compile on every chip now. * The implementation as of now is only a light wrapper on HAL (not code from the official core) * Make it work first (with HAL), make it fast/small later (with register access on a case by case basis) * Edit: No SPI I2C ADC / PWM yet... Although Serial UART is, and based on it, if the API is mostly the same for every series (I think yes), they should not be hard. these are in testable state * No precompiled-staticlibrary stuff thingy * Make variants (folder) as light as possible, so a new one can be easily added. Clock setup and pin list and thats it (and unfotunately ldscript). The chip-related peripheral settings are not in variant. (But variant should be able to override defaults.) * Generated the chip related peripheral setup from cubemx .xml files * Did not yet rearrange the pins * Make a script to compile blink & others to see if everything compiles on every variant. Also zwei Varianten, die zwar beide auf HAL basieren, aber unterschiedlicher nicht sein können.
Vielleicht ist meine Kritik am STM-Core unbegründet und ich mache irgend was falsch. Der Generic-Core hat z.B. Interrupt-Timer Funktionen. Die sehe ich im STM-Core nicht. Viele Boards haben einen DAC und I2S. Das sehe ich auch nicht im Offical.
Sepp: Nö, glaube nicht, dass du etwas falsch machst, Timer, DAC, I2S und USB werden noch nicht unterstützt. USB dürfte recht bald kommen (auch für Bluepill). Die I2S Implementation im GenericCore ist Käse, habe eh schon ein Issue auf Github veröffentlicht, wenn ich Zeit habe, schreibe ich eine I2S Funktion selbst mit Circular Buffer +DMA (half/complete full), alles andere ist einfach der vollkommen falsche Ansatz
>Autor: Johannes S. (jojos) >Datum: 01.09.2018 12:05 >Stefanus F. schrieb: >> Ganz ehrlich, was die Chiphersteller da seit Jahren fabrizieren ist ein >> schlechter Witz. Die wollen einfach nur ihre Chips verkaufen. >Natürlich wollen die ihre Chips verkaufen, die produzieren soviele das >sie es sogar tun müssen... >Die Dinger sind so komplex geworden das es nicht reicht einen Chip und >ein 1000 seitiges Handbuch dazu zu liefern. Der Markt ist heiß umkämpft >und der Support seitens der Hersteller ist einfach ein Mehrwert für den >Kunden, so kann man das auch sehen. Für die ganzen Tools und Libraries >hat man noch vor wenigen Jahren mehrere k€ auf den Tisch legen müssen, >heute kostet dich das nur noch eine Registrierung. Und das böse 'vendor >lock-in' juckt da auch keinen mehr, die STM32 oder NXP Palette ist so >gross das man gar nicht einen Hund aus jedem Dorf braucht. Das ist >einfach erfolgreiches Marketing und da man auch als Bastler alles für >Nüsse bekommt sind soche Beschwerden völlig unnötig. >Zum Thema cores: das ist Open Source und da haben freiwillige >Unterstützer viel Zeit reingesteckt. Die Projekte leben vom mitmachen, >testen und Fehler melden, nicht vom beschweren über deren Fehler. Übrigens ist die Arduino-HAL genau das Argument gegen das "vendor lock in". Sie abstrahiert nämlich vom Prozessor und zwar herstellerunabhängig. Die MCU wird damit weitgehend austauschbar, nur die oberste Schicht, die Arduino API muss stimmen. Insofern wundert es mich eigentlich, dass STM die Arduino API unterstützt.
Eigentlich beantworten sich die hier gestellten nicht technischen Fragen über den Arduino von alleine. 1.) Die Arduino AVR IDE funktioniert annähernd fast Fehlerfrei, dank der Grundlage Prozessing. 2.) Dank diese Prozessing Grundlage gibt es viele Millionen Menschen die damit sehr einfach ihre Projekte realisieren ohne erst einmal ein Studium abzulegen. Das zeigt auch der Umsatz von AVR Produkten bei dieser Gruppe. Dazu gehöre ich auch. Viele die sich die Grundlagen mit Arduino erarbeitet haben steigen auch in den Profibereich um und verdienen heute ihr Geld damit. Was ohne Arduino nie passiert wäre. 3.) Das AVR Grundgerüst, was von den Arduino Machern entwickelt wurde funktioniert ziemlich gut. 4.) Was Seegen und Fluch zu gleich ist, mit den GCC Compiler lassen sich die verschiedensten CPU Hersteller unterstützen. 5.) Freeware mit freien Code lässt nun mal die schlimmsten Blühten entstehen. Und da sind die freien Programmierer selber gefragt, wie schlimm Sie die Grundidee von Arduino versaubeuteln. 6.) All diese Gründe sorgen auch dafür, das einige Profis meinen, die Arduino IDE sei murks. Schließlich wollen diese Gattung keine so einfache Konkurrenz haben. Dieses Thema wurde auch in der letzten MAKE angesprochen und ist meine persönliche Erfahrung, nach dem ich einige Beiträge gelesen habe. Beim Thema Arduino geht das Lamentieren los, warum, weshalb, es geht doch anders viel besser, u.s.w. und das eigentliche angesprochene Thema verschwindet. Es wäre schön, wenn die Profis die von Arduino, nach Eigenaussage keine Ahnung haben, dieses für sich behalten oder sich ein Auskotz-Forum suchen. Ich persönlich, möchte etwas mit Arduino lernen, und das ist bestimmt nicht, das alles nur schei.. ist. Und alles andere ist besser. Für mich persönlich ist Arduino die richtige Plattform und Probleme sind dafür da, um gelöst zu werden. Wir leben doch in einem Freien Land, da kann doch jeder für sich handeln wie er möchte. Und Missionare gibt es schon genug auf dieser Welt. Nette Grüße Siegfried
:
Bearbeitet durch User
Siegfried S. schrieb: > Es wäre schön, wenn die Profis die von Arduino, nach Eigenaussage keine > Ahnung haben, dieses für sich behalten oder sich ein Auskotz-Forum > suchen. Also hier. Hier ist der landesweite Stammtisch der Elektroniker. Ich kenne keinen anderen, der nicht spezifisch für bestimmte Produkte ist. Wer die Meinung von nicht-Arduino Leuten nicht lesen will, der ist wohl besser im Arduino Forum aufgehoben. Ich denke jedoch, dass so mancher Arduino User hier fragt, weil er eben doch Interesse an dem Know-How außerhalb des eigenen Tellerandes hat. > Wir leben doch in einem Freien Land, da kann doch jeder > für sich handeln wie er möchte. In einem freien Land sollte man sich auch frei äußern dürfen. Ganz besonders in öffentlichen Diskussionen.
Es betrifft nicht nur Arduino: Ich muss zugeben, dass ich kaum noch in diesem Forum bin, alleine aus Zeitgründen. Grund: Ich bin nicht gewillt, wenn jemand eine konkrete(!) Frage gestellt hat, dass hier gleich mal 10 Besserwisser pauschal irgendetwas für "Scheiße" zu empfinden ohne auf die eigentliche Frage einzugehen oder einen anderen Lösungsansatz zu bieten. So etwas erwarte ich einfach von einem Sachforum nicht. Alle die sich für STM32 + Arduino interessieren und Englisch können, empfehle ich das Forum auf stm32duino.com
Matthias D. schrieb: > Alle die sich für STM32 + Arduino interessieren und Englisch können, > empfehle ich das Forum auf stm32duino.com Wenn man andere Meinungen nicht hören will ist eine Filterblase natürlich die Lösung :-D
Matthias D. schrieb: > Alle die sich für STM32 + Arduino interessieren und Englisch können, > empfehle ich das Forum auf stm32duino.com bessere Foren gibt es mittlerweile für alle Fachthemen wie Mechanik, Raspberry, Modellbau, Programmierung usw. Siegfried S. schrieb: > 5.) > Freeware mit freien Code lässt nun mal die schlimmsten Blühten > entstehen. > Und da sind die freien Programmierer selber gefragt, wie schlimm Sie die > Grundidee von Arduino versaubeuteln. als Arduino erfolgreich wurde waren die Macher aber nur noch mit Geld zählen beschäfftigt und haben sich gegenseitig bekriegt anstatt das marode API oder den spartanischen Editor zu verbessern. Das war alles nur auf die Atmel AVR getrimmt, Weitsicht oder Visionen waren da nicht zu erkennen. Die ganzen Weiterentwicklungen für STM32 und ESP kommen doch von freiwilligen Unterstützern, nicht von den Arduino Autoren!
Nein, wenn man den Scheißdreck der Besserwisser, die es nicht auf die Reihe bekommen zu kapieren, was eine konkrete Frage ist, nicht hören will ist es die Lösung. In diesem Sinne, bin ich mal draußen aus diesem Beitrag.
Siegfried S. schrieb: > Eigentlich beantworten sich die hier gestellten nicht technischen Fragen > über den Arduino von alleine. Kannst du mir mal helfen? Irgendwie finde ich in diesem Faden keine Fragen, zu denen deine Antworten passen würden. > 1.) > Die Arduino AVR IDE funktioniert annähernd fast Fehlerfrei Sapperlot! Reicht es heutzutage schon, wenn ein Stück Software "annähernd fast Fehlerfrei funktioniert" (Rechtschreibfehler vom Original übernommen) damit sich eine Fanbasis bildet? > 2.) > Dank diese Prozessing Grundlage gibt es viele Millionen Menschen die > damit sehr einfach ihre Projekte realisieren ohne erst einmal ein > Studium abzulegen. Viele Millionen? Das dürfte Faktor 100 zu hoch gegriffen sein. > 3.) > Das AVR Grundgerüst, was von den Arduino Machern entwickelt wurde > funktioniert ziemlich gut. Du meinst wohl: der Arduino Core für AVR ist weitgehend vollständig und fehlerfrei. Stimmt. Auch das ist aber nur der Mindeststandard. Daß es für STM32 anders aussieht, hast du ja nun selber herausgefunden. > 4.) > Was Seegen und Fluch zu gleich ist, mit den GCC Compiler lassen sich die > verschiedensten CPU Hersteller unterstützen. Was auch immer das mit Arduino zu tun hat. Die Arduino-Leute haben schlicht gar keine Aktie an gcc. Sie nutzen den gcc nur als Unterbau (was auch vollkommen in Ordnung ist) > 5.) > Freeware mit freien Code lässt nun mal die schlimmsten Blühten > entstehen. Verwende doch bitte(!) eine Rechtschreibprüfung. Da tun einem ja die Augen weh beim Lesen. > Und da sind die freien Programmierer selber gefragt, wie schlimm Sie die > Grundidee von Arduino versaubeuteln. Was auch immer du damit sagen willst. > 6.) > All diese Gründe sorgen auch dafür, das einige Profis meinen, die > Arduino IDE sei murks. Ich habe das noch nirgends gelesen oder gar selber geschrieben. Wahr ist allerdings, daß die Arduino IDE so ziemlich das Minimum enthält, um überhaupt als IDE durchzugehen. Was auch du sehen könntest, wenn du dir mal eine ausgewachsene IDE wie Eclipse, Code::Blocks oder Visual Studio angesehen hättest. In meinen Augen ist sogar ein schlichter Editor wie Emacs oder vim komfortabler als die Editorkomponente der Arduino "IDE". > Es wäre schön, wenn die Profis die von Arduino, nach Eigenaussage keine > Ahnung haben, dieses für sich behalten oder sich ein Auskotz-Forum > suchen. Es wäre noch schöner, wenn Arduino-Fanboys wie du sich auf die Arduino-Foren beschränken würden. > Wir leben doch in einem Freien Land, da kann doch jeder für sich handeln > wie er möchte. Klar. Nur kannst du nicht einfordern, deine Meinung haben zu dürfen, wenn du mir gleichzeitig meine Meinung verbieten willst. > Für mich persönlich ist Arduino die richtige Plattform und Probleme sind > dafür da, um gelöst zu werden. Ist halt nur blöd, wenn der Arduino Core selber das größte Problem ist. Arduino ist ein klassischer walled garden. Alles ist super(einfach), so lange du dich in den vorgesehenen Grenzen bewegst. Aber wehe du willst etwas, was außerhalb der Mauern liegt. Dann geht gar nichts mehr.
Axel S. schrieb: >> All diese Gründe sorgen auch dafür, das einige Profis meinen, die >> Arduino IDE sei murks. > Ich habe das noch nirgends gelesen Ich schon. Das früher oder später fast immer, nachdem das Stichwort Arduino gefallen ist. Ich beobachte aber auch, dass die Sichtweise zunehmend von schwarz/weiß in Graustufen über geht. Die Benutzer der sonst üblichen Entwicklungsumgebungen verstehen zunehmend, dass es auch Leute mit anderen Bedürfnissen gibt, welche mit der Arduino IDE zufrieden sind. Die selbe Problematik hat man überall, wo Werkzeuge und Material verarbeitet werden. Ich besitze zuhause zum Beispiel immer noch keinen Akkuschrauber und fühle mich dabei wohl. Und ich lackiere dort alles mit Acryl Farben, trotz ihrer Nachteile. Dass andere Leute mit anderen Werkzeugen und anderem Material schneller und besser arbeiten können, ist mir durchaus bewusst. Trotzdem bleibe ich dabei. Ich darf das, ich bin über 40 :-) Auf der Arbeit sieht das schon anders aus, dort bin ich jedoch nicht Handwerker, sondern Java Entwickler. PS: Die Editor-Komponente der Arduino IDE finde ich auch nicht gut. Zum Glück hat man die Freiheit, andere Editoren zu benutzen.
Axel S. schrieb: > Aber wehe du willst etwas, was außerhalb der Mauern liegt. Dann geht gar > nichts mehr. Das stimmt so einfach nicht!! Ich habe jahrelang mit AVR und GCC gearbeitet. Auf die Arduinos bin ich gekommen, weil einfach der Preis super ist. Und weil es sehr einfach nachbaubar ist, für fast jederman. Für einfache Sachenreicht das Arduino Zeugs. Und wenn es speziell wird oder zeitkritisch, dann kann man einfach auf die herkömmliche Schiene wechseln. Die Arduino IDE versteht alles, was bei der herkömmlichen Programmierung der AVR geht. Registernahmen, einfach alles. Man kann auch sehr einfach beides kombinieren, dann muss man halt wissen, was der Arduino wie und wann verwendet.
Thomas W. schrieb: > Ich habe jahrelang mit AVR und GCC gearbeitet. > > Auf die Arduinos bin ich gekommen, weil einfach der Preis super ist. > Und weil es sehr einfach nachbaubar ist, für fast jederman. Dann bist du mit AVR & GCC aber scheinbar nicht besonders weit gekommen, da du sonst keinen Grund gehabt hättest auf die Arduino-Schiene zu wechseln.
Harry L. schrieb: > Dann bist du mit AVR & GCC aber scheinbar nicht besonders weit gekommen, was nicht Schlimm ist.
Thomas W. schrieb: > Man kann auch sehr einfach beides kombinieren, dann muss man halt > wissen, was der Arduino wie und wann verwendet. Das ist ja auch vorgesehen. Ich hatte bisher nur wenig Kontakt mit Arduino, dafür meistens keinen guten. Letztens wollte ich schnell ein NUCLEO-L432KC in Betrieb nehmen. Dann stellte sich heraus, dass die serielle Schnittstelle nicht funktioniert. Es zeigte sich, dass erst gar nichts auf den Pins gesendet wird. Nach einer Stunde Fehlersuche habe ich das Projekt in deutlich kürzerer Zeit mit eigenen Bibliotheken aufgesetzt gehabt. Mein Fazit: Wenn was mal nicht funktioniert, sucht man deutlich länger nach Fehlern. Ich finde für kleine Projekte mit gut unterstützten Plattformen kann Arduino durchaus sinnvoll sein. Für größere Projekte sehe ich keinen Sinn, weil das Schreiben einer angepassten HAL nur einen Bruchteil der Zeit des Projekts beansprucht. Oftmals braucht man auch Funktionen von Peripherie, die nicht unterstützt wird.
avr schrieb: > Wenn was mal > nicht funktioniert, sucht man deutlich länger nach Fehlern. Das ist die Krux bei allen Frameworks, ganz besonders bei Frameworks die auf anderen Frameworks aufbauen. Es ist viel einfacher, selbst gemachte Fehler zu korrigieren, als ein kaputtes Framework zu reparieren. Sich für ein Framework zu entscheiden, ist immer mit hohem Risiko verbunden. Ich habe in Unternehmen oft erlebt, dass man die Entscheidung viel zu leichtfertig fällt.
Nur noch einmal zum Verständnis: Außer ein paar Ausnahmen bedeutet für das Arduino Team, [ Arduino ist ATMEL ], alles andere sind irgendwelche Benutzer selber. Das heißt, wer sich ein Kombi schenken lässt, sollte sich nicht beschweren, das er kein LKW bekommen hat. Wenn dieses Konzept nicht so gut gewesen wäre, wär bestimmt niemand auf die Idee gekommen, dieses Gerüst für andere CPU Plattformen zu nutzen. Das es dabei Halbheiten gibt, sollte man in kauf nehmen können, wenn eine andere CPU als die von ATMEL benutzt werden soll. Sonst bleibt einem, der Profibereich mit Studium. Grundsätzlich ist die Arduino IDE für AVR Prozessoren in der Lage Code mit Main, CPU-lib (Also reiner C Code) und ohne Setup und Loop zu erstellen. Habe ich selber ausprobiert. Somit kann die Arduino IDE alle Funktionen zur Code Erstellung, wie die Profi IDE's. Mit Debugger habe ich noch keine Erfahrung, gehört aber nicht zum compilieren sondern zum Fehler suchen. Grundsätzlich gibt es keine Komplexe Software ohne Fehler. Somit haben alle IDE's irgendwelche Probleme. Und wenn es der Compiler ist, der bei vielen IDE's GCC heißt. Somit kann auch die Anfangsfrage gut beantwortet werden. Je nach dem, welche STM32 Plattform mit dem Boardmanager zur Arduino IDE hinzu geführt worden ist, sind die Arduino Funktionen mehr oder weniger gut vorhanden. Aber von Prinzip von Arduino, können fehlende Funktionen in der Library hinzu gefügt werden, soweit diese fertig gefunden werden oder selbst programmiert sind. Nach diesem Prinzip können vorhandene Funktionen auch mit bessere Funktionen ersetzt werden. Also die Arduino Idee lebt mit Ihren Benutzern und Programmieren. Auch diesmal habe ich wieder Rechtschreibfehler im Text. Extra für die, die danach suchen. Nette Grüße Siegfried
:
Bearbeitet durch User
Siegfried S. schrieb: > Somit kann die Arduino IDE alle > Funktionen zur Code Erstellung, wie die Profi IDE's. Was sind für dich Funktionen zur Code-Erstellung? Was man kompileren kann, hängt vom Compilier ab, nicht von der IDE. Bezüglich der Funktionen der IDE ist, wie schon erwähnt wurde, diese ganz schlecht dabei. Gibts inzwischen wenigstens Autovervollständigung? Profi IDEs biete u.a. Navigation im Code, Refactoring, Macro Expansion, Syntax Checks zur Laufzeit... - schau mal bei den Features von Visual Studio rein. Das ist kein Vergleich zur Arduino IDE. > Grundsätzlich gibt es keine Komplexe Software ohne Fehler. Somit haben > alle IDE's irgendwelche Probleme. Und wenn es der Compiler ist, der bei > vielen IDE's GCC heißt. Der GCC ist mit Sicherheit die letzte Fehlerquelle - nicht nur bei Ardunio.
avr schrieb:
Profi IDEs biete u.a.
Hallo: Arduino IDE war und ist keine Profi IDE.
Aber wenn du Arduino mit entwickelst könnte es ja noch etwas werden.
Siegfried schrieb: >Nur noch einmal zum Verständnis: Außer ein paar Ausnahmen bedeutet für >das Arduino Team, [ Arduino ist ATMEL ], alles andere sind irgendwelche >Benutzer selber. Das heißt, wer sich ein Kombi schenken lässt, sollte >sich nicht beschweren, das er kein LKW bekommen hat. Ich würde nicht sagen, dass Arduino Atmel ist. Die meisten Prozessoren, die sie verwenden, sind von Atmel. Aber ganz kurz gab's auch mal den Arduino-Otto ( STM32 ). Sehr erhellend ist "The untold history of Arduino" https://arduinohistory.github.io/ Das kann ich jedem mal empfehlen zu lesen. Auch denen, die alles was mit Arduino zu tun hat, ablehnen. Dort sind die Auf's und Ab's beschrieben und auch die Intrigen und Machtkämpfe, die es normalerweise bei solch erfolgreichen Projekten gibt. Letztendlich kann man sagen, das "Arduino" längst mehr ist, als das was die eigentliche Firma darstellt. Wenn man es genau nimmt, ist es eigentlich die im Dokument beschriebene Wiring-API so wie sie auch auf dem ESP8266 zu finden ist, der nun gar nichts mit der Firma "Arduino" zu tun hat. Das meiste, was sich Arduino nennt, hat sich längst von der Firma oder deren Markenname gelöst. Es ist schlicht eine prozessorübergreifende HAL, die auf sehr vielen unterschiedlichen Prozessoren existiert und die es ermöglicht, ohne großen Einarbeitungsaufwand zwischen den Architekturen wechseln. Der Mikrocontroller macht damit eine ähnliche Entwicklungsgeschichte wie der PC durch: Es entsteht eine Art BIOS das die Architekturen vereinheitlicht und bei dem die Benutzer nicht an den Registereinstellungen der Soundkarte oder den Befehlssatz von Intel oder AMD gebunden sind.
Per Zufall bin ich darauf gestossen, dass es neuerdings einen STM32 Arduino gibt http://www.theorycircuit.com/arduino-star-otto/ Das lässt die Hoffnung steigen das es ev. weitere "out of the box" Versionen geben wird.
Johnny S. schrieb: > Per Zufall bin ich darauf gestossen, dass es neuerdings einen STM32 > Arduino gibt Es gab vorher auch schon einen: Maple Mini Dieses Otto Board kommt aber genau wie das Maple Mini nicht von Arduino.cc (siehe https://www.arduino.cc/en/Main/Products) und ist daher genau so wenig "offiziell" wie das, was wir bereits vorher hatten. Mit welchem Core es programmiert werden soll, steht da auch nicht. Vermutlich bekommst du da also nur ein Stück Hardware ganz ohne Software-Support.
Stefanus F. schrieb: > Johnny S. schrieb: >> Per Zufall bin ich darauf gestossen, dass es neuerdings einen STM32 >> Arduino gibt > > Es gab vorher auch schon einen: Maple Mini > > Dieses Otto Board kommt aber genau wie das Maple Mini nicht von > Arduino.cc (siehe https://www.arduino.cc/en/Main/Products) und ist daher > genau so wenig "offiziell" wie das, was wir bereits vorher hatten. Mit > welchem Core es programmiert werden soll, steht da auch nicht. > Vermutlich bekommst du da also nur ein Stück Hardware ganz ohne > Software-Support. Das stimmt nicht ganz so! Code, also die Board-Files in der IDE stammen nicht von Arduino. Die Daten für den Star-Otto aber schon, was bedeuted das der Code von Arduino stammt, oder zumindestens soweit überprüft worden ist das Arduino ihn unter dem offiziellen namen anbietet.
Arduino für stm32f1 läuft schon ewig. Auch die meisten libraries laufen problemlos für AVR, esp und stm32
Sepp schrieb: > Sehr erhellend ist "The untold history of Arduino" > https://arduinohistory.github.io/ kann ich nur bestätigen. Ist auch in mehreren Sprachen da.
Die Intention der Arduino-Entwicklung erinnert mich ein wenig an die Entstehungsgeschichte von Python, die ja einen ähnlichen Erfolg hat. Mittlerweile ist Python in der Wissenschaft mit SciPy ziemlich weit verbreitet. Im Grunde hat Arduino die selbe Philosphie wie die des Python Gründers. Sie ist der Wikipedia beschrieben: >Beautiful is better than ugly >Explicit is better than implicit >Simple is better than complex >Complex is better than complicated >Readability counts https://en.wikipedia.org/wiki/Python_(programming_language)
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.