Forum: Mikrocontroller und Digitale Elektronik Microchip SAMD (M0+) bzw. SAML10/11 (M23) Erfahrung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Max M. (prokrastinator)


Lesenswert?

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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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

von Lothar (Gast)


Lesenswert?

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/

von Max M. (prokrastinator)


Lesenswert?

Lothar schrieb:
> schnelle 8051
ARM wurde entschieden, da dort die Verwandschaft zu den größeren (Linux) 
Systemen gegeben ist.

von Lothar (Gast)


Lesenswert?

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.

von Max M. (prokrastinator)


Lesenswert?

Lothar schrieb:
> deutlich anders zu programmieren

Ist nicht auf meinem Mist gewachsen.
Ich finde die AVR32DA vollkommen ausreichend.

von Lothar (Gast)


Lesenswert?

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 ...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Olaf (Gast)


Lesenswert?

> 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

von Lothar (Gast)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Lothar (Gast)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Max M. (prokrastinator)


Lesenswert?

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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Max M. (prokrastinator)


Lesenswert?

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.

von PittyJ (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Max M. (prokrastinator)


Lesenswert?

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.

von DerEgon (Gast)


Lesenswert?

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

von Andreas M. (amesser)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.
von J. S. (jojos)


Lesenswert?

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.

von Max (Gast)


Lesenswert?

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.

von Max M. (prokrastinator)


Lesenswert?

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?

von Max M. (prokrastinator)


Lesenswert?

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.

von Lothar (Gast)


Lesenswert?

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

von Max M. (prokrastinator)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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).

von PittyJ (Gast)


Lesenswert?

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.

von DerEgon (Gast)


Lesenswert?

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ß.

von PittyJ (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Max M. (prokrastinator)


Lesenswert?

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.

von PittyJ (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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. :)

von Lothar (Gast)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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?

von Max M. (prokrastinator)


Lesenswert?

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.

von Lothar (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Rudolph R. (rudolph)


Lesenswert?

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...

von Lothar (Gast)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Lothar (Gast)


Lesenswert?

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/

von Rudolph R. (rudolph)


Lesenswert?

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.

von Max M. (prokrastinator)


Lesenswert?

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.

von Lothar (Gast)


Lesenswert?

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

von Max M. (prokrastinator)


Lesenswert?

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.

von Lothar (Gast)


Lesenswert?

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 
:-)

von Max M. (prokrastinator)


Lesenswert?

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.

von Lothar (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Lothar (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Lothar (Gast)


Lesenswert?

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.

von Max M. (prokrastinator)


Lesenswert?

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.

von Lothar (Gast)


Lesenswert?

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/

von Lothar (Gast)


Lesenswert?

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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Lothar (Gast)


Lesenswert?

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 :-)

von Max M. (prokrastinator)


Lesenswert?

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. 😉

von Lothar (Gast)


Lesenswert?

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

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Lesenswert?

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.

von Max M. (prokrastinator)


Lesenswert?

Philipp Klaus K. schrieb:
> STM8
Hat STM den nicht beerdigt?

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Lesenswert?

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

von Max M. (prokrastinator)


Lesenswert?

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.

von MCUA (Gast)


Lesenswert?

>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
von Lothar (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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 …

von Max M. (prokrastinator)


Lesenswert?

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.

von MCUA (Gast)


Lesenswert?

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)

von Max M. (prokrastinator)


Lesenswert?

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.

von MCUA (Gast)


Lesenswert?

>Seit damals hat der 8051 viele Verbesserungen erfahren.

Nicht betr. Speicher-Architektur.

: Bearbeitet durch Moderator

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.