MicroEJ mit neuen Bibliotheken, nRF Connect SDK mit Zephyr, neues EtherCat-Testtool

[Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)]

Die Java-Embeddedumgebung MicroEJ unterstützt ab Sofort Googles flatbuffers-Bibliothek und offeriert neue Ökosystemkomponenten. Nordic liefert derweil nRF Connect SDK in Version v2.0.0 aus, und stellt die Toolchain auf Zephyr um, was für Entwickler mit Umstellungsarbeit einhergeht.

MicroEJ – neuer Touchscreen-Kalibrator

Wer mit einem Palm-PDA aufgewachsen ist, kennt die berühmt-berüchtigte Kalibrationsroutine mit Sicherheit. Da resistive Touchscreens in MicroEJ-basierten Systemen nach wie vor weit verbreitet sind, stellt der Anbieter unter https://forum.microej.com/t/tool-java-touch-v2-1-0/1059 nun eine Beispielimplementierung eines Kalibrators zur Verfügung.

(Bildquelle: MicroEJ)

MicroEJ: Dependency Discoverer Tool aktualisiert

Der wichtigste Anwendungsfall für MicroEJ dürfte das Recyclieren von Projekten sein, die auf Desktop- oder Serverseite mit Java-Code arbeiten. Problematisch ist dabei, dass die MicroEJ-Umgebung trotz permanenter Erweiterungen nur einen Bruchteil der in anderen Umgebungen verfügbaren Abhängigkeiten befriedigen kann. Unter https://github.com/MicroEJ/Tool-ApiDependencyDiscoverer/tree/3.1.0 findet sich eine aktualisierte Version des Dependency Discoverers: er ist ein Werkzeug, das JAR-Files nach Dependencies untersucht, die unter MicroEJ nicht anzutreffen sind.

MicroEJ: Unterstützung für FlatBuffers

Googles unter https://google.github.io/flatbuffers/ dokumentiertes Serialisierungsformat FlatBuffers ist hoch optimiert und deshalb für den Datenaustausch mit Embeddedsystemen prädestiniert. Ab Sofort steht die Bibliothek auch für MicroEJ-Entwickler zur Verfügung. Wer zugreifen möchte, muss lediglich die Datei modules.ivy um folgende Passage erweitern:

<dependency org="com.google" name="flatbuffers" rev="1.0.0" />

Nordic nRF Connect 2.0 mit Erweiterungen ...

Nordic Semiconductor – das Unternehmen produziert Mikrocontroller mit integriertem Bluetoothchip, die beispielsweise im BBC MicroBit zum Einsatz kommen – hat nun eine neue Version des hauseigenen SDKs ausgeliefert. Die wichtigste Neuerung ist, dass es ab sofort (experimentielle) Unterstützung für Bluetooth LE Audio bietet. Dabei handelt es sich um ein neues Audioübertragungsprotokoll für Bluetooth, das geringeren Energieverbrauch und bessere Tonqualität bieten soll. Quasi nebenbei wurden die Kernkomponenten des SDKs nun gemäß Bluetooth-Standard in Version 5.3 zertifiziert. Neuerung Nummero zwei betrifft Unterstützung für das Smart Home-Protokoll Thread:

support for Thread v1.2 no longer being experimental. Both Homekit over Thread and Matter over Thread use Thread v1.2 libraries by default. nRF Connect SDK v2.0.0 is the first release with Thread v1.2 certification compliance for all supported nRF52 and nRF53 Series SoCs.

Zu guter Letzt bringt eine Verbesserung im SMP-Server schnellere Firmwareupdates per Bluetooth LE – in der Ankündigung verspricht Nordic eine Beschleunigung um den Faktor zwei bis drei.

… und Umstellungsaufwand für Entwickler

Im Rahmen der Einführung der neuen Funktionen führt Nordic – leider – auch eine Anpassung der Toolchain durch. Statt der GNU Arm Embedded Toolchain setzt man nun auf Zephyr, was Aktualisierungen der Projektstruktur voraussetzt. Im Bereich der IDE gab es ebenfalls Änderungen: Segger ist nun nicht mehr die präferierte IDE im Ökosystem:

Visual Studio Code extension IDE has replaced SEGGER Embedded Studio as the default supported IDE for working with the nRF Connect SDK.

(Bildquelle: Autor)

Nutzer des unter https://cbor.io/ im Detail beschriebenen Serialisierungsformats CBOR müssen Anpassungen an ihrer Applikation vornehmen – statt TinyCBOR kommt nun zcbor zum Einsatz. Weitere Informationen zu den Änderungen an einigen APIs finden Sie unter https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/migration/migration_guide_1.x_to_2.x.html.

EtherCAT Conformance Test Tool um neue Testfunktionen für Entwicklung erweitert

Das zum Feldbus EtherCAT gehörende Testprogramm liegt seit einigen Tagen in Version 2.3 vor. Für die neue Version verspricht das EtherCAT-Team – neben striktester Abwärtskompatibilität – neue Softwarefunktionen, die das Werkzeug als “Dummy-Gegenstelle” prädestinieren:

Die CTT-Erweiterungen, egal ob bei den Tool-Funktionalitäten oder der Test-Abdeckung, basieren wie gewohnt auf praktischen Anforderungen sowie Rückmeldungen der Gerätehersteller. So wurde das Tool im Lauf der Jahre vom reinen Test-Tool, das nach Abschluss der Entwicklung die Konformität überprüft, zur sehr hilfreichen „entwicklungsbegleitenden“ Software, mit der die EtherCAT-Geräte konfiguriert, in den gewünschten Zustand versetzt und gezielt zu bestimmtem Verhalten angeregt werden können. Dies setzt sich in vielen der neuen Funktionalitäten fort. So wurden zusätzliche Anwenderschnittstellen für die Steuerung und das Testen spezifischer EtherCAT-Protokoll-Eigenschaften sowie weitere Interfaces auf den unteren Schichten des ISO/OSI-Modells hinzugefügt. Komfortabel und besonders, weil nur selten von Tools unterstützt, ermöglicht das CTT nun den Lese- und Schreibzugriff auf die PHY-Register. Dies ist insbesondere während der ersten Hardware-Inbetriebnahme eine wertvolle Hilfe.
Alle CTT-Funktionalitäten sind auch für eine Skript-basierte Steuerung nutzbar, und sie erlauben somit automatisierte Testabläufe, welche in die übergreifende Geräte-Abnahme integriert werden können. Neben den vielen Funktionalitäten, die die EtherCAT-Implementierung an sich unterstützen, wurde auch der Kern des CTT erweitert: die Test-Abdeckung. Viele Halbleiter-Geräteprofile wurden in das standardmäßige Test-Set aufgenommen. Auch die Abdeckung für das Servo-Drive-Profile entsprechend der IEC 61800-7-2 (entspricht dem CiA DS402) konnte signifikant erhöht werden.

In eigener Sache: Antwort auf die Leserfrage zu HARWIN

Wir hatten unter Beitrag "Immer kleiner: Hersteller optimieren Gehäuse- und Steckergrößen" neue, kleinere Steckverbinder aus dem Hause Harwin vorgestellt, die Pick and Place-freundlich sind. Als Antwort auf die Leserfrage, wie die Verpackung aussieht, bekamen wir die folgenden beiden Bilder.

(Bildquelle: https://cdn.harwin.com/pdfs/M58-250R.pdf)

(Bildquelle: https://cdn.harwin.com/pdfs/M58-350R.pdf)

Anscheinend wird der “fleischige” Teil der Steckverbinder im Reel nach oben gedreht, die Maschine kann ihn also (bei ausreichender Vakuumkraft) mit einem für kleine SMD-Komponenten vorgesehenen Nozzle erbeuten.

[Michael D. (nospam2000)]

Tam H. schrieb:
> Im Bereich der IDE gab es ebenfalls Änderungen:
> Segger ist nun nicht mehr die präferierte IDE im Ökosystem:

Hoffentlich ist das jetzt besser. Mit diesem Segger Zeugs kam ich nie 
zurecht. Die spezielle Nordic Edition war dann auch hoffnungslos 
veraltet.

Ich denke es ist ein großer Schritt diesen geschlossenen Mist 
loszuwerden.

 Michael

[Matthias D. (marvin42)]

@Michael
...mit Segger kam ich gut zurecht, das hat bisher stabil und gut 
funktioniert. Den Upgrade auf NCS 2.0.0 und VS code habe ich nach 
einigen Stunden Install/Uninstall-Desaster abgebrochen und bin zurück 
auf die 1.9.1 gegangen. Auch der Toolchain-Manager 3.11.1 ist offenbar 
nicht ganz sauber. Nach der Installation von NCS 2.0.0 konnte ich 
plötzlich meine alten Projekte mit dem SES nicht mehr fehlerfrei 
compilieren usw - ich beschäftige mich aktuell mehr mit Nordic's 
Toolchain-Flausen als mit der eigentlichen Arbeit.
Darf ich dich fragen ob du Nordic/NCS privat oder beruflich nutzt ? - 
ich nutze es beruflich und bei deren Dauer-Update-Strategie ist mir 
schleierhaft wie man damit Produkte über Jahre hinweg supporten will.
Ich werde das nächste Nordic-Toolkit/Update erst mal nicht auf meinem 
Haupt.-Entwicklungs-PC testen sondern auf einem anderen Rechner, der 
Downgrade hat mich eine Nacht gekostet.

[Michael D. (nospam2000)]

Matthias D. schrieb:
> @Michael
> ich beschäftige mich aktuell mehr mit Nordic's
> Toolchain-Flausen als mit der eigentlichen Arbeit.

Das kann ich absolut so bestätigen und fasst das ganze Drama in einem 
Satz zusammen!

> Darf ich dich fragen ob du Nordic/NCS privat oder beruflich nutzt ? -

Ich nutze es nur privat. Vor Segger hat die Umgebung mit reinem make am 
besten funktioniert, das war nur leider sehr aufwändig zu installieren 
und schwierig auf einem anderen Rechner zu reproduzieren. Das lies sich 
dann auch in Eclipse integrieren und hat dann prinzipiell auch gut 
funktioniert. Ist schon einige Jahre her.

Nachdem ich dann irgendwann 3 unterschiedliche Eclipse Versionen 
gleichzeitig drauf hatte hat und es nur mit den alten Versionen 
funktioniert hat, habe ich wieder aufgegeben. Es war nicht mehr möglich 
die passenden Versionen der Nordic delivieries zu den aktuellen Eclipse 
Plugins zum laufen zu bringen.

Heute würde ich mir einen Docker container wünschen in welchem die ganze 
build Umgebung läuft. Das lässt sich hervorragend auf andere Rechner 
übertragen und alle Installationsschritte sind im Dockerfile genau 
dokumentiert. Beruflich mache ich builds nur noch in Docker containern.

> ich nutze es beruflich und bei deren Dauer-Update-Strategie ist mir
> schleierhaft wie man damit Produkte über Jahre hinweg supporten will.

Der eigentliche Punkt ist: Die sollen die Finger davon lassen eine 
proprietäre IDE zu liefern oder sich fest in eine solche zu integrieren!
Wenn die IDE dann noch eine kastrierte und veraltete Version ist hört 
der Spass echt auf.

Sie sollen nur ihre libraries in einer Form liefern damit man mit 
beliebigen IDEs (sowohl Typ als auch Version) und auch ohne IDE arbeiten 
kann. Die Beschreibung der Installation der Build Umgebung bitte als 
Dockerfile ausliefern. Es macht keine Spass auf mehreren Rechnern 
manuell diesselben 20 Installationschritte immer wieder zu machen und 
ist fehleranfällig.

Ich will meinen build in einer build pipeline machen in einem Docker 
Container (z.B. mit gitlab). Da kann ich eine Abhängigkeit zu einer IDE 
nicht brauchen die z.B. irgendwelche Definitionen in proprietären und 
IDE spezifischen Dateiformaten verwaltet.

Ich hoffe, dass der Schritt in Visual Studio Code in die richtige 
Richtung geht zu einem offenen System welches keine Abhängigkeiten zu 
proprietären Tools hat. Meine Freizeit ist mir zu schade um sie in 
irgendwelche proprietären Tools zu investieren. Wenn ich sie in Visual 
Studio Code investiere, dann nehme ich morgen einen anderen SoC und kann 
mein Tool know-how weiterverwenden.

  Michael

[Michael D. (nospam2000)]

Michael D. schrieb:
> Heute würde ich mir einen Docker container wünschen in welchem die ganze
> build Umgebung läuft.

Tatsächlich gibt es das: 
https://devzone.nordicsemi.com/guides/nrf-connect-sdk-guides/b/getting-started/posts/build-ncs-application-firmware-images-using-docker