Moin, da STM wohl noch auf längere Sicht kaum lieferfähig ist, suchen wir für neue Projekte nach Alternativen. Mir fallen da die im Betreff genannten MCUs auf. MC scheint erheblich verfügbarer zu sein als STM. Der Softwerker wünscht sich vollständige GCC Unterstützung mit IDE seiner Wahl statt MC IDE. Wer hat Erfahrung mit der Familie und kann über Pros / Cons berichten? Welche Alternativen gäbe es noch, wenn es mindesten M0+ und ein großer, überlebensfähiger Hersteller, kein Exot, kein China, lange Verfügbarkeit und momentaner Verfügbarkeit ein soll? Was die können muß? Schwer zu sagen. So viel wie möglich in max TQFP32 / QFN48 Größe ohne BGA und fine Pitch QFN. Lieber leistungsmäßig oversized und dafür universell einsetzbar.
Moin Moin, ich hatte mal ein Spaß-Projekt mit dem SAMD5 angefangen (https://github.com/TorstenRobitzki/DevPort) und bin dabei auf keine unüberwindlichen Hindernisse gestoßen. Das Projekt nutzt CMake/GCC und setzt keine Hersteller spezifische Version von Eclipse vorraus. Das herunterladen / befreien der Peripheral-Header war (soweit ich mich erinnere) etwas lästig, aber nicht unmöglich. schöne Grüße Torsten
Wir haben anstatt M0+ wieder vermehrt schnelle 8051 im Einsatz. Allerdings sind da aktuell hauptsächlich nur QFN lieferbar. Debugger entweder ein Eval-Board mit J-Link oder ein J-Link Base: https://www.mouser.de/c/?q=efm8bb3 https://www.silabs.com/development-tools/mcu/8-bit/slstk2022a-efm8bb3-starter-kit https://www.segger.com/products/debug-probes/j-link/models/model-overview/
Lothar schrieb: > schnelle 8051 ARM wurde entschieden, da dort die Verwandschaft zu den größeren (Linux) Systemen gegeben ist.
Die EFM gibt es auch mit M0+ oder M33 meist aber mit überdimensionierter Peripherie. Du müsstest hier schauen was passt: https://www.silabs.com/mcu/32-bit-microcontrollers Und dann hier was lieferbar ist z.B. QFN https://www.mouser.de/c/?q=efm32PG https://www.mouser.de/c/?q=EFM32HG Max M. schrieb: > ARM wurde entschieden, da dort die Verwandschaft zu den größeren (Linux) > Systemen gegeben ist Also ein Linux ARM Cortex-A ist deutlich anders zu programmieren als die uC Cortex-M z.B. die Interrupts und auch die Peripherie ist ganz anders.
Lothar schrieb: > deutlich anders zu programmieren Ist nicht auf meinem Mist gewachsen. Ich finde die AVR32DA vollkommen ausreichend.
Max M. schrieb: > AVR32DA Die DA haben doch so viele Bugs dass sofort die DB nachgeschoben werden mussten :-) Ausserdem gibt es noch immer kein offizielles Arduino dafür oder? Stattdessen haben sie den ATMega4809 genommen der zuerst einen DAC haben sollte und nun doch keinen hat ...
Max M. schrieb: > Wer hat Erfahrung mit der Familie und kann über Pros / Cons berichten? Habe mit den M0+ nicht viel gemacht (beruflich dafür einiges mit SAM4E und SAME70 früher), fand die aber insgesamt gut verdaulich. Recht gut dokumentiert wie bei Atmel auch sonst üblich (wenn ich mich recht entsinne, auch wieder alles in einem Datenblatt pro MCU-Typ, wie auch schon bei den klassischen AVRs), im Gegensatz zu STM32 viele Peripherals 32-bittig durchgezogen (theoretisch könntest du also an einem Port auch 32-bittig parallele IO machen). Durch das Clock-System muss man aber erstmal durchsteigen lernen, zumal da teilweise auch mit Registerzeigern gearbeitet wird, d.h. in den Registern wählen je 3 Bit den "Generic clock generator" aus, auf den sich die anderen Einstellungen dieses Registers dann beziehen. Zuweilen habe ich da auch mal ein Atmel Studio angeworfen und mir mit ASF ein Demoprojekt generieren lassen. Das ASF ist zwar hoffnungslos mit Abstraktionsebenen überfrachtet, durch die dann keiner mehr durchblickt, aber man kann zumindest mal mit dem Debugger durchgucken, was sie dann in welchem Register tun und sich so seinen eigenen Code davon abgucken.
> Also ein Linux ARM Cortex-A ist deutlich anders zu programmieren als die > uC Cortex-M z.B. die Interrupts und auch die Peripherie ist ganz anders. Dieses angebliche Verwandschaftsgelaber hab ich auch schon oft gehoert. Dabei programmiert man doch ueblicherweise in C, es ist dann doch vollkommen egal was da letztlich fuer ein Core druntersteckt wenn die Rechenleistung ausreichend ist. Andererseits wenn man auf denselben Core eines anderen Herstellers umsteigt hat man immer eine ganz andere Peripherie und damit immer den grossen Aufwasch bis alles wieder laeuft. Olaf
Olaf schrieb: > programmiert man doch ueblicherweise in C, > es ist dann doch vollkommen egal Cortex-M schafft auch in C unauffindbare Hardfault https://interrupt.memfault.com/blog/cortex-m-fault-debug
Olaf schrieb: > Dabei programmiert man doch ueblicherweise in C, > es ist dann doch vollkommen egal was da letztlich fuer ein > Core druntersteckt Nicht ganz. Cortex-A arbeitet üblicherweise mit "richtigem" (meist auch virtual memory) Betriebssystem, d.h. das API ist dann etwas Posix-artiges. Peripherie ist durch Gerätedateien abstrahiert, in aller Regel hat einem diese Arbeit auch schon jemand abgenommen. Cortex-M benutzt man dagegen "bare metal" oder mit irgendeinem RTOS, API eine Nummer kleiner als bei Posix, Peripherie muss man oft genug auch selbst abstrahieren (wenn man nicht auf solche Dinger wie hier ASF zurück greifen will). Die Programmiersprache selbst spielt dabei eher die kleinere Rolle. Lothar schrieb: > Cortex-M schafft auch in C unauffindbare Hardfault Wobei sich die Ursache manch eines bus errors oder segmentation faults in einem Posix-artigen System kaum leichter finden lässt als die eines hard faults auf einem Cortex-M. Die Atmel (von denen ist das Design, auch wenn jetzt Microchip dran steht) Cortex-M0+ haben einen micro trace buffer, der einem für solche Fälle ganz nützlich sein kann, denn damit kann man die execution history vor dem Fault nachvollziehen. Ist besser als ein Coredump unter Unix, denn der enthält nicht die History sondern nur den kaputten Zustand.
Jörg W. schrieb: > Cortex-A arbeitet üblicherweise mit "richtigem" (meist auch > virtual memory) Betriebssystem RTOS auf dem 8051 - Banking als MMU für Arme :-) https://github.com/contiki-os/contiki/wiki/8051-Code-Banking
Lothar schrieb: > Jörg W. schrieb: >> Cortex-A arbeitet üblicherweise mit "richtigem" (meist auch >> virtual memory) Betriebssystem > > RTOS auf dem 8051 Ja, man konnte auch mit dem Trabant mit Caravan dran von der DDR bis Bulgarien fahren … (wirklich welche gesehen dort). Es ging hier aber nicht um Dinosaurier, sondern um die typischen Unterschiede in der Benutzung zwischen Cortex A und M.
Lothar schrieb: > RTOS auf dem 8051 - Banking als MMU für Arme :-) Ich hatte mich beim 8051 auch sehr angestrengt, mehr als 64kB Flash zu verbrauchen, um banken zu dürfen. Es ist mir aber nicht gelungen. Es hat immer alles bequem in die ersten 64kB gepaßt. Den AT89C51RE2 hatte ich nur wegen der 8kB SRAM gebraucht. Er hatte den P89C668 abgelöst, beide sind aber schon lange nicht mehr verfügbar.
Lothar schrieb: > sofort die DB nachgeschoben Auch eine wertvolle Info. Ich programmiere die Systeme nicht, ich mache nur die HW. Und da liegt der Hase im Pfeffer, weil ich nur Vorschläge machen kann und je näher ich mich an die Vorgaben des Softwerkers annähere, um so wahrscheinlicher das ich noch in endlicher Zeit eine neue MCU mit Zukukunftspotential für neue Projekte entschieden bekomme. Da in dieser Beauftragungssituation eine strikte HW / SW Teilung besteht, schlage ich vor, treffe aber nicht die Entscheidung. Silabs ist klein, fabless und m.E. ein Übernahmekandidat. Daher sind die raus. Infineon und TI sind aus anderen Gründen raus. Renesas, Holtek, Novoton und die aufstrebenden China Firmen sind auch unbeliebt hier. M.E. ist alles raus das zu klein ist sich bei Börsengang von ARM ein fettes Stück vom Kuchen zu holen, um die Lizenzkostenerhöhungen steuern und abfedern zu können. Denn die neuen Eigentümer werden sich Ihre Investitionen ganz direkt wiederholen indem ARM Lizenznehmer gemolken werden. Es sei denn, die Lizenznehmer sind die Eigentümer. Wer das nicht kann, wird Federn lassen und auf längere Sicht muss man dann wieder wechseln. STM wäre der Sympatheiträger weil EU Unternehmen, aber denen fehlt es seit >10J an Rentabilität im Vergleich zu den anderen und selbst die Kapazitäten der Fabs die noch in Planung sind, sind bereits ausverkauft. MC würde ich gerne nehmen, brauche aber Argumente. NXP ist noch nicht gefaller. Wie sieht es denn da aus mit Verfügbarkeit und leistungsfähigen MCUs in der SAMD / SAML Liga?
Max M. schrieb: > leistungsfähigen MCUs in der SAMD / SAML Liga? (Verfügbarkeit hab' ich keine Ahnung, was aktuell da ist) SAMD/SAML sind ja eher die kleinen Teile bei Atmel/Microchip, nicht unbedingt die Rennautos. SAME/SAMV sind dort die größeren. Die sind taktfrequenzmäßig meiner Erinnerung nach ein bisschen langsamer als die vergleichbaren STMs, aber eher unwesentlich. Die restlichen Features nehmen sich m.E. nicht viel. In meinem damaligen Job hatten wir neben den schon genannten SAM4E und SAME70 die gleiche Software auf Kundenwunsch auch noch auf STM32F4xx und STM32F7xx laufen, insofern habe ich da beides mal gesehen. Am Ende benutzt man für eine Anwendung von der riesigen Peripherie meist eh nur einen Bruchteil. Was ich bei STM32 sehr gewöhnungsbedürftig fand, war deren Gruppierung der Extern-Interrupts: Bitnummern im Port statt jeweils einen Port zusammen, wie es sonst eher üblich ist. Dazu dann noch "nach oben zu" ein Zusammenfassen von mehreren Bitnummern zu einer Gruppe. Aber das ist vielleicht auch Geschmackssache.
Jörg W. schrieb: > SAMD/SAML sind ja eher die kleinen Teile bei Atmel/Microchip Die sollen bei uns in die Jahre gekommene AVRs und einen nicht verfügbaren STM M0+ ersetzen. Für alles wo die neuen MCUs reinwandern werden die derzeit völlig übertrieben sein. Vereinfacht bei den geringen Stückzahlen Lagerhaltung und Programmierung. Die Stückkosten der MCU spielen kaum eine Rolle. Baugröße, lötfreundliche, zuverlässige FPs aber schon, weil die auch in sehr kompakte und in stark belastete Geräte wandern. Jörg W. schrieb: > Am Ende > benutzt man für eine Anwendung von der riesigen Peripherie meist eh nur > einen Bruchteil. Man weiß vorher nur oft nicht welchen Teil. Haben ist besser als brauchen.
Ich musste letztens auch mal einen ATSAMD20 programmieren. Bisher hatte ich nur mit Arms von NXP und STM zu tun. Ich fand die ATSAMD irgendwie in der Zeit sehen geblieben, so aus dem letzten Jahrtausend. Beim FW-Upload kann ich das bei NXP und STM einfach über irgendeinen USB-Port machen. Bei Microchip mußte ich dann noch einen ICE-Programmer in der richtigen Version kaufen, bei dem man die Kabel eigentlich immer in die falsche Buchse steckt, der Platinenstecker war nicht drehsicher. Alles bei MC wirkte altbackener. Und der Support bei MC ist sehr störrisch. Wir brauchten nur die originale Firmware für den einen Chip. Die bekommt man aber von MC nicht, sondern nur den Sourcecode. Also muss man sich ein Devboard und den Programmer kaufen, um die Beispiel-Anwendung zu kompilieren. Ohne eine einzige Zeile zu ändern. Meine Erfahrungen mit STM sind da wesentlich besser.
Max M. schrieb: > Baugröße, lötfreundliche, zuverlässige FPs aber schon, weil die auch in > sehr kompakte und in stark belastete Geräte wandern. Wir haben die auch nur in TQFP verbaut, Kunden teilweise aber auch QFNs. Bezüglich Lieferengpässen der jeweiligen Gehäuse müsstest du halt mal gucken. Prinzipiell könnte man vermutlich sogar Platinen bauen, auf die sowohl QFN als auch TQFP passen, um so bei Lieferengpässen von TQFP auf QFN gehen zu können und zumindest überhaupt lieferfähig zu bleiben.
PittyJ schrieb: > Bei Microchip mußte ich dann noch einen ICE-Programmer in der richtigen > Version kaufen, Richtige Version? Was gibt's denn beim Atmel-ICE da an "Versionen"? Ich habe das Atmel-ICE am Ende auch für die STMs (der Kundenboards) benutzt, weil ich es weniger störrisch fand als die ST-Lösung. Aber da das eh alles SWD ist, kannst du das auch andersrum machen, wenn du willst: der ST-Programmer kann auch die SAMD oder SAME programmieren. Natürlich wird sich die jeweilige Herstellersoftware weigern, das mit den Chips des anderen Herstellers zu tun, aber der TE wollte sicher sowieso nicht irgendwelche "Studios" anwerfen zum Flashen. OpenOCD zumindest kann das alles. (Wer das nicht mag, kann auch jederzeit einen Segger dafür nehmen.) > bei dem man die Kabel eigentlich immer in die falsche > Buchse steckt, der Platinenstecker war nicht drehsicher. Die Stecker haben doch Nasen. Wenn man es idiotensicher haben will, muss man auf der Platine halt Wannenstecker montieren. Das Einzige, was beim Atmel-ICE wackelig war, waren die 10-Pin-Kabel. Das liegt aber eher daran, dass Cortex-M einen Stecker mit 1,27 mm Rastermaß genormt hat und sich Atmel dran gehalten hat: in die kleinen Flachbandkabel passen dann nur noch wenige Drähte in die Litze, die ziemlich schnell brechen. Auf unser Nachfolgedesign haben wir dann gleich einen FT2232 als Onboard-Debugger gepackt (aber naja, das geht aktuell gar nicht, weil man die gerade nirgends kaufen kann). Bei den SAMD weiß ich gerade nicht, SAME/SAMV hat ebenfalls einen ROM-Bootloader, der über USB oder UART benutzbar ist – wenn man auf sowas steht. Ich bin Softwareentwickler und habe daher eh immer einen Debugport für den Emulator haben wollen, insofern hat mich der Bootloader nie vom Hocker gerissen. Was wir stattdessen vereinzelt benutzt haben, war ein selbst geschriebener Bootloader, der von SD-Karte lesen kann, denn damit konnte man dem Kunde auf einfache Weise einen Firmwareupgrade zusenden, den er ohne irgendwelche externen Tools einspielen kann.
PittyJ schrieb: > Beim FW-Upload kann ich das bei NXP und STM einfach über irgendeinen > USB-Port machen. Bei Microchip mußte ich dann noch einen ICE-Programmer > in der richtigen Version kaufen, bei dem man die Kabel eigentlich immer > in die falsche Buchse steckt, der Platinenstecker war nicht drehsicher. Das wäre für uns kein Kriterium. Sind eh eigene Bootloader und USB nutzen wie nicht in dieser Art Geräte. Einen ICE oder J-Link würde ich auf jeden Fall kaufen, weil man über USB/Uart nicht vernünftig debuggen kann. Wir nutzen eigene ISP Stecker, also ist das Verdrehproblem gelöst. > Die bekommt man aber von MC > nicht, sondern nur den Sourcecode. Na das würde ich nicht als Nachteil sehen. Normalerweise bekommt man nur das Compilat und kann eben garnichts ändern. > Also muss man sich ein Devboard und > den Programmer kaufen, um die Beispiel-Anwendung zu kompilieren. Wozu das Dev Board? Den Programmer hättet ihr in jedem Fall gebraucht, um den SAM zu programmieren. ich weiß das es da unterschiedliche Ansichten gibt, gerade bei den 'richtigen' Programmierern. Ich als HW Friggler mit seichten Programmierkenntnissen kann allerdings nicht verstehen warum man freiwillig auf extrem leistungsfähige HW Debugger verzichtet. Du hast recht, MC hat seine Eigenarten, die Website ist eine Frechheit, das MAPS Tool ist nur zu finden wenn man weiß das es das gibt, die DBs haben die alles entscheidende Info auf S.578 in Fliesstext und einiges sieht etwas altbacken aus. An der darstellung habe die echten Nachholbedarf. Aber MC ist sehr freigiebig mit Code, DBs, Applikationen und baut m.E. schon sehr lange sehr innovative HW in seine MCUs. Ich mag MC. MC hat noch nie den Hörer auf die Gabel geworfen weil ich nicht 50.000 Stk kaufen wollte, sondern nur das DB für meine popeligen 20Stk. MC verkauft in geringsten Stückzahlen direkt an mich, programmiert die Teile ab Werk für einen lächerlichen Betrag und gurtet die danach auf Rolle. Das ist schon ganz große Klasse und da verzeihe ich denen ein paar Schwächen. Silabs, Dialog, Infineon sind da völlig anders drauf. Ich habe bei Vitesse noch ein NDA für ein DB unterschreiben müssen und habe dann genau ein DB bekommen, das ich nicht mal an einen Geschäftspartner weitergeben konnte ohne mit einem Bein im Knast zu stehen. Kaum hat MC Vitesse übernommen sprudeln geradezu Netzwerk Switche aus dem Laden mit DBs. Applikationen, Software etc. pp. Alles frei, alles für Lau. 'Nehmt es, baut Geräte damit und macht Umsatz!' SO sollte ein Chip Hersteller aggieren.
Eine nette Alternative zum ICE ist Mplab Snap. Der kann die diversen Programmier- und Debugvarianten der AVRs (ISP, debugwire, JTAG und PDI), kennt aber auch SWD und JTAG für die SAMD-ARMe - und PICs kann man damit auch bemachen. Schön ist, daß das Teil einen Steckverbinder im 0.1"-Raster verwendet, so daß man sich die nötigen Adapter problemlos selbst stricken kann, statt wie beim ICE auf 0.05"-Pfostenverbinderchen angewiesen zu sein. https://www.microchip.com/en-us/development-tool/PG164100
Ich habe in einigen Projekten SAM4S8B benutzt. Bis auf die merkwürdigee I2C Peripherie, die man nur mit DMA sinnvoll nutzen kann bin ich damit gut zurecht gekommen. In meinen Anwendungen wird auch der interne Flash als "EEPROM" misbraucht, bisher leben die noch alle. Firmware erstelle ich mit eigener Buildumgebung auf Basis GCC, als IDE benutze ich im Moment Visual Code. Debugging über openocd oder Lauterbach Trace 32. Das Teil hat auch nen eingebautes ITM/DWT mit dem man die CPU tracen kann.
DerEgon schrieb: > statt wie beim ICE auf 0.05"-Pfostenverbinderchen angewiesen zu sein Wie gesagt: da darfst du dich bei ARM beklagen. Die Stecker im 1,27er Raster sind deren Norm/Empfehlung (für Cortex-M), Atmel hat sich nur dran gehalten. Vom Platzbedarf her finde ich die inzwischen auch besser als das grobschlächtige Zeug (was beim 20poligen dann auch noch sackweise Pins für GND verplempert), wenn nur nicht die fragilen Kabelchen wären.
Beitrag #7111811 wurde von einem Moderator gelöscht.
DerEgon schrieb: > Eine nette Alternative zum ICE ist Mplab Snap mag ich nicht. Die Software ist sehr frech, ich konnte mich mit dem PIC nicht verbinden und die SW behauptet ich hätte was bei den Power Einstellungen falsch gemacht und müsse das erst beheben. Habe ich nichts verstellt und ging auch nicht weil auf der Seite keine Einstellungen waren. Es war dann ein falsch eingestellter Prozessor. Dann noch in der Hilfe nach der Belegung des Anschlusses beim Snap gesucht und gefunden. 'die Belegung ist genauso wie bei Adapter XY, guck da nach'. Ja hallo? Stattdessen die Belegung da anzuzeigen wäre genauso viel Aufwand gewesen.
Max M. schrieb: > M.E. ist alles raus das zu klein ist sich bei Börsengang von ARM ein > fettes Stück vom Kuchen zu holen, um die Lizenzkostenerhöhungen steuern > und abfedern zu können. Denn die neuen Eigentümer werden sich Ihre > Investitionen ganz direkt wiederholen indem ARM Lizenznehmer gemolken > werden. Es sei denn, die Lizenznehmer sind die Eigentümer. > Wer das nicht kann, wird Federn lassen und auf längere Sicht muss man > dann wieder wechseln. Dann schau nach RISC-V. Aktuell ist das noch stark von China geprägt. In ein paar Jahren wird jeder namenhafter Hersteller solche µC haben. Max M. schrieb: > Welche Alternativen gäbe es noch, wenn es mindesten M0+ und ein großer, > überlebensfähiger Hersteller, kein Exot, kein China, lange Verfügbarkeit > und momentaner Verfügbarkeit ein soll? Also nicht China, etablierte Chips die jeder will mit langer Verfügbarkeit und das ganze aktuell gut lieferbar? Somit bleibt eine leere Menge übrig. Max M. schrieb: > MC hat noch nie den Hörer auf die Gabel geworfen weil ich nicht 50.000 > Stk kaufen wollte, sondern nur das DB für meine popeligen 20Stk. Dann kauf ein reel von einem überdimensionierten Chip den du bei vielen Projekten verwenden kannst. Realistisch kaufst du jetzt halt Taiwan oder China. In ein paar Jahren wechselt du zurück zu westlichen Herstellern sobald diese RISC-V anbieten und zuverlässig liefern können. Aktuell (gefühlt) herrscht bei einigen Herstellern eine verdammt schädliche Mentalität, die nur funktioniert wegen der Knappheit. Ansonsten würden denen die Kunden weglaufen wenn kommentarlos zich mal der Liefertermin rumgeschoben wird und nebenbei an der Preisschraube gedreht wird.
DerEgon schrieb: > Mplab Snap Klingt interessant. Ich habe den Überblick verloren welcher MC Programmer noch was kann, weil MPlab gefühlt alle paar Monate einen neuen raushaut und dafür die teuer gekauften alten auslaufen. Mein AVRone ist EOL, der ICD2 auch schon lange, der ice kann nur was mal Atmel war und ist wohl auch bald weg, zwei mitlerweile nutzlose PicKit 'x' liegen auch noch im Schrank. Nun also der MPlab Snap. Mit dem Snap ist man auf MPlab X festgelegt, vermute ich? Ist denn beim MPlab X die Transfomation zu kompletter Atmel unterstützung abgeschlossen? Was sind dann die Gründe noch das Studio zu pflegen?
Max schrieb: > Dann kauf ein reel von einem überdimensionierten Chip den du bei vielen > Projekten verwenden kannst. Das ist der Plan. Aber ein Reel sind nicht 50.000 und 50.000 MCUs für 3-4€ hinzulegen ist nicht darstellbar. Max schrieb: > Also nicht China, etablierte Chips die jeder will mit langer > Verfügbarkeit und das ganze aktuell gut lieferbar? > Somit bleibt eine leere Menge übrig. Die SAMD / L sind m.e. genau was ich suche. Etabliert, großer Hersteller der bekannt dafür ist auch älteste MCUs noch zu liefern, nicht China. Ob die jeder will ist mir völlig egal. Das MC fast 100% in eigenen Fabs produziert gefällt mir auch. Ich habe nur keine Erfahrung mit den SAM und Anforderungen die ich nicht bewerten kann und will. Daher meine Frage hier. Max schrieb: > RISC-V Ich brauche die Chips jetzt. Nicht in 3-8 Jahren. Der Core ist das eine, aber die HW und die Toolchains dazu müssen auch was taugen ohne sich noch 12mal zu verändern bis sich das stabilisiert. Und irgendwelches China Gelump kann und will ich nicht nehmen. Ich hab da nichts von wenn im DB steht was ich hören will aber ich mich auf nichts davon verlassen kann oder ein mit googel aus dem kantonesisch übersetztes DB bekomme. Wir müssen 10J liefern können und jede Bauteilveränderung zieht eine Rezertifizierung für fantastsiche Summen nach sich.
Max M. schrieb: > Silabs ist klein, fabless und m.E. ein Übernahmekandidat. > Daher sind die raus. Grade war doch ARM selbst Übernahmekandidat :-) Ich denke eher geht Microchip Pleite, mit ihren ganzen unrentablen Altlasten, als dass es die Silabs Chips nicht mehr gibt, dann eben vom Übernehmer. Und Renesas musste mal von den Kunden gerettet werden: https://www.n-tv.de/wirtschaft/Renesas-steht-vor-Rettung-article9606071.html
Lothar schrieb: > Ich denke eher geht Microchip Pleite, mit ihren ganzen unrentablen > Altlasten MC: Umsatz wie STM. Jedes Jahr 3stellig (Mio) als Gewinn. STM krampft um die schwarze Null rum. Jahr für Jahr für Jahr. Silabs ist ein Fabless Zwerg im Vergleich zu beiden und hat sich 2021 gerade erst wieder Geld besorgt durch den Verkauf einer Sparte an Skyworks. MC hat keine Kosten durch die ollen Chips. MC produziert weit mehr als MCUs und nutzt seine alten FABs dafür. Wenn ein Kunde wirklich mal was altes zu einem horrenden Preis will, legen die das eben mal wieder auf.
Max M. schrieb: > Wenn ein Kunde wirklich mal was altes zu einem horrenden Preis will, > legen die das eben mal wieder auf. Geht natürlich auch nur begrenzt, ohne dabei selbst neue (massive) Kosten für eine Technologieanpassung zu haben (bspw. für den Umstieg auf größere Scheiben).
Max M. schrieb: > Lothar schrieb: >> Ich denke eher geht Microchip Pleite, mit ihren ganzen unrentablen >> Altlasten > > MC: Umsatz wie STM. > Jedes Jahr 3stellig (Mio) als Gewinn. > STM krampft um die schwarze Null rum. Jahr für Jahr für Jahr. > > Silabs ist ein Fabless Zwerg im Vergleich zu beiden und hat sich 2021 > gerade erst wieder Geld besorgt durch den Verkauf einer Sparte an > Skyworks. > > MC hat keine Kosten durch die ollen Chips. > MC produziert weit mehr als MCUs und nutzt seine alten FABs dafür. > Wenn ein Kunde wirklich mal was altes zu einem horrenden Preis will, > legen die das eben mal wieder auf. Das wäre ein Grund Microchip Aktien zu kaufen und nicht STM Aktien. Die Dividendenrendite war bei MC auch besser. Aber zum Entwickeln finde ich die STM Umgebung angenehmer als die von Microchip. Meine subjektiven, persönlichen Erfahrungen.
Max M. schrieb: > Mit dem Snap ist man auf MPlab X festgelegt, vermute ich? Nein, zum Glück nicht, der funktioniert auch mit dem, was früher "Atmel Studio" hieß.
Max M. schrieb: > PittyJ schrieb: >> Beim FW-Upload kann ich das bei NXP und STM einfach über irgendeinen >> USB-Port machen. Bei Microchip mußte ich dann noch einen ICE-Programmer >> in der richtigen Version kaufen, bei dem man die Kabel eigentlich immer >> in die falsche Buchse steckt, der Platinenstecker war nicht drehsicher. > Das wäre für uns kein Kriterium. > Sind eh eigene Bootloader und USB nutzen wie nicht in dieser Art Geräte. > Einen ICE oder J-Link würde ich auf jeden Fall kaufen, weil man über > USB/Uart nicht vernünftig debuggen kann. > Wir nutzen eigene ISP Stecker, also ist das Verdrehproblem gelöst. > Bei mir ist der STM ein Slave zu einem Raspi-artigen Mastercontroller: 4fach CortexA mit Linux. Der 'Raspi' kann über einen GPIO-Pin den STM in den Bootmode ziehen, und dann kann der 'Raspi' ganz einfach über USB eine neue Firmware auf den STM aufspielen. Ganz einfach, alles mit Bordmittel. Das geht im laufenden Betrieb beim Kunden. Das könnte ich nicht mit einem ICE Programmer machen. Das dfu-util Programm fürs ist sogar über apt-get in Linux verfügbar.
PittyJ schrieb: > Aber zum Entwickeln finde ich die STM Umgebung angenehmer als die von > Microchip. Da seine Softwarker eh den GCC als Bedingung gestellt haben, werden sie keinen Pfifferling auf diese Art von herstellerspezifischen Entwicklungsumgebungen geben, sondern lieber ihr Zeug selbst stricken. Haben wir damals auch so getan, am Ende waren wir bei platform.io angekommen, das hat prima funktioniert – und wenn man mal einen anderen Hersteller braucht, muss man nicht gleich alles über den Haufen werfen.
Jörg W. schrieb: > Technologieanpassung Ich vermute das ist dann auch der einzige Grund für MC mal was abzukündigen. Aber solange die alten Fabs Halbleiter mit gröberen Strukturbreiten bauen, laufen die so weiter und schieben hin und wieder mal einen 16C505 zwischen, den man immer noch kaufen kann. Wie alt ist der jetzt? PittyJ schrieb: > Das könnte ich nicht mit einem ICE Programmer machen. Die Programmierschnittstelle ist definiert. Man muss keinen ICE nehmen. Man kann sich das auch selbst stricken. Mit eigenem Bootloader kann man dann beliebige Wege wählen. Wir machen FW Updates über den RS485 Master, ohne die Geräte anzufassen.
Jörg W. schrieb: > PittyJ schrieb: >> Aber zum Entwickeln finde ich die STM Umgebung angenehmer als die von >> Microchip. > > Da seine Softwarker eh den GCC als Bedingung gestellt haben, werden sie > keinen Pfifferling auf diese Art von herstellerspezifischen > Entwicklungsumgebungen geben, sondern lieber ihr Zeug selbst stricken. > Haben wir damals auch so getan, am Ende waren wir bei platform.io > angekommen, das hat prima funktioniert – und wenn man mal einen anderen > Hersteller braucht, muss man nicht gleich alles über den Haufen werfen. Ich verwende auch einen gcc, mit eigenen Makefiles für den STM. Mit Umgebung bezeichne ich die Tools wie ein angepasstes FreeRtos, oder APIs wie die HAL, die mir einiges an Arbeit abnehmen. Und das fand ich bei STM besser.
PittyJ schrieb: > APIs wie die HAL, Fand ich ähnlich verwurschtelt wie ASF, als ich mal reingeschaut hatte. Ist aber schon 'ne Weile her, so sehr erinnere ich mich auch gerade nicht an Details. Max M. schrieb: > Aber solange die alten Fabs Halbleiter mit gröberen Strukturbreiten > bauen, Breitere Strukturen als das Minimum kannst du immer bauen, aber wenn du die Dinger auf eine neue Scheibengröße bringen musst, weil die Fab mit der alten Größe keiner mehr (rentabel) braucht, hast du schon Aufwand damit. Auch die AVRs wurden und werden ja in eher grobschlächtigen Strukturen gefertigt, und dennoch (mittlerweile) bei TSMC. Das stört die dort nicht weiter, ob man in die Breite einer Leiterbahn auch hätte 5 packen können. :)
Max M. schrieb: > MC produziert weit mehr als MCUs und nutzt seine alten FABs dafür. > Wenn ein Kunde wirklich mal was altes zu einem horrenden Preis will, > legen die das eben mal wieder auf. Warum können sie dann aktuell keine ATMEGA2560 herstellen und bremsen alle SPS Hersteller aus: https://www.mouser.de/c/?q=atmega2560
Lothar schrieb: > Warum können sie dann aktuell keine ATMEGA2560 herstellen Erwartest du jetzt ernsthaft eine Antwort aus dem Forum da drauf? Oder wolltest du nur einen fremden Thread kapern, um dich über deine Probleme auszuk*en?
Lothar schrieb: > alle SPS Hersteller Alle SPS verwenden diese MCUs? Eigene Fabs bedeutet ja nicht das man die so mit 30% Auslastung rumdümpeln hat für alle Fälle. Die sind voll ausgelastet und 'mal eben' kann man sowas auch nicht in der Spätschicht fertigen. Mir eigenen Fabs kann man wenigstens noch umdisponieren. Mit 100% Fremdfertigung steht man hinten in der Schlange. Schon an der Preisgestaltung des mega2560 sehe ich das MC die Kunden 'motivieren' will auf neue Produkte umzusatteln. Wenn Jörg recht hat das die AVR mittlerweile bei TSMC laufen, ist die Frage ja beantwortet.
Jörg W. schrieb: > Erwartest du jetzt ernsthaft eine Antwort aus dem Forum da drauf? Am Anfang ging es darum wer lieferfähiger als STM ist. Das sollte Microchip sein - ist es aber nicht bzw. nur teilweise. Silabs kann liefern, haben aber keine eigenen Fabs, müssen also rechtzeiig irgendwo gebucht haben. NXP kann auch noch teilweise liefern. Weiss nicht ob die noch eigene Fabs haben.
Max M. schrieb: > Wenn Jörg recht hat das die AVR mittlerweile bei TSMC laufen, ist die > Frage ja beantwortet. Atmel hatte am Ende alle seine Fabs außer Colorado Springs verkauft. Dort wurden meines Wissens nie AVRs gefertigt. Ich glaube, die kamen davor aus Rousset. Das Schicksal der dortigen Fab unter LFoundry kann man in Wikipedia nachlesen, und die da beschriebene 30%ige Kürzung der Atmel-Aufträge dürfte dem Technologietransfer vieler AVRs zu TSMC geschuldet sein. Wie das jetzt mit den aktuellen AVR-Produkten aussieht, die dann bereits unter Microchip rausgekommen sind, hab' ich keine Ahnung.
PittyJ schrieb: > Ich musste letztens auch mal einen ATSAMD20 programmieren. Bisher hatte > ich nur mit Arms von NXP und STM zu tun. > Ich fand die ATSAMD irgendwie in der Zeit sehen geblieben, so aus dem > letzten Jahrtausend. > Beim FW-Upload kann ich das bei NXP und STM einfach über irgendeinen > USB-Port machen. Tja, die ATSAMD20 haben gar keinen USB, das wären die ATSAMD21, ATSAMDA1 oder ATSAML21. Die haben aber auch keinen ROM Bootloader. Die ATSAMDA1G16B nutze ich gerade für mein LIN Interface: https://github.com/RudolphRiedel/USB_LIN Aber der einzige Vorteil bisher ist das die Teile gerade zu bekommen waren. Die haben mit 64kiB FLASH und 8kiB SRAM etwas wenig Speicher und eigentlich keinen Support für LIN. Eine Platine habe ich mit einem ATSAMD21G18A bestückt, davon hatte ich aber nur zwei und der hat "nur" mehr Speicher". Ich würde gerne bei den ATSAMD51 oder ATSAME51 bleiben, die sind aber vielleicht erst Ende nächsten Jahres zu bekommen. Und da gibt es leider keine 48 Pin Version in TQFP. Erwähnenswert wären noch die ATSAMC20/ATSAMC21, zu bekommen sind die aber auch nicht. Die zu den ATSAMC20 praktisch baugleichen PIC32CM bekommt man allerdings noch, vermutlich weil die einfach keiner kennt. Für mein CAN-Interface bin ich gerade auf Gigadevice gekommen. Genauer den GD32C103CBT6. Denn JLCPCB hat einiges an GD Controllern im Lager und kann die folglich direkt bestücken. Die ersten Platinen habe ich da und die GD32C103CBT6 haben auch einen USB DFU ROM Bootloader, aber so richtig überzeugen tut mich der Chip noch nicht. Aber der Spatz in der Hand und die Taube auf dem Dach und so...
Rudolph R. schrieb: > Die haben mit 64kiB FLASH und 8kiB SRAM etwas wenig Speicher und > eigentlich keinen Support für LIN 8051 mit CAN/LIN und 128k sind lieferbar und CAN/LIN Demo ist mit dabei: https://www.mouser.de/ProductDetail/Silicon-Labs/C8051F582-IM?qs=sXzyty3v6jpf1bkGIm%252B%2FuQ%3D%3D https://www.mouser.de/ProductDetail/Silicon-Labs/C8051F582-IQ?qs=sXzyty3v6jpuSq%2FeVNaROQ%3D%3D
Lothar schrieb: > 8051 mit CAN/LIN und 128k sind lieferbar und CAN/LIN Demo ist mit dabei: Ja schön, aber keinen USB und auch nur 8kiB SRAM. Und der CAN kann nur 2.0 - also Classic. Mal davon ab das ich ganz sicher keinen 8051 mehr anfassen werde, oder irgendeinen anderen Controller mit Akkummulator Architektur. Und was Silabs angeht, ich habe hier noch ein PG22 Dev Kit liegen das ich noch nicht benutzen konnte, da ich noch nicht eingesehen habe mir dafür extra einen Account bei Silabs anzulegen. Und der EFM32 ist wenigstens ein Cortex M33.
Rudolph R. schrieb: > Ja schön, aber keinen USB Automotive Anwendung mit USB?? > PG22 ... ist wenigstens ein Cortex M33 Hat aber kein CAN/LIN und ist derzeit nur begrenzt lieferbar. Vom 8051 > 10k Stück > Controller mit Akkummulator Architektur Davon bekommst Du doch in C nichts mit. Ist aber dennoch schnell wie hier getestet: "powers through with brute force ... simply overwhelms other parts" https://jaycarlson.net/pf/silicon-labs-efm8/
Lothar schrieb: > Rudolph R. schrieb: >> Ja schön, aber keinen USB > > Automotive Anwendung mit USB?? Warum nicht? Die ATSAME51 gibt es mit CAN-FD und USB in Automotive Varianten, genau wie E7x/V7x. Und plus Ethernet als ATSAME54. Ich habe aber USB/CAN-FD und USB/LIN Interfaces und die nutze ich zum Testen von Automotive Steuergeräten. https://github.com/RudolphRiedel/USB_LIN https://github.com/RudolphRiedel/USB_CAN-FD Nur tja, Teile bekommen und so. >> PG22 ... ist wenigstens ein Cortex M33 > > Hat aber kein CAN/LIN und ist derzeit nur begrenzt lieferbar. Wie ich schrieb: "was Silabs angeht", das hat überhaupt nichts mit den anderen Controllern zu tun. > Vom 8051 > 10k Stück >> Controller mit Akkummulator Architektur > > Davon bekommst Du doch in C nichts mit. Ist aber dennoch schnell wie > hier getestet: > > "powers through with brute force ... simply overwhelms other parts" > > https://jaycarlson.net/pf/silicon-labs-efm8/ Äh, prima, der EFM8 hängt also 8-Bit Controller ab, weil der zwar viele Taktzyklen braucht, dafür aber einen hohen Takt hat, ganz toll.
Rudolph R. schrieb: > Mal davon ab das ich ganz sicher keinen 8051 mehr anfassen werde, Als 2009 niemand liefern konnte, habe ich einen 8051 von Silabs genommen. Der war okay. Der dazugehörige Keil amokte als man an den 2K Free Bereich kratzte, aber der SDCC hats dann gebracht. Ich will nicht bestreiten das die Silabs Teile durchaus einen guten Job machen. Aber hier sind die eben raus, weil das so entschieden wurde. Das Ziel ist ARM, mindestens M0+ und am liebsten M4. Der M23 liegt da irgendwo zwischen. Ob man die Power wirklich braucht ist nicht die Frage. Da wissen wir das wir die derzeit nicht nutzen. Das auch MC da nur eingeschränkt lieferfähig ist, ist richtig. Aber eingeschränkt ist besser als so gut wie garnicht lieferfähig. Schon damals beim Silabs 8051 hätte ich sehr gerne mehr Leistung gehabt. Ich musste 4 x PWM mit min 100Hz Wiederholrate machen. Da der nur 3HW PWM hat war das ein riesen gekrampfe das mit handoptimierten PDM Code flacker und Glitchfrei hinzubekommen und dabei noch Softdimming und Farbortausgleich zu machen. Mehr als 10bit Auflösung ging nicht. Das war eigentlich etwas knapp und wurde nur mit Diskussionen durchgewunken. Mit einer übergroßen MCU kann man auch mal fehlende HW in SW machen. Vor allem baut unser Softwerker die ganz großen Systeme bis runter zu den Winzlingen. Der hat einfach keinen Bock auf die jeweiligen Besonderheiten Rücksicht nehmen zu müssen und mit Toolchains für 3 Familien zu jonglieren. Wie gut z.B. der Bootloader Bereich tatsächlich vom Applikationsbereich getrennt ist, wer da wen überschreiben kann, Speichercheck, failsafe Clock etc. pp., da kocht doch jeder seine eigene Suppe. Und Silabs hat sich mal als störrischer und verschlossener Laden gezeigt, der nicht bereit war uns wenigstens Datenblätter für Chips zu geben die wir kaufen konnten. Ein schicker Feature Flyer, um zu zeigen welchen geilen Scheiß WIR nicht von denen bekommen. Mehr nicht. Der Support wäre zu anstrengend für die kleinen Stückzahlen. Dabei hätten wir auf Support verzichtet, jedes NDA unterschrieben nur um diese Chips verwenden zu können. Das vergesse ich Silabs nicht und auf so einen Laden baue ich nicht eine Produktpalette auf. Schlimmer sind nur noch Broadcom und Qualcom. Klar, die Chips gibt es. Würde man sogar kaufen können beim Broker. Und jede windige China Klitsche scheint auch an FW, Tools, DB, Applikationsschriften und Support zu kommen. Aber wir nicht. Solche Läden muss man weiträumig umgehen wo möglich. Vielen Dank für die zahlreichen Erfahrungsberichte und den angenehmen Ton. Damit kann ich schon was anfangen.
Max M. schrieb: > Der dazugehörige Keil amokte als man an den 2K Free > Bereich kratzte Der ist doch schon lange umsonst: https://community.silabs.com/s/question/0D51M00007xeFg3SAE/free-unlimited-keil-pk51-for-8bit-silicon-labs-mcus?language=en_US > Ich musste 4 x PWM mit min 100Hz Wiederholrate machen Das muss der 6-Kanal PCA in Hardware können, keine Programmierung erforderlich. Die EFM8 haben zudem ein integriertes CPLD das sollte auch dafür gehen: https://www.silabs.com/documents/public/training/mcu/efm8-lb1-clu.pdf
Lothar schrieb: > Das muss der 6-Kanal PCA in Hardware können, keine Programmierung > erforderlich. Schön das Du weißt welches 8051 Teil ich damals verwendet habe. Selbst ich müsste da nachforschen. Irgendwas mit kleiner 4x4mm Kantenlänge im QFN war das Limit. Und frei ist der Keil offenbar seid 2013 und das nur für Silabs 8051 MCUs, mit Registrierung und Produktkey. Was hat mir das 2009 genutzt? Und was nutzt mir das heute, wenn GCC und ARM Cortex M gesetzt ist? Der 8051 ist so alt, da habe ich als Lehrling kleine Systeme gebaut. Egal für was wir uns entscheiden werden, es wird etwas sein das nicht noch erheblich älter ist als die ollen AVR, die wir hauptsächlich ersetzen wollen. Und es wird nicht Silabs. Diese beiden Dinge kann ich mit absoluter Sicherheit so sagen.
Max M. schrieb: > Der 8051 ist so alt Schon klar dass es bei Euch kein 8051 wird, also nur zur Info, der ARM1 kam 1985 und der 8051 kam nur kurz vorher, sind also beide so gleich alt, der AVR kam 1994 und ist viel neuer :-) Ich hatte 1987 den ARM2 und den 8051 hatte ich erstmals 2010 von NXP, davor noch nie von 8051 gehört, und den ersten Silabs 8051 EFM8 in 2015 :-)
Lothar schrieb: > er ARM1 > kam 1985 und der 8051 Seit dem ARM1 ist einiges passiert bis zum M23. Einfach aus Interesse wäre das sicher ganz interessant wie sich ein 72Mhz EFM8 Laser Bee mit 8bit 8051 (Harvard) gegen einen 48Mhz SAMD (M0+, von Neumann) und gegen einen 48Mhz SAML (M23, Harvard, hardware division) schlägt. Für den EFM8 laut Silabs: 70% der Befehle in 1-2 Taktzyklen. Die Cortexe haben natürlich 4fache bitbreite, Cache, branch prediction etc. pp. Der 8051 hat eine Architektur die zwar schön in ASM zu programmieren ist, die aber durch den Accu ständig Register umladen muss. Schlecht optimierter Code, keine unterstützende Hardware. Wegen des simplen Designs eben höher zu takten. Gerade das DB zur Laser Bee Familie überfolgen. Ist das wirklich so das der EFM8 nur einen fix und fertig vorprogrammierten Bootloader hat, den ich nicht ändern kann? Self programming NUR vom Silabs Bootloader aus? Kein EEprom? 4K XRAM über DPTR .... Stack im 256Byte IRam. Oha, da kommen jetzt mehr und mehr Erinerungen hoch. Ja, war mal nett, als ich vom 8085 kam. Aber 2022 lassen wir den 8051 mal in Frieden ruhen.
Max M. schrieb: > EFM8 nur einen fix und fertig vorprogrammierten Bootloader Im Simplicity Studio ist der Bootloader Source Code. Den kann man ändern, Security Page ab 0xFA00 entsperren, neuen Bootloader schreiben, natürlich nur mit einem Silabs J-Link, kostet 30 EUR https://www.silabs.com/development-tools/mcu/8-bit/slstk2030a-efm8lb-starter-kit EEPROM Emulation im Flash EFM8LB1 macht SAMD21 platt: https://jaycarlson.net/microcontrollers/ Hast Du gesehen dass der 14-bit 1 MHz ADC DMA nach XRAM hat? > Seit dem ARM1 ist einiges passiert bis zum M23 Leider nicht nur Positives. Die Cortex-M hätten das Interruptschema der Cortex-A behalten sollen.
Lothar schrieb: > natürlich nur mit einem Silabs J-Link Was soll daran "natürlich" sein? Dass war nichtmal bei Atmels AVRs "natürlich", alle Informationen über das Programmier-Interface hatten sie von Anfang an offen gelegt. Nur das Debug-Interface wurde als privat betrachtet. Bei Cortex-M ist "natürlich" komplett alles offen gelegt, und man kann problemlos die Tools des einen Herstellers auch für den Cortex-M eines anderen benutzen. "Natürlich" nicht die jeweiligen IDEs.
Jörg W. schrieb: > Bei Cortex-M ist "natürlich" komplett alles offen gelegt Bei Silabs ist auch alles offen gelegt, es gibt sogar einen Debug Firmware Sourcecode, ausserdem ist C2 fast gleich SWD https://www.silabs.com/documents/public/application-notes/AN127.pdf Es ist nur so dass erst mal fast niemand einen Debugger braucht, da Bootloader, gab es bei den ganz alten AVR ja auch mal, bis Atmel seine MK2 verkaufen wollte. Und jetzt gibt es den Arduino Bootloader. Und wenn Debugger gibt es wie gesagt den Silabs J-Link für 30 EUR. Da bastelt keiner selbst was, es sei denn aus Spass: https://hackaday.io/project/14950-silabs-efm8-programmer Der Profi wird dennoch den J-Link Base kaufen, weil der halt alle ARM und die Silabs 8051 unterstützt: https://www.segger.com/products/debug-probes/j-link/models/model-overview/ Atmel ICE ist im Vergleich völlig überteuert.
Lothar schrieb: > Es ist nur so dass erst mal fast niemand einen Debugger braucht, da > Bootloader, Ich weiß nicht, wie du Software entwickelst. Ich war jedenfalls immer sehr froh, nicht nur ein Programmierwerkzeug sondern einen Emulator zu haben. > gab es bei den ganz alten AVR ja auch mal, bis Atmel seine > MK2 verkaufen wollte. Humbug. ROM-Bootloader hatten nur wenige AVRs (und gerade die "ganz alten" überhaupt nicht), aber mit "seinem MK2" (welcher auch immer das jetzt ist) hat das rein gar nichts zu tun. Ein paar USB-Teile hatten einen Bootloader von vornherein drin, die größeren Cortexe auch. > Der Profi wird dennoch den J-Link Base kaufen, weil der halt alle ARM > und die Silabs 8051 unterstützt: Der Profi nimmt u.U. ganz andere Tools. Habe dienstlich (also professionell) gerade mit NXP-Teilen zu tun, bei denen auch J-Link nur so unsupported mitgeführt ist, weil sie ansonsten auf Lauterbach setzen. Wenn du deren Preise hörst (im Netz lesen kannst du die nicht), solltest du dich vorher gut festhalten. > Atmel ICE ist im Vergleich völlig überteuert. Auch erst seit der Übernahme durch Microchip. Die wollen das Zeug offenbar ausphasen.
Ich hätte noch schreiben sollen, bei Silabs gibt es den Bootloader UART, SPI, I2C, CAN, LIN, USB, Ethernet, und das Debug Interface C2. Einen offiziellen "Programmer" gibt es nicht. Flashen über Bootloader heisst bei Silabs ISP und flashen über das Debug Interface C2 ICP Beim AVR wäre also vergleichbar über Bootloader FLIP ISP, über SPI ICP, was Atmel aber ISP nennt, und über Debug Interface debugWIRE eben Debug.
Lothar schrieb: > https://jaycarlson.net/microcontrollers/ Wow, was für ein unübersichtliche wall of text. Gestestet wurde eher die Kombination Toolchain + MCU. > EFM8LB1 macht SAMD21 platt: Wo liest Du das? Beim Biquad filter pulverisiert der SAMD den EFM8. 19fach(!) mehr samples /sec. Der Tiny ist mit 20Mhz nur knapp langsamer als der EFM8 mit 72Mhz 🤣 Bit Toggling ist nicht vergleichbar weil Cycles statt freq. angegeben werden. Trotzdem ist der SAM schneller. 3cyc statt 8cyc beim efm8. Selbst der 1,5fache Takt holt das bei weitem nicht raus. ISR Latenz weiß ich nicht was er dem SAM angetan hat das der 391 Cycles Latenz hat. Speicherbedarf: Wie unglaublich überraschend das ein 32bit RISC einen höheren Speicherbedarf hat als ein 8bit CISC. Wertung: >SAM D10: Killer performance & peripherals, but with runtime library hiccups Naja, 5J sind seitdem vergangen und wenn es drauf ankommt nimmt man eben keine lib die es nicht bringt. >the SAM D10 was the most efficient part tested when running at full speed. nice >The EFM8 was the fastest 8-bit part in my round-up Naja, schnell für einen 8bitter. Der zweitschnellste war ein Exoten STC8 mit 30Mhz der sonst ziemlich schlecht war. Jeder der Speed braucht nimmt eben keine 8bitter aus 1980 auf Steroiden, der von hinten durch die Brust ins Auge auf sein XRAM Speicher zugreifen muss. Das beste was er über den 'silly' Keil erzählen konnte, war das Silbas den recht effektiv in der IDE versteckt. Ich sehe einen pulverisierten EFM8 und einen SAMD der sich sehr gut geschlagen hat. Und ich tendiere ja eher zum SAML mit M23 ARM V8 Core. Also alles gut, ich gönn Dir den EFM8 und wenn man 8051 mag, den speed und die modernen Features nicht braucht, dann ist der ganz schick. Aber Dinge die Dir selbstverständlich erscheinen, erscheinen mir nicht hinnehmbar. Jetzt suchen wir was neues für die nächsten Jahre und die Anforderungen werden steigen. Der EFM ist schnell für einen 8051 aber nur durch den hohen Takt schnell für einen 8bitter.
Jörg W. schrieb: > NXP-Teilen zu tun, bei denen auch J-Link nur > so unsupported mitgeführt ist Bei den NXP Philips LPC ist J-Link üblich. Es gibt sogar eine kostenlose Firmware für die LPC Debugger. Du meinst wahrscheinlich die zugekauften Motorola Kinetis? https://www.segger.com/products/debug-probes/j-link/models/other-j-links/lpc-link-2/
Max M. schrieb: > ich gönn Dir den EFM8 Wie schon geschrieben, wir setzen eigentlich hauptsächlich NXP LPC ARM ein. Aber schau mal auf die Lieferzeiten. Deswegen kommt jetzt seit letzter Woche erstmal der C8051F580 CAN/LIN zum Einsatz, sind halt 10k Stück lieferbar. Die EFM8 kommen dort zum Einsatz, wo es wenig Rechenleistung, aber viel analoge Peripherie braucht. Der EFM8LB1 heisst ja Laser Bee, weil eigentlich mal für Glasfaser Repeater entwickelt, daher der dicke ADC und 4x DAC. Und kostet 1.50 EUR. Was kostet denn wohl ein vergleichbarer ARM, wenn lieferbar?
Lothar schrieb: > Du meinst wahrscheinlich die zugekauften Motorola Kinetis? Nein. Die Dinger, die wir da haben, sind Cortex-M33 und von NXP, aber proprietär. Außer einem product flyer gibt's dafür alles nur unter NDA.
Jörg W. schrieb: > Cortex-M33 und von NXP, aber proprietär Da kann ich dann nicht mitreden, wir kaufen nur was im Angebot ist :-)
Lothar schrieb: > schau mal auf die Lieferzeiten. Deswegen kommt jetzt seit > letzter Woche erstmal der C8051F580 CAN/LIN zum Einsatz Erstmal. Weil es nichts anderes gibt. Nicht weil ihr wollt. Lothar schrieb: > kostet 1.50 EUR. Was kostet denn wohl ein vergleichbarer > ARM, wenn lieferbar? Bei uns kein Thema. Kleine Stückzahlen, sehr speziell, sehr teuer. Entwicklerzeit ist was uns fehlt. SAML10/11 (Pinkompatibel) sind in 1000er Stückzahlen lagernd lieferbar. So um 3€. Aber schöne Diskussion. Wenn das so weitergeht mit dem Markt, unterhalten wir uns bald darüber welche China Gurken MCU aus irgendeiner Hinterhofklitsche, die am wenigsten schreckliche ist und erinnern uns wehmütig daran wie schön das war als man die efm8 noch hätte kaufen können. 😉
Max M. schrieb: > China Gurken MCU aus irgendeiner Hinterhofklitsche Wir haben schon die hier evaluiert, 8051 mit Bootloader, funktionieren soweit :-) https://www.richis-lab.de/CH55x.htm
Lothar schrieb: > Wir haben anstatt M0+ wieder vermehrt schnelle 8051 im Einsatz. Einen GCC gibt es für die halt nicht. Von der Unterstützung der C-Standards kann man Keil vergessen, SDCC (und eventuell IAR) mögen da inzwischen ganz gut sein (und SDCC lässt sich auch mit verschiedenen IDE nutzen), aber wenn man wirklich GCC-spezifische Erweiterungen will, reicht das auch nicht. Falls ST STM8 liefern kann, wäre das noch etwas zwischen 8051 und ARM: Da ist der SDCC nochmal deutlich besser (da die Architektur sich besser zu C eignet), und so ein STM8 ist dann üblicherweise auch deutlich schneller als ein 8051.
Max M. schrieb: > Philipp Klaus K. schrieb: >> STM8 > Hat STM den nicht beerdigt? Ich habe die Lage die letzten 2 Jahre nicht mehr genau verfolgt, aber davor hatte ich den Eindruck, dass es innerhalb von ST verschiedene Bestrebungen gab. Einerseits erhielt ich von ST Mails, die zur Migration auf STM32 aufforderten. Und die ST-eigene IDE für STM8 wird schon seit langem nicht mehr weiterentwickelt. Andererseits hat ST danach nochmal neue STM8-Varianten (insbesondere 8-Pin STM8S und STM8L) herausgebracht, sowie neue Entwicklungsboards (einerseits für die 8-Pin-Varianten, andererseits Arduino-kompatible Boards). Bei Raisonance gab es zwischenzeitlich mal etwas Stillstand, aber inzwischen arbeiten anscheinend alle 4 Entwickler von Compilern für STM8 wieder aktiv an Verbesserungen, und veröffentlichen neue Versionen: http://www.colecovision.eu/stm8/compilers-2016-2018-2020-2022.shtml
Ich finde den STM8 auch ganz schick, habe aber auch lange nichts mehr mit denen gemacht. Für Low Cost Massenware würde ich tatsächlich die Padauk oder andere China MCUs ins Auge fassen, wenn ich dafür was neues suchen würde. Für uns ist M0+ und GCC als Minimumanforderung gesetzt. Ich warte jetzt ab was da entschieden wird.
>Wir haben anstatt M0+ wieder vermehrt schnelle 8051 im Einsatz. Wie weit muss man zurück fallen? Der 8051 ist grässlich! >Infineon und TI sind aus anderen Gründen raus. >Renesas, Holtek, Novoton und die aufstrebenden China Firmen sind auch >unbeliebt hier. Was hat Renesas mit chines. Firmen zu tun? Von Renesas gibt es einige Controller, die CM3 usw weit überlegen (!) sind. (auch sind dort die Datenblätter zusammenhänged nicht gestückelt geschrieben) >Ich finde den STM8 auch ganz schick, Ja fürs untere Ende ist der ziemlich schnell (viele Befehle in 1 Takt), und sehr günstig, z.T wenige ct. (aber werden glaubich nicht mehr weiter entwickelt)
:
Bearbeitet durch Moderator
MCUA schrieb: > Wie weit muss man zurück fallen? Der 8051 ist grässlich! Der C8051F580 CAN/LIN ist lieferbar und wir können fertigen. Der vorher eingesetzte LPC11C22 hat Lieferzeit 27-Jun-23 Der EFM8LB1 ADC/DAC ist lieferbar und wir können fertigen. Der vorher eingesetzte LPC845 hat Lieferzeit 04-Jul-23 Damit hat sich die Sache erledigt. Das LPC845 Evalboard hat übrigens jetzt 117 Wochen Lieferzeit. Hat wohl einer alle aufgekauft um die uC runter zu machen. Bei der 8051 Programmierung gibt es keine Probleme. Klar sollte man keine Funktion mit long Parametern machen, das ist aber beim AVR auch nicht gesund. Immerhin gibt es keinen Hardfault.
Lothar schrieb: > Immerhin gibt es keinen Hardfault. D.h. die CPU führt im Zweifelsfalle Unfug aus, statt in einen sicheren Zustand zu fallen. Ist ja nicht so, dass ein Hardfault irgendwas völlig Nutzloses wäre …
Lothar schrieb: > lieferbar und wir können fertigen Im Endeffekt das einzige das zählt. MCUA schrieb: > Der 8051 ist grässlich! Nö. Ist er nicht. In die Jahre gekommen aber der hält sich bis heute, weil er bis heute den Job erledigt. 8085, Z80, 6502 und viele, viele andere sind schon lange Geschichte. Also so gräßlich kann der dann nicht sein.
Die 8051-Speicher-Architekt. (auch bei 6502) ist grässlich. Das konnte man in den 70ern schon besser. (gut, immerhin besser als Nichts) (aber ich würde Schmerzensgeld verlangen den (nochmal) zu programmieren)
MCUA schrieb: > Das konnte man in den 70ern schon besser. Ich habe noch den 8085 für Industriesteuerungen beackert. Schau Dir den mal an und vergleiche mit 8051. Der 8051 hat den ersetzt und war eine Offenbarung an Kompfort und Integration. Welcher Controller hat das in den 70er besser gemacht? Vielleicht irgendeine CPU die sauteuer und riesig war und Händeweise ext Peripherie brauchte. Überhaupt nicht vergleichbar! Seit damals hat der 8051 viele Verbesserungen erfahren. Ja, der ist alt und abgehängt von den modernen MCUs. Aber das was er kann macht er gut, sonst wäre der schon lange verschwunden. Speicherintensive Operationen und Compute Power sind nicht sein Ding. Sinnlos den dafür zu nehmen und sich dann darüber zu mokieren das der das nicht gut kann. Für kleinere Dinge ist der aber immer noch eine gute MCU.
>Seit damals hat der 8051 viele Verbesserungen erfahren.
Nicht betr. Speicher-Architektur.
:
Bearbeitet durch Moderator
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.