Angespornt durch diesen thread: Beitrag "Cortex M freie Bibliotheken, API?" habe ich mir kurzerhand ein Nucleo-stm32f103 board zugelegt und möchte gerne meine Erfahrungen mit allen interessenten teilen. Vorneweg zu meinen bisherigen Erfahrungen im Embedded bereich: Vor rund 5 Jahren das letzte mal µC Programmiert: AVR und MSP430 Seit 2 Jahren embedded Linux Für zuhause suchte ich immer mal wieder eine Plattform, welche einfach zu programmieren war und ich ohne grosses Detailwissen loslegen konnte. Bislang kam ich meist auf den Raspberry Pi, da ich mit der Linux API vertraut bin und deshalb gleich loslegen könnte. Für einfache Programme ist dieser zwar hoffnungslos überdimensioniert und mit rund 40€ (nur das board, ohne Gehäuse oder sonstiges) auch nicht sonderlich günstig, aber man könnte gleich loslegen. Trotzdem habe ich das nie gemacht, da das nicht embedded genug war. Mit mbed steht nun eine Software zur Verfügung, die dieses Ziel auch mit einem Cortex-M ermöglicht. Die API ist praktisch wie Arduino und somit auch für laien ohne probleme zu benutzen. Bei mbed.org steht ein online compiler zur verfügung. Damit war es mir möglich innerhalb von 10 Minuten ein eigenes Programm zu kompilieren (inkl Registrierung!) weiter 10 Minuten musste ich verschwenden, um openocd, bzw. danach das funktionierende stlink zum laufen zu bringen. Fazit: innerhalb von 20 Minuten zur eigenen LED Blinky. Weitere 15 Minuten später, hatte ich das ganze exportiert und unter der lokal toolchain mittels make am laufen. Weitere 5 Minuten und ich konnte mittels Potentiometer an Analog In die LED über Software PWM bedienen. Zurzeit bin ich begeistert von der Einfachheit, die einem mit mbed geboten wird. So frustfrei habe ich wahrschleinich noch nie in eine embedded Plattform zum laufen gebracht. Und genau das macht Spass wenns ums hobby geht. Für die detailreichen Entwicklungen bleibt mir immernoch mein Job als Entwicklungsingenieur, aber zuhause möchte ich sowas nicht. Natürlich ist ein analog Eingang und ein digital Ausgang noch nichts, was man als Projekt bezeichnen könnte, aber für eine Lüftersteuerung reicht es schon aus. In nächster Zeit werde ich sicher mehr mit der gesamten Plattform herumspielen und dabei auch verschiedene Kommunikations Funktionen benötigen. Dann wird sich auch zeigen, bis zu welchem Punkt man mbed verwenden kann. Insbesondere die Ähnlichkeit zu Arduino mag manch einem einen faden Beigeschmack bringen. Aber wer sich bereits mit C/C++ und Elektronik auskennt, dem werden die Einstiegshürden für eine embedded Plattform erheblich gesenkt. Gleichzeitig nimmt mbed einem ebendiese Schulung nicht ab. Programmieren muss immernoch selbst gelernt werden, ebenso wie rum man ein Protentiometer anschliesst. Und vermutlich sind es eben diese Anfängerfragen, die auch mbed einen faden Beigeschmack hinterlassen werden... Bin mal auf eure Erfahrungen und Meinungen gespannt!
Ich beobachte mbed auch schon eine ganze Weile. Es entwickelt sich zumindestens recht ordentlich. Den online-Compiler würde ich mir aber nicht antun. Ist aber auch mit dem ganz normalen gcc offline nutzbar und vor allem debugbar. Über eins muss man sich aber im klaren sein. Am besten unterstützt sind immer noch die NXP Chips. Für CAN und STM32 z.B. gibts noch kein HAL im Standard. Spätestens wenn man das nachrüsten will muss man schon ganz tief in den mbed-Source einsteigen. Timer sind auch so eine Sache. PWM lässt sich noch einigermaßen abstrahieren. Bei allem was darüber hinausgeht sind wieder die Register der Hardware gefragt und man kommt nicht an einer Einarbeitung herum. Ich habe mich deshalb bisher auch immer noch dagegen entschieden. Sollte bei mir aber mal was mit USB anstehen, denke ich nochmal drüber nach.
Ich beobachte das Projekt seit einer Weile, habe auch mal damit rumgespielt, aber noch keine Hardware gekauft. Die Online IDE ist mir unheimlich, ich möchte nicht von so einem Dienst abhängen. Aber wenn ich lokal Software installiere, dann kann ich gleich mit einem herkömmlichen Programmieradapter arbeiten. Aber für Schulen könnte das sehr interessant sein. Da kann man dann an wechselnden Computern arbeiten, ohne Software installieren zu müssen.
temp schrieb: > Den online-Compiler würde ich mir aber > nicht antun. Stefan Us schrieb: > Die Online IDE ist mir unheimlich, ich möchte nicht von so einem Dienst > abhängen. Man ist aber auch nicht an die IDE gebunden. Ich hab mir mein erstes Projekt dort erstellet und dann export -> Gnu/Gcc. Seit da läuft alles lokal, samt der Library. Stefan Us schrieb: > Aber wenn ich lokal Software installiere, dann kann ich gleich mit einem > herkömmlichen Programmieradapter arbeiten. Verstehe den Zusammenhang nicht. Was hat lokale Software mit einem "herkömmlichen Programmieradapter" zu tun? Flashen muss man das ganze eigentlich immer gleich, egal ob mbed oder nicht, es läuft übers St-Link V2
Die Online IDE wird m.M.n. zu Unrecht verteufelt, die lässt sich sehr gut nutzen und ist nicht nur ein Compiler sondern auch eine Versionsverwaltung. Man kann auch ein Team gründen und gemeinsam an Projekten arbeiten. Wer keine Top Secret Projekte hat und seine Software eh auf Github hält oder in Foren veröffentlicht sollte keine Probleme damit haben die irgendwo zu hosten. Es gibt nur nicht die unendlich vielen Einstellmöglichen über Compileroptionen, die wird aber auch nicht jeder vermissen. Einen Programmieradapter braucht man bei richtig mbed konformer Hardware auch nicht, da reicht ein USB Kabel. Ich habe jetzt für einige Projekte den NXP LPC1347 eingesetzt, der ist auch einfach per eingebautem USB Massenspeichergerät programmierbar.
Das Tolle bei mbed ist doch, dass man gar keine Software installieren muss. Man compiliert online, lädt das Binary runter und überträgt es per Dateimanager auf den mbed Controller. Wenn ich jedoch bereit bin, Software zu installieren, dann habe ich kein Problem damit, die Software für einen wie auch immer gearteten Programmieradapter zu installieren. Diese coole USB-Speicher-Stick Emulation von mbed brauche ich dann nicht.
ich hab hier einige verschiedene stm32 discovery boards liegen, kann ich die auch mit mbed programmieren oder gehen nur die hand voll nucleos die sie auf ihrer seite haben?
Dies möchte ich selbst auch noch ausprobieren. In einem Forumseintrag steht, man kann dies machen, solange es der selbe Controllertyp ist und Flash/Ram ausreicht. In einem Configfile für das Board müssen dann diese Werte angepasst werden und das sollte ausreichen. Ich habe vor den selben Code vom Nucleo-F103RB auf einem STM32F103C8T6 laufen zu lassen, die gibts ab ca. €1.60 über ebay, oder gleich das minimalboard für ~4.50
also ist die Vorgehensweise: board mit gleicher cpu auswählen, config file anpassen, und los legen? ich kann nämlich leider kein projekt in der online ide anlegen ohne ein board an zu geben, das macht das ganze für Eigenentwicklung ziemlich nutzlos finde ich.
Bisher habe ich das so verstanden, ja. Hatte aber auch noch zu wenig Zeit mich in das Projekt einzulesen. Laut Zeitplan wird das ganze aber in Zukunft auch immer weiter geöffnet. Früher war es z.B. nicht möglich die Projekte zu exportieren, darum wahrscheinlich auch die grosse Abneigung gegenüber der online IDE. Das hat sich inzwischen aber erledigt. Ich vermute in Zukunft werden weitere CPUs Unterstützung finden, da der gesamte mbed Code unter der Apache Lizenz liegt, könnte man aber auch selbst die Sourcen erweitern und dann sogar closed source vertreiben.
Update: Der oben beschriebene Erfahrungsbericht galt für das bisherige mbed OS und deren Internetauftritt. Wie ich jetzt gesehen habe, wurde die gesamte Seite zum release von mbed OS 3.0 umgestaltet. Bis jetzt finde ich mich noch nicht so zurecht und es hat viele Neuerungen gegeben. Habe aber auch nicht viel Zeit demnächst, um das genauer anzuschauen... Interessant ist sicherlich die Aufteilung der Softwarepakete, welche durch yotta zusammengebündelt werden. Wer Yocto kennt: es scheint ähnlich zu sein. Statt recipes sind es aber jetzt module, welche eine Software samt dependencies beschreibt. Zum kompilieren wird 'yotta build' aufgerufen, welche dann anhand der Modulbeschreibung das Target auswählt und kompiliert. Abhängigkeiten werden von yotta selbst aufgelöst und aus den entsprechenden repositories heruntergeladen, falls diese noch nicht vorhanden sind. Meiner Meinung nach geht mbed damit auf eine viel mächtigere Struktur zu, die aber auch erheblich grössere Komplexität mitbringt. Ob das der richtige Weg ist weiss ich aber noch nicht so recht...
Operator S.: Du wirst nicht zufällig von mbed bezahlt? Oder Nxp? Deine Texte klingen so nach Werbung.
Operator S. schrieb: > Wie ich jetzt gesehen habe, wurde die gesamte Seite zum release von mbed > OS 3.0 umgestaltet. die v2 gibt es auch noch, ist nur sehr versteckt: https://developer.mbed.org/
Marc schrieb: > Du wirst nicht zufällig von mbed bezahlt? Nein > Oder Nxp? Auch nicht und benutzen tu ich deren µCs erst recht nicht. Für meinen Geschmack sind die zu wenig Hobbyfreundlich, was das Marketing angeht. Transistoren und Co. benutze ich aber gerne von NXP. > Deine Texte klingen so nach Werbung. Entschuldige, ich konnte mir noch keinen anderen Schreibstil aneignen. Vielleicht sollte ich doch besser in den Verkauf, statt als Entwickler zu verenden :-)
Marc S. schrieb: > ich hab hier einige verschiedene stm32 discovery boards liegen, kann ich > die auch mit mbed programmieren oder gehen nur die hand voll nucleos die > sie auf ihrer seite haben? Die meisten Discovery Boards werden von mbed unterstützt, allerdings nur durch die Offline Toolchain. Dazu muss man das Projekt von Github runterladen und mit ein paar Python Scripten kommt man zu lauffähigen Beispiel Projekten, mit denen man dann weiter entwickeln kann.
Operator S. schrieb: > Fazit: innerhalb von 20 Minuten zur eigenen LED Blinky. Ja. Und was hast du dabei gelernt? Ich meine nicht, wie man sich dort einloggt, sondern was du über µC und embedded Programmiererei darauf und Anwendung davon für konkrete Zwecke gelernt hast. W.S.
Aufgrund deiner Fragestellung weiss ich schon wohin das abdriften wird und bevorzuge es daher, nicht darauf zu antworten. Ich kann dir nur sagen, dass ich genug Erfahrungen im embedded Bereich habe, um auch ein Datenblatt zu lesen und ausreichend bitschubserei in den Registern betrieben habe. ARM scheint nur der erste uC Hersteller zu sein, der die Treiber für seine Hardware mitliefert und seine Lizenznehmer dazu ermutigt, sich auf ein einheitliches API zu beschränken. Das kann dem Kunden (ich) doch eigentlich nur recht sein. Dann kann es aus Softwaresicht egal sein, ob ein Atmel, NXP, ST, whatever darunter sitzt.
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.