MicroEJ 6.0, Meadow 1.7, STM-Reorganisation und Handelskrieg

So ruhig sich die Nachrichtenlage zwischen den Jahren präsentierte, so aktiv wird es nun. Hier ein Round-Up, der auf Erscheinungen im Bereich Software, eine Reorganisation bei STMicroelectronics sowie einen potentiellen Handelskrieg zwischen den USA und China hindeutet - insbesondere Nutzer von QuecTel-Funkmodul sind gut beraten, diese News sorgfältig zu lesen.

US-Regierung: Chinas Dominanz im Bereich „Halbleiter großer Strukturbreite“ ist besorgniserregend.

Der im Halbleiterbereich ausgetragene Handelskrieg zwischen der Volksrepublik China und den USA konzentrierte sich bisher - man denke beispielsweise an die Querelen im Bereich NVIDIA - auf hoch leistungsfähige Chips mit sehr geringen Strukturgrößen. Laut dem unter https://asia.nikkei.com/Business/Tech/Semiconductors/U.S.-nervous-about-flood-of-older-generation-chips-from-China bereitstehenden Bericht von Nikkei richtet sich die Aufmerksamkeit der Senatoren nun auf „primitivere“ Bauteile wie Mikrocontroller, Spannungsregelung und ähnliches. Die US-Regierung hat nämlich festgestellt, in diesem (ob der hohen Stückkosten in Europa und den USA vergleichsweise unattraktiven, Anmerkung des Autors) Bereich von chinesischen Importen abhängig zu sein:

1

"China's looming dominance of the legacy chip market will create new national security and economic vulnerabilities for the U.S., but can only be addressed effectively through close collaboration with allies," he said, noting that Washington and its allies need to jointly address the issue.

Ärgerlich ist, dass die Senatoren von der Regierung verlangen, mit „allen möglichen Mitteln (sic)“ gegen die Importe vorzugehen - explizit wird im Dokument auch dazu aufgefordert, (wirtschaftsschädliche) Strafzölle zu erheben:

1

calling for urgent action to stem U.S. reliance on China's less advanced chips by using all means, including potential tariffs.

Nutzer chinesischer Bauteile sind deshalb gut beraten, die Entwicklung zu beachten und im Bedarfsfall bei ihrem Fertiger „Reserven“ anzulegen - es ist nach Ansicht des Autos nicht davon auszugehen, dass die von der Kostenstruktur her (Stichwort Umweltauflagen) absolut nicht konkurrenzfähige westeuropäische und amerikanische Industrie die entstehende Bedarfslücke, die übrigens die Inflation anheizen würde, füllen kann.

US-Thinktank möchte QuecTel zur Liste der „militärnahen“ Unternehmen hinzufügen.

Der Funkmodul-Hersteller QuecTel hat im Laufe der letzten Monate - sowohl aufgrund geringer Kosten, als auch aufgrund guter Produkte - erheblich an Marktanteilen gewonnen. Auch ein Automotive-Projekt des Autors basiert auf QuecTel-Technologie.

Bildquelle: Autor

Problematisch ist in diesem Zusammenhang, dass ein regierungsnaher Thinktank unter der URL https://selectcommitteeontheccp.house.gov/media/press-releases/gallagher-krishnamoorthi-urge-administration-blacklist-quectel-chinese damit beginnt, sich auf QuecTel „einzuschießen“. Spezifischerweise findet sich in der letzten veröffentlichten Meldung die folgende Passage, die die Alarmglocken bei QuecTel-Nutzern laut läuten lassen sollte:

1

Chairman Mike Gallagher (R-WI) and Ranking Member Raja Krishnamoorthi (D-IL) of the House Select Committee on the Strategic Competition Between the United States and the Chinese Communist Party wrote to Defense Secretary Lloyd Austin and Treasury Secretary Janet Yellen, outlining new information on Quectel Wireless Solutions’ problematic relationships with a civil-military fusion arm of the Chinese government and with blacklisted firms like Huawei, ZTE, and other Chinese military companies.

Hervorzuheben ist allerdings auch, dass eine Aufnahme in dieser Liste derzeit wenig „praktische“ Konsequenzen für die jeweiligen Unternehmen mitbringt. Unter https://www.lawfaremedia.org/article/chinese-military-civil-fusion-and-section-1260h-congress-incorporates-defense-contributors - die Webseite ist in Juristenkreisen durchaus gut Beleumundet - findet sich unter anderem folgende Passage, die diese Aussage bestätigt:

1

Section 1260H appears to be one piece of an ever-increasing mosaic of “naming and shaming” efforts by the United States vis-a-vis China

STMicroelectronics: Reorganisation zur Reduktion des Infightings

Der „Sektarianismus“ im Hause STMicroelectronics trägt mitunter seltsame Blüten - unter https://www.instagram.com/reel/C0zfPL2LP9j/ findet sich ein Beispiel, das erklärt, warum die hauseigenen Bluetooth-SOCs jahrelang nicht in den Rest des Mikrocontroller-Ökosystems eingebunden waren. In der unter https://newsroom.st.com/media-center/press-item.html/c3225.html bereit stehenden „Reorganisations-Pressemeldung“ kündigt SGS Thomson nun einen Anlauf zur Zähmung des Chaos an. Fortan soll es nur noch zwei Business Units geben, der für die dritte Business Unit verantwortliche Manager verlässt das Unternehmen mit sofortiger Wirkung:

1

    Analog, Power & Discrete, MEMS and Sensors (APMS), led by Marco Cassis, ST President and member of the Executive Committee; and

2

    Microcontrollers, Digital ICs and RF products (MDRF), led by Remi El-Ouazzane, ST President and member of the Executive Committee.

3

. . .

4

Concurrent with this new organization Marco Monti, ST President of the former Automotive and Discrete Product Group, will leave the Company.

Interessant ist außerdem, dass die MEMS- und sonstigen Sensoren nicht in die Digital-Abteilung kommen. Stattdessen finden sie sich im Analog-Team:

1

The APMS Product Group will include all ST analog products, including Smart Power solutions for automotive; all ST Power & Discrete product lines including Silicon Carbide products; MEMS and Sensors.

2

APMS will include two Reportable Segments: Analog products, MEMS and Sensors (AM&S); Power and discrete products (P&D).

Immerhin gilt fortan, dass das „Digital Team“ sowohl Mikrocontroller als auch RF-Produkte beaufsichtigen wird:

1

The MDRF Product Group will include all ST digital ICs and microcontrollers, including automotive microcontrollers; RF, ADAS, Infotainment ICs. MDRF will include two Reportable Segments: Microcontrollers (MCU); Digital ICs and RF Products (D&RF).

MicroEJ SDK 6.0 - Compilerchen, mache alles!

MicroEJ - das Unternehmen bietet eine Java-Runtime für diverse Mikrocontroller an - hat die hauseigene Produktpalette soeben auf Version 6 aktualisiert. Die Abbildung zeigt dabei den „Fokus“ der Neuerungen.

Bildquelle: https://www.microej.com/news/sdk6/

Wohl im Interesse besserer Breitenwirkung ist MicroEJ nun mit verschiedenen integrierten Entwicklungsumgebungen kompatibel; außerdem integriert sich der Embedded-Builder in die (unter Android mittlerweile zum Standard gewordene) Gradle-Kompilations-Toolchain. Interessant ist außerdem, dass sich die Beziehung zwischen Micro EJ und der einstigen „Gestations-Firma“ STMicroelectronics abkühlt. Wer die unter https://docs.microej.com/en/latest/SDK6UserGuide/gettingStarted.html bereitstehende Getting Started-Webseite des Produkts besucht, findet zum Zeitpunkt der Drucklegung nämlich wie in der Abbildung gezeigt nur NXP-bezogene Angebote.

Bildquelle: https://docs.microej.com/en/latest/SDK6UserGuide/gettingStarted.html

Doch damit nicht genug, gibt es außerdem eine Pressemeldung, die die Zusammenarbeit zwischen MicroEJ und NXP im Containerbereich verkündet:

1

Der neue NXP Platform Accelerator wurde gemeinsam mit MicroEJ entwickelt. Er nutzt Software-Container mit Standard-APIs, um in industriellen und IoT-Edge-Umgebungen eine Smartphone-ähnliche Flexibilität beim Software-Design zu ermöglichen. Das senkt die Entwicklungskosten der KundInnen und verkürzt die Markteinführungszeit

2

--- via https://www.nxp.com/company/about-nxp/nxp-and-microej-collaborate-to-use-software-containers-to-accelerate-embedded-platform-development:NW-NXP-MICROEJ-COLLABORATE-USE-SOFTWARE-CONTAINERS

Meadow F7: Version 1.7 mit neuer Threading-Komponente zur Zentralisierung von Sensordaten.

Bryan Costanichs Mannen sind ebenfalls nicht faul: In Version 1.7 beheben sie unter anderem den lang „lebenden“ Fehler in der Methode System.Debug.WriteLine.

Bildquelle: https://developer.wildernesslabs.co/Meadow/Release_Notes/v1/

Neben der Behebung des Fehlers steht ein neuartiger Weg zum „Einsammeln“ von Sensor-Informationen am Start. Im Prinzip handelt es sich dabei, wie unter https://blog.wildernesslabs.co/using-meadows-sensorservice-to-optimize-sensor-reads-into-a-single-thread/ en Detail beschrieben, um einen Weg zu einer Umgebung eine Einschränkung im NuttX-Echtzeitbetriebssystem:

1

Why is this a problem? Well, the Meadow F7-based platforms are using a micro-RTOS POSIX kernel called NuttX, and that RTOS is designed for running on embedded devices with limited resources. One of the constraints it has is the number of threads the entire system is allowed to create – in our current configuration that number is 32. That means that in total no more than 32 threads can be created. That number includes not just the application but also drivers, the base class libraries (e.g. the Task thread pool), the OS itself (e.g. networking), and even HCOM (the USB serial communication used to talk with your development machine). 32 threads really isn’t a lot, and if every sensor consumes one of those slots, a solution with several sensors can exhaust this pretty quickly.

Die SensorService-Klasse ist eine Art „intelligenter Thread“, der mehrere Sensoren gleichzeitig pollt. Seine Inbetriebnahme - sie ist ebenfalls unter der oben genannten URL en Detail beschrieben - kann durch ein einziges, nach folgendem Schema aufgebautes Statement erfolgen:

1

var mySensor = new BME688(Device.CreateI2CBus());

2

Resolver.SensorService.RegisterSensor(mySensor);

Tiobe: C# ist die schnellst-wachsende Programmiersprache.

Insbesondere „dienstalte“ Entwickler betrachten Systeme wie den Meadow F7 oft etwas schal. Dass ein in Assembler oder C gehaltenes System wesentlich effizienter ist, folgt aus der Logik. Andererseits gilt aber auch, dass Embedded-Entwickler vergleichsweise schwierig zu finden und teuer sind. Die vor wenigen Tagen veröffentlichte „aktuellste“ Ausgabe des Programmiersprachen-Popularitäts Benchmarks Tiobe enthält nun die folgende, durchaus interessante Passage:

1

For the first time in the history of the TIOBE index, C# has won the programming language of the year award. Congratulations! C# has been a top 10 player for more than 2 decades and now that it is catching up with the big 4 languages, it won the well-deserved award by being the language with the biggest uptick in one year (+1.43%). Runners up are Scratch (+0.83%) and Fortran (+0.64%). C# is eating market share from Java and is getting more and more popular in domains such as web application back ends and games (thanks to Unity). C# can be used free of charge and evolves in a steady pace, making the language more expressive every new release. C# is here to stay and might even surpass Java soon.

Weitere Informationen finden sich in der Grafik oder der Bildquelle.

Bildquelle: https://www.tiobe.com/tiobe-index/.

Rust: Embedded-Erweiterung in Version 1.0“ stabilisiert“.

Auch von der insbesondere von Espressif vorangetriebenen Mozilla-Ausgründung „Rust“ gibt es Neuigkeiten. Die schon seit einiger Zeit „quasi stabile“ und auf Rustisch als Crate bezeichnete Embedded-Erweiterungsbibliothek ist ab sofort „stabil“.

Bildquelle: https://blog.rust-embedded.org/embedded-hal-v1/.

Im Rahmen der „zur-Verfügung-Stellung bzw. Finalisierung“ der in der Crate implementierten Programmier-Interfaces gab es leider Breaking Changes, beispielsweise im Bereich der Timer. Unter https://github.com/rust-embedded/embedded-hal/blob/master/docs/migrating-from-0.2-to-1.0.md findet sich ein Migration Guide, der den „Umstieg“ demonstriert. Interessant ist außerdem, dass SPI-Geräte fortan „geteilt“ werden können - die Unterstützung für das „Makeln“ unter Nutzung des CS-Pins ist fortan auf Bibliotheksebene implementiert.

In eigener Sache: Noch keine Antwort von Radxa.

Trotz dem Versenden mehrerlei E-Mails gab es bisher keine Antwort zum X86-Board. Sollten weitere Informationen eintreffen, posten wir diese schnellstmöglich.