Mahlzeit! 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.
Bauform B. schrieb: > Mahlzeit! > > gibt es uC, die man heute und in 10 Jahren auch noch kaufen kann? 8051 Oliver
Bauform B. schrieb: > 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. Bullshit, bei den Milliarden Handies/Tabletts etc. die jährlich verkauft werden, kriegste mit Sicherheit in zehn Jahren noch funktionsfähuge Gebrauchtgeräte. https://de.statista.com/statistik/daten/studie/173049/umfrage/weltweiter-absatz-von-smartphones-seit-2009/ > 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.
J. S. schrieb: > 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...
:
Bearbeitet durch User
Sogar die 16 Jahre alten Modelle der ersten STM32 Serie werden immer noch produziert, wie man nun nach der ausgestandenen Lieferkrise sehen kann. https://www.mouser.de/c/?q=stm32f103&instock=y
Uwe B. schrieb: > 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.
DSGV-Violator schrieb: > Bauform B. schrieb: >> 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?
C-hater schrieb: > 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 Das war auch nicht seine Frage ...
Bauform B. schrieb: > 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. fchk
Frank K. schrieb: > 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?
:
Bearbeitet durch User
Frank K. schrieb: > 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) (Quelle: https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/32-bit-mcus/pic32-32-bit-mcus/pic32mz-ef) Auch in der Tabelle hier https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/32-bit-mcus/pic32-32-bit-mcus liegt das Maximum an RAM bei 640 kB. Wo siehst Du 32 MB?
:
Bearbeitet durch User
Harald K. schrieb: > Das scheint Microchip etwas anders zu sehen: Microchips Meistern der Formulierungskunst ist beim PIC32MZ1025DAB176 dieses Schmuckstück eingefallen: "..., available on-chip 32MB or 128MB externally addressable DDR2 DRAM, ..." https://www.microchip.com/en-us/product/pic32mz1025dab176 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. Sowas kennt man sonst eigentlich aus chinesischen Bedienungsanleitungen. Wo sitzen die Freunde denn mittlerweile?
:
Bearbeitet durch User
Die Seite ist gleich mehrfach sehr gelungen: > PIC32MZ DA series offers MPU like performance with ease of design > of an MCU for GUI designs with it’s 2MB Flash and 640KB of SRAM .. > Product Features > .. > * 1MB Flash memory (plus an additional 160 KB of Boot Flash) > * 256KB SRAM memory Gut, im Einleitungstext steht "series", aber ... Marketing ist die Kunst, im rechtlich noch vertretbarem Rahmen zu lügen.
Bauform B. schrieb: > 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. fchk
:
Bearbeitet durch User
(prx) A. K. schrieb: > Harald K. schrieb: >> Das scheint Microchip etwas anders zu sehen: > > Microchips Meistern der Formulierungskunst ist beim PIC32MZ1025DAB176 > dieses Schmuckstück eingefallen: "..., available on-chip 32MB or 128MB > externally addressable DDR2 DRAM, ..." > > https://www.microchip.com/en-us/product/pic32mz1025dab176 > > 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: 1. 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. 2. 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. 3. Es wird kein extra DRAM mit reingepackt, und die Signale werden auch nicht nach außen geführt. Dann hast DU ein kleineres Package. fchk
C-hater schrieb: > 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.
:
Bearbeitet durch User
Bauform B. schrieb: > Noch ein Rätsel 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.
:
Bearbeitet durch User
Bauform B. schrieb: > allerdings versteht der nur C90 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.
:
Bearbeitet durch User
(prx) A. K. schrieb: > 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 ;) (prx) A. K. schrieb: > 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.
Bauform B. schrieb: > Die Lizenzprüfung selbst ist ja ganz normal Die war damals wenig phantasievoll implementiert. Ersetzte man das Programm für den Lizenzcheck durch einen Einzeiler "exit(0);" war das Thema gegessen.
:
Bearbeitet durch User
Frank K. schrieb: > 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. Empfehlen dürfen sie gerne :)
Bauform B. schrieb: > 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? Ich wollte es nicht glauben und habe mal bei Microchip gesucht. https://ww1.microchip.com/downloads/aemDocuments/documents/DEV/ProductDocuments/ReleaseNotes/xc32-v4.21-full-install-release-notes.html#Migration "New Features in MPLAB® XC32 v4.00" "C99 Standard -- MPLAB® XC32 is now C99 compliant." Ja ok, das war erst November 2021, aber nicht erst letzte Woche. Vor zwei Jahren wäre das noch ein Argument gewesen. Und C99 passt doch? Was in C11 drin ist muss man erstmal benötigen und C17 hat gar nichts neues gebracht. https://de.wikipedia.org/wiki/Varianten_der_Programmiersprache_C 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.
Rudolph R. schrieb: > 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.
:
Bearbeitet durch User
Bauform B. schrieb: > Rudolph R. schrieb: >> 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.
Rudolph R. schrieb: > Bauform B. schrieb: >> Rudolph R. schrieb: >>> 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. ich nehme auch lieber 1Hz aus dem RTC-Chip ;) > es gibt auch sowas wie PIC32MM. OK, den müsste ich noch unter die Lupe nehmen. > 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ß...
Bauform B. schrieb: > 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.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Bauform B. schrieb: >> 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.
Bauform B. schrieb: > 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.
:
Bearbeitet durch User
Bauform B. schrieb: > Samsung könnte eigene Chips bauen. 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.
:
Bearbeitet durch User
Bauform B. schrieb: > ARM ist mit sehr wenigen Kunden groß geworden. Seltenst fängt man als Riese an. ;-) 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.
Bauform B. schrieb: > 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.
:
Bearbeitet durch User
Bauform B. schrieb: > Rudolph R. schrieb: >> Bauform B. schrieb: >>> Rudolph R. schrieb: >>>> 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? 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?
Frank K. schrieb: [...] > 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. > > fchk ciao Marci
(prx) A. K. schrieb: > 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.
Bauform B. schrieb: > 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.
Harald K. schrieb: > 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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Rudolph R. schrieb: > 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.
Marci W. schrieb: > Frank K. schrieb: > [...] >> 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. fchk
Bauform B. schrieb: > 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. C:\Microchip\xc32\v4.21\bin>xc32-gcc --version pic32m-gcc.exe (Microchip XC32 Compiler v4.21) 8.3.1 Build date: Dec 5 2022 fchk
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. Wo gibt es ein kompletes Datenblatt ?
:
Bearbeitet durch User
Servus, 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. Gruß
Purzel H. schrieb: > 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... Robert G. schrieb: > ARM wird es noch ewig geben. Wahrscheinlich. Und was nützt uns das, wenn wir die Chips ohne Lizenz nicht kaufen können? > Warum willst Du min. 10 Jahre haben? Musst Du Dein Produkt inkl. > Ersatzteile für 10 Jahre lieferfähig halten? "Will" eigentlich nicht, aber bisher waren auch 25 Jahre kein Problem, Kunden mögen das ;) Das ist mal ein klarer Fall von "früher war alles besser".
:
Bearbeitet durch User
Frank K. schrieb: >> 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.
:
Bearbeitet durch User
Bauform B. schrieb: > jetzt habe ich einen Compiler, der root-Rechte > braucht und /usr/bin/mount als root aufruft :) WTF oder was sagt man > dazu? Was macht ein Kommandozeilen-Compiler mit "mount"???
:
Bearbeitet durch User
(prx) A. K. schrieb: > Was macht ein Kommandozeilen-Compiler mit "mount"??? Ja wirklich WTF? Das hat mich jetzt auch neugierig gemacht.
Bauform B. schrieb: > Aber z.B. ((fallthrough)) (in eckigen Klammern) kennt er garnicht Das ist ja meiner Erinnerung nach auch ein C23-Feature (wie alle diese Attribute).
Oliver S. schrieb: > Bauform B. schrieb: >> Mahlzeit! >> >> gibt es uC, die man heute und in 10 Jahren auch noch kaufen kann? > > 8051 Überschrift gelesen? Mir war nicht klar, dass die mittlerweile 32bittig wären …
:
Bearbeitet durch Moderator
(prx) A. K. schrieb: > 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 :)
1 | # strace -u xc32 -f -o /tmp/xl2 ./xclm -status |
2 | # grep '\/bin\/sh' /tmp/xl2 |
3 | 5573 execve("/bin/sh", ["sh", "-c", "mount"], 0x7ffd357a5260 /* 14 vars */ <unfinished ...>
|
4 | 5575 execve("/bin/sh", ["sh", "-c", "ls \"/srv/license/\" 2>/dev/null"], 0x7ffd357a5260 /* 14 vars */ <unfinished ...>
|
und zum Beispiel
1 | ioctl(3, SIOCGIFNAME, {ifr_ifindex=0}) = -1 ENODEV (No such device)
|
2 | ioctl(3, SIOCGIFNAME, {ifr_ifindex=1, ifr_name="lo"}) = 0
|
3 | ioctl(3, SIOCGIFHWADDR, {ifr_name="lo", ifr_hwaddr={sa_family=ARPHRD_LOOPBACK, sa_data=00:00:00:00:00:00}}) = 0
|
4 | ioctl(3, SIOCGIFNAME, {ifr_ifindex=2, ifr_name="eth0"}) = 0
|
5 | ioctl(3, SIOCGIFHWADDR, {ifr_name="eth0", ifr_hwaddr={sa_family=ARPHRD_ETHER, sa_data=80:ee:73:f5:6b:9b}}) = 0
|
6 | ioctl(3, SIOCGIFNAME, {ifr_ifindex=3}) = -1 ENODEV (No such device)
|
7 | ### 5000 Versuche bis ### |
8 | ioctl(3, SIOCGIFNAME, {ifr_ifindex=4999}) = -1 ENODEV (No such device)
|
oder
1 | # strings ./xclm | grep mount |
2 | %u byte%s of memory at %p too small for even 1 mount point |
3 | Error carving up %u bytes of memory at %p for mount points |
4 | mount |
5 | Error opening pipe from 'mount': %s |
6 | Line from 'mount' truncated - result may be bogus |
7 | mount [%s] no match |
8 | mount [%s] found {%.*s}
|
9 | Error carving out %u-character string for mount point %u |
10 | No candidate mount found |
11 | {%lu}before enumerate_mountpoints
|
12 | {%lu}after enumerate_mountpoints
|
13 | _check_rehost(): Wrong amount of data in hostid |
14 | Number of redirects hit maximum amount |
15 | sysfs not mounted |
Bauform B. schrieb: > Der xclm baut wohl aus /proc/self/mountinfo und diversen anderen Daten > die hostid zusammen. Ach du grüne Neune! Also jedesmal, wenn du da noch einen USB-Stick dran hast, bekommst du eine andere HostID?
Jörg W. schrieb: > Bauform B. schrieb: >> 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.
Bauform B. schrieb: >> 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.
Jörg W. schrieb: > Ach du grüne Neune! Also jedesmal, wenn du da noch einen USB-Stick dran > hast, bekommst du eine andere HostID? Na, das dann doch nicht. In der kostenlosen Version funktionieren Compiler und Assembler wohl auch ohne root-Rechte, das sieht dann so aus:
1 | lcd-cg.c |
2 | XCLM: Failed to elevate privilege - is the XCLM binary setuid-root? |
3 | In file included from lcd-cg.c:4: |
4 | ../include/ansi.h:19:16: warning: padding struct to align 'p0' [-Wpadded] |
5 | uint16_t p0; |
6 | ^~ |
7 | XCLM: Failed to elevate privilege - is the XCLM binary setuid-root? |
Wenn xclm ein Link auf /bin/true ist, bekommt man immer noch object files, nur die Fehlermeldungen werden etwas abschreckender
1 | lcd-cg.c |
2 | cc1: warning: Detected corrupt executable file |
3 | cc1: note: Please reinstall the compiler |
4 | In file included from lcd-cg.c:4: |
5 | ../include/ansi.h:19:16: warning: padding struct to align 'p0' [-Wpadded] |
6 | uint16_t p0; |
7 | ^~ |
8 | cc1: warning: Detected corrupt executable file |
9 | cc1: note: Please reinstall the compiler |
Vielleicht musst du ja einen etwas intelligenteren Ersatz für xclm erbauen. ;-)
Bauform B. schrieb: > 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.
Bauform B. schrieb: > 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. fchk
Jörg W. schrieb: > Vielleicht musst du ja einen etwas intelligenteren Ersatz für xclm > erbauen. ;-) Nicht ganz richtig. Die Binaries enthalten einen SHA oder MD5 Hash des XCLM Binaries. Das muss man überall umpatchen. fchk
Frank K. schrieb: > Die Binaries enthalten einen SHA oder MD5 Hash des XCLM Binaries. MD5 sollte machbar sein. ;-) https://de.wikipedia.org/wiki/Message-Digest_Algorithm_5#Kollisionsangriffe
Bauform B. schrieb > 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. Jörg
Joerg W. schrieb: >> 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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.