Frontplatten-Pool BLOG

Arduino aktualisiert den Nano 33 BLE Sense mit neuen Sensoren, während die Raspberry Pi Foundation sowohl für den Pi Pico als auch für die Vollversion Softwareupdates anbietet. Was es sonst Neues gibt, verrät dieser Roundup.

Arduino Nano 33 BLE Sense rev2 – identische Funktion, andere Sensoren

Der Arduino 3 unter Nano 33 BLE Sense wurde nun in einer neuen Variante angekündigt – als offizielle Begründung führt man an, die Nutzerzufriedenheit erhöhen zu wollen.

Bildquelle: https://docs.arduino.cc/hardware/nano-33-ble-sense-rev2

Als Hauptprozessor kommt dabei nach wie vor ein Nordic Semi nRF52840 zum Einsatz, der in Form eines UBlox Nina-Moduls vorliegt.
Die Änderungen betreffen vor allem die Sensorik. Statt dem STM LSM9D1 stehen nun ein BMI270 und ein BMM150 zur Verfügung – beide sind aus dem Hause Bosch SensorTec. Der Feuchtigkeits- und Temperatursensor Bauart HTS221 wird durch einen HS3003 von Renesas ersetzt – der einzige ST-Sensor am neuen Board ist das MEMS-Mikrophon.

Wer ein vorhandenes Arduino-Projekt an die „neue Situation“ anpassen möchte, muss auf die Bibliotheken Arduino_BMI270_BMM150 und Arduino_HS300x umstellen, der Rest des Codes soll kompatibel sein.
Interessant ist außerdem die Preiserhöhung: Ohne Header kostet die Platine nun $ 40,5, während der ursprünglich ausgelieferte Original-Nano nur 29,5 US-Dollar kostete. Wie immer ist es außerdem möglich, für rund zwei US-Dollar mehr eine Variante des Boards zu kaufen, die die Steckerleisten bereits eingelötet hat.

Raspberry Pi Pico: Grafischer Installer für das C-SDK.

Während die Inbetriebnahme der Raspberry Pi Pico-Entwicklungsumgebung auf einem hauseigenen Prozessrechner kein großes Problem darstellt, ist auf einem vollwertigen Rechner einige Arbeit erforderlich.
Nutzer von Windows finden unter der URL https://www.raspberrypi.com/news/raspberry-pi-pico-windows-installer/ einen Installer, der das direkte Deployment der Arbeitsumgebung samt Visual Studio Code ermöglicht. Nach dem Durchlaufen des Assistenten steht im Startmenü die Option “Pico – Visual Studio Code” zur Verfügung, die eine schlüsselfertig parametrierte Variante der IDE startet.

Raspberry Pi OS – Version 2023-02-21 ausgeliefert.

Für die großen Prozessrechner aus dem Hause Upton gibt es ebenfalls Neuerungen – Raspberry Pi OS Version 2023-02-21 basiert zwar nach wie vor auf Debian 11, bringt aber eine Gruppe von Verbesserungen mit:

Zu beachten ist allerdings, dass das Update laut der unter https://forums.raspberrypi.com/viewtopic.php?p=2083988 bereitstehenden Diskussion mitunter zu Problemen in der Bildschirmdarstellung führt – es ist empfehlenswert, vor einem Update eines Prozessrechners ein Image der SD-Karte zu ziehen.

.net-Runtime für Linux: Beginn der Arbeiten an RISC-V-Unterstützung.

Während die quelloffene RISC-V-Architektur im Laufe der letzten Monate von den diversesten Industriepartnern Unterstützung bekam, hat sich Microsoft im Bezug auf Windows für RISC-V bisher bedeckt gehalten. Die von der Community vorangetriebene .net-Runtime bekam vor wenigen Tagen das erste Update, das sich mit der Adaptierung der unter Linux laufenden Variante des Produkts für RISC-V auseinandersetzt.

Bildquelle: https://github.com/dotnet/runtime/pull/82382

Interessant ist daran, dass der Patch von Dong-Heon Jung hochgeladen wurde – er ist laut seiner GitHub-Biografie für Samsung tätig.

Bildquelle: https://github.com/clamp03

Für Retro-Fans: Neuimplementierung von Palm OS 5.

Wer – wie der Autor dieser Zeilen – mit Palm OS aufgewachsen ist, vermisst Betriebssystem und Handhead nach wie vor. Auf GitHub findet sich unter https://github.com/migueletto/PumpkinOS eine Reimplementierung, die Palm OS 5 mehr oder weniger zur Gänze nachzubilden sucht. Zum Zeitpunkt der Drucklegung gilt allerdings, dass Applikationen „neu kompiliert“ werden müssen: Pumpkin OS ist ein reines X86-System, und bietet derzeit keine PACE-Emulation an.

Bildquelle: https://github.com/migueletto/PumpkinOS

Microsoft Indien: Experimente mit ML auf extrem kleinen Maschinen.

Dass Machine-Learning-Prozesse im Allgemeinen mit hohem Rechenleistung-Bedarf einhergehen, dürfte spätestens seit Experimenten mit dem Stable Diffusion bekannt sein. Die indische Abteilung von Microsoft experimentiert indes seit längerer Zeit mit ressourcensparenden“ ML-Systemen, und bietet im unter https://github.com/krantikiran68/EdgeML/tree/shikhar_posit_vbw_haunter bereitstehenden GitHub-Repositorium einen Überblick der Forschungsergebnisse.

Ubuntu-Variante für Amateurfunk.

Amateurfunk ist seit langer Zeit eine Aufgabe, die „nicht allein im Labor“ durchgeführt wird, sondern in vielen Fällen von Rechner-Unterstützung profitiert. Mit dem von KB1OIQ entwickelten und unter https://sourceforge.net/projects/kb1oiq-andysham/ bereitstehenden Ham Radio Linux findet sich nun eine vergleichsweise Ressourcen-schonende Variante von Ubuntu Linux, die unter anderem die folgende Software schlüsselfertig mitbringt:

In der Ankündigung bzw. auf der Projekt-Startseite spricht der Entwickler von sehr geringen Mindest-Anforderungen an die Hardware. Dies erreicht das System unter anderem dadurch, dass er statt der normalerweise verwendeten Desktop-Umgebungen auf XFCE4 setzt.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Nutzer des RP2040-Mikrocontrollers konnten bisher einen Raspberry Pi Pico zu einer PicoProbe umwandeln. Mit der Raspberry Pi Debug Probe steht eine dedizierte Variante des Produkts zur Verfügung. Arduino arbeitet derweil daran, eine – an PicoVoice und Co. erinnernde – Spracherkennungsengine zu erzeugen. STM liefert neue Chips, während sich eine AI um Super Mario-Levels kümmert.

Arduino-Spracherkennung für ARM-basierte Boards.

„Volle“ Spracherkennung nach dem einst von Lernout und Hauspie in Dragon implementierten Verfahren ist nur eine von vielen Wegen, um die Mensch-Maschine-Interaktion per Sprache abzuwickeln. In der Praxis gibt es immer wieder Situationen, in denen die Interaktions-Aufgabe auf ein kleineres, „formalisiertes“ Vokabular eingeschränkt werden kann – ein gutes Beispiel wäre die einst von HP in verschiedenen Infinuum-Oszilloskopen implementierte Sprachsteuerung.

Bildquelle: Arduino

Dass diese „Reduktion der Aufgaben-Komplexität“ so gut wie immer mit einer Steigerung der Qualität der zurückgelieferten Ergebnisse einhergeht, sei schon im Interesse der Vollständigkeit angemerkt.
Mit der vom in Formosa ansässigen Unternehmen Cyberon zugekauften Arduino Speech Recognition Engine steht nun ein Spracherkennungssystem Verfügung, das auf Nano RP 2040 Connect, Nano 33 BLE Sense und Portenta H7 diese Funktion implementiert. Das Unternehmen bewirbt dabei unter anderem Unterstützung für 40 Sprachen – wichtig ist naturgemäß, dass „im ersten Schritt“ immer eine Definition der durchzuführenden Keywords erfolgt. Unter der URL https://tool.cyberon.com.tw/ArduinoDSpotterAuth/Document/Cyberon_DSpotterSDK_Maker_User_Guide_Arduino_Platform.pdf findet sich dabei ein Whitepaper, das die diversen durchzuführenden Schritte on Detail illustriert – interessant ist auch die unter https://docs.arduino.cc/tutorials/portenta-vision-shield/speech-recognition-engine bereitstehende getting started-Anleitung des Arduino-Teams.
Ob des „Zukaufs“ externer Technologie ist die Engine nicht kostenfrei. Die Arduino-Gruppe bietet – neben der nur bei Anfrage erhältlichen Pro-Lizenz – die beiden in der Abbildung gezeigten Varianten an.

Bildquelle: https://store.arduino.cc/products/speech-recognition-engine?variant=42904193204375.

Die nach Anmeldung kostenlos nutzbare Variante des Systems liegt dabei eine 20-sekündige „Denkpause“ ein, bevor das System auf Spracheingaben reagiert. Außerdem ist nach 50 erfolgreichen Erkennungs-Durchläufen ein Neustart des Boards obligatorisch – eine weitere Maßnahme, um die „Kauf-Motivation“ zu erhöhen.

Raspberry Pi Debug Probe hilft beim Debugging mit RP2040

Bei der Arbeit mit dem Raspberry Pi Pico kommt gerne die in der Abbildung gezeigte PicoProbe zum Einsatz – wer ihr ein 3-D-gedrucktes Gehäuse spendiert, erhält eine durchaus komfortable Arbeitsumgebung.

Bildquelle: https://github.com/raspberrypi/picoprobe.

Mit der soeben angekündigten Raspberry Pi Debug Probe steht ein um rund zwölf US-Dollar erhältliches System zur Verfügung, das sich wie in der Abbildung gezeigt präsentiert.

Bildquelle: Raspberry Pi Foundation.

Für die Bedürfnisse von HP 2040-Nutzern ist das Board unter anderem insofern optimiert, als es Unterstützung sowohl für SWD (die Raspberry Pi-Variante von JPEG) als auch für „serielles Debugging“ mitbringt.

Bildquelle: Raspberry Pi Foundation.

Als Debugging-Software kommt dabei wie bei anderen Debugging-Fällen GDB zum Einsatz – unter https://www.raspberrypi.com/documentation/microcontrollers/debug-probe.html findet sich ein leicht nachvollziehbares Tutorium, dass die Inbetriebnahme der Software erklärt.
Interessant ist außerdem, dass der Schaltplan zur Verfügung steht – auch er findet sich in der weiter oben genannten GDB-Bedienungsanleitung.

STMicroelectronics: U5-Serie ab sofort mit mehr Speicher

Im Hause STM gibt es einen Neuzugang: der STM32U5 ist ab Sofort in neuen Varianten erhältlich, die mehr Remanentspeicher offerieren:

STM betont außerdem die soeben erreichte NIST-Zertifizierung für den am Chip verbauten Zufallszahlengenerator:

Wichtig auch noch die (geplante) Verfügbarkeit:

AI-getriebener Levelgenerator für Super Mario.

Zu guter Letzt noch ein „innovatives“ Anwendungsbeispiel für künstliche Intelligenz. Auf GitHub findet sich im unter https://www.hackster.io/news/let-s-a-go-mariogpt-3913da0c05d6 bereitstehenden Repositorium ein Level-Generator, der – nach Zuruf – Bitmaps auswirft, die zumindest in der Theorie spielbare Levels für Nintendos Klassiker Super Mario darstellen.
Neben dem Witzigkeitswert ist das Repositorium auch deshalb interessant, weil die dort befindlichen Quellcodes eine exzellente Demonstration der Nutzung von AI zur Generierung von Levels darstellen.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Einmal im Monat ist es an der Zeit, sich den Neuerungen der Bauteil-Industrie zu widmen. Hier eine Liste einiger Komponenten, die in den letzten vier Wochen das Licht der Welt erblickt haben.

Nordic NRF7002: WLAN-Controller-Chip aus dem Hause Nordic Semi.

Dass die Geschichte von Espressif mit dem Anbieten von WLAN-“Netzwerkchips“ begann, dürfte bekannt sein. Mit dem NRF7002 versucht Nordic nun, ebenfalls in diesem Markt mitzuspielen.
Per se ist der Chip als Erweiterung für die hauseigenen Serien nRF52840, nRF5340 und RF91 vorgesehen. Er lässt sich aber auch mit MCUs anderer Hersteller verwenden, so diese ein SPI-Interface aufweisen.

Bildquelle: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf7002%2Fkeyfeatures_html5.html, (lesenswert).

Angemerkt sei, dass die Bauteile alles andere als preiswert sind. In Hunderterstückzahlen liegt der OEMSecrets-Preis bei rund vier Euro pro Stück – ESP32-Module sind preiswerter.

Ubuntu: Echtzeitvariante ab sofort frei verfügbar

Ubuntu hat die seit einiger Zeit im Preview befindliche Echtzeitvariante von Ubuntu nun offiziell freigegeben – unter https://ubuntu.com/blog/real-time-ubuntu-is-now-generally-available finden sich, sowohl zur Server- als auch zur Core-Variante, tiefergehende Informationen.

GigaDevice: Fokus auf medizinischen Geräten für den Haushaltsbereich.

Der Mikrocontroller-Hersteller GigaDevice fährt im Heimatmarkt seit längerer Zeit eine Strategie, die auf das Anbieten „schlüsselfertiger“ Lösungen für spezifische Zielmärkte abgestimmt ist.
Unter https://gd32mcu.com/cn/detail/452 – die Webseite funktioniert gut mit Google Translate – finden sich nun Referenzdesigns für ein Fingertip-Oxymeter, einen Sauerstoff-Generator und eine Temperaturpistole. Die Sensoren kauft man zu, während die vorgestellten Mikrocontroller aus der GD32-Familie kommen. Im Bereich der ARM-Kerne hat GigaDevice vor einiger Zeit nicht unerhebliche Erweiterungen vorgenommen.

Bildquelle: https://gd32mcu.com/cn/detail/452

Pericom PI4IOE5V6416RQ: I2C-Portextender.

Die mittlerweile von Diodes inc. übernommene Pericom schickt eine neue Variante des I2C-Port-Extenders ins Rennen, die 16 Ausgangsleitungen bietet.

Bildquelle: Pericom.

Interessant ist im vorliegenden System vor allem, dass es eine Interruptlogik mitbringt. Wer dem I2C-Bus einen „zusätzlichen“ Interrupt-Port spendiert, wird vom Bauteil so beim Eintreffen von Zustandsänderungen informiert.
Interessant ist außerdem, dass das Bauteil als „Voltage Translator“ funktionieren kann – sowohl auf Seiten des I2C-Busses als auch auf Seiten der Ausgangslogik werden die Spannungspegel 1.8/2.5/3.3/5V    unterstützt. In Hunderterstückzahlen kostet das im TSSOP24-Gehäuse verfügbare Bauteil rund € 1,6 pro Stück.

Honeywell: CAN-Interface-Gassensor für die Analyse von Lithium-Ionen-Zellen.

Honeywell schickt ein – in Hunderterstückzahlen rund 85 Euro kostendes – Bauteil ins Rennen, das auf die Bedürfnisse der Elektromobilität optimiert ist.
Der BAS6C enthält in CAN-Interface, über das er über die im Gehäuse integrierten „Gas-Sensoren“ informiert. Sinn des Systems ist die Zustandsüberprüfung von LiIon-Akkumulatoren – der enthaltene Sensor ist auf die Erkennung von „Batterie-Zerfallsprodukten“ optimiert.

ESP32: S3- und C6-Module erreichen Distributoren.

Dass Espressif mittlerweile eine ganze „Controllerfamilie“ anbietet, ist nicht neu. Im Laufe der letzten Tage haben auf ESP32-S2 und ESP32-C6 basierende Module Distributoren erreicht. Außerdem steht mit dem ESP32-C6-Devkit eine neue Entwicklerplatine am Start, die Experimente mit dem C6 erleichtert.

Analog Devices: MAX17615 als „elektronische Sicherung“.

Das Ersetzen von klassischen elektromechanischen Bauteilen durch elektronische Sicherungen ist populär. Mit dem MAX17615 schickt Dallas Maxim nun ein neues Bauteil ins Rennen, dass die „Absicherung“ von Schaltungen erlaubt.

Bildquelle: Analog Devices.

Neben Überspannungs- und Unterspannungsabsicherung gibt es auch einen Stromabsicherungsbereich, der folgendermaßen spezifiziert ist:

Schade ist am vorliegenden Bauteil lediglich, das ist es Element nur in einem 3 × 3 mm kleinem TDFN-Gehäuse gibt – in Hunderterstückzahlen kostet er außerdem rund drei Euro.

MeanWell: Galvanisch isolierende DC-DC-Wandler.

Das Design von „Netzteilen- und Spannungsversorgungen“ ist im Consultinggeschäft ein tägliches Ärgernis – ein lustiges Beispiel aus der praktischen Arbeit des News-Autors findet sich unter https://www.youtube.com/watch?v=bPp2OgcdUY0. MeanWell bietet seit einiger Zeit eine „Serie“ von Bauteilen an, die klassische DC DC-Wandler im zwei Inch mal ein Inch großen Gehäuse bereitstellen.
Die neueste Version der – pro Stück um ungefähr € 30 erhältlichen – Bauteile bietet wie in der Abbildung gezeigt einen „breiteren“ Eingangsspannungsbereich an.

(Bildquelle: MeanWell)

Texas Instruments TPS25961 – eFuse mit „höherem Spannungsbereich“.

Texas Instruments schickt ebenfalls ein Bauteil ins Rennen, das im eFuse-Market aktiv ist. Der „schaltungstechnische Aufbau“ setzt dabei externe Widerstände voraus, die die Programmierung der verschiedenen Spannungs- und Strom-Grenzwerte ermöglichen.

Bildquelle: TI.

Interessant ist am vorliegenden Bauteil der „wesentlich höhere“ maximale Strombereich, die Genauigkeit ist indes weniger hoch als beim weiter oben vorgestellten Konkurrenten:

Nisshinbo: Neuer Schaltregler mit 4 MHz Schaltfrequenz.

Aus der Logik folgt, dass eine „höhere“ Schaltfrequenz zu kleineren und somit meist billigeren passiven Komponenten führt. Nisshinbo schickt mit dem NC2600 eine neue Serie von Buck-Reglern ins Rennen, die eine Schaltfrequenz von bis zu 4 MHz aufweisen. Die Komponenten gibt es dabei – siehe Abbildung – sowohl mit fester als auch mit einstellbarer Ausgangsspannung.

Bildquelle: Nisshinbo.

Diodes Inc: I2C-oder SPI-Interface-Treiber mit 36 Kanälen und je rund 70 mA Ausgangsstrom.

Im Bereich der RGB-IC-Treiber gibt es einen weiteren neun Teilnehmer: Diodes Inc schicken den AL5887 ins Rennen, der in Hunderterstückzahlen rund € 2,3 kostet und bis zu 36 LED-Kanäle gleichzeitig steuern kann.

Bildquelle: Diodes

Wiznet-Module ab sofort mit RP2040.

Die Kombination des Raspberry Pi-Mikrocontrollers mit „diversen“ externen Modulen ist nicht neu. Wiznet schickt nun ein Board ins Rennen, das den RP2040 mit einem der „hauseigenen“ Ethernet-Module kombiniert.
In Einzelstücken kostet das Bauteil dabei übrigens gute € 16,5, in hunderter Stückzahlen nimmt man noch rund € 13. Andererseits bringt das Modul allerdings einen Embedded TCP/IP-Stack mit, was die Kombination mit einer Kommunikation mit den Endstellen erleichtert.

Infineon XENSIV™ BGT60LTR11AIP: Arduino-kompatibles Millimeter Wave-Radarmodul.
Seeed bietet seit längerer Zeit diverse mmWave-Module an. Infineon bietet nun ebenfalls ein hauseigenes Modul an, das in Einzelstücken allerdings € 32 kostet.
Infineon betont dabei die Integration sowohl in die Arduino-IDE als auch in Plattform IO – das Produkt ist als „Objekterkennung für „Radar-herausgeforderte Personen“ vorgesehen.

PUIAudio – Ultraschall-Transducer als Sensoren

PUI Audio schickt eine Gruppe von Ultraschall-Transducern ins Rennen, die – je nach Modell – entweder mit 225, oder aber mit 295 kHz arbeiten. Wichtig ist an den vorliegenden Bauteil vor allem, dass sie sowohl als „Sender“ als auch als „Empfänger“ dienen; der Hersteller empfiehlt unter anderem die Nutzung zur Erkennung von Flüssigkeit- oder Gas-Flüssen.
PUIAudio scheint den Fokus dabei auf das Anbieten von umfangreiche Dokumentation zu bieten – unter Ultrasonic Transducers Whitepaper (mouser.com) findet sich ein lesenswertes Whitepaper.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Ob der Umstellung auf alljährliche Major Releases steht – es ist nun mal das erste Quartal des Jahres – eine neue Version von KiCAD, dem kostenlosen und quelloffenen Platinen-Layout-Programm, am Start. Hier eine Zusammenfassung dessen, auf was sich KiCAD-Nutzer freuen dürfen.

Verbesserungen im Textrendering.

Unklare Schaltbilder laden zur Erzeugung von Problemen ein. KiCAD 7.0 schafft im Bereich des Textrenderings an zwei Stellen Abhilfe: Erstens ist es ab sofort möglich, Textblöcke sowohl im Schaltungs- als auch im PCB-Editor unterzubringen. Dabei handelt es sich um „herumschwebende” Labels, die Beschreibungstext anliefern.
Außerdem gilt, dass die Renderingengine ab sofort zur Verarbeitung aller Herren Schriftarten befähigt ist. Neben dem in der Release-Ankündigung gezeigten und aus chinesischen Schriftzeichen bestehenden String ist dies auch zur Integration der verschiedenen Symbol-Schriftarten nützlich.

Bildquelle: KiCAD.

Eine weitere Erweiterung betrifft die Möglichkeit zum Einfügen von Kreisen und Rechtecken – dabei handelt es sich um ein Entgegenkommen an Entwickler, die „hauseigene“ Symbole entwickeln. Sie dürfen die Eingangs- und Ausgangsports fortan außerdem im Editor filtern; Textfelder können auch Hyperlinks aufnehmen.

Bildquelle: KiCAD.

Ab Sofort ist es möglich, eine „zusätzliche“ Beschränkung der Wachstumsrichtung von Linien im Schaltplan vorzunehmen. Die in KiCAD 6.0 eingeführte Einschränkung für rechtwinklige Drähte ermöglicht nun auch das Verlegen von Drähten in 45°-Schritten. Sinn ist auch hier – offensichtlich – das Erzeugen „ordentlich aussehender“ Schaltbilder.

Verbesserte Systemintegration, automatische Aktualisierung und Unterstützung für Apple-Prozessoren.

Viele EDA-Systeme zeigen auch heute noch ihre „Herkunft“ aus dem unixoiden Bereich: Die Integration in die Windows- bzw. Mac OS-Benutzeroberflächen gelingt oft mehr schlecht als recht.
Erstens ist es in KiCAD 7 ab sofort möglich, ein gutes halbes Dutzend von Handlungen per Drag and Drop auszulösen. Spezifischerweise unterstützt man die folgenden Aktionen:

Im Bereich der „aktiven Weiterentwicklung“ bekommt der Plugin and Content Manager eine Erweiterung, die die verschiedenen installierten Plugins und Bibliotheken permanent aktualisiert und bei Bedarf den Benutzer zum Durchführen eines Updates auffordert.
Erweiterung Nummero drei ist die Integration des als Sentry bezeichneten und quelloffenen Crash Trackers (siehe https://sentry.io/welcome/), der ab sofort das Einsammeln von Absturzberichten ermöglicht. Das KiCAD-Entwicklerteam betont dabei sowohl die Deaktivieren der Funktion als auch, dass auf keinen Fall Designdaten in Richtung des Servers übertragen werden.

Bildquelle: Autor

Im Bereich der Drag und Drop-Unterstützung gibt es außerdem eine Anpassung, die das „Fortschreiben“ von Verbindungen beim Bewegen eines Elements im Schaltbild verbessert. Am Besten lässt sich dies durch die beiden Abbildungen illustrieren.

Bildquelle: KiCad

Zu guter letzt gibt es ab sofort ein natives Kompilat von KiCAD, dass die neue Apple-M Prozessorserie unterstützt und ohne Emulation ans Ziel kommt.

Verbesserungen des PDF-Exports

Das KiCAD-Entwicklerteam ist sich bewusst, dass das hauseigene Produkt nicht der einzige am Markt befindliche Schaltplaneditor ist. Als neutrales Austauschformat setzt man auf PDFs.
Version 7 des Produkts „wertet“ exportierte PDF-Dateien auf zweierlei Arten auf. Erstens gibt es fortan ein Inhaltsverzeichnis, das Nutzern eines PDF-Viewers das direkte Ansprechen bestimmter Schaltplanseiten erlaubt. Zweitens werden Symbole fortan mit zusätzlichen Informationen ausgestattet, die in einem kompatiblen PDF-Viewer wie in der Abbildung gezeigt als Informations-Pop Up aufscheinen.

Bildquelle: KiCad

Erweiterungen von DRC-Checker und Co.

KiCAD ist ab sofort dazu in der Lage, DNP-Attribute zu berücksichtigen: Das als nicht zu bestückend Markieren von Bauteilen kann somit direkt im Benutzerinterface des Programms erfolgen, fehleranfällige Eingriffe in die Stücklisten-Datei entfallen.
Die DRC-Engine selbst ist fortan in der Lage, zusätzliche Prüfungen durchzuführen. Erstens kann sie feststellen, wenn der „Footprint“ eines in einer Platine platzierten Elements von dem abweicht, der in der das Element realisierenden Bibliothek deklariert ist.
Außerdem sorgt eine Gruppe zusätzlicher Regeln dafür, dass Befestigungs-Löcher und Pads mit mechanischem Freiraum ausgestattet werden – ein durchaus nützliches Feature, das dem einen oder anderen Anfänger sicher den einen oder anderen Platinen-Shot erspart hätte.
Zu guter letzt ist die DRC-Engine fortan in der Lage, wie in der Abbildung gezeigt direkt eine Liste aller DRC-Regeln auszuwerfen, die im vorliegenden Design ignoriert wurden.

Bildquelle: KiCAD.

Was weiter?

KiCAD in Version 6.X bekommt ab sofort keine Updates mehr: Wer an „weiterer Pflege“ seiner KiCAD-Installation interessiert hat, ist also zum Updaten verpflichtet. Allerdings sind die unter der URL https://www.kicad.org/blog/2023/02/Version-7.0.0-Released/ bereitstehenden Änderungen – dieser Artikel konnte schon aus Platzgründen nur einen Teil vorstellen – im Allgemeinem „im Interesse“ der Nutzerschaft.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

In der Welt der Embedded-Software gibt es Updates. Neben der ersten Developer Preview von Android 14 aktualisiert Emteria sein Industrie-Android. Der Pico W bekommt experimentelle Unterstützung für Bluetooth, während Wilderness Labs mehr Informationen über die „Timeline“ zur Fertigstellung der Meadow-Plattform anbietet.

Meadow F7: Fertigstellung für Mai geplant.

Brian Costanichs Meadow-Umgebung ermöglicht die „Mobilisierung“ von .net-Payloads im Embeddedbereich – eine Technologie, die wir beispielsweise unter Beitrag „Meadow F7 RC1 – JIT-Compiler, mehr Performance“ vorgestellt haben.
Wer die vor wenigen Wochen erschienene Version RC2 benutzt, sollte an dieser Stelle updaten – die Behebung einiger Probleme und die „Vergrößerung“ von Puffern im Datei-Zugriffsstack sorgen unterm Strich für eine wesentliche Erhöhung der Systemzuverlässigkeit:

Für die langfristige Entwicklung des Produkts wichtiger dürfte sein, dass der zur Ankündigung ausgesendeten Newsletter – nach folgendem Schema – über die geplanten Schritte bis zur Fertigstellung der Ausführungsumgebung informiert:

Bildquelle: Wilderness Labs.

Emteria: Tablet in Planung!

Die wahrscheinlich häufigste Anwendung von Embedded Android dürfte das realisieren des „GUI-Teils“ eines Embedded-Systems sein Embedded-GUI-Stacks mögen immer mehr Funktionen aufweisen, können vom Komfort her aber nicht mit einem klassischen Smartphone-Betriebssystem mithalten. Im Hause Emteria bietet man bald ein Tablet an.

Bildquelle: emteria

Frei nach dem einst von Palm Source in The Zen of Palm aufgestellten Postulats des from the horses mouth geht dabei aber, dass Emteria unter der URL https://emteria.com/emteria-os-tablet „Feedback“ von Nutzern einsammelt. Die dort befindliche Umfrage erlaubt das Deponieren der eigenen Wünsche und Ansprüche, und soll dem Unternehmen die bessere Abschätzung der Kundenwünsche ermöglichen.

Emteria OS: Industrie-Android mit diversen Updates.

Nach der Einstellung von Android Things ist nur noch das in Deutschland ansässige Unternehmen Emteria „ernsthaft“ in Sachen Embedded-Android unterwegs: Das hauseigene Produkt ist sehr leistungsfähig, und wird – unter anderem – mit einem cloudbasierten Verwaltungssystem ausgeliefert, das das Aktuell-Halten der diversen IoT-Geräte zentralisiert.
Im Laufe der letzten Tage hat Emteria einige der Builds, die für verschiedene weit verbreitete Prozessrechner angeboten werden, aktualisiert bzw. ergänzt.
Am wichtigsten dürfte das für den Raspberry Pi 4B vorgesehene Image auf Basis Android 13 sein, das – wie in der Abbildung gezeigt – verschiedene Aktualisierungen erhält.

Bildquelle: https://emteria.com/release-notes.

Im Interesse der einfacheren programmierbare der Anwendungen unterstützt man im Hause Emteria meist auch „ältere“ Versionen – im Fall der meisten Prozessrechner handelt es sich dabei um Android 11 und Android 13. Aus der Logik folgt, dass das Android 11-Image für den Raspberry Pi 4B nach folgendem Schema ebenfalls Updates mitnahm.

Bildquelle: https://emteria.com/release-notes

Wer die Raspberry Pi-Familie – egal aus welchen Gründen – nicht gerne nutzt, muss nicht auf den MTerrier verzichten. Interessanterweise auf Android 12 basiert das Image für den Rock 5B – der im Umfeld von RS stark vertriebene Prozessrechner ist gut verfügbar und weist eine sehr hohe Rechenleistung auf.

Bildquelle: Emteria

Zu guter Letzt gibt es auch noch ein Update für den Intel Celadon: Die neueste Version des Images „entsperrt“ die Prozessorkerne und erlaubt die maximale Ausnutzung der zur Verfügung stehenden Hardware.

Raspberry Pi Pico W: Ab sofort mit Bluetooth.

Als der Raspberry Pi Pico W erschien, wunderte sich die Technikpresse über das Fehlen von Bluetooth – im Infineon Modul war das Element ja enthalten. Die Antwort war wie so oft ein Blick auf das Datenblatt, wo man feststellen konnte, dass der für die Bluetooth-Kommunikation notwendige Teil des Chips nicht mit dem RP2040 verbunden war.
„Stand der Gedanken“ zum damaligen Zeitpunkt war, dass wahrscheinlich eine Anpassung der Modul Firmware erforderlich war, um Bluetooth zur Kommunikation über die WLAN-Leitungen zu befähigen.
Wohl ob des immensen Kunden-Interesse haben Ebenezer Uptons Mannen nachgelegt: Ein derzeit im Beta-Status befindliches SDK 1.5 gibt die folgenden neuen Funktionen frei:

Interessant ist in diesem Zusammenhang außerdem, dass der verwendete Bluetooth-Stack – siehe hierzu auch https://github.com/raspberrypi/pico-sdk/issues/1164 – von der Raspberry Pi Trading lizenziert wurde, um auch die kommerzielle Nutzung zu erlauben.

Bildquelle: GitHub.

Android 14 verfügbar

Zu guter letzt sei noch – wenn auch kurz – darauf hingewiesen, dass Google ab sofort Android 14 unter der URL https://android-developers.googleblog.com/2023/02/first-developer-preview-android14.html als Developer Preview anbietet.
Zum Zeitpunkt der Drucklegung gibt es keine Änderungen in den Bluetooth- und WLAN-APIs, die in der Vergangenheit ja „stark durchgeschüttelt“ wurden.
Neu ist allerdings das unter https://developer.android.com/guide/topics/connectivity/cross-device-sdk/overview en Detail beschriebene Cross Device-SDK, das die Interaktion von Applikationen über Gerätegrenzen hinaus ermöglichen soll.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Am zweiten Tag des FOSDEM-Kongresses bekamen Teilnehmer verschiedener Themen zu sehen. Neben einer Einführung in Secure Boot unter Nutzung quelloffener Systeme demonstrierte man eine in MicroPython gehaltene 3D-Engine für den ESP 32.

FPGAs als „Garant der reinen Lehre“.

Der an der Carnegie Mellon-Universität tätige Gabriel Somlo demonstriert einen FPGA samt Softcore (siehe https://fosdem.org/2023/schedule/event/rv_selfhosting_all_the_way_down/), der zum Durchstarten von Fedora Linux befähigt war – ob der äquivalenten Taktrate von nur rund 50 MHz war dies naturgemäß ein Prozess, der einige Zeit in Anspruch nahm.
Als Sinn präsentierte man dabei die „komplette Kontrolle“ über die Compute-Infrastruktur.

(Bildquelle alle: Autor, via FOSDEM oder https://www.instagram.com/tam.hanna/)

Spezifischerweise sprach Somlo von einem probeweise durchgeführten Exploit, der einem Chip-Hersteller ein modifiziertes Schaltbild unterschob – eine Gruppe von Widerständen und ein Kondensator sorgten dann dafür, dass eine bestimmte Gruppe „unprivilegierter „Assembler-Befehle ausreichte, um den Chip in den Privileged Mode zu versetzen. Mit FPGAs sind diese Angriffe schon deshalb schwieriger, weil der Designer des Chips am Ende nicht weiß, „welche“ Zelle des Halbleiters von welchem Teil des Bitstroms des Endanwenders konfiguriert werden wird.

Secure Boot mit quelloffener Software

TPM und Co. wurden von der Open Source-Entwicklerschaft lange Zeit als Inkarnation des Teufels angesehen. Tomasz Żyjewski präsentierte mit Overview of Secure Boot state in the ARM-based SoCs (siehe https://fosdem.org/2023/schedule/event/arm_secure_boot_2/) einen Überblick darüber, wie die – insbesondere im Embedded-Bereich immer wichtiger werdende -Technologie mit quelloffenen oder zumindest mit nicht unter NDA stehenden Werkzeugen implementierbar gemacht werden kann.
Besonders interessant ist dabei die in der Abbildung gezeigte „Support-Matrix“, die über den Unterstützungsgrad der verschiedenen Architekturen informiert.

Lobenswert war beim Vortrag neben der Einführung in die Art des Funktionierens von Secure Boot, dass eine Auflistung der von den verschiedenen Halbleiter-Herstellern implementierten Verfahren samt den in ihnen enthaltenen Schwachstellen erfolgte.
Manche verbreitete Familien weisen „von Haus aus“ nämlich Schwächen auf, die das umgehen von Secure Boot ermöglichen – dass man bei einem der Chips durch „Ausbrennen“ der USB-Datenleitungen Sicherheit wiederherstellen kann, ist ein interessantes Detail am Rande.

Neues Futter für Java-Entwickler.

Die Nutzung von Java am Raspberry Pi ist – auch wenn man es auf den ersten Blick nicht glaubt – durchaus verbreitet. Das für das Anbieten einer „frei lizenzierbare“ JVM bekannte Unternehmen Azul bietet mit der in der Abbildung gezeigten Webseite seit einiger Zeit eine Art „Anlaufstelle“ an, die – analog zu JaxCenter im Desktopbereich – alle Informationen der Community zu bündeln sucht (siehe auch https://fosdem.org/2023/schedule/event/pi/).

Bildquelle: Screenshot von https://pi4j.com/

Neben Unterstützung für Kotlin arbeitet die Community auch daran, die JDK-Verwaltung SDKMan am RasberryPI zum Laufen zu bringen. Lohn der Mühen ist, dass an einer JVM interessierte Nutzer so mit weniger Aufwand aus den zur Verfügung stehenden Implementierungen wählen können.

3D-Engine für ESP32 zeigt Möglichkeiten zur Performance-Steigerung von MicroPython.

Dass Kongress-Teilnehmer seit einiger Zeit aus Platinen bestehende „Name Tags“ bekommen, ist per se nichts Neues. Mat Booth fühlte sich durch seinen ESP 32-Tag allerdings dazu animiert, auf diesem eine 3-D-Engine zum Laufen zu bringen (siehe https://fosdem.org/2023/schedule/event/python_hacking_esp32/).

Während der Erfolg der Engine – wohl auch ob der Nutzung von MicroPython – unterm Strich überschaubar bleibt, gilt, dass Booth im Rahmen der Arbeiten Informationen über die Optimierung der Performance von in der MicroPython-Runtime lebenden Systemen sammeln konnte. Wer die „optimale“ Leistung aus einem MicroPython-System herausholen möchte, sollte beispielsweise darauf achten, „häufige“ Python-Performance-fressen nach Maßgabe der Möglichkeit zu umschiffen.

Maximale Performance lässt sich dadurch erreichen, dass man der MicroPython-Runtime ein natives Modul einschreibt. Hier gibt es allerdings der Wege zwei – während ein einkombiniertes natives Modul für den Entwickler einfach zu verwalten ist, muss der Endanwender die schon vorhandene MicroPython-Firmware durch die modifizierte Variante ersetzen. Dynamisch „nachladbare“ Module machen dem Anwender weniger Arbeit, sind aber im Bereich der Erzeugung wesentlich komplizierter von der Handhabung.

Zu guter Letzt sei darauf hingewiesen, dass der Quellcode der Engine als Ganzes unter der URL https://github.com/mbooth101/tidal3d/ bereitsteht. Wer sich in die diversen mathematischen Transformationen einlesen möchte, bereut einen Besuch nicht.

Für MicroPython-Anfänger interessant ist auch der unter der URL https://fosdem.org/2023/schedule/event/python_micropython_intro/ bereitstehende Vortrag von Wouter van Ooijen – während „erfahrene“ MicroPython-User in ihm absolut nichts Neues lernen, können Quereinsteiger den einen oder anderen wertvollen Hinweis mitnehmen.

RISCV als Werkzeug der Lehre.

Nicht erst seit Adolf Melenzineks Klassiker zur Ingenieur-Pädagogik gilt, dass sich über die beste Art zur Vermittlung technischer Kenntnisse hervorragend diskutieren lässt. An der technischen Universität zu Prag entwickelt man mit QtRVSim aus diesem Grund einen „Emulator“, der auf Basis der RISCV-Architektur die Visualisierung der in Prozessoren bei der Abarbeitung verschiedener Algorithmen auftretenden Prozesse ermöglicht.

Besonders interessant ist, dass das Produkt quelloffen ist – wer sich den Quellcode des Emulators ansehen möchte, kann dies beispielsweise unter der URL https://fosdem.org/2023/schedule/event/rv_qtrvsim/ tun.

Emulatoren als Quell der „Fortbildung“.

Emulatoren werden primär als Werkzeug zur Erhaltung von Spielen vorgesehen, die nicht oder nur schwer portierenbar sind.
Der Vortrag von

Neil Coffey – oberflächlich beschäftigte er sich unter dem Thema Emulator development in Java mit der Nutzung von Java zur Erzeugung von Emulatoren – ist nicht nur aufgrund der Emulator-Entwicklung interessant: Bei der Arbeit mit Emulatoren lernt man auch diverse Methoden der Bildverarbeitung und des performancekritischen Rechnens (siehe https://fosdem.org/2023/schedule/event/oak/).

Neben diesem Vortrag gab es auch eine ganze Gruppe weiterer Präsentationen zum Thema Emulatoren, die – teilweise – ebenso lehrreich – hier schon aus Platzgründen nur erwähnt werden müssen.

Cutting Room Floor – das übrig gebliebene!

Obwohl der zweite Tag der vor dem etwas weniger Events für Embeddedentwickler mitbrachte, galt auch diesmal, dass die gut zwei Dutzend parallel laufenden Tracks jede Menge Platz für „Kollisionen“ lieferten. Hier deshalb abermals eine Liste von besonders interessanten Vorträgen.

Uwe Kleine-König zeigte in Pulse-Width-Modulation (PWM) is easy, isn’t it? (siehe https://fosdem.org/2023/schedule/event/pwm/) verschiedene PWM-Implementierungen.

Christophe Ponsard präsentierte einen Vortrag zum Bull Gamma 3 (siehe https://fosdem.org/2023/schedule/event/gamma/) – ein antiker Computer aus der elektromechanischen Zeit, der – witzigerweise – von der Architektur her modernen Systemen gar nicht so unähnlich ist.

German Gomez präsentierte in I made a GameBoy emulator (siehe https://fosdem.org/2023/schedule/event/gb_arm/) ebenfalls Informationen zur Arbeit mit Emulatoren. Zu guter Letzt zeigt Andre Almeida in Hacking the Linux Kernel to get moar FPS (siehe https://fosdem.org/2023/schedule/event/kernel_fps/) die „Rolle“ der Computerspiele – der Talk geht darauf ein, „wie“ Computerspiele die Performance von Teilen des Linux-Kernels erhöht haben.

Lowlevel-Entwicklung ist nicht unbedingt attraktiv – ein Problem, dass die Linux-Community bemerkt. Zur „Lösung“ hat man sich für die Erzeugung des Kernel Development Learning Pipeline entschieden, der von Joel Savitz in seinem Vortrag ohne Teil vorgestellt wurde (siehe https://fosdem.org/2023/schedule/event/kdlp_kernel_devel_learning_pipeline/).

Ein weiteres „interessantes“ Problem betrifft eine Neuauflage des Jahr-2000-Problems, das mit 32-bittigen Datentypen im Januar 2038 auftreten wird. In Fixing Year 2038 (siehe https://fosdem.org/2023/schedule/event/fixing_2038/) nahm man sich dieses Themas an.

Der KiCad – Entwickler Seth Hillbrand bot mit Donation Page Design (siehe https://fosdem.org/2023/schedule/event/donation_page_design/) derweil einen Vortrag an, der erklärte, wie man eine Spenden-Sammel-Webseite technisch optimal aufbaut.

Blockbasierte Programmiersprachen waren ebenfalls Thema. Einerseits präsentierte man MicroBlocks (siehe https://fosdem.org/2023/schedule/event/microblocks/), andererseits ging man auf Möglichkeiten zu „Erweiterung“ von Snap ein (siehe https://fosdem.org/2023/schedule/event/snap/).

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Nachdem die in Belgien stattfindende FOSDEM die letzten Jahre rein virtuell stattfand, gab es dieses Jahr wieder eine Präsenz-Variante. Die in den letzten Jahren aufgebaute Streaming-Infrastruktur wurde von den Organisatoren indes nicht verworfen, weshalb man auch von Zuhause aus teilnehmen konnte. Fokus des ersten Tages – der Kongress ist traditionell auch auf Embedded bezogen – waren vor allem quelloffene Anwendungsfälle von FPGAs, das Design quelloffener Chips und die Nutzung von Go und Linux im Embeddedbereich.

Go mit Unterstützung für LoraWAN

Die Programmiersprache Go hat sich als fixe Größe etabliert. Mit dem unter https://tinygo.org/ bereitstehenden Compiler kann sie auch auf Embedded-Systemen zur Ausführung gebracht werden.
Im Interesse der maximalen Benutzerfreundlichkeit pflegt das Go-Entwicklerteam ein Repositorium mit diversen Code-Beispiel, die Interaktion mit externer Hardware zu erleichtern suchen.
Auf der FOSDEM demonstrierte Ron Evans (siehe https://fosdem.org/2023/schedule/event/goevenfurtherwithoutwires/) nun, wie man eine Gruppe von RP2040-Modulen mit SemTech-Transcievern verbindet, um so Informationen unter Nutzung des lizenzfreien Funkstandards auszutauschen.

FPGAs und Chips, zur Ersten.

Spätestens wer die Geschichte des letzten Solartron-Multimeters SI7063 en Detail studiert, weiß, wie teuer Shots von ASICs sind – die Briten mussten ihre letzte Serie „Kübeln“, weil ein seltener Fehler im ASIC mitunter zu Anzeige gefährlicher Fehler führte (siehe https://www.eevblog.com/forum/testgear/my-new-old-schlumberger-si-7063-dmm/50/).
Im-zugegebenermaßen etwas kurz gefassten Vortrag “Can we do an open source chip design in 45 minutes?” präsentierte Philipp Wagner (siehe https://fosdem.org/2023/schedule/event/open_source_chip_design/) in 45 Minuten einen „Aufriss“ von allem, was der P. T. Open Source-Chipentwickler an Werkzeug kennen sollte.
Neben dem bereitstehenden Stream, die ob der langen Ressourcenliste sehenswert ist, fiel dem Autor der Container auf. Dabei handelt es sich um in Form eines docker-Container vorliegende “Appliance“, die Verilog-Code aufnimmt und am Ende eine fertigungsbereite Datei ausspeit.

(Bildquelle: https://fosdem.org/2023/schedule/event/open_source_chip_design/)

Interessant waren auch die Ausführungen zur Suche nach fertigen Blöcken: die von OpernCores gewartete Sammlung wird ja seit einiger Zeit nicht mehr gewartet. Als „Alternative“ schlug man die Nutzung von LiteX vor.

(Bildquelle: Autor, via https://www.instagram.com/p/CoPKLlsNYXs/)

Hare: neue systemnahe Programmiersprache

Die Entwicklung neuartiger Programmiersprachen findet seit langer Zeit vor allem auf „hohem Niveau“ statt – Themen wie Garbage Collection und fortgeschrittene Vererbung geben dem P. T. Technischen Informatik-Professor nun einmal mehr Gelegenheit zum Veröffentlichen von Papers.
Die von Drew DeVault vorangetriebene und unter https://harelang.org/ en Detail beschriebene Sprache Hare hat stattdessen die systemnahe Programmierung zum Ziel.

(Bildquelle: https://fosdem.org/2023/schedule/event/helios/)

Interessant ist an Hare vor allem, dass neben der Programmiersprache auch ein durchaus vollständige Microkernel namens Helios entwickelt wird. Zum Zeitpunkt der Drucklegung ist er auf X64-und ARM64-Prozessoren lauffähig; eine Portierung auf den RISCV-Kern ist in nicht allzu ferner Zeit vorgesehen.

FPGAs im Audiobereich.

FPGAs kommen nicht nur zur Ausführung von Softcores mit Linux und Co. zum Einsatz. Sebastian Holzapfel präsentierte in seinem Vortrag FPGA-based music synthesis with open-source tools (siehe https://fosdem.org/2023/schedule/event/fpga_music_synthesis/) verschiedene Module und Anwendungen im Bereich der Audio-Signalverarbeitung bzw. Audio-Erzeugung.
Als „Mittel der Wahl“ erkor er dabei das mehr oder weniger stark standardisierte Eurorack-Format aus – ein standardisierter Synthesizer, der Module verschiedener Anbieter entgegennimmt.

Quelloffene FPGA-Toolchain

Der von diversen Linux-Events bekannte Embedded-Linux-Anbieter PenguTronix präsentierte mit Building FPGA Bitstreams with Open-Source Tools (siehe https://fosdem.org/2023/schedule/event/fpga_bitstreams/) ebenfalls einen Vortrag, der sich um die „Realisierung einer komplett quelloffenen“ Toolchain für die Entwicklung von FPGA-Software drehte.

(Bildquelle: https://www.instagram.com/p/CoP1Q6XtqbL/)

Cutting Room Floor – interessante Vorträge, kurz gefasst

Da die FOSDEM bis zu zwei Dutzend Tracks „paralell“ veranstaltet, war es dem News-Autor unmöglich, an allen teilzunehmen. Hier deshalb eine Auflistung weiterer Vorträge, die für Embedded-Entwickler interessant sein könnten.
Für „Freunde der Kommunikation“ präsentierte Dejan Bosanac einen Vortrag, der die Programmierung von Bluetooth Mesh-Systemen unter Nutzung der Programmiersprache Rust demonstrierte.

Bildquelle: https://fosdem.org/2023/schedule/event/bt_mesh_rust/

Freunde der Programmiersprache Go fanden in The State of Go (siehe https://fosdem.org/2023/schedule/event/gostateofgo/) einen neuen Vortrag, der auf die Änderungen in Go einging – wer sich seit Version 1.19 des Projekts nicht mehr fortgebildet hat, bekommt hier eine Möglichkeit zur schnellen Aktualisierung seiner Programmierkenntnisse. Unter https://fosdem.org/2023/schedule/event/the_state_of_kotlin/ gibt es ein Analogon mit Bezug auf Kotlin.
Auch Rust macht im Embedded-Bereich Fortschritte: unter https://fosdem.org/2023/schedule/event/rust_rust_api_design_learnings/ findet sich ein Vortrag, der auf „vernünftige“ Design-Paradigmata zur Verbesserung der Usability von für Rust vorgesehene APIs eingeht.

Im Smart Home-Bereich ist Matter nicht mehr wegzudenken. Stefan Schmidt präsentierte mit Matter and Thread as Connectivity Solution for Embedded einen halbstündigen Vortrag, der einen schnellen Einstieg in die Thematik ermöglicht (siehe https://fosdem.org/2023/schedule/event/matter_and_thread/).

User Interviews sind in der Praxis – man denke nur an den unter https://archive.org/details/zen-of-palm bereitstehenden Zen of Palm – oft der beste Weg, um dem Benutzer auf den Zahn zu fühlen. Emily Omier bot mit Do more awkward user interviews ebenfalls eine Präsentation zum Thema an.

(Bildquelle: https://fosdem.org/2023/schedule/event/awkward_user_interviews/)

Wer einen Raspberry PI oder einen ähnlichen Prozessrechner produktiv im Labor nutzt, legt sich irgendwann eine VNC-Verbindung zu. Leon Anavi plädiert stattdessen für die Nutzung von RDP, und präsentiert neben einer Auflistung der Vorteil des Protokolls auch Wege, um RDP in verschiedenen häufig verwendeten Embedded Linux-Varianten einzubauen.

(Bildquelle: https://fosdem.org/2023/schedule/event/rdp_wayland/)

Wer sich über die Rolle von LLVM im Bereich der Embedded-Toolchains wundert, wird im von Peter Smith gehaltenen Vortrag aufgeklärt – die Slides finden sich unter https://fosdem.org/2023/schedule/event/llvmembedded/.
Angemerkt sei, dass die Veranstalter planen, langfristig für alle hier genannten Vorträge vollwertige Videos online zu stellen. Die jeweils als Bildquelle angeführten Links dienen als Einstiegspunkt in dem der jeweilige Ressourcenportal, wo das Video nach dem erfolgreichen Hochladen und Rendern zur Abwertung bereitstehen wird.

Für morgen: es geht weiter!

Das Veranstalter-Team plant einen weiteren Tag Vorträge. Wer teilnehmen möchte, sollte einfach die unter https://fosdem.org/2023/schedule/streaming/ bereitstehende und in der Abbildung gezeigte Webseite benutzen.

Das Drücken von F5 reicht dabei aus, um die in der Spalte Happening now angezeigten Vortragsthemen zu aktualisieren. Der ganz rechts befindliche Link Watch Live ermöglicht dann den direkten Einstieg in den Livestream.
„Kritisch“ ist daran vor allem, dass das Auftauchen der Livestream-Portale mitunter etwas Zeit in Anspruch nimmt. So sie eine auf den Chat-Server des Kongresses verweisende Fehlermeldung bekommen, sollten Sie die Seite einige Male aktualisieren – diese Message weist darauf hin, dass der jeweilige Livestream noch nicht erfolgreich aufgebaut wurde.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

SeeedStudio zeigt ESP32-artige Module, die Embedded Linux unterstützen und so den Prozessrechner unnötig machen. Quectel steigt ins Connectivity-Geschäft ein und bietet vorausbezahlte SIM-Karten für den IoT-Einsatz, während diverse neue Chips die Arbeit erleichtern. Zu guter Letzt gibt es einen neuen SCSI-Emulator, der das Am-Leben-Erhalten diverser Messtechnik erleichtert.

Seeed – ESP32-artige Module für Embedded Linux

Im Embeddedmarkt gibt es eine “tote Zone” zwischen klassischen mikrocontrollerbasierten Systemen und vollwertigen Linux-Einplatinencomputern. Seeed Studio versucht nun, diese mit Leben zu füllen – beide hier genannten Produkte sind vom Deployment her ESP32-Module, sind aber zur Ausführung von OpenWRT und ähnlichen extrem schlanken Linuxdistributionen befähigt.
Kandidat Nummero eins steht unter der URL https://www.seeedstudio.com/LinkIt-Smart-7688.html bereit, und basiert auf einem Chipsatz aus dem Hause MediaTek.

Bildquelle: Seeed

Unter https://www.seeedstudio.com/SMD-WIFI-Module-56P-18-35-2-2-8mm-p-5547.html gibt es auch eine Standalone-Variante des Moduls, die 128MB RAM und 32MB Flashspeicher mitbringt.

Bildquelle: Seeed

RiotEE – Bluetoothmodul mit Ökosystem

Der in Deutschland ansässige Low-Power-Spezialist Nessie Circuits plant die Fertigung einer Familie von Evaluationsboards, die sich um das hauseigene Funkmodul gruppieren – es bringt ein BTLE-Radio und einen Cortex M4-Mikrocontroller mit.

Bildquelle: hackster, via https://www.hackster.io/news/nessie-circuits-riotee-platform-aims-to-provide-easy-entry-into-the-battery-free-internet-of-things-931392bb7c75

Interessant ist am vorliegenden Ökosystem die Verfügbarkeit verschiedener Carrier-Boards, die Energy Harvesting ermöglichen. Die Abbildung zeigt beispielhaft eine Platine mit Solarzellen.

Bildquelle: hackster

QuecTel steigt ins Connectivity-Geschäft ein

Anbieter von Funkmodulen erweitern ihr Produktspektrum permanent. QuecTel kündigte soeben an, dass man innerhalb Europas ab Sofort M2M-SIMs anbietet. Die Abbildung zeigt die zum Stand der Drucklegung verfügbaren Offerte.

Bildquelle: QuecTel

STMicroelectronics – AI-”Streichelzoo”

STMicroelectronics vertieft das hauseigene Investment in AI-Technologien. Unter der URL https://stm32ai-cs.st.com steht ab Sofort ein Portal zur Verfügung, das die diversen von ST angebotenen Dienstleistungen im Bereich der künstlichen Intelligenz zusammenfasst.

Bildquelle: STMicroelectronics

En Detail bietet der Dienst folgende Leistungen:

STMicroelectronics – USB PD-Controller mit integrierter MCU und Unterstützung für zwei Ports

Mit dem unter https://www.st.com/en/power-management/st-onemp.html? Beschriebenen ONEMP schickt STM einen PD-Controller ins Rennen, der zwei USB-Ports unterstützt. Zur Implementierung “hauseigener” Protokolle steht außerdem ein Cortex-M0-Chip zur Verfügung.

Bildquelle: STM

Toshiba / Bodos Power – Whitepaper zur Isolation von I2C unter Nutzung von Optokopplern

Toshiba bietet unter https://toshiba.semicon-storage.com/eu/semiconductor/design-development/innovationcentre/articles/tcm0646_PhotocouplerI2CIsolation.html ein lesenswertes Whitepaper an, das die galvanische Trennung eines I2C-Bus unter Nutzung von vier Optokopplern illustriert.

(Bildquelle: Toshiba)

IB-IoT, SigFox und Co – neue Deployments und Angebote

Telekom Srbija bietet Kunden ab Sofort ein NB-IoT-Netzwerk an, das das hauseigene LoraWAN-Angebot erweitert und so eine umfassendere Abdeckung für M2M-Dienste in Serbien bietet. Das französische Wasserwerk Sogedo verlängert derweil seine Partnerschaft mit SigFox um zehn weitere Jahre – Ziel ist das Anbieten von Wasseruhren mit Konnektivität.
Laut dem im Allgemeinen gut informierten Branchennewsdienst RCR (siehe https://www.rcrwireless.com/20230125/internet-of-things-4/french-water-company-sogedo-signs-10-year-iot-deal-with-sigfox-owner-unabiz?) ist der primäre Sinn dieser Wasseruhren die Erkennung von Lecks:

Paralell dazu plant der norwegische Anbieter Netmore indes den Ausbau eines LoraWAN-Netzwerks in Frankreich – ob bzw inwiefern die von Bouygues zurückgelassenen Ressourcen (Einstellung des hauseigenen LoRA-Netzes erfolgte 2021) zum Einsatz kommen, ist unklar.

SCSI-Emulator nun schneller

Wer alte Messtechnik mit SCSI-Laufwerken am Leben erhalten möchte, profitiert von SCSI-Emulatoren. Unter https://www.hackster.io/news/bluescsi-v2-packs-a-raspberry-pi-pico-to-offer-high-speed-scsi-emulation-for-your-vintage-hardware-49af4d8ca487 findet sich nun ein neues schnelleres Design, das eine SD-Karte “scsiiert”.

MicroEJ – hauseigene Runtime unterstützt nun auch C

MicroEJ – das Unternehmen ist vor Allem für seine Java-Runtime bekannt – unterstützt ab Sofort auch die Ausführung von C-Code in der hauseigenen Runtime.

Bildquelle: https://developer.microej.com/managed-code/

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Der einst als Gründer des hinter ThreadX stehenden Unternehmens Express Logic hat mit PX5 ein neues Echtzeitbetriebssystem am Start. Primäres Verkaufsargument ist die pThreads-API – was es sonst zu sagen gibt, zeigt dieses Interview.

Interview-Modus: wie lief das Interview?

Bill Lamie spricht nicht Deutsch. Aus diesem Grund erfolgte das Interview per e-mail in englischer Sprache. Die Übersetzung ins Deutsche erledigte der Autor per Hand. Wer den Originaltext haben möchte, kann tamhan aeht tamoggemon punkt com anschreiben.

Bildquelle alle: gestellt von PX5

Hallo Bill, danke, dass du Dir die Zeit für dieses Interview genommen hast. Bitte verrate uns ein wenig mehr darüber, wie sich Deine Lebensgeschichte präsentiert.

Während ich an der Universität war, hatte ich das Glück, in einem Unternehmen ein Praktikum zu machen, dass sich mit einem Echtzeit-Betriebssystem für eine militärische Anwendung auseinandersetzte – das System hieß damals EXOS.
Obwohl Compiler, Prozessorarchitektur und das Design des Betriebssystems komplett anders waren, als es heute der Fall ist, setzte es mich trotzdem auf den Pfad der Echtzeitbetriebssystem-Entwicklung.
Mein erstes kommerzielles Echtzeitbetriebssysteme Nucleus RTX entwickelte ich im Jahre 1989, danach folgte Nucleus Plus. Beide entwickelte ich unter dem Namen des Unternehmens Accelerated Technology, das später von Mentor Grafics aufgekauft wurde und jetzt zu Siemens gehört.
Im Jahre 1997 startete ich das Unternehmen Express Logic und lancierte ein neues Echtzeitbetriebssysteme namens ThreadX. ThreadX wurde auf mehr als 10 Milliarden Geräten ausgeliefert, und 2019 von Microsoft aufgekauft.
Letzten Sommer habe ich Microsoft dann verlassen und bin wieder im Embeddedbereich zurückgekehrt und habe eine – meiner Meinung nach disruptive-Technologie namens PX5 entwickelt.

OK! Lass uns In Medias Res gehen. Bitte gib mir einen „Elevator Pitch“ für PX5.

Das interessanteste Attribut von PX5 ist, dass das Betriebssystem die POSIX-pThreads-API nativ umsetzt. Wir haben die POSIX-Standard-API mit einem Echtzeitbetriebssystem kombiniert, um Geräte-Firmware portable zu gestalten und außerdem den Trainingsaufwand zur Einschulung von Entwicklern stark zu reduzieren.
Wir hoffen, dass wir die Embedded-Entwicklung um die POSIX-APIs zusammenfassen und vereinheitlichen können. Außerdem möchte ich anmerken, dass PX5 für die Industrie als Ganzes im Bezug auf Performance, Platzbedarf, Einfachheit der Nutzung und Sicherheit einen Schritt nach vorne darstellt.

Warum hast Du Dich ausgerechnet für POSIX-Kompatibilität entschieden? Probiert die Linux Foundation mit Zephyr nicht etwas ähnliches?

Unsere Entscheidung, POSIX-pThreads „nativ“ zu implementieren, liegt vor allem an der immensen Popularität von Embedded Linux-Systemen. Embedded Linux macht mehr als 70 % der gesamten Embedded-Industrie aus. POSIX ist also nicht nur ein Industriestandard, sondern auch die best bekannte und meist benutzte API im Embedded-Bereich.
Ich hoffe, dass wir den gesamten Embedded-Bereich – spezifisch meine ich hier auch die klassische Entwicklung von Mikrocontroller-Applikationen – um die POSIX-pThreads-API standardisieren können.
Im Bezug auf Zephyr: Ich gehe davon aus, dass der Fokus auf POSIX-pThreads, egal ob es von Zephyr oder von einem anderen Echtzeit-Betriebssystem-Anbieter her erfolgt, für die Industrie als Ganzes ein „net positive“ darstellt.
Nun aber noch spezifisch zu Zephyr: Das Betriebssystem ist eigentlich ein Derivat vom bei Eonic erzeugten Virtuoso RTOS, und ist nicht von Haus aus auf POSIX optimiert. Stattdessen hast Du die POSIX-API, die auf einer hauseigenen API “reitet“. Dieser mehrschichtige API-Aufbau führt nur allzu oft zu suboptimaler Performance und aufgeblähtem Code.

Welche Kerne unterstützt ihr anfangs?

Anfangs planen wir Unterstützung für Cortex-M/A/R , unter Unterstützung der Entwicklungswerkzeuge von IAR, GCC und ARM. Unterstützung für RiscV, 64 Bit-Kerne und SMP planen wir dann innerhalb der nächsten zwölf Monate.

Ich vermisse hier die Angebote von GigaDevice ein wenig. Gibt es denn schon „News“ zu den ARM-basierten Angeboten von GigaDevice? Und wie sieht es mit Unterstützung für andere ISAs wie RiscV oder X86 aus?

Unser „Off the Shelf“ Support ist architekturspezifisch – jeder Halbleiter-Anbieter, der einen Prozessor auf einer unterstützten Architektur hat, hat so gut wie sofort Unterstützung – das inkludiert explizit auch GigaDevice.

Unterstützung für RiscV planen wir innerhalb von zwölf Monaten. Zu X86 haben wir derzeit noch überhaupt keine Pläne.

Trotzdem bleibt eine Frage offen: Wie möchtet Ihr Integration in Codegeneratoren wie Cube oder MCC abbilden. Die in den diversen Mikrocontroller integrierten Peripheriegeräte werden immer komplexer.

Ja, langfristig werden wir uns definitiv in die verschiedenen Codegeneratoren integrieren. Anfangs ist unser Ziel allerdings ein anderes: Wir wollen sicherstellen, dass es geradezu Deppensicher ist, das PX5-Betriebssystem per „Drop-in“ in jedes beliebige vorhandene Mikrocontroller-Projektskelett einzubinden.
PX5 besteht ja wie gesagt aus nur zwei Codedateien, normalerweise sind nicht einmal Eingriffe in die Einstellungen des Linkers erforderlich. Das bedeutet, dass Du Dir einfach die beiden Dateien „greifst“, die Headerdatei pthread.h inkludierst und die Methode px5_pthread_start aufrufst. Damit ist die Integration auch schon abgeschlossen.

OK, das klingt gut. Die nächste Frage sind die Benutzerinterfaces: STMicroelectronics hat Graupner, während Renesas ebenfalls einen hauseigenen GUI-Stack hat. Auch hier mache ich mir ein wenig Gedanken, weil ja moderne Mikrocontroller immer mehr „hauseigene“ 2-D-Beschleuniger mitbringen, die beispielsweise Rotation in Hardwarebeschleunigung erledigen. Im Allgemeinen ist hierfür allerdings „Hauseigenes“ Codieren erforderlich – OpenGL oder DirectX sucht man vergebens.

Wir unterstützen das quelloffene LVGL-Paket. In der Zukunft wird es außerdem Integration mit verschiedenen anderen kommerziellen GUI-Stacks geben. Weil das PX5-Echtzeitbetriebssystem auf POSIX-pThreads basiert, wird jede andere GUI (oder jede andere Middleware) mit Embedded Linux-Unterstützung auch auf PX5 ausführbar sein.

Was plant ihr zu TCP/IP?

Wir arbeiten derzeit an einem hauseigenen TCP/IP-Stack, und hoffen, dass dieser im Frühling zur Verfügung stehen wird.

Damit bleibt noch ein Thema offen: Was tut Ihr für die Thema Cloud? Sowohl AzureRTOS als auch FreeRTOS werden ja von Unternehmen vorangetrieben, die – mehr oder weniger umfangreiche – Cloud-Angebote in der Hinterhand haben.

Die Bedeutung des Internets der Dinge ist uns wohl bekannt. Wir planen, alle „marktführenden“ Anbieter von Cloud-Systemen gleichermaßen zu unterstützen.
PX5 ist konzeptuell komplett anders als die anderen Systeme, weshalb wir diese (also Azure RTOS und FreeRTOS) nicht als direkte Konkurrenz zu unseren Angeboten wahrnehmen.

Lasst uns ein wenig über die Vergangenheit reden. Es gibt ja immer wieder Gerüchte, dass der Verkauf von FreeRTOS an Amazon eine „Notverkaufshandlung“ seitens Real Time Engineers war. Hast du diesbezüglich irgendetwas zu sagen?

Ich weiß nichts darüber, „wie“ die Transaktionen zwischen Amazon und Real Time Engineers abgelaufen sind. Weil FreeRTOS in der Vergangenheit aber ein vergleichsweise frei lizenzierbares, quelloffenes Betriebssystem war, kann ich mir nicht ganz vorstellen, wie es zu einem Notverkauf kommen sollte.

Diese Entscheidung dürfte Microsoft unter Druck gesetzt haben. Oder hast du eine andere Erklärung für die Übernahme von ThreadX?

Ich bin mir sicher, dass „so etwas von so etwas“ kommt. Und wenn es nur der Effekt war, dass diese doch stark publizierte Übernahme mehr Aufmerksamkeit für den Embedded-Bereich als Ganzes geschaffen hat.

Microsoft hatte bisher im Embedded-Bereich durchaus Probleme: Egal ob Sendo, der NetDuino oder der Gagdeteer. Denkst du, dass ThreadX in seinem „neuen Heim“ eine gute Zukunft haben wird?

Ich denke, dass ThreadX ein großartiges neues Zuhause gefunden hat. Das IoT-Team bei Microsoft versteht definitiv, wie der Embeddedbereich funktioniert und ist sich auch über die Bedeutung bzw. Relevanz von ThreadX im klaren.

Wenn einer meiner Leser mit ThreadX anfangen möchte – welche Ressourcen würdest Du empfehlen?

Ich würde vorschlagen, dass er im ersten Schritt unsere Firmenwebseite besucht. Dort gibt es jede Menge technische Informationen. Wer noch mehr Daten haben möchte, soll sich den User Guide herunterladen.

Planst Du auch, Präsenz außerhalb der vereinigten Staaten von Amerika zu haben?

Ja, im Laufe der Zeit werden wir unseren internationalen „Footprint“ erweitern – ganz analog dazu, wie es damals bei Express Logic lief.

Entwickler von Echtzeit-Betriebssystemen reden nur ungern über den Preis. Ich muss aber trotzdem fragen – in einer Zeit der kostenlosen Echtzeitbetriebssysteme würde ich gerne wissen, was wir „ungefähr“ im Bereich der Kostenfrage erwarten dürfen.

Wir werden permanente Lizenzen anbieten, die ohne Zahlungen für die einzelnen Geräte auskommen – im Bereich der Preise kann ich „reasonably priced – generally less than a couple months of an engineer’s salary“ zusagen. Außerdem werden wir ein Abonnement anbieten, wo Startups pro Entwickler bezahlen.

Community-Frage: Wie unterscheidet sich von der PX5 vom unter https://nuttx.apache.org/ bereitstehenden NuttX. NuttX ist ja seit vielen Jahren am Markt, und behauptet ebenfalls, POSIX-kompatibel zu sein.

Ich habe in der Vergangenheit immer wieder einen Blick auf NuttX geworfen, ohne es aber im Detail zu studieren. Wie ich vorher zu Zephyr gesagt habe: Jede Lösung, die die POSIX-PThreads-API „vorwärts treibt“, ist meiner Ansicht nach für die Embedded-Industrie als Ganzes ein net positiv.

Danke Dir vielmals für deine Zeit. Gibt es sonst noch etwas, was Du sagen möchtest?

Ich möchte mich noch vielmals dafür bedanken, dass ich über diese Themen mit Dir reden darf. Und es freut mich sehr, wieder zurück in der Embedded-Industrie zu sein.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Bill Lamie – er war jahrelang Präsident des Herstellers von ThreadX (heute Azure RTOS) – schickt mit PX5 ein neues Echtzeitbetriebssystem ins Rennen. Hervorragendstes Attribut der neuen Plattform ist Unterstützung für die POSIX-API, was mit Linux und anderen unixoiden Betriebssystemen aufgewachsen Entwicklern Umlernaufwand spart.

Bildquelle: PX5

Worum geht es hier?

Echtzeitbetriebssysteme gibt es per se en masse: „Problematisch“ ist, dass vom Desktop oder von größeren Embedded-Systemen umsteigende Entwickler eine neue API zur Nutzung von Threading erlernen müssen.
Im Linux- bzw. Unix-Bereich hat sich POSIX als Standard etabliert – PX5 unterstützt diese API „nativ“, die oft für zusätzlichen Aufwand sorgenden Übersetzungs-Schichten sind nicht erforderlich.

Eine Frage der Einbindung.

Außer Frage steht, dass Codegeneratoren wie Cube oder MCC die „Inbetriebnahme“ der immer komplizierter werdenden Peripherie-Geräte moderner Mikrocontroller wesentlich erleichtern.
PX5 begegnet diesem Problem dadurch, dass es sich – siehe auch das Architekturdiagramm – auf die Kernaufgaben eines Echtzeit-Betriebssystems beschränkt.

Bildquelle: https://px5rtos.com/px5-rtos/, Diagramm ist anklickbar

Aus dieser Vorgehensweise der Reduktion ergibt sich ein sehr einfaches Deployment des Echtzeit Betriebssystems. Im nach Anmeldung (mit Linkedin-Konto besonders bequem) unter https://px5rtos.com/px5-rtos-user-guides/ zugänglichen User Guide wird davon gesprochen, dass man für die Einbindung neben einigen Header-Dateien lediglich die Files px5.c und px5_binding.s benötigt. Das eigentliche „Anwerfen“ des ersten Threads könnte dann einfacher nicht sein:

Ein weiterer Nebeneffekt dieser „Reduktion auf das Minimum“ ist, dass das Betriebssystem mit sehr wenig Ressourcen auskommt. Eine Minimalinstallation soll laut PX5 mit rund 1 kB Remanentspeicher und 1 kB Arbeitsspeicher ihr Auskommen finden – dass die Nutzung höherwertiger Funktionen mehr Speicher verbraucht, dürfte aus der Logik folgen.
Auf einem mit 80 MHz getakteten Kortex-Controller verspricht PX5 außerdem, dass ein Context-Switch normalerweise in weniger als 1 µs abgeschlossen werden kann.

Speicher-Verifikation durch „Canaries“.

Ein weiteres interessantes Feature von PX5 läuft unter dem Namen „PX5 RTOS Pointer/Data Verification (PDV)“. Dabei handelt es sich um ein Verfahren, das unautorisierte Speicher-Zugriffe zu erkennen sucht. Dies erfolgt durch Berechnung einer Checksumme, was nach folgendem Schema passiert:

Bildquelle: PX5.

PX5 verspricht, dass die Aktivierung dieses Systems, das – normalerweise – nur die „eigenen Strukturen“ des Echtzeit Betriebssystems schützt, mit vergleichsweise wenig Overhead einhergeht – aus einer ein bis zwei Instruktionen benötigenden Anweisung wird eine 6-8 Instruktionen benötigende.

Integration ins Ökosystem

In kurzer Zeit plant PX5 sowohl das zur-Verfügung-Stellen eines GUI-Stacks als auch eines TCP-IP-Stacks. In beiden Fällen möchte das Unternehmen dabei auf „etablierte“ Mitspieler im Ökosystem setzen – weitere Informationen hierzu kommen in wenigen Tagen in Form eines Interviews mit Bill Lamie, das schon von seinem PR-Team bearbeitet wird.

Schon im Rahmen der „Ankündigung“ der Verfügbarkeit des Echtzeit Betriebssystems kündigte man die ersten Partnerschaften an – neben dem Bluetooth und WLAN-Stack-Spezialisten Clarinox (siehe https://www.businesswire.com/news/home/20230125005148/en/Clarinox-Strengthens-Wireless-Connectivity-Development-for-IoT-Devices-with-Support-for-Innovative-PX5-RTOS) und dem Tracing-Spezialisten Percepio (siehe https://www.electronicspecifier.com/industries/industrial/percepio-to-support-px5-rtos-with-tracealyzer-tool) gab es auch eine Ankündigung von CypherBridge (https://www.businesswire.com/news/home/20230125005146/en/Cypherbridge-Enhances-Security-and-Interoperability-for-IoT-Devices-with-Support-for-New-PX5-RTOS).
Einige Stunden später folgte IAR:

Was kostet es, und wie wird es supportet?

Die Lizenzierung, und insbesondere die Lizenzkosten von Echtzeitbetriebssysteme sind immer ein „haariges“ Thema. Zum Zeitpunkt der Drucklegung dieses Artikels gibt es noch keine öffentlichen Informationen dazu – unter der URL https://px5rtos.com/licensing/ findet sich auf der Webseite aber die gezeigte Abbildung, die die „Flexibilität“ im Bereich der Lizenzierungsbedingungen illustrieren soll.

Welche Systeme werden unterstützt?

Ob der „Ultra neuen“ Verfügbarkeit gibt es derzeit noch keine vollständige Kompatibilitäts-Liste für PX5. Unter https://px5rtos.com/semiconductor/ gibt es allerdings schon jetzt eine Liste der unterstützten Halbleiterpartner. In der unter https://px5rtos.com/px5-rtos-faq/ bereitstehenden FAQ findet sich außerdem die folgende Aussage.

In eigener Sache

Obwohl das Interview zum Thema bereits in Arbeit ist, ist Bill Lamie gewillt, weitere Anfragen der Community entgegenzunehmen und zu beantworten. Bitte einfach hier einen Kommentar posten – der Autor kümmert sich um die Übersetzung.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More