PicoLog Cloud im Hands-On-Test

Mit PicoLog Cloud erweitert Pico Technology die hauseigenen PC-Oszilloskope und Data Logger um eine Cloudschnittstelle, die Messdaten aus dem Internet ansprechbar macht.

Worum geht es hier?

Die vom englischen Hardware-Hersteller Pico Technology gefertigten PicoScopes haben sich in vielen Bereichen der Messtechnik als Quasistandard etabliert. Mit PicoScope Cloud schicken offerieren die Briten einen Clouddienst, der das verteilte Arbeiten mit Messdaten ermöglicht.

Umfangreiche Hardwarekompatibilität

In der „offiziellen Ankündigung“ des Loggers, der auf Host-Seite unter Windows, Mac OS, Linux und Rasbpian ausführbar ist, findet sich folgende Kompatibilitätsliste:

1As always, PicoLog 6 in local capture mode is compatible with all existing data loggers and all realtime oscilloscopes (albeit with a sample rate limit of 1 kS/s).
2Using the PicoLog Cloud is also compatible with the same instruments, except the sample rate is limited to 1 S/s (sample per second) per channel.

Der Autor wird in den folgenden Schritten auf ein 5444D MSO setzen – an sich viel zu leistungsstarke Hardware. Das 16bit-Oszilloskop wurde vor einigen Jahren aus politischem Zelotismus angeschafft, um die damals neuen KURT-Superkondensatoren (siehe https://kurt.energy/) “als next Theranos zu entlarven“. Die Kondensatoren erwiesen sich allerdings als funktionsfähiges (und sehr nützliches) Produkt, und werden in einem zukünftigen Artikel vorgestellt.
In praktischen Anwendungen sind die ab etwa 160 EUR erhältlichen Low End-Modelle (PicoScope 2000) oder dedizierte Logger (PicoLog) meist mehr als ausreichend – die maximale Samplerate des Systems ist ein Sample pro Sekunde.

Installation und Inbetriebnahme

Besuchen Sie im ersten Schritt die URL https://www.picotech.com/downloads, um nach der Auswahl ihres Oszilloskops die passende Software herunterzuladen. Sie benötigen auf jeden Fall die Datei picolog-setup-6.2.0.exe, die sie danach wie ein gewöhnliches Windows-Programm anwerfen.
Nach der erfolgreichen Einrichtung verbinden sie PicoLog wie in der Abbildung gezeigt mit einem oder mehreren Kanälen des PicoScopes, die sie in einer realen Anwendung mit dem Device Under Test verbinden.

Im nächsten Schritt folgt ein Klick auf das Werkzeug-Symbol, um die Optionen einzublenden. Klicken Sie dort in der Rubrik Cloud auf die Option zum Anmelden, und loggen Sie sich auf der pico-Webseite ein. Pico Technology erlaubt dabei – unter anderem – die Verwendung eines Microsoft-Accounts: eine strategisch günstige Entscheidung, da der „Gutteil“ des Systems auf Azure-Technologie basiert.
Die Anmeldung erfolgt dann allerdings wieder von Hand – das AuthToken müssen sie von Hand eingeben. Nach dem erfolgreichen Einrichten der Cloud-Verbindung können Sie beim Starten der Datenausgabe wie in Abbildung zwei gezeigt entscheiden, ob die Informationen auf Ihrem Rechner, oder aber im Azure-Konto untergebracht werden sollen.

Wichtig ist in diesem Zusammenhang, dass Pico Technology nicht „unbegrenzt“ viel Speicherplatz zur Verfügung stellt. Der Autor entschied sich in den folgenden Schritten für eine 30 Minuten dauernde Aufnahme, nach dem Durcharbeiten des Assistenten beginnt die Workstation automatisch mit der Datenerfassung. Beachten Sie, dass die Datenübertragung über die Workstation erfolgt – ein Raspberry Pi ist eine preiswerte Alternative.

Entgegennahme der Picolog-Daten.

Für das Abernten der hochgeladenen Informationen müssen Sie danach die URL https://picolog.app/ öffnen – das Einloggen erfolgt abermals mit dem Account, mit dem sie „im ersten Schritt“ die Informationen in die Cloud gesendet haben. Das Teilen der Messreihen mit anderen Personen bzw Identitäten ist derzeit nicht vorgesehen.
Im Browser erscheint dann ein durchaus brauchbares Programm, mit dem sie die Daten auswerten und exportieren-beachten Sie, dass die Web-Applikation nicht in der Lage ist, die Einstellungen des Oszilloskops zu adjustieren.

Lohnt es sich?

Schon jetzt ist PicoLog Cloud ein interessantes Produkt, das die Analyse entfernter Datenpunkte bequemer macht: denken Sie an Temperaturen, Wasserstände oder die Feuchtigkeit in einem Weinkeller.
Zum direkten Fernsteuern oder Fern-Analysieren eines Oszilloskops ist PicoScope Cloud derzeit aber noch denkbar schlecht geeignet – schon deshalb, weil die maximale Samplerate von eine Quine pro Sekunde selbst für die langsamsten Signale nicht wirklich geeignet ist. „Schön“ wäre es, wenn ein PicoScope eine Trigger-Einstellung übernehmen könnte, und „erbeutete“ Datensätze in die Cloud sendet.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Neue nRF52-Revision erzwingt Updates der Nordic-Toolchain

Nutzer der von Nordic Semiconductor entwickelten nRF52-Bluetooth-SOC müssen mit Umstellungen rechnen. Eine neue Hardware-Revision erzwingt – unbedingt erforderliche – Aktualisierungen der Entwicklungswerkzeuge und Binärimages.

Worum geht es hier?

Wer ein Funkmodul mit Mikrocontroller sucht, denkt normalerweise instinktiv an Espressif. Das ist nicht unbedingt richtig – die nRF52-Serie von Nordic mag zwar keinen WLAN-Transmitter haben, hat aber geringeren Energieverbrauch und mehr Zertifikationen.
Am 12. Juni 2020 hat Nordic – siehe IN-133 unter https://infocenter.nordicsemi.com/pdf/in_133_v1.0.pdf -allerdings eine Schwachstelle in den Controllern gefunden, die den Zugriff auf an sich schreibgeschützte Chips ermöglicht:

1Failure of the APPROTECT configuration and debug port connectivity and function implies access to all memory on a device. A
2device that programmatically configured APPROTECT can have that configuration circumvented and program memory containing
3program instructions can be read out of the device. It is also possible to write to memory.

Behebung durch Firmware unmöglich =Y neue Hardware erforderlich

In der ursprünglichen Ankündigung der Schwachstelle fand sich folgende, wenig Erhellung versprechende Passage:

1Mitigations:
2
3Preventing physical access to the device, or detecting and responding to product enclosure breach, are mitigations for fault
4injection techniques.

Zur Lösung des Problems musste man im Hause Nordic Semiconductor Kontakt neue Revisionen des Chips nachschieben. Dabei sind sowohl nRF52832 als auch nRF52833 und nRF52840 betroffen – die Abbildung zeigt die „neuen“ Revisionen.

Verpflichtendes MDK-Update!

Mit dem „Release“ der neuen Revisionen der Hardware geht ein verpflichtendes Update der als MDK bezeichneten Entwicklungskomponente einher. In der Ankündigung warnt Nordic nach folgendem Schema davor, dass das Verwenden eines mit einer „älteren“ Version kompilierten Binärimages – immer – zur Deaktivierung des Debugger-Ports bei aktuellen Revisionen führt:

1If one of the mentioned new device revisions is programmed with software compiled with a version of the MDK prior to release 8.36.0, the debug port will be locked. It is strongly recommended upgrading to the latest MDK (at least version 8.40.2 or later)

Schon aus diesem Grund ist eine Aktualisierung unbedingt erforderlich. Im Laufe der nächsten Zeit werden die „alten“ Revisionen nämlich vom Markt verschwinden – bieten sie derzeit nRF-basierte Produkte an, so besteht nach Ansicht des Autors akuter Handlungsbedarf.

Aktualisierungen der weiteren Entwicklungssysteme

Die Anpassung des als MDK bezeichneten Header-Pakets “schlägt“ in den Rest des Nordic Semiconductor-Ökosystems durch. Die als nRF5 SDK bezeichnete Legacy-Entwicklungsumgebung wurde nach folgendem Schema aktualisiert:

1Highlights:
2
3 Added support for the new versions of the nRF52 devices:
4 nRF52820 revision 3
5 nRF52832 revision 3
6 nRF52833 revision 2
7 nRF52840 revision 3
8 (Note: Programming these requires nrfjprog v10.13 or newer.)
9 Updated nrf_oberon to v3.0.8.
10 Updated Mbed TLS to v2.16.10.

Auch für die „aktuelle“ Version nRF Connect for Desktop gibt es ein Update, das sie aufgrund des weiter oben erwähnten Problems mit MDK unbedingt einspielen sollten.

Weitere Informationen

Change Log für nRF5 SDK – nach unten scrollen, um IDE-spezifische Informationen zu erhalten
=> https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v17.1.0%2Findex.html

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

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