TI kauft SiLabs, Infineon kauft Teile von ams OSRAM, Preiserhöhungen uvam

OP (Firma: Tamoggemon Holding k.s.) #8004274
Lesenswert?

Sicherheitslücken in RISC/V-CPUs ermöglichen Angriffe auf SoCs. Im Hause Raspberry Pi steht eine Preiserhöhung an, während erste Benchmarks der neuen Loongson-CPU eine Einschätzung der Leistungsfähigkeit der chinesischen Halbleiterindustrie ermöglichen.

Symbian-Urgestein Colly Myers verstorben

Wer sich in der goldenen Vergangenheit der Hand-Computertechnik mit Symbian auseinandergesetzt hat, kennt Colly Myers als Entwickler des Ur-EPOC oder als Symbian-CEO. Unter der URL https://www.linkedin.com/feed/update/urn:li:activity:7423809082802946048/ findet sich nun die traurige Meldung, dass er überraschend verstorben ist:

1
I was deeply saddened to learn this weekend of the sudden passing of Colly.
2

3
After an unexpected fall, Colly was placed into an induced coma and later passed away. His death will be a shock to many of us who knew and worked with him.
4
. . .

Newsautor und Exfrau verneigen sich in tiefer Dankbarkeit und tiefem Respekt die langjährige gute Zusammenarbeit im Bereich Symbian.

TI kauft Silicon Labs

Silicon Labs hat in der Vergangenheit in Sachen Bluetooth den einen oder anderen Achtungserfolg vollbracht: man war zum Beispiel als Erster in Sachen Channel Sounding lieferfähig (siehe https://www.youtube.com/watch?v=wpfyrcnIgqc).

Texas Instruments vermeldet unter https://investor.ti.com/news-releases/news-release-details/texas-instruments-acquire-silicon-labs nun, das Unternehmen übernehmen zu wollen:

1
(Nasdaq: TXN), a global semiconductor company that designs, manufactures and sells analog and embedded processing chips, and (Nasdaq: SLAB), a leader in secure, intelligent wireless technology, today announced they have signed a definitive agreement under which will acquire for per share in an all-cash transaction, representing a total enterprise value of approximately .

Zu den Kaufmodalitäten findet sich folgendes:

1
Under the terms of the agreement, which has been unanimously approved by the Board of Directors of both companies, stockholders will receive in cash for each share of common stock they hold at the time of closing. expects to fund the transaction with a combination of cash on hand and debt financing to be arranged prior to closing. The transaction is not subject to any financing contingency.
2
The transaction is expected to close in the first half of 2027, subject to receipt of regulatory approvals and other customary closing conditions, including approval by stockholders.
3
The transaction is expected to be accretive to earnings per share, excluding transaction-related costs, in the first full year post-close. remains committed to its capital return strategy to return 100% of free cash flow to shareholders over time via dividends and share repurchases.

Infineon kauft Teile von ams OSRAM

Wo Rauch ist, ist in vielen Fällen auch Feuer. Die seit einiger Zeit durch die Gerüchteküche wabende Geschichte über einen Teil-Verkauf des österreichischen Parade-Halbleiterherstellers ams OSRAM wurde unter der URL https://www.infineon.com/press-release/2026/infxx202602-0431 nun bestätigt. Spezifischerweise kauft Infineon die Sensor-Sparte unter Auslassung der optischen Sensoren:

1
Infineon Technologies AG (FSE: IFX / OTCQX: IFNNY) is expanding its sensor business with the acquisition of the non-optical analog/mixed-signal sensor portfolio from ams OSRAM Group (SIX: AMS). The two companies have entered into an agreement for a purchase price of 570 million on a debt-free and cash-free basis.

Infineon vermeldet zum „Umfang“ der Transaktion folgendes:

1
The overall transaction is structured as a fabless asset deal covering sensor products, R&D capabilities, intellectual property and test & lab equipment. The transaction is subject to customary closing conditions, including regulatory approvals, and is expected to close in the second quarter of calendar year 2026. Infineon will fund the acquisition with additional debt, as part of its general corporate financing plans.  

STMicroelectronics finalisiert die Übernahme der NXP-Sensorsparte.

Die Elektronikindustrie dürfte dem „Million Monkey Effekt“ unterliegen. STMicroelectronics schickte wenige Stunden vor der Infineon-Ankündigung die folgende Meldung, die die an sich im Vorjahr geplante Übernahme der NXP-MEMS-Sensorsparte als final deklariert:

1
STMicroelectronics (NYSE: STM), a global semiconductor
2
leader serving customers across the spectrum of electronics applications, today
3
completed the acquisition of NXP Semiconductors (NASDAQ: NXPI) MEMS sensors
4
business. Announced in July 2025 and now fully approved by regulators, this
5
transaction, focused on automotive safety and non-safety products and sensors for
6
industrial applications, expands STs global sensors capabilities.
7
Based on our initial assessment, we expect the acquired business to contribute in the
8
mid-forties million dollars range to STs revenues in the first quarter of 2026.

Uptonitisches, zur Ersten - Preiserhöhung.

Der AI-Boom bzw. die AI-Blase sorgen für permanent steigende Preise für Arbeitsspeicher. Im Hause Raspberry Pi muss man nun eine abermalige Preiserhöhung durchführen. Spezifischerweise erhöhen sich die Preise der Produkte wie in der Abbildung gezeigt.

Bildquelle: https://www.raspberrypi.com/news/more-memory-driven-price-rises/

Im Rahmen der Ankündigung vermelden die Uptoniten ihre Intention, diese Preisanpassung wieder zurückzunehmen, sobald sich die Marktpreise für DDR4-RAM wieder reduzieren. Interessant ist außerdem die folgende Passage, die auf erhebliche Vorräte der für die älteren Varianten verwendeten Arbeitsspeicher hinweist:

1
We dont anticipate any changes to the price of Raspberry Pi Zero, Raspberry Pi 3, and other older products, as we currently hold several years inventory of the LPDDR2 memory that they use.

Uptonitisches, zur Zweiten - Haut den RP2350 verlängert.

Die durchaus informativen Experimente zur Schwachstellen-Suche im RP2350 haben bisher nicht zu Ergebnissen geführt. Nun gibt es eine Erleichterung, die die Fehlersuche zu vereinfachen sucht:

1
Our AES implementation was designed to withstand side-channel attacks by using multi-way secret sharing (where sensitive values are split into random components that must be XORed together) and by randomly permuting the order of operations and data. We hope that even just the multi-way shares are enough to protect us against side-channel attacks; hence, we have decided to update our challenge:
2
If you manage to demonstrate a successful attack on our AES implementation without the randomisation, you win!
3
--- via https://www.raspberrypi.com/news/rp2350-hacking-challenge-2-less-randomisation-more-correlation/

Die sonstigen Modalitäten im Bezug auf das Preisgeld bleiben identisch - neu ist, dass am Hacking interessierte Personen nun mehr Zeit zur Finalisierung ihrer Experimente bekommen:

1
To give you a little more time to keep hacking, were extending the deadline to 30 April 2026. The prize remains unchanged at $20,000.

RISC/V: Sicherheit der meisten Implementierungen eher mangelhaft.

Die vor wenigen Jahren erschienenen Heartbleed-Attacken zeigten, dass auch die „ISAs von Prozessoren“ in der heutigen Zeit Fair Game für Computersicherheitsforschung sind. Auf der FOSDEM wurde ein Vortrag gehalten, in dem kommerziell verfügbare RISC/V-Implementierungen untersucht wurden. Die Ergebnisse präsentierten sich nicht sonderlich gut.

Bildquelle, beide: https://fosdem.org/2026/schedule/event/DL89YW-how-secure-are-commercial-risc-v-cpus/

Zusammenfassend wird außerdem noch folgendes vermeldet:

1
But manual analysis does not scale. RISCover, our open-source differential fuzzing framework, automatically discovers architectural vulnerabilities across closed-source RISC-V CPUs. By comparing instruction behavior across 8 commercial CPUs from 3 vendors, RISCover found what manual analysis missed: GhostWrite, a bug in T-Head's XuanTie C910 that lets unprivileged code write directly to physical memory, completely bypassing virtual memory isolation. We also discovered multiple "halt-and-catch-fire" sequences that crash CPUs from userspace, leading to denial-of-service. 
2
 via https://www.phoronix.com/news/RISC-V-Security-CPU-Not-So-Good

Loongson 3B6000 Benchmarks von Phoronix

Die chinesische Loongson-Architektur bekommt immer wieder Erwähnungen: Wer nicht chinesisch spricht und nicht in China lebt, kann die Hardware nur auf X betrachten. Der für seine Linux-Benchmarks bekannte Branchen-Newsdienst Phoronix wurde nun mit einem Evaluationsboard der aktuellsten CPU ausgestattet, und führte Experimente durch. Die „zusammenfassenden Ergebnisse“ präsentieren sich wie in der Abbildung gezeigt - unter der Bildquelle finden sich sieben Seiten mit detaillierteren Performance-Berichten.

Bildquelle: https://www.phoronix.com/review/loongson-3b6000-loongarch

STMicroelectronics „pusht“ Visual Studio Code.

Wer bisher auf die ehemals von Atollic entwickelte Cube-IDE setzt, sollte das in der Abbildung gezeigte Bild sorgfältig betrachten. STMicroelectronics veröffentlichte auf seiner offiziellen Entwickler-News einen von ARM geschriebenen Bericht, der die Inbetriebnahme des Visual Studio Code-Plugins von Keil im Zusammenspiel mit STM32-MCUs beschreibt.

Bildquelle: https://community.st.com/t5/developer-news/using-stm32-devices-with-keil-studio-for-visual-studio-code/ba-p/873652

M5Stack AI-8850 - alternativer AI-Beschleuniger für Raspberry Pi 5.

Das offizielle AI-Erweiterungsmodul aus dem Hause Upton ist nicht das einzige Produkt, das den uptonitischen Prozessrechnern zu mehr AI-Leistung zu verhelfen sucht. Im Hause M5Stack lanciert man - wie in der Abbildung gezeigt - ein ähnliches Produkt, das allerdings auf einen Beschleuniger aus dem Hause Axera setzt.

Bildquelle: https://s.click.aliexpress.com/e/_c4L4gwjv

Zu beachten ist, dass dieses vergleichsweise teure Modul seine Rechenleistung aus einer gewöhnlichen M2-Erweiterungskarte bezieht. Insbesondere bei größeren Deployments kann es billiger sein, die wesentlich preiswertere M2-Karte einfach so zu kaufen und eine hauseigene Raspberry Pi-Adapterumgebung zu entwerfen.

GimmeGPIO - ESP32-basiertes USB-zu-GPIO-Modul.

Die 40 Pin lange GPIO-Steckerleiste des Raspberry Pi hat sich als absoluter Klassiker etabliert. Auf element14 gibt es nun ein Open Source-Projekt, das einen USB-Stick mit eben dieser GPIO-Schnittstelle zu realisieren sucht.

Bildquelle: https://community.element14.com/challenges-projects/element14-presents/project-videos/w/documents/72021/gimmegpio-a-simple-way-to-get-gpio-on-laptops-and-desktops----episode-699?C

Auf Seiten der Host-Workstation stellt die Karte ein serielles Interface zur Verfügung, über das - Ähnlichkeiten zu Firmata sind rein zufällig - Befehle in Richtung des ESP32 geschickt werden. Dieser wendet diese danach gegen die „reale Peripherie“ an.

Embedded World: Kostenlose Tickets und Freibier.

Auch auf der diesjährigen Embedded World verteilt die Bauteilpreissuchmaschine OEMSecrets kostenloses Bier. Wer noch kein Ticket für die Messe hat, kann unter der Bildquelle eines beantragen.

Bildquelle: https://www.messe-ticket.de/Nuernberg_SHOP/embeddedworld2026/Register/ew26OESE?utm_source=barter&utm_medium=cpc&utm_campaign=2026.en.visitors.GG.oem

Der Newsautor wird - mit 99 %iger Wahrscheinlichkeit - alle Messetage vor Ort sein, und freut sich schon darauf, mit der vereinigten Leserschaft das eine oder andere Glas zu heben.

CartoType: Besseres Mehrroutensystem.

Dass die in Großbritannien ansässige CartoType ein Big Tech-unabhängiges Routen- und Kartenframework zur Verfügung stellt, kann man im Interesse der digitalen Souveränität nicht oft genug betonen. In einem vor wenigen Stunden an die Entwicklerschaft verschickten Bericht findet sich unter anderem die abgedruckte Grafik, die über „Fortschritte“ im Bereich der Multi-Routen-Berechnung informiert.

Bildquelle: CartoType.

Spezifischerweise gilt, dass CartoType nun bequemer zu handhaben ist, wenn es um das Anbieten mehrerer konkurrierender Routen geht. Ein Beispiel hierfür ist die Berechnung von sehr schnellen und alternativ dazu sehr kurzen Routen:

1
Theres a new Framework function on all platforms named DisplayRouteChoices (displayRouteChoices in some APIs). It takes an array of immutable Route objects and draws them on the map, labelling them using the route profile names and the distances and times. In the example above, the profiles are called Shortest and Fastest.

Lesestoff: Tamper Protection in Arcade-Systemen.

Die erste Runde im Kampf zwischen Hardware-Hacker und Hardware-Hersteller fand im Bereich der Spielhallencomputersysteme statt. Unter der URL https://arcadehacker.blogspot.com/ findet sich ein zwar nicht mehr aktiv gepflegter, aber lesenswerter Blog, der auf die „Highlights“ der im Rahmen der Gefechte entwickelten Technologien eingeht. Sehr interessant empfand der News-Autor beispielsweise das in der Abbildung gezeigte Sicherheitsmodul von Sega bzw. Hitachi. Die glänzenden Quader sind Keramikblöcke, die auf der Platine platziert wurden, um das Abtasten der darunter befindlichen Datenleitungen des Arbeitsspeichers zu erschweren und beim Aufflexen des Moduls für zusätzliche Freude zu sorgen.

Bildquelle: https://arcadehacker.blogspot.com/2020/04/deconstructing-segas-system-16-security-part2.html

Lesestoff: Vom Antennentest mit VNAs.

Antennen-Matching unter Nutzung eines Vektor-Netzwerk-Analysators gilt als gefürchtete Aktivität. Unter der URL https://coppermountaintech.com/wi-fi-bluetooth-pcb-tuning-and-antenna-testing/?utm findet sich ein Grundlagen-Artikel, der interessantesten Aspekte kompakt hervorhebt.

In eigener Sache: Bauteil-Roundup folgt morgen.

Aus Gründen der dringenden Nachrichtenlage wurde die Veröffentlichung der (sehr umfangreich ausgefallenen) Liste der neuen Bauteile verschoben - der Text wird nach vorausgehende Planung morgen erscheinen.

-edit 23h30 tvh bilder ausgetauscht, ein RR repariert. thx

Angehängte Dateien:
: Bearbeitet durch NewsPoster

Kommentare

OP (Firma: Tamoggemon Holding k.s.) #8004495
Lesenswert?

Alex J. schrieb:

Richard W. schrieb:

TI neigt zu völlig overengineerten Software-SDKs. Bei Silabs war alles immer ein wenig einfacher gehalten und man hatte mehr Freiheiten. Schade darum.

Du hast schon eine Weile nicht mehr mit Silabs zu tun gehabt, oder? ;) #simplyshittySDK

Man darf gespannt sein, wie sie die Transceiver-Sparten langfristig zusammenbringen.

Hallo, sorry dass ich da nerve - aber mich hat das SDK sehr beeindruckt, insbesondere die automatische Erkennung der Ziele etc.

OK, es gibt ein paar Anfängerfallen, aber sonst...siehe Video auch oben...

#8004552
Lesenswert?

Alex J. schrieb:

Richard W. schrieb:

TI neigt zu völlig overengineerten Software-SDKs. Bei Silabs war alles immer ein wenig einfacher gehalten und man hatte mehr Freiheiten. Schade darum.

Du hast schon eine Weile nicht mehr mit Silabs zu tun gehabt, oder? ;) #simplyshittySDK

Ich fand, das hat sich bei Silabs in Grenzen gehalten. Deren hauseigene Entwicklungsumgebung benötigte ich nur um die SDK-Pakete herunterzuladen. Auch die Entwicklungstools und -boards waren eher schlicht gehalten. Dank J-Link-kompatiblem Debugger kann man auf nahezu jeder Host-Plattform debuggen. Dazu gab's ein schlankes Kommandozeilentool zum ansteuern der Eval-Boards und für die Energiemessung.

Was TI dagegen veranstaltet, ist in meinen Augen blanker Horror. Die haben anscheinend viel zu viele Leute die Unmengen an Arbeit in proprietäre Lösungen und aufwendige GUIs versenken mit denen dann die Entwickler gequält werden. CCS, XDC, XDS, SysConfig (was für ein Moloch), eigene proprietäre Toolchains, das ignorieren oder abwehren sämtlicher Open Source Tools bis es nicht mehr anders geht... dafür steht TI. Das hat sich in den letzten Jahren gebessert, aber das Mindset hat sich in der Firma kaum verändert. Klar versucht jeder Hersteller die Entwickler zu ihren hauseigenen IDE- und Toolinglösungen zu "motivieren". Aber bei Silabs genau so wie ST is es wenigstens mit überschaubarem Aufwand möglich, dem zu entfleuchen. Bei TI ist das nur sehr schwer.

#8004813
Lesenswert?

Die vor wenigen Jahren erschienenen Heartbleed-Attacken zeigten, dass auch die „ISAs von Prozessoren“ in der heutigen Zeit Fair Game für Computersicherheitsforschung sind.

Was hat Heartbleed denn mit Schwachstellen in der ISA zu tun? Heartbleed war doch ein reiner Software-Bug.

: Bearbeitet durch User
#8004828
Lesenswert?

Zu den Raspberry-Pi-Preiserhöhungen:

Der Raspberry Pi 4 B wird jetzt mit einem neuen Platinenlayout und zwei statt einem Speicherchip gefertigt.

Das bedeutet, daß z.B. für das 4-GiB-Modell günstigere 2-GiB-Chips eingesetzt werden können.

Ob sich das auf die Verkaufspreise auswirken wird?

https://www.heise.de/news/Raspberry-Pi-4-kommt-jetzt-mit-zwei-Speicherchips-11166924.html

#8004855
Lesenswert?

Tam H. schrieb:

Sehr interessant empfand der News-Autor beispielsweise das in der Abbildung gezeigte Sicherheitsmodul von Sega bzw. Hitachi. Die glänzenden Quader sind Keramikblöcke, die auf der Platine platziert wurden, um das Abtasten der darunter befindlichen Datenleitungen des Arbeitsspeichers zu erschweren und beim Aufflexen des Moduls für zusätzliche Freude zu sorgen.

Man sollte dazu auch die aktuellen Zeiten der damaligen Technik (oder die Ausbildung der Leute damals) im Hinterkopf haben. Bei Mame gab es früher viele Hinweise zu technischen Zusammenhängen, beispielsweise warum bei den Sounds der Spiele-Roms wie Space Invader Samples eingesetzt wurden. Es gibt auch verschiedenen Internetseiten (mal mehr, mal weniger spannend) zur Soundangelegenheit von Space Invaders. Aktuell müsste das Space-Invader-Rom allerdings mit dem Sample-File zusammen gepackt sein.

Bei Breath of Fire 1 kann man hinsichtlich der Spielgestaltung noch erkennen, wieviel Spaß und Liebe wie auch der Respekt vor der Technik im Vordergrund stehen. Aktuell steht da eher Geld im Vordergrund - so als könnte man sich mit Geld alles kaufen. Auch die Künstler konnten damals noch eine phantastische Ausbildung genossen haben.

(RISC-V for Gaming: Emulating X86 on RISC-V - Paris Oplopoios, felix86 https://www.youtube.com/watch?v=S_NkVBgOcoQ)

(Firma: AW-Elektronik) #8004945
Lesenswert?

Ich nutze mal die Gunst der Stunde und zeige zum Thema GimmeGPIO ein ESP32 auf RPi Zero Basis, das ich mal in meiner Firma entwickelt hatte.

Wenn Interesse besteht, wäre ein Nachfolger mit ESP32-S3 möglich!

Angehängte Dateien:
: Bearbeitet durch User
#8004976
Lesenswert?

Wenn du ein paar Millionen MCUs kaufst, ist der Support bei TI erstklassig. Dann entwickeln die dir sogar dein halbes Produkt.

Das kann ich so bestaetigen, allerdings gibt es schon auch ein Interesse gerne dein Produkt zu entwickeln um deine Expertise in ihr Unternehmen zu bekommen. .-)

Vanye

Gast #8005043
Lesenswert?

STMicroelectronics „pusht“ Visual Studio Code.

Wer bisher auf die ehemals von Atollic entwickelte Cube-IDE setzt, sollte das in der Abbildung gezeigte Bild sorgfältig betrachten.

Hallo,

was genau soll das jetzt heißen?Eigentlich doch nur, dass nun auch Keil auf Visual Studio Code setzt und wenn man will auch STM32 damit programmieren kann. ST bietet ja auch eine eigene Visual Studio Code Integration. Wenn, dann würde ich doch eher diese präferieren. Ich habe auch noch keine News gesehen, dass CubeIDE von ST abgekündigt wurde.

Außerdem: Achtung. Jetzt kommt meine persönliche Meinung. Wenn man sich ausschließlich im ST Univerum bewegt, ist die CubeIDE perfekt. Und so schlecht wie sie immer beschrieben wird, ist sie jetzt auch nicht. Bei Visual Studio Code komme ich mir immer wie in meine IT Anfangszeit zurück versetzt, als es unter DOS 3.x noch den Edlin gab. Und Edlin war grauenhaft.

So, nun möge der "Sh..-Storm" über mich hereinbrechen :-)

Gruß Kai

Persönliche Seite #8005051
Lesenswert?

Kai schrieb:

Ich habe auch noch keine News gesehen, dass CubeIDE von ST abgekündigt wurde.

Allerdings könnte man das am Horizont vielleicht schon erahnen...

Kai schrieb:

Und so schlecht wie sie immer beschrieben wird, ist sie jetzt auch nicht. Bei Visual Studio Code komme ich mir immer wie in meine IT Anfangszeit zurück versetzt

Cool, ich bin nicht der Einzige... 😉 VS Code hat aber schon ein paar Vorteile.

Insbesondere ist die CMake-Integration sehr gut, dadurch kann man sich sehr flexibel ein Build-System aufbauen und dennoch komfortabel über die UI verwenden. Das ist praktisch gerade auch für komplexe Projekte die aus vielen einzelnen Komponenten bestehen. Und weil's CMake ist kann man es dann auch wunderbar per Kommandozeile kompilieren (z.B. in CI), das geht bei Eclipse nicht so toll.

Allgemein wird an VS Code intensiv gearbeitet, es gibt viele aktuelle Extensions usw. Das ist bei Eclipse etwas eingeschlafen.

#8005063
Lesenswert?

Niklas G. schrieb:

Allgemein wird an VS Code intensiv gearbeitet, es gibt viele aktuelle Extensions usw. Das ist bei Eclipse etwas eingeschlafen.

Die Vorstellung, alles über eine GUI konfigurieren zu müssen und in eigene proprietäre Konfigurationsdateien zu packen, hat sich als Sackgasse erwiesen, das war vor über einer Dekade, spätestens mit dem Aufkommen von CI/CD schon absehbar. Software entsteht schon lange nicht mehr ausschlißelich auf dem Desktop eines einzelnen Entwicklers, sondern auf diversen mit unterschliedlichen OS und vor allem auch in Pipelines. VSCode macht das mit seinen json Config-Dateien und der Trennung von common project config und user project config richtig. CMake hat mit dem Aufkommen von Presets auch die Kurve gekriegt. Und die Sillicon-Vendor kapieren einer nach dem anderen dass es sich nicht lohnt, Unmengen an Geld in eine eigene IDE zu versenken. Oft wollen ja nicht mal die In-House Entwickler damit arbeiten.

Aber hat VSCode denn mittlerweile ein korrekt funtionierendes und mit dem Buildsystem verzahntes und clangd-gestütztes Code-Modell so dass man schnell und unfallfrei durch seine C++-Codebasis navigieren kann oder hört es immer noch bei Syntax Highlighting und "Sprungziele werden erraten" auf?

Persönliche Seite #8005074
Lesenswert?

Richard W. schrieb:

Die Vorstellung, alles über eine GUI konfigurieren zu müssen und in eigene proprietäre Konfigurationsdateien zu packen, hat sich als Sackgasse erwiesen

Ja, wobei es auch unklar ist, warum man nicht zumindest eine simple CMake-Konfiguration über eine GUI zusammenbauen und bearbeiten kann... in QtCreator geht das IIRC ansatzweise.

Richard W. schrieb:

Aber hat VSCode denn mittlerweile ein korrekt funtionierendes und mit dem Buildsystem verzahntes und clangd-gestütztes Code-Modell so dass man schnell und unfallfrei durch seine C++-Codebasis navigieren kann

VS Code hat das auf Basis von MS-eigenem IntelliSense. Das STM32 Plugin bringt aus irgendwelchen Gründen aber eine eigene clangd-basierte Navigation mit, die aber nur so mittelprächtig funktioniert. Bei Multi-Root-Workspaces funktioniert diese eigene clangd-Code-Navigation gar nicht, da kann man besser wieder IntelliSense verwenden, was aber nicht so leicht zu bewirken ist. IntelliSense funktioniert einigermaßen, ist aber langsam.

Der clang-format Code-Formatter hingegen ist davon unberührt und funktioniert normal wie im Standard VS-Code. Man legt eine ".clang-format"-Datei ins Projekt und schon wird alles wie gewünscht formatiert.

: Bearbeitet durch User
#8005083
Lesenswert?

Niklas G. schrieb:

Ja, wobei es auch unklar ist, warum man nicht zumindest eine simple CMake-Konfiguration über eine GUI zusammenbauen und bearbeiten kann...

Weil es immer sofort kaputt geht wenn man über „simple CMake-Konfiguration“ hinaus gehen möchte und einem dann befindet weiteren Arbeit im Weg steht.

in QtCreator geht das IIRC ansatzweise.

Ansatzweise und es ist grauenhaft. Das sollte sie aufgeben und über vscode-kompatible Config Files nachdenken. Die GUI-zentrierte Klick-Orgie ist dort ungemein lästig wenn man auf vielen Plattformen unterwegs ist und nach 2 Jahren ein altes Kundenprojekt wieder herausholen will und dann nichts mehr geht weil man in der Zwischenzeit einiges umkonfiguriert hat. Aber diese Entscheidung ist aber politisch.

Aber QtCreator ist nach wie vor die IDE mit dem besten C++-Codemodell. Die clangd-Integration ist sehr gut. Clangd ist aber einfach langsam.

Persönliche Seite #8005084
Lesenswert?

Richard W. schrieb:

Weil es immer sofort kaputt geht wenn man über „simple CMake-Konfiguration“ hinaus gehen möchte und einem dann befindet weiteren Arbeit im Weg steht.

Ab da könnte man es ja komplett manuell machen. Aber bis zu diesem Punkt wäre eine grafische Hilfestellung gar nicht so verkehrt...

Richard W. schrieb:

Das sollte sie aufgeben und über vscode-kompatible Config Files nachdenken

Die Config Files sind ja gar nicht der Punkt, sondern die CMakeLists ... Makefiles werden ja von vielen IDEs automatisch generiert, wenn man CMakeLists.txt zumindest für einfache Projekte ebenfalls generieren und aktuell halten (neue Dateien einfügen etc) könnte wär das ein Gewinn.

Gast #8005092
Lesenswert?

Harap

Entweder hast Du vscode nicht verstanden, oder Du hast ... sehr interessante Vorstellungen davon, was eine IDE so alles können soll.

Im Dezember habe ich versucht nach Anleitung das ST Plugin zu installieren. Das hat auch alles funktioniert, aber leider lief das Plugin nicht.

Ich erwarte von einer IDE, dass ich sie installiere und sie läuft. Nicht mehr und nicht weniger.

Ich bin mit IDEs groß geworden und mag sie und VSCode ist für mich keine IDE. Für mich ist es ein Editor.

#8005097
Lesenswert?

Niklas G. schrieb:

Die Config Files sind ja gar nicht der Punkt, sondern die CMakeLists ... Makefiles werden ja von vielen IDEs automatisch generiert, wenn man CMakeLists.txt zumindest für einfache Projekte ebenfalls generieren und aktuell halten (neue Dateien einfügen etc) könnte wär das ein Gewinn.

Dann reden wir von verschiedenen Dingen. Mir reicht es wenn man in der IDE auf Pfade in CMake Dateien drauf klicken kann und dann richtig landet bzw. es überhaupt eine Projektansicht gibt. Die wenigsten Leute führen aber Headerdateien bzw. andere evtl. relevante Dateien als Sourcen in CMake auf und da geht das schon wieder kaputt und man muss auf die nackte Dateisystemansicht des Projekts zurückgreifen. Und wie CMake-Dateien in mittelgroßen Projekten aussehen an denen einige Entwickler mit unterschiedlichen Vorstellungen beteiligt sind…naja.

Persönliche Seite #8005141
Lesenswert?

Kai schrieb:

Ich erwarte von einer IDE, dass ich sie installiere und sie läuft. Nicht mehr und nicht weniger.

Es ist halt noch Beta / Prerelease. Die Einrichtung ist noch etwas holprig, funktioniert aber grundsätzlich. Ich denke mal dass das noch korrigiert wird.

Richard W. schrieb:

Mir reicht es wenn man in der IDE auf Pfade in CMake Dateien drauf klicken kann und dann richtig landet bzw. es überhaupt eine Projektansicht gibt.

Ja mir auch, aber für Einsteiger oder Quick-and-Dirty Projekte wär's schon praktisch wenn es so geht wie in Eclipse - Projekt anlegen, neue Datei hinzufügen, kompilieren drücken, fertig. Aber egal, müßig damit zu hadern

#8005282
Lesenswert?

Richard W. schrieb:

Aber hat VSCode denn mittlerweile ein korrekt funtionierendes und mit dem Buildsystem verzahntes und clangd-gestütztes Code-Modell so dass man schnell und unfallfrei durch seine C++-Codebasis navigieren kann oder hört es immer noch bei Syntax Highlighting und "Sprungziele werden erraten" auf?

Ist Dir https://github.com/clangd/vscode-clangd bekannt?

Das ist die clangd-Extension für vscode.

#8005298
Lesenswert?

Ich finde da eher sowas unterhaltsam: https://developer.arm.com/documentation/ka002766/latest/

So etwas witziges und gut gemachtes wie den Watcom-Vi wird es wohl so schnell nicht wieder geben. Schade eigentlich. Die Community hatte sich zum Schluss eigentlich mehr auf den Compiler fixiert beispielsweise auch auf 64Bit - ist natürlich auch wichtig aber - Naja, schöne Pionierzeiten damals, heute eher MS-Überallzeiten ;)

#8005677
Lesenswert?

Richard W. schrieb:

Wenn du ein paar Millionen MCUs kaufst, ist der Support bei TI erstklassig. Dann entwickeln die dir sogar dein halbes Produkt.

Wenn du ein paar Millionen MCUs kauft dann spricht jeder Hersteller. Wenn TI sämtliche noch nicht großen auf dem weg dahin vergrault kommen die auch bei höheren Stückzahlen nicht mehr inbetracht. Wenn ein Hersteller Produktfehler und Dokumentation völlig egal sind schießen die sich eh komplett raus. Sowas lässt sich nicht einfach mit wir bieten dir mal besseren Support beheben.

Auch zweifelhaft wo die Mitarbeiter die MSP430 (MCUs) kennen herkommen sollen, wenn TI nur an den größten Firmen interessiert ist und Nachwuchs sowie KMU vergrault wird. Unis sind soweit ich weiß auch nicht mehr mit MSP430 unterwegs. Da ist ein STM32, ESP oder Nordic auf einmal deutlich interessanter wenn es um neue Designs geht, da es für die tausende von Leuten gibt die die Platform beherschen und verstehen.

Persönliche Seite #8005744
Lesenswert?

N. B. schrieb:

Auch zweifelhaft wo die Mitarbeiter die MSP430 (MCUs) kennen herkommen sollen, wenn TI nur an den größten Firmen interessiert ist

Wie bei allen solchen "Geheimtechnologien": Diese Mitarbeiter fangen mit 17 als Trainee bei den Firmen an die diese Dinge auch "schon immer" verwenden, und lernen es eben dort. Bei älteren Bewerbern wird vorausgesetzt dass sie das schon können - wenn das nicht der Fall ist, hat man Pech gehabt. Dann noch über Fachkräftemangel lamentieren.

(Firma: AW-Elektronik) #8005798
Lesenswert?

Richard W. schrieb:

Alexander W. schrieb:

Ich nutze mal die Gunst der Stunde und zeige zum Thema GimmeGPIO ein ESP32 auf RPi Zero Basis, das ich mal in meiner Firma entwickelt hatte.

Wenn Interesse besteht, wäre ein Nachfolger mit ESP32-S3 möglich!

Was meinst du mit “ein ESP32 auf RPi Zero Basis”?

Der Formfaktor ist ein Raspberry Pi Zero W und dort ist ein ESP32 verbaut. Die Stiftleisten sind also RPi-kompatibel.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren