Kategorie: News

Wenige Monate nach der Auslieferung der Version 5.0 von ESP_IDF legt Espressif eine Nachfolgeversion vor. Am wichtigsten ist die Unterstützung für die neuen Chips H2 und C6; außerdem gibt es Fehlerbehebungen und Änderungen, die Anpassungen an vorhandenem Applikationscode erforderlich machen.

Worum geht es hier?

Wer die maximale Leistung seines ESP32 ausnutzen möchte, setzt auf die native Entwicklungsumgebung ESP_IDF. Systeme wie der Arduino basieren intern übrigens ebenfalls auf IDF – die als Arduino Core bezeichnete Arbeitsumgebung ist eine Softwareschicht, die über dem eigentlichen IDF-Framework liegt und die Ausführung der Sketches ermöglicht.

Unterstützung für C6 und H2

Die für den Smart Home-Bereich und Protokolle wie Matter vorgesehenen Chip-Varianten ESP32-C6 und ESP32-H2 waren bisher nur teilweise unterstützt – die neue Version erweitert die Unterstützung.
Weitere Informationen zu den Unterstützungsgraden der Peripheriegeräte finden sich für den C6 unter https://github.com/espressif/esp-idf/issues/10423, während der H2 unter https://github.com/espressif/esp-idf/issues/11038 abgehandelt wird. Zu beachten ist, dass Engineering Sample-Varianten der H2-Chips in 5.1 nicht mehr unterstützt werden!

Zu beachten ist außerdem, dass der ESP32-C6 bei Nutzung dieser Version mit den folgenden Problemen zu kämpfen hat:

Zudem gilt, dass die FPU in manchen Fällen Probleme bekommt:

Liste der Breaking Changes

Espressif spricht in der unter https://github.com/espressif/esp-idf/releases/tag/v5.1 bereitstehenden Ankündigung des Releases – wie in der Abbildung gezeigt – davon, dass die neue Version von ESP_IDF „im Allgemeinen“ mit schon vorhandenem Code kompatibel sein sollte.

Bildquelle: Espressif.

In der Praxis gibt es allerdings einige Probleme, die folgendermaßen aufgelistet sind:

Was ist neu?

Neben der „Erweiterung“ der unterstützten Chips führte Espressif Verbesserungen im Bereich der Funkmodule bzw. der Coexistenz verschiedener Funkprotokolle durch:

Im Bereich der neu hinzugekommenen Funktionen finden sich im Allgemeinen Detailverbesserungen; die auf RISC-V-Technologie basierenden ULP-Zellen von S2 und S3 sind nun zur Kommunikation per I2C befähigt.
Espressif behob außerdem die folgenden bekannten Fehler:

Ausblick und Mehr

Espressif bietet unter der URL https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides/release-5.x/5.1/index.html umfangreiche Dokumentation an, die auf die Änderungen und Neuerungen eingeht. Der Changelog unter der URL https://github.com/espressif/esp-idf/releases/tag/v5.1 ist ebenfalls interessant, weil er „Verweise“ auf die zu den jeweiligen Änderungen gehörenden Diskussionen anbietet.
Zu guter letzt sei noch darauf hingewiesen, dass Espressif – naturgemäß – schon an der Nachfolgeversion 5.2 arbeitet. Weitere Informationen hierzu werden unter der URL https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides/release-5.x/5.2/index.html zur Verfügung gestellt – zum Zeitpunkt der Drucklegung gibt es noch nur den folgenden Breaking Change:

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Am dritten Tag offenbarten sich Google und Meta (ehemals Facebook) als intensive Nutzer von Zephyr. Außerdem gab es Neuigkeiten zu Espressifs und STs Positionierung im Bezug auf das quelloffene Echtzeitbetriebssystem. Hier ein weiterer Neuigkeiten-Roundup.

Google und Meta nutzen Zephyr

Zephyr erfreut sich durchaus mächtiger Referenzkunden: Google kündigte im Rahmen einer Keynote an, das System in Zukunft in allen Chromebooks im Embedded Controller (lies: PMIC) einzusetzen.

(Bildquelle, wo nicht anders angegeben: Tamoggemon Holding k.s.)

Meta liess sich als Reaktion darauf nicht lumpen: das ehemals als Facebook verriet, Zephyr sogar in zwei hauseigenen Halbleitern einzusetzen.

Im Fall beider AI-Beschleuniger kommt Zephyr in der “Management Engine” zum Einsatz: ein spezialisierter Controller, der sich um die Verwaltung und Konfiguration der AI-Beschleunigerelemente des Chips kümmert.

Google: bauet Emulatoren und CI’et euch

Der Sprecher von Meta betonte die Wichtigkeit, mit der Softwareentwicklung vor der Verfügbarkeit des eigentlichen Chips zu beginnen. Aus der Logik folgt, dass Emulatoren hierzu hilfreich sind – den Vortrag zum Thema hielt dann wieder ein Googler.
Sein Einstieg in die Thematik war, dass die Nutzung von Sensoremulatoren verschiedene fortgeschrittene Methoden der Softwareentwicklung im Embeddedbereich ermöglicht bzw. begünstigt.

Zephyr erleichtert die Aufgabe insofern, als der Emulator auf Ebene der Bus-API andocken kann. Eine Compilerkonstante ermöglicht dann den Wechsel zwischen dem emulierten und dem realen Betriebsmodus.

Espressif: Zepyhr-Portierung vermeldet Fortschritte auf ganzer Linie

Espressif setzt in ESP_IDF – per se – auf FreeRTOS – eine nicht unvernünftige Kooperation, da das Unternehmen auch diverse Clouddienstleistungen von Big A bezieht. Trotzdem ist das hauseigene Zephyr-Team mittlerweile vier Mann stark.

Im Rahmen des Vortrages zeigte man unter Anderem die Tabelle, die über die jeweiligen Unterstützungsgrade der verschiedenen Prozessorfamilien und ihrer enthaltenen Peripheriegeräte informierte.

Zur Demonstration der Möglichkeiten setzte man auf eine über zwei Kerne verteilte Motorsteuerung auf einem klassischen ESP32: interessant daran ist, dass CPU1 ihren Code derzeit nur aus dem RAM beziehen kann.

BeagleBone: man kombiniere Zephyr und Linux

BeagleBones Neuvorstellungen richten sich direkt an Personen, die einen kombinatorischen Prozessrechner auf Basis von Zephyr und Linux zu realisieren suchen.

Im Vortrag des Firmengründers stellte BeagleBone verschiedene Varianten vor, um die beiden Systeme zusammenarbeiten zu lassen – in Retrospektive gilt, dass die Wichtigkeit des Arduino Yun nicht zu unterschätzen ist.

Neue APIs für Zephyr

Im Rahmen einer Gruppe von Talks stellten Entwickler Erweiterungen der Zephyr-APIs vor. Von Nordic Semi stammten zwei Talks, die auf den USB-Stack des Echtzeitbetriebssystems eingingen: interessant, weil dadurch Feature-Parität zu Azure RTOS und seinem USB-Paket hergestellt wird.
Das unter https://static.sched.com/hosted_files/eoss2023/1c/Introducing%20the%20Zephyr%20Input%20subsystem.pdf? en Detail beschriebene Eingabe-Subsystem zeigt die Nähe zwischen Linux und Zephyr – die Zephyr-Entwickler liessen sich von Linux inspirieren, um eine generische API für diverse Eingabegeräte zu finden.
Interessant ist auch der von Facebook vorangetriebene POSIX-Interfaceport, der Zephyr eine vollständige Implementierung von POSIX einzuschreiben sucht.

Bildquelle: https://static.sched.com/hosted_files/eoss2023/fd/ZDS-2023_%20POSIX%20Roadmap%20for%20Zephyr%20LTSv3.pdf

Neuerungen von Embedded Linux

Embedded Linux kam naturgemäß ebenfalls zur Sprache. Problem Nummero eins ist in vielen Fällen das Fehlen verschiedenster Zertifikate – eine Situation, der CodeThink mit RAFIA Änderungen verschaffen möchte. Grund für Friktionen zwischen Standardisierungsgemium und “modernem Entwickler” dürfte in vielen Fällen die Tatsache sein, dass das durchschnittliche Standardisierungsgremium moderne Methoden der Softwareentwicklung absolut nicht berücksichtigt.

Themenkreis Nummero zwei waren die verschiedenen Kernelpatches, die Linux Echtzeitfähigkeit verschaffen sollen. Der von

STMicroelectronics klarifiziert Position zu Zephyr

Die Nachfrage meiner Wenigkeit, wie das Engagement in Zephyr zur Azure RTOS-Strategie passt, löste bei den Francoitalienern erhebliche Aktivität aus. Einen Tag nach der Frage passte mich ein höherer ST-Manager überraschend an der Futterstelle ab, um nachzufragen, “welches Problem mein Unternehmen mit STs Engagement für Zephyr habe” (sic).
Auf meine Erwiederung, dass dies eine erhebliche “Störung” der Klarheit des Ökosystems darstellt, offenbarten sich zusätzliche Informationen. ST investiert in Zephyr, weil Halbleiterkunden dies wünschen – das präferierte Echtzeitbetriebssystem im Hause ST sei nach wie vor Azure RTOS, man wolle allerdings an Zephyr interessierten Kunden unter die Arme greifen.

Slides und mehr

Die Linux Foundation versprach in einer nach dem Ende des Kongresses an alle Teilnehmer versendeten E-Mail, Videos der Talks baldigst unter https://www.youtube.com/user/thelinuxfoundation online zu stellen. Schon jetzt gilt, dass die unter https://events.linuxfoundation.org/embedded-open-source-summit/program/schedule/ bereitstehende Webseite für den Gutteil der Talks die Slides im PDF-Format bereitstellt.

In eigener Sache: Grüße an die Leser!

Der Newsaffe wurde von zwei nichtrauchenden und einem rauchenden Fan angesprochen, die Nichtraucher posierten – hier die versprochenen Bilder; es war mir eine Ehre.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Die Linux Foundation ist mehr als Linux: mit Zephyr pflegt man seit neun Jahren ein Echtzeitbetriebssystem, das man mit einem Ökosystem-Play zu unterstützen sucht. Arduino gab sich ein inoffizielles Stelldichein. Ausserdem erobert Linux den Weltraum – was es an den ersten Tagen zu sehen gab, verraten wir hier.

Zephyr abseits des Echtzeitbetriebssystems…

Anas Nashif sprach in der Keynote des zweiten Tages davon, dass Zephyr nicht auf das Bereitstellen klassischer RTOS-Funktionalität beschränkt sein soll. Stattdessen sollen Contributoren – siehe auch die Folie – auf höheren Schichten lebende Funktionen committen.
Sinn davon ist ein Ökosystem-Play, um die von Amazon FreeRTOS bzw. Azure RTOS angebotenen Value Added Features zu kompensieren. Echtzeitbetriebssysteme beschränken sich in der heutigen Zeit nicht mehr auf das Verwalten von Threads, sondern versuchen, Entwicklern immer mehr eine “Komplettlösung aus einer Hand” zu präsentieren.

(Bildquelle alle: Tamoggemon Holding k.s.)

Im Hintergrund erfährt Zephyr in verschiedenen Bereichen Erweiterungen. Im Bereich Eventsysteme bzw IPC stellte ein Entwickler von Meta Experimente zur Nutzung des hauseigenen Protokolls Thrift vor. Lustig war die Folie, die (neben realistischeren Systemen) die Verwendung eines Dual Port-SRAM als Kommunikationsschnittstelle avisierte.
Als primäres Problem für die breitere Nutzung erweist sich übrigens die fehlende C++-Unterstützung in Zephyr, weshalb Meta von der produktiven Nutzung Thrifts unter Zephyr abrät.

Interessantes Produkt Zwei ist der ZBus: ein klassischer Message-Bus, der analog zum in QtCore enthaltenen Signal-Slot-System die Entkoppelung innerhalb einer Applikation erlaubt. Lobenswert ist, dass laut der unter https://eoss2023.sched.com/event/1LcMe/zbus-the-lightweight-and-flexible-zephyr-message-bus-rodrigo-peixoto-edge-ufalcitrinio? bereitstehenden Ankündigung geplant ist, ZBus bald auch in ISRs arbeiten zu lassen.

Visual Studio Code hat sich als Quasistandard für die Zephyrentwicklung etabliert. Noch gibt es allerdings kein einheitliches Plugin-Komplement – in einem Vortrag des Beratungsunternehmens Golioth (siehe https://eoss2023.sched.com/event/1LcO9/zephyr-visual-studio-code-how-to-develop-zephyr-apps-with-a-modern-visual-ide-jonathan-beri-golioth?) stellte der Sprecher eine empfehlenswerte Sammlung vor. Besonders interessant ist nach Ansicht des Autors die von Microsoft zur Verfügung gestellte Terminalerweiterung, die ein universelles und cross-plattform-verfügbares serielles Terminal realisiert.

Unter https://eoss2023.sched.com/event/1LcMP/practical-tips-to-boost-your-productivity-when-using-zephyr-benjamin-cabe-the-linux-foundation findet sich derweil eine ebenfalls sehenswerte Präsentation, die diverse wenig beachtete Aspekte der Zephyr-Toolchain zum Fokus hat.
Zu guter Letzt kündigte man an, den Bug im Bereich der Dynamic Kernel Thread Stacks behoben zu haben – ein gravierendes Hindernis für die C++-Unterstützung weniger.

…und im Hause STMicroelectronics

STs Entscheidung, Atollic zu erwerben, sollte zu einer „Bereinigung“ des Ökosystems führen. Die unter Beitrag „STMicroelectronics: Azure RTOS im Fokus“ im Detail beschriebene Vorstellung des U5 ging mit der Ankündigung einher, fortan Azure RTOS als „Standardbetriebssystem“ verwenden zu wollen – die großartige Integration in Cube erleichtert das Deployment.
Auf dem Kongress zeigte ST, dass man auch an Zephyr Interesse hat. Der eigentliche Entwicklungsprozess erfolgt dabei ohne grafische Unterstützung; bis der Code lauffähig ist, ist manuelle Anpassung erforderlich.

Langfristig evaluiert ST auf Nachfrage, Zephyr-Unterstützung in den Cube-Codegenerator zu integrieren – hierfür gibt es aber noch keine ETA.

Mender – OTA-Updates fuer Zephyr

Das quelloffene OTA-Aktualisierungssystem Mender ist im Bereich des klassischen Embedded Linux seit längerer Zeit nicht wegzudenken – dank eines Contributors aus der Community erweitert sich die Reichweite des Produkts in Richtung ESP32 und Co.

Das im gezeigten Repositorium zur Verfügung stehende Softwaremodul ist dabei plattformagnostisch: wer es auf einem neuen Mikrocontrollertyp zur Ausführung bringen möchte, muss lediglich die fehlenden plattformspezifischen Komponenten ergänzen.
Außerdem – auch dies eine Livevorstellung am OSS Summit – ist es ab Sofort möglich, über Mender auf die Terminalkonsole von Zephyr zuzugreifen.

Mit Linux in den Weltraum

Im Rahmen einer Keynote channelte der Sprecher – wohl unwollend – den vor kurzem verstorbenen CEO eines Nautikunternehmens: den Begriff des “New Space” wollen wir hier unkommentiert für sich sprechen lassen.

Mit Projekten wie Linux4Space stehen allerdings verschiedene auf die Nutzung im Weltraum optimierte Varianten von Linux zur Verfügung. Diese sind praktisch erprobt: der CubeSat ist eine Art “Clustersatellit”, der von kommerziellen Satellitenstartanbietern in die Umlaufbahn gebracht wird – einige davon basieren bereits auf Linux.

Arduino R4 WiFi „in leibhaftiger Form“

Während Seeed mit einem eigenen Stand (Fokus auf verschiedene Evaluationsboards im Zusammenspiel mit Zephyr) vertreten waren, suchte man Arduino vergeblich.

Im Meetingbereich kämpfte ein Entwickler der Italiener mit Bugs am Arduino R4 WiFi (und seiner sehr attraktiv aussehenden LED-Matrix); interessant empfand der Autor auch die Beobachtung eines Meetings des Arduinisten mit verschiedenen Zephyrentwicklern.

Es geht weiter…

Der Kongress geht noch zwei Tage weiter; wir berichten live. Wer vor Ort ist – der Newsautor freut sich über einen Raucherkollegen!

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Nach einer längeren “Vaporware”- bzw. Vorankündigungsphase steht die vierte Generation des Arduino-Evergreens Arduino R4 in gleich zwei Varianten im Arduino Store zur Verfügung. Was Arduino Uno R4 Minima und Uno R4 WiFi von den Vorgängern unterscheidet, klärt dieser Artikel.

Bildquelle: https://store.arduino.cc/pages/uno-r4

32bit-Rechenleistung, 5V-Kompatibilität

Auf Prerelease-Fotos waren sowohl der Formfaktor als auch die genaue Seriennummer des am Uno R4 verwendeten Prozessors durch ein gelbes Post-It kaschiert – im Rahmen der Freischaltung der Store Listings findet sich die in der Abbildung gezeigte Detailbeschreibung.

Bildquelle: Arduino

Arduino entschied sich für den RA4M1 – eine auf einem Cortex M4-Kern samt FPU basierende MCU, die Renesas wie in der Abbildung beschreibt.

Bildquelle, lesenswert: https://www.renesas.com/us/en/products/microcontrollers-microprocessors/ra-cortex-m-mcus/ra4m1-32-bit-microcontrollers-48mhz-arm-cortex-m4-and-lcd-controller-and-cap-touch-hmi

Neben der wesentlich höheren Rechenleistung erfuhr auch der Rest des GPIO-Komplements eine Erweiterung: wie viel davon in praktischen Arduino-Platinen zur Verfügung steht, ist naturgemäß vom PCB-Layout des jeweiligen Boards abhängig.
Durch die Bank steht nun allerdings eine Maximaltaktrate von 48 MHz zur Verfügung, der Flashspeicher ist nun 256KB groß. Das RAM ist 32KB groß.

Arduino Uno R4 Minima – preiswert, mit ISCP-Connector

Beim unter https://store.arduino.cc/products/uno-r4-minima um 18 EUR erhältlichen Arduino Uno R4 Minima setzt Arduino im Allgemeinen auf bekannte Kost: neu ist erstens ein erweiterter Versorgungsspannungsbereich von bis zu 24V und zweitens ein ISCP-Connector, der das direkte Debugging des am Rechners laufenden Codes erlaubt.

Bildquelle: Arduino

Wohl aufgrund dem Druck aus Richtung des DeviceScript-Ökosystems betont Arduino außerdem die HID-Fähigkeiten des neuen Boards:

Zu guter Letzt findet sich im unter https://docs.arduino.cc/resources/datasheets/ABX00080-datasheet.pdf bereitstehenden Datenblatt eine Tabelle mit weiteren Pinout-Daten.

Bildquelle: Arduino

Arduino Uno R4 WiFi – mit ESP32 und LED-Matrix

Unter https://store.arduino.cc/products/uno-r4-wifi wechselt die größere Variante um 25 EUR den Besitzer. Neben einem auf einem ESP32-S3 basierenden Funkmodul bringt sie eine LED-Matrix (12×8 rote LEDs) mit.

Bildquelle: Arduino

Bei sorgfältiger Betrachtung fällt ein QWIIC-Interface auf, das einen weiteren I2C-Bus in einem im Makerbereich populären Format exponiert.
Insbesondere für Quereinsteiger dürfte der WiFI-Fehleranzeiger hilfreich sein, der nach folgendem Schema beschrieben wird:

Kompatibilität: 5V ist nicht alles

Obwohl der verwendete Controller 5V-fähig ist, gilt, dass er naturgemäß mit AVR-Assembly nichts anzufangen weiss. In den Storeseiten warnen die Arduinoentwickler davor explizit:

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Obwohl Linux (und Windows für ARM) Fortschritte machen, gilt nach wie vor, dass viele Aufgaben mit X86-CPUs bequemer erledigbar sind. Als Beispiel für viele derartige „X86-Raspberry Pis“ wollen wir hier den Udoo Vision näher ansehen, der seit einigen Tagen kommerziell verfügbar ist.

Wie funktioniert es in der Theorie

Intels Versuche im Embeddedbereich verliefen wenig erfolgreich – die Quark-CPUs kündigte man bald unter Zurücklassung diverser Chippartner ab; Systeme wie der hier gezeigte Arduino Galileo dürften Seltenheitswert haben.

Bildquelle: Tamoggemon Holding k.s.

Heutige Embedded-x86-Systeme nutzen meist die aus dem Netbookbereich bekannten Atom-CPUs, die keine nennenswerten GPIO-Komplemente mitbringen. Zur Lösung des Problems, und aufgrund der extrem schlechten Echtzeiteignung von Desktop-Windows, realisieren so gut wie alle Anbieter einen kombinatorischen Prozessrechner – der Windows-Teil kommuniziert normalerweise per USB mit einem dedizierten zweiten Mikrocontroller, der sich um die Hardwarekommunikation kümmert.

Bildquelle: Udoo.

Im Fall des vorliegenden Systems gibt es derer sogar zwei: neben dem Arduino steht auch ein MEC1705 zur Verfügung, der einige weitere GPIOs und zwei serielle Busse exponiert. Sein unter https://ww1.microchip.com/downloads/aemDocuments/documents/CPG/ProductDocuments/DataSheets/MEC170x-Data-Sheet-DS00002206H.pdf bereitstehendes Datenblatt bietet mehr Informationen zum Thema an.

Inbetriebnahme…

Die Rückseite des Udoo Vision wird komplett vom Kühlkörper bestimmt; neben zwei Ethernet-Ports bringt die Platine auch zwei USB-Ports mit. Zum Installieren von Windows 10 – Windows 11 unterstützt die verwendete Atom-CPU nicht – ist ein Hub erforderlich, weil das Betriebssystemimage in Form eines von Workstation und Co bekannten USB-Stick angeliefert werden muss.

Bildquelle: Tamoggemon Holding k.s.

Für die Stromversorgung kommt zwingend ein dediziertes Netzgerät zum Einsatz, dessen Stecker nicht sonderlich zuverlässig ist. Sonst verhält sich die hier mit 8GB RAM und 64GB internem Flashspeicher ausgestattete Maschine im Allgemeinen so, wie man es von einem Windows-PC erwarten würde.
Der massive Kühlkörper katapultiert den Rechner außerdem in hohe Gewichtsklassen – siehe Abbildung.

Bildquelle: Tamoggemon Holding k.s.

… Findung unüblicher Erweiterungsmöglichkeiten …

Auf der Unterseite findet sich ein Portkomplement, das – unter Anderem – zwei USB 2.0-Ports, einen seriellen Port exponiert (siehe https://udoo.org/download/files/UDOO_VISION/Doc/UDOO_VISION_MANUAL.pdf).

Bildquelle: Tamoggemon Holding k.s.

Externe Erweiterbarkeit (Stichwort Funkmodul) steht in Form eines M2. Key B-Sockels zur Verfügung, außerdem findet sich ein gewöhnlicher SATA-Port. Außerdem ist eine externe Batterie anschließbar, die wohl die Echtzeituhr puffert.

…und Interaktion mit dem Arduino

Ein Blick auf die Unterseite der Platine zeigt – siehe auch das Makrofoto – das Echtzeitelement, das sich schaltungstechnisch streng am Arduino Leonardo orientiert.

Bildquelle: Tamoggemon Holding k.s.

Wer die Arduino IDE startet (oder in den Gerätemanager blickt), stellt fest, dass dieser Eindruck korrekt ist – der Arduno bucht sich unter Windows 10 in COM3 ein, und lässt sich von dort aus wie ein externes Board programmieren.

Kritik am vorliegenden Design

Das wichtigste Problem bei der vorliegenden Platine ist die Energieversorgung: die Verbindung zur Platine geht reproduzierbar verloren, sobald man den Rechner umdreht. Dies ist doppelt schade, weil er nur in diesem „umgedrehten“ Zustand zuverlässig steht – die Füße sind zu kurz.

Bildquelle: Tamoggemon Holding k.s.

Durch die Vibrationsempfindlichkeit disqualifiziert sich das System für die Nutzung als „mobiles Rechensystem“ – egal ob Drohne oder Fahrzeug gilt, dass Vibration zur Bewegung dazugehört.

Lohnt es sich?

x86-Boards sind schon ob der hohen Kosten – die vorliegende Planare wechselt um mehr als 300 EUR den Besitzer – nicht für jeden Einsatz geeignet. Nach Ansicht des Autors lohnt sich die Verwendung immer dann, wenn eine für x64 optimierte Applikation ausgeführt werden muss: Windows on ARM ist nun mal nicht mit allem kompatibel…

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Das quelloffene und im Makerbereich populäre Schaltungsentwurfsystem Fritzing liegt nun in Version 1.0 vor. Neben (eher kleinen) Verbesserungen gegenüber den 0.9.x-Versionen gibt es eine gravierende Neuerung: derzeit steht das neueste Release nur zahlenden Kunden zur Verfügung.

Bildquelle: Autor

Mehr Exportmöglichkeiten

Im Gerber-Exportmodul erweiterten bzw. behoben die Entwickler einige Holprigkeiten, die die erzeugten Gerberfiles suboptimal bzw schwierig renderbar machten. Am Wichtigsten dürfte die Unterstützung für schraffierte Rechtecke sein, was Masselayer-Nutzern mehr Flexibilität verschafft.
Außerdem verspricht man Unterstützung für Exporte ins IPC-D-356-Format, was dreidimensionale Vorschaurenderings der Platinen ermöglicht.
Zu guter Letzt enthalten exportierte Pick and Place-Files nun eine zusätzliche Spalte, die SMD- und THT-Bauteile unterscheidet. Das neue Format ist folgendermaßen aufgebaut:

Simulator ist nun offiziell

Fritzing brachte seit einiger Zeit einen auf SPICE basierenden Schaltungssimulator mit – in Version 1.0 ist er nun ein offiziell unterstütztes Feature. Außerdem erweitern die Entwickler die Spice-Dateien um Modelle für RGB-LEDs und Photosensoren.

Neue Schriftart und Anpassungen für Dark Mode

Als Hauptfont kommt nun OCR-Fritzing zum Einsatz – die neue Schriftart unterstützt unter Anderem das scharfe S und diverse andere in europäischen Sprachen verwendete Sonderzeichen.

Bildquelle: https://fritzing.org/releases/1-0-0

Ob der immer weiteren Verbreitung von Dark Mode erweiterte das Entwicklerteam einige Symbole, die nun auch in Dark Mode-kompatiblen Versionen zur Verfügung stehen. Zu guter Letzt gibt es Unterstützung für Multitouch.

Diverse Fehlerbereinigungen und Aktualisierungen

Im derzeit nur unter https://fritzing.org/releases/1-0-0 bereitstehenden Changelog informiert das Entwicklerteam über Anpassungen an den verwendeten Bibliotheken:

Außerdem wurden einige Bugs bzw Performanceprobleme behoben:

Von der Verfügbarkeit

Im Rahmen der Verfassung dieses Artikels hat sich der Newsaffe durch die (sehr aufwändige, weil schlecht dokumentierte) Kompilation unter Windows durchgearbeitet – unter https://youtu.be/deyyxNkQPSM findet sich ein Video, das den Prozess samt den diversen fehlenden Modulen en Detail beschreibt. Lohn der Mühen ist zum Zeitpunkt der Drucklegung eine Version 0.9.x.
Das unter https://forum.fritzing.org/t/can-t-find-source-code/19723 bereitstehende Forum bietet – siehe Abbildung – mehr Informationen zum Thema. Anscheinend dürften die Entwickler den Code erst später ausliefern; wohl um mehr Kunden zum Bezahlen für das fertig kompilierte Release zu animieren.

Bildquelle: https://forum.fritzing.org/t/can-t-find-source-code/19723

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

USB kam für Elektroniker einer Vertreibung aus dem Serail gleich – viele früher einfach realisierbare MSR-Aufgaben arbeiteten nun in Arbeit aus. Mit der für die Desktop-Programmierung vorgesehenen Meadow.Windows-Umgebung versucht Bryan Costanich, dieses Problem zu beheben.

Worum geht es hier?

Dass die Meadow F7-Ausführungsumgebung umfangreiche Treiber-Unterstützung mitbringt, ist aufgrund diverser Besprechungen in Microcontroller.net bekannt. Mit Meadow.Desktop für Windows versuchen Bryan Costanichs Mannen wie in der Abbildung gezeigt das Einschreiben eine Abstraktionsschicht.

Bildquelle: Autor.

Für die eigentliche Hardware-Kommunikation kommen GPIO-Extender zum Einsatz-der Autor wird in den folgenden Schritten ein FTDI FT2232H-MiniModule verwenden, das über MicroUSB Verbindung mit der mit Windows 11 ausgestatteten Workstation aufnimmt.

Einrichtung einer Arbeitsumgebung.

Ob des noch sehr frühen Entwicklungsstand ist Meadow Desktop derzeit nur leidlich in das Visual Studio-Plug-in integriert-im ersten Schritt öffnen wir die Arbeitsumgebung Visual Studio 2022 Developer Command Prompt, um danach durch Eingabe der folgenden Kommandos ein Arbeitsverzeichnis zu erzeugen:

Die eigentliche Generierung des Projektskeletts erfolgt dann in einem zweistufigen Verfahren. Als „erstes“ erzeugen wir eine neue Kommandozeilen-Applikation:

Im zweiten Schritt bekommt diese das Grundpaket Meadow.Windows eingeschrieben – es kümmert sich (unter anderem) um das Bereitstellen der in Abbildung eins gezeigten Treiberkomponenten:

Im nächsten Schritt können wir auch schon eine charakteristische Wellenform ausgeben. Hierzu bearbeiten wir die Datei Program.cs, deren Deklaration nun nach folgendem Schema beginnt:

Neben der Ableitung der App-Klasse von generischen Parameter Windows ist hier auch die Erzeugung der Klasse Ft232h interessant – sie erzeugt ein Abstraktionsobjekt, das den FTDI-GPIO-Expander für unseren .net-Code ansprechbar macht.
Im nächsten Schritt ist das eigentliche Hochfahren des Betriebssystemkerns erforderlich:

Zu guter Letzt findet sich dann das eigentliche Prozessrechnerprogramm, das sich vom Aufbau her stark daran orientiert, was man von der gewöhnlichen Meadow F7-Entwicklung kennt:

Sodann bietet sich eine erstmalige Kompilation an, was auf Kommandozeilenebene in der Eingabeaufforderung nach folgendem Schema erfolgt:

Wie die „Prozessrechner-Variante“ ist auch der Desktop-Version der Meadow-Arbeitsumgebung vollständig modularisiert. Aus diesem Grund erscheint die Fehlermeldung error CS0234: Der Typ- oder Namespacename „ICs“ ist im Namespace „Meadow.Foundation“ nicht vorhanden., die auf das Nicht-vorhanden-sein eines NuGet-Pakets hinweist. Die Behebung erfolgt folgendermaßen:

Im nächsten Schritt ist eine abermalige Kompilation und Ausführung erforderlich, was die beiden folgenden Befehle erledigen:

Zum Zeitpunkt der Drucklegung dieses Artikels gilt, dass das Basispaket die benötigten Treiber für das FTDI-Modul nicht „vollständig“ bereitstellt. Stattdessen erscheint die folgende Fehlermeldung:

Zur Behebung öffnen Sie die URL https://ftdichip.com/software-examples/mpsse-projects/libmpsse-spi-examples/ in einem Browser ihrer Wahl, und klicken auf den Link LibMPSSE V1.0.3. Entpacken Sie das Archiv dann, und erbeuten Sie die Datei im Ordner LibMPSSE_1.0.3Windowslibmpsse-windows-1.0.3.zipreleasebuildx64 befindlichen Dateien – sie wandern in das Verzeichnis C:UserstamhasourcereposdevexperimentMeadowWindowsSampleAppbinDebugnet7.0. Danach ist eine abermalige Ausführung möglich.

Evaluation der Ausgabegeschwindigkeit per Picoscope.

Unser hier verwendetes MiniModule besteht aus „zwei“ FTDI-Modulen – die API arbeitet normalerweise mit dem A-Modul. Aus diesem Grund verbinden wir den Kanal eins des PicoScope mit Pin AC0, wo wir das in der Abbildung gezeigte Schirmbild sehen.

Bildquelle: Autor.

Im nächsten Schritt bietet es sich an, nach folgendem Schema vier Zustandsänderungen in der Arbeitsschleife zu platzieren und so Rückschlüsse über die „Arbeitsgeschwindigkeit“ zu gewinnen:

An dieser Stelle erweist sich die Nutzung der Persistenzfunktion als wenig vorteilhaft, weil sie zu „Verwachschungen“ der extrem instabilen Ausgabe führt. Die beiden Abbildungen erlauben eine Abschätzung.

Bildquelle: Autor

Experimente mit höherwertigen Interfaces.

FTDI exponiert am FT232 sowohl einen I2C-als auch einen SPI-Bus – zum Zeitpunkt der Drucklegung weisen Bryan Costanichs Mannen in der Dokumentation an mehrerlei Stelle hin, dass derzeit nur die SPI-Implementierung funktionsfähig ist.
Für ein nächstes Experiment wollen wir auf das unter https://github.com/WildernessLabs/Meadow.Core.Samples/tree/main/Source/Meadow.Windows.Samples bereitstehende Beispiel setzen, dass das XXX-TFT-Display ansteuert.
Erste Amtshandlung ist auch hier die Wiederherstellung der diversen benötigten Pakete – öffnen Sie hierzu die Datei https://github.com/WildernessLabs/Meadow.Core.Samples/blob/main/Source/Meadow.Windows.Samples/IO/SPI/SPI.csproj, und analysieren Sie das nach folgendem Schema aufgebaute Mark-Up:

Im Fall des vorliegenden Beispiels lassen sich die fehlenden Elemente nach folgendem Schema importieren:

Leider gilt, dass die Ausführung des vorliegenden Programms im Moment zu folgenden Problemen führt:

In der „Theorie“ ist es möglich, nach folgendem Schema „andere“ Werte einzuschreiben – die-Definitionen finden sich dabei im unter http://www.ftdichip.com/Support/Documents/AppNotes/AN_114_FTDI_Hi_Speed_USB_To_SPI_Example.pdf bereitstehenden Dokument, das die FTDI-SPI-Implementierung en Detail erklärt und auf die Pin-Zuweisungen eingeht:

In der Praxis gilt derzeit allerdings, dass auch diese „fortgeschrittene“ Variante nicht zum Ziel führt – das Problem ist Bryan Costanich mittlerweile bekannt, und wird in einem Folgeteil behoben.

Was bringt es?

Mit Meadow.Desktop erleben mit COM-und LPT-Port aufgewachsene Entwickler in vielerlei Hinsicht die „Rückkehr ins Serail“. Im Zusammenspiel mit einem FTDI-MiniModule – der OEMSecrets-Bestpreis des hier verwendeten Bauteils (siehe https://www.oemsecrets.com/compare/FT2232H-56Q%20MINI%20MDL) liegt bei 30 EUR – bekommen Entwickler wieder niederschwelligen Zugang zu Hardware unter Nutzung von C# und Visual Basic. Schon aus diesem Grund sind die „Kinderkrankheiten“ zu tolerieren!

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Arduino, Raspberry Pi und die diversen kleineren Hersteller liefern sich einen harten Kampf um Marktanteile und Aufmerksamkeit – schon lang wird dabei nicht mehr nur mit Hardware, sondern auch mit “Value Added Services” gekämpft. Hier eine Liste neuer Funktionen der verschiedenen Anbieter,

Arduino Cloud interagiert mit ChatGPT

Mit dem unter https://projecthub.arduino.cc/dbeamonte_arduino/chat-with-chatgpt-through-arduino-iot-cloud-6b4ef0 en Detail beschriebenen Projekt verbindet Arduino das hauseigene Backend- und Dashboardsystem erstmals mit ChatGPT.

Bildquelle: Arduino

Interessant ist dabei, dass die eigentliche Verarbeitung der Anfragen nicht über die Cloud erfolgt. Stattdessen senden die Cloudwidgets die einzuholenden Prompts an den RP2040 Nano, der diese danach bei ChatGPT einreicht und die Ergebnisse in das Cloud-Dashboard zurückgibt.

Arduino Cloud: Unterstützung für JavaScript- und (Micro)Python-Applikationen

Die Arduino Cloud kommt normalerweise mit einer durchaus komfortablen Arduino-Bibliothek zum Anwender, die wir unter Beitrag „Arduino IoT Cloud – IoT-Clouddienst ohne MQTT“ en Detail beschrieben haben. Mit “Manual Setup for Any Device” steht nun ein generisches Interface zur Verfügung, über das beliebige Drittanbietergeräte Verbindung zur Arduino Cloud aufnehmen können.
Sowohl für JavaScript als auch für Python stehen unter https://docs.arduino.cc/arduino-cloud/getting-started/manual-device Bibliotheken bereit – ein kleines Beispiel für Python präsentiert sich folgendermaßen:

Udoo Boards: hauseigener Clouddienst CLEA ante portas

Das Boardhaus Udoo – bekannt für seine innovativen Designs und seine Glücklosigkeit mit Intel und der allgemeinen Komponentenverfügbarkeit – kündigte in einer Meldung an Käufer des Udoo Key einen neuen Clouddienst an. Als wichtigste Features avisiert man folgendes:

Unter https://clea.ai/ findet sich das in Abbildung zwei gezeigte Architekturdiagramm, das die Cloud als eine “lustige Mischung” verschiedener quelloffener und proprietärer Technologien präsentiert.

Bildquelle: SECO

Zur Bepreisung gibt es schon jetzt Informationen:

Raspberry Pi Pico W – Bluetooth jetzt offiziell

Die Entscheidung der Raspberry Pi Foundation, das Infineon-Funkmodul nur per SPI anzubinden (siehe https://www.youtube.com/watch?v=_-5gPj0fphg), dürfte wohl auch dem Mangel an GPIO-Ports am RP2040 geschuldet sein.

Sei dem wie es sei, ist die Bluetoothunterstützung für den Pico W nun offiziell. In der unter https://www.raspberrypi.com/news/new-functionality-bluetooth-for-pico-w/ bereitstehenden Ankündigung findet sich die Bestätigung, dass das Onlinebringen der Funktion nur Dank aktiver Mithilfe seitens Infineon möglich war:

Qt für Mikrocontroller – Version 2.5LTS verfügbar

Dass die Mikrocontrollervariante von Qt – neudeutsch Qt for MCUs – mit Qt im Allgemeinen nicht viel zu tun hat, ist spätestens ob des Fehlens von QtCore offensichtlich. Trotzdem erfreut sich der QML-Renderer immer höherer Beliebtheit.
Unter https://www.qt.io/blog/qt-for-mcus-2.5-lts-released findet sich nun die in der Abbildung gezeigte Grafik – wer der hohen Releasekadenz entkommen möchte, darf sich an einer neuen LTS-Version des Produkts erfreuen.

Bildquelle: Qt Group

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

AutoDesk finalisiert die Pläne für die Eagle-Abkündigung bzw. die Zusammenlegung mit Fusion 360. Von Seiten der hinter I3C stehenden Standardisierungs Organisations Mipi gibt es diverse „Standard-Updates“ und Whitepaper, während Audio Precision ein Whitepaper mit Daten zu Lautsprecher-Messungen zur Verfügung stellt.

Autodesk: Eagle wird nur noch Teil von Fusion 360

Seit der Übernahme von CadSoft durch Autodesk gibt es immer wieder Gerüchte, dass die Zeit der PCB-Layout Software Eagle „eingeschränkt“ sei. Im unter https://www.autodesk.com/products/fusion-360/blog/future-of-autodesk-eagle-fusion-360-electronics/ bereitstehenden Blogposts spricht Autodesk nun darüber, „wie“ die Zukunft von Eagle aussieht. Erstens gilt, dass Eagle in jeder alleinstehenden Form abgekündigt wird – am siebenten Juni 2026 endet jegliche Unterstützung. Spezifischerweise gilt, dass manche Abonnenten schon früher umsteigen müssen:

Als „Ersatz“ plant Autodesk – logischerweise – die Nutzung des hauseigenen Services Fusion 360; unter der URL https://assets.library.io/migrationGuides/migration-guide-EAGLE.pdf findet sich ein Migrationsguide.

Wichtig ist außerdem, dass die unter https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/Autodesk-EAGLE-Announcement-Next-steps-and-FAQ.html bereitstehende FAQ darauf hinweist, dass „uralte“ Lizenzen nicht ewig gelten werden – Spezifischerweise gilt folgendes:

Bildquelle: AutoDesk

I3C-Standard: Klarifizierung von Standard-Dokumenten, Plugfest und Whitepaper zu Energieeinsparungen

Dass ein Standard „nur“ eine Einladung ist, möglichst viele „inkompatible“ Systeme zu entwerfen, ist bekannt. Das hinter dem I3C-Bus stehende Standardisierungsgremium Mipi hat Formalisierungen vorgenommen, um die Dokumente weniger missverständlich zu gestalten.
Die wichtigste Neuerung betrifft das I3C Host Controller-Interface, in dessen Version 1.2 eine Gruppe neuer Features zur Verfügung steht:

Wer mehr Informationen über das neue Interface erhalten möchte, kann unter der URL https://www.mipi.org/specifications/i3c-hci die Spezifikation herunterladen – ein „Gutteil“ der Daten steht dabei auch für Nichtmitglieder zur Verfügung.
Neuerung Nummero zwei ist die Abhaltung eines der als „Plugfest“ bezeichneten Events.

Bildquelle: https://www.mipi.org/san-jose-plugfest?.

Analog zu den von diversen Feldbus-Standardisierungs Gremien veranstalteten Varianten gilt auch hier, dass das Plugfest ein „Zusammenkommen“ von I3C-Nutzern ist – Sinn des Meetings ist, so viele Geräte-Kombinationen wie möglich miteinander zu verpaaren, um die weitest-mögliche Interoperabilität innerhalb des Ökosystems sicherzustellen.
Zu guter letzt – dann wollen wir den I3C-Hattrick beenden – sei noch auf das unter der URL https://www.mipi.org/download-mipi-whitepaper-achieving-power-efficiency-in-iot-devices-with-mipi-i3c bereitstehende Whitepaper Achieving Power Efficiency in IoT Devices with MIPI I3C hingewiesen.

I3C-Angebotsliste von I3C-Implementierungen

Der I3C-Standard wird zwar von immer mehr Chips unterstützt – eine Liste von Sensoren gibt es indes noch nicht. Unter der URL https://binho.io/blogs/i3c-reference/i3c-devices findet sich eine von einem I3C-Nutzer gepflegte Liste, die sowohl Sensoren als auch Mikrocontroller auflistet.

Bildquelle: https://binho.io/blogs/i3c-reference/i3c-devices?

Apple: Unterstützung für private 5G- und LTE-Netzwerke.

Die vor einiger Zeit abgehaltene Apple-Entwicklerkonferenz beschäftigte vor allem die populärwissenschaftlichen Medien – wenn Apple eine „neue Produkt-Gattung“ anbietet, haben die Medien eine neue Sau, die sie durch das Dorf treiben können.
Im Hintergrund führte Apple allerdings auch eine Anpassung durch, die für den Betrieb privater LTE- und 5G-Netzwerke relevant ist.
Ab sofort ist es nämlich auch erlaubt, Apple-Geräte in diesem Bereich einzusetzen. Der „relevanteste“ Teil der unter https://support-apple-com.translate.goog/guide/deployment/support-for-private-5g-and-lte-networks-depac6747317/web?_x_tr_sl=en&_x_tr_tl=pt&_x_tr_hl=pt-BR&_x_tr_pto=sc im Volltext bereitstehenden Ankündigung ist in der Abbildung gezeigt.

Bildquelle: Apple.

Arm: Erweiterung der Unterstützung für Start Ups.

Wohl aufgrund der Verfügbarkeit der quelloffenen RISC/V-Architektur bietet Arm immer mehr hauseigenes IP für Startups kostenlos an. Dahinter steht der Gedanke, das Unternehmen zur Nutzung von Arm-Technologie zu animieren – nach dem „Design in“ ist ein Wechsel teuer, weshalb das Bezahlen der Lizenzgebühr als „ökonomisch vernünftigster“ Weg auf der Agenda der Neugründung stehen wird.
Erstens steht mit dem unter https://siliconcatalyst.com/arm-sic-contest-2023 im Detail beschriebenen Silicon Startup Contest ein „neuer“ Wettbewerb zur Verfügung – wer ihn gewinnt, wird (wie in der Abbildung gezeigt) finanziell beim Tape-Out der hauseigenen IC-Designs unterstützt.

Bildquelle: ARM.

Neuerung Nummero zwei sind „Erweiterungen“ des kostenlos zur Verfügung gestellten IP-Portfolios, das nun auch den Cortex A55-Prozessorkern enthält. Weitere Informationen hierzu finden sich unter den URLs https://www.arm.com/products/flexible-access/startup und https://www.arm.com/blogs/blueprint/silicon-startups.

Erste Daten zum Meadow F7-Funksystem.

Das Bryan Costanich auf seinem Entwicklerevent Unterstützung für Funkmodule angekündigt hat, ist bekannt. Unter der URL http://beta-developer.wildernesslabs.co/Meadow/Meadow.OS/Cellular/ findet sich nun eine „erste“ Beschreibung der zur Steuerung der Funkmodule vorgesehenen APIs.

Whitepaper mit Informationen zu Lautsprecher-Messungen.

Dass man mit den berühmt-berüchtigten „AudioFools“ viel Geld verdienen kann, dürfte bekannt sein. Wer Lautsprecher kommerziell einsetzt, tut gut daran, die verschiedenen in Datenblättern genannten Messwerte zu verstehen. Audio Precision – das Unternehmen bietet verschiedene Messgeräte für den Lautsprecherbereich an – stellt unter der URL https://go.ap.com/ewlsappnoteap?deliveryName=DM138530 ein 40-seitiges Dokument zur Verfügung, das „Quereinsteiger“ in die Grundlagen der Lautsprechermessung einführt.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More

Auch im Mai gab es im Bauteilmarkt Neuerungen – unter Anderem kommt der I3C-Standard langsam aber sicher in Fahrt, was sich in der Verfügbarkeit diverser Sensoren äußert. Hier ein kleiner Überblick der Neuerungen!

KingBright: Leuchtdioden höherer Hitzeresistenz

Wer – wie der Newsautor – vor vielen Jahren in die Welt der Elektronik eingestiegen ist, hatte beim Löten der (damals fragilen) Leuchtdioden immer ein etwas mulmiges Gefühl.
Der Optoelektronik-Spezialist KingBright schickt nun eine ganze Reihe von Leuchtdioden ins Rennen, die Temperaturen von bis zu 100 °C dauerhaft standhalten können. Die Bauteile gibt es dabei sowohl als Side View – als auch als Top View-Varianten; die Halbleiter-Chemie deckt die Farben rot, grün, blau, gelb und orange ab.

Die „normalen“ Serien laufen im Allgemeinen unter dem Namen APT, während die Side View-Varianten unter AA laufen. Zu beachten ist, dass die Dioden wesentlich teurer sind als gewöhnliche Kollegen. Die APT1608SYC kostet beispielsweise in Hunderterstückzahlen als OEMSecrets-Bestpreis rund 30 Eurocent, normale LEDs sind um den Faktor zehn billiger.

Bildquelle: Autor

Stromverbrauchs-Sensor mit I2C-Interface.

Mit dem INA234 schickt Texas Instruments einen Shunt-Ausleser ins Rennen, der im Zusammenspiel mit einem Shunt genaue Ermittlungen des Stromverbrauchs erlaubt und die Ergebnisse über ein I2C-Interface zur Aberntung zur Verfügung stellt. Abbildung zwei zeigt, wie das System „im Prinzip“ funktioniert.

Bildquelle: Texas Instruments.

NXP PP3T1x – I2C-Thermosensoren mit bis zu 0,4° Genauigkeit und Unterstützung für I3C.
Der I2C-Nachfolger I3C wird von immer mehr Chipherstellern umgesetzt. Mit der PP3T1x-Familie schlägt NXP nun eine Familie von Temperatursensoren ins Rennen, die Genauigkeiten von bis zu 0,4° erreichen.
Interessant ist an den vorliegenden Bauteilen vor allem, dass sie – siehe die beiden Abbildungen – sowohl im I2C- als auch im I3C-Format kommunizieren können.

Bildquelle: NXP.

Analog Devices ADR3630-Spannungsreferenz mit initialer Ungenauigkeit von ±0.04% und bis zu 70 mA Ausgangsstrom.

Das Liefern „vergleichsweiser hoher“ Ströme ist für Spannungsreferenzen im Allgemeinen Kryptonit. Mit dem ADR3630 schickt Analog Devices nun ein Bauteil ins Rennen, das die in der Abbildung gezeigten Genauigkeitswerte aufweist.

Bildquelle: Analog Devices.

Hervorragend ist am vorliegenden Bauteil, dass es – wie in der Prinzipschaltung gezeigt – zum Treiben höherer Ströme befähigt ist. Im Datenblatt finden sich ausserdem einige interessante Applikationen.

Bildquelle: Analog Devices.

Analog Devices MAX22196 – Feld-Sensor – zu SPI-Wandler mit GPIO-Komplement (!!!).

Dass „Feld-Sensoren“ gern mit der Übertragung von Strömen arbeiten, ist bekannt. Mit dem MAX22196 schickt Dallas Maxim nun ein Bauteil ins Rennen, das auf die „Auswertung“ von bis zu acht derartigen Sensoren spezialisiert ist; als Eingangs- bzw. Ausgangs-Strom sind Werte von 0,5-6,75 mA zulässig; die Aberntung der gelesenen Werte erfolgt über ein SPI-Interface.

Bildquelle: Analog Devices.

Wer das in der Abbildung gezeigte Schaubild sorgfältig betrachtet, findet unten rechts seltsames – neben der eigentlichen Eingangs-Funktion spendiert Dallas Maxim einen Ausgangsblock, über die der per SPI Informationen anliefernde Mikrocontroller Daten nach außen tragen kann. Je nach Parametrisierung ist es dabei sogar erlaubt, wie in der Abbildung gezeigt eine 9 × 9-LED-Matrix anzusteuern.

Bildquelle: Analog Devices.

Broadcom HD SM-20XX-SMD-Siebensegmentanzeigen

Obwohl Siebensegmentanzeigen in der Zeit preiswerter OLED-Displays an Wertigkeit verloren haben, gibt es nach wie vor viele Fälle, in denen ihre unbürokratische Ansteuerbarkeit Vorteile bringt – ein gutes Beispiel wären die in diversen Tektronix TDS-Scopes verbauten „Zustandsdisplays“.
Im Allgemeinen galt dabei allerdings, dass die Nutzung eine solche sieben Segment-Anzeige das Hinzufügen von Thruhole-Bauteilen zur BOM erforderlich macht.
Mit den HDSM-201x und HDSM-203x-Serien „bricht“ Broadcom mit dieser Tradition. Die 203xer haben dabei eine gemeinsame Kathode, während die 201xer eine gemeinsame Anode aufweisen.

Bildquelle: Broadcom.

Diodes Incorporated PSMUX136

Wer hochfrequente Signale zu schalten hat, greift nur allzu gern zu verschiedenen elektromechanischen Bauteilen. Mit der in Hunderterstückzahlen um rund 60 Eurocent erhältlichen PSMUX136 bietet Diodes Incorporated nun eine „Alternative“ an.

Bildquelle: Diodes Incorporated

Für den Port A verspricht man einen -3 dB-Punkt im Bereich von 5,5 GHz; der Port B hat eine Bandbreite von 5,3 GHz. Die Übergangswiderstände betragen 4.6 bzw. 5.7 Ohm, während der Propagations-Delay im Bereich von 0.1 ns liegt.

Bosch BMP 585-flüssigkeitsresistenter barometrischer Sensor.

Mit dem BMP585 schickt Bosch einem Druck-Sensor ins Rennen, der den Bereich von 300hPa  bis 1250hPa  abdeckt. Interessant ist am vorliegenden Bauteil zweierlei: Erstens ist es wasserfest, zweitens unterstützt es – siehe auch die Abbildung – Kommunikation per I2C, I3C und SPI.

Bildquelle: Bosch.

Stewart: Ethernet-Kabel im „selbstaufrollenden“ Zustand.

Der Preis für das „lustigste“ Bauteil geht in dieser Auslieferung sicher an Steward Connector – das Unternehmen gehört mittlerweile zur Bel-Gruppe. Mit der BM-CBRR-Familie stehen Internet-Kabel zur Verfügung, die – wie in der Abbildung gezeigt – gekräuselt sind.

Bildquelle: Mouser.

Ein 1 m langes Kabel kostet dabei ungefähr 120 Euro – Bel lässt sich den gesteigerten Komfort durchaus bezahlen.

OnSemi – selbstschützender Mosfet.

Dass diskrete Mosfets insbesondere in Stromrichtern verschiedensten Belastungen unterliegen, dürfte bekannt sein. Mit der NCV8415-Familie schickt On Semi nun eine Serie von Fets in seinen, die – wie in der Abbildung gezeigt – verschiedene „Absicherungen“ direkt auf dem Chip mitbringen.

Bildquelle: OnSemi.

PEM: SMD-„Schraubkopf“ zur Platinen-Befestigung.

Wer eine Platine befestigen möchte, setzt – normalerweise – auf ein Loch. Im Hause PEM kam man darauf, dass derartige Löcher – die Abbildung entstammt der Produkt Dokumentation – Platz entnehmen, der nicht für Leiterbahnen zur Verfügung steht.

Mit den in Hunderter-Stückzahlen um rund 80 Eurocent erhältlichen SMT-BSO steht nun ein Bauteil zur Verfügung, das dieses Problem – wie in der Abbildung gezeigt – einzuschränken sucht.

Zuerst erschienen bei Mikrocontroller.net News

Quelle: Read More