Neue Boards: Arduino Portenta H7 Lite, Windows 11 für Raspberry Pi

Arduino liefert eine preiswertere Variante des Portenta H7 ohne Funkmodul. In der Raspberry Pi-Welt gibt es derweil ein neues Skript, das die Erzeugung von Windows 11-Images erleichtert.

von Tam HANNA

Worum geht es hier?

Vollwertige Einplatinencomputer erlauben die Ausführung von Desktopbetriebssystemen. Hier einige Neuerungen aus der Welt des SBC.

Portenta H7 Lite – preiswerter Arduino Pro ohne Funkmodul

Arduino bietet mit dem Portenta H7 eine vergleichsweise teure Platine auf Basis des zweikernigen STM32H747XI an. Neben der mit fast 90 EUR bepreisten Standardvariante offerieren die Italiener nun eine kleinere Variante, die um 60 EUR den Besitzer wechselt.

Der wichtigste Unterschied zur Vollversion ist die Entfernung des Funkmoduls und des Videoausgangs. Das normalerweise integrierte Murata 1DX – es bietet Bluetooth LE und WLAN – ist nicht verfügbar, die Ethernet-PHY ist allerdings nach wie vor mit von der Partie.
Dank des USB-C-Steckers konnte der Portenta H7 – Stichwort DisplayPort – auch “vollwertige” Bildinformationen ausgeben. Der Portenta H7 Lite bietet dieses Feature nicht an.
Zu guter Letzt ändert die Arduino AG das verwendete Cryptomodul. Statt dem NXP-Chip kommt nun ein Microchip ATECC608 zum Einsatz.

Installations-Skript für Windows 10 und Windows 11 für Raspberry Pi

Microsoft experimentierte immer wieder mit Windows für den Raspberry Pi, um die Versuchsreihe (siehe zum Beispiel https://www.linkedin.com/learning/windows-10-iot-grundkurs/) wieder einzustellen.

Mit WoR-flasher steht nun ein Skript zur Verfügung, das die folgenden Einplatinencomputer mit Linux ausstattet:

1field=“on a”:CB “Pi4/Pi400!Pi3/Pi2_v1.2”

Wichtig ist dabei die Verwendung eines ausreichend großen IS-Mediums. Hat das Medium mehr als 32GB an Kapazität, so kann es “sich selbst” konfigurieren. Ab 8GB große IS-Medien erlauben “nur” die Konfiguration anderer Speicherchips, die dann für den Start des Prozessrechners sorgen.
Mehr Informationen und das schlüsselfertige, sowohl am Raspberry Pi als auch auf Linux-Maschinen ausführbare Skript finden sich unter https://github.com/Botspot/wor-flasher.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Kurzmeldungen: RISC-V, mehr .net und Entwickler-Boards

Im Bereich der RISC-V-Mikrocontroller gibt es Neuerungen: GigaDevice adaptiert den Sipeed Longan Nano, während Mikron einen für den russischen Markt vorgesehenen RISC-V-Chip anbietet.

Worum geht es hier?

Kurzmitteilungen – ehemals Birulki – ermöglichen die Vorstellung von “kleinen” Nachrichten, die trotzdem Aufmerksamkeit verdienen.

Sipeed Longan Nano in Version 1.1 – neues GPIO-Pinout

GigaDevice bietet mit den hauseigenen Evaluationsboards einen preiswerten Weg zur Entwicklung an – unter https://www.mikrocontroller.net/topic/520816 findet sich ein schrittweises Tutorial.
Der Longan Nano (siehe https://www.seeedstudio.com/Sipeed-Longan-Nano-V1-1-p-5118.html) ist eine vom Format her kompaktere und dank des eingebauten Vollfarbdisplays in vielen Fällen auch für Kleinserien geeignete Entwicklungs-Platine.
SeeedStudio eine aktualisierten Version an, die sich folgendermaßen präsentiert:

Zum Vergleich hier noch ein Bild des Vorgängers:

Die neue Version, die laut aktueller Planung am 30. September in den Versand geht, ist unwesentlich teurer als der Vorgänger. Über die Frage, welche Platine für eigene Experimente besser geeignet ist, lässt sich hervorragend diskutieren. Nach Ansicht des Autors, der den GD32VF produktiv einsetzt, sind die White PCBs vor allem dann gut geeignet, wenn sie am Ende eine eigene Platine entwerfen wollen. Möchten Sie den RISC-V-Mikrocontroller stattdessen – analog zu einem Raspberry Pi oder Orange Pi – als „Board on Board“ verwenden, so ist der Longan Nano wahrscheinlich die bequemere Wahl – er exponiert zwar weniger GPIO-Pins, bringt aber ein Display und zwei Taster mit.

RISC-V ohne GigaDevice.

GigaDevice mag der einzige nicht-sektierererische Hardware-Hersteller sein, der sein „Unwesen“ im Bereich der RISC-V-Mikrocontroller treibt.
Das russische Unternehmen Micron bietet mit dem MIK32 einen „weiteren“ Controller an, der auf die Bedürfnisse von russischen Regierungs- und regierungsnaher-Organisationen optimiert ist.
Diese Ausrichtung zeigt sich unter anderem im Krypto-Beschleuniger, der – siehe Abbildung – für diverse russische Regierungsstandards optimierte Beschleuniger mitbringt.

Sonst ist der Controller, was man von einem RISC-V-Chip erwarten würde. Das in englischer Sprache verfügbare Übersichts-Datenblatt listet detaillierte Spezifikationen (siehe https://clck.ru/Vkvn6) auf.

Offen ist zum Zeitpunkt der Drucklegung die Frage nach dem Preis. Der im Allgemeinen gut informierte Branchen-Nachrichtendienst CNX spricht davon, dass ein Chip ungefähr 450 Rubel (etwa 6 $) kosten dürfte – zum Vergleich kostet GigaDevices GD32VF beim Distributor TME in Einzelstückzahlen ungefähr 2,5 $. Andererseits sei angemerkt, dass der MIK32 ob der russischen rechtlichen Situation für viele Anwender die „einzelne mögliche“ Vorgehensweise sein dürfte.

Meadow b5.3 – jetzt mit SQLite

In der Welt des Madow F7 gilt der alte Kalauer des „nach dem Update ist vor dem Update“ in besonderer Stärke – wer in C#, F# oder Visual Basic gehaltenes geistiges Eigentum unter Nutzung von Bryan Costanichs Plattform „embeddisiert“, darf Software-Updates einspielen.
Das neueste Update B5.3i bringt neben diversen Fehlerbehebungen auch eine SQLite-Datenbankengine „im ROM“ mit:

1SQLite Support SQLite is now built into Meadow.OS and Frank added support for Meadow in his SQLite.NET ORM.
2 Azure Integration The auth bug that prevented integration with Azure is fixed.
3 Network Fixes There are a pile of Network stack fixes and stabilization.
4 Bluetooth Fixes There were some strange bugs introduced to bluetooth in b5.2, we fixed them.
5 Meadow.Foundation Cleanup Lots of sample cleanup and some small API upgrades.
6 Docs We reorganized some of our Meadow.OS docs, and did a huge update on Meadow.Foundation documentation.

SeeedStudio: CAN-I2C-Modul auf Basis des MCP2515.

Möchte ein Prozessrechner Kontakt mit CAN aufnehmen, so ist Microchips Evergreen MCP2510 nicht weit entfernt. Mit dem MCP2515 bieten die Amerikaner allerdings-seit einiger Zeit-ein Nachfolgeprodukt an, das Neuerungen im Bereich des CAN-Standards abbildet.
Mit dem Seeed Studio MCP2551 and MCP2515 I2C CAN-BUS Module bietet SeeedStudio nun eine Version an, die die „modernisierte“ Variante des Controllers ansprechbar macht. Als PHY kommt ein MCP2551 zum Einsatz, das Board ist auch sonst bis zur Schraubklemme „abwärtskompatibel“.

Panasonic: kompakte Polymer-Tantal-Kondensatoren ohne Deratierung

MLCC-Kondensatoren werden auf Make-up fährst immer wieder als Freikugel zur Lösung aller kondensatorbezogenen Probleme angepriesen. Ein als Deratierung bezeichnete Effekt – weitere Informationen hierzu unter https://www.mikrocontroller.net/topic/523245#new – sorgt dafür, dass dies in der Praxis oft nicht zutrifft.
Polymer-Kondensatoren sind deratierungsfrei, aber wesentlich teurerer. Mit der POSCAP TPE-Familie schickt Panasonic Tantal-Kondensatoren ins Rennen, der Gehäusegröße von 3.5mm x 2.8mm x 1.9mm für Polymer-Kondensatoren durchaus klein ist.
Interessant ist an diesen Komponenten vor allem, dass sie in einem weiten Bereich „häufig benötigter“ Spannungspaaren angeboten werden-die Tabelle zeigt, was Panasonic derzeit offeriert.

Adieu, (Dallas) Maxim – Übernahme finalisiert

Zu guter Letzt eine Nachricht, die den Autor persönlich ein wenig wehmütig macht – die Konsolidierung im Halbleitermarkt schreitet unaufhaltbar voran. Analog Devices haben die Übernahme von Dallas Maxim nun abgeschlossen. Die offizielle und vergleichsweise lapidare Meldung liest sich folgendermaßen:

1We are pleased to announce that Analog Devices has completed its acquisition of Maxim Integrated and we are now one company.

Auch als Dankeschön für die vielen, vielen Samples und das excellente Ingenieursmagazin in meiner aktiven Zeit: danke, Dallas Maxim!

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Kurzmitteilungen: Armbian, 8×8-TOF-Tiefensensor, GigaDevice baut DDR4-RAM und vieles mehr

Seit den letzten Kurzmitteilungen gab es einige Neuerungen in Sachen Digitalelektronik und Internet der Dinge.
von Tam HANNA

Worum geht es hier

Mit den Kurzmitteilungen – ehemals Birulki – versuchen wir, einen Überblick über Meldungen zu geben, die für einen normalen Artikel nicht genug Inhalt bieten, aber trotzdem Aufmerksamkeit verdienen.

GigaDevice GDQ2BFAA: DDR4-RAM ala GD

GigaDevice ist vor allem als Hersteller von RISC-V und STM32-kompatiblen ARM-Mikrocontroller bekannt. Weniger geläufig ist, dass die Firma eigentlich ein Speicherhersteller ist, der in die Welt der Mikrocontroller expandierte.

Im Heimatmarkt stellt GigaDevice mit dem GDQ2BFAA ein vier Gigabit großes Speichermodul zur Verfügung, das den DDR4-Bus mit den Geschwindigkeiten 2666Mbps und 2933Mbps unterstützt, und zu den JEDEC-Standards kompatibel ist.

I2C-Pegelwandler für geringe Signalspannungen.

War das klassische I2C-Problem einst das Makeln zwischen 5 V und 3,3 V, so sind heute Logik-Pegel von 1,8V und 1,2V geläufig.
Texas Instruments bietet mit dem TCA9416 einen Chip an, der für den Spannungsbereich von 1,08 V bis 3,6 V vorgesehen ist. Sonst verhält sich das Bauteil – siehe Abbildung – so, wie man es von einem I2C-Pegelwandler erwarten würde.

Im Bereich der Geschwindigkeiten ist das Produkt ebenfalls flexibel, für SCL wird ein Geschwindigkeitsbereich von 100kHz bis 1MHz avisiert.

Armbian 21.08 verfügbar

Wer einen OrangePi oder ein ähnliches chinesisches ARM-Board verwendet, kennt Armbian mit Sicherheit: das unter anderem in der tschechischen Republik entwickelte Produkt ist eine Debian-Variante, die die verschiedensten Single Board-Computer unterstützt.

Die nun erschienene Version „Focal“ führt eine Aktualisierung der verwendeten Basis-Distributionen durch: Sie dürfen nun auf Pakete aus den folgenden neuen Versionen setzen:

1Debian sid
2Ubuntu 21.04 hirsute
3Ubuntu 21.10 impish

Der eigentliche Kernel basiert dabei in den meisten Fällen auf Linux 5.10.59, für die meisten Boards gibt es auch „aktualisierte“ Varianten mit 5.13er-Kernel. Das Entwicklerteam verspricht außerdem die folgenden Neuerungen:

1 minimal, server or XFCE, Cinnamon and Budgie desktop
2 fast and effective automated language selection on first run
3 regular stable and daily beta & EDGE updates
4 CLI is powered with ZSH or BASH
5 added automated kernel upgrade on EDGE 5.13.y kernels
6 added mainline based SPI boot support for Odroid HC4
7 added Qemu virtual Armbian builds
8 added CSC images for Tinkerboard 2, Rockpi N10,
9 added ZFS upgrade to v2.1
10 improved Github Actions CI and CDN network
11 added Cinnamon and Budgie desktop
12 enabled 3D support wherever its possible and works reasonble well
13 added Khadas VIM13 & Edge boards, Avnet Microzed
14 enabled VPU support for Rockchip
15 added legacy kernel support for OrangepiZero2, Nvidia Jetson
16 declare Ubuntu Hirsute and Debian Bullseye packages as stable
17 added Ubuntu Impish and Debian Sid as beta build targets
18 added KDE plasma DE as a beta build target

Ein schneller Test des Autors – er verwendet OrangePi-Boards produktiv in seinem Unternehmen – ergab, dass ein Gutteil der Platinen zum Zeitpunkt der Drucklegung noch nicht auf die „aktuellsten“ Images aktualisiert wurde.

Renesas: Neue RXv3-Variante mit Unterstützung für kapazitive Touchscreens.

Renesas dürfte das Konzept des „Special-Interrest-Mikrocontroller“ besser verkörpern als die meisten anderen Hersteller: es gibt kaum eine „spezifische Anwendung“, für die die Japaner nicht einen dedizierten Mikrocontroller vorhalten.
Mit dem RX671 offeriert man nun eine neue Variante, die zwar einerseits mit der RX600-Familie kompatibel ist, andererseits aber – siehe Abbildung – Unterstützung für kapazitive Touchscreens mitbringt.

Als intendierten Einsatzzweck avisiert Renesas dabei die Realisierung von HMI-getriebenen Geräten-denken Sie an Kaffeemaschinen und andere „White Goods“, die heute immer mehr Rechenleistung und immer anspruchsvollere Benutzerinterfaces voraussetzt.

VL53L5CX-Sensor nun mit Auflösung von 8X8 Sektoren.

STMicroelectronics bietet in der VL53-Serie seit längerer Zeit eine Gruppe von Tiefensensoren an, die auf dem Time of Flight-Prinzip basieren. Mit dem VL53L5CX folgt nun eine „neue“ Variante des Chips, die statt einer einzelnen Messung eines entweder 4 × 4 oder 8 × 8 Felder großen Bereich“ abdeckt.
Das in einem GA16-Gehäuse angebotene Teil kommuniziert mit dem Hosst dabei über einen I2C-Bus, und kann im 4 × 4-Betrieb bis zu 60 Frames pro Sekunde liefern. Die „Reichweite“ der einzelnen Zellen reicht dabei von 2-400 cm.

Wie bei so gut wie allen Tiefensensoren gilt auch für den VL53L5CX, dass die unterm Strich erreichbare Genauigkeit stark von der Betriebssituation abhängig ist. Das unter https://www.st.com/resource/en/datasheet/vl53l5cx.pdf bereitstehende Datenblatt bietet Informationen und Programme zum Thema.

In eigener Sache: Birulki heissen ab jetzt Kurzmitteilungen, Anfrage an KEMET läuft

Rassische Halbaraber sind (bedingt) lernfähig: ab sofort steht im Titel Kurzmitteilungen. Am Format und an der Intention ändert sich nichts.
Die Anfrage bei KEMET war aus gesundheitlichen Gründen meinerseits verzögert, läuft nun aber. In der nächsten Komponentenbestellung für die Holding sind einige solche Bauteile enthalten, die mit dem Bode100 getestet werden.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Arduino-Updates: Neuer ESP32-Core, aktualisierte Version von Arduino CLI

Wer seine Software unter Nutzung der Arduino-Programmierumgebung realisiert, darf sich auf Anpassungen freuen: Breaking Changes an der Arduino CLI erfordern Anpassungen vorhandener Buildskripte, während der ESP32-Kern neue Varianten von Espressifs kombinatorischem Mikrocontroller zu unterstützen weiß.

von Tam HANNA

Worum geht es hier?

Die auf dem Wiring-Programmiersystem basierende Arduino IDE hat sich im Laufe der letzten Jahre als eine Art Cross-Plattform-Standard im Bereich der Mikrocontroller etabliert. Die nach der Einleitung des Projekts festgelegten Designentscheidungen erwiesen sich teilweise als suboptimal, weshalb man seither an Optimierungen arbeitet. Einige davon wollen wir in diesem Artikel kurz vorstellen.

ESP32 ohne ESP-IDF

Wer die maximale Leistung von Espressif-Mikrocontrollern in Anspruch nehmen möchte, setzt seit Jahr und Tag auf die als ESP-IDF bezeichnete Programmierumgebung. Diese mag durchaus komfortabel sein – insbesondere im Makerbereich schätzt man die Arduino-Umgebung allerdings ob ihrer Möglichkeit, unterm Strich doch kompakteren Code zu generieren.
Der ESP 32 wird dabei seit einiger Zeit durch ein als Arduino-ESP32 bezeichnetes Modul unterstützt, das seit dem 1. September in Version 2.0 verfügbar ist.
Die mit Abstand wichtigste Neuerung der moderneren Variante ist, dass die im Hintergrund arbeitende Version von ESP-IDF aktualisiert wurde. Nutzte die Version 1.X des Arduino-ESP-Plugins ESP-IDF noch in Version 3.3, so vollzieht die „neueste“ Version die in ESP-IDF erfolgten Neuerungen nach und basiert auf einer brandaktuellen Version. Das ist relevant, weil es Unterstützung für ESP32-S2, ESP32-C3 und ESP32-S3 ermöglicht – wie unter https://www.mikrocontroller.net/topic/523923#new beschrieben ist sind diese neueren Versionen des Chips nur für IDF-Versionen ansprechbar, deren Toolchain auf CMake basiert.
Spezifischerweise nennt Espressif im unter https://github.com/espressif/arduino-esp32/releases bereitstehenden Change Log folgende Verbesserungen:

1Support for ESP32S2.
2 Support for ESP32C3.
3 Upload over CDC.
4 Support for the KSZ8081 (Ethernet PHY).
5 LittleFS update for partition label and multiple partitions.
6 Added support for RainMaker.
7 BLE5 features for ESP32C3 (ESP32S3 ready).
8 ESPTOOL update.
9 Added FTM support.
10 Online Documentation added. See here.
11 USB MSC and HID support (ESP32S2 only).
12 UART refactoring (SerialHardware).
13 New examples.
14 Boards added.
15 Bugs fixed.

Änderungen auf Kommandozeile

Mit der Arduino CLI – hinter der Abkürzung verbirgt sich der Begriff Command Line Interface – steht seit einiger Zeit ein Werkzeug zur Verfügung, das die Auslösung von Build- und Deploymentprozessen auf Kommandozeilenebene erlaubt. Mit Version 0.19.0 führte das Entwicklerteam Änderungen an der inneren Struktur durch.
Neben Stabilitätsverbesserungen bringt die neue Version ein als Pluggable Discovery bezeichnetes Feature mit. Die unter https://arduino.github.io/arduino-cli/0.19/platform-specification/#pluggable-discovery im Detail beschriebene Programmierschnittstelle ermöglicht das Anmelden zusätzlicher Boards wie der Teensy-Serie, die sich zudem über neue Interfaces ansprechen lassen:

1. . . the possibility to support more and more boards (such as the Teensy), and also new ways of uploading to boards, like via WiFi, Bluetooth, SSH, CAN bus and anything that comes to mind . . .

Leider gingen diese Anpassungen an der Systemstruktur mit umfangreichen Änderungen im Verhalten der Werkzeuge einher. Die unter https://arduino.github.io/arduino-cli/0.19/UPGRADING/ bereitstehende Änderungsliste zeigt beispielsweise Veränderungen im Aufbau der von Kommandos zurückgelieferten JSON-Strings – wartet ein Skript auf eine bestimmte Ausgabezeile, so scheitert es nach dem Update.
Analoge Änderungen finden sich auch in der Go-Bibliothek, die die Einbindung bzw. Steuerung von Arduino-Deployments unter Nutzung der Programmiersprache Go erlauben.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

MicroEJ: JavaScript-Unterstützung angekündigt, Python und Kotlin ante portas

MicroEJ – das Unternehmen ist vor Allem für seine Java-Runtime für diverse Microcontroller bekannt – bietet mit Kifaru eine JavaScript-Runtime für diverse Microcontroller an.

von Tam HANNA

BILDQUELLE: https://docs.microej.com/en/latest/_images/js_runtime.png

Was bringt es?

JavaScript-Entwickler sind Massenware: es gibt kaum eine (drittklassige) Fachhochschule, die nicht pro Semester einige Dutzend davon auswirft. Heutige Hardware stellt hohe Ansprüche an das Aussehen des Benutzerinterfaces – wer nicht echtzeitkritische Aufgaben unter Nutzung einer billigeren Arbeitskraft realisiert, spart Kosten.

Wie funktioniert es?

MicroEJ realisiert die JavaScript-Ausführungsumgebung unter Nutzung des bekannten Java-Interpreters. Java-Entwickler müssen ihre MicroEJ-Applikation im ersten Schritt um ein derzeit nur auf Anfrage erhältliches Paket mit dem JavaScript-Interpreter ergänzen, und können diesen danach nach folgendem Schema auf JavaScript-Code loslassen:

1import com.microej.js.JsErrorWrapper;
2import com.microej.js.JsCode;
3import com.microej.js.JsRuntime;
4
5
6
7JsCode.initJs();
8JsRuntime.ENGINE.runOneJob();
9JsRuntime.stop();

Der JavaScript-Interpreter ist dabei auf die Ausführung von Code beschränkt – es gibt kein an Cordova und Co erinnerdes WebView-Steuerelement, in dem GUI-Stacks wie jQuery UI oder Telerik ausgeführt werden können.

Für die eigentliche Realisierung der JavaScript-Ausführung setzt MicroEJ dabei auf die Nashorn-Bibliothek aus dem JDK 1.8. Für Sie als Entwickler bedeutet dies, dass der JavaScript-Code – siehe Abbildung – noch auf der Workstation in Java transpiliert wird.

BILDQUELLE https://docs.microej.com/en/latest/ApplicationDeveloperGuide/js/internals.html

Das bedeutet allerdings nicht, dass der Java- und der JavaScript-Code isoliert sind: es ist erlaubt, Funktionsaufrufe aus den beiden Domänen auszulösen. Der dafür notwendige Code ist allerdings vergleichsweise komplex, weshalb Ping-Pong-Spiele zwischen den Domänen auch hier ein klassisches Antipattern darstellen.

Noch mehr Hochsprachen

Die zur Mobilisierung von JavaScript verwendete Modularisierungstechnik lässt sich auch auf andere Hochsprachen anwenden. In der Dokumentation zum derzeit nur auf Anfrage erhältlichen JavaScript-Transpiler findet sich folgende Passage:

1Additionally, Kotlin and Python programming languages development frameworks will soon be released to embrace an even broader engineering workforce. Stay tuned or contact us for more info!

– via https://developer.microej.com/microej-kifaru-javascript-development-environment-embedded-devices/

Lohnt es sich?

MicroEJ mag für erste Experimente kostenlos sein: im produktiven Einsatz fallen nicht unerhebliche Kosten an. Personen mit großem Java-IP haben keine wirkliche Wahl, was MicroEJ weidlich ausnutzt.

Für Besitzer von in JavaScript gehaltenem geistigen Eigentum sieht die Lage etwas anders aus: auch wenn die unter https://www.neonious.com/ befindliche Neonious die Arbeiten an ihrem ESP32-Port Low.js mittlerweile zu Gunsten einer Kryptowährung reduziert hat, ist das Produkt trotzdem ein attraktiver Alternativkandidat.

Mehr Ressourcen

Einstiegs-Portal => https://developer.microej.com/microej-kifaru-javascript-development-environment-embedded-devices/

Entwicklerdokumentation => https://docs.microej.com/en/latest/ApplicationDeveloperGuide/js/index.html

Einschränkungen der JavaScript-Syntax => https://docs.microej.com/en/latest/ApplicationDeveloperGuide/js/limitations.html#js-limitations

Disclaimer aus Ehrlichkeitsgründen: der Autor bekam die Presseinformationen bereits am 30. August.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Arduino Edge Control: Arduino-Board für Smart Farming

Das Arduino-Team arbeitet daran, seine Produkte nicht als reine Maker-Boards zu präsentieren. Man strebt mit der Arduino Pro-Serie nach dem industriellen Turn Key-Bereich. Mit dem Arduino Edge Control steht nun ein erstes Board zur Verfügung, das sich auf die Bedürfnisse intelligenter Farmen konzentriert.

von Tam Hanna

Die als Teil der Arduino Pro-Familie vorgesehene Platine vertieft die Zusammenarbeit zwischen Arduino und uBlox. Als Hauptprozessor kommt diesmal ein Nina B306 zum Einsatz – der mit 64 MHz laufende Cortex M4F-ARM-Prozessor ist über die Arduino IDE programmierbar, für die drahtlose Kommunikation steht Bluetooth LE zur Verfügung.
Interessant ist, dass das Board zusätzliche Kommunikationsschnittstellen erlernt: dabei kommen, wie in der Abbildung gezeigt, entweder ein oder zwei zusätzliche Arduino MKR-Boards zum Einsatz, die als eine Art Plug-In eingebaut werden. Die Kommunikation zwischen ihnen und der Hauptplatine erfolgt dann per I2C oder UART.

Eingabe-Ports für den Agrarbetrieb.

Arduino sieht den Edge Control als ausschliessliches Agrar-Werkzeug. In der dazugehörenden Dokumentation fühlt man als Soll-Anwedungsfall neben der Kultivation von Pilzen (kann extremst (!!!) lukrativ sein) und der Automatisierung von Glashäusern explizit auch die hydroponische Erzeugung von Pflanzen an.
Für die eigentlichen Agrar-Anwendungen sind laut dem unter https://content.arduino.cc/assets/AKX00044-Datasheet.pdf bereitstehenden Datenblatt dedizierte“ I/O-Subsysteme vorgesehen.

1Acht 5VIOSensoren
2Sechzehn hydrostatische Sensoren
3Vier Halbleiterrelais
4Sechzehn generische Ausgänge mit LatchingFähigkeit

Allen I/O-Subsystemen ist gemein, dass sie unter Nutzung eines TCA6424-Expanderbausteins aus dem Hause Texas Instruments entstehen. Dies dürfte die maximal erreichbare Performance stark limitieren – Farming ist allerdings, was man in aller Ehrlichkeit zugeben muss, keine Aufgabe, die hohe Echtzeit-Anforderungen stellt.

Weitere neue Hardware.

Der Edge Control ist nicht die einzige „Neuerung“ im Hause Arduino. Im für die Ankündigung verwendeten Newsletters findet sich auch die folgende Grafik, die auf weitere, neue Hardware hinweist.

Lohnt es sich?

Der in Ungarn ansässige Autor dieser Zeilen bekommt permanent Agrar-Anfragen vorgelegt: wer nicht im Großbauern-Bereich tätig ist, findet dabei als Konstante das extrem geringe Budget. Mit dem um 169 Euro erhältlichen Board lässt sich der „elektrische“ Teil der Lösung mit wenig Mannstunden realisieren – ein durchaus positiver Aspekt. Ob man das Board allerdings in Großserie einsetzen möchte, ist eine andere Frage.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

ESP-DL: hardwarebeschleunigtes maschinelles Lernen für ESP32

Neben Optimierungen im Bereich der Entwicklungswerkzeuge hat Espressif eine neue API angekündigt, die die Erledigung von Machine-Learning-Aufgaben unter Nutzung der in neueren ESP32-Kernen enthaltenen ML-Hardwareressourcen beschleunigt.

von Tam HANNA

Worum geht es hier?

Die einst als reine „Funk-Knechte“ für andere Mikrocontroller gestartete ESP-Familie bekommt im Laufe der letzten Monate fortgeschrittene Funktionen eingeschrieben, die in vielen Applikationen den Host-Mikrocontroller arbeitslos machen.

Mit dem noch nur in Samplemengen verfügbaren ESP32-S3 stellte Espressif eine an Kendryte K210 und Maxim MAX78000 erinnernde Hardware-Beschleunigerengine zur Verfügung, die in ML-Aufgaben anfallende Tasks stark beschleunigt.
Spezifischerweise verspricht Espressif für ein – natürlich handoptimiertes – Modell auf einem S3 folgende Ergebnisse:

1MNIST::forward: 6103 μs
2Prediction Result: 9

Führt man dasselbe Modell hingegen auf einem normalen ESP 32 aus, so fällt die Performance wesentlich bescheidener aus:

1MNIST::forward: 37294 μs
2Prediction Result: 9

Wie bei vielen anderen ML-Beschleunigen gilt, dass die „Krux“ in der Software begraben liegt – eine Aufgabe, der Espressif mit der DL-Bibliothek Abhilfe verschaffen möchte.

Wie funktioniert es für den Embedded-Entwickler.

Die Erzeugung von ML-Modellen ist eine Aufgabe, die man sich als Embedded-Entwickler tunlichst vom Leib halten sollte. Wir wollen für unsere Experimente deshalb das unter https://github.com/espressif/esp-dl/tree/master/examples/cat_face_detect bereitstehende Codebeispiel verwenden, das Katzen zu erkennen sucht.
Am interessantesten ist die Arbeitsschleife, die nach folgendem Schema aufgebaut ist:

1#include <stdio.h>
2#include “image.hpp”
3#include “cat_face_detect_mn03.hpp”
4#include “dl_tool.hpp”

Neben der Datei “cat_face_detect_mn03.hpp”, die das eigentliche Modell bereitstellt, enthält die Datei “image.hpp” das zu verarbeitende Bild. Die von Espressif bereitgestellten Beispiele arbeiten ausschließlich mit in Form von C-Arrays vorliegenden Bilddaten, die das unter https://github.com/espressif/esp-dl/tree/master/tools/convert_tool befindliche Werkzeug auf der Workstation erzeugt.

Der nächste Akt der Arbeitsschleife ist das Laden der eigentlichen Modell-Logik:

1extern “C” void app_main(void)
2{
3 dl::tool::Latency latency;
4 // detector
5 CatFaceDetectMN03 cat_face_detect(0.4F, 0.3F, 10, 0.3F);
6
7 // inference
8 latency.start();
9 std::list<dl::detect::result_t> &results = cat_face_detect.infer((uint8_t *)IMAGE_ELEMENT, {IMAGE_HEIGHT, IMAGE_WIDTH, IMAGE_CHANNEL});
10 latency.end();
11 latency.print(“Inference latency”);
12
13 int i = 0;
14 for (std::list<dl::detect::result_t>::iterator prediction = results.begin(); prediction != results.end(); prediction++, i++)
15 {
16 printf(“[%d] score: %f, box: [%d, %d, %d, %d]n, i, prediction->score, prediction->box[0], prediction->box[1], prediction->box[2], prediction->box[3]);
17 }
18}

Der Rest des Codes ist dann gewöhnliches Betreiben eines Hardware-Beschleunigers. Informationen wandern im ersten Schritt in die dafür bereitgestellten Register, aus denen wir die Ergebnisse danach wieder abernten.
Ausgabewert des Programms sind dabei Koordinatenwerte, die – siehe auch die Abbildung – für vom ML-Modell als relevant erkannte Teile des Bildes markieren. Für ihre Visualisierung steht am Desktop ebenfalls ein Werkzeug zur Verfügung, das sie nach folgendem Schema aufrufen:

1python display_image.py i ../cat_face_detect/image.jpg b “(122, 2, 256, 117)”

(Bildquelle: https://github.com/espressif/esp-dl/blob/master/examples/cat_face_detect/result.png)

Erzeugung hauseigener Modelle.

Obwohl Espressif im unter https://github.com/espressif/esp-dl/tree/master/include/model_zoo bereitstehenden und apart als Model Zoo bezeichneten Repository eine Gruppe schlüsselfertige Modelle für ESP32-Entwickler bereitstellt, wünscht man sich in der Praxis die Verwendung „hauseigener“ Modelle.
Informationen dazu, wie man ein vorliegendes Modell für den ESP32 einsatzbereit macht, finden sich in der unter https://github.com/espressif/esp-dl/tree/master/tutorial bereitstehenden fünfstufigen Anleitung.
Offensichtlich ist schon hier, dass zur Nutzung Handarbeit erforderlich ist. Die einzelnen „Layers“ eines Modells muss der Entwickler beispielsweise von Hand in der von Espressif bereitgestellten Modell-Basisklasse anlegen:

1class MNIST : public Model<int16_t>
2{
3private:
4 Conv2D<int16_t> l1; // a layer named l1
5 DepthwiseConv2D<int16_t> l2_depth; // a layer named l2_depth
6 Conv2D<int16_t> l2_compress; // a layer named l2_compress

Analoges gilt auch für die Initialisierung, deren Generierung – zumindest zum Zeitpunkt der Drucklegung – ebenfalls Handarbeit voraussetzt:

1class MNIST : public Model<int16_t>
2{
3 // ellipsis member variables
4
5 MNIST() : l1(Conv2D<int16_t>(2, get_l1_filter(), get_l1_bias(), get_l1_activation(), PADDING_VALID, 2, 2, “l1”)),
6 l2_depth(DepthwiseConv2D<int16_t>(1, get_l2_depth_filter(), NULL, get_l2_depth_activation(), PADDING_SAME, 2, 2, “l2_depth”)),
7 l2_compress(Conv2D<int16_t>(3, get_l2_compress_filter(), get_l2_compress_bias(), NULL, PADDING_SAME, 1, 1, “l2_compress”)),

Lohnt es sich?

Wer auf einem ESP32 ML-Aufgaben mit hoher Performance ausführen möchte, ist gut beraten, dem unter https://github.com/espressif/esp-dl/ bereitstehenden GitHub-Repository Aufmerksamkeit zu geben. Auch wenn die Lernkurve des ML-Frameworks mit Sicherheit steil ist, dürfte das manuelle Entwickeln von einer hardwarebeschleunigten Engines für den ESP32 noch viel arbeitsamer sein.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Espressif: Klarstellung der IDE-Roadmap und der Pläne für AWS

In einer Gruppe von Pressemeldungen hat Espressif heute einige Ankündigungen durchgeführt, die das ESP32-Ökosystemen „als Ganzes“ betreffen.
von Tam HANNA

Worum geht es hier?

Der ESP32 ist ein leistungsfähiger, aber preisgünstiger WLAN-Bluetooth-Mikrocontroller. Nach dem eher unfallartigen Erfolg des ESP8266 hat das in Shanghai ansässige Unternehmen eine Gruppe von Nachfolge-Controllern auf den Markt gebracht, die sich großer Popularität sowohl bei Makern als auch bei professionellen Anwendern erfreuen.

ESP-IDF: neuer Installer, endgültige Abkündigung von GNU Make

Dass man bei der Arbeit mit ESP-EDF auf Kommandozeilenebene arbeitet, ist erwartet. Um Quereinsteigern, die vollgrafische Systeme wie MPLAB oder CUBE gewohnt sind, das Leben zu erleichtern, führt Espressif Anpassungen an der Entwickler-Toolchain durch.
Anstatt die eigentliche Kompilation – wie bisher – unter Nutzung von GNU Make zu erledigen, kommt seit 2018 CMake zum Einsatz. Espressif kündigt nun „offiziell“ an, neue Chips nur noch in der CMake-Variante zu unterstützen:

1Since then, new features, such as support for ESP32S2, ESP32C3 and ESP32S3 chips, were added to the CMakebased build system only.

Die Installation von ESP-IDF unter Windows erwies sich in der Vergangenheit als haarig.
Mit dem ESP-IDF Tools Installer schickt Espressif ein Werkzeug ins Rennen, dass die Installation der Werkzeuge der notwendigen Produkte automatisiert durchführt. Administratoren größerer Firmen-Netzwerke können einen Offlineinstaller paketieren, der Workstations ohne Zugriff auf das Internet mit den notwendigen Ressourcen ausstattet. Weitere Informationen hierzu finden sich unter der URL https://github.com/espressif/idf-installer.
Zu guter Letzt kündigt Espressif an, mit Container-Systemen zu arbeiten. Zum Zeitpunkt der Abfassung dieses Artikels finden sich in der Dokumentation sowohl Hinweise auf Docker als auch auf Hyper-V.

IDEs: Plug-Ins für Eclipse und Visual Studio Code

Espressif orientiert sich im Bereich der Ökosystem-Entwicklung an der alten STMicroelectronics-Methode: „desto mehr“ an Tooling, desto besser. Der Gutteil der Entwickler dürfte – nach Ansicht des Autors – entweder auf Kommandozeile arbeiten, oder kommerzielle IDEs (Stichwort z.B. Segger) verwenden.

Das ESP32-Plugin steht im VS Code-Erweiterungssystem zum Download bereit

Seit 2019 bietet Espressif zwei hauseigene Plug-Ins an, die entweder Eclipse oder Visual Studio Code (nicht zu verwechseln mit der nur unter Windows lauffähigen Visual Studio-IDE) an. In beiden Systemen verspricht Espressif dabei neben Unterstützung für den bekannten seriellen Flash-Prozess auch die Möglichkeit, auf „unterstützten“ Chips (S3 und C3) Programmiervorgänge per JTAG vorzunehmen. Zu guter letzt verspricht Espressif, Debugger-Funktionen zu offerieren. Wenn Sie eine der IDEs verwenden, sollten Sie die folgenden Links ansehen:
VS Code → https://github.com/espressif/vscode-esp-idf-extension
Eclipse → https://github.com/espressif/idf-eclipse-plugin

Formalisierung der AWS-Unterstützung für ESP32.

Amazon und EspressifaArbeiten im Bereich Cloud Services seit langer Zeit zusammen: eine logische Partnerschaft, bietet Espressif doch preiswerte Chips an, die dank ihrer WLAN-Transmitter problemlos ins Internet kommen. „Bisher“ gab es – siehe auch die Abbildung – zwei Wege, um eine ESP32-Anwendung mit AWS zu integrieren.

Zwei Wege führen zu AWS am ESP32

Neben der von Amazon bereitgestellten FreeRTOS-basierten Arbeitsumgebung gibt es ein SDK, das sich auf das Bereitstellen der Cloud-Funktionen konzentriert und kein Echtzeitbetriebssystem enthält.
Die „Freiheit“ erkauften sich Entwickler bisher durch einen reduzierten Funktionsumfang. Mit Version 202103.00 legt Espressif insofern nach, als nun die folgenden Bibliotheken Unterstützung finden:

1AWS Standard LTS libraries:
2 coreHTTP
3 coreJSON
4 coreMQTT
5 corePKCS11
6
7AWS LTS libraries:
8 AWS IoT Device Shadow
9 AWS IoT Jobs
10 AWS IoT OTA

Mehr Informationen zu den „Neuerungen“ finden sich in der unter https://www.espressif.com/en/news/LTSrelease bereitstellenden Presseankündigung, die unter anderem eine Gruppe von Codebeispielen mit „lebendigen Demonstrationen“ enthält.

Es gibt mehr!

Im Rahmen des heutigen Pressemeldung hat Espressif außerdem eine API zur Ausführung von neuronalen Netzwerken und anderen Aufgaben des Machine-Learning angekündigt. Wir werden diese in einem Folgeartikel beleuchten.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Turing Pi 2: Spezifikationen bekannt gegeben

Die finalen Spezifikationen des Mini-Clusters stehen mittlerweile fest. Im Gegensatz zum Vorgänger unterstützt der Turing Pi 2 neben dem aktuellen Raspberry Pi Compute Module nun auch Nvidia Jetson.

Das Board ist im mini-ITX-Formfaktor gehalten und kann mit einem 24-Pin ATX-Netzteil versorgt werden. Je nach Bestückung kann mit bis zu 80 Watt kalkuliert werden. Dies erlaubt die Nutzung kompakter DC/DC-Module. Insgesamt können wahlweise vier Raspberry Pi 4 Compute Modulen oder Nvidia Jetson Modulen als Nodes bestückt werden, wobei sich diese auch gemischt verwenden lassen. Zusätzlich kann das System durch zwei mini PCIe Gen2 und zwei SATA III Anschlüsse erweitert werden. Neben einem integrierten Managed Switch stehen zwei Gigabit Ports, USB 3.0 und HDMI zur Verfügung. Ein Raspberry Pi kompatibler GPIO Header ist ebenfalls vorhanden.

Neben der Unterstützung aktueller Einplatinencomputer wurde gegenüber dem Vorgänger auch ein Managementcontroller hinzugefügt, über den sich der Cluster warten lässt. In Verbindung mit dem integrierten Switch und einer eigenen Firmware kann so über das Netzwerk auf die seriellen Schnittstellen der einzelnen Module zugegriffen oder ein Betriebssystem installiert werden.

Mit genaueren Angaben des Erscheinungsdatums und Preises dürfe in den nächsten Wochen zu rechnen sein, erste Lieferungen sollen dann im ersten Quartal des kommenden Jahres erfolgen. Im Anschluss ist auch der Verkauf eigener Module in Planung. Wer nicht so lange waren kann und noch einen Schwung älterer Compute Module übrig hat, kann sich den Vorgänger Turing Pi 1 ansehen. Alternativ gibt es mit dem SOPINE Clusterboard von Pine64 einen ebenfalls interessanten Ansatz.

Bild: turingpi.com

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Meadow F7: Dateisystem, neue I2C / SPI-API, Refactorings für neue Zielplattformen

Mit Beta 5.2 führt das Entwicklerteam um Bryan Costanich diverse „Verbesserungen“ an der API ihres Embedded-.net-Systems durch.

Worum geht es hier?

Microsofts bisherige Versuche im Embedded-Bereich waren im allgemeinen wenig erfolgreich: der Gadgeteer war zu früh am Markt, während die NetDuino-Produktlinie aufgrund finanzieller Malversationen mit einem Smartwatch-Projekt über den Jordan ging.
Der einst bei Xamarin tätige Bryan Costanich entwickelt mit dem Meadow F7 einen kombinatorischen Prozessrechner, der einen für die Ausführung der .net-Payload zuständigen STM32-Kern und einen ESP32 als WLAN-und Bluetooth-Funkmodul einspannt. Das Produkt ist seit einiger Zeit am Markt (siehe Unboxing der ersten Variante unter https://www.youtube.com/watch?v=8uU0TFuvgis), und nähert sich nun der Fertigstellung.

Persistierung von Dateien.

Die Meadow-API bietet Entwicklern seit einiger Zeit die Möglichkeit, Dateien im Flashspeicher abzulegen. Bisher wurden diese von der IDE im Rahmen jeder Neu-Auslieferung des Programms zerstört, was den Langfristnutzen reduzierte. Ab Beta 5.1 lässt die IDE diese Dateien beim Deployment neuer Applikationsprogramme “in Ruhe“.
Die API verhält sich sonst im allgemeinen so, wie man es von anderen .net-Dateisystem-APIs erwartet:

1 void EnumerateNamedDirectories()
2 {
3 Console.WriteLine(“The following named directories are available:”);
4 Console.WriteLine($t MeadowOS.FileSystem.UserFileSystemRoot: {MeadowOS.FileSystem.UserFileSystemRoot}”);
5 Console.WriteLine($t MeadowOS.FileSystem.CacheDirectory: {MeadowOS.FileSystem.CacheDirectory}”);
6 Console.WriteLine($t MeadowOS.FileSystem.DataDirectory: {MeadowOS.FileSystem.DataDirectory}”);
7 Console.WriteLine($t MeadowOS.FileSystem.DocumentsDirectory: {MeadowOS.FileSystem.DocumentsDirectory}”);
8 Console.WriteLine($t MeadowOS.FileSystem.TempDirectory: {MeadowOS.FileSystem.TempDirectory}”);
9 }
10
11 private void CreateFile(string path, string filename)
12 {
13 Console.WriteLine($“Creating ‘{path}/{filename}’…”);
14
15 if (!Directory.Exists(path)) {
16 Console.WriteLine(“Directory doesn’t exist, creating.”);
17 Directory.CreateDirectory(path);
18 }
19
20 try {
21 using (var fs = File.CreateText(Path.Combine(path,filename))) {
22 fs.WriteLine(“Hello Meadow File!”);
23 }
24 } catch (Exception ex) {
25 Console.WriteLine(ex.Message);
26 }
27 }

Weitere Code-Snippet finden sich in der unter https://github.com/WildernessLabs/Meadow.Core.Samples/tree/main/Source/Meadow.Core.Samples/OS/FileSystem_Basics bereitstehenden Beispieldatei.

Bekämpfung von Speicherlecks.

Managed Memory-Programmiersprachen gelten als immun gegen Speicherlecks. Leider ist das in der Praxis nicht so – es ist möglich, dass Datenstrukturen Verweise auf „temporäre“ Speicherbereiche nicht freigeben, und den Garbage Collector so am Einsammeln hindern.
Der Meadow F7 litt bisher unter derartigen Problemen im Bereich der Verarbeitung von über die REST-Schnittstelle eingehenden Anfragen. Mit Beta 5.1 verspricht das Entwicklerteam um Bryan Costanich, dass die Speicherlecks zur Gänze beseitigt sind – in der Ankündigung spricht man sogar davon, dass mehr als 200 000 Requests in einer Session verarbeitet wurden:

1Weve fixed nearly all of the leaks on web requests. Weve successfully tested 200k+ requests without blowing mem.

Stramlineing im Bereich der I2C-und SPI-API ist

Das permanente Allozieren und Freigeben von Speichebereichen erweist sich als Performancebremse. Ein Redesign der APIs für die beiden seriellen Busse ermöglicht dem Meadow das Durchführen vieler Transaktionen, ohne dabei permanente Allokationen durchzuführen. Lohn der Mühen ist eine „Erhöhung der Performance“.

Hardware-Verfügbarkeit angekündigt

Als vergleichsweise kleine Lieferant ist Wilderness Labs von den Problemen im Hause STMicroelectronics betroffen. F7-Boards sind zum Zeitpunkt der Abfassung dieses Artikels nicht im Handel verfügbar, die Wilderness Labs-Gruppe verspricht allerdings, im Laufe eines Monats wieder „neue“ Boards und Module anbieten zu können.
Außerdem findet sich in der Dokumentation an mehrerlei Stelle, beispielsweise folgendermaßen, ein Zitat ein Hinweise darauf, dass bald „neue“ Hardware ante Portas steht.

Nach Ansicht des Autors – dies ist explizit eine Eigenmeinung und stellt keine irgendwie geartete offizielle Ankündigung aus dem Hause Costanich dar – ist ein „Targeting“ des ESP32 sehr wahrscheinlich.

Unterstützung für Visual Studio Code verbessert.

F7-Applikationen lassen sich seit längerer Zeit nicht nur unter einer Vollversion von Visual Studio, sondern auch mit der Spar-Variante Visual Studio Code realisieren. Die neue Version des Visual Studio Code-Plug-Ins bietet Projektskelette an, die die Erzeugung von auf C#, F# und Visual Basic.net basierenden Projekten ohne Umweg in GitHub und Co. ermöglichen.

Lohnt es sich?

Microsoft-Embedded-Entwickler Leben lange leben schon lange nach dem britischen Konzept des Beggars can’t be Choosers – spätestens seit der Abkündigung der IoT-Variante von Windows 10 gibt es, insbesondere für Klein-Bastler, nicht viel Spielzeug. Wer eine kleine Aufgabe zu realisieren hat, und auf.net-Technologien setzen möchte, wird mit dem Meadow F7 – unter Weglassung der Verfügbarkeitsproblematik – glücklich.
Vor einem „größeren“ Deployment, insbesondere wenn sie das Meadow-System nicht in Form der Platine in ihre Hardware einbinden möchten, sollten Sie allerdings Kontakt mit dem Entwicklerteam aufnehmen um eine „individuelle“ Vorgehensweise abzusprechen.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More