Als Fork von diesem Thread
Beitrag "Re: Erfahrungen mit ChibiOS & ChibiStudio auf STM32Fxxx" habe ich
mal ein neues Thema aufgemacht um den anderen Thread nicht zu kapern.
Es ging um ein ein OS und eine IDE für STM32 und mein Vorschlag war mbed
zu benutzen. Das ist ein mittlerweile sehr umfangreiches OS von ARM
(Keil) und ist im letzten Jahr massiv weiterentwickelt worden.
Die mbed Website zeigt schöne Bilder und viele Buzzwords und damit
meiner Meinung nach nicht das ganze Potential das dahinter steckt. mbed
verbinden viele sofort mit dem Online Compiler den man lieber nicht
benutzen möchte. Aber das ist nur ein Teil von dem grossen Ganzen und
mittlerweile ist die Nutzung per Command Line Interface vereinfacht und
gut ausgebaut worden. Ich arbeite am liebsten in einer IDE incl.
Debugger, und um da ein Projekt per mbed-cli zu erzeugen sind nur wenige
Schritte nötig.
Die 8 Bitter nutze ich kaum noch und Arduino war anfangs ja auf die AVR
beschränkt. Das hat sich geändert, mit STM32duino und dem Import der
ESPs kann man die Arduino Libs auch auf anderen Plattformen nutzen. Die
Entwicklung ist aber sehr verteilt und nicht einheitlich, ich persönlich
halte mbed für das 'bessere' Arduino. Wobei ich durchaus Arduino nutze,
z.B. im 3D-Drucker. Und auch Arduino Code lässt sich oft mit wenigen
Anpassungen für mbed verwenden, selbst die Anpassung einer TFT Grafik
Lib mit FSMC hat mich gerade mal 2 lange Abende Zeit gekostet (ist aber
noch im Teststadium).
mbed stammt aus dem Hause ARM, wurde für den LPC1768 als Urvater
entwickelt und dann wurde die Unterstützung für alles was einen Cortex-M
core hat weitergeführt. Es werden viele Evalboards von NXP, STM, Nordic,
Atmel usw. unterstützt, die Lister der offiziellen Targets findet man
auf der mbed Website. Dazu kommen weitere die per mbed-cli genutzt
werden können, das ist im folgenden beschrieben.
Peter schrieb:
> Aber bietet MBED auch eine IDE als lokale Installation an? (Vorzugswese> für Windows und Linux)
ja,
das geht mit dem mbed-cli (command line interface). Für Windows gibt es
einen Installer der die Toolchain, Python und nötige Python Libs in
einem Rutsch installiert. Für Linux muss man sich durch die Anleitung
hangeln, ist aber auch nicht kompliziert weil nur Standard Pakete
benutzt werden.
Dann startet man z.B. mit dem mbed-os-blinky (für die fetteren F4/F7),
https://github.com/ARMmbed/mbed-os-example-blinky auf den lokalen
Rechner clonen. Der ganze Ablauf ist auf der blinky Seite beschrieben:
1
mbed import mbed-os-example-blinky
2
cd mbed-os-example-blinky
3
mbed compile -t GCC_ARM -m DISCO_F407VG
Der import holt den code aus dem git oder mercurial repo und fügt die
Library mbde-os hinzu. Das sind einige MegaBytes weil die immer für alle
Targets ist und der Download dauert etwas.
Dann compiliert man z.B. den Code für ein STM Dicovery F407 oder anderes
Target, eine Liste bekommt man wenn man für -m etwas ungültiges wie XX
angibt. Auf der mbed Site unter Hardware sind nur die offiziellen 'mbed
enabled' boards gelistet, aber man kann per mbed-cli auch andere
benuzten. Z.B. das beliebte Bluepill mit dem F103. Das läuft aber besser
mit dem mbed2, ein Projekt kann man so erstellen:
per mbed export kann man dann eine Projektconfig für seine Lieblings IDE
oder für ein makefile schreiben wenn man nicht mit 'mbed compile'
arbeiten möchte.
Ich wollte hierzu immer mal einen Artikel ins Wiki schreiben, vielleicht
fange ich am WE mal an.
Es wird aktuell eine auf Eclipse basierende Mbed IDE entwickelt:
https://os.mbed.com/studio/
Inzwischen ist die Entwicklung mit Mbed und stm32 Mikrocontrollern
wirklich sehr einfach und es gibt immer mehr fertige Libs für
verschiedene Sensoren.
Ich finde es ist für Anfänger besser wenn sie mit Mbed starten statt mit
Arduino.
Mit Mbed beginnt man direkt mit einer modernen Mikrocontroller Familie.
Bei Arduino muss man früher oder später umsteigen und umlernen. Ok man
muss nicht, aber wenn man leistungsfähigere Mikrocontroller benötigt
oder langfristig etwas kommerzielles plant dann kommt irgendwann der
Umstieg von Arduino.
Und die Entwicklung von Mbed ist wirklich sehr aktiv und schnell.
Regelmäßig erscheinen neue Versionen.
Die letzte gestern:
https://os.mbed.com/blog/entry/Mbed-OS-58-release/
Ich denke ARM ist dabei ein Mbed Ökosystem zu schaffen. Langfristig
könnte das die Arduino Community unter Druck setzen.
Wobei ja aber auch nichts dagegen spricht das Arduino Plattform
verstärkt auf 32bit Mikroncontroller auszubauen.
Hallo,
es wird wohl vorerst immer eine Diskrepanz zwischen dem Konzept Arduino
und allen anderen IDEs geben.
Will man einsteigen weil man es beruflich oder in größerem umfang privat
dauerhaft braucht, ist der Vorschlag und die Begründung 100% zutreffend.
Ist allgemein Elektronik Hobby oder Modelbau oder Modellbahn o.ä. Hobby
und man kommt zu µC weil sie helfen können, ein Vorhaben zu realisieren,
wird das Konzept Arduino gewinnen.
10 Minuten zum Runterladen und Installieren der IDE. Ein USB-Kabel an
den "Arduino" stecken, das Board und die Schnittstelle auswählen, ein
Beispiel laden, kompilieren und flashen.
Ein Projekt gefunden? Bibliothek fehlt? Von gitHub runterladen,
Bibliothek als ZIP einbinden, neuer Versuch - klappt (wenn man Glück
hat...).
Mach das mal z.Z. mit irgendeiner anderen "Umgebung".
Für eine "Arduino"-Schrankensteuerung der Modellbahn erstmal schauen was
ein Compiler ist, was es mit Makefile und Linkerfile und... auf sich
hat?
Herausfinden, wo das Dateisammelsurium einer Bibliothek in welche Ordner
verteilt werden muß und wo die sind?
Sicher gut zu wissen. Was macht obiger Gelegenheitsbastler wenn das
nächste Fundstück statt des AVR einen ESP8622 benutzt? Nächste
IDE-Einrichtung, alles von vorn? Oder eine URL ind die ArduinoIDE
kpieren, ESP-Paket dazu installieren, Board ist jetzt in der Auswahl,
also auswählen, kompilieren, flashen.
Das ist im Moment der große Vorteil von Arduino, das Konzept.
Ich kann ohne nachdenken auch Plain C oder C++ drin machen, kann auf die
SDK-Funktionen direkt durchgreifen und diese nutzen usw.
Wenn ich soweit bin (immernoch privat), dann bin ich ohnehin da, wo ein
Umstig auf eine andere IDE eigentlich kein umlernen mehr ist. Dann habe
ich sowieso schon die Finger in den Innereien von Arduino gehbt und
festgestellt: oh, da wohnt ja auch nur ein GCC drunter, da läuft ja auch
nur ein AVRDude oder das Espesssif-Python-Tool zum Flashen.
Ich kann das alles, wenn ich will, muß es aber nicht, wenn ich es nicht
wirklich brauche und nutzen will.
Gruß aus Berlin
Michael
Nichts, nur gerade hier wird online immer = böse gesehen.
Und offline IDE hat den Vorteil das man steppen und analysieren kann.
Danke auch Michael für deinen Beitrag. Mbed ist weil von ARM halt nicht
für andere Plsttformen. Halte ich nur beim ESP für schade, die meisten
für Hobby interassanten kennt mbed schon.
>Was spricht gegen die mbed online Handhabung?
- Editor: code-browsing, auto-complete, etc. ist unbrauchbar
- Compiler: Wenn was nicht compilierbar ist, musst Du
raten an welcher welcher codezeile es liegt
- Debuggen: schlichtweg nicht möglich.
- Export: Wenn mal ein bischen was erarbeitet hast, funzt der
Code-Export
nicht mehr. Er bricht mit einer Fehlermeldung ab mit dem Hinweis man
soll sich beim Support melden. Das habe ich getan aber keine
brauchbare
Hilfe bzw. Lösung erhalten, dem Problem geht auch keiner wirklich
nach.
MBED ist ein Geschwür! Die kaufen alles was erfolgversprechend ist auf
und lassen es versanden um jegliche Konkurrenz auszuschalten:
=> http://www.yagarto.org/
=> http://www.emide.org/
Irgendwann, wenn sie genügend Entwickler und Projekte an der Leine haben
wir es wohl grausam teuer, die wollen schlussendlich auch nur Geld
verdienen.
Ich habe auch den Eindruck, dass diverse MBED Mitarbeiter oder
beteiligte sich hier auf dem Forum herumtreiben und kräftig die
Werbetrommel für MBED rühren wie z.B. Johannes S. (jojos)
Was spricht gegen die mbed online Handhabung?
- Editor: code-browsing, auto-complete, etc. ist unbrauchbar
- Compiler: Wenn was nicht compilierbar ist, musst Du
raten an welcher welcher codezeile es liegt
- Debuggen: schlichtweg nicht möglich.
- Export: Wenn mal ein bisschen was erarbeitet hast, funzt der
Code-Export nicht mehr. Er bricht mit einer Fehlermeldung ab
mit dem Hinweis man soll sich beim Support melden.
Das habe ich getan aber keine brauchbare Hilfe bzw.
Lösung erhalten, dem Problem geht auch keiner wirklich nach.
MBED ist ein Geschwür! Die kaufen alles was erfolgversprechend ist auf
und lassen es versanden um jegliche Konkurrenz auszuschalten:
=> http://www.yagarto.org/
=> http://www.emide.org/
Irgendwann, wenn sie genügend Entwickler und Projekte an der Leine haben
wir es wohl grausam teuer, die wollen schlussendlich auch nur Geld
verdienen.
Ich habe auch den Eindruck, dass diverse MBED Mitarbeiter oder
Beteiligte sich hier auf dem Forum herumtreiben und kräftig die
Werbetrommel für MBED rühren wie z.B. "Johannes S. (jojos)"
Ich bin kein ARM Mitarbeiter und bekomme auch kein Geld von ARM & Co.
für meine Beiträge. Mit mbed habe ich mich schon lange beschäftig und
ich finde es einfach besser als Arduino.
Die online IDE macht für grössere Projekte keinen Spaß, das ist richtig.
Dafür läuft das ad hoc ohne etwas zu installieren auf jedem Rechner.
Zumindest zum Einstieg oder etwas schnell zu testen ist das ok, für mehr
nutze ich das auch nicht.
Deshalb favorisiere ich auch das mbed-cli, Kommandline Interface. Von
hier aus funktioniert auch der Export besser und man hat alles lokal.
Die Exporter wurden lange links liegen gelassen, ich kenne die Roadmap
der Entwicklung nicht aber die Exporter hatten keine Priorität. Mit der
Entwicklung von mbed 5 hat ARM scheinbar mehr Power da rein gesteckt und
es tut sich immer noch eine ganze Menge. Die meisten Exporter werden von
freiwilligen Unterstützern gepflegt, das ist wie bei Open Source üblich
mal mehr oder weniger gut. Den MCUXpresso Exporter habe ich geschrieben
(bzw. aus dem gnu arm eclipse Exporter abgeleitet) weil das LPCXpresso
veraltet ist und da so gut wie gar nix ging. Den Gnu Arm Eclipse
Exporter hat der Liviu Ionescu, der Entwickler von gnu arm eclipse
übrigends dazu beigetragen.
Die Entwickler von mbed reagieren meist sehr freundlich auf die git
contributions.
Wie gesagt, nicht lange mit dem Online Kram aufhalten und mbed-cli
benutzen.
Das einzige was mir persönlich nicht so gut gefällt ist das der Export
immer nicht mehr wie früher ein zip-file anlegt sondern nur das IDE
Projektfile und immer das ganze mbed für alle Targets guckt. Da es sehr
viele Targets gibt ist das mittlerweile sehr groß geworden.
du meinst das hier abarbeiten ...
https://github.com/ARMmbed/mbed-cli
Ich bevorzuge jedoch lieber was mit Fenster statt in der Konsole
rumzutippen.
Ich frage deshalb weil ich schon länger einen Arch Pro von Seeedstudio
rumliegen habe. Irgendwann wollte ich damit etwas rumspielen.
Mike schrieb:> Irgendwann, wenn sie genügend Entwickler und Projekte an der Leine haben> wir es wohl grausam teuer, die wollen schlussendlich auch nur Geld> verdienen.
wohl kaum, mbed = ARM / Keil, die verdienen Geld mit dem Verkauf von
Lizenzen für die ARM cores. mbed ist auf git und das meiste ist frei
nach MIT oder GPL, auch für kommerzielle Nutzung.
Keil verkauft sicher auch gerne seinen Compiler, aber gcc und IAR werden
auch bestens von mbed unterstützt.
Ob das mit Yagarto/emIde stimmt weiss ich nicht, aber es ist eine
Eclipse IDE von mbed angekündigt, da würde so eine Aquise Sinn machen.
Und was ARM nicht kauft das schnappt sich STM ja gerade.
Checker schrieb:> Ich bevorzuge jedoch lieber was mit Fenster statt in der Konsole> rumzutippen.
vom mbed-cli aus kann man ein Projektfile für die IDE erzeugen lassen
und von da an fensterln.
Der Arch Pro ist soweit ich weiss in der Liste der unterstützten
Hardware drin: https://os.mbed.com/platforms/Seeeduino-Arch-Pro/
Da der den LPC1768, den Urvater von mbed drauf hat, müsste auch Ethernet
sofort damit laufen.
Gibt es nichts vergleichbares wie Atmel Studio nur eben für mbed arm? Es
macht doch keinen Sinn in der Konsole ein File zu erzeugen um es danach
in der IDE zu erarbeiten. Das muss doch alles in der IDE funktionieren.
Oder ich habe irgendwas falsch verstanden?
Auch wenn ich mich wiederhole. Welche IDE soll ich für offline nehmen?
Darum geht es doch laut meiner Meinung zur Zeit. Oder funktioniert für
das arch pro Board nur die mbed online Variante?
Es gibt MCUXpresso von NXP, das ist für die LPC und Kinetis Prozessoren.
Einfach zu installieren, aber eben nur mit Support für die NXP Teile.
Dann gibt es als universellere IDE das gnu arm eclipse, aber da muss man
eine Menge zusammensuchen und manuell installieren.
ARM hat eine mbed IDE angekündigt, ist aber noch nicht verfügbar.
https://os.mbed.com/blog/entry/Introducing-Mbed-Studio/
Das mbed-cli ist aber mit wenigen Klicks installiert (incl. Toolchain)
und um ein Blinky für das Arch Pro zu erstellen brauchst du auch nur die
3 Zeilen aus meinem ersten Post. Zum kompilieren ist der Aufruf dann:
mbed compile -t GCC_ARM -m ARCH_PRO
Exportieren nach MCUXpresso:
mbed export -m ARCH_PRO -i mcuxpresso
Das erzeugt die Projektfiles und die IDE kann das importieren. Von da an
kann man mit der IDE weiterarbeiten.
Bei mbed habe ich gemischte Gefühle. Die Idee ist sehr gut, die
Umsetzung gut, die Dokumentation so lala und die Community nicht
vorhanden.
Faktisch geschieht die gesamte Entwicklung von uController Hersteller,
die ihre Treiber an das mbed API anbinden.
Seit einigen Jahren schon verfolge ich mbed, aber wirklich benutzbar ist
es leider bis heute nicht. Man sieht auch nicht, welche Features von
mbed auf welchen konkreten Mikrocontroller laufen, so dass man bereits
in den Code einsteigen muss, um den uC zu evaluieren.
Dann gab es vor einigen Jahren einen Bruch von mbed 2 auf mbed 5. Vieles
der Dokumentation ist noch immer nicht umgeschrieben.
Irgendwann gab es einen Bruch im Export der online IDE, so dass man
nicht mehr sein erstelltes Projekt auf SW4STM32 exportieren konnte.
Bei den ganzen "success stories" frage ich mich auch, wie da die
Wartbarkeit etc. aussieht. USBDevice ist erst im komment, Ethernet ist
bei 2-3 devices wohl implementiert, aber gleichzeitig sind die gross im
"IOT" drin. Ich frag mich nur mit welcher Technologie...
Zum rumspielen ist es wohl gut genug, aber für den professionellen
Einsatz würde ich noch 1 Jahr warten - und dann wieder schauen obs so
weit ist.
Operator S. schrieb:> Irgendwann gab es einen Bruch im Export der online IDE, so dass man> nicht mehr sein erstelltes Projekt auf SW4STM32 exportieren konnte.
das hatte mich auch geärgert, da wurde die Verzeichnisstruktur geändert
und von da an ging der Export lange Zeit nicht mehr. Dann habe ich mich
da weiter reingearbeitet und mittlerweile wird der Export besser
unterstützt und ist sogar in den automatischen Tests mit drin.
Aktuell wird das mbed 5 weiterentwickelt, das mbed 2 gibts auch noch, da
werden die Änderungen rüberkopiert. mbed 2 ist immer noch gut für
kleinere Targets, mbed 5 ist mit dem RTOS etwas anspruchsvoller. Aber
das RTOS kann man da auch abklemmen und dann ist der Unterschied nicht
mehr so gross.
> USBDevice ist erst im komment, Ethernet ist> bei 2-3 devices wohl implementiert,
USB gibt es eigentlich schon lange, ist aber nicht für alle Devices
implementiert. Es ist im 'unsupported' Ordner und nicht in den
automatischen Tests drin. Wegen der vielen verschiedenen Targets und
Compiler wird da exzessiv getestet und ein offizielles USB müsste auch
in die Hardwaretests rein. Trotzdem funktioniert das, habe ich schon auf
mehreren LPC und STM benutzt.
Ethernet ist noch weniger verbreitet, aber auch das ging schon auf dem
Ur mbed LPC1768. Auf den beliebten STM Boards funktioniert das auch.
ARM gehört das TLS, das ist auf den fetteren Boards auch implementiert
und diese sind wohl für das IoT gedacht.
Hallo,
habe nun alles nach der mbed youtube Anleitung mit dem installer tool
installieren lassen. Danach das Bsp. youtube mit blinky begonnen. Hier
komme ich nicht weiter.
Das mit dem blinky download mittels url funktionierte noch.
Dann soll man "mbed detect" eintippen, dass scheitert.
C:\Users\Checker\mbed_blinky>mbed detect
1
Traceback (most recent call last):
2
File "C:\Users\Checker\mbed_blinky\.temp\tools\detect_targets.py", line 33, in <module>
3
from tools.test_api import get_autodetected_MUTS_list
4
File "C:\Users\Checker\mbed_blinky\.temp\tools\test_api.py", line 53, in <module>
5
import tools.test_configs as TestConfig
6
ImportError: No module named test_configs
7
[mbed] ERROR: "C:\Python27\python.exe" returned error code 1.
8
[mbed] ERROR: Command "C:\Python27\python.exe -u C:\Users\Checker\mbed_blinky\.temp\tools\detect_targets.py" in "C:\Users\Checker\mbed_blinky"
9
---
Auf C:\ gibt es einen Ordner namens "mbed-cli" und "Python27".
Was mit eigentlich gar nicht gefällt, wenn sich eine Installation wild
auf der Platte breit macht.
Was läuft schief?
Checker schrieb:> Was mit eigentlich gar nicht gefällt, wenn sich eine Installation wild> auf der Platte breit macht.
Es ist aber zweckmäßig, denn es ist auch nicht das Gelbe vom Ei wenn man
sowas elendig langes wie "C:\Program Files (x86)\Acme Corporation
Inc\Super Product Pro 10.2\Tools\Compiler\ARM\Bin" im Pfad hat. Bei so
komplex aufgebauten Softwares mit diversen Komponenten ist es auch nicht
schlecht, wenn man einen standardisierten Installationspfad hat.
Hallo,
naja, es gibt seit Jahrzehnten eine allgemeine Installationsvorgabe
(oder wie man das nennt) seitens MS. Die beiden Ordner hätte man locker
in einen Programmordner mbed oder so ähnlich reinwerfen können.
Der Rest der selbst erstellten Code Projekte landet standardmäßig unter
Dokumente im user Ordner. Alles ganz easy und seit Jahren eigentlich
Standard.
Ist jetzt aber auch egal. Was ich falsch mache oder schief lief zu
wissen wäre mir aktuell lieber. :-)
Checker schrieb:> Die beiden Ordner hätte man locker> in einen Programmordner mbed oder so ähnlich reinwerfen können.
Und wenn dann ein anderes Programm auch Python braucht hast du es 2x auf
dem Rechner... Da lieber eine "allgemeingültige" globale Version
C:\Python die dann allen Softwares zur Verfügung steht. Unter Windows
ist das halt alles etwas komisch, unter Unix fügt sich das so
"natürlicher" zusammen.
Checker schrieb:> Alles ganz easy und seit Jahren eigentlich> Standard.
Nö, erst seit MS da seinen eigenen "Standard" gemacht hat :) Python & Co
orientieren sich aber am älteren echten Standard Unix (Posix)...
Johannes S. schrieb:> Die 8 Bitter nutze ich kaum noch und Arduino war anfangs ja auf die AVR> beschränkt. Das hat sich geändert, mit STM32duino und dem Import der> ESPs kann man die Arduino Libs auch auf anderen Plattformen nutzen. Die> Entwicklung ist aber sehr verteilt und nicht einheitlich, ich persönlich> halte mbed für das 'bessere' Arduino.
Ich befürchte, du hast nicht mal ansatzweise verstanden, was das Arduino
Konzept so interessant für Anfänger macht.
Aber schön, daß ARM versucht, etwas für seine ARM auf die Beine zu
stellen. Es richtet sich nur an eine andere Zielgruppe.
Checker schrieb:> Ist jetzt aber auch egal. Was ich falsch mache oder schief lief zu> wissen wäre mir aktuell lieber. :-)
Die Firmware für das Board muss aktualisiert werden (steht auf der HW
Seite zu dem Board) und der mbed serielle Treiber muss installiert sein.
Der Installiert sich blöderweise nur wenn sich die Hardware
angeschlossen ist und erkannt werden kann.
Das mbed detect ist aber auch nicht dringend nötig, das Programm sollte
sich kompilieren lassen und kann dann per copy auf das Board geschoben
werden.
Hallo,
die Firmware hatte ich schon vorher auf die v244 aktualisiert und der
serielle Treiber wurde installiert, hatte ich beobachtet während die
Installation lief. Du meinst jetzt das "mbed detect" überspringen?
-------------------------
@ Dr. Sommer
Mit "reinwerfen" meinte ich eine saubere Installation!
Vielleicht auch ein Missverständnis. Wenn sich Python und mbed sauber in
die Programmordner-Struktur "Programme" oder "Programme(x86)"
installieren würden ...
Wenn Python sich zum Bsp. direkt auf C:\ "entpackt" findet das kein
anderes Programm was davon nichts weiß. Wenn es sich sauber installieren
würde, kann jedes andere Programm im Standardinstallationspfad/Eintrag
nachschauen und findet es. Funktioniert seit Jahren so.
Unter Linux wird auch nichts wild irgendwohin verfrachtet. Es gibt auch
unter Linux klare Regeln. Sonst könnten die ganzen Paketabhängigkeiten
niemals sauber aufgelöst werden und es würde immer etwas fehlen oder
nicht gefunden.
Checker schrieb:> Wenn sich Python und mbed sauber in> die Programmordner-Struktur "Programme" oder "Programme(x86)"> installieren würden ...
Hat man das o.g. Problem mit den ewigen langen Pfaden.
Checker schrieb:> Wenn Python sich zum Bsp. direkt auf C:\ "entpackt" findet das kein> anderes Programm was davon nichts weiß
Andere Programme wissen das über die Path-Variable.
Checker schrieb:> Wenn es sich sauber installieren> würde, kann jedes andere Programm im Standardinstallationspfad/Eintrag> nachschauen und findet es.
Wird bei Unixoiden Programmen so nicht gemacht. Wenn du ein "make"
-Programm ausführst, sucht das via "Path" nach "gcc.exe", "python.exe"
usw., aber nicht über irgendwelche Registry-Einträge.
Checker schrieb:> Unter Linux wird auch nichts wild irgendwohin verfrachtet.
Da gibt es auch keine Registry. Sowas wie /bin gibts ja unter Windows
nicht...
Hallo,
eben, wenn es über Path sowieso gefunden werden kann oder wird, dann
kann es auch ordentlich installiert sein. Gehüpft wie gesprungen. Unter
Linux wird doch auch nichts direkt auf das Laufwerk installiert. Warum
wird oder soll der Mist unter Windows gemacht und soll für okay
empfunden werden. Die Logik verstehe ich nicht. Entweder hält man sich
an Regeln oder nicht.
Checker schrieb:> Gibt es nichts vergleichbares wie Atmel Studio nur eben für mbed arm? Es> macht doch keinen Sinn in der Konsole ein File zu erzeugen um es danach> in der IDE zu erarbeiten. Das muss doch alles in der IDE funktionieren.> Oder ich habe irgendwas falsch verstanden?
Doch, das mit dem CLI macht eben schon Sinn, weil man damit relativ
einfach Projekte für sehr viele verschiedene IDEs generieren kann und
genau das macht das mbed-cli. Für offline kannst du z.B. SW4STM32
nehmen. Darüber hinaus bauen die Leute von mbed gerade an ihrer eigenen
Eclipse-basierten mbed-offline-IDE, finde aber leider gerade den Link
nicht mehr.
Hallo,
die mbed Studio IDE hat noch frühen alpha status. Da sollte man bestimmt
noch warten.
https://os.mbed.com/studio/
Die ST IDE. Da wird wohl kaum mein "mbed Arch Pro" Board funktionieren,
denke ich. Oder?
Ich finde keine Auflistung oder dergleichen.
Werde mich nochmal mit der mbed cli befassen.
Checker schrieb:> Die ST IDE. Da wird wohl kaum mein "mbed Arch Pro" Board funktionieren,> denke ich. Oder?
Ja, stimmt natürlich. Johannes hatte ja auch schon direkt den korrekten
Hinweis auf MCU Xpresso gebracht. Prinzipiell sollte jedoch sogar
SW4STM32 gehen, wenn du es als Makefile-Projekt aus dem mbed-cli
exportierst und als Makefile-Projekt importierst. Ob das sinnvoll ist,
das ist natürlich eine ganz andere Frage aber prinzipiell sollte es
gehen.
heute weiter gemacht und "mbed detect" ignoriert. Scheint nicht sinnvoll
zu sein. Denn später folgte ein "mbed compile" mit ähnlicher
Fehlermeldung. Irgendwas scheint mit der Python Installation nicht zu
stimmen.
1
C:\Users\Checker\mbed_blinky>mbed detect
2
Traceback (most recent call last):
3
File "C:\Users\Checker\mbed_blinky\.temp\tools\detect_targets.py", line 33, in <module>
4
from tools.test_api import get_autodetected_MUTS_list
5
File "C:\Users\Checker\mbed_blinky\.temp\tools\test_api.py", line 53, in <module>
6
import tools.test_configs as TestConfig
7
ImportError: No module named test_configs
8
[mbed] ERROR: "C:\Python27\python.exe" returned error code 1.
9
[mbed] ERROR: Command "C:\Python27\python.exe -u C:\Users\Checker\mbed_blinky\.temp\tools\detect_targets.py" in "C:\Users\Checker\mbed_blinky"
Der Fehler beim compile scheint eher an der Toolchain Installation zu
liegen. Wenn die fragt ob die Environment Variablen gesetzt werden
sollen muss man das mit ja beantworten.
In dem bin Verzeichnis der gcc Installation liegt eine Batchdatei die
das macht, die kann man auch vorher aufrufen.
und welche mbed Version hattest du benutzt? Für den Arch Pro geht auch
mbed 5, also mbed import mbed-os-example-blinky.
Im mbed ist eine Versionsverwaltung integriert, ältere mbed2 Sachen
benutzen noch Mercurial (historisch bedingt) und neuere verwenden git.
Wenn man ein älteres Beispiel mit dem cli lädt liegt erstmal nur ein
link (.lib) im Verzeichnis. Mit mbed update oder wenn mbed compile die
Dateien nicht findet wird die Version geladen auf die der Link zeigt.
Das können dann ältere Versionen sein, mbed detect ist etwas neueres das
in der alten Version evtl. noch nicht drin war.
Ist etwas komplizierter als Arduino, aber die Versionsverwaltung mit git
ist etwas geniales und das sollte man sich auch die Basics anlesen.
Hallo,
das Arch Pro Board hat den LPC1768 drauf, falls das einen Unterschied
macht.
Ich hatte das nach der Anleitung des letzten Links gemacht, nur eben
nicht einzeln sondern mit dem Windows Installer der alles in einem
Rutsch installiert. Deinstalliert ist es schon, sobald mehr Zeit ist
versuche ich es nochmal einzeln ...
Das erzeugt das mbed 5 Blinky.
Checker schrieb:> das Arch Pro Board hat den LPC1768 drauf, falls das einen Unterschied> macht.
da hatte ich falsch gesehen, macht keinen Unterschied, ist richtig als
LPC1768 target da.
> nur eben> nicht einzeln sondern mit dem Windows Installer der alles in einem> Rutsch installiert.
das hat bei mir auf mehreren Rechnern funktioniert, nur eben bei der
Toolchain muss man drauf achten das der Path gesetzt ist. Das kann bei
der manuellen Installation auch passieren.
bei der kompletten Windows Installer Variante wird man nicht gefragt ob
der Python Pfad eingetragen werden soll oder nicht.
Habs nochmal von vorn probiert.
Bis zum "mbed compile" sah es vielversprechend aus.
GCC-ARM und Python kann nicht gefunden werden.
Habe dann Python entfernt und einzeln mit Pfadeintragsoption
installiert.
Ab da war der Befehl "mbed" unbekannt. Es geht nichts mehr. Habe jetzt
aktuell alles wieder deinstalliert. Morgen fang ich nochmal von vorn an.
Vielleicht habe ich auch was falschen oben ausgewählt. GCC_ARM und
ARCH_PRO ist doch richtig? Oder?
Macht es Sinn Python einzeln mit Pfadeintrag zu installieren und dann
beim Windows Komplettinstaller Python abwählen?
yuchee schrieb:> Ok man> muss nicht, aber wenn man leistungsfähigere Mikrocontroller benötigt> oder langfristig etwas kommerzielles plant dann kommt irgendwann der> Umstieg von Arduino.
Schau dir erstmal an was so einige aus winzigen 8-bittern so raus holen.
Ich behaupte einfach, dass das meiste was gerade Hobbyisten so machen,
mit 8 bit durchaus auch noch geklappt hätte.
Gut, ich bin kein Maßstab und schon wieder eine Weile raus, aber ich
kann mir in meinem Hobbybereich keine Anwendung vorstellen (die auch
zeitlich machbar wäre), die mit 8 bit nicht mehr laufen würde. und wenn
am Ende zwei oder drei Controller zusammen arbeiten, als verteiltes
System.
Wenn ich mir vielen Steuerungen ansehe, drin sind meist noch 8-bitter
und die steuern ziemlich komplexe Sachen.
Hatte für Spaß einmal geguckt was das für ein Siemens Teil ist. Hätte an
FPGA gedacht. Ziemlich groß, steuert (gut wir haben dann auch noch zwei
andere Controller da drin) einen ganzen Stapler.
Bis ich das ausreizen könnte, da bin ich auch unter normalen Umständen
längst tot.
Checker schrieb:> make.py: error: Could not find executable for GCC_ARM.> Currently set search path: No path set> [mbed] ERROR: "C:\Python27\python.exe" returned error code 2.
bis hierhin war schon alles gut, Python ist vermutlich auch korrekt
installiert. Der Fehlercode bezieht sich nicht auf Python sondern das
make.py kann einfach den GCC nicht finden, und der wird über eine
Environmentvariable gefunden die bei der gcc Installation gesetzt werden
soll.
Wenn die nicht gesetzt ist kann man auch die Batchdatei ausführen die
bei der Windows version dabei ist, zB für den gcc Version 6:
1
c:\Program Files (x86)\GNU Tools ARM Embedded\6 2017-q2-update\bin\gccvar.bat
Danach muss in der Kommandozeile
1
arm-none-eabi-gcc --version
funktionieren und der gcc seine Version melden. Dann klappts auch mit
dem kompilieren. So kann man auch mehrere gcc Versionen installieren und
per Environmentvariable auswählen.
F. F. schrieb:> Schau dir erstmal an was so einige aus winzigen 8-bittern so raus holen.
ist richtig, aber die Cortex-M oder andere haben viel mehr an Peripherie
zu bieten, z.B. schnelle LCD Controller oder wie beim Arch Pro mit dem
LPC1768 gleich Ethernet on Chip. Das alles per Datenblatt from scratch
zu programmieren kostet Zeit die nicht jeder investieren will, deshalb
ist das zusammenstoppeln von fertigen Funktionen oder Klassen Libs nix
verwerfliches finde ich.
Johannes S. schrieb:> ist richtig, aber die Cortex-M oder andere haben viel mehr an Peripherie> zu bieten, z.B.
Das ist dann natürlich ein Grund.
Johannes S. schrieb:> Das alles per Datenblatt from scratch> zu programmieren kostet Zeit die nicht jeder investieren will, deshalb> ist das zusammenstoppeln von fertigen Funktionen oder Klassen Libs nix> verwerfliches finde ich.
Überhaupt nicht. Deswegen erfreut sich Arduino auch solcher Beliebtheit.
Wird auch immer mehr grafisch angeboten. Was meiner Meinung nach dann
irgendwann den Hauptteil ausmacht.
Gerade schnell etwas machen zu können, ist im Hobby mindestens genauso
wichtig, wie im professionellen Einsatz.
Die Profis müssen schnell Ergebnisse liefern. Wenn du ewig dran bist, zu
Hause, und nichts wird fertig, verliert man die Lust.
Aber zu dem Beitrag, finde ich klasse.
danke, ich habe auch nichts (mehr) gegen Arduino. mbed ist sicher keine
grosse Konkurrenz zu Arduino, die STM haben sich da ja sehr breit
gemacht und dafür gibt es auch ja mittlerweile auch die Arduino cores,
wie auch für andere Architekturen. mbed war da seiner Zeit etwas vorraus
und schwieriger in den Griff zu bekommen, ausser vielleicht die ersten
mbed Boards + Online Compiler. Aber der Ur-mbed war da mit ca. 60-70 €
einfach zu teuer und jetzt wird der Markt von den Chinaboards
überschwemmt.
Trotzdem freut es mich wenn sich jemand auch mal was anderes ansieht
oder ein Board aus der Schublade mit mbed zum Leben verhelfen kann.
Checker schrieb:> make.py: error: Could not find executable for GCC_ARM.
Man brauch keine Windows-Environmentvariable zu setzen. Das geht auch
als mbed-Konfiguration nach der Installation des Compilers:
[/c]
mbed config -G GCC_ARM_PATH "C:\Program Files (x86)\GNU Tools ARM
Embedded\7 2017-q4-major\bin"
[c]
Statt dem Pfad im Beispiel sollte man natürlich den Pfad nehmen, in dem
man den Compiler installiert hat.
ihr werdet es kaum glauben :-) aber die Sch... funktioniert. :-)
Aus irgendwelchen Gründen funktioniert der Windows Installer wohl nicht
richtig bei mir. Keine Ahnung. Ich muss Python selbst installieren,
dabei advanced wählen und den Pfad eintragen lassen. Dann ist bei Python
alles korrekt. Danach starte ich den Windows Installer und muss danach
den gcc_arm Pfad anpassen. Wie ihr oben beschrieben habt. Vielen Dank
für den Tipp. Ich habs mit der mbed config gemacht.
Danach lief compile durch und die Led blinkte, Änderungen vorgemommen,
Led blinkte schneller.
Alles so wie es soll. Vielen Dank für eure Geduld.
Läuft das für AVR's und ihren make ähnlich ab?
Habe bisher dafür nur Atmel Studio verwendet.
Nochmal für die Nachwelt alles zusammengefasst.
nochwas, die gccvar.bat habe ich ausgeführt
arm-none-eabi-gcc --version
wird jedoch nicht gefunden ???
Die arm-none-eabi-gcc.exe ist aber vorhanden, sehe ich im Ordner
Muss deswegen nochwas korrigiert werden?
Checker schrieb:> nochwas, die gccvar.bat habe ich ausgeführt>> arm-none-eabi-gcc --version>> wird jedoch nicht gefunden ???
Dann rufst du irgendwas falsch auf. gccvar setzt den Pfad in einer neuen
cmd.exe. Nur in dieser cmd.exe wird danach der Compiler gefunden.
Das ist nur beschränkt nützlich.
> Die arm-none-eabi-gcc.exe ist aber vorhanden, sehe ich im Ordner>> Muss deswegen nochwas korrigiert werden?
Nein. Das mbed cli braucht das nicht.
Checker schrieb:> nochwas, die gccvar.bat habe ich ausgeführt
hoffentlich in der Eingabeaufforderung. Nur die die Batchdatei ausführen
bringt nix, das ist nur für die gerade ausgeführte Shell gültig, mit der
Ausführung der Batchdatei startet man die und die beendet sich gleich
wieder.
Ein weiterer Schritt wäre dann MCUXpresso zu installieren und das
Projekt per mbed export / import in MCUXpresso anzulegen. Der Arch Pro
sollte mit der aktuellen Firmware als CMSIS-DAP debug probe in der
Geräteliste auftauchen und dann man direkt darüber debuggen.
Ein bisschen Eclipse Erfahrung vorausgesetzt, da findet man ja jeden Tag
neue Dialoge. Das mitgelieferte Tutorial ist aber sehr ausführlich und
hilfreich für den Anfang.
okay, dachte das wird mit der .bat ein dauerhafter Pfadeintrag. In der
gleichen Konsole klappt alles.
6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437]
Wenn ich vielleicht MCUXpresso verwende, kann ich dann alles bis jetzt
installierte wieder deinstallieren?
Ich beobachte mbed auch schon sehr lange. Lange Zeit gab es für den
STM32F103 keine USB Unterstützung, was in Hinsicht auf die
Blue-Pill-Boards schade war. Inzwischen geht das aber. Ich hab mir mal
die Mühe gemacht und das folgende Projekt compiliert:
https://os.mbed.com/users/hudakz/code/STM32F103C8T6_USBSerial/
Wenn ich den Online-Compiler benutze kriege ich am Ende ein Binarie von
ca 34k. Da kann man aber mit Keil in der freien Version schon nicht mehr
debuggen.
Exportiere ich das ganze für den gcc lande ich bei 56k. Wohlgemerkt das
ist ein blinky mit USB-CDC das nur ein paar Bytes an den Host sendet.
Das ist mir persönlich deutlich zu fett. Allerdings ist das auch kein
Wunder. Unter dem (in meinen Augen recht gut geschriebenen) mbed-C++
Code liegt nochmal die ganze STM32-HAL. Allein die nötigen Header
belegen 6MB in 248 Dateien. Arduino ist da auch nicht viel sparsamer,
aber diese Entwicklung mache ich persönlich nicht mehr mit. Für kleine
Sachen wird mit den Register und dem Manual gearbeitet und für alles das
wo es nicht mehr reicht nehme ich dann doch lieber ein richtiges BS. In
sofern ist mbed also keine Alternative.
Checker schrieb:> Wenn ich vielleicht MCUXpresso verwende, kann ich dann alles bis jetzt> installierte wieder deinstallieren?
wenn du mbed nicht benutzen möchtest dann ja, mit MCUXpress kannst du
die Programme von Adam und Eva an selber bauen. D.h. man kann aus
vorinstallierten Templates ein C/C++ Projekt erstellen, Linkerfile und
Startupfile werden aus dem Template erzeugt. Das ist ok zum Grundlagen
lernen, mit mbed bekommt ein Projekt auf höherem Abstraktionslevel
erzeugt.
Die beiden Installationen tun sich aber nix und können nebenander
laufen, MCUX installiert den gcc nochmal in seinem eigenen Pfad.
was muss man denn beim mbed cli machen um offline ein neues projekt zu
erstellen? Ich lese immer nur von Bsp. importieren. Weil es müssen ja
dann auch alle weiteren benötigten Dateien herbeigezaubert werden in den
neuen Ordner.
für mbed2 hatte ich das im ersten Post schonmal beschrieben, für mbed5
ist etwas einfacher weil das default ist:
1
mkdir myProject
2
cd myProject
3
mbed new .
jetzt noch ein main.cpp erstellen und im Projektverzeichniss speichern,
dann einfach kompilieren mit
1
#include "mbed.h"
2
3
DigitalOut led1(LED1);
4
5
// main() runs in its own thread in the OS
6
int main() {
7
while (true) {
8
led1 = !led1;
9
wait(0.5);
10
}
11
}
1
mbed compile -t GCC_ARM -m BLUEPILL_F103C8
z.B. für das Bluepill Board.
Der Schritt 'mbed new .' lädt dann das aktuelle mbed-os von github.com.
Das geht leider nur für alle Targets in einem Stück, und da das
mittlerweile sehr viele sind dauert das eine Weile. Man kann das auch
einmal machen, die Targets die man nicht braucht aus dem Verzeichnis
.\mbed-os\targets rauslöschen und das dann als Kopiervorlage benutzen.
Eigenen Quellcode kann man jetzt im Projektverzeichnis erstellen oder
auch in Unterverzeichnisse packen. Das Build System sucht die Quellen
und erzeugt die nötigen Compiler und Linker includes.
danke, freut mich.
Noch ein Tip zur Codegrösse: default ist das 'develop' Profil, die
Compilersettings die da verwendet werden sind in
./mbed-os/tools/profiles zu finden. Das zieht printf für Debugausgaben
mit rein und kostet in der newlib viel Speicher. Mit
1
mbed compile --stats-depth 4 --profile release -c
bekommt man eine erweiterte Statistik über Speichernutzung, benutzt das
release Profil und -c macht ein clean build.
Danke, funktioniert und .bin schrumpft. Damit habe ich nun auch den
Pintakt auf 24MHz erhöhen können. Das wäre 1/4 vom CPU Takt. Ist das so
normal? Würde bedeuten der braucht 4 Takte zum Pin umschalten.
1
#include"mbed.h"
2
#include"LPC17xx.h"
3
4
intmain(void){
5
6
SystemInit();//Clock and PLL configuration
7
LPC_GPIO0->FIODIR=0xFFFFFFFF;//Configure the PORT pins as OUTPUT;
8
9
10
while(1)
11
{
12
LPC_GPIO0->FIOSET=0xFFFFFFFF;// Turn ON all the LEDs
13
14
LPC_GPIO0->FIOCLR=0xFFFFFFFF;// Turn OFF all the LEDs
Checker schrieb:> Ist das so> normal?
ich würde sagen ja, das ist schon sehr schnell.
In dem Beispiel nutzt du natürlich nur das Buildsystem von mbed und
nicht die lib. Das funktioniert in dem Fall weil mbed auch die CMSIS
benutzt. Das SystemInit wird auch schon im Startupcode aufgerufen und
kann weggelassen werden.
Als Benchmark mag ich diese Pintoggle Beispiele nicht, die Power der
Cortex-M liegt eher in viel Speicher, guter Peripherie und eben der
mbed lib die den Code einfacher und für die Standardklassen auch
portabel macht. Die Programmierung auf Registerebene braucht man
natürlich trozdem wenn man eigene Klassen bauen möchte mit Komponenten
die nicht in diesem Standard enthalten sind, zB. DMA, Counter,
Grafikfunktionen etc.
Das MCUXpresso Problemchen hatte ich gesehen, kann ich evtl. morgen
reinsehen, hier ist schon spät.
ich wollte mal testen was so geht. Mit 8Bit AVRs kenne ich mich
einigermaßen aus. Deswegen nun der Versuch mit dem Arch Pro Board als
ich dein Thread entdeckt hatte. Was sowas auslöst ist manchmal nicht
vorhersehbar.
Die mbed Lib werde ich auch wieder nutzen. :-)
Das mit MCUXpresso drängelt erstmal nicht. So umfangreich sind die
Gehversuche nicht.
Checker schrieb:> Das mit MCUXpresso drängelt erstmal nicht.
ok, IDEs mag ja auch nicht jeder und mit Eclipse und den vielen Optionen
muss man sich auch erstmal anfreunden. Aber das Debuggen oder Code
analysieren damit alleine macht schon Spass oder mit Ctrl-Klick ist man
sofort in Definitionen von Klassen oder Typen.
Die Autovervollständigung und IntelliSense wären irgendwann schon von
Vorteil. :-)
Mir fiel auf das sich die 4 vordefinierten Leds irgendwie immer negiert
verhalten. Die anderen Portpins dagegen nicht.
while(1) ist leer und "mbed.h" ist immer inkludiert.
DigitalOut led1(LED1); // Led leuchtet
DigitalOut led1(LED1,0); // Led leuchtet
DigitalOut led1(LED1,1); // Led leuchtet nicht
DigitalOut led(P0_25); // Pin ist "aus"
DigitalOut led(P0_25,0); // Pin ist "aus"
DigitalOut led(P0_25,1); // Pin ist "ein"
Hat sich dann nach der Schaltplansuche bestätigt. Die haben die Leds
wirklich gegen (+) angeklemmt. Sorgt erstmal für Verwirrung.
Pinname P1_18, P1_20, P1_21 und P1_23
Checker schrieb:> Die haben die Leds> wirklich gegen (+) angeklemmt. Sorgt erstmal für Verwirrung.
das ist aber üblich weil die Ausgänge nach GND mehr Strom schalten
können. So war es jedenfalls mal, heute sind da oft Push-Pull Stufen
drin die auch nach Plus mehrere mA schaffen. Das Thema gab es hier schon
öfter, hier ist zB etwas altes dazu:
Beitrag "LED gegen VCC oder GND?"
Ich mache mir dafür defines wie
1
#define LED_ON (0)
2
#define LED_OFF (1)
Da C++ kann man auch ein DigitalOutInvers bauen und die read/write und
Operatoren überschreiben, das wäre noch eleganter.
Thread beobachten
Seitenaufteilung abschalten