News News-Roundup: Arduino-Multitasking, Raspberry Pi mit Vulkan, OrangePi-Display uvm


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Angehängte Dateien:

Lesenswert?

Die Welt der Halbleiter steht nie still. Im Arduinobereich laufen Arbeiten an der Standardisierung einer Multitasking-API, während Eben Uptons Mannen an Unterstützung für den Grafikstandard Vulkan arbeiten. Außerdem gibt es einige interessante Referenzdesigns und neue Software – Zeit für den News-Roundup!

Arduino plant Multitasking-API

Schon auf dem 2016 abgehaltenen Arduino Summit sprach man darüber, dass die Nutzung eines Echtzeitbetriebssystems zur Realisierung der Wiring-API in Zeiten immer komplizierterer SoCs der Weg in die Zukunft ist. Aus der Logik folgt, dass die zugrundeliegenden APIs auch für Entwickler interessant sind, die mehrere Aufgaben paralell ausführen wollen. Nun plant die Arduino-Entwicklerschaft eine neue API, die eine einheitliche API zur Realisierung von Nebenläufigkeit bereitstellen wird:

1
The goal is to define a standardized API that can be ported across all architectures and that, in line with the Arduino philosophy, will make complex things easy for anyone. Multitasking is a hard concept, so here we have plenty of margin to bring the Arduino approach to make this available to everyone.

Wer sich an der Diskussion beteiligen will, kann dies in GitHub unter der URL https://github.com/arduino/language/discussions/2 tun.

Raspberry Pi IV – Vulkan-Zertifiziert

Die OpenGL-Alternative Vulkan ist im Desktop- und Mobilbereich seit einiger Zeit En Vogue – der Raspberry Pi IV wurde soeben vom Standardisierungsgremium Khronos zertifiziert.

(Bildquelle: https://www.khronos.org/conformance/adopters/conformant-products#submission_694)

Laut dem für die Entwicklung verantwortlichen Unternehmen Igalia sollen die Modifikationen bald Teil des Hauptbetriebssystem-Branches werden:

1
All the changes required for this have already been merged in the upstream v3dv Mesa driver and will eventually be available in future Raspberry Pi OS updates.

Chiphersteller: Berichtssaison läuft, Ergebnisse eher schlecht

Die für Trader wichtige Berichtssaison hat begonnen, die Ergebnisse der Chipindustrie fallen eher verhalten aus. Der Onlinebroker eToro fasst die Situation in seiner aktuellsten Aussendung an Statuskunden folgendermaßen zusammen:

1
Die US-Chiphersteller brachen gestern ein, nachdem Micron Technology (-3,68%) vor einer nachlassenden Nachfrage gewarnt hatte. Das Unternehmen mit einer Marktkapitalisierung von 68 Mrd. $ erklärte, dass "schwierige" Bedingungen dazu führen könnten, dass der Umsatz im vierten Quartal "am oder unter dem unteren Ende" der bisherigen Prognose liegen könnte. Die Warnung kommt einen Tag, nachdem NVIDIA weniger Umsatz als erwartet mit seinen Gaming-Chips gemeldet hat.

DS2488 1-Wire-Referenzdesign für Headset-Energieverwaltung

Der einst von Dallas Semiconductor entwickelte OneWire-Bus hilft beim Einsparen von Steckverbindern. Mit dem unter https://www.maximintegrated.com/en/design/reference-design-center/ref-circuits/7519.html bereitstehenden Referenzdesign MAXREFDES1302 zeigt Maxim nun eine komplett durchimplementierte Applikation, die den OneWire-Bus zur Energieverwaltung in der Ladestation eines drahtlosen Kopfhörersystems einspannt.

(Bildquelle: Maxim)

Microchip: Investitionen in Zeitsynchronisationsprodukte laufen weiter

Microchip forciert das Anbieten “schlüsselfertiger” eigener Produkte. Der SyncServer S600 Network Time Server wurde vor einiger Zeit in einem Newsletter an alle registrierten Nutzer der Chips beworben – wer ein NTP-Synchronisationssystem benötigt, findet hier eine Alternative zu Pendulum und Co.

(Bildquelle: https://www.microchip.com//en-us/solutions/timing-synchronization/trusted-time)

TouchGFX nun mit besserer Modularisierung

Der einst von Draupner entwickelte GUI-Stack TouchGFX gehört seit einiger Zeit zu STMicroelectronics, und wird – logischerweise – in STMCubeIDE integriert. Die neueste Version des Produkts erleichtert nun die Recyclage von Widgets:

1
To make widgets more straightforward, designers can group them inside a container. Containers are often the building blocks of an interface. They enable programmers to reuse a set of widgets across multiple screens without having to reconfigure them every time. Additionally, modifying a container impacts every screen using it, which vastly simplifies developments. TouchGFX also comes with predefined containers to hasten the most common design operations and developers can create custom containers.

Im Zusammenspiel mit der hauseigenen Beschleunigerengine Chrom-ART gibt es außerdem Performancesteigerungen bei der Verwendung von Vektorgrafiken:

1
TouchGFX 4.20 offers significant optimizations when processing vector graphics with an increase in efficiency of up to 70% in some cases. Developers can thus offer smoother animations on smaller MCUs or use more vector elements. However, developers will see the biggest performance gains on larger animations.
2
The new optimization utilizes Chrom-ART to offload the microcontroller during certain operations like color fills. ST also updated the way the framework computes the edges of a shape.

Weitere Informationen hierzu finden sich unter https://blog.st.com/touchgfx/.

Touchscreen für OrangePI-SBCs

Das Anbieten von Zubehör für Einplatinencomputer ist lukrativ – im Hause Shenzhen Xunlong steht ab Sofort ein Touchscreen zur Verfügung, der für die Nutzung mit Orange Pi 4 / 4B und 4LTS vorgesehen ist.

(Bildquelle: https://www.aliexpress.com/item/1005004593686946.html)

Im Bereich der Auflösung bietet das per MIPI DSI ansprechbare Display “nur” 1280x800, was ob der Diagonale von 10.1 Zoll allerdings nicht zu dramatisch ist. Für die Helligkeitssteuerung steht PWM zur Verfügung, zur Verbindung mit dem Prozessrechner ist allerdings eine Adapterplatine erforderlich.

(Bildquelle: https://www.aliexpress.com/item/1005004593686946.html)


: Bearbeitet durch NewsPoster
von Rudolph R. (rudolph)


Lesenswert?

>Arduino plant Multitasking-API

Die sollten mal lieber eine DMA-API andenken, vor allem so für Dinge wie 
SPI.
Im Moment macht das jeder Arduino Core unterschiedlich und meistens kann 
man die SPI Klasse nicht nutzen, wenn man DMA machen möchte.
Aber bisher sind ja nicht mal die SPI-Klassen einheitlich, nicht mal 
wenn es von Arduino selber kommt, so wie bei ArduinoCore-mbed.

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


Lesenswert?

Rudolph R. schrieb:
>>Arduino plant Multitasking-API
>
> Die sollten mal lieber eine DMA-API andenken, vor allem so für Dinge wie
> SPI.

Meine Rede.

> Im Moment macht das jeder Arduino Core unterschiedlich und meistens kann
> man die SPI Klasse nicht nutzen, wenn man DMA machen möchte.
> Aber bisher sind ja nicht mal die SPI-Klassen einheitlich, nicht mal
> wenn es von Arduino selber kommt, so wie bei ArduinoCore-mbed.

Es bewahrheitet sich, was die Leute um Frederico Musto damals gesagt 
haben. Die Wiring-API ist und bleibt nun mal etwas "externes"...und es 
kommt halt immer wieder zu Reibereien beim Umsetzen bestimmter Features.

von Christoph M. (mchris)


Lesenswert?

>Die Wiring-API ist und bleibt nun mal etwas "externes"...und es
>kommt halt immer wieder zu Reibereien beim Umsetzen bestimmter Features.

Was soll "etwas externes" bedeuten?

Soll es bedeuten, dass der Autor von "Wiring" Hernando Barragán extern 
war und immer von den Arduino Entwicklern ignoriert? Dann würde ich 
empfehlen, die Geschichte dazu zu lesen:

https://arduinohistory.github.io/

Zur Zeit des Arduino Starts gab es genügend Mikrocontrollerboards und 
auch genügend Entwickler, die versucht haben, etwas Universelles zu 
schaffen.
Obwohl Wiring etwas gewöhnungsbedürftig war und seine Schwächen hat, war 
es zusammen mit der "trivial" IDE und der Möglichkeit, das Board 3 
Minuten nach dem Auspacken zum Blinken zu bringen, sowie der 
Verfügbarkeit von mit einem Klick einbindbaren Codebeispielen 
entscheidend für den Erfolg des Arduino-Frameworks. Ohne das wäre das 
System so unbedeutend wie alle andere geblieben.

Und ja: es gibt keine API (von keinem Hersteller und für keinen 
Mikrocontroller), die alle möglichen Optimierungskriterien eines 
Softwareframeworks erfüllt:

- Einfachheit
- Verständlichkeit
- Geschwindigkeit (bekanntes Beispiel Portfunktionen)
- Codegröße
usw

Das Framework hat viele Schwächen, die man überarbeiten oder 
nacharbeiten müsste, da wären
- die erwähnten DMA Funktionen
-- I2S Standardisierung
-- Unterstützung mehrfach ADCs für high speed sampling
-- Unterstützung für DACs
- standardisierte Timer-API teilweise bei STM32duino vorhanden

Schön an der IDE ist die Verfügbarkeit eines grapischen Plotters, mit 
dem man die bei Mikrocontrollern üblicherweise anfallenden analogen 
Daten schnell sichtbar machen kann. Nicht so schön ist, dass man in der 
langen Entwicklungszeit der IDE nie eine Zoom-Möglichkeit, Holdfunktion, 
Grid und Speichermöglichkeit hinzugefügt hat.

Die Vielheit der MCUs und ihrer Peripherie macht es immer schwieriger, 
alle MCUs mit einer einheitlichen API zu unterstützen.

Und noch was: Ich verwende seit vielen Jahrzehnten alle möglichen Arten 
von Mikrocontrollern und es war immer unnötig aufwendig, für jedes 
Framework die Peripherie-APIs zu lernen. Da ist eine Standardisierung, 
wie sie von Wiring angefangen wurde, zumindest sehr nützlich, um diesen 
Aufwand zu vermeiden.

Was das Multitasking Framework anbelangt, wird es spannend, ob man das 
in genügender Einfachheit hin bekommt. Die Problematik bei Multitaskings 
Systemene liegt in Deadlocks und der schwierigen Analysierbarkeit von 
Timing Overloads, die meist in der Implementierung der Anwender liegt.

Dieser Beitrag kann nur von angemeldeten Benutzern beantwortet werden. Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.