Seite 1 von 1

nanoFramework

Verfasst: 24 Apr 2018, 00:16
von steffalk
Tach auch!

Mein heißgeliebtes Microsoft .net Micro Framework (aka "netmf" oder "µF") wird ja leider schon länger nicht mehr aktiv gepflegt - die letzte Version lief mit Visual Studio 2013. Auf der Convention 2016 hatte ich diese Demo dabei: https://www.ftcommunity.de/categories.php?cat_id=3273.

Eher zufällig stieß ich aber auf ein heißes Community-Projekt http://www.nanoframework.net. Da sind eine Reihe sehr fähiger und ganz enorm freundlicher und hilfsbereiter Leute dran, das netmf in modernisierter Form anzubieten. Kostenlos - das ist alles Open Source. Das ist zwar alles noch Version 0.3.x.y, aber es geht schon eine ganze Menge mit einer ganzen Menge an Microcontroller-Boards.

Die Leute dort halfen mir, die Firmware und das Framework auf meine Netduino 3-Boards zu bekommen und die ersten Gehversuche zu machen. Netduinos sind Arduino-kompatible Boards mit hinreichend mächtiger Hardware, um das netmf und nun eben das nanoFramework zu fahren. Ich habe nun dieselben Abstraktionsschichten gebaut und weiterentwickelt, wie ich es mit dem netmf (siehe die Demo) tat. Den aktuellen Stand kann man hier sehen: https://github.com/steffalk/AbstractIO.

AbstractIO kann mit den Netduino-Boards digitales I/O an allen PINs incl. dem onboard-Button und allen onboard-LEDs, mit Polling oder IRQ/Event-gesteuert, analogen Input, und via PWM analogen Output an die I/O-Pins und LEDs. Es unterstützt auch bereits Motoren an Adafruit Motor Shields V2.3, und neben mir läuft eine Demo von 16 (sechzehn) fischertechnik-Motoren, getrieben von vier aufeinandergesteckten Adafruit Motor Shields, gesteuert von einem einzigen Netduino-3-Board: Auf separaten Threads werden die 16 Motoren weich beschleunigend und abbremsend gemeinsam und in zufälligen Geschwindigkeiten vor und zurück betrieben, und parallel blinkt die onboard-LED ebenfalls weich im Sekundentakt auf. Das ist das Sample08SmoothManyAnalogOutputs im (völlig Board-unabhängigen!) https://github.com/steffalk/AbstractIO/ ... Outputs.cs, und hineingereicht werden 16 Motoren von vier Shields (siehe das Sample09LetManyMotorsRun in https://github.com/steffalk/AbstractIO/ ... lesMain.cs).

Es wird bestimmt eine Reihe von ft:pedia-Artikeln über das nanoFramework mit warum, wieso, wozu, was geht, wie komfortabel geht das etc. geben, und auch über AbstractIO.

Langer Rede, kurzer Sinn: Hier ist die Demo, aufgenommen zur Nacht bei schummriger Wohnzimmerbeleuchtung: https://1drv.ms/f/s!AnuxuhxP0zblqKRsucTPUSC2mp_4jA.

Gruß,
Stefan

Re: nanoFramework

Verfasst: 24 Apr 2018, 21:48
von ThanksForTheFish
Wow,
ich bin absolut begeistert. Ich muss das unbedingt alles ausprobieren.

Viele Grüße, Ralf

Re: nanoFramework

Verfasst: 25 Apr 2018, 19:10
von hamlet
Tach Stefan,
Das sieht verdammt cool aus! Ich habe Deine Beispiele überflogen und finde, dass das API und Beispiele sehr sauber und übersichtlich ausschauen. Und 16 (!) Motoren an einem Controller sind schon klasse.

Der Netduino ist ein schickes Teil. Wird der weiterentwickelt? Ich habe bei Adafruit ein "Discontinued" gesehen. Vor einiger Zeit habe ich ja selbst mal mit einem ARM Cortex M4 basierten Controller experimentiert, allerdings im mbed Ökosystem. Ich finde, dass die M4-Controller ausreichend Leistung haben, meist über viele Interfaces verfügen und dennoch nicht sehr energiehungrig sind. Die Pixy Cam hat ja ebenfalls einen Cortex-M4 als Hauptcontroller. Die Adafruit Motor-Shields find ich ebenfalls klasse.

Werden die Motor-Shields über i2c angesprochen? Funktioniert das von parallelen Threads aus? Dein Code sieht auf den ersten Blick so aus, als sei es nur ein Thread der alle Motoren in einer Schleife anspricht. Weißt Du wie die i2c Treiber im nano-Framework ticken, asynchron? Beim mbed Framework sind die HW-Interfaces zwar auch schön abstrahiert aber die verfügbaren "Treiber" waren mal (sind es hoffentlich nicht mehr) recht primitiv. Sie liefen letztendlich synchron und haben dumpf viele CPU-Cycles in busy-wait-Schleifen beim Warten auf die Rückmeldung der HW verbrannt. Bei einem langsamen i2c-client tut sowas echt weh. Weißt Du ob das beim Nano Framework besser gelöst ist?

Ich habe viele "doubles" in Deinem Beispiel gesehen. Sind das 64bit double-precision floats? Dann schaltet man damit vermutlich die single-precision FPU des Cortex M4 auf dem Netduino weg.

Ich bin auf jeden Fall gespannt wie es weiter geht und freue mich auf Updates.

Viele Grüße,
Helmut

Re: nanoFramework

Verfasst: 25 Apr 2018, 19:26
von steffalk
Tach auch!

(Mehrfach ergänzt - wer das in der Urfassung gelesen hat, ruhig nochmal lesen ;-)

- Der Netduino ist seit einiger Zeit in neuen Händen, damit die Entwicklung weitergeht. Aber selbst wenn der sich mal überlebt haben sollte, unterstützt das nanoFrameork - heute schon - eine ganze Reihe von Boards. Schau mal die aktuelle Firmwareliste auf https://github.com/nanoframework/Home.

- Die Ideen hinter AbstractIO sind:

a) Code für Modelle in separate Projekte auszulagern, ohne dass die genau wissen müssen, was für Peripherie sie ansteuern. Über die I/O-Transformationen kann man dann einfach andere Objekte reinreichen, ohne irgendwas am Modellcode ändern zu müssen (Beispiel: IBooleanInput für "Stop", das kann tatsächlich ein einzelner Taster sein, das AND zweier Taster (Zweihandbedienung), oder der per Schmitt-Trigger zu einem Boolean transformierte Analogwert einer Fotozelle - völlig ohne Änderungen am Modell-Code.

b) Das eröffnet die Möglichkeit, den Modellen Mock-Objekte reinzureichen, um den Code für die Modelle gänzlich ohne jede Hardware unit-testbar zu haben.

c) Außerdem erlaub es das, den Modellcode völlig unabhängig vom tatsächlichen Board zu schreiben. Ob da nun ein Netduino drunter liegt oder was anderes, und ob es Adafruit-Shields sind oder was anderes, ist egal, solange man "Treiber" dafür hat, die einfach Objekte liefern, die die I<Datentyp><Input/Output>-Interfaces implementieren.

- Wenn es mal sowas wie V1.0 ist, will ich AbstractIO als simple Nuget-Packages anbieten, die man mit wenigen Klicks in ein Visual Studio-Projekt einbetten und updaten kann.

- Ich habe es selbst noch nicht probiert, aber nanoFramework kann man wohl auch mit Visual Studio Code verwenden - unter Windows, Mac, Linux, was auch immer. Fragen dazu am besten auf slack (siehe den Hinweis weiter unten).

- Ja, die Adafruits werden über I²C angesprochen, und AbstractIO ist in dieser Hinsicht thread-sicher. Ich erwarte in echten Modellen, dass es der Normalfall ist, einen Haufen unabhängiger Threads zu haben. Und auch jetzt schon ist das nötig: Auch wenn die 16-Motor-Demo nur einen Thread für den Blinker und einen Thread für die Motoren hat (damit es nämlich alle 16 mal gleichzeitig auf volle Pulle schalten kann), wird die Smoothed-Operation, die das sanfte Anlaufen und Bremsen macht, über Timer realisiert, und die Timer-Callbacks laufen eh auf anderen Threads (die vom OS kommen nämlich).

Ich habe um alle I²C-Transaktionen lock()-Statements auf Objekte aus https://github.com/steffalk/AbstractIO/ ... Objects.cs gepackt, damit nicht nur "meine" I²C-Operationen threadsicher sein können, sondern auch andere. Man schreibe einfach um jede I²C-Operation in C# ein lock(AbstractIO.GlobalLockObjects.I2cLockObject) { /* Hier z.B. ein write gefolgt von einem read */ } - und man ist auf der sicheren Seite, egal wie viele Threads, Timer man hat und wie viele I²C-Geräte am Bus hängen. Genau das ist in https://github.com/steffalk/AbstractIO/ ... troller.cs an den betreffenden Stellen gemacht.

- Aktuell haben wir in der Firmware noch ein Problem mit I²C, dass sich dadurch äußert, dass sich das ganze OS aufhängen kann, wenn man I²C nutzt - mal nach einer Sekunde, mal auch erst nach einer Stunde Betrieb. Das klären die nanoFramework-Gurus aber gerade, haben das Problem bereits auf was mit DMA eingegrenzt, und es wird bestimmt bald eine neue Firmware geben.

Als OS drunter läuft ein ChibiOS, und wenn (!) ich die Jungs richtig verstanden habe, läuft I²C da noch synchron. Da sind die aber gerade dran am werkeln.

Aktuell ist das ja noch work in progress alles, aber schon sehr brauchbar. Es hängen auch "richtige" Firmen dran, die bisher netmf gemacht haben und jetzt NF betreiben, incl. Bereitstellung von Resourcen für die Entwicklung.

- Ja, ich habe da mehrere IDoubleInput/IDoubleOutput verwendet. Die FPU auf dem Netduino macht tatsächlich nur single precision. Es hält mich ja niemand, auch ein ISingleInput/ISingleOutput anzubieten. :-)

- Für Updates schaut ab und zu in https://github.com/nanoframework, insbesondere auf https://github.com/nanoframework/Home, und auf https://github.com/steffalk/AbstractIO.

- Die Samples erweitere ich laufend, und das AbstractIO-Framework auch. Es fehlen noch die coolen Sachen, die man für Schrittmotoren und sonstige Schritt-Antriebe (Motor plus Impulstaster anstatt Schrittmotor gefällig?) wegabstrahieren kann.

Das nanoFramework-Team sucht Verstärkung! Es gibt noch genug zu tun im C/C++-Teil, OS, Framework, Visual Studio Extension, Dokumentation, Beispielcode etc. Wer immer lust hat, melde sich gerne auf https://nanoframework.slack.com - da sind all die netten Leute!

Gruß,
Stefan

Re: nanoFramework

Verfasst: 08 Mai 2018, 19:20
von steffalk
Tach auch!

Eine Demo hab ich veröffentlicht: 16 Motoren von einem Netduino gesteuert: https://www.ftcommunity.de/categories.php?cat_id=3510 und https://youtu.be/9j031Vu6o4s. Sourcen sind auf https://github.com/steffalk/AbstractIO

Als nächstes kommen Schrittmotoren dran.

Gruß,
Stefan

Re: nanoFramework

Verfasst: 17 Jun 2018, 10:48
von steffalk
Tach auch!

@hamlet:
Ich habe viele "doubles" in Deinem Beispiel gesehen. Sind das 64bit double-precision floats? Dann schaltet man damit vermutlich die single-precision FPU des Cortex M4 auf dem Netduino weg.
Seit gestern unterstütz die Firmware System.Math (all die Mathe-Funktionen) in single precision und nutzt die FPU des Netduino. Ich bin gerade dabei, das in AbstractIO auszunutzen - niemand braucht wohl double precision beim Setzen einer Motor-Geschwindigkeit ;-)

Gruß,
Stefan