gibt es uC, die man heute und in 10 Jahren auch noch kaufen kann? RISC-V gibt es praktisch noch nicht und alles mit ARM drin vielleicht bald nicht mehr.
Für PowerPC versprechen NXP und STM Lieferbarkeit bis ca. 2035 und die haben einen UART-Bootloader, aber sie brauchen 10 mal soviel Strom wie aktuelle Chips.
Die PIC32M könnten es auch schaffen, aber gibt es dafür einen gcc? Von den nötigen Programmiergeräten garnicht zu reden.
Ich bin jetzt total verwöhnt von den STM32 mit 128K RAM und CAN und viel UART, SPI und so. Und mit vielen nutzbaren Pins; die SPC5xx und PIC32M müssten wahrscheinlich 100 Pins haben, wo ich beim STM32 mit 64 auskomme.
gibt es uC, die man heute und in 10 Jahren auch noch kaufen kann? RISC-V
gibt es praktisch noch nicht und alles mit ARM drin vielleicht bald
nicht mehr.
Für PowerPC versprechen NXP und STM Lieferbarkeit bis ca. 2035 und die
haben einen UART-Bootloader, aber sie brauchen 10 mal soviel Strom wie
aktuelle Chips.
Die PIC32M könnten es auch schaffen, aber gibt es dafür einen gcc?
man braucht nicht gcc um C zu programmieren. Und mit C programmiert, ist dr Code ohnehin Zukunfts- und Prozessorwechsel-sicher.
Ich bin jetzt total verwöhnt von den STM32 mit 128K RAM und CAN und viel
UART, SPI und so
Auch der STM32 ist ein ARM, das macht dich ohnehin zum ARM-Leuchter. SCNR
Bei STM habe ich auch schon was von 10 Jahren Verfügbarkeit gelesen. Und die STM32 haben viele Pinkompatible Geschwister, das sieht bei anderen Herstellern oft deutlich schlechter aus.
Von RISC-V wird schon lange geredet, aber von einer Markteroberung sind die weit entfernt. Die Cortex-M gibt es in so vielen Varianten und haben den ausgeklügelten Coresight Kern fürs Debuggen mit riesiger Unterstützung. Denn auch das gehört zum Controller, die HW und SW Tools. Sowas wie RISC-V macht doch nur Sinn wenn es um low cost Produkte mit größten Stückzahlen geht.
Von daher gehe ich davon aus das es die Cortex-M länger als mich geben wird.
Bei STM habe ich auch schon was von 10 Jahren Verfügbarkeit gelesen.
Ja, aber wohl nicht mit dem Zusatz "dauerhaft"...
Hast du die letzten drei Jahre komplett verpennt? Die waren eben gerade davon gezeichnet, dass viele weit verbreitete STM32 eben NICHT (oder nur zu horrenden Preisen über Broker) lieferbar waren. Und die Sache ist immer noch nicht ausgestanden, obwohl inzwischen zumindest eine leichte Entspannung erkennbar ist.
So viel zu den Versprechen von STM und deren sachlich korrekter Interpretation...
Die schlechte Verfuegbarkeit war aber keine spezielle Eigenschaft der STM32 sondern bei allen CPUs, auch AVR8. Du konnest STM32 ja noch bestellen, aber das Lieferdatum hat halt deutlich in der Zukunft gelegen...
Die schlechte Verfuegbarkeit war aber keine spezielle Eigenschaft der
STM32 sondern bei allen CPUs, auch AVR8.
Jupp. Bei den AVR8 war es zum Glück allerdings weitestgehend auf einige wenige Typen beschränkt. Überwiegend halt das typische Arduino-Gedöhns. M328P und M2560.
Die PIC32M könnten es auch schaffen, aber gibt es dafür einen gcc?
man braucht nicht gcc um C zu programmieren.
Es programmiert sich aber viel entspannter als mit einem kommerziellen unter Windows.
Und mit C programmiert, ist der Code ohnehin
Zukunfts- und Prozessorwechsel-sicher.
Das nützt nicht viel, es scheitert an der Hardware. PIC und Power brauchen viel mehr Platz und die Power brauchen einen Schaltregler, wo die STM mit einem linearen auskommen. Wenn ich jetzt noch einen STM einbauen würde, müsste ich gleich mehr Platz und bessere Kühlung einplanen.
J. S. schrieb im Beitrag #738863
Sowas wie RISC-V macht doch nur Sinn wenn es um low cost Produkte mit
größten Stückzahlen geht.
Von daher gehe ich davon aus das es die Cortex-M länger als mich geben
wird.
Geben wohl, nur bekommt nicht jeder eine Lizenz. Wer größte Stückzahlen abnimmt, hat damit natürlich kein Problem. Den Chip-Herstellern kann es auch relativ egal sein - wie viel Promille Umsatz machen die Kunden, die auf Distributoren angewiesen sind?
Hast du die letzten drei Jahre komplett verpennt? Die waren eben gerade
davon gezeichnet, dass viele weit verbreitete STM32 eben NICHT (oder
nur zu horrenden Preisen über Broker) lieferbar waren. Und die Sache ist
Die PIC32M könnten es auch schaffen, aber gibt es dafür einen gcc? Von
den nötigen Programmiergeräten garnicht zu reden.
MPLABX und XC32 sind kostenlos und funktionieren unter Windows, Linux und MacOS, allerdings nur unter amd64. Zum Programmieren und Debuggen brauchst Du ein PICKIT3-Clone (15-20€) oder ein PICKIT4.
Ich bin jetzt total verwöhnt von den STM32 mit 128K RAM und CAN und viel
UART, SPI und so. Und mit vielen nutzbaren Pins; die SPC5xx und PIC32M
müssten wahrscheinlich 100 Pins haben, wo ich beim STM32 mit 64
auskomme.
Es gibt PIC32MZ mit 2MB Flash und 32MByte(!) RAM eingebaut.
MPLABX und XC32 sind kostenlos und funktionieren unter Windows, Linux
und MacOS, allerdings nur unter amd64. Zum Programmieren und Debuggen
brauchst Du ein PICKIT3-Clone (15-20€) oder ein PICKIT4.
Danke, das ist sehr erfreulich. Die PICKIT4-Hardware gefällt mir auch, aber die Software dazu? Anscheinend braucht man sogar einen speziellen USB-Treiber und MPLAB und das ist dann nur per GUI bedienbar? GUI, kommerziell und Linux spielen ja auch perfekt zusammen? Also, flashen wird viel umständlicher...
Der XC32 ist ein modifizierter gcc und man bekommt wohl auch die Quellen. Soweit sehr gut, allerdings versteht der nur C90. Inzwischen ist C23 so gut wie fertig, das meint Microchip doch nicht ernst? Es passt zu meinem ersten Eindruck von den PIC32M-Chips. Verglichen mit den STM32L wirken sie ein wenig primitiv.
Noch ein Rätsel: der "originale" gcc kennt doch -march=m4k und bei den meisten PIC32M steht "M4K" im Datenblatt. Was kann der XC32 besser? OK, ich muss ihn nicht selber bauen, und sonst? Man findet im Internet diverse XC32-Cracks, warum nehmen die Leute nicht das Original?
P.S.: nebenbei, was ist an meiner Frage falsch, unmoralisch oder beleidigend? -7 ist schon eine klare Aussage, aber warum?
Es gibt PIC32MZ mit 2MB Flash und 32MByte(!) RAM eingebaut.
Das scheint Microchip etwas anders zu sehen:
PIC32MZ EF Family of Microcontrollers
The PIC32MZ EF series of high-performance microcontrollers (MCUs)
with industry-leading connectivity (... gekürzt ...) applications.
Key Features
252 MHz/415 DMIPS performance
Up to 2 MB dual-panel live update Flash and 512 KB RAM
Excellent connectivity options (Hi-Speed USB, CAN, and
10/100 Ethernet)
Microchips Meistern der Formulierungskunst ist beim PIC32MZ1025DAB176 dieses Schmuckstück eingefallen: "..., available on-chip 32MB or 128MB externally addressable DDR2 DRAM, ..."
Danke, das ist sehr erfreulich. Die PICKIT4-Hardware gefällt mir auch,
aber die Software dazu? Anscheinend braucht man sogar einen speziellen
USB-Treiber und MPLAB und das ist dann nur per GUI bedienbar? GUI,
kommerziell und Linux spielen ja auch perfekt zusammen? Also, flashen
wird viel umständlicher...
Um das MPLABX wirst Du proaktisch nicht drumrum kommen. Die IPE (Integrated Programming Environment) kann man wohl auch per Kommandozeile aufrufen, aber das habe ich nie gemacht.
Der XC32 ist ein modifizierter gcc und man bekommt wohl auch die
Quellen. Soweit sehr gut, allerdings versteht der nur C90. Inzwischen
ist C23 so gut wie fertig, das meint Microchip doch nicht ernst?
Mich stört es nicht. Ich bin auch kein Informatiker, sondern E-Techniker, und ich hab bisher alles damit hinbekommen, was ich gebraucht habe.
Noch ein Rätsel: der "originale" gcc kennt doch -march=m4k und bei den
meisten PIC32M steht "M4K" im Datenblatt. Was kann der XC32 besser? OK,
ich muss ihn nicht selber bauen, und sonst? Man findet im Internet
diverse XC32-Cracks, warum nehmen die Leute nicht das Original?
Erstens weil es einfach funktioniert. Meine Zeit ist sehr teuer, ich muss da nicht unbedingt rumdaddeln. Zweitens erzeugt der XC32 wohl defaultmäßig 16 Bit Code (MicroMips), was im Flash des PIC32 schneller läuft, und das ist wohl so nicht im normalen gcc drin (oder war es nicht, mein Stand ist von vor 20 Jahren). Und drittens darf man die ganzen Bibliotheken und Header von Microchip lizenztechnisch nur mit dem XC32 nutzen (steht im Kleingedruckten drin). Vorteil für die kommerzielle Nutzung: es ist kein Stück GPL drin, man kann das ohne weitere Kosten einfach so in kommerzieller Software nutzen, aber irgendeinen Preis hat das halt auch. Wie gesagt, hat mich bislang nicht gestört.
Unter Debian und Ubuntu läuft das ganze problemlos, hier kann ich nichts negatives sagen. Wie es mit Redhat-Derivaten aussieht, weiß ich nicht, interessiert mich aber auch nicht. Wenn Microchip Ubuntu empfiehlt, nehme ich das halt.
Und Du merkst vielleicht auch, dass ich nicht unbedingt ein Open-Source-Verfechter bin. Ich mache das nicht als Hobby, da liegen die Schwerpunkte eben anders.
Microchips Meistern der Formulierungskunst ist beim PIC32MZ1025DAB176
dieses Schmuckstück eingefallen: "..., available on-chip 32MB or 128MB
externally addressable DDR2 DRAM, ..."
Wie würdest du das lesen, wenn du es nicht besser wüsstest? Bliebe nur
die Frage, wieso internes DRAM unbedingt extern adressierbar sein
sollte.
Es gibt drei Möglichkeiten:
In das Package kommt ein 32MB LPDDR2 Die rein und wird intern verbondet. In diesem Fall werden die Signale fürs DR2-DRAM micht rausgeführt.
Es wird kein extra DRAM mit reingepackt, aber dann werden die Signale nach außen geführt, und man kann ein 128MB LPDDR2 DRAM extern anschließen. Dann hast Du ein 300irgendwas Ball BGA.
Es wird kein extra DRAM mit reingepackt, und die Signale werden auch nicht nach außen geführt. Dann hast DU ein kleineres Package.
Hast du die letzten drei Jahre komplett verpennt? Die waren eben gerade
davon gezeichnet, dass viele weit verbreitete STM32 eben NICHT (oder
nur zu horrenden Preisen über Broker) lieferbar waren.
Hast du in den letzten drei Jahren nur auf STM32 geguckt.
Der Halbleiterengpass betraf(/-ift) praktisch alle Halbleiter, wo der Hersteller nicht rechtzeitig Fertigungskapazität gebucht oder selber ausreichend zur Verfügung hat. Erst allmählich wird es jetzt besser.
Ich hatte mir vor vielen Jahren mal Microchips Compiler für deren 16-Bitter angesehen. Der war zwar auf Basis GCC, hatte aber eine spezielle Optimierung drin, die nicht Teil des veröffentlichten Quellcodes war. Die war in ein separates Programm ausgelagert.
Obendrein hatten sie jenes Programm, das die diversen Teile wie Compiler+Assembler+Linker aufruft, so dressiert, dass ohne erfolgreiche ebenfalls ausgelagerte Lizenzprüfung nur ein Teil der Funktionalität zur Verfügung stand.
Das ganze wirkte sehr nach einer Lösung, die zwar gezwungenermassen die GNU Lizenz formal einhält, aber mehr den Buchstaben als dem Sinn folgend.
Mein Eindruck: Im µC-Sektor sind Compiler auf halbwegs aktuellem Stand der Sprache(n) nicht unbedingt üblich. Wer als Anwender moderne Features nutzt, begibt sich deshalb in eine Abhängigkeit, also bleibt man lieber bei altem C. Und weil das so ist, werfen jene Hersteller, die eigene Entwicklungsumgebungen pflegen, da nicht viel Aufwand rein, um auf Level zu bleiben. Damit schliesst sich der Kreis.
Der war zwar auf Basis GCC, hatte aber eine
spezielle Optimierung drin, die nicht Teil des veröffentlichten
Quellcodes war. Die war in ein separates Programm ausgelagert.
Selbst wenn das nicht mehr so ist, und selbst wenn Microchip ihre Patches brav eingereicht hat, weiß man nicht, ob die angenommen wurden. Das würde mit dem Unterschied zwischen kostenlos und PRO gut zusammenpassen: -O2, -Os, -flto, -mips16 und -mmicromips kosten Kohle. Die Lizenzprüfung selbst ist ja ganz normal, das passt schon. Und wer den XC32 nicht kauft, soll eben einen größeren Chip kaufen ;)
Wer als Anwender moderne Features
nutzt, begibt sich deshalb in eine Abhängigkeit, also bleibt man lieber
bei altem C. Und weil das so ist, werfen jene Hersteller, die eigene
Entwicklungsumgebungen pflegen, da nicht viel Aufwand rein, um auf Level
zu bleiben.
Jetzt sagst du mir das, ein paar Jahre zu spät. Ja, ich bin wirklich verwöhnt. Aber wer denkt schon dran, dass die erfolgreichste uC-Familie aller Zeiten plötzlich nicht mehr frei verkäuflich ist.
Die war damals wenig phantasievoll implementiert. Ersetzte man das Programm für den Lizenzcheck durch einen Einzeiler "exit(0);" war das Thema gegessen.
Und drittens darf man die ganzen Bibliotheken und Header von Microchip
lizenztechnisch nur mit dem XC32 nutzen (steht im Kleingedruckten drin).
Das ist ein Argument, hatte ich glatt überlesen, danke für die Warnung. Aber wenigstens ist es klar geregelt, nicht wie bei STM, wo jedes Update eine neue Lizenz mitbringt. Die einzelnen Dateien haben auch mal eine eigene, andere, als das Paket. Deshalb bin es gewohnt, solche Header nicht zu benutzen.
Wenn Microchip Ubuntu empfiehlt, nehme ich das halt.
Der XC32 ist ein modifizierter gcc und man bekommt wohl auch die
Quellen. Soweit sehr gut, allerdings versteht der nur C90. Inzwischen
ist C23 so gut wie fertig, das meint Microchip doch nicht ernst?
Mich hält dann eher vor allem MPLAB-X davon ab irgendeinen PIC verwenden zu wollen.
Und dann gibt es zwar sowas wie die PIC32CM-JH die auf den ersten Blick umgelabelte ATSAMC20 / ATSAMC21 sind, im Detail haben die aber kleine Unterschiede die nirgendwo dokumentiert sind und welche die dann doch nicht zu 100% kompatibel machen.
Und leider kann man die PIC32CM-JH nicht einfach so im Microchip Studio verwenden.
Es passt zu meinem ersten Eindruck von den PIC32M-Chips.
Verglichen mit den STM32L wirken sie ein wenig primitiv.
Hast Du mal ein konkretes Beispiel?
Denn im Gegensatz zu STM32 sind viele von den PIC32M nicht nur für AECQ-100 qualifiziert, sondern auch auf Functional Safety ausgelegt.
Und C99 passt doch?
Was in C11 drin ist muss man erstmal benötigen
Natürlich muss man heutzutage überall Abstriche machen, ich sträube mich aber immer noch. Früher hatte ich auch nur einen Assembler mit ich mir passende Cross-Assembler selbst geschrieben hab'. Bootloader wurden mit Kippschalter eingetoggelt, inzwischen gibt es den gcc-12 sogar bei Debian.
Und dann gibt es zwar sowas wie die PIC32CM-JH die auf den ersten Blick
umgelabelte ATSAMC20 / ATSAMC21 sind
Vor allem haben die einen Cortex-M-Kern, sind also völlig uninteressant.
Es passt zu meinem ersten Eindruck von den PIC32M-Chips.
Verglichen mit den STM32L wirken sie ein wenig primitiv.
Hast Du mal ein konkretes Beispiel?
Denn im Gegensatz zu STM32 sind viele von den PIC32M nicht nur für
AECQ-100 qualifiziert, sondern auch auf Functional Safety ausgelegt.
/Dafür/ ist einfachere Hardware natürlich von Vorteil, keine Frage. Mir war vor allem aufgefallen, dass die Ports keine slew rate-Begrenzung haben. Dann braucht man bei den meisten Typen einen MHz-Quarz, die STM32L können ihren Takt auch aus 32kHz erzeugen oder sogar intern. Dazu kommt die relativ hohe Stromaufnahme, besonders bei hohen Temperaturen (ja, PowerPC ist noch schlimmer). STM32L betreibe ich aus 24V per Linearregler. An viel RAM hab' ich mich auch gewöhnt. Und ohne eingebauten Bootloader brauche ich für die Inbetriebnahme eine völlig andere Technik als für Firmware-Updates.
Das sind auch keine speziellen STM32L-Vorteile. Die EFM32 können das ähnlich gut, haben aber leider auch ARM-CPUs.
Bei Digikey finde ich überhaupt nur noch PIC32M und PowerPC, und evt. AVR32, aber die sind doch sehr exotisch. Der Rest ist erst 2059 lieferbar oder wird nicht vom gcc unterstützt.
Und C99 passt doch?
Was in C11 drin ist muss man erstmal benötigen
Natürlich muss man heutzutage überall Abstriche machen,
Was für Abstriche?
Und dann gibt es zwar sowas wie die PIC32CM-JH die auf den ersten Blick
umgelabelte ATSAMC20 / ATSAMC21 sind
Vor allem haben die einen Cortex-M-Kern, sind also völlig uninteressant.
Mal davon ab, dass der Absatz beschreibt warum ich keine PICs verwenden möchte und mal davon ab, dass STM32 auch einen Cortex-M-Kern haben?
Mir war vor allem aufgefallen, dass die Ports keine slew rate-Begrenzung
haben.
Ok, das sehe ich da auch gerade nicht, aber ich kenne die PIC32M nicht und man kann nicht alle Datenblättern durchsuchen.
Dann braucht man bei den meisten Typen einen MHz-Quarz, die
STM32L können ihren Takt auch aus 32kHz erzeugen oder sogar intern.
Ich habe gerade das Datenblatt von einem PIC32MX offen und die haben zwar einen LPCR Oszillator mit 31,25kHz eingebaut und haben einen Secondary Oszillator Anschluss für 32,768kHz, dem Block Diagramm nach kann man die aber nicht durch die PLL schicken.
Dafür ist noch ein 8MHz Oszillator eingebaut, also intern können die den Takt auch erzeugen.
Aber dann habe ich gerade mal ein Projekt für den STM32L412C8 in STM32CubeIDE aufgemacht und mit dem kann man die 32kHz auch nicht auf die PLL geben um den Core-Takt zu erzeugen.
So im Gegensatz zum Beispiel zu einem ATSAMC21 bei dem man auch einen 32KHz Oszillator für die PLL benutzen kann.
Nicht das ich das ernsthaft in Erwägung ziehe, meine Controller aus einem 32kHz Oszillator zu betreiben.
Dazu kommt die relativ hohe Stromaufnahme,
besonders bei hohen Temperaturen
Ja, vielleicht, aber "PIC32M" ist viel breiter gefasst als "STM32L" und es gibt auch sowas wie PIC32MM.
Und ohne eingebauten Bootloader brauche ich für die Inbetriebnahme eine
völlig andere Technik als für Firmware-Updates.
Keine Ahnung was die PIC32M auf der Bootloader Seite machen, aber die werden sicher auch erlauben das man einen Bootloader flasht.
Das sind auch keine speziellen STM32L-Vorteile. Die EFM32 können das
ähnlich gut, haben aber leider auch ARM-CPUs.
Dafür sitzt Silicon Labs ähnlich wie Renesas auf jeweils eigenen Inseln.
Bei Digikey finde ich überhaupt nur noch PIC32M und PowerPC, und evt.
AVR32, aber die sind doch sehr exotisch. Der Rest ist erst 2059
lieferbar oder wird nicht vom gcc unterstützt.
Dann hast Du nicht richtig geschaut.
Ich habe mir gerade mal auf Digikey die lieferbaren 32 Bit Controller anzeigen lassen und das sind aktuell 2588.
Selbst wenn man die 500 abzieht bei denen die Stückzahl unter 100 liegt bleiben noch genug übrig.
Der größte Teil davon sind Cortex-M, von M0 bis M7, 1934 Stück.
Ich halte die Chip-Krise für noch lange nicht beendet, so langsam tut es aber etwas weniger weh.
Und C99 passt doch?
Was in C11 drin ist muss man erstmal benötigen
Natürlich muss man heutzutage überall Abstriche machen,
Was für Abstriche?
Na, C99 statt C23, Schalt- statt Linearregler, mehr EMV-Probleme , mehr Platinenfläche und nicht zuletzt utopische Lieferzeiten.
Vor allem haben die einen Cortex-M-Kern, sind also völlig uninteressant.
Mal davon ab, dass der Absatz beschreibt warum ich keine PICs verwenden
möchte und mal davon ab, dass STM32 auch einen Cortex-M-Kern haben?
ich suche einen Ersatz für STM32 (aber siehe unten)
Dann braucht man bei den meisten Typen einen MHz-Quarz
Aber dann habe ich gerade mal ein Projekt für den STM32L412C8 in
STM32CubeIDE aufgemacht und mit dem kann man die 32kHz auch nicht auf
die PLL geben um den Core-Takt zu erzeugen.
ich glaube, es geht so: 32kHz -> FLL -> 48MHz-RC
Nicht das ich das ernsthaft in Erwägung ziehe, meine Controller aus
einem 32kHz Oszillator zu betreiben.
Keine Ahnung was die PIC32M auf der Bootloader Seite machen, aber die
werden sicher auch erlauben das man einen Bootloader flasht.
Ja, natürlich. Aber bei vielen anderen Herstellern ist der schon ab Werk eingebaut und kennt die richtige Programmiervorschrift.
Ich habe mir gerade mal auf Digikey die lieferbaren 32 Bit Controller
anzeigen lassen und das sind aktuell 2588. (...)
Der größte Teil davon sind Cortex-M, von M0 bis M7, 1934 Stück.
Das genau ist doch das Problem. Wenn ARM Ernst macht, kann man die alle nicht mehr kaufen. Und daraufhin alle anderen auch nicht mehr, weil ich wohl nicht der einzige bin, der umsteigen muss. Insofern ist auch meine Frage nach einem Ersatz sinnlos, es wird keinen geben.
Ich halte die Chip-Krise für noch lange nicht beendet
Die hat noch garnicht richtig angefangen, bis jetzt war es nur Spaß...
Wenn ARM Ernst macht, kann man die alle nicht mehr kaufen.
Doch, natürlich kann man. Nur muss man dann selbst einen Lizenzvertrag mit ARM abschließen und hat Kosten am Hals, die sich am Wert des Produktes orientieren, in dem er verbaut wird.
Da das allerdings bei Privatleuten und eher kleinen Firmen im Mikrocontroller Sektor wenig realistisch ist, gehe ich davon aus, dass ARM mit dieser Änderung der Lizenzpolitik hauptsächlich Server und Mobilgeräte wie Smartphones und Tablets adressiert.
Klar ist aber, dass ARM sich damit auf längere Sicht abschiesst, und Kunden gut beraten sind, sich schon mal anderweitig umzusehen. Selbst wenn sich das letztlich als Windei entpuppen sollte.
Wenn ARM Ernst macht, kann man die alle nicht mehr kaufen.
Doch, natürlich kann man. Nur muss man dann selbst einen Lizenzvertrag
mit ARM abschließen und hat Kosten am Hals, die sich am Wert des
Produktes orientieren, in dem er verbaut wird.
In der Vergangenheit hatte ich mit Produkten zu tun, die ARM sicher gefallen würden :) Einmal 1 uC, viel Analog und viel Know How, ab 100k VK. Oder 2 bis 3 uC, mehrere Tonnen Eisen und Kupfer und Tiefbau für knappe 500k VK. Selbst wenn es eine Lizenz gibt, wie will man sowas abrechnen?
ARM ist mit sehr wenigen Kunden groß geworden. Wenn dann jeder eine Lizenz bekäme, wären es plötzlich Tausende. Schon von daher wird nicht jeder eine Lizenz bekommen.
Da das allerdings bei Privatleuten und eher kleinen Firmen im
Mikrocontroller Sektor wenig realistisch ist, gehe ich davon aus, dass
ARM mit dieser Änderung der Lizenzpolitik hauptsächlich Server und
Mobilgeräte wie Smartphones und Tablets adressiert.
Apple wäre angeblich nicht betroffen, wegen spezieller Lizenzen für eigene Chips. Samsung könnte eigene Chips bauen. Die Chinesen bauen so oder so etwas ohne Lizenz. IoT funktioniert ohne ARM. Damit fallen schon mal ein paar Stück weg. Aber die Buchhalter werden das schon richtig ausgerechnet haben...
Klar ist aber, dass ARM sich damit auf längere Sicht abschiesst, und
Kunden gut beraten sind, sich schon mal anderweitig umzusehen. Selbst
wenn sich das letztlich als Windei entpuppen sollte.
Apple wäre angeblich nicht betroffen, wegen spezieller Lizenzen für
eigene Chips. Samsung könnte eigene Chips bauen.
ARM verkauft sowieso keine Chips, sondern nur Designs für Integration in Chips anderer Hersteller. Wie etwa einen Cortex M3 oder A510 Core.
Apple kauft aber keine solchen Core-Designs, sondern hat eine Architektur-Lizenz, darf also den Befehlssatz nutzen. Was eine völlig andere Lizenzierung ist. Deren Cores sind Eigenentwicklungen (verdammt gute übrigens).
Samsung hat beides. Für einige Jahre hatte Samsung in den Galaxy Sx Exemplaren für Kunden ausserhalb USA/Japan eigene Designs mit Mongoose-Cores drin, auf Basis der Architektur-Lizenz. Diese erwiesen sich aber als nachhaltig schlechter und das Team wurde eines Tages sehr plötzlich aufgelöst. Zu einiger Überraschung kam indes unlängst die Meldung rein, Samsung wolle wieder eigene Cores designen. Als kurz darauf die Meldung über ARMs Lizenzspiel reinkam, zählte ich Eins und Eins zusammen.
Tun sie auch. Die derzeitigen Exynos (sowie Googles Tensors) sind aus Samsungs Fertigung, verwenden aber ARM-Cores.
Die Chinesen bauen so oder so etwas ohne Lizenz.
Auch die SoCs für die China-Smartphones? Die können sie nämlich nicht in China selbst herstellen. Auf diesem Weg könnte ARM schnell den Laden dicht machen - genau wie das aus anderen Gründen Huawei geschah.
Die SoCs etlicher China-Smartphones der Unter- und Mittelklasse, also ohne Snapdragons drin, stammen auch im Gesamt-Design mindestens teilweise nicht aus VR-China, sondern aus Taiwan, wie die von MediaTek.
Aber so wenige waren es dann doch nicht, denn als Kundschaft mit Sinn für Custom-Chips nach 32-Bittern suchte, war ausser ARM kaum jemand in Sicht. Der Handy-Markt hatte schon vor den Smartphones allerhand ARMe drin. Ich fand auch Storage-Controller mit ARM-CPU, also kein µC.
Aber die Buchhalter werden das schon richtig ausgerechnet haben...
Die Buchhalter eher nicht. Diese Entscheidung ist strategischer Art und findet weit oberhalb deren Gehaltsklasse statt. Softbank, der Inhaber von ARM, braucht Geld. Der versuchte Verkauf an NVidia ging in die Hose, die Wettbewerbshüter sahen das mit Recht äusserst kritisch.
Das war aber nicht das letzte Wort. ARM soll noch in diesem Jahre an die Börse gehen. Dazu muss die Braut aufgehübscht werden, damit fachfremde Käufer, die Finanzdaten im Auge, wie blöde einsteigen. Wenn die erwartbaren Folgen dieser Lizenz-Entscheidung nach Jahren allmählich Wirkung zeigen, oder die Sache als Monopolmissbrauch einkassiert wurde, hat die Softbank ihr Geld schon bekommen.
Und C99 passt doch?
Was in C11 drin ist muss man erstmal benötigen
Natürlich muss man heutzutage überall Abstriche machen,
Was für Abstriche?
Na, C99 statt C23,
Noch mal, was für Abstriche?
C23 nehme ich noch nicht Ernst, dafür ist das zu frisch, spontan fällt mir da auch nur #embed als potentiell nützlich für mich auf.
C17 bringt exakt gar nichts Neues.
C11 nicht nutzen zu können erfodert jetzt was genau für Abstriche?
Und Du merkst vielleicht auch, dass ich nicht unbedingt ein
Open-Source-Verfechter bin.
Du verwendest also wenn möglich keine OSS? Dann ist Deine SW-Welt heute aber eher "übersichtlich". Selbst große Firmen verwenden in ihren Produkten haufenweise OSS.
Ich mache das nicht als Hobby, da liegen die
Schwerpunkte eben anders.
Das eine schließt das andere nicht aus. Bei dir klingt das so, als dürfe man im professionellen engineering keine OSS verwenden.
Die Zeiten, in denen im Profi-Umfeld OSS verpöhnt war, sind IMHO vorbei.
Das war aber nicht das letzte Wort. ARM soll noch in diesem Jahre an die
Börse gehen. Dazu muss die Braut aufgehübscht werden, damit fachfremde
Käufer, die Finanzdaten im Auge, wie blöde einsteigen. Wenn die
erwartbaren Folgen dieser Lizenz-Entscheidung nach Jahren allmählich
Wirkung zeigen, oder die Sache als Monopolmissbrauch einkassiert wurde,
hat die Softbank ihr Geld schon bekommen.
Ich halte das für eine ziemlich realistische Einschätzung der Sachlage.
Das genau ist doch das Problem. Wenn ARM Ernst macht, kann man die alle nicht mehr kaufen.
Blödsinn! Warum sollte ARM verhindern wollen, dass Chips mit ARM Kern verkauft werden? ARM möchte Firmen, die Produkte mit ARM-IPs vertreiben, zur Kasse bitten. In wie weit dies bereits bestehende Produkte betrifft, wissen wir nicht. Oder kennst du den Vertrag zwischen z.B. STM und ARM? Sollte ARM den Bogen überspannen, werden wohl eher die Chips zum Ladenhüter, weil KMUs evtl. keine Chips mehr mit ARM-IP mehr kaufen. STM hat ja seine Lizenz und kann erstmal produzieren. ARM wird nicht so doof sein und den Ast, auf dem es sitzt, durchschneiden.
Wie wahrscheinlich ist es überhaupt, daß "ARM ernstmacht"? Mir scheint das ein fehlverstandenes Schreckgespenst zu sein, das hier an die Wand gemalt wird.
Wie wahrscheinlich ist es überhaupt, daß "ARM ernstmacht"?
Die bisherigen Informationen über Lizenzänderungen stammen m.W. aus Gerichtsakten und ähnlich indirekten Quellen. Nicht aber von ARM selbst, da hält man sich bedeckt. Es gibt also keine Details dazu. Solche Lizenzgespräche sind üblicherweise nicht öffentlich und wer mag schon am Ast sägen, auf dem man sitzt.
Das passt zu meiner obigen These zum Börsengang, denn es hilft dabei, wenn die Sache nicht als dräuende Katastrophe auf Seite 1 der Financial Times breitgetreten wird, sondern als Notiz auf Seite 10 einiger Fachblätter versumpft. ARM dürfte daran interessiert sein, dass es so bleibt.
Nun baut z.B. Qualcomm die Snapdragons für Samsungs Handys, hat aber mit den Cortex M für den µC-Masseneinsatz nur am Rande zu tun (im Peripherie- und Baseband-Bereich). Die Highend-Chips haben einen kurzen Produktzyklus von wenigen Jahren, was jährlich neue Lizenzen für neue IP erfordert. Diese Hersteller sind also unmittelbar betroffen, und auch damit gemeint. Die Cortex M sind aber auch nach 10 Jahren nicht veraltet, da drängt nix.
Es kann also gut sein, dass jener Markt, in dem sich die hiesigen Forinten bewegen, davon überhaupt nicht betroffen ist. Erst recht nicht kurzfristig.
Aber die Chinesen haben noch andere Motive, von ARM wegzugehen, nämlich weil die USA sie verhungern lassen können und die Weltpolitik diesem Risiko nicht eben widerspricht. Die werden also mit der Zeit deutlich in Richtung RISC-V migrieren. Besonders in jenem Fertigungsbereich, den sie selbst im Griff haben oder in absehbarer Zeit haben werden. Was für die weltweite Kundschaft auf lange Sicht von Bedeutung sein kann.
Deshalb meine Einschätzung: Kein Grund, etwas übers Knie zu brechen, aber im Auge behalten und vielleicht bei passender Gelegenheit Alternativen ausprobieren.
PS: Es gibt zwei signifikante Änderungen: Einerseits die Umstellung des Lizenzmodells vom Wert des Chips auf den Produktwert des Gerätes, in dem die ARMe stecken. Andererseits ein Zwang, GPUs von ARM zu verwenden, statt Drittlösungen zu nutzen - wie bisher häufig der Fall.
Die Änderung im GPU-Bereich - der ziemliche Probleme mit Monopolmissbrauch drohen - passt perfekt im Bereich der Mobilgeräte, ist aber völlig uninteressant bei µCs.
C11 nicht nutzen zu können erfodert jetzt was genau für Abstriche?
https://en.wikipedia.org/wiki/C11_(C_standard_revision)
Was würde Dir da konkret fehlen und warum, wenn Du "nur" C99 statt C11
auf einem Mikro-Controller zur Verfügung hättest?
Hauptsächlich _Static_assert, das lässt sich nicht so einfach nachbauen. 0b statt 0x wäre noch nett. Ob Unicode unterstützt wird, ist mir /bisher/ egal gewesen. Wenn ich ein Programm, das mit gcc-10 und -std=c2x keine Warnungen wirft, mit -std=c99 übersetze, wird auch _Noreturn, unnamed structs/unions, struct has no named members und redefinition of typedef 'isr_type' angemeckert.
Interessant ist, warum die redefinition mit c2x keine Warnung gibt und warum es für //-Kommentare mit c99 keine Warnung gibt. Irgendwie lässt sich das nicht so einfach testen, ohne den XC32 zu installieren. Welche gcc-Version im neuesten XC32 steckt, ist auch noch die Frage. Der gcc wird ja auch unabhängig vom C-Standard verbessert.
Und Du merkst vielleicht auch, dass ich nicht unbedingt ein
Open-Source-Verfechter bin.
Du verwendest also wenn möglich keine OSS?
Das habe ich so nicht geschrieben. Klar verwende ich das, wenn es sich anbietet. Ich bin aber kein militanter Verfechter, kein Aktivist, kein Ideologe und auch kein Politiker.
Ich habe lange Zeit beispielsweise mit Solaris gearbeitet, obwohl die Maschinen auch NetBSD oder Linux hätten booten können. Solaris hatte halt damals Vorteile gehabt. Der Sun CC war damals deutlich besser als der gcc gewesen (clang gabs in den 90'ern noch nicht).
Wenn kommerzielles Zeugs für ein Projekt besser ist, dann nehme ich das eben. Das wäre für andere Leute aus politischen Gründen ein Auschlusskriterium, für mich aber nicht.
OSS ist auch nicht gleich OSS. Im kommerziellen Bereich muss man aufpassen, sich beispielsweise keinen GPL-Code einzufangen, der dann das gesamte Binary zu GPL-Code machen würde, mit allem, was dazu gehört. Die Lizenzbedingungen gefallen nicht alle Auftraggebern. BSD oder verwandte Lizenzen sind aber meist kein Problem.
Interessant ist, warum die redefinition mit c2x keine Warnung gibt und
warum es für //-Kommentare mit c99 keine Warnung gibt. Irgendwie lässt
sich das nicht so einfach testen, ohne den XC32 zu installieren.
Warum diese Vorsicht? Hast Du Angst, Dir Corona, Pocken oder Ebola einzufangen. Hint: Da ist auch ein funktionierender Uninstaller dabei.
Welche
gcc-Version im neuesten XC32 steckt, ist auch noch die Frage. Der gcc
wird ja auch unabhängig vom C-Standard verbessert.
Pic32 wollt ich auch mal probieren, hab dann aber leider nicht mal das Datenblatt komplett zusammengekriegt. Da waeren immer externe Referenzen zum eingekauften Kern. Jede Subgruppe ein eigenes Datenblatt... Dann versandeten meine Suchen jeweils.
Hat glaub einen Mips Kern.
nimm einen ARM des Herstellers dem Du am geringsten Misstraust.
ARM wird es noch ewig geben. Diese sind in genug Automotive und Industrieanwendungen drinnen, und da sind Produktlebenszyklen von >10 Jahren nichts ungewöhnliches. Und da rede ich nicht von der Familie sondern von einem ganz speziellen Typen.
Warum willst Du min. 10 Jahre haben? Musst Du Dein Produkt inkl. Ersatzteile für 10 Jahre lieferfähig halten? Wenn ja, dann solltest Du halt mal mit dem Hersteller sprechen und (notfalls) einen entsprechenden Vertrag machen. Der Hersteller wird Dir dann schon sagen, welche Typen im Langzeitprogramm drinnen sind, und sich das dann auch ordentlich bezahlen lassen.
Pic32 wollt ich auch mal probieren
Jede Subgruppe ein eigenes Datenblatt...
Dann versandeten meine Suchen jeweils.
Bei den STM32 beklagen sich die Leute über die 2000+ Seiten. Wie man es macht, ist es verkehrt ;) Mir gefällt www.microchip.com (noch?) viel besser als www.st.com, aber bisher hab' ich auch nur die eigentlichen Datenblätter...
Irgendwie lässt sich das nicht so einfach testen,
ohne den XC32 zu installieren.
Warum diese Vorsicht? Hast Du Angst, Dir Corona, Pocken oder Ebola
einzufangen.
Angst hatte ich keine und jetzt habe ich einen Compiler, der root-Rechte braucht und /usr/bin/mount als root aufruft :) WTF oder was sagt man dazu?
Immerhin funktioniert er ganz ohne Mplab und ohne GUI; sehr brav. Dann wieder ist es eine interessante Mischung: er akzeptiert -std=c99, c11 und c17, aber nicht c2x, und verhält sich auch ein wenig unterschiedlich. Aber z.B. ((fallthrough)) (in eckigen Klammern) kennt er garnicht und "stack usage computation not supported for this target". Also insgesamt keine ernsten Probleme, aber doch ein Rückschritt.
Was macht ein Kommandozeilen-Compiler mit "mount"???
Es ist nicht der Compiler selbst, aber ohne richtige Antwort vom License Manager xclm geht eben nichts. Der xclm baut wohl aus /proc/self/mountinfo und diversen anderen Daten die hostid zusammen. Die ist für die kostenlose Version natürlich besonders wichtig :)
Aber z.B. ((fallthrough)) (in eckigen Klammern) kennt er garnicht
Das ist ja meiner Erinnerung nach auch ein C23-Feature (wie alle diese
Attribute).
Ja aber, schreibt man das nicht so? Natürlich geht es auch anders oder ganz ohne, aber jede Warnung hilft. Mit den neuen Konstruktionen kann man sich nicht ganz so leicht in den Fuß schießen. Ich glaube, die /* Kommentare */ sind auch schon für böse erklärt worden.
Das ist ja meiner Erinnerung nach auch ein C23-Feature (wie alle diese
Attribute).
Ja aber, schreibt man das nicht so?
Schon, aber wenn dein Compiler eben nicht "bleeding edge" ist und die (angehenden) C23-Features schon implementiert, dann geht das nicht so. Wenn es ein GCC-basierter Compiler ist, kannst du noch mit irgendwelchen Pragmas die entsprechende Warnung für die Übersetzungseinheit (oder vielleicht sogar pro Funktion) ausschalten.
Der Klassiker war /* FALLTHROUGH */, aber das lag daran, dass der originale Lint solche Kommentare benutzt hat.
Der xclm baut wohl aus /proc/self/mountinfo
und diversen anderen Daten die hostid zusammen.
Wow, auf so eine (scheinbar) dumme Idee muss man erst mal kommen. Ich würde gerne man den Quelltext sehen. Oder ist der etwa aus Sicherheitsgründen geheim (security by oscurity). Würde dazu passen.
Es ist nicht der Compiler selbst, aber ohne richtige Antwort vom License
Manager xclm geht eben nichts. Der xclm baut wohl aus
/proc/self/mountinfo und diversen anderen Daten die hostid zusammen. Die
ist für die kostenlose Version natürlich besonders wichtig :)
Es gibt keine kostenlose Version, genausowenig wie es eine Standard oder Pro Edition gibt. Es gibt genau eine Version, und der Lizenzmanager bestimmt den Funktionsumfang.
Und so wie Du an die Sache rangehst, solltest Du bei dem bleiben, was Du hast, kennst und liebst.
Für PowerPC versprechen NXP und STM Lieferbarkeit bis ca. 2035 und die
haben einen UART-Bootloader, aber sie brauchen 10 mal soviel Strom wie
aktuelle Chips.
Wie kommst Du eigentlich auf diese Rechnung? Die PowerPC Controller verbrauchen zwar meist etwas mehr Strom, aber so krass ist der Unterschied eigentlich nicht. Zumindest, wenn man vergleichbare Controller heranzieht.
Zum Vergleich habe ich mal einen SPC560B50 und einen S32K118 bei jeweils 48MHz Taktfrequenz und einer kleinen CAN-Applikation (Frames mit 500Kbps senden und LED je nach ACK setzen) getestet:
SPC560B50 ca. 46mA
S32K118 ca. 27mA
Bei den aktuellen SPC58xx sollte der Unterschied zum S32K3xx noch geringer ausfallen, aber das kann ich momentan nicht testen.
Für PowerPC versprechen NXP und STM Lieferbarkeit bis ca. 2035 und die
haben einen UART-Bootloader, aber sie brauchen 10 mal soviel Strom wie
aktuelle Chips.
Wie kommst Du eigentlich auf diese Rechnung?
Das ist natürlich nur eine pauschale Schätzung und die kommt daher: STM32L496 7.3mA max. @48MHz,105°C und SPC560P44L 77mA max. @40MHz, aber bei welcher Temperatur? Das passt irgendwie nicht zu den typisch 45 oder 62mA.
Beim STM32 muss man noch Peripherie dazu rechnen, dann bleibt aber immer noch ein Faktor 5 oder so.
