Welche 8-Bit-Architekturen werden in 10 Jahren relevant sein?

[Philipp Klaus K. (pkk)]

Seit ein paar Monaten sind die STM8 NRND. Für die Rabbits gilt das schon 
etwas länger. Damit verlieren wir zwei meiner Meinung nach relativ 
elegante 8/16-Bit-Architekturen.

Welche 8-Bit oder 8/16-Bit Architekturen werden in 10 Jahren relevant 
sein?

Einerseits gibt es ein paar noch aktuelle. Da fallen mir ein:

* AVR
* PIC
* PDK
* HCS08
* MCS-51

Es könnten neue Architekturen auftauchen, aber das ist heute schwer 
abzuschätzen. Vermutlich gibt es aber noch ein paar weitere 8-Bit oder 
8/16-Bit-Architekturen, die heute wie in 10 Jahren noch relevant sind.

[F. M. (foxmulder)]

Philipp Klaus K. schrieb:
> AVR

In 10 Jahren sicher noch relevant, immerhin wurden jetzt gerade komplett 
neue Serien herausgebracht, sicher nicht zum Spaß.

[Stephan S. (uxdx)]

Philipp Klaus K. schrieb:
> * PIC

Die dürften auch in >10 Jahren noch relevant sein, sind in zahlreichen 
Geräten als Steuer-µC eingebaut

[Gerhard O. (gerhard_)]

Philipp Klaus K. schrieb:
> Seit ein paar Monaten sind die STM8 NRND. Für die Rabbits gilt das
> schon
> etwas länger. Damit verlieren wir zwei meiner Meinung nach relativ
> elegante 8/16-Bit-Architekturen.
>
> Welche 8-Bit oder 8/16-Bit Architekturen werden in 10 Jahren relevant
> sein?
>
> Einerseits gibt es ein paar noch aktuelle. Da fallen mir ein:
>
> * AVR
> * PIC
> * PDK
> * HCS08
> * MCS-51
>
> Es könnten neue Architekturen auftauchen, aber das ist heute schwer
> abzuschätzen. Vermutlich gibt es aber noch ein paar weitere 8-Bit oder
> 8/16-Bit-Architekturen, die heute wie in 10 Jahren noch relevant sind.

Frag mich in zehn Jahren:-)

Ich vermute es läuft eher auf eine Kostenfrage hinaus als auf eine 
Technologiefrage. Die meisten 8-Bitter kosten momentan meist mehr wie 
die modernen Shrinkköpfe a la Cortex. Es ist eine Frage des Marktes. 
Technisch gesehen wird es auch in 10 Jahren noch Vieles geben, das man 
mit einem 8-Bitter durchziehen könnte; aber wenn der 32-bit uC mit 
Geschmack des Monats eben nur einen Bruchteil kostet...

Donn kommt dazu, daß der Kunde bald oft nur noch KI befähigte und 
sprechende und hörende Gadgets haben will; da braucht man eben dann mehr 
Umpf als ein bescheidener, sonst ausreichender 8-Bitter, fähig ist, 
herzugeben. Das hat dann wieder mit dem Markt zu tun, zu bestimmen  was 
der Kunde betreiben soll. Man will ja mehr und mehr fähigere Technik mit 
natürlicher Sprache Fähigkeiten, um sie überall, wie in Startrek 
emuliert, herum haben. Als Beispiel sind mal viele der neuzeitlichen 
Automobile erwähnt. Da wird man das KI Zeugs zuerst finden. Einfache 
Sachen wollen bald nur noch die wenigsten Menschen und entzieht der 
8-Bit Welt zunehmend seine Existenzgrundlage.

Entwicklung kostet nur einmal. Die eingesparten Cents multiplizieren 
sich aber immer als fette Gewinne in den Echelons der Firmen.

Einfache Sachen, die ein 8-Bitter fundamental noch genauso gut erledigen 
könnte, will dann kaum noch einer haben wollen.

War eine schöne Zeit wo ein versteckter uC im VCR sofort erwachte, kein 
BS laden musste und ohne Wolkenunterstützung zügig funktionierte. Wenn 
man da vielen modernen Geräten zusieht, die sich langwierig beim 
Aufwecken plagen...

Es gibt Millionen Gründe und die haben alle mehr oder weniger mit der 
Kohle zu tun:-)

Der 8-Bitter ist tot. Es lebe der 8-Bitter!

[Peter D. (peda)]

Gerhard O. schrieb:
> Wenn
> man da vielen modernen Geräten zusieht, die sich langwierig beim
> Aufwecken plagen...

Meine Tante hat sich zu Telekom TV überreden lassen. Die Settop-Box 
startet dermaßen lahmarschig, daß sie sich entschieden hat, sie ständig 
angeschaltet zu lassen. Und der DSL-Router muß zum Telefonieren auch 
ständig Strom ziehen und wird ordentlich warm.
Viele moderne Geräte kann man nicht mehr einfach abschalten, verbrauchen 
also ständig Strom.

Ältere Leute kennen die Anheizzeit ja noch von Röhren-Radios und 
Röhren-TV.
Das wird von modernen Geräten meilenweit übertroffen.

[Fred R. (Firma: www.ramser-elektro.at/shop) (fred_ram)]

DSGV-Violator schrieb im Beitrag #7418572:
> Alle die nicht durch neuentwicklung ersetzt werden, da man sonst viel
> Testtiefe verliert. Die NASA bunkert immer mal wieder Alt-Prozessoren
> als Ersatzteile:
>
> https://www.heise.de/news/NASA-sucht-im-Internet-nach-uralten-Chips-59066.html

Suchte da das Militär nicht auch mal 486DX4 ?

Philipp Klaus K. schrieb:
> PIC

Schon sehr oft angetroffen. Alle möglichen Modelle.
Zwischen einen PIC12 und PIC18 liegen nochmals einige Welten.
Geschweige PIC24 oder PIC32.

[Arduino F. (Firma: Gast) (arduinof)]

Philipp Klaus K. schrieb:
> Welche 8-Bit oder 8/16-Bit Architekturen werden in 10 Jahren relevant
> sein?

Prognosen sind immer sehr schwierig!
Insbesondere, wenn sie die Zukunft betreffen.

[Jens H. (jensh22)]

Die Lottozahlen von übernächster Woche hätte ich, aber die 
Mikroelektronik in 10 Jahren übersteigt meine Weitsichtigkeit doch 
erheblich. Vielleicht nicht ganz, denn in DE wird dieses Thema schon 
vorher völlig irrelevant.

[M. K. (sylaina)]

Jens H. schrieb:
> Die Lottozahlen von übernächster Woche hätte ich

Würde ich nehmen, ich hab nur die von vor zwei Wochen :D

[Sebastian E. (der_andere_sebastian)]

Wenn man von der Vergangenheit auf die Zukunft schließen kann, dann auf 
jeden Fall MCS-51. Natürlich sind die betagt, und ein paar Dinge würde 
man heute sicher anders lösen was die Architektur angeht, aber 
inzwischen scheint das Design nicht mehr unter Schutz zu stehen, und 
viele Hersteller fertigen noch Controller auf dieser Basis. Selbst für 
die alten Versionen mit externem Speicher bekommt man noch Ersatz im 
Handumdrehen.
In der Zeit, in der es MCS-51 gab, sind diverse 8-bit Architekturen 
entstanden, über die heute keiner mehr redet. Aufgrund der weiten 
Verbreitung könnten allerdings AVR und PIC ähnlich langlebig sein.

[Rolf M. (rmagnus)]

Gerhard O. schrieb:
> Man will ja mehr und mehr fähigere Technik mit
> natürlicher Sprache Fähigkeiten, um sie überall, wie in Startrek
> emuliert, herum haben. Als Beispiel sind mal viele der neuzeitlichen
> Automobile erwähnt. Da wird man das KI Zeugs zuerst finden. Einfache
> Sachen wollen bald nur noch die wenigsten Menschen und entzieht der
> 8-Bit Welt zunehmend seine Existenzgrundlage.

Was du da erwähnst, ist schon länger nicht mehr die Aufgabe von µCs - 
schon gar nicht von 8-Bittern. Da sprechen wir eher von SOCs ähnlich wie 
im Handy, mit 3D-Beschleuniger, Betriebssystem, HD-Display und RAM im 
GB-Bereich. Allerdings sind in einem modernen Auto zusätzlich 
schätzungsweise deutlich mehr als 100 µCs verbaut, und bei einigen davon 
würde ein 8-Bitter noch locker reichen. Ob er sich dann kostenmäßig noch 
lohnt, ist die andere Frage.

> Einfache Sachen, die ein 8-Bitter fundamental noch genauso gut erledigen
> könnte, will dann kaum noch einer haben wollen.

Die gibt's immer noch. Irgendwelche Sensoren, die an ein Bussystem 
angebunden werden müssen, die Lüftersteuerung, das BMS oder ähnliche 
Dinge brauchen nicht mehr. Hier ist eher die Stückzahl ausschlaggebend, 
die bei den ARMen einfach im Vergleich riesig ist. Das drückt den Preis, 
und dann kann ein 32-Bitter ggf. auch an einer Stelle zum Einsatz 
kommen, wo es ein 8-Bitter auch locker getan hätte, einfach weil er 
billiger ist.

DSGV-Violator schrieb im Beitrag #7418572:
> Man mmuss schon ziemlich geistig unterbelichtete sein, wenn man wegen
> dem einen neuen Thread startet ...

Geht's inzwischen nicht mehr ohne Beleidigungen und persönliche 
Angriffe? Als was würdest du dich denn selbst bezeichnen, wenn du in 
einem solchen Thread mitdiskutierst?

Peter D. schrieb:
> Ältere Leute kennen die Anheizzeit ja noch von Röhren-Radios und
> Röhren-TV.
> Das wird von modernen Geräten meilenweit übertroffen.

Naja, die Fernseher haben früher vor der Einführung der 
Schnellstartröhren teilweise die Heizung ihrer Bildröhre auch bei 
ausgeschaltetem Gerät weiter bestromt, wenn auch mit weniger Leistung. 
Dadurch brauchten die Geräte zwar auch permanent Strom, aber das Bild 
ist beim Einschalten schneller erschienen. Ein Kaltstart konnten dann 
durchaus auch im Minutenbereich liegen. Von daher kein so schlechter 
Vergleich.

[Rainer W. (rawi)]

Gerhard O. schrieb:
> War eine schöne Zeit wo ein versteckter uC im VCR sofort erwachte, kein
> BS laden musste und ohne Wolkenunterstützung zügig funktionierte. Wenn
> man da vielen modernen Geräten zusieht, die sich langwierig beim
> Aufwecken plagen...

Das "sofort erwachen" war nur eine vorübergehende Phase. Früher (tm) 
brauchten die Radios eine Vorheizzeit, heute muss eine Streamingkiste 
erstmal booten und ihren Buffer füllen.
Damals ertönte der Gong der Tagesschau allerdings noch pünktlich.

[Andi M. (andi6510)]

Fuer mich wird in 10 Jahren ganz sicher der Commodore 64 noch relevant 
sein. So wie die letzten 40 Jahre. :-D

Allgemein wuerde ich behaupten, dass in 10 Jahren immer mal wieder was 
8-Bittiges gebraucht wird. Und sei es als controller fuer eine 
elektronisches Kuechenschere oder was man in 10 Jahren noch so alles mit 
controllern ausstatten will.
Da ausserdem niemand mehr ernsthaft eine neue 8-Bit Architektur 
entwickeln will, werden die jetzt etablierten Architekturen wohl immer 
und immer wieder in neuem Gewand auftauchen. So zumindest mein Tipp.

[Christoph Z. (rayelec)]

Andi M. schrieb:
> Da ausserdem niemand mehr ernsthaft eine neue 8-Bit Architektur
> entwickeln will, werden die jetzt etablierten Architekturen wohl immer
> und immer wieder in neuem Gewand auftauchen. So zumindest mein Tipp.

Die Geschichte spricht auf jeden Fall dafür. Z80, MCS-51, PIC, 6502 sind 
alles Entwicklungen aus den 70er Jahren und man kann sie allesamt noch 
heute kaufen!

[Wilhelm S. (wilhelmdk4tj)]

Christoph Z. schrieb:
> Die Geschichte spricht auf jeden Fall dafür. Z80, MCS-51, PIC, 6502 sind
> alles Entwicklungen aus den 70er Jahren und man kann sie allesamt noch
> heute kaufen!

Nicht nur kaufen, es werden wohl noch viele! sinnvolle! Dinge damit 
gemacht, sonst gäbe es sie nicht mehr.

73
Wilhelm

[Tilo R. (joey5337)]

M. K. schrieb:
> Jens H. schrieb:
>> Die Lottozahlen von übernächster Woche hätte ich
>
> Würde ich nehmen, ich hab nur die von vor zwei Wochen :D

einfach komplex konjugiert erweitern. Alternativ Laplace-Transformation.
Hilft immer.

[Tilo R. (joey5337)]

Rolf M. schrieb:
> Allerdings sind in einem modernen Auto zusätzlich
> schätzungsweise deutlich mehr als 100 µCs verbaut, und bei einigen davon
> würde ein 8-Bitter noch locker reichen. Ob er sich dann kostenmäßig noch
> lohnt, ist die andere Frage.

Zumindest im Automobilbereich sehe ich das Ende der 8-Bitter relativ 
schnell kommen, so es sie noch gibt.
Grund dafür sehe ich in der ISO/SAE 21434 mit dem Titel "Road vehicles – 
Cybersecurity engineering" und den dazugehörigen UNECE R155 und R156.
Da wird für alle Geräte ein Cyber-Security-Management-System verlangt, 
es müssen Bedrohungsanalysen durchgeführt und Produkte auf 
Schwachstellen hin beobachtet werden. Wenn man eine Schwachstelle 
findet, muss man ggf. patchen können. Und dafür muss man (mindestens) 
den Update-Pfad sicher bekommen. Und das schafft man nur mit 
kryptografischen Checksummen und Zertifikaten, wo sich die meisten 
8-Bitter schwer tun.

Vorerst halten die OEMs noch schützend die Hand über einige Zulieferer, 
machen die Bedrohungsanalyse selbst und übernehmen auch die 
Anforderungen des Management-Systems. Aber die Zulieferer sind angezählt 
und i. d. Regel schon extern auditiert worden. Wer von denen noch keine 
geeigneten Steuergeräte hat ist aktuell am entwickeln.

[Fritz G. (fritz65)]

In manchen sicherheitskritischen Bereichen (Medizintechnik, Luftfahrt, 
Militär) liegen die Lebens- und Innovationszyklen eher im Bereich von 
Jahrzehnten. Ein Wechsel auf eine neue Controllerfamilie zieht einen 
riesigen Rattenschwanz an Qualifizierungs - und Zulassungsmassnahmen 
nach sich. Zumindest für die laufende Produktion und den Ersatzteilmarkt 
wird es die kleinen Controller wohl noch längere Zeit geben.
Bei Neuentwicklungen wird es komplizierter. Vermutlich werden die 
„Dinosaurier mit Spatzenhirn“ wie Atmega2560 zuerst verschwinden, denn 
wer so viel Speicher braucht, wird gleich auf einer 32bit-Architektur 
einsteigen.
Eher eine Chance sehe ich bei kleinen Anwendungen ohne oder mit 
rudimentären Bedienerinterface, wie Taschenlampen, Kaffeemaschinen, 
Fieberthermometer etc. Auch hier dringt aber die Vernetzung immer weiter 
vor und der Anschluss an die Cloud bzw. die Smartphone App gelingt mit 
8bit ohne Zusatzhardware kaum. Letztendlich wird es dann vor allem von 
den Bauteilpreisen abhängen. Im Consumerbereich können einstellige 
Centbeträge entscheidend sein.
Allerdings habe ich schon in einer Zahnbürste einen 16bit MSP430 und in 
der Ladestation eines Saugroboters einen ARM Cortex gesehen.

[Lars F. (larsf)]

Zwei wichtige Punkte werden gern übersehen: 8-Bit Architekturen sind 
viel leichter zu überblicken und sie langen vielen Zwecken. Beides in 
Kombination dürfte sie auch in 30 Jahren noch attraktiv für viele und 
vieles machen. Die "Gefahr" droht da eher von völlig neuen 
Funktionsweisen, Stichwort KI.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

DSGV-Violator schrieb im Beitrag #7419174:
> Offtopic:
> wenn man hier anfängt einen einzelnen Beiträge mit der Begründung "Tut
> nichts zur Sache" zu löschen dann muß man konsequenterweise auch die
> anderen, auch eigene Beiträge löschen, die "nichts zur Sache tun".
Erledigt.

[Martin S. (mmaddin)]

Philipp Klaus K. schrieb:
> * AVR
> * PIC

...das sind doch Produktlinien und keine Architekturen, geht es nun 
darum welche Architektur oder welche Produktlinien "relevant" sein 
werden. Wobei auch "relevant" dehnbar ist, woran gemessen etc...

[Philipp Klaus K. (pkk)]

Martin S. schrieb:
> Philipp Klaus K. schrieb:
>> * AVR
>> * PIC
>
> ...das sind doch Produktlinien und keine Architekturen, geht es nun
> darum welche Architektur oder welche Produktlinien "relevant" sein
> werden. Wobei auch "relevant" dehnbar ist, woran gemessen etc...

Meines Wissens ist AVR eine µC-Familie, die eine eigene, und (abgesehen 
von den üblichen kleinen Unterschieden) einheitliche Architektur 
aufweist, und die Architektur wird üblicherweise ebenfalls als AVR oder 
avr bezeichnet.

Mit "PIC" meinte ich die 8-Bit PIC, also jene, die man oft mit PIC10 bis 
PIC18 bezeichnet. Diese Architekturen unterscheiden sich tatsächlich 
hinreichend voneinander, dass ich sie hätte einzeln aufführen können.

Das "relevant" war in der Tat unklar formuliert. Ich dachte bei 
"relevant" daran, dass auch außerhalb der Retrocomputing-Szene noch 
Software entwickelt wird, die auf diesen Architekturen laufen soll.

[DSGV-Violator (Gast)]

> Meines Wissens ist AVR eine µC-Familie, die eine eigene, und (abgesehen
> von den üblichen kleinen Unterschieden) einheitliche Architektur

Reichlich lückenhaft dieses sogenannte "Wissen".
Über die letzten 25+ Jahre sind 6(?) verschiedene Cores mit 
unterscheidbaren Befehlssatzarchitekturen unter dem Label AVR vermarktet 
worden.

Einfach mal die Comfortzone des bequemen Viertelwissens verlassen und in 
die Docs schauen (Auszug im Anhang).

[Philipp Klaus K. (pkk)]

DSGV-Violator schrieb:
>> Meines Wissens ist AVR eine µC-Familie, die eine eigene, und (abgesehen
>> von den üblichen kleinen Unterschieden) einheitliche Architektur
>
> Reichlich lückenhaft dieses sogenannte "Wissen".
> Über die letzten 25+ Jahre sind 6(?) verschiedene Cores mit
> unterscheidbaren Befehlssatzarchitekturen unter dem Label AVR vermarktet
> worden.
>
> Einfach mal die Comfortzone des bequemen Viertelwissens verlassen und in
> die Docs schauen (Auszug im Anhang).

Eine handvoll Befehle mehr oder weniger machen keine andere Architektur. 
Das sind nur die "üblichen kleinen Unterschiede" innerhalb einer 
Architektur. Da hat man z.B. immer noch ein einziges Compilerbackend für 
die Architektur (das dann abhängig von Optionen möglicherweise Code 
optimiert für die eine oder andere Variante generiert).

[Martin S. (mmaddin)]

Philipp Klaus K. schrieb:
> und die Architektur wird üblicherweise ebenfalls als AVR oder
> avr bezeichnet.

https://www.mikrocontroller.net/articles/Prozessorarchitekturen

Darum gehts doch eigentlich, oder eben gerade nicht, das war die Frage.

Und die andere Frage ist, was mit "relevant" gemeint ist. Relevant ist 
in dem Zusammenhand so aussagekräftig wie "Teuer" bei Autos...

[Rolf M. (rmagnus)]

DSGV-Violator schrieb:
> Reichlich lückenhaft dieses sogenannte "Wissen".
> Über die letzten 25+ Jahre sind 6(?) verschiedene Cores mit
> unterscheidbaren Befehlssatzarchitekturen unter dem Label AVR vermarktet
> worden.

Dann schau dir mal an, was sich bei x86 über die Jahrzehnte hinweg am 
Befehlssatz getan hat, oder gar bei ARM - oder so ziemlich jeder anderen 
Architektur. Dagegen sind die Unterschiede bei den AVRs winzig.

[H.Joachim S. (crazyhorse)]

Spannende Frage das Ganze :-)
Als "Zuarbeiter" wird es die meiner Meinung nach noch lange geben. 
Einfach weil es für vieles völlig ausreicht und auf ausgemusterten 
Fertigungsstrassen noch lange billig produziert werden kann. Wie die 
Preise am Markt aussehen hat mit den Fertigungskosten i.a. nicht viel zu 
tun, da bestimmen andere Faktoren die Preise.
Es gibt auch zunehmend scheinbar spezialisierte Chips, die sich bei 
genauerem hinsehen als ab Werk programmierte MCs erweisen.
Und ob wir eine immer weiter vernetzte Welt in allen Bereichen wirklich 
haben wollen steht auch noch nicht fest. Scheinbar ist das in Stein 
gemeisselt, aber irgendwann gibts zu allem auch eine Gegenbewegung - 
keine Ahnung wie das ausgeht. Vielleicht endet das Ganze auch völlig 
unfreiwillig, dann brauchen wir aber auch erst mal keine 8-Bitter mehr.

[(prx) A. K. (prx)]

H.Joachim S. schrieb:
> Als "Zuarbeiter" wird es die meiner Meinung nach noch lange geben.

Es soll ja sogar noch 4-Bitter geben. Einzig der 1-Bitter MC14500B war 
eine 1-Tags-Fliege - oder gibts sogar sowas noch in Produkten?

[Andrea B. (stromteam)]

Wird der CDP1802 immernoch in der Luft- und Raumfahrt eingesetzt?

[Irgend W. (Firma: egal) (irgendwer)]

Rolf M. schrieb:
> ... Das drückt den Preis,
> und dann kann ein 32-Bitter ggf. auch an einer Stelle zum Einsatz
> kommen, wo es ein 8-Bitter auch locker getan hätte, einfach weil er
> billiger ist.

Die Aussage "es hätte auch eine 8-Bit getan" interessiert schon lange 
nicht mehr. Die eigentliche Frage lautet: "langt auch ein billigerer 
Chip?"

Wobei sich das "Billiger" sich sowohl auf die Hardware mal Stückzahl als 
auch auf den Entwicklungsaufwand (gerade bei niedrigeren Stückzahlen 
interessant).  Krampfhaftes 8-Bit Assembler gemurkse weil der Speicher 
so knapp ist oder Klick-Klack Software Generatoren auf der anderen Seite 
weil der genau Ressourcenverbrauch keine Mehrkosten verursacht. Was ist 
da wohl billiger?

Bei Neuentwicklungen stellt sich, meiner Meinung nach, die Frage nach 
8-Bit schon lange nicht mehr. Die Zeiten wo die mal die billigsten waren 
sind lange vorbei (auch wenn das durch die derzeitigen 
Lieferschwierigkeiten etwas verdeckt ist).

Das einzige was also noch bliebt sind ältere Entwicklungen wo eine 
Neuentwicklung einfach zu teuer ist weil da ggf. sehr aufwendige 
Zertifizierungen usw. notwendig sind. Aber irgendwann werden auch die 
"Verschwinden" weil sowieso neu entwickelt werden muss oder aber der 
Stückpreisunterschied so groß wird das sich eine Neuentwicklung lohnt.
Und wenn da dann mal einige Kunden wegfallen die derzeit noch größere 
Stückzahlen abnehmen, wird auch das Microchip-Museum mal anfangen müssen 
auszumisten. Alle anderen Hersteller sind da anscheinend schon kräftig 
damit beschäftigt. Spätesten wenn mal wieder eine derzeit verwendet 
Fertigungstechnologie "end of live" geht werden die Hersteller sehr 
genau nachrechnen ob sich eine Adaptierung auf was neueres überhaupt 
noch rentiert. Relevant sind hier Stückzahlen im Mio. Bereich und keine 
Bastler Einzelstücke - die interessieren die Hersteller nicht die Bohne.


Die Frage müsste daher eher lauten "welcher Chip wird in 10 Jahren der 
billigste am Markt sein?", nur der ist relevant! Und wenn das dann ein 
64-Bit Risc-V ist, wird halt der genommen um eine LED blinken zu 
lassen:-)

[Lars F. (larsf)]

Irgend W. schrieb:
> Die Frage müsste daher eher lauten "welcher Chip wird in 10 Jahren der
> billigste am Markt sein?", nur der ist relevant!

Das glaube ich eher weniger.
Alles dem Preis unterzuordnen wird ja den vielfältigen unterschiedlichen 
Ansprüchen an die verwendete Controller Architektur nicht gerecht. Im 
Markt sind zudem Faktoren wie Erhältlichkeit und Liefer-Zuverlässigkeit 
relevant. Im übrigen spielen die reinen Controller-Preise bei vielen 
Produkten eher die zweite Geige.

Irgend W. schrieb:
> Das einzige was also noch bliebt sind ältere Entwicklungen wo eine
> Neuentwicklung einfach zu teuer ist

8Bitter finden sich selbstverständlich weiter in aktuellen Produkten.
Die absoluten Produktionszahlen sind immer noch steigend und wären 
anders gar nicht erklärbar, sinkender 8Bit Marktanteil hin oder her. 
Also: Bitte kein vorschneller Abgesang.

Irgend W. schrieb:
> Aber irgendwann

Da sind wir uns dann einig. Irgendwann. Aber sicher nicht in 10 Jahren.

[DSGV-Violator (Gast)]

Martin S. schrieb:

> https://www.mikrocontroller.net/articles/Prozessorarchitekturen
>
> Darum gehts doch eigentlich, oder eben gerade nicht, das war die Frage.

Der TO will offensichtlich als "Fachmann" glänzen und knallt daher das 
Buzzword 'Architektur" hier komplett unverstanden und fehlplatziert in 
die Diskussion rein.
Eigentlich will er über die interne Registerbreite diskutieren, deshalb 
die Klassifizierung nach 8/16/32. Die Busbreite ist aber der Architektur 
egal, die wird eben nach Harvard oder "von-Neumann" klassifiziert. Oder, 
schaut man sich den befehlsstatz, Micro-scheduling an, nach 1-, 2-, 3- 
Addressmaschine oder Load-Store Architektur oder Stack-maschinde oder 
Register-windowing, ...


> Und die andere Frage ist, was mit "relevant" gemeint ist. Relevant ist
> in dem Zusammenhand so aussagekräftig wie "Teuer" bei Autos...

Der TO "präzesiert" später "Relevanz" später zu "Bedeutsam für die 
Software-Entwicklung". Naja, auch nicht besser.

Bei der "Einsatzplanung" eines "Embedded" controllers ist die Software 
nachrangig. Entscheidend ist die Verknüpfung zuwischen Sensorik (Taste) 
und Aktor, die durch den Controller realisiert werden muß. Da wird eher 
gefragt welche AD-Wandlung der Controller intus hat und nicht wie sich 
seine Architektur schimpft und wie breit er ist.

Für eine kleine Mikrocontroller-Application muß man nicht vollumfänglich 
"Software entwickeln", das Runterschreiben von den paar Zeilen Code die 
in die wenigen bytes Speicher eines controllers passen ist trivial. 
Anders sieht es bei Betriebssystem aus, aber die nbraucht man erst wenn 
man Datensätze abspeichert, in (komplexeren) Netzwerken arbeitet oder 
graphische oberflächen zu realisieren hat.

Und wie in der Vergangenheit gezeigt wurd,e kann man dergleichen 
unabhängig von der Datenbusbreite, die der TO hier gerne in die 
Streitarena gestellt hätte, realisiert.

Und natürlich wird es auch in 10,20, 30 Jahren neue Produkte geben, die 
mit ein paar Hundert Codzeilen auskommen für die "Datenverarbeitung" 
zwischen Knopf und Schaltttransistor auskommen: Taschenrechner, 
Sexspielzeug, Ladegeräte, Scheibenheber, Drehtahlregler, 
Fernbedienungen, Personenwaagen, wlwkreonische Thermometer, individuelle 
Vitalmonitor (Pols, Pulsoxy, Hautwiderstand, ...)

--
> Eine handvoll Befehle mehr oder weniger machen keine andere Architektur.
> Das sind nur die "üblichen kleinen Unterschiede" innerhalb einer
> Architektur.

Naja, als ich persönlich code aus einem AVR-Projekt ca 2001 auf einem 
damals Aktuellen AVR-Type umsetzen wollte, lief das auf eine quasi 
Neuprogrammierung raus, weil fast jede zweite Zeile angemeckert wurde, 
da Steuerregister inzwischen über das Speicherinterface angesprochen 
wurden und nicht über das Registerinterface. Oder umgekehrt. Dabei war 
ist Applikation (Kurzzeitwecker) nicht sonderlich komplex ... 
https://www.funkamateur.de/tl_files/downloads/hefte/2001/kzt.zip

Auch das 16bit Zugriffe aus von 'neueren' Instructionssets unterstütz 
werden ist eine wesentliche Architekturänderung (frag mal einen 
MC68000-Kenner ob der prozessor eine 16bit oder eine 32bit architektur 
hat ;-).

Aber wie bereits zu Beginn festgestellt, ist "Architektur" ohnehin eine 
hier verpatzte Begriffswahl des TO.

[Falk B. (falk)]

Bei der aktuellen Inflationsrate haben 8-Bit CPUs in 10 Jahren fast 16 
Bit! ;-)

[DSGV-Violator (Gast)]

Falk B. schrieb:
> Bei der aktuellen Inflationsrate haben 8-Bit CPUs in 10 Jahren fast 16
> Bit! ;-)

Ja auch bei geistigen Inhalten greift die Inflation aka 'Entwertung' um 
sich.

Früher brauchte es eine Dissertation und Titel nach 20 Jahren Ausbildung 
um eine Fachdiskussion zu führen, heute genügt eine von Mutti 
geschriebene Freistellung vom Kindergarten um sich vom Handy aus eine 
Karriere als "Beeinflußer" aufzubauen.

Aber wenn selbst das BBC einen komplett "Ahnungslosen" als 
Internet-Experten auf Sendung bringt ... 
https://time.com/4325712/guy-goma-bbc-interview-wrong-guy-internet/

[Rolf M. (rmagnus)]

DSGV-Violator schrieb:
> Der TO will offensichtlich als "Fachmann" glänzen

Nein, er hat einfach eine Frage dazu gestellt, wie relevant 8-Bitter in 
10 Jahren wohl sein werden und hat dafür ein paar Beispiele genannt. Du 
dagegen willst offenbar als "Fachmann" glänzen, indem du hier eine 
Diskussion darüber vom Zaun brichst, was der Begriff "Architektur" 
bedeutet. Das interessiert aber sonst keinen, weil es darum überhaupt 
nicht geht.

> Bei der "Einsatzplanung" eines "Embedded" controllers ist die Software
> nachrangig.

Heute ist doch alles "Software-defined", d.h. ein Gerät besteht im 
Wesentlichen aus einem Stück Software, an das etwas Peripherie 
angebunden wird. Natürlich braucht man auch noch etwas, worauf diese 
Software dann läuft. Die Software selbst ist aber nicht nachrangig, 
sondern steht vielmehr im Zentrum des Ganzen.

> Und natürlich wird es auch in 10,20, 30 Jahren neue Produkte geben, die
> mit ein paar Hundert Codzeilen auskommen für die "Datenverarbeitung"
> zwischen Knopf und Schaltttransistor auskommen: Taschenrechner,
> Sexspielzeug, Ladegeräte, Scheibenheber, Drehtahlregler,
> Fernbedienungen, Personenwaagen, wlwkreonische Thermometer, individuelle
> Vitalmonitor (Pols, Pulsoxy, Hautwiderstand, ...)

Wie hier aber schon mehrfach erwähnt wurde, ist es vollkommen 
irrelevant, ob die damit auskommen. Wesentlich ist nur, was in 
Massenstückzahlen am billigsten ist. Viele Zugverbindungen würde heute 
auch noch mit einer Dampflokomotive auskommen, aber die ist eben einfach 
nicht wirtschaftlich, also wird sie kommerziell nicht mehr eingesetzt.

[Philipp Klaus K. (pkk)]

Irgend W. schrieb:
> Bei Neuentwicklungen stellt sich, meiner Meinung nach, die Frage nach
> 8-Bit schon lange nicht mehr. Die Zeiten wo die mal die billigsten waren
> sind lange vorbei (auch wenn das durch die derzeitigen
> Lieferschwierigkeiten etwas verdeckt ist).

Die billigsten von Padauk (also aus der 8-Bit-Architekturfamilie, die 
ich oben als "PDK" nannte) sind bei LCSC zur Zeit unter 0,02 € pro 
Stück, wenn man 1000 nimmt.
Billigere 32-Bit-µC habe ich bisher bei Distributoren nicht gesehen.

[Falk B. (falk)]

Philipp Klaus K. schrieb:
> Die billigsten von Padauk (also aus der 8-Bit-Architekturfamilie, die
> ich oben als "PDK" nannte) sind bei LCSC zur Zeit unter 0,02 € pro
> Stück, wenn man 1000 nimmt.

Die können aber auch fast nix! Minimalste CPU im 70er Jahre PIC Design 
mit sehr wenig Speicher!

[Purzel H. (hacky)]

So schnell wird der Uebergang nach 32 bit nicht gehen. Meine 
persoenlichen Versuche resp Plaene sind bisher gescheitert.

Da war mal ein AVR32, der mir gefallen haette, speziell die UC3 Familie 
davon, er ist aber gefloppt. Und nicht mehr im Angebot. Es gab auch 
keine Tools, allenfalls ein Assembler. Fuer einen 32bitter .. ein 
schoener Beginn.

Da war mal eine PIC32 Familie, wofuer ich mich auch interessiert haette, 
aber Microchip hat es nicht auf die Reihe gekriegt ein Manual zu 
produzieren. hat fuer den Core auf Mips verwiesen, und dort ist die 
suche dann ausgefranst. Update.. mittlerweile sind die Manuals bei 
Microchip, ausgenommen die, welchen eben fehlen. Naja, solange die 
Manuals nicht vollstaendig sind, kann ich nicht beginnen.

Soll ich mir das Gezerre fuer eine andere Familie auch antun ? Hat schon 
jemand mit der Verfuegbarkeit von Manuals gekaempft ?

[J. S. (jojos)]

Purzel H. schrieb:
> So schnell wird der Uebergang nach 32 bit nicht gehen. Meine
> persoenlichen Versuche resp Plaene sind bisher gescheitert.

So ein Einzelschicksal wird kaum relevant sein für die Chipentwickler. 
Auch nicht wenn man die paar weiteren Bastler dazunimmt denen 32 Bitter 
zu kompliziert sind. Die Musik bestellen die Firmen die 100k Stückzahlen 
ordern, und die können sich auch (hoffentlich) Entwickler leisten die 
moderne Prozessoren programmieren können. Da geht es um die 
Leitungsfähigkeit der Controller bei kleinem Preis, und aufwändige 
Controller stecken heute in sehr vielen Geräten. Sogar im Toaster sind 
die angekommen, die gibt es auch schon mit Farbdisplay. Und bitte jetzt 
keine Diskussion das man eine Scheibe Weißbrot auch auf einem 
zurechtgebogenen Kleiderbügel über einer Kerze toasten kann.

Für den Preis spielt auch die Chipfläche eine Rolle, und damit moderne 
Produktionsprozesse mit kleineren Strukturgrößen. Ich vermute da sind 
die 32 Bit Designs auch weiter.

[Roland F. (rhf)]

Hallo,
Werner S. schrieb im Beitrag #7419967:
> Merkst Du daß Deine "am billigsten" These faul ist?

Nun ja, aber es zeigt zumindest auf, das 8-Bit-Prozessoren zu einem 
Preis herstellbar sind, die ein 32-Bit-Prozessor niemals erreichen wird. 
Und es wird auch in der Zukunft Dinge geben, bei deren Herstellung jeder 
1/10 Cent Kosten zählt.

rhf

[DSGV-Violator (Gast)]

> Diskussion darüber vom Zaun brichst, was der Begriff "Architektur"
> bedeutet. Das interessiert aber sonst keinen, weil es darum überhaupt
> nicht geht.

Doch, darum geht es, schau ins Topic: das steht "Architektur",
schau in den ersten Beitrag das steht Architektur viermal, sogar in der 
Variante 8/16 und noch in ein paar andere.
Das Wort Datenbus- oder Registerbreite taucht dagegen kein einziges Mal 
auf -> ergo die Frage wurde von einem Laienkaspar formuliert.

>> Bei der "Einsatzplanung" eines "Embedded" controllers ist die Software
>> nachrangig.
>
> Heute ist doch alles "Software-defined", d.h. ein Gerät besteht im
> Wesentlichen aus einem Stück Software, an das etwas Peripherie
> angebunden wird. Natürlich braucht man auch noch etwas, worauf diese
> Software dann läuft. Die Software selbst ist aber nicht nachrangig,
> sondern steht vielmehr im Zentrum des Ganzen.

Mumpitz,
bei der Geräteentwicklung wird zuerst gezählt welche und wieviel I/O's 
resp. Pins gebraucht werden und wieviel Power bereitgestellt (Batterie, 
enrgy-harvest, netzbetrieb) ist. Dann wird ein controller gewählt und 
die Softwareentwicklung so trivial gehalten, das der Hardware-Ingenieur 
das nebenher mitmacht. Wenns complexer sein muß, wird die 
Softwareentwicklung eh nach Transilvanien oder Nahe Pampa ausgelagert.

>> Und natürlich wird es auch in 10,20, 30 Jahren neue Produkte geben, die
>> mit ein paar Hundert Codzeilen auskommen für die "Datenverarbeitung"
>> zwischen Knopf und Schaltttransistor auskommen: Taschenrechner,
>> Sexspielzeug, Ladegeräte, Scheibenheber, Drehtahlregler,
>> Fernbedienungen, Personenwaagen, wlwkreonische Thermometer, individuelle
>> Vitalmonitor (Pols, Pulsoxy, Hautwiderstand, ...)
>
> Wie hier aber schon mehrfach erwähnt wurde, ist es vollkommen
> irrelevant, ob die damit auskommen. Wesentlich ist nur, was in
> Massenstückzahlen am billigsten ist.

Naja eine simples 8 bit Hundert Zeilen Progrämmchen ist billiger als 
eine Touch-GUI-Oberfläche 32 bit app auf einen 10^7+ Codezeilen 
OS-Monster. Das auch noch aufwendig getestet werden muß, damit auch 
nicht die Bugs/Sicherheitslücken zuschlagen, die mit einer 
Bug-Wahrscheinlichkeit von eins auf 100...1000 LoC im Software-Erguß 
"schlummern".

Und für so ein kleines Controller-programm findet man auch schneller ein 
Codierschwein als für irgendeinen Code-Moloch dessen Programmierer x++ 
Zertifikate und Schulungen vorweisen sollten um die Anforderungen an 
FuSi wenigstens im Ansatz garantiert werden könnte. KISS eben 
https://de.wikipedia.org/wiki/KISS-Prinzip .


##
> Viele Zugverbindungen würde heute
> auch noch mit einer Dampflokomotive auskommen, aber die ist eben einfach
> nicht wirtschaftlich,

Grund für das Ende der Dampflok ist nicht unbedingt die 
Wirtschaftlichkeit sondern des Gefahrenpotential (Kesselzerknall, 
Funkenflug) und die Beschränkheit der Reichweite einer Tenderfüllung 
resp. der Aufwand für eine Neubefüllung. Und somit der erheblische 
Wartungs-/Betriebs-aufwand für die Dampflok im Vergleich zur genügsamen 
Diesel-Lok.
In China fuhr und produzierte man noch bis ins Jahr 2000 Dampfloks 
(https://de.wikipedia.org/wiki/Eisenbahnverkehr_in_China#Ende_der_Dampflokzeit_in_China), 
selbst damit in den Neunzigern auf der Turfan-Ürumqui Strecke (兰新铁路) 
gefahren. Aber was hat das mit dem Thema "µC-Architektur" zu tun?

[DSGV-Violator (Gast)]

> DSGV-Violator schrieb:
>> Dann wird ein controller gewählt und die Softwareentwicklung so trivial
>> gehalten, das der Hardware-Ingenieur das nebenher mitmacht
>
> Das mag vielleicht für Deine Simpel-Beispiele gelten. Doch irrst Du wenn
> Du glaubst daß 8Bit nicht zu mehr taugen würde. Und dann wirds sehr
> schnell aufwendig.

Hab ich doch geschrieben, klar taugt 8bit für GUI/Massenspeicher und so, 
siehe GEOS oder CP/M. Aber Massenspeicher, Netzwerke braucht man eher 
nicht zwingend in der Controller-Entwicklung für bspw.Consumer 
Kaffemaschinen. Da brauchts simple Sensor->Motor steuerung, da ist der 8 
bit Controller ideal.

Dagegen kriegt man fast einen Krampf, wenn selbst simple Filesysteme wie 
FAT16 mit einem 8 Bit controller realisieren muß, BTDT. Da ist man mit 
native 32 bit besser dran. Aber warum soll man ein full-featured 
Filesystem in eine simple controller-Application stricken?!

Mit 8 bit hat der Anwender auch weniger Schereein mit als mit so ein 32 
bit overengineered Irgendwas. KISS eben.

[DSGV-Violator (Gast)]

Philipp Klaus K. schrieb:
> Seit ein paar Monaten sind die STM8 NRND.

Gibt es dafür irgendeinen vorzeigbaren Beleg ?

Das die STM8-Familie "nicht für neue Designs empfohlen" wäre oder gar 
abgekündigt wurde?

Ich such mir gerade einen Wolf auf 
https://www.st.com/en/microcontrollers-microprocessors/stm8-8-bit-mcus.html

und finde nichts in der Richtung.

[Philipp Klaus K. (pkk)]

DSGV-Violator schrieb:

> Ich such mir gerade einen Wolf auf
> https://www.st.com/en/microcontrollers-microprocessors/stm8-8-bit-mcus.html

Wähle dort "Product Selector". Dann steht in der Spalte "Status & 
Availability" bei allen 135 STM8 "NRND" in rot.

[DSGV-Violator (Gast)]

Der TO behauptete eingangs
>>> Seit ein paar Monaten sind die STM8 NRND

Werner S. schrieb im Beitrag #7420159:

> Auf Digikey hat den erwähnten Status etwa die Hälfte der STM8. Also
> längst nicht alle. Von einer generellen Abkündigung kann also keine Rede
> sein.
> Hat
> halt alles seine Absatz- und Produktionskapazitäts- Grenzen. Und nicht
> unbedingt mit der Busbreite des Controllers zu tun.

Eben. Das einzelne Typen/packages/OTP in einer Serie als "Auslaufend" 
markiert werden ist Alltag und ist hier öfters durchgekaut worden

Beitrag "Atmel noch zukunftsfähig?"
https://www.mikrocontroller.net/articles/AVR_Typen#Referenzen
Beitrag "Tiny 15 im DIP abgekündigt?"
Beitrag "ST62T25CM6 Produktion eingestellt"
Beitrag "Lifecycle AT90CAN Controllerfamilie"
Beitrag "80C51 Ersatztyp"
Beitrag "Nachfolger für ATMega gesucht"

Und aus diesem umgefallenen Sack Reis konstruiert der TO gleich die 
Relevanzfrage für alle 8bit µC ?! Was für ein Larry! SCNR

[Michael F. (Firma: IAR Systems) (michael_iar)]

DSGV-Violator schrieb:
> Eben. Das einzelne Typen/packages/OTP in einer Serie als "Auslaufend"
> markiert werden ist Alltag und ist hier öfters durchgekaut worden

Moin,

ersetze "einzelne" durch "alle"... Oder ist die Website von ST in Deinen 
Augen kein vorzeigbarer Beleg?

STM8xxx: 135 von 135 stehen auf "NRND"
https://www.st.com/en/microcontrollers-microprocessors/stm8-8-bit-mcus/products.html

Gruß,
Michael

[DSGV-Violator (Gast)]

Philipp Klaus K. schrieb:
> DSGV-Violator schrieb:
>
>> Ich such mir gerade einen Wolf auf
>> https://www.st.com/en/microcontrollers-microprocessors/stm8-8-bit-mcus.html
>
> Wähle dort "Product Selector". Dann steht in der Spalte "Status &
> Availability" bei allen 135 STM8 "NRND" in rot.

Also ich hab nach einen allgemeinen Dokument gesucht, oder ein 
entsprechendes Waserzeichen/Hinweis im Datenblatt, wie es eigentlich 
üblich ist.

Aber der erwähnte "produkt selector" wird (mir?) nur angezeigt, falls 
die Server-scripte im Browser aktiviert sind, in der (statischen) 
Web-Page findet sich kein solcher Hinweis.

Die Erklärung in der mouse pointer bubble (auch nur script generiert, 
seufz!) ist auch vielsagend. Es ist in der Massenproduktion nur um die 
Kundenproduktion zu unterstützen (also nicht auf Lager). Aber man kann 
es ordern, jedenfall platziert das Serverscript einen Einkaufswagen an 
der Stelle.

##
> Die Crux ist bloß: Es gibt wesentlich mehr STM8 Derivate.
Und auf der Website steht allenthalben "Long-term support", je nach dem 
ob LowPower- Automotive-, GeneralPurpose- productlinie.

[Ralf K. (kurtx)]

Brauchst du eine Empfehlung für den Aktienkauf,
oder eine Absicherung gegen geistige Anstrengung
(dann bräuchte man ja nix mehr neu lernen).

Vergiss es:
- Aktienrisiken streut man besser.
- Wenn du unter 67 bist: Da schützt auch die konservativste Partei
  bis zum Rentenalter nicht vor Neues-Lernen-Müssen.
- Und ab Mindestrente musst du auch mit 77, oder 88 eine digitale
  Steuererklärung abgeben. Halte dich besser fit!

[Christoph M. (mchris)]

rhf schrieb
>Hallo,
>Werner S. schrieb:
>> Merkst Du daß Deine "am billigsten" These faul ist?

>Nun ja, aber es zeigt zumindest auf, das 8-Bit-Prozessoren zu einem
>Preis herstellbar sind, die ein 32-Bit-Prozessor niemals erreichen wird.
>Und es wird auch in der Zukunft Dinge geben, bei deren Herstellung jeder
>1/10 Cent Kosten zählt.
>rhf

Würde man so bei E-Zigartten denken. Da ist aber in machen durchaus ein 
ARM-Controller drinn:
https://www.heise.de/select/ct/2018/16/1532920762784958

[G. K. (zumsel)]

Tilo R. schrieb:

> Zumindest im Automobilbereich sehe ich das Ende der 8-Bitter relativ
> schnell kommen, so es sie noch gibt.
> Grund dafür sehe ich in der ISO/SAE 21434 mit dem Titel "Road vehicles –
> Cybersecurity engineering" und den dazugehörigen UNECE R155 und R156.
> Da wird für alle Geräte ein Cyber-Security-Management-System verlangt,
> es müssen Bedrohungsanalysen durchgeführt und Produkte auf
> Schwachstellen hin beobachtet werden. Wenn man eine Schwachstelle
> findet, muss man ggf. patchen können. Und dafür muss man (mindestens)
> den Update-Pfad sicher bekommen. Und das schafft man nur mit
> kryptografischen Checksummen und Zertifikaten, wo sich die meisten
> 8-Bitter schwer tun.

Warum schaffen größere Angriffsvektoren ein 
"Cyber-Security-Management-System".

Und die jetzigen Krypto-Primitiven schaffen doch niemals den Lifecycle 
eines Autos.

[DSGV-Violator (Gast)]

Christoph M. schrieb:

> Würde man so bei E-Zigartten denken. Da ist aber in machen durchaus ein
> ARM-Controller drinn:
> https://www.heise.de/select/ct/2018/16/1532920762784958

Ju, irgendwie wundert es mich garnicht, das es eine Russen-Firma ist, 
die sich beim E-Zigaretten-Tuning austobt.
Da gibt es bestimmt ein Profil "папироса" - auch am Glimmstengel 
lutschen kann ein Faustschlag ins Gesicht sein ;-)

Marketing-mäßig ist die Verwendung von teuren Bauteilen in der Erstserie 
nicht ungewöhnlich. Ist ein gewisser Grundkundenstamm erreicht, ersetzt 
man beim Ramp-On derMassenproduktion die teuren Bauteile durch eine 
"Cost-optimized Variante". Und manchmal ist es der Markt, der einfach 
nichts billiges abnehmen will, da muss es schon was "Wertiges" sein.

>Nun ja, aber es zeigt zumindest auf, das 8-Bit-Prozessoren zu einem
>Preis herstellbar sind, die ein 32-Bit-Prozessor niemals erreichen wird.

Naja, das sollte man nicht als unverrückbares Naturgesetz stehen lassen.
Der Kostenanteil vom Silizium-Core ist eher gering, insbesonders wenn 
man lizenfreie also kostenlose Cores fertigt. Die Hauptkostem liegen 
eher im Package. Und eben in der Software. Die wird gerne 
üderdimensioniert, so nach dem Motte: wenn die ressourcen vorhanden sind 
dann verschwenden wir sie auch. Beispiel Mikro-python, nennt sich 'micro 
braucht' aber mehr Codespace als das OS eines classic-Macintosh.

[Ralph S. (jjflash)]

Dass die STM8 wohl auslaufen finde ich persönlich auch sehr schade, mir 
waren die bisweilen lieber als AVR (und waren auch lange Zeit 
preiswerterl).

Für Dich als Mitentwickler des SDCC ist das dann 2 mal schade, da 
(meiner Meinung nach) einer der wichtigsten Devices damit wegfällt.

Philipp Klaus K. schrieb:
> Einerseits gibt es ein paar noch aktuelle. Da fallen mir ein:
>
> * AVR
> * PIC
> * PDK
> * HCS08
> * MCS-51

MCS-51 wirds wohl ewig geben und auch wohl dann noch, wenn ich schon 
längst verbrannt bin (auf MCS51 und Z80 hatte ich gelernt).

PDK ist so eine Sache. Der Preis für diese Controller ist einfach zu 
sexy (egal ob Falk anmerkt dass er dafür auch fast nichts kann). 
Allerdings: Schaut man auf der Padauk-Seite stellt man fest, dass ein 
Controller dieser Familie, PFS-173, auch schon nicht mehr gelistet wird. 
Ob es diesen Controller also lange geben wird ist wohl schwierig 
abzuschätzen. Vllt. gibt es dann irgendwann einmal einen uns noch nicht 
bekannten Hersteller, der zu einem gleich billigsten Preis mehr als ein 
PDK kann und dann dürfte der Padauk wohl schnell vom Markt sein.

AVR wird es wohl ebenfalls noch eine Weile geben, sonst hätte Microchip 
wohl nicht die AVR series 0 -1 -2 aufgelegt (die bei den meisten 
Distributoren jetzt schon günstiger als die klassischen sind).

Allerdings: wenn man sieht wie ultrabillig die kleinsten 32-Bitter zu 
haben sind (STM32F030 ab ca. 40ct bei 100Stck+) mit Tendenz fallend, 
stellt sich die wirklich die Frage (wie viele der Vorredner bereits 
gesagt), wann der Preisvorteil der 8-Bitter aufgefressen ist.

[Tilo R. (joey5337)]

G. K. schrieb:
> Tilo R. schrieb:
>
>> Zumindest im Automobilbereich sehe ich das Ende der 8-Bitter relativ
>> schnell kommen, so es sie noch gibt.
>> Grund dafür sehe ich in der ISO/SAE 21434 mit dem Titel "Road vehicles –
>> Cybersecurity engineering" und den dazugehörigen UNECE R155 und R156.
>> Da wird für alle Geräte ein Cyber-Security-Management-System verlangt,
>> es müssen Bedrohungsanalysen durchgeführt und Produkte auf
>> Schwachstellen hin beobachtet werden. Wenn man eine Schwachstelle
>> findet, muss man ggf. patchen können. Und dafür muss man (mindestens)
>> den Update-Pfad sicher bekommen. Und das schafft man nur mit
>> kryptografischen Checksummen und Zertifikaten, wo sich die meisten
>> 8-Bitter schwer tun.
>
> Warum schaffen größere Angriffsvektoren ein
> "Cyber-Security-Management-System".
Mit dem Management-Gedöns weist man nach, dass man Prozesse hat, um sich 
im Ernstfall zeitnah um Probleme kümmern zu können. Und dass man bei der 
Entwicklung über mögliche Angriffsvektoren nachdenkt.

> Und die jetzigen Krypto-Primitiven schaffen doch niemals den Lifecycle
> eines Autos.
Sehe ich nicht so. Es gibt Algorithmen, bei denen man erwarten kann, 
dass sie auch in 10 oder 20 Jahren noch eine angemessene Sicherheit 
bieten.
Und selbst wenn durch neue Erkenntnisse nach und nach rauskommt, dass 
ein Algorithmus schwächer als gedacht ist (Beispiel: SHA1), dann kann 
man immer noch überlegen, ob man einen neuen Key oder einen anderen 
Algorithmus ausrollt.

[Falk B. (falk)]

Ralph S. schrieb:
> Allerdings: wenn man sieht wie ultrabillig die kleinsten 32-Bitter zu
> haben sind (STM32F030 ab ca. 40ct bei 100Stck+) mit Tendenz fallend,
> stellt sich die wirklich die Frage (wie viele der Vorredner bereits
> gesagt), wann der Preisvorteil der 8-Bitter aufgefressen ist.

Stimmt. Denn auf dem Chip ist die CPU bei den modernen Prozessen relativ 
klein, der Speicher bestimmt die Fläche und damit die Kosten. Naja, und 
das Backend mit Test und Verpackung. Der Kostenvorsprung der 8 Bitter 
ist schon lange geschrumpft, teilweise sogar NEGATIV! Vergleicht mal 
einen der größeren AVRs mit einem 32 Bitter mit gleichem Speicher! Das 
sehen die AVRs alt und teuer aus! Erst recht die schon leicht betagten 
Serien.

Trotzdem werden sich die 8 Bitter halten, warum auch immer.

[Falk B. (falk)]

" MCU sales exceed 29 billion units in 2021, reaching a market size of 
$18.5 billion."

Es wurden 2011 als 29 Milliarden Mikrocontroller für "nur" 18.5 
Milliarden Dollar verkauft? D.h. die große Masse kostet deutlich unter 
einem Dollar! Da müsste man mal eine Häufigkeitsverteilung über Preis 
sehen. Da sind Controller über 5 Doller schon sehr selten.

"Only 16-bit MCUs, in the face of 8-bit and 32-bit MCU "two-way attack", 
regardless of specifications, features and advantages are squeezed, 
market share gradually unpopular.

In terms of current mainstream applications, 4-bit and 16-bit MCUs have 
almost disappeared, with 8-bit and 32-bit MCUs basically sharing the 
entire application market. 64-bit MCU market is still in its infancy, 
with most applications in high-end workstations, and advanced 
terminals."

Klingt nachvollziehbar.

[Jann (jann_w)]

Lage in meiner aktuellen Firma und der davor, beide Mikrocontroller 
Abnehmer im Bereich >= 100k/pro Jahr.

8-Bitter werden für keine "SW-Funktionen" mehr benutzt. Dafür tauchen 
Sie aber verstärkt als Wächter in der Spannungsvorsorge oder aber für 
zusätzliche Diagnosen in anderen Pfaden auf. Dann meistens von der 
Hardware Abteilung programmiert mit evtl. etwas Support aus den SW 
Abteilungen.
Da die SW meistens recht überschaubar ist, reichen in jedem Fall weniger 
als 8 kB Rom ... 2 kB würden meist schon ausreichen.

Primäre Anforderungen sind meist SPI (manchmal aber auch nur zwei DIO 
Pins an den Primärprozessor), ADC, Preis, Spannungsversorgung, allgemein 
keine übermäßige Komplexität -> Cortex-M irgendwas Derivate sehe ich da 
auch noch mit drin.
Ist übrigens häufiger die Wahl auf MCS-51 Derivate gefallen. Kenne keine 
konkreten Preise, muss aber im Austausch gegen den vorherigen Aufbau in 
einem Fall eigentlich im 0-20 Cent Bereich gelegen haben ... sonst hätte 
man den Umbau nicht gemacht.

Falk B. schrieb:
> 4-bit and 16-bit MCUs have
> almost disappeared
Beim ex-Arbeitgeber ist in einem ASIC ein 16-Bitter drin, würd mich 
überraschen wenn die in den Statistiken überhaupt auftauchen. Einfache 
Geräte laufen nur mit dem, komplexere haben einen zusätzlichen 
Rechenkern on Board. Ganz tot sind die 16-Bitter also noch nicht 😉

[Philipp Klaus K. (pkk)]

Ralph S. schrieb:

> PDK ist so eine Sache. Der Preis für diese Controller ist einfach zu
> sexy (egal ob Falk anmerkt dass er dafür auch fast nichts kann).
> Allerdings: Schaut man auf der Padauk-Seite stellt man fest, dass ein
> Controller dieser Familie, PFS-173, auch schon nicht mehr gelistet wird.
> Ob es diesen Controller also lange geben wird ist wohl schwierig
> abzuschätzen.

Einzelne µC mögen gehen, aber die Architektur bleibt ja, so lange es 
noch andere µC dazu gibt. Es ist auch mein Eindruck, dass Padauk 
einzelne µC recht kurzfristig abkündigt, üblicherweise, wenn ein etwas 
besserer Ersatzty verfügbar wird. Der PFS173 wurde durch den weitgehend 
kompatiblen PFS123 ersetzt.

[DSGV-Violator (Gast)]

> Falk B. schrieb:
>> 4-bit and 16-bit MCUs have
>> almost disappeared
> Beim ex-Arbeitgeber ist in einem ASIC ein 16-Bitter drin, würd mich
> überraschen wenn die in den Statistiken überhaupt auftauchen. Einfache
> Geräte laufen nur mit dem, komplexere haben einen zusätzlichen
> Rechenkern on Board. Ganz tot sind die 16-Bitter also noch nicht 😉

Die 16bitter sind IMHO in der Elektronik-Entwicklung 
bedauernswerterweise weitgehend "übersprungen" worden.

IMHO zu unrecht, weil viele Aufgaben aufgrund der 
datenbreite/wahrnehmbare Dynamikumfang der AD-Wandler ideal in 16 bit 
passen.

Aber die Prozessorhersteller sind halt schon in den 80ern (MC68000 - 
1979) auf 32 bit gegangen und bieten 16 bit als Halbherziges Downgrading 
der 32bit Hauptlinie an (i.e. ARM-Thumb).
Bei DSP mag es anders ausgeschaut haben.

[(prx) A. K. (prx)]

DSGV-Violator schrieb:
> Aber die Prozessorhersteller sind halt schon in den 80ern (MC68000 -
> 1979) auf 32 bit gegangen und bieten 16 bit als Halbherziges Downgrading
> der 32bit Hauptlinie an

Ein 16-Bit Adressraum als Grundlage einer Architekturfamilie reicht 
schon lange nicht mehr aus und entsprechende Architekturen haben beim 
Umgang mit diesem Problem nur halbherzige Lösungen anzubieten.

> (i.e. ARM-Thumb).

Mit der Codierung der Befehle als Kriterium sind die aktuellen 
PC-Prozessoren halbherzige 8-Bitter. ;-)

[DSGV-Violator (Gast)]

(prx) A. K. schrieb:
> DSGV-Violator schrieb:
>> Aber die Prozessorhersteller sind halt schon in den 80ern (MC68000 -
>> 1979) auf 32 bit gegangen und bieten 16 bit als Halbherziges Downgrading
>> der 32bit Hauptlinie an
>
> Ein 16-Bit Adressraum als Grundlage einer Architekturfamilie reicht
> schon lange nicht mehr aus und entsprechende Architekturen haben beim
> Umgang mit diesem Problem nur halbherzige Lösungen anzubieten.

Verwirr hier mal nicht Addressraum unbd Registerbreite.

Für einen einzelnen AD-Wandlerkanal braucht man gerade mal zwei Register 
(Daten und Config) da wäre auch 1bit  Addressraum genug. Und auch die 16 
bit Prozessoren haben für den Addressbus mehr bits 20 bit -> 1 MWord 
adressierbar bspw. .

Und ein Controller, der für ne 
Kaffemaschiene/Scheibenheber/Fernbedienung/Taschenrechner mehr oder 
überhaupt  64kyte Addressierbaren Raum braucht ist IMHO reichlich 
"overenginered".

Man erinnere an sinclairs ersten Taschenrechner aus den Zeiten, in denen 
die Computergenies noch in Cambridge hockten.
Deren Programm benötigte weniger als ein halbes tausend Speicherwörter 
und genügte trotzdem für log und sin und ersetzte so die Wälzer an 
Logarithmentafeln damals:

http://datamath.org/Related/Sinclair/Scientific.htm

Aber heute schämt man sich nicht einen 256k word Softwareklumpen benannt 
"micropython" als "optimal für µC" anzupreisen ...

[Veit D. (devil-elec)]

Hallo,

der gesamte Thread und damit diese Diskussion ist doch komplett 
sinnfrei. Definiert erstmal die Architekturunterschiede. Im gesamten 
Thread wird nur sinnfrei ganz allgemein diskutiert ob 8 Bit Controller 
weiterleben oder nicht. Die werden ewig leben. Punkt. Was versteht ihr 
denn unter Architektur? Womit macht ihr das denn fest? Worin liegt der 
Sinn darin? Worin würde der Sinn liegen zu diskutieren ob Intels oder 
AMDs x86 CPU Design die bessere Architektur hat? Beide sind zueinander 
kompatibel mit kleinen Anpassungen im OS. Daraus würde dann laut 
aktuellen Diskussionsfaden hier im Thread daraus werden ob x86 überlebt. 
Mir ist gar nicht klar über was ihr überhaupt so richtig ernsthaft 
diskutiert womit man einen Grund hätte darüber nachzudenken zum 
Gesagten.

[(prx) A. K. (prx)]

DSGV-Violator schrieb:
> Verwirr hier mal nicht Addressraum unbd Registerbreite.

Ich habe deinen Unsinn mit ARM-Thumb nur konsequent weitergeführt. ;-)

[Georg M. (g_m)]

"Vereinfacht dargestellt bedeutet 32 Bit, dass ... zwei 32-Bit-Zahlen 
(also 4 Byte) gleichzeitig verarbeitet werden können"

https://de.wikipedia.org/wiki/32-Bit-Architektur

[Steve van de Grens (roehrmond)]

Georg M. schrieb:
> Vereinfacht dargestellt bedeutet 32 Bit, dass ... zwei 32-Bit-Zahlen
> (also 4 Byte) gleichzeitig verarbeitet werden können

Genau. Das ist natürlich praktisch und vorteilhaft.

Der Haken ist, dass diese Mikrocontroller fast alle eine erheblich 
komplexere Peripherie um den CPU Kern herum haben.

[Rick (rick)]

Steve van de Grens schrieb:
> Genau. Das ist natürlich praktisch und vorteilhaft.
Wenn man denn den Bedarf dafür hat.
Mit 4 Bit kann man super Uhren und anderes Zeugs mit Ziffern bauen.
Für 'Textverarbeitung' sind 8 Bit recht sinnvoll.
Mit 16 Bit kann man Werte mit einer Dynamik von 60 bis 80 dB abbilden. 
Das ist für Ohr und Auge m.E. ausreichend.
Immerhin reden wir hier von embedded...

[Falk B. (falk)]

Der ASM-Fanatiker ist wieder da! ;-)

[(prx) A. K. (prx)]

Könnte er nicht auf 7 Bit umsteigen? Primzahlen sind so viel schöner, 
und wenigsten originell.

[Falk B. (falk)]

Hmm, Moby Dick endete so . . .

https://www.youtube.com/watch?v=eHrxPANXbJ8

[S. L. (sldt)]

Schon, aber der nahm alle mit, bis auf einen - And I only am escaped 
alone to tell thee.

[S. R. (svenska)]

DSGV-Violator schrieb:
> Die 16bitter sind IMHO in der Elektronik-Entwicklung
> bedauernswerterweise weitgehend "übersprungen" worden.

Naja, sie haben die gleichen Adressraumbeschränkungen wie 8-Bitter und 
sind damit für größere Systeme trotzdem zu klein - und einfache 
Arithmetik können die 8-Bitter auch ausreichend.

Bei komplexer Arithmetik muss man dafür ständig die Wertebereiche für 
Zwischenergebnisse im Blick behalten, was bei 32-Bittern egal ist. 
Floating-Point passt den 32-Bittern auch besser in die Register...

Veit D. schrieb:
> Im gesamten Thread wird nur sinnfrei ganz allgemein diskutiert ob 8 Bit
> Controller weiterleben oder nicht. Die werden ewig leben. Punkt. Was
> versteht ihr denn unter Architektur?

Für jemanden, der sich tief mit Compilern für 8-Bit-Architekturen 
befasst, ist die Frage, ob es selbige in der näheren, mittleren oder 
weiteren Zukunft noch gibt, durchaus relevant.

Und da sehe ich durchaus hohe Relevanzwahrscheinlichkeiten für 8051, AVR 
und PIC. PDK kann ich nicht einschätzen. Den Z80 sehe ich eher in der 
Hobby- und Liebhaberecke, und dort auch noch sehr lange.

[Christoph M. (mchris)]

>DSGV-Violator schrieb:
>> Die 16bitter sind IMHO in der Elektronik-Entwicklung
>> bedauernswerterweise weitgehend "übersprungen" worden.

Die 80C166 waren in Industriegeräten und Steuerungen relativ weit 
verbreitet. Vor allen Dingen die Peripherie war sehr umfangreich.

https://de.wikipedia.org/wiki/C166

[DSGV-Violator (Gast)]

S. R. schrieb:
> DSGV-Violator schrieb:
>> Die 16bitter sind IMHO in der Elektronik-Entwicklung
>> bedauernswerterweise weitgehend "übersprungen" worden.
>
> Naja, sie haben die gleichen Adressraumbeschränkungen wie 8-Bitter und
> sind damit für größere Systeme trotzdem zu klein - und einfache
> Arithmetik können die 8-Bitter auch ausreichend.
Das mit der angeblichen gleichen Addressraumbeschränkung für alle 8 und 
16 bit (ALU-registerbreite) Systeme ist schlicht falsch, das wurde oben 
schon zurückgewiesen, daran verschwende ich nicht nochmal eine 
Argumentation.

Dagegen hat der Hinweis auf den Zusammenhang zwischen Registerbreite und 
"Komplexität" durchaus seine Berechtigung. Auch der Hinweis auf Float 
hat Beachtung verdient, auch wenn der sich durchaus schon in dem Aspekt 
"Komplexität" wiederfindet.

Betrachtat man die Frage "wie komplex ist das System" als Ingenieur in 
der Embedded-Branche kommt man auf den die Komplexität bestimmenden 
Faktor auf die Breite der AD/DA-Wandler. Also, welche Quantisierung ist 
sinnvollerweise nötig?

Als Bewerter gelten die menschlichen Sinnesorgane und damit die Frage 
wieviel bit Farbunterschiede/Lautstärkeunterschiede kann der Mensch 
warnehmen, wieviel Nuancen sind unterscheidbar. Und seit den Neunzigern 
Jahren ist da eigentlich klar, das technisch weitaus mehr möglich ist 
als der Mensch wahrnehmen kann. CCD-Sensoren liegen sinnvollweiser unter 
10 bit grauwert, Scope-displays liegen immho auch bei 8 bis 10 bit. Hat 
man mehr bits, "gehen die als lsb im Rauschen unter". Legt man intern 
für die Verarbeitung noch ein paar bits auf die Quantisierungsbits drauf 
für den numerischen Überlauf bei der Akkumulation (Filterstrukturen) 
reichen 16 bit bei Embedded wie Drucker, bediendisplays, Kaffemaschine.

Das man bei der PC-Rechentechnik und Katzenvideos mehr verlangt ist IMHO 
eine andere Diskussion, im Embeddedbereich sind 1 ... 16 bit in 99,9% 
der Fälle ausreichend. Und mit dem KISS-Prinzip macht man sich nicht nur 
die Entwicklungsarbeit leichter sondern auch sicherer.
Denn je komplexer ein System, desto mehr kann schief gehen und schon 
E.A. Murphy hat 1949 erkannt und formuliert, das "das was schief gehen 
kann auch schief gehen wird".

[(prx) A. K. (prx)]

DSGV-Violator schrieb:
> Also, welche Quantisierung ist sinnvollerweise nötig?

Die Erfordernisse von Bild/Ton Massendaten gehen seit langer Zeit in 
spezielle SIMD Befehle ein, deren Verarbeitungsbreiten nichts mit dem zu 
tun haben, was man unter einer Architekturbreite versteht. Andernfalls 
hätte mein Laptop eine 512-Bit CPU.

Auch bei Mikrocontroller hat das Einzug gehalten.

Diese typischerweise intern von normalen Operationen etwas abgetrennte 
Verarbeitung ist oft assoziiert mit einer FPU, deren Verarbeitungsbreite 
nicht als Architektureigenschaft gilt. Oder war der 8086 mit FPU ein 
80-Bitter, ohne sie aber ein 16-Bitter?

[DSGV-Violator (Gast)]

> Die Erfordernisse von Bild/Ton Massendaten

> spezielle SIMD Befehle ein,

> Auch bei Mikrocontroller hat das Einzug gehalten.

Nein.

[(prx) A. K. (prx)]

DSGV-Violator schrieb:
>> spezielle SIMD Befehle ein,
>
>> Auch bei Mikrocontroller hat das Einzug gehalten.
>
> Nein.

Ab Cortex M4.

[Stefan F. (Gast)]

DSGV-Violator schrieb:
> Denn je komplexer ein System, desto mehr kann schief gehen

Ja schon, aber ein paar Bits mehr empfinde ich nun nicht als "komplexer" 
sondern einfach "mehr". So wie auch 4 kB RAM versus 32 kB.

Programmiersprachen wie C abstrahieren den CPU Kern weitgehend. Nur 
wenige Zeilen Quelltext sehen bei 32 Bit anders als bei 8 Bit aus.

Bei den mir bekannten 32 Bit Controllern ist allerdings die Peripherie 
drumherum komplexer, was Funktionsumfang, Seiteneffekte und 
Konfiguration betrifft. Dafür kann der CPU Kern nichts, das ist eher 
eine Designentscheidung der Chipherstellers gewesen. Genau so gut könnte 
man auch 8 Bit CPUs zusammen mit komplexer Peripherie in ein Gehäuse 
packen, was bei einigen Microchip AVR Modellen tatsächlich gemacht 
wurde.

[(prx) A. K. (prx)]

Stefan F. schrieb:
> allerdings wirklich komplexer, was Funktionsumfang, Seiteneffekte und
> Konfiguration betrifft.

Die Errata-Liste ist ebenfalls länger.

[Harry L. (mysth)]

Moby hat nicht nur nen erheblichen Sprung in der Schüssel, sondern auch 
seine Platte hat nen Sprung....

...dabei hat er sich vor ca. 2J mit seinem missionarischen Eifer schon 
ne blutige Nase geholt.

Kann ein Moderator den nicht mal stumm schalten?

Das grenzt langsam an "intellektueller Körperverletzung".

[Steve van de Grens (roehrmond)]

Ich habe gestern gelesen, dass ARM wohl voll auf 64 Bit für Smartphones 
setzt. Da kam mir spontan die Frage in den Kopf: Wozu?

Damals auf PC war das größte Argument, dass durch den Wechsel 32->64 Bit 
die Speicherverwaltung großer Programme einfacher wird. Logisch fand ich 
das Argument nicht, denn Intel Prozessoren konnten schon immer viel mehr 
Speicher adressieren, als die Breite der Rechenregister. Man hätte 64 
Bit Adressraum ebenso auf 32 Bit Prozessoren haben können (denke ich).

Zurück zu Smartphones, da frage mich wirklich, was das bringen soll, 
außer mehr Speicher- und Energiebedarf schon im Leerlauf. Kennt jemand 
die Hintergründe dieser Entscheidung?

[(prx) A. K. (prx)]

Steve van de Grens schrieb:
> Ich habe gestern gelesen, dass ARM wohl voll auf 64 Bit für Smartphones
> setzt. Da kam mir spontan die Frage in den Kopf: Wozu?

Genau wie beim PC geht es nicht um die Fähigkeit, durch das Gesamtsystem 
genug RAM adressieren zu können, sondern um den Adressraum einer 
einzelnen Anwendung. Schon früh konnten x86 Prozessoren insgesamt viel 
mehr RAM nutzen, als die 4GB definierten, auch wenn normales 32-Bit 
Windows das nicht freigab. Der einzelnen Anwendung half das aber nicht.

Die Verarbeitung von Adressen wird wesentlich erleichtert, wenn die 
Rechenbreite der Adressbreite entspricht. Das war schon beim 8088 des 
ersten PCs so: Programme mit 64KB Daten (und 64KB Code) waren wesentlich 
kompakter und schneller als solche mit mehr als 64KB Daten. Und wenn 
einzelne Datenstrukturen grösser als 64KB wurden, war es ein übler 
Krampf.

Im Protected Mode des 286 war es nicht anders. Unix liess sich darauf 
nur mühsam abbilden, weshalb erst der 386 mit seiner flachen, also 
nicht-segmentierten 32-Bit Adressierung so richtig aus der DOS-Welt 
ausbrach. Aber irgendwann wurden dessen natürliche 4GB etwas eng. Zuerst 
natürlich bei Servern.

Für Windows beschrieben: Der Adressraum einer Anwendung umfasst 4GB, 
davon 2GB fürs System und 2GB für die Anwendung. Innerhalb der 2GB gibt 
es bedingt durch die Adressraumverwaltung grosse Lücken, die nicht 
sinnvoll genutzt werden können, und es gibt virtuellen Speicher, dessen 
Inhalt in EXEs oder Swap liegt. Daumenregel ist, dass eine 32-Bit 
Anwendungen effektiv nicht wesentlich mehr als 1GB RAM wirklich nutzen 
kann. Und das ist längt zu wenig. Bei Android wird es im Detail etwas 
anders aussehen, aber das grundsätzliche Problem bleibt.

[(prx) A. K. (prx)]

Steve van de Grens schrieb:
> Ich habe gestern gelesen, dass ARM wohl voll auf 64 Bit für Smartphones
> setzt.

Schon mit Android 5 fing die Migration zu 64-System und 64-Bit Apps an. 
Aber erst jetzt wird die Kompatibilität zu 32-Bit runtergefahren, auch 
in der ARM Hardware.

[Steve van de Grens (roehrmond)]

Ich danke euch für die Erklärung

[Lutz S. (lutzs)]

Da hier ganz am Anfang mal Rabbit (Z180) als 8-bit Prozessor erwähnt 
wurde: die habe ich gern verwendet, hatten mit Dynamic-C schon vor über 
20 Jahren unter anderem TCP/IP Bibliotheken, sogar mit SNMP.

[Philipp Klaus K. (pkk)]

Lutz S. schrieb:
> Da hier ganz am Anfang mal Rabbit (Z180) als 8-bit Prozessor erwähnt
> wurde: die habe ich gern verwendet, hatten mit Dynamic-C schon vor über
> 20 Jahren unter anderem TCP/IP Bibliotheken, sogar mit SNMP.

Wobei Dynamic-C allerdings weder gute Standardunterstützung aufweist, 
noch gut optimiert (und bei beidem schon vor vielen Jahren weit hinter 
SDCC lag). Leider wurden die TCP/IP-Bibliotheken meines Wissens nie auf 
SDCC portiert.

[Philipp Klaus K. (pkk)]

S. R. schrieb:
>
> Für jemanden, der sich tief mit Compilern für 8-Bit-Architekturen
> befasst, ist die Frage, ob es selbige in der näheren, mittleren oder
> weiteren Zukunft noch gibt, durchaus relevant.
>
> Und da sehe ich durchaus hohe Relevanzwahrscheinlichkeiten für 8051, AVR
> und PIC. PDK kann ich nicht einschätzen. Den Z80 sehe ich eher in der
> Hobby- und Liebhaberecke, und dort auch noch sehr lange.

Bei der Arbeit an SDCC gäbe es immer mehr zu tun, als Zeit verfügbar 
ist.

Z.B. Verbesserungen der Standardunterstützung, Tests und Bugfixes, 
maschinenunabhängige Optimierungen, Verbesserungen an einzelnen Ports, 
neue Ports, etc.

Und gerade für die letzteren beiden Punkte ist es gut zu wissen, für 
welche 8-Bit-Architekturen in 10 Jahren noch Software geschrieben wird. 
Könnte ja sein, dass jemand hier etwas zur Zukunft von z.B. HCS08 oder 
PDK weiß, dass mir nicht bekannt ist, oder von aufsteigenden, aber 
bisher noch wenig bekannten neuen 8-Bit-Architekturen.

[Ralph S. (jjflash)]

Moby A. schrieb im Beitrag #7426530:
> Die Ingenieurs-Power wär statt in dumme, immer komplexer konfigurierbare
> lieber in intelligentere Peripherie geflossen in der ganze Abläufe
> automatisch erledigt werden.

Was ist das für eine xyz Aussage? Wenn auf Chips (für das gleiche Geld) 
immer leistungsfähigere Peripherie geboten wird, die eben auch mehr 
Möglichkeiten bietet, dann ist die eben komplexer zu konfigurieren. In 
aller Regel wird man die Peripherie für den eigenen Bedarf einmal 
durchexerzieren und nach diesem Schema weitere Projekte bearbeiten. Im 
Übrigen ist bsp. ein nativer USB-Port in einem 8-Bitter "komplex" zu 
konfigurieren und nicht wirklich einfach. Ein DMA habe ich in einem 
8-Bitter noch gar nicht gesehen (was nicht heißt dass es das nicht 
gibt).

Moby A. schrieb im Beitrag #7426530:
> Die STM8 werden übrigens mitnichten komplett eingestellt. Gewisse Leute
> können es halt einfach nicht erwarten. Die absoluten Produktionszahlen
> der 8Bitter steigen weiter.

Aha, du hast als deine Spione bei ST electronics und die geben diese 
Infos nur zu Verwirrung der Konkurrenz heraus? Natürlich weißt du auch 
die Daten vieler Chipproduzenten und dass die Produktionszahlen steigen? 
(Achtung, Ironie)

Das einzige womit ich dir Recht gebe ist, dass es in Zukunft wohl 
tatsächlich noch (sehr) lange 8-Bitter geben wird, weil es einfach viele 
Einfachstanwendungen dafür gibt und wohl geben wird (sei es nur Gadgets 
für irgendwelches Spielzeug oder Datensammler für irgendwelche 
Sensoren). Aber viele Geräte erfordern einfach andere Controller, weil 
der Kunde mittlerweile überall Iot fordert, das ganze gepaart mit einem 
graphischen Display (ich brauche keine Kaffeemaschine mit so einem 
Display, aber der große Kundenstamm kauft so etwas eher, einfach weil es 
schick ist).

Zudem gibt es einfach irre viele fertige Software für 8-Bit Controller. 
Die Frage stellt sich nicht, ob 8 oder 32 oder 64 Bit. Und eine 
Diskussion darüber ist müßig.

Einzig eine Frage stellt sich: wer wird die 8-Bitter herstellen und wer 
die 32-Bitter. Ich habe meinen gesammelten Vorrat an MCS-51 Controllern 
verschenkt (waren fast 150 Stck.) weil ich damit nichts mehr machen 
werde (waren aber eh nur entweder Originale von Intel, Siemens und 
Atmel). Am Beispiel von MCS-51 kann man jedoch gut sehen wie sich etwas 
entwickeln kann: Intel stellt schon ganz lange keine MCS-51 mehr her, 
weil sich das Geschäft für Intel wohl nicht gelohnt hat. Für andere, 
vorwiegend chinesische Firmen jedoch schon. Wie gesagt stellt sich die 
Frage, wer das herstellen wird.

Zur Eingangsfrage des TO würde ich von daher nur 2 Spekulationen 
abgeben: es wird wohl MCS-51, AVR und PIC noch geben.

STM8 wird wohl abgekündigt sein, u. a. auch um Produktionskapazitäten 
frei für STM32 zu haben und damit dann auch in ihrem Produktportfolio 
besser durchgängig zu sein.

Ob PDK über längere Zeit "am Leben" bleibt glaube ich nicht, da werden 
andere kommen die dann wieder neue und bessere Ideen im Billigstsegment 
haben und dann wird Padauk eben auf etwas anderes umsteigen (vllt. liege 
ich aber auch falsch und sie werden der PDK-Serie besser und komplexere 
Peripherie spendieren, wie auch immer sie das dann bewerkstelligen)

[Harald K. (kirnbichler)]

Don't feed the troll.

[Philipp Klaus K. (pkk)]

Ralph S. schrieb:

> Ob PDK über längere Zeit "am Leben" bleibt glaube ich nicht, da werden
> andere kommen die dann wieder neue und bessere Ideen im Billigstsegment
> haben und dann wird Padauk eben auf etwas anderes umsteigen (vllt. liege
> ich aber auch falsch und sie werden der PDK-Serie besser und komplexere
> Peripherie spendieren, wie auch immer sie das dann bewerkstelligen)

Bisher ist Padauk aber erfolgreich: 2005 gegründet, seit 2018 
börsennotiert. Komplexere Peripherie passt nicht zum Konzept von Padauk 
(das mir durchaus sinnvoll erscheint): Funktionalität, die solche 
Peripherie böte, emuliert man stattdessen in Software.

[S. R. (svenska)]

DSGV-Violator schrieb:
> Das mit der angeblichen gleichen Addressraumbeschränkung für alle 8 und
> 16 bit (ALU-registerbreite) Systeme ist schlicht falsch, das wurde oben
> schon zurückgewiesen, daran verschwende ich nicht nochmal eine
> Argumentation.

Die meisten 8-Bit-Systeme bieten 64K Adressraum. Die meisten 
16-Bit-Systeme bieten auch 64K pro Adressraum, manchmal Kiloworte statt 
Kilobytes und manchmal getrennt zwischen Code und Daten, aber 
grundsätzlich ändert sich am Problem nichts.

Steve van de Grens schrieb:
> Ich habe gestern gelesen, dass ARM wohl voll auf 64 Bit für Smartphones
> setzt. Da kam mir spontan die Frage in den Kopf: Wozu?

Funktionalität, Geschwindigkeit, Sicherheit und Kompatiblität.

Zu 1: Es gibt inzwischen viele Anwendungen und Verfahren, die mehrere GB 
RAM sinnvoll benutzen können (z.B. das Kamerasystem in einem modernen 
Smartphone oder das Entertainment/Navigationssystem im Auto können sehr 
speicherhungrig sein) und das geht mit einem 32-Bit-Adressraum nicht.

Zu 2: Das gilt sinngemäß auch für die Verarbeitung, und 
64-Bit-Architekturen haben SIMD-Befehle schon vordefiniert, die bei 
32-Bit-Architekturen optional sind. Das vereinfach die Entwicklung, weil 
man auf Billiggeräte keine Rücksicht nehmen muss.

Zu 3: Der 32-Bit-Adressraum eines Prozesses ist fast komplett voll, d.h. 
Zufallszahlen sind sehr wahrscheinlich gültige Pointer. Damit verliert 
ALSR seine Wirkung; mit einem 64-Bit-Adressraum ist der Adressraum fast 
komplett leer, statistische Mitigations funktionieren deutlich besser.

Zu 4: ARM entfernt die 32-Bit-Kompatibilität aus aktuellen 
High-End-Prozessoren (ARMv8). In modernen Smartphones sind mehrere 
unterschiedliche Cores verbaut und nicht alle können noch 32-Bit-Code 
ausführen. Deswegen zwingt Google auch App-Hersteller auch zu 
64-Bit-Kompatiblität.

(prx) A. K. schrieb:
> Schon mit Android 5 fing die Migration zu 64-System und 64-Bit Apps an.
> Aber erst jetzt wird die Kompatibilität zu 32-Bit runtergefahren, auch
> in der ARM Hardware.

Intel überlegt auch, die 32-Bit-Kompatiblität (und damit auch die 
letzten 16-Bit-Reste) einzustampfen, zumindest auf der Kernel-Seite.

Philipp Klaus K. schrieb:
> Könnte ja sein, dass jemand hier etwas zur Zukunft von z.B. HCS08 oder
> PDK weiß, dass mir nicht bekannt ist, oder von aufsteigenden, aber
> bisher noch wenig bekannten neuen 8-Bit-Architekturen.

Ich kann mir irgendwie nicht vorstellen, dass neue 8-Bit-Architekturen 
mit Compilersupport große Chancen haben. Padauk ist da eher die 
Ausnahme.

[Ralph S. (jjflash)]

Philipp Klaus K. schrieb:
> Bisher ist Padauk aber erfolgreich: 2005 gegründet, seit 2018
> börsennotiert. Komplexere Peripherie passt nicht zum Konzept von Padauk
> (das mir durchaus sinnvoll erscheint): Funktionalität, die solche
> Peripherie böte, emuliert man stattdessen in Software.

Ich habe nicht gesagt, dass Padauk nicht erfolgreich ist ... und ich 
glaube schon, dass sie erfolgreich bleiben. Ob PDK erfolgreich bleiben 
wird ist die Frage. Im Moment sind sie das und für das, was sie 
eingesetzt werden reicht natürlich die Emulation von Funktionalitäten. 
SDCC (und damit auch dir) sei Dank hab ich mit PDK gespielt und es ist 
schon irgendwie ein "back to the roots" mit denen etwas zu erstellen. 
Die - für mich - wichtigsten Funktionalitäten: I2C, SPI und UART waren 
kein Problem (sogar I2C-Slave geht mit Abstrichen). Allerdings kann ich 
mir auch vorstellen, dass, wenn jemand auftaucht der das noch billiger 
machen kann es dann eben noch billiger gemacht wird. Ich glaube nicht 
dass Padauk auf eine große Kontinuität der Produktlinie großen Wert 
legt. Wenn etwas nicht am Markt einschlägt, wird es vom Markt genommen. 
So geschehen am Beispiel PFS173. Der war wirklich sehr kurz am Markt und 
wurde dann wieder eingestellt (auch wenn es dafür einen Nachfolger 
gibt).

Hier ging es ja nur um eine Einschätzung und irgendwie fehlt mir das 
"Vertrauen" hier in Padauk. Grundsätzlich aber wird der Markt 
entscheiden, ob es PDK geben wird oder nicht.

Um es mit Radio Eriwan zu sagen: Kann sein, dass es PDK noch in 10 
Jahren geben wird oder auch nicht.

Eine Frage für das Überleben sehe ich auch in der Frage der 
Entwicklungstoolchain. Vielleicht kann ich das nicht so richtig 
beurteilen, aber die zu PDK gehörende Toolchain mit einem Pseudo-C ist 
für mich nicht so wirklich berrauschend und im Moment sehe ich als 
Alternative nur Euren SDCC an den ich im Längen besser empfinde als das, 
was Padauk anbietet. Die Frage hier ist dann, ob im kommerziellen Umfeld 
der SDCC eingesetzt wird ?!?

Vordergründig - so erscheint es mir - wurde PDK für den chinesischen 
Markt entwickelt und das ist auch deren Zielmarkt. Was die Chinesen so 
alles treiben und was sie akzeptieren und was nicht erschließt sich mir 
nicht immer so ganz. Allerdings gibt ihnen der Erfolg und das Wachstum 
der letzten Jahre recht.

[C-hater (c-hater)]

Ralph S. schrieb:

> Ein DMA habe ich in einem
> 8-Bitter noch gar nicht gesehen (was nicht heißt dass es das nicht
> gibt).

Siehe z.B. ATXmega. Da gibt's das. Gab es vor Jahrzehnten schon.

[Philipp Klaus K. (pkk)]

C-hater schrieb:
> Ralph S. schrieb:
>
>> Ein DMA habe ich in einem
>> 8-Bitter noch gar nicht gesehen (was nicht heißt dass es das nicht
>> gibt).
>
> Siehe z.B. ATXmega. Da gibt's das. Gab es vor Jahrzehnten schon.

Oder noch älter (aus dem Z180-Datenblatt): "The Z8X180 contains a 
two-channel DMA (Direct Memory Access) controller which supports high 
speed data transfer. […]"

[(prx) A. K. (prx)]

Beim RCA 1802 Mikroprozessor von 1974 war DMA integraler Teil der CPU.

Zusammen mit dem AY-3-1015, einem einfachen Async-Chip der damaligen 
Ära, kann man darüber ein ROM-loses System seriell urladen.

[Harald K. (kirnbichler)]

Bei 8-Bit-Mikroprozessoren war DMA durchaus üblich, aber halt nicht wie 
bei einem Microcontroller auf einem Chip, sondern als Bestandteil der 
diversen Peripheriebausteine, die zusätzlich zum Einsatz kommen konnten.

Die 68xx-Reihe hatte dafür den 6844, die Z80-Familie hatte den Z8410 
oder Z8420, die i8080-Reihe hatte den i8257 und den i8237 (der auch im 
IBM PC bis IBM AT verwendet wurde) - nur die 6502-Reihe hatte keinen 
DMA-Controller, weil aus Kostengründen auf die notwendige 
Tristatefähigkeit des Adressbusses der CPU verzichtet wurde. Mit einigem 
Aufwand ließ sich das natürlich nachrüsten, aber das war dann keine 
standardisierte Lösung, sondern jeweils sehr individuell ausgeführt.

In 8-Bit-Microcontrollern gibt es DMA u.a. in der PIC18F-Reihe oder in 
der STM8L-Reihe, aber das ist keine allgemeine Selbstverständlichkeit.

[Ralph S. (jjflash)]

Okay, ihr habt mich überzeugt: DMA auf 8-Bit MVU's gibt es. ATXmega 
hatte ich nie in Gebrauch, die anderen genannten auch nicht.

Ich bin allerdings auch nicht der Nabel der Welt und es gibt viele 
Dinge, die nicht gesehen habe und dennoch existent sind.

DMA werde ich wohl auf 8 Bit trotzdem nicht einsetzen, dafür wirds dann 
doch STM32.

Allerdings habe ich durch diesen Thread hier "Lust" auf 8 Bit und mache 
mit dem Padauk gerade etwas.

Beim Thread gehts ja darum, welche 8 Bit es in 10 Jahren noch gibt.

[J. S. (jojos)]

Oder welche der 8 Bit Entwickler es in 10 Jahren noch gibt? 😬

[Harald K. (kirnbichler)]

Ralph S. schrieb:
> Beim Thread gehts ja darum, welche 8 Bit es in 10 Jahren noch gibt.

Man kann mit einer gewissen Sicherheit davon ausgehen, daß sowohl PICs, 
AVRs und die MCS-51-Reihe auch in zehn Jahren noch existieren werden. Ob 
weiterhin neue µCs für diese Reihen entwickelt werden, steht auf einem 
anderen Blatt, aber besonders unwahrscheinlich ist das nicht. MCS-51 
sieht man halt eher in irgendwelchen chinesischen Produkten wie dem 
Portfolio von WCH, und damit ist unklar, wie die Halbwertszeit aussieht. 
Da WCH mittlerweile die dritte Controllerarchitektur in ihr Programm 
aufgenommen hat (nach MCS-51 kam ARM und jetzt RISC-V), ist das 
Ausdünnen des MCS-51-Engagements eher wahrscheinlich. Vermutlich müsste 
MCS-51 auch weiterhin von Intel lizenziert werden (falls WCH das macht), 
in dem Fall wäre die Kostenersparnis durch die frei verfügbare 
RISC-V-Architektur ein gewichtiges "Incentive".

[Philipp Klaus K. (pkk)]

Harald K. schrieb:
> Vermutlich müsste
> MCS-51 auch weiterhin von Intel lizenziert werden

MCS-51 wird nicht lizensiert¹, sondern einfach gemacht. Nicht nur in 
China. Falls es je Patente gab, sind die längst ausgelaufen. Und das war 
für viele µC-Hersteller auch der Grund, auf MCS-51 zu setzen.

¹ Wenn man will kann MCS-51 Softcores lizensieren, aber für die 
Architektur selbst braucht es keine Lizenz.

[Harald K. (kirnbichler)]

Philipp Klaus K. schrieb:
> MCS-51 wird nicht lizensiert

Nun, ich schrieb vermutlich.

(Nitpick: lizen_z_iert)

[Peter D. (peda)]

Philipp Klaus K. schrieb:
> MCS-51 wird nicht lizensiert¹, sondern einfach gemacht. Nicht nur in
> China. Falls es je Patente gab, sind die längst ausgelaufen. Und das war
> für viele µC-Hersteller auch der Grund, auf MCS-51 zu setzen.

Ich hab noch ein altes Datenblatt des P89C669 gefunden. Das war ein 8051 
auf 24Bit Adreßraum aufgebohrt, d.h. je 8MB Code und RAM waren 
adressierbar. Der Zugriff erfolgte über 2 24Bit Pointer aus je 3 
Registern.
Ob der P89C669 je produziert wurde oder gleich von NXP eingestampft, ist 
mir nicht bekannt. Philips hatte vermutlich die größte Vielfalt an 
8051-Derivaten.

https://www.nxp.com/docs/en/user-guide/UM_P89C669.pdf

[Tim . (cpldcpu)]

Wahrscheinlich absolut keine mehr. Das liegt einfach daran, dass die 
600-350nm Prozessknoten, in denen 8Bit Flächenvorteile bringt, nach- und 
nach ausgephased werden und damit keine Koostenvorteile mehr bringen.

[Philipp Klaus K. (pkk)]

Tim  . schrieb:
> Wahrscheinlich absolut keine mehr. Das liegt einfach daran, dass die
> 600-350nm Prozessknoten, in denen 8Bit Flächenvorteile bringt, nach- und
> nach ausgephased werden und damit keine Koostenvorteile mehr bringen.

2020, als im Padauk-Katalog noch etwas zum verwendeten Prozess stand, 
gab es zwar noch ein paar, die in 500 nm hergestellt wurden, aber die 
neueren waren bereits in 180 nm.
So ein Padauk-Die hatte damals bei den billigsten in anscheinend 180nm 
eine Fläche von ca 0,25 mm²; daran dürfte sich seither wenig geändert 
haben.

[Tim . (cpldcpu)]

Philipp Klaus K. schrieb:
> Tim  . schrieb:
>> Wahrscheinlich absolut keine mehr. Das liegt einfach daran, dass die
>> 600-350nm Prozessknoten, in denen 8Bit Flächenvorteile bringt, nach- und
>> nach ausgephased werden und damit keine Koostenvorteile mehr bringen.
>
> 2020, als im Padauk-Katalog noch etwas zum verwendeten Prozess stand,
> gab es zwar noch ein paar, die in 500 nm hergestellt wurden, aber die
> neueren waren bereits in 180 nm.
> So ein Padauk-Die hatte damals bei den billigsten in anscheinend 180nm
> eine Fläche von ca 0,25 mm²; daran dürfte sich seither wenig geändert
> haben.

Ich finde die Padauk devices auch ziemlich interessant. Allerdings 
nutzen die ziemlich wilde Tricks um die Chipfläche zu reduzieren - z.B. 
aggressiv circuit under pad, sehr kleine MTP/OTP Zellen (die vermutlich 
keine Auto-Qual überstehen würden), offensichtlich vereinfachte ESD 
Struktur, Kompromisse in der Entstörung (Siehe Einschränkungen bezüglich 
"EFT"), altertumliches ISP interface, kein debugging. Ein "sauberes" 
Design, würde deutlich größer werden und der Vorteil des 8bit cores 
würde sich reduzieren.

Inzwischen gibt es RISC-V und CM0 devices auch für unter 10c. Die 
benötigen vielleicht 1-2mm² 90nm bis 180nm Silizium und kommen mit 
wesentlich mächtigerer Peripherie, mehr Speicher und einem einfacher zu 
programmierenden Core mit vernünftigem ISP interface. Die 8-bit Nische 
wird einfach immer kleiner.

Man sollte sich auch nicht durch Microchip blenden lassen. Ein großer 
Teil von deren Erfolg beruht auf besserer Logistik, Kundensupport, 
Maßgeschneiderter Peripherie usw. (Siehe Buch von Steve Sanghi).

[Harald K. (kirnbichler)]

Tim  . schrieb:
> Allerdings
> nutzen die ziemlich wilde Tricks um die Chipfläche zu reduzieren

Woher stammt dieses Wissen? Bei "Richie" mit seinen Die-Photos muss ich 
das übersehen haben ...

[Tim . (cpldcpu)]

Harald K. schrieb:
> Woher stammt dieses Wissen? Bei "Richie" mit seinen Die-Photos muss ich
> das übersehen haben ...

Was genau hast Du hier übersehen? Dass die CUP nutzen, sieht man z.B. 
hier sehr schön: 
https://electronupdate.blogspot.com/2019/10/padauk-pms171b-s08.html

Das OTP Macro kannst Du ja mal händisch ausmessen und dann die 
IP-Kollegen in Deiner Firma fragen, ob die etwas mit ähnlicher Dichte 
haben.

Der Rest ergibt sich aus den Datenblättern.

[Gerhard O. (gerhard_)]

Moin,

Bitte fasst meine Frage nicht falsch auf: Welche speziellen Gründe gibt 
es sich als Europäer näher mit Padauk und ähnlichen Erzeugnissen 
befassen zu wollen? Fährt man mit unseren eigenen Produkten nicht doch 
besser? Zumindest, was Lesbarkeit und Verfügbarkeit von Dokus und App 
Notes betrifft, meine ich, wäre man mit unseren üblichen Verdächtigen 
besser dran. Irgendwie arbeite ich lieber mit User unseren Manuals. Ist 
es wirklich nur der Preis der Padauk interessant macht?

Kürzlich stand im Forum, daß es einen neuen AVR Klon geben soll, der 
"fast" komplett kompatibel sein soll. Kann dieses "fast" unter Umständen 
möglicherweise aber nicht für ungewünschte nervige Überraschungen 
sorgen?

Was mich betrifft, beschränke ich mich lieber auf Produkte unser eigenen 
industriellen Kultur und Industrie. Padauk ist ja für deren Land OK und 
hat dort in Anbetracht der Produktionsvolumen Sinn; trotzdem macht es 
keinen Spaß mit möglicherweise ungenau und schlecht übersetzten 
Datenblättern und anderen Dokus vom Ausland her arbeiten zu müssen.

Vg,
Gerhard

[Marc X. (marc_x)]

Gerhard O. schrieb:
> Bitte fasst meine Frage nicht falsch auf: Welche speziellen Gründe gibt
> es sich als Europäer näher mit Padauk und ähnlichen Erzeugnissen
> befassen zu wollen? Fährt man mit unseren eigenen Produkten nicht doch
> besser?

Naja wenn deine größte Anforderung es ist die Stückliste günstig zu 
halten macht es schon Sinn, wenn es keinen Bedarf für günstige kleine 
Controller gäbe, wäre auch in Asien kein Markt dafür da.

[Frank O. (frank_o)]

Vielleicht gibt es in ein paar Jahren nur noch Mikrocontroller (wenn man 
die dann noch so nennen kann), denen du deinen "Plan" erzählst und die 
programmieren sich danach selbst, dank der in Hardware eingebauten KI.

Oder aber wir meißeln wieder in Stein, statt in Textverarbeitung tippen.

SCNR

[Arduino F. (Firma: Gast) (arduinof)]

Gerhard O. schrieb:
> Kürzlich stand im Forum, daß es einen neuen AVR Klon geben soll, der
> "fast" komplett kompatibel sein soll. Kann dieses "fast" unter Umständen
> möglicherweise aber nicht für ungewünschte nervige Überraschungen
> sorgen?
Natürlich!

Meinst du den LGT8F328P?
Dann könnte dich die Leistungsfähigkeit überraschen.

PS:
Das Original ist abgekündigt.

Gerhard O. schrieb:
> Was mich betrifft, beschränke ich mich lieber auf Produkte unser eigenen
> industriellen Kultur und Industrie.
Sorry, aber da ist doch nichts...
Und wenn, dann irre teuer.

[Gerhard O. (gerhard_)]

Arduino F. schrieb:
> Gerhard O. schrieb:
>> Kürzlich stand im Forum, daß es einen neuen AVR Klon geben soll, der
>> "fast" komplett kompatibel sein soll. Kann dieses "fast" unter Umständen
>> möglicherweise aber nicht für ungewünschte nervige Überraschungen
>> sorgen?
> Natürlich!
>
> Meinst du den LGT8F328P?
> Dann könnte dich die Leistungsfähigkeit überraschen.
Schon möglich. Aber ich ziehe trotzdem für viele Klein-Projekte unsere 
eigenen Hersteller vor. Da weiß man für gut oder schlecht, woran man 
ist. Auch Werkzeugbeschaffung ist weniger abenteuerlich. Für die weniger 
konservativen Entwickler mit ausreichender Resilienz, ausreichender 
Geduld und Perseverenz mögen Exkursionen in die Gefilden ausländischer 
Hersteller ja durchaus reizvoll sein. Aber das ist nichts für mich, was 
mich angeht. Ich ziehe aus früheren Erfahrungen vor, unnötigen Risiken 
aus dem Weg zu gehen. Jeder von uns kann den eigenen Weg gehen. Man muß 
ja nicht immer recht haben müssen verteidigen:-)

Abgesehen davon hat z.B. Microchip, Atmel, NXP, ST in der Vergangenheit 
mit vielen Device-Typen bewiesen, daß sie willens waren, 
Produkterhältlichkeit so weit wie markttechnisch ernst zu nehmen und 
nicht zu viele Abkündigungen mit unbequemem Ersatz zu verursachen. Nicht 
immer natürlich.
Schlimm ist es eher, wenn bestimmte Kerne ganz aufgegeben werden. Es hat 
Sinn, nur auf solche uC zu setzen die im Markt schon einige Zeit gefragt 
sind.

Wer Bange vor Abkündigungen hat, könnte gleich von Anfang an, ein 
bestimmtes Design so zu planen, daß es mit uC unterschiedlicher 
Hersteller vergleichbar ohne größere Umstände mit nur LP Änderungen 
umgesetzt werden kann. Auch multiple sourcing Familien sind da von 
Interesse. Beim 8051 Kern hatte man ja viel Möglichkeiten.
>
> PS:
> Das Original ist abgekündigt.
>
> Gerhard O. schrieb:
>> Was mich betrifft, beschränke ich mich lieber auf Produkte unser eigenen
>> industriellen Kultur und Industrie.
> Sorry, aber da ist doch nichts...
> Und wenn, dann irre teuer.
Jetzt übertreibst Du etwas maßlos:-)

[Tim . (cpldcpu)]

Gerhard O. schrieb:
> Bitte fasst meine Frage nicht falsch auf: Welche speziellen Gründe gibt
> es sich als Europäer näher mit Padauk und ähnlichen Erzeugnissen
> befassen zu wollen? Fährt man mit unseren eigenen Produkten nicht doch

> Was mich betrifft, beschränke ich mich lieber auf Produkte unser eigenen
> industriellen Kultur und Industrie. Padauk ist ja für deren Land OK und
> hat dort in Anbetracht der Produktionsvolumen Sinn; trotzdem macht es
> keinen Spaß mit möglicherweise ungenau und schlecht übersetzten
> Datenblättern und anderen Dokus vom Ausland her arbeiten zu müssen.

Merkwürdig, so etwas im Jahre 2023 noch lesen zu müssen. Padauk ist 
übrigens eine Firma aus Taiwan. Die gesamte Dokumentation und Toolchain 
ist auch auf English verfügbar, so dass nicht davon auszugehen ist, dass 
sie nur auf den lokalen Market oder mainland China abzielen.

[Philipp Klaus K. (pkk)]

Gerhard O. schrieb:
> […]
> Schon möglich. Aber ich ziehe trotzdem für viele Klein-Projekte unsere
> eigenen Hersteller vor. Da weiß man für gut oder schlecht, woran man
> ist. Auch Werkzeugbeschaffung ist weniger abenteuerlich. […]
>
> Abgesehen davon hat z.B. Microchip, Atmel, NXP, ST in der Vergangenheit
> mit vielen Device-Typen bewiesen, daß sie willens waren,
> Produkterhältlichkeit so weit wie markttechnisch ernst zu nehmen und
> nicht zu viele Abkündigungen mit unbequemem Ersatz zu verursachen. Nicht
> immer natürlich.
> Schlimm ist es eher, wenn bestimmte Kerne ganz aufgegeben werden. Es hat
> Sinn, nur auf solche uC zu setzen die im Markt schon einige Zeit gefragt
> sind.


Wo finde ich denn, abgesehen vom S08 bei NXP als "Europäer" diese 
"eigenen Produkte"?

Microchip und Atmel sind / waren keine europäischen Firmen. ST ist 
europäisch, gibt aber nun mit dem STM8 seine letzte 8-Bit-Architektur 
auf.
NXP hat innerhalb von knapp 20 Jahren die Architektur von HC05 auf HC08, 
dann auf S08 und RS08 gewechselt. Heute ist nur noch der S08 aktuell, 
und die anderen werden von den aktuellen Werkzeugen des Herstellers 
nicht mehr unterstützt.

[Stefan F. (Gast)]

J. S. schrieb:
> welche der 8 Bit Entwickler es in 10 Jahren noch gibt

Das ist eine Unsinnige Frage. Es gibt keine 8 Bit Entwickler. Wer 
Software für 8 Bit Geräte entwickeln kann, der kommt auch mit mehr oder 
weniger Bits zurecht.

[Stefan F. (Gast)]

Gerhard O. schrieb:
> Welche speziellen Gründe gibt es sich als Europäer näher mit
> Padauk und ähnlichen Erzeugnissen befassen zu wollen?

Manche Leute fröhnen der "Geiz ist geil" Mentalität, koste es was es 
wolle.

[Harald K. (kirnbichler)]

Gerhard O. schrieb:
> Aber ich ziehe trotzdem für viele Klein-Projekte unsere
> eigenen Hersteller vor.

Du machst also keine Klein-Projekte, sonst hättest Du mitbekommen, daß 
es keine "unseren eigenen Hersteller" mehr gibt, schon lange nicht mehr.

[J. S. (jojos)]

Stefan F. schrieb:
> Manche Leute fröhnen der "Geiz ist geil" Mentalität, koste es was es
> wolle.

was hat es mit Geiz zu tun für Billigprodukte auch entsprechend billige 
Komponenten einzusetzen? Es gibt eben Produkte da darf ein Controller 
nichts oder nur ein paar cent kosten. Das wird dann auch nichts sein was 
Langzeitverfügbar sein muss.
Im Hobbybereich sehe ich nur den Sportsgeist etwas so billig oder 
einfach wie möglich zu bauen. Oder wenn die Controller in großen 
Stückzahlen gebraucht werden, etwas wenn man sein eigenes 
Miniaturwunderland bauen will.

[J. S. (jojos)]

Stefan F. schrieb:
> Das ist eine Unsinnige Frage.

Na einige haben ja scheinbar eine große mentale Hürde, siehe Moby.

[C-hater (c-hater)]

Philipp Klaus K. schrieb:

> Microchip und Atmel sind / waren keine europäischen Firmen.

Nunja, Atmel ist zwar von Hause aus eine US-Firma, aber die 
µC-Entwicklung lag bei der norwegischen Tochter, Produktion war in den 
USA und in Europa (auch in Deutschland, nämlich in Heilbronn).

Alles in allem jedenfall sehr viel "europäischer" als etwa Padauk...

[Uwe D. (monkye)]

Vielleicht kostet die Einarbeitung in das Padauk-Ökosystem ja nur 5 Tage 
oder eben 50 Tage - keine Ahnung. Diese Einarbeitung erhöht, zusammen 
mit der neuen Hardware - sofern man sowas braucht, die Einstandskosten.

Und ich finde die vorgetragenen Argumente - z.B. kostenoptimierte 
Massenprodukte (Spielzeug, optimistische 2 Jahre Lebensdauer), 
sportlicher (privater) Ehrgeiz, Neugier usw. alle legitim. Und 
langlebige, gut eingeführte und zuverlässige Produkte (vielleicht noch 
zertifiziert), da gelten dann andere Bedingungen.

Es ist halt von dem Ziel des Projektes abhängig, was mehr oder weniger 
sinnvoll ist. Manchmal hilft es, die Perspektive zu wechseln und sich zu 
fragen, ob die persönliche Sicht nicht hauptsächlich aus Scheuklappen 
besteht… (ohne Jemanden zu Nahe treten zu wollen)

[Gerhard O. (gerhard_)]

Moin,

Anhand Eurer meisten Antworten, finde ich, daß ich mich wohl nicht kjar 
genug ausgedrückt habe. Erstmal, N.A. ist mein Standort. Da sind 
westliche Hersteller vorrangig. Zweitens arbeite ich, ausser für Hobby 
Projekte, durchwegs nur an industriellen Projekten im Energiesektor, wo 
es uns nicht in den Sinn kommen würde, uns mit Herstellern wie Padauk zu 
befassen. Für unsere Projekte kommen durchwegs fast nur noch größere 
32-Bitter zum Einsatz, wo uC Preis keine Rolle spielt. 8-Bit nur noch 
für spezielle Unterstützungsrollen oder in-house Laborprojektchen. Auch 
da spielt Preis kein Rolle. Auch Arduino HW hat sich für spezielle 
in-house Laboranwendungen und unterstützende temporäre Aufgaben gut 
bewährt. Ich sehe keinen Grund, warum wir nichts "Richtiges" von den 
üblichen Herstellern finden könnten. Meistens bleiben wir ohnehin bei uC 
Typen mit denen vorher schon gearbeitet wurde. Das erspart durch 
Wiederverwendung vorheriger Arbeitserkenntnisse Zeit und Geld nebst 
Erfahrung. Was 8-Bit betrifft, gibt es bei MC genug Auswahl. Da halte 
ich mich lieber an das Angebot von Digikey, Mouser und Co.

Ich sehe, was uns betrifft, keinen triftigen Grund zum Experimentieren. 
Jeder kann doch selber entscheiden was er tun will. Es besteht überhaupt 
keine Veranlassung zum Missionieren. Für uns ist Padauk ein Hersteller 
für einen gänzlich anderen Markt und Zielgruppe. Ich hoffe ihr habt mich 
jetzt besser verstanden. Ich sehe nicht den geringsten Grund, bei uC 
nach asiatischen Konsumer IP-Produkten in diesen Sektur Ausschau zu 
halten. Warum soll das Sinn haben, wenn ich z.B. bei MC viel "näheren" 
Zugang mit erstklassigen Dokus habe? Aus diesem Blickwinkel ist mir das 
Interesse an Padauk u.ä. vollkommen unverständlich. Die Töchter anderer 
Mütter dürften sicherlich hin und wieder auch schön sein. Trotzdem 
besteht kein triftiger Grund sie näher miteinzubeziehen.

Jedenfalls tut es mir im Nachhinein leid, mich überhaupt zu meinen 
Beiträgen hingerissen zu haben. Ich sehe eben die Dinge von hier aus 
etwas anders. Ausser unzähligen substanzlosen anonymen Minuspunkten 
bringt es ohnehin nichts ein:-)

VG,
Gerhard

[Marc X. (marc_x)]

Gerhard O. schrieb:
> Ich sehe, was uns betrifft, keinen triftigen Grund zum Experimentieren.
> Jeder kann doch selber entscheiden was er tun will. Es besteht überhaupt
> keine Veranlassung zum Missionieren. Für uns ist Padauk ein Hersteller
> für einen gänzlich anderen Markt und Zielgruppe.

Na dann ist das ganze natürlich für euch uninteressant, aber wie du ja 
selbst bemerkt hast, es gibt Bereiche wo es Sinn macht.

[Veit D. (devil-elec)]

Arduino F. schrieb:
> Gerhard O. schrieb:
>> Kürzlich stand im Forum, daß es einen neuen AVR Klon geben soll, der
>> "fast" komplett kompatibel sein soll. Kann dieses "fast" unter Umständen
>> möglicherweise aber nicht für ungewünschte nervige Überraschungen
>> sorgen?
> Natürlich!
>
> Meinst du den LGT8F328P?
> Dann könnte dich die Leistungsfähigkeit überraschen.
>
> PS:
> Das Original ist abgekündigt.

Hallo,

->-> ATmega328PB <-<-

Leistungsfähigkeit ist so eine Sache wie man das definiert. Mit dem 
Eventsystem und CCL der neuen MC Controllerfamilien umgeht man jede 
Rechenlast und deren Einfluss auf zeitliche Abhängigkeit. Der 
ATmega328PB vs. LGT8F328P wurden in verschiedene Richtungen aufgebohrt. 
Der Vorteil vom 328PB ist das er Binärkompatibel zum 328P ist. 
Austauschen, flashen, fertig.

[Arduino F. (Firma: Gast) (arduinof)]

Veit D. schrieb:
> Leistungsfähigkeit ist so eine Sache wie man das definiert.
In dem Fall recht einfach...
32MHz auch schon bei 3,3V
Einige ASM Statements, welche mit 1 Takt weniger auskommen.
12 Bit ADC
DAC
Timer/PWM mit DeadTime Gedönse

Ansonsten:
Keine Fuses, kein EEPROM

Befehlssatz wie ATMega328P
Gleiche Signatur.

usw.

Es ist also schon einiges anders.

[Frank O. (frank_o)]

Gerhard O. schrieb:
> Jedenfalls tut es mir im Nachhinein leid, mich überhaupt zu meinen
> Beiträgen hingerissen zu haben.

Hallo Gerhard,
ich kann dich gut verstehen.
Aber trotzdem freue ich mich nicht nur von dir zu lesen, sondern auch 
über deinen (sehr fachkundigen) Blick auf die Dinge.
Da du zunächst einmal ein Vollprofi bist und auch private Projekte hast, 
kannst du das sehr wohl und sehr gut beurteilen.
Auch wenn ich das selbst nicht so betreibe (auch nie so betrieben habe), 
kenne ich aus meiner Tätigkeit wie teils sehr große Industriefirmen, 
aber auch sehr kleine und spezialisierte Firmen so etwas machen und das 
deckt sich mit deinen Aussagen.
Ganz liebe Grüße
Frank

[Gerhard O. (gerhard_)]

Hallo Frank,

Es ist gut von Dir zu hören und hoffe, es geht Dir gut. Was das andere 
betrifft, reiten wir alle mehr oder weniger auf den Schultern 
diejenigen, die vor uns kamen und Wege bereiteten.

Zur Zeit leiden wir hier schon ewig lang unter der schlechten Luft wegen 
der vielen Waldbrände.

VG,
Gerhard

[Gerhard O. (gerhard_)]

Arduino F. schrieb:
> Veit D. schrieb:
>> Leistungsfähigkeit ist so eine Sache wie man das definiert.
> In dem Fall recht einfach...
> 32MHz auch schon bei 3,3V
> Einige ASM Statements, welche mit 1 Takt weniger auskommen.
> 12 Bit ADC
> DAC
> Timer/PWM mit DeadTime Gedönse
>
> Ansonsten:
> Keine Fuses, kein EEPROM
>
> Befehlssatz wie ATMega328P
> Gleiche Signatur.
>
> usw.
>
> Es ist also schon einiges anders.

Naja, MC hat ja mit den feinen DB AVRs nachgezogen und der 328PB ist ja 
auch viel fähiger als sein Namensbruder ohne dem "B" dahinter.

Ob die anderen erwähnten Verbesserungen sooo viel Gewicht haben, wage 
ich zu bezweifeln. Mir reicht die Performanz der üblichen uC im 
Allgemeinen eigentlich schon. Wirklich schnelle zeitkritische Sachen 
macht man besser ohnehin mit FPGAs oder CPLDs. Einen uC aus sportlichen 
Motivationen in eine Zwangsjacke fester Zyklen zu stecken, finde ich 
persönlich uncool, speziell wenn in komplizierten Anwendungen asynchron 
viele unregelmäßige Interrupts den zügigen Ablauf stören können und 
beeinträchtigen die Resilienz der Anwendung. Die Timing der Main loop 
sollte idealerweise immer eine gewisse "Narren-" oder Laufzeitfreiheit 
haben und von den berüchtigten blockierenden Logik-Konstrukten frei 
bleiben.

[Arduino F. (Firma: Gast) (arduinof)]

Gerhard O. schrieb:
> Naja, MC hat ja mit den feinen DB AVRs nachgezogen und der 328PB ist ja
> auch viel fähiger als sein Namensbruder ohne dem "B" dahinter.

Du!
Exakt Du hast das Thema mit den Fernost AVR Nachbauten auf den Tisch 
gebracht.
Dir "Überraschungen" damit erwünscht.

Ja, ich verstehe, dass dir "positive" Überraschungen nicht schmecken, da 
sie dir offensichtlich nicht in den Kram passen.
Ich verstehe, dass du lieber über schlechte Dokumentationen und Probleme 
lästern möchtest.


Der Rest hat auch wenig mit dem Titel zu tun....
> Welche 8-Bit-Architekturen werden in 10 Jahren relevant sein?

Ich persönlich erwarte nicht, dass die offizielle AVR Linie vollständig 
eingestampft wird, in den nächsten Jahren.
Und selbst wenn, dann steht Fernost in den Startlöchern, um die Lücke 
mit Nachbauten zu füllen.
Mit billigeren und Leistungsfähigeren µC.

Zudem wird Chinaland RISC-V vorantreiben. Preiswert und Leistungsfähig. 
Meine Prognose, an der Stelle: ARM wird durch 64Bit RISC-V auf Händis, 
Tablets und sonstigen Kleingeräten ersetzt werden.

Ob 10 Jahre dafür reichen? KA!
Aber der RISC-V Zug ist schon auf der Bahn, wenn auch erst noch 
hauptsächlich auf der 32Bit Schiene.

[Peter D. (peda)]

Arduino F. schrieb:
> Meinst du den LGT8F328P?

Gibt es den irgendwo zu kaufen?
Ich finde immer nur Platinen damit, aber keine einzelnen Chips.

[Arduino F. (Firma: Gast) (arduinof)]

Peter D. schrieb:
> aber keine einzelnen Chips
Vielleicht nicht bei deutschen Händlern...

Aber Ali Express usw. bieten da schon was an.

z.B.:
https://www.alibaba.com/product-detail/LGT8F328P-Original-QFP32-Electronic-Components-LGT8F328_1600754576350.html

Aber hast schon recht das meiste wird wohl (zur Zeit?) in Form von 
Arduino kompatiblen Boards hier rüber schwappen.

[Gerhard O. (gerhard_)]

Arduino F. schrieb:
> Gerhard O. schrieb:
>> Naja, MC hat ja mit den feinen DB AVRs nachgezogen und der 328PB ist ja
>> auch viel fähiger als sein Namensbruder ohne dem "B" dahinter.
>
> Du!
> Exakt Du hast das Thema mit den Fernost AVR Nachbauten auf den Tisch
> gebracht.
> Dir "Überraschungen" damit erwünscht.
Komm. Jetzt schalte mal das Getriebe zurück. Warum so borstig? Es hat 
mich tatsächlich interessiert. Wäre eigentlich nett von Dir, mir 
Datenblätter Links zu zeigen wo ich Einblick nehmen könnte; welche 
bewährte Programmiergeräte es gibt und zugänglich sind und angepaßte 
Entwicklungs- SW.
>
> Ja, ich verstehe, dass dir "positive" Überraschungen nicht schmecken, da
> sie dir offensichtlich nicht in den Kram passen.
Das kannst Du nicht wirklich wissen. Und wenn schon. Ist doch meine 
Sache.
> Ich verstehe, dass du lieber über schlechte Dokumentationen und Probleme
> lästern möchtest.
Lästern? Keine Spur. Warum sollte ich mir die Mühe machen über den Zaun 
zu schauen, wenn ich lokal schon alles griffbereit habe und mir bekannt 
ist wo alles zu finden ist.

Ich sage mal so: wenn der Hersteller es schafft, die besagten Devices 
ins Lieferprogramm von Digikey, Mouser, Newark zu bringen, nebst guten 
Links zu allen relevanten Papieren und zuverlässiger Belieferung, dann 
sehen wir vielleicht weiter. Solange sie nur über ALI und Co. erhältlich 
sind, ist es für mich wenig interessant. Klingt hart, ist aber so.
>
>
> Der Rest hat auch wenig mit dem Titel zu tun....
>> Welche 8-Bit-Architekturen werden in 10 Jahren relevant sein?
>
> Ich persönlich erwarte nicht, dass die offizielle AVR Linie vollständig
> eingestampft wird, in den nächsten Jahren.
> Und selbst wenn, dann steht Fernost in den Startlöchern, um die Lücke
> mit Nachbauten zu füllen.
> Mit billigeren und Leistungsfähigeren µC.
Um unsere Zivilisation mit noch mehr spionierenden unnützen Iot e-Muell 
zu beglücken den niemand braucht? Auf einen solchen Markt verzichte ich 
gerne.
>
> Zudem wird Chinaland RISC-V vorantreiben. Preiswert und Leistungsfähig.
> Meine Prognose, an der Stelle: ARM wird durch 64Bit RISC-V auf Händis,
> Tablets und sonstigen Kleingeräten ersetzt werden.
Papier ist geduldig...
>
> Ob 10 Jahre dafür reichen? KA!
> Aber der RISC-V Zug ist schon auf der Bahn, wenn auch erst noch
> hauptsächlich auf der 32Bit Schiene.
Man wird sehen...

[Arduino F. (Firma: Gast) (arduinof)]

Gerhard O. schrieb:
> Um unsere Zivilisation mit noch mehr spionierenden unnützen Iot e-Muell
> zu beglücken, den niemand braucht?

Wir haben explizit über die Zukunft von 8 Bit Dingern gesprochen, im 
speziellen über den AVR Kern, oder seinen Nachbauten.
Da musst du nicht mit solchen Strohmann Argumenten kommen.

MicroChip kündigt den ATMega328P ab, China bietet einen Ersatz, und du 
siehst darin den Untergang der Zivilisation...
Mir scheint, du bist heute etwas verwirrt.

Gerhard O. schrieb:
> Das kannst Du nicht wirklich wissen. Und wenn schon. Ist doch meine
> Sache.
Deine Aussagen sind vorgespannt/biased.
Grob formuliert: Ich sehe rassistische und diskriminierende Tendenzen.
Und da ich mich gerade mit dir unterhalte, ist das nicht nur "deine" 
Sache, denn du trittst mir mit dieser Einstellung entgegen

[Gerhard O. (gerhard_)]

Arduino F. schrieb:
> Gerhard O. schrieb:
>> Um unsere Zivilisation mit noch mehr spionierenden unnützen Iot e-Muell
>> zu beglücken, den niemand braucht?
>
> Wir haben explizit über die Zukunft von 8 Bit Dingern gesprochen, im
> speziellen über den AVR Kern, oder seinen Nachbauten.
> Da musst du nicht mit solchen Strohmann Argumenten kommen.
Das bezieht sich auf das:
> Mit billigeren und Leistungsfähigeren µC.
>
> MicroChip kündigt den ATMega328P ab, China bietet einen Ersatz, und du
> siehst darin den Untergang der Zivilisation...
> Mir scheint, du bist heute etwas verwirrt.
MC kündigt nur die DIP Version ab. Alles andere ist davon nicht 
betroffen. Und wenn schon. Der 328PB ist ein guter Ersatz mit mehr 
Fähigkeiten. NANOS und Pro-Minis nur mit dem 328PB wären mir sogar sehr 
willkommen und gibt es ohnehin schon vereinzelt. Und der 328 ist nicht 
das Maß aller Dinge. Es gibt noch genug andere uC in den Reihen der 
AVRs. Ob ich einen AVR oder PIC nehme spielt meist ohnehin keine große 
Rolle.
>
> Gerhard O. schrieb:
>> Das kannst Du nicht wirklich wissen. Und wenn schon. Ist doch meine
>> Sache.
> Deine Aussagen sind vorgespannt/biased.
Dankend angenommen;-)
> Grob formuliert: Ich sehe rassistische und diskriminierende Tendenzen.
Nein Pragmatik. Als Hersteller von Elektronik muss man aufpassen. 
Solange unsere Distributoren es nicht ins Lieferprogramm bringen ist es 
für uns vollkommen uninteressant.
> Und da ich mich gerade mit dir unterhalte, ist das nicht nur "deine"
> Sache, denn du trittst mir mit dieser Einstellung entgegen
Nur Dir. Ich schlage aber vor zu beenden, weil Dein P.O.V. nicht 
wirklich zutreffend ist. Ich habe jetzt keine Zeit zum muessigen 
Diskutieren. Es steht uns frei zu denken was uns beliebt. Ich muss hier 
im Forum nicht recht haben. Also scheiden wir in Frieden. Schönen Tag 
noch.

[Steve van de Grens (roehrmond)]

Arduino F. schrieb:
> MicroChip kündigt den ATMega328P ab

weil sie lieber dessen Nachfolger ATMega328PB verkaufen wollen. Der ist 
nicht abgekündigt, sondern sogar "Recommended for Automotive Design".

Fake News enstehen selten durch Lügen, sondern durch das Weglassen 
relevanter Informationen.

[Gerhard O. (gerhard_)]

Moin,

Ich kann nicht verhehlen, daß ich heute das erste Mal Google bemühte 
nach Padauk technischen uC Informationen zu suchen, um mir einen 
explorativen Überblick verschaffen zu können.

Ich fand übrigens diesen informativen Beitrag:

https://jaycarlson.net/2019/09/06/whats-up-with-these-3-cent-microcontrollers/

Gerhard

[Philipp Klaus K. (pkk)]

Gerhard O. schrieb:
> Moin,
>
> Ich kann nicht verhehlen, daß ich heute das erste Mal Google bemühte
> nach Padauk technischen uC Informationen zu suchen, um mir einen
> explorativen Überblick verschaffen zu können.
>
> Ich fand übrigens diesen informativen Beitrag:
>
> https://jaycarlson.net/2019/09/06/whats-up-with-these-3-cent-microcontrollers/
>
> Gerhard

Auch https://free-pdk.github.io/ ist als Überblick über Padauk-µC und 
tools dafür nützlich.

[Arduino F. (Firma: Gast) (arduinof)]

Gerhard O. schrieb:
> Ich kann nicht verhehlen, daß ich heute das erste Mal Google bemühte
> nach Padauk technischen uC Informationen zu suchen, um mir einen
> explorativen Überblick verschaffen zu können.

Immerhin!

Ist zwar die falsche Reihenfolge, aber immerhin.

Meine Bitte an dich:
Nächstes mal, erst kundig machen und dann urteilen.

[Gerhard O. (gerhard_)]

Arduino F. schrieb:
> Gerhard O. schrieb:
>> Ich kann nicht verhehlen, daß ich heute das erste Mal Google bemühte
>> nach Padauk technischen uC Informationen zu suchen, um mir einen
>> explorativen Überblick verschaffen zu können.
>
> Immerhin!
>
> Ist zwar die falsche Reihenfolge, aber immerhin.
>
> Meine Bitte an dich:
> Nächstes mal, erst kundig machen und dann urteilen.

Moin,

Uff! Du bist ein schwieriger Fall für mich;-)

Wie in dem verlinkten Beitrag und anderen Internet Informationen sehr 
ersichtlich ist, wurden die besagten uC für einen bestimmt Massenmarkt 
ins Leben gerufen und sind für den Großeinsatz in (einfach(st)en) 
Massenprodukten vorgesehen. Für mein typisches Interessengebiet und 
Anwendungen sind sie aber aus verschiedenen Gründen technisch einfach 
eine schlechte Wahl und vermissen Peripherien die mir wichtig sind. Auch 
sind mir die Speicher Ressourcen zu mager.

Auch ist die Programmierung sehr "abenteuerlich" und hat viele 
Einschränkungen die man bei normalem C/C++ nicht hat. Auch sind 
Berechnungen viel umständlicher. Warum soll ich mir das antun? Aus dem 
Alter wo sportliche Motivationen mitspielen, bin ich heraus.

(Ich sehe solche ULtra-niedrig billigen Controller im Übrigen eher als 
ein negatives Kriterium, weil solch billigst Elektronik die Vermarktung 
von unnützer Wegwerfelektronik und unnötigen Konsumerspielereien 
provoziert. Das ist hinsichtlich auf Ressourcenverschwendung und 
Umweltbelastung ein grosses Manko. Abgesehen davon, will ich als 
Konsumer wirklich unreparierbare Billigst Elektronik in meinen Sachen 
Zuhause, an denen noch aggressiver um jeden Cent geknausert wurde? Mir 
ist Produktqualität wichtig.)

Jedenfalls kann ich mit Sicherheit ausschließen, daß ich Padauk 
Controller jemals für irgendwelche Zwecke verwenden würde. Die kleinsten 
uC unserer Hersteller sind da immer noch günstig genug. Sogar der 
ATMEGA328PB mit Digikey Preis von 1,59 € ist mir niedrig genug und kann 
wesentlich mehr. Als Hobbyist ist mir das erschwinglich genug und kann 
mir schon erschwingliche fertige Bords überall damit kaufen.

Wenn Dir Padauk Controller Freude machen, ist es ja alles schön und gut; 
und wenn sie von Dir nützlich eingesetzt werden können, ist ja alles in 
Ordnung. Nur mich interessieren sie aus obig genannten Gründen nicht 
wirklich. Aber deswegen brauchen wir uns ja nicht zu zerfleischen und 
sollten als erwachsene Menschen imstande sein, das zu respektieren. 
Missionarische Tendenzen sind schlicht unangebracht.

Gerhard

[Frank O. (frank_o)]

Gerhard O. schrieb:
> Uff! Du bist ein schwieriger Fall für mich;-)

Ignorieren. Der ist eben anders. Und dann diese Belehrungsversuche. Ich 
nenne solche Leute "Pfortnermentalität".

[Falk B. (falk)]

Gerhard O. schrieb:
> Jedenfalls kann ich mit Sicherheit ausschließen, daß ich Padauk
> Controller jemals für irgendwelche Zwecke verwenden würde. Die kleinsten
> uC unserer Hersteller sind da immer noch günstig genug. Sogar der
> ATMEGA328PB mit Digikey Preis von 1,59 € ist mir niedrig genug und kann
> wesentlich mehr. Als Hobbyist ist mir das erschwinglich genug und kann
> mir schon erschwingliche fertige Bords überall damit kaufen.

BINGO!

[Irgend W. (Firma: egal) (irgendwer)]

Falk B. schrieb:
> Gerhard O. schrieb:
>> Jedenfalls kann ich mit Sicherheit ausschließen, daß ich Padauk
>> Controller jemals für irgendwelche Zwecke verwenden würde. Die kleinsten
>> uC unserer Hersteller sind da immer noch günstig genug. Sogar der
>> ATMEGA328PB mit Digikey Preis von 1,59 € ist mir niedrig genug und kann
>> wesentlich mehr. Als Hobbyist ist mir das erschwinglich genug und kann
>> mir schon erschwingliche fertige Bords überall damit kaufen.
>
> BINGO!

Die viel größere Frage aber ist, ob Microchip die Stückzahlen von den 
paar Hobbybastler langen um die auch zukünftig noch für den Preis 
anbieten können. Die wo die Dinger millionenfach verbauen schauen nunmal 
auf jeden Cent und da wird das genommen, was am billigsten ist und 
gerade so die Anforderungen erfüllt, völlig frei von irgendwelchen 
Sentimentalitäten.

Das sind einfach zwei total unterschiedliche Baustellen. Das was dem 
Hobbybastler langt und er bereit ist zu bezahlen und das was die 
Abnehmer großer Stückzahlen machen.

[Irgend W. (Firma: egal) (irgendwer)]

Gerhard O. schrieb:
> ... will ich als Konsumer wirklich unreparierbare Billigst Elektronik in meinen 
Sachen
> Zuhause, an denen noch aggressiver um jeden Cent geknausert wurde?...

Sehr viele leider Ja.

Was glaubst du wenn es z.B. im November interessiert wenn er sich im 
Supermarkt eine Kette Weihnachtsflackerkerzen kauft von welcher Qualität 
die darin verbaute Elektronik ist? Die meisten schauen da ja noch nicht 
mal auf das Netzteil/Knallfrosch den sie sich da ins Haus holen. Welcher 
billigst-µC da für das Flackern verwendet wird interessiert erstrecht 
niemanden.
Anfang Januar landet das ganze sowieso in der (Haus-)Mülltonne - nimmt 
ja beim Einlagern nur unnötig Platz weg und es ist ja so schön Billig da 
rentiert sich das garnicht aufzuheben und nächstes Jahr ist ja sowieso 
alles noch Besser/Schöner/Billiger.

Die große Masse der Kunden tickt nunmal nach Hauptsache Billing und 
möglichst oft was Neues. Die interessiert noch eher ob auf ihrem 
Eierkarton ein Bild von glücklichen Hühnern drauf ist als die 
Bedingungen unter denen ihre Billigelektronik hergestellt (und auch 
wieder entsorgt) wird. Wie Welt ist hier schon arg krank........

Gerhard O. schrieb:
> ... an denen noch aggressiver um jeden Cent geknausert wurde?...

Das Bescheuerte heutzutage ist, dass man selbst bei teuren Sachen nicht 
sicher sein kann ob die nicht nach genau derselben Devise 
Zusammengeschustert wurden und man am ende nur mehr Geld für dieselbe 
Scheiße bezahlt. Nur halt in einem hübscheren Gehäuse.

[Gerhard O. (gerhard_)]

Irgend W. schrieb:
> Falk B. schrieb:
>> Gerhard O. schrieb:
>>> Jedenfalls kann ich mit Sicherheit ausschließen, daß ich Padauk
>>> Controller jemals für irgendwelche Zwecke verwenden würde. Die kleinsten
>>> uC unserer Hersteller sind da immer noch günstig genug. Sogar der
>>> ATMEGA328PB mit Digikey Preis von 1,59 € ist mir niedrig genug und kann
>>> wesentlich mehr. Als Hobbyist ist mir das erschwinglich genug und kann
>>> mir schon erschwingliche fertige Bords überall damit kaufen.
>>
>> BINGO!
>
> Die viel größere Frage aber ist, ob Microchip die Stückzahlen von den
> paar Hobbybastler langen um die auch zukünftig noch für den Preis
> anbieten können. Die wo die Dinger millionenfach verbauen schauen nunmal
> auf jeden Cent und da wird das genommen, was am billigsten ist und
> gerade so die Anforderungen erfüllt, völlig frei von irgendwelchen
> Sentimentalitäten.
>
> Das sind einfach zwei total unterschiedliche Baustellen. Das was dem
> Hobbybastler langt und er bereit ist zu bezahlen und das was die
> Abnehmer großer Stückzahlen machen.

Naja,

Ich habe nicht den Eindruck, daß Produkte westlicher Hersteller ohne 
große Not Asien IP uC verwenden möchte. Mir ist bis jetzt noch 
diesbezügliches unter den Augen gekommen.

Abgesehen davon wird man in Anbetracht aller Umweltsorgen vielleicht 
doch ein Umdenken stattfinden müssen, daß wenig nützliche Gerätschaften 
uncool sind und der Konsument entgegen aller Prognosis in der nicht zu 
fernen Zukunft zu dieser Erkenntnis eventuell kommen wird. Die junge 
Generation ist sensibilisiert worden und macht sich zunehmend Gedanken 
wie es um ihre Zukunft stehen wird und dass gedankenloser Konsum nicht 
mehr zu übersehende Folgen haben wird. Die Probleme mit den Unmengen an 
Plastikmüll illustriert diese Erkenntnis deutlich. Elektronikentsorgung 
ist auch einer der vielen Schandflecke unserer Zivilisation.

Wenn wir als moderne Zivilisation weiser sein würden, dann müssten wir 
darauf bestehen unsere Produkte langlebiger zu machen, modernisierbar, 
günstig reparierbar, sie an andere weitergeben, wenn wir das Interesse 
daran verloren haben. Es gibt so viele Alternativen gegen Entsorgung. 
Auch sollten wir standardisieren, um unnötige Vielfalt ähnlicher 
Komponentenbaugruppen zu verringern. Mit etwas Willen und Motivation 
könnten wir Viel Unnötiges eliminieren. Ich sehe nicht ein, warum jedes 
KFZ für dieselbe Funktion eigene proprietäre Steuermodule benötigt. Aber 
das ist ein anderes Thema.

Warum werden Elektronikbaugruppen nicht zerlegt und deren 
Komponentenwieder verwendet. Ein Flash programmierter uC ließe sich 
Jahrzehnte in neuen Gerätschaften weiterverwenden, da er sich neu 
programmieren lässt. Die gigantische Verschwendung und Zerstörung 
hochwertiger elektronischer Bauteile ist eigentlich sooo unnötig.

Mir scheint, die Verantwortlichen sind alle in ihren Paradigmen gefangen 
und paralysiert. Sie sehen nicht die Möglichkeiten und Potenzial in 
lateralen Denken. Es wird lieber einfach so wie früher weitergemacht um 
den Status Quo ja nicht umzuwerfen, weil die Courage fehlt, es besser 
machen zu wollen.

Es ist wirklich deprimierend, wenn man weiß, was technisch möglich wäre, 
aber eigennütziges Denken dominant ist und verbessernde Umwälzungen 
andauernd torpedieren werden.

Weniger ist mehr. Wir haben uns alle viel zu sehr mit unnötiger Technik 
zumüllen lassen. Wir würden mit bedachter, selektierter Nutzung von 
Technik glücklicher sein. Auch konsumieren die meisten viel zu viel von 
den Medien. Das müllt m.A.n. eventuell das Gehirn zu und macht die Leute 
nervös und genervt.

In meinen Augen ist eMobilität als totaler Ersatz der Verbrenner ein 
weißer Elefant und Utopie. Es würde an allen Ecken fehlen. Sicher, 
einige wenige sind beeindruckt was eMobilität vermag. Aber für eine 
totale Umstellung? Wie sollen die vielen kWh an Energie aus fossilen 
Brennstoffen ersetzt werden? Wir sind noch lange nicht so weit um alle 
diese Probleme zufriedenstellend lösen zu können.

Zurück zu uC:

Ich mache mir um die Zukunft von Microchip und anderer Verdächtiger 
keine großen Sorgen. Es sind genug Geräteklassen da, die mit 8-Bit 
auskommen und nicht ans Internet angebunden sein müssen. Solange der 
Markt nicht kontraktiert, sollte die Zukunft gesichert sein. Die 
32-Bitter sind eher für solche Anwendungen vorgezogen. Andrerseits ist 
eine Kombination von ESP32 und 8-Bitter auch ziemlich interessant. Die 
kleinen Padauk Controller stoßen da schnell an ihre Grenzen. Für 
kommunikationsintensive Anwendungen scheinen sie ohnehin nicht sehr 
attraktiv zu sein. Auch damit rechnen zu müssen ist nicht angenehm und 
zwingt zu vielen Klimmzügen.

Als Designer ziehe ich einfach die Produkte unserer eigenen Hersteller 
vor, einfach, weil ich es gewöhnt bin und bestimmen kann mit welchen uC 
ich das Projekt ausstatten möchte. Da muß man sich nicht alles immer 
zusammensuchen. Auch kommerzielle Entwicklungswerkzeuge, für die bezahlt 
worden ist, will man lieber gerne verwenden. In der Firma kommt noch 
schwerwiegend dazu, daß man die Früchte und IP früherer Arbeiten 
wiederverwenden will. Da wechselt man nicht leichtfertig die UC 
Hersteller. Die billigst uC lohnen sich nur wenn die Stückzahlen 
entsprechend gigantisch sind.

Da wir in einen freien Land leben, können wir unsere Technik 
entsprechend wählen.

Gerhard

[Falk B. (falk)]

Irgend W. schrieb:
> Die viel größere Frage aber ist, ob Microchip die Stückzahlen von den
> paar Hobbybastler langen um die auch zukünftig noch für den Preis
> anbieten können. Die wo die Dinger millionenfach verbauen schauen nunmal
> auf jeden Cent und da wird das genommen, was am billigsten ist und
> gerade so die Anforderungen erfüllt, völlig frei von irgendwelchen
> Sentimentalitäten.

Stimmt. Aber glaubst du ernsthaft, daß die Welt nur ULTRAbillige 
Mikrocontroller haben will, die zwar fast nix kosten aber auch fast nix 
können und technologisch 10 Jahre und älter sind?
Extrem niedrige Kosten allein machen kein gescheites Produkt.

[Falk B. (falk)]

Gerhard O. schrieb:
> Naja,
>
> Ich habe nicht den Eindruck, daß Produkte westlicher Hersteller ohne
> große Not Asien IP uC verwenden möchte.

Ähhh, was glaubst du wo die PICs, AVRs und alle anderen GEBAUT werden? 
;-)

> Mir ist bis jetzt noch
> diesbezügliches unter den Augen gekommen.

Fehlt da ein "nichts"?

> Abgesehen davon wird man in Anbetracht aller Umweltsorgen

Die massiv durch Propaganda aufgeblasen sind.

> Generation ist sensibilisiert worden und macht sich zunehmend Gedanken
> wie es um ihre Zukunft stehen wird und dass gedankenloser Konsum nicht
> mehr zu übersehende Folgen haben wird.

Mag sein, aber das ist nicht in erster Linie das Problem der 
ultrabilligen Elektronik.

> Die Probleme mit den Unmengen an
> Plastikmüll illustriert diese Erkenntnis deutlich. Elektronikentsorgung
> ist auch einer der vielen Schandflecke unserer Zivilisation.

Naja, nur weil es drekcige Beispiele gibt, heißt das nicht, das ALLES so 
abläuft. Hast du belastbare Zahlen, wieviel E-Schrott weltweit bzw. aus 
Deutschland "fachgerecht" entsorgt wird und wieviel in Afrika landet?

> Wenn wir als moderne Zivilisation weiser sein würden, dann müssten wir
> darauf bestehen unsere Produkte langlebiger zu machen, modernisierbar,
> günstig reparierbar, sie an andere weitergeben, wenn wir das Interesse
> daran verloren haben.

Kannst du alles machen, wenn es dir danach ist und wenn Leute daran 
Interesse haben. Ebay, Kleinanzeigen, Verschenken, vor die Tür stellen. 
Wird alles schon gemacht. Alles was so NICHT weiterverwertet wird, will 
einfach keiner haben, weil es ausreichend Neuware gibt!

> Es gibt so viele Alternativen gegen Entsorgung.

Tu mal nicht so, als ob alles ewig hält oder halten soll oder gar kann. 
Dem ist nicht so. Ja, über bestimmte Nutzungsdauern von bestimmten 
Geräten kann man diskutieren, allen voran vermutlich Smartphones und 
Computer. Aber auch die haben kein endloses Leben, allein auf Grund des 
rasanten, technischen Fortschritts. Man KANN mit einem 10 Jahre alten 
Smartphone nur noch wenig anfangen, bestenfalls telephonieren, bissel 
whatsapp und Bilder machen. Der Rest wird dann schon enger.

> Auch sollten wir standardisieren, um unnötige Vielfalt ähnlicher
> Komponentenbaugruppen zu verringern.

Du trägst Eulen nach Athen. Das gibt es längst. Nur weil es keinen 
Standard Smartphone Akku zum selber Wechseln gibt, wird rumgeheult. Ja, 
TEILWEISE wollen die Hersteller das nicht, auch keine Ersatzteile und 
Reparaturen. Teilweise geht es aber sinnvoll nicht, weil die 
Integrationsdichte extrem geworden ist. AA-Zellen im Smartphone sehen 
komisch aus ;-)

> Mit etwas Willen und Motivation
> könnten wir Viel Unnötiges eliminieren.

Was denn? Askese?

> Ich sehe nicht ein, warum jedes
> KFZ für dieselbe Funktion eigene proprietäre Steuermodule benötigt.

Uhhhh, schon wieder sozialistische Träume. Das würde ich lassen. Been 
there, seen it. Doesn't work properly.

> Warum werden Elektronikbaugruppen nicht zerlegt und deren
> Komponentenwieder verwendet.

Weil du damit den Schinken nach der Wurst wirfst! Wer sich mal GENAU mit 
der Massenproduktion von Elektronik befaßt, wird merken, daß JEDES 
"Anfassen" eines noch so kleinen Bauteiles fast teurer als dessen 
Produktion ist! Wir leben nicht in der Mangelwirtschaft der Ostzone, wo 
Material knapp und Arbeitskraft billig war! Es ist heute genau anders 
herum!

> Ein Flash programmierter uC ließe sich
> Jahrzehnte in neuen Gerätschaften weiterverwenden,

NEIN!

> da er sich neu
> programmieren lässt. Die gigantische Verschwendung und Zerstörung
> hochwertiger elektronischer Bauteile ist eigentlich sooo unnötig.

Du unterschätzt den Aufwand dieser Art von Recycling. Das klingt gut, 
öko und nach Weltrettung, ist aber technisch wie ökonomischer 
Schwachsinn. Außer für Bastler und Liebhaberprojekte nicht zu 
gebrauchen. Oder in Ländern mit extremen Materialmangel wie Kuba. Dort 
funktioniert das, weil es praktisch alternativlos ist!

> Mir scheint, die Verantwortlichen sind alle in ihren Paradigmen gefangen
> und paralysiert.

Hör doch auf mit "die Verantwortlichen", als ob es einen 
Parteifunktionär und "weisen Führer" mit väterlicher Aufgabe dafür gäbe. 
Gibt es nicht! Die Regeln des Marktes im Zusammenhang mit der 
Technologie bestimmen diese Handlungen! Und das ist in den MEISTEN 
Fällen die beste Option. Der Staat hat nur minimale Randbedingungen 
festzulegen wie Arbeitsrecht, Umweltschutz, Steuern. Der Rest ist 
DEUTLICH besser beim Kapitalismus angesiedelt, der bringt in den meisten 
Fällen die besseren Lösungen.

> Sie sehen nicht die Möglichkeiten und Potenzial in
> lateralen Denken.

Aber du mit deiner Nostalgie? Da wäre ich vorsichtig.

> Es wird lieber einfach so wie früher weitergemacht um
> den Status Quo ja nicht umzuwerfen, weil die Courage fehlt, es besser
> machen zu wollen.

Wenn eine neue Idee Potential hat, wird man sie versuchen. OK, kann 
schief gehen, aus verschiedenen Gründen. Aber auch, weil die "tolle 
Idee" praxisuntauglich ist.

> Es ist wirklich deprimierend, wenn man weiß, was technisch möglich wäre,

Was denn? Alte Handies und sonstigen Konsumerkram alles auslöten? Bis 
zum kleinsten Widerstand? C'mon!

> aber eigennütziges Denken dominant ist und verbessernde Umwälzungen
> andauernd torpedieren werden.

Sinnloses Gejammer! Wenn man einigen kapitalistischen Vordenkern glauben 
schenkt, ist der GESUNDE Eigennutz der beste Motor für eine 
wirtschaftlich-technische Entwicklung einer Gesellschaft. Adam Smith, 
wenn ich mich richtig erinnere. Marx war da nur allzu oft praxisfremd 
und akademisch und hat fast alles freie Unternehmertum verteufelt, seine 
"Nachfolger" sowieso. Was dabei rauskommt, konnte und kann man an den 
diversen sozialistischen Experimenten sehen!

Kritik an bestehenden Zuständen ist legitim und nötig, aber bitte keine 
Nostalgie und Gejammer! Der gute Mann bringt es auf den Punkt, naja, 
drei Punkte/Fragen.

https://www.youtube.com/watch?v=8aF8rKa_Ogw

"There are no solutions, only tradeoffs."
"Compared to what?"
"At which costs?"
"What hard evidence do you have?"

> Weniger ist mehr. Wir haben uns alle viel zu sehr mit unnötiger Technik
> zumüllen lassen. Wir würden mit bedachter, selektierter Nutzung von
> Technik glücklicher sein. Auch konsumieren die meisten viel zu viel von
> den Medien. Das müllt m.A.n. eventuell das Gehirn zu und macht die Leute
> nervös und genervt.

Stimmt! Aber das Problem löst du nicht technisch, weder mit teuren noch 
ultrabilligen Mikrocontrollern.

> In meinen Augen ist eMobilität als totaler Ersatz der Verbrenner ein
> weißer Elefant und Utopie. Es würde an allen Ecken fehlen. Sicher,
> einige wenige sind beeindruckt was eMobilität vermag. Aber für eine
> totale Umstellung? Wie sollen die vielen kWh an Energie aus fossilen
> Brennstoffen ersetzt werden?

Durch Solar und Wind! Muss man nur gaaaaaanz vieeeeel bauen! Sagt der 
Robert.

> Wir sind noch lange nicht so weit um alle
> diese Probleme zufriedenstellend lösen zu können.

Siehe oben! Es gibt keine Lösungen, nur Kompromisse!

> Hersteller. Die billigst uC lohnen sich nur wenn die Stückzahlen
> entsprechend gigantisch sind.

BINGO!

[Gerhard O. (gerhard_)]

Oh, Falk!

Hast ja so ziemlich recht in Allem und ganz sooo schlimm meinte ich es 
eigentlich auch wieder nicht. Aber ab und zu sticht mich der Hafer und 
lasse mich zum "Predigen" verleiten:-)

Ich denke mir eigentlich, wenn es den "Jungen" zu blöd sein wird, dann 
müssen sie sich eben mit geballter Kraft darum kümmern müssen, um ihre 
Welt zu "verbessern".

Man kann halt nicht aus seiner Haut springen. Für mich waren Komponenten 
in den jungen Jahren sehr schwer beziehbar und man wieder verwertete als 
Schüler so viel wie möglich. Da tut einem das Herz weh, wenn so viel 
teuer ersetzbare hochwertige Komponenten, nur deren Rohstoffe wegen, 
zerstört werden. Ich denke da mal nur an die schönen Neuberger 
Instrumente. "There is beauty in Analog".

VG,
Gerhard

[Steve van de Grens (roehrmond)]

Irgend W. schrieb:
> Die große Masse der Kunden tickt nunmal nach Hauptsache Billing und
> möglichst oft was Neues.

Ich denke, dass ändert sich seit einigen Jahren. Frage mal die 
Jugendlichen, wie die zu Konsum stehen. Die die ich kenne denken dabei 
durchaus an die Umwelt.

Für Vernünftige Entscheidungen fehlt ihnen teilweise noch KnowHow, so 
dass sie leicht durch "grüne" Werbesprüche beeinflussbar sind. Aber das 
kommt noch, gut Ding will Weile haben.

> Das Bescheuerte heutzutage ist, dass man selbst bei teuren Sachen
> nicht sicher sein kann ob die nicht nach genau derselben Devise
> Zusammengeschustert wurden und man am ende nur mehr Geld für dieselbe
> Scheiße bezahlt. Nur halt in einem hübscheren Gehäuse.

Genau!

[Steve van de Grens (roehrmond)]

Gerhard O. schrieb:
> Warum werden Elektronikbaugruppen nicht zerlegt und deren
> Komponentenwieder verwendet.

Das wird mit einigen Bauteilen durchaus gemacht. Diese findest du bei 
Aliexpress wieder.

Leider sind sie in der Regel nicht gründlich getestet, so dass da die 
Fehlerquote hoch ist. Ein KFZ Hersteller will sich wohl kaum damit herum 
schlagen. Das Testen ist ja teurer, als neu kaufen.

[Philipp Klaus K. (pkk)]

>
> Wenn wir als moderne Zivilisation weiser sein würden, dann müssten wir
> darauf bestehen unsere Produkte langlebiger zu machen, modernisierbar,
> günstig reparierbar, sie an andere weitergeben, wenn wir das Interesse
> daran verloren haben.

Der OTP-Speicher behält seine Daten viel länger als der Flash, so dass 
das Gerät mit OTP-µC länger hält.
Und bei der Herstellung waren für den Padauk-µC mit seienem 0,25 mm²-Die 
auch deutlich weniger Ressourcen nötig als für einen größeren µC.

[Steve van de Grens (roehrmond)]

Falk B. schrieb:
> Aber glaubst du ernsthaft, daß die Welt nur ULTRAbillige
> Mikrocontroller haben will, die ...
> technologisch 10 Jahre und älter sind?

10 Jahre ist nicht viel. Einige durchaus beliebte STM32 Modelle sind da 
schon drüber.

Ich denke schon, dass man die mittelalten AVR Modelle* durchaus 30 Jahre 
lang gut gebrauchen kann. Die haben noch nicht ausgedient. So lange sie 
gekauft werden und die Produktionsanlagen noch funktionieren, lassen sie 
sich zum gleichen Preis herstellen, wie neuere Mikrocontroller (glaube 
ich).

So why not?

*) Damit meine ich konkret:
ATtiny 25, 45, 85
ATtiny 24, 44, 84, 441, 841
ATtiny 261, 461, 861
ATmega 48, 88, 168, 328
ATmega 164, 324, 644, 1284
ATmega 1281, 2561
ATmega 640, 1280, 2560

[Ralph S. (jjflash)]

... einfach einmal eine Frage am Rande? Wie programmiert / flasht die 
Industrie die Mikrocontroller in großer Stückzahl (sagen wir so ab 10000 
Stück)?

Ich meine jetzt die Controller (logischerweise) die nicht 
Maskenprogrammiert sind. Hierfür gab und gibt es die Gangprogrammer, die 
aber bestimmt nicht mehr als 10 oder 20 Stück auf einmal flashen können.

Außerdem müssen die Controller hierbei ja auch ersteinmal kontaktiert 
werden. Bei manchen Flachbaugruppen (weiß ich) wird die Programmierung 
auch gerne einmal über einen Prüfadapter gemacht, der dann auch Fehler 
auf der Baugruppe entdeckt.

Aber in sehr großer Stückzahl ist das alles nicht praktikabel (glaube 
ich zumindest).

Wenn man jetzt zudem den hier genannten Billigstcontroller von Padauk 
ansieht (mit dem ich mich immer wieder auch mal beschäftige) dann sieht 
der für mich nicht so wirklich gut dannach aus, dass der "in system" 
aufgrund der erhöhten Spannungen an VDD und PA5 geeignet ist.

Wie wird hier in einer Stückzahl von 10000 das Programm auf den 
Controller gebracht ?

[Steve van de Grens (roehrmond)]

Ralph S. schrieb:
> Außerdem müssen die Controller hierbei ja auch ersteinmal kontaktiert
> werden.

Ist das nicht sowieso auch zur Qualitätskontrolle nötig? Bei dem Vorgang 
kann man dann auch gleich das bestellte Anwendungsprogramm drauf 
flashen.

[Vanye R. (vanye_rijan)]

> Ein Flash programmierter uC ließe sich Jahrzehnte in neuen
> Gerätschaften weiterverwenden, da er sich neu programmieren lässt.

Bist du sicher das du dein Geld als Entwickler verdienst?

Privat mache ich das! Aber die meisten hier kommen doch schon ins
jammern wenn sie eine moderne MCU im DFN Gehaeuse sehen.

In der Firma? Undenkbar. Wie willst du da Prozessicherheit garantieren?
Also loetbarkeit, oder auch Abnutzung. Wer weiss schon genau wie
der Baustein vom Vorbesitzer mishandelt wurde?

Mal ganz davon abgesehen das die Kosten fuer sowas immer ueber den
Neupreis liegen.

Vanye

[Falk B. (falk)]

Ralph S. schrieb:
> ... einfach einmal eine Frage am Rande? Wie programmiert / flasht die
> Industrie die Mikrocontroller in großer Stückzahl (sagen wir so ab 10000
> Stück)?

Es gibt Automaten, welche die Bauteile aus dem Gurt nehmen, 
programmieren und wieder in einen Gurt packen.

> Ich meine jetzt die Controller (logischerweise) die nicht
> Maskenprogrammiert sind. Hierfür gab und gibt es die Gangprogrammer, die
> aber bestimmt nicht mehr als 10 oder 20 Stück auf einmal flashen können.

Ist nur für Kleinserien mit ein paar hundert bis tausenden pro Jahr 
wirklich sinnvoll, denn das Ding wird auch noch manuell bedient.

> Außerdem müssen die Controller hierbei ja auch ersteinmal kontaktiert
> werden. Bei manchen Flachbaugruppen (weiß ich) wird die Programmierung
> auch gerne einmal über einen Prüfadapter gemacht, der dann auch Fehler
> auf der Baugruppe entdeckt.

Das ist auch eine Option.

> Aber in sehr großer Stückzahl ist das alles nicht praktikabel (glaube
> ich zumindest).

Doch, sogar sehr.

> Wenn man jetzt zudem den hier genannten Billigstcontroller von Padauk
> ansieht (mit dem ich mich immer wieder auch mal beschäftige) dann sieht
> der für mich nicht so wirklich gut dannach aus, dass der "in system"
> aufgrund der erhöhten Spannungen an VDD und PA5 geeignet ist.

Kommt drauf an.

[Jörg W. (dl8dtl) (Moderator)]

C-hater schrieb:
> auch in Deutschland, nämlich in Heilbronn

AVRs sind da aber nie gebaut worden, sondern diverser Automotive-Kram. 
Die Fab wurde schon zu Atmel-Zeiten ausgegründet.

[Mampf F. (mampf)]

Philipp Klaus K. schrieb:
> Seit ein paar Monaten sind die STM8 NRND

Sehr schade, ich wollte mir die STM8 vor ein paar Monaten ankucken, weil 
man sie leichter debuggen kann und 8Bit-Performance ja oft reicht.

Aber waren nicht erhältlich. Irgendwie nirgendswo und nicht auf Digikey 
oder Mouser, dann hab ich davon abgelassen und mir schon gedacht, dass 
sie bald komplett eingestampft werden.

Zur ursprünglichen Frage:
- AVR
- PIC
- MCS51

Die wirds noch ne Zeit geben.

Alles andere (im 8Bit-Segment) ist mehr oder weniger irrelevant - außer 
du benötigst Millionen an 8Bitter für 1,5ct/Stück und dir ist egal, wie 
die Architektur aussieht, weil du nur ein "Gets the job done"-µC 
benötigst.

[Arduino F. (Firma: Gast) (arduinof)]

Ralph S. schrieb:
> Wie programmiert / flasht die
> Industrie die Mikrocontroller in großer Stückzahl (sagen wir so ab 10000
> Stück)?

Das beschreiben wird meist von den Herstellern, Distributoren, 
Bestückern oder anderen externen Dienstleistern angeboten..
Kann man also fertig erwerben.

[Falk B. (falk)]

Arduino F. schrieb:
>> Wie programmiert / flasht die
>> Industrie die Mikrocontroller in großer Stückzahl (sagen wir so ab 10000
>> Stück)?
>
> Das beschreiben wird meist von den Herstellern, Distributoren,
> Bestückern oder anderen externen Dienstleistern angeboten..
> Kann man also fertig erwerben.

Das mag zwar richtig sein, beschreibt aber nur die Logistik, nicht die 
technische Lösung.

[Jörg W. (dl8dtl) (Moderator)]

Falk B. schrieb:
> Das mag zwar richtig sein, beschreibt aber nur die Logistik, nicht die
> technische Lösung.

Die hängt ja auch davon ab, wer es macht. Der Hersteller kann die 
Programmierung in den Testzyklus einbauen. Das lohnt aber nur für 
Millionenstückzahlen. Alle andered können nur 
Standard-Programmierschnittstellen benutzen und müssen dann neu gurten.

[Ralph S. (jjflash)]

Falk B. schrieb:
> Es gibt Automaten, welche die Bauteile aus dem Gurt nehmen,
> programmieren und wieder in einen Gurt packen.

Vielen Dank für die Info.

Ich habe jetzt mal etwas nach solchen Automaten gegoogelt und u.a. ein 
Video zu einem Automaten PSV7000 gefunden.

Für mich interessant das mal zu wissen (weil ich mir bisher da keine 
Gedanken darüber gemacht hatte).

Grundsätzlich hatte ich angenommen, dass es wohl auf einen Automaten 
hinausläuft.

[Marc X. (marc_x)]

Ralph S. schrieb:
> Falk B. schrieb:
>> Es gibt Automaten, welche die Bauteile aus dem Gurt nehmen,
>> programmieren und wieder in einen Gurt packen.
>
> Vielen Dank für die Info.
>
> Ich habe jetzt mal etwas nach solchen Automaten gegoogelt und u.a. ein
> Video zu einem Automaten PSV7000 gefunden.

Gibt auch noch andere Hersteller die solche Automaten herstellen, zum 
Beispiel BPM Microsystems und Xeltek, mein Arbeitgeber hat sowas auch 
mal entwickelt und eine 2 stellige Anzahl für die eigene Verwendung 
gebaut.

> Für mich interessant das mal zu wissen (weil ich mir bisher da keine
> Gedanken darüber gemacht hatte).
>
> Grundsätzlich hatte ich angenommen, dass es wohl auf einen Automaten
> hinausläuft.

Solche Automaten sind richtig teuer, zudem verlangen die Hersteller 
enorme Preise für die Lizenzen der Chiptreiber, Sockelmodule und 
verpflichtende Wartungsverträge.

Für viele Firmen lohnt sich eine Investition in diese Richtung einfach 
nicht, daher entstanden in den 2000er Jahren viele 
Chip-Programmier-Dienstleister wovon die meisten allerdings schon wieder 
liquidiert wurden oder das Geschäftsfeld geändert haben. Zum Beispiel 
ProMik in Nürnberg hat das viele Jahre gemacht bevor sie sich auf 
Programmiergeräte spezialisiert haben und ErTec in Erlangen macht das 
auch heute noch neben dem Programmiergeräte-Geschäft.

[Chris K. (kathe)]

Falk B. schrieb:
> Tu mal nicht so, als ob alles ewig hält oder halten soll oder gar kann.
> Dem ist nicht so. Ja, über bestimmte Nutzungsdauern von bestimmten
> Geräten kann man diskutieren, allen voran vermutlich Smartphones und
> Computer. Aber auch die haben kein endloses Leben, allein auf Grund des
> rasanten, technischen Fortschritts. Man KANN mit einem 10 Jahre alten
> Smartphone nur noch wenig anfangen, bestenfalls telephonieren, bissel
> whatsapp und Bilder machen. Der Rest wird dann schon enger.

Alte Autos ohne viel Elektronik funktionieren heute noch auch wenn das 
alter > 30 Jahre ist. Bei einem aktuellen Auto darfst du froh sein wenn 
es 10 Jahre läuft ohne das die billig elektronik oder der "Software 
dongle" key abläuft.
Hab heute mich mit meinem Autodealer unterhalten, mittlerweile Probleme 
ohne ende das Autos sich einfach hinstellen Motorproblematik.....
Keilriemen aus gummi läuft in Ölbad.
Gummi in Ölbad .... das ist zum auflösen verdammt. wtf.
Irgendwie scheint es die erste und vlt. zweite Gen nach dem Krieg geht 
in Rente und nun kommen die Autos der Scrum/agil Entwickler in das 
alter...

Wer hat solch einen "Sche**** Entwicklung " seinen Kindern beigebracht ?
Bezahlt bitte selber für eure "Mü.. Entwicklung" und lastet nicht die 
Entsorgunkskosten euren Enkeln auf.

[Arduino F. (Firma: Gast) (arduinof)]

Chris K. schrieb:
> Keilriemen aus gummi läuft in Ölbad.

Zahnriemen!
Nix Keilriemen.
Ford ECO Boost Motor.
https://de.wikipedia.org/wiki/Ford_EcoBoost

Tuts eigentlich ganz gut, wenn man die Wechselintervalle einhält und das 
richtige Öl drauf tut.
Und da sind wir beim Problem!
Einmal falsches Öl an der Tanke nachkippen, und der Riemen zerlegt sich.
Der fatale Error: Zuhause mit Öl aus dem Baumarkt selber wechseln.

Der Grund für den öligen Riemen:
Laufruhe und Variable Nockenwellenverstellung.
Die Verstellung spritzt mit ÖL um sich.
Bei jedem Fahrzeug.

Die Alternative: Kette
Da gibts bei vielen anderen Modellen auch erhebliche Probleme.
Und die enden oft mit einem harten Knall.

Meine private Sicht:
Ein guter Motor!
Welcher eine fachkundige Hand braucht.
Immer schön warm fahren und danach reichlich Gas.
Dann kann er ewig halten.

[Rolf M. (rmagnus)]

Arduino F. schrieb:
> https://de.wikipedia.org/wiki/Ford_EcoBoost

Von dort:

"Beide Zahnriemen laufen im Motorölbad, was die Laufruhe erhöht, 
Reibungsverluste verringert und so die Lebensdauer erhöht, jedoch wird 
ein nach (nach Herstellerfreigabe) geeignetes Motoröl benötigt, das den 
Riemen nicht zersetzt wie es viele andere Motoröle tun."

[Andreas S. (andreas) (Admin)]

Da alles zum Thema gesagt zu sein scheint, und es jetzt nur noch off 
topic wird, denke ich dass dieser Thread geschlossen werden kann.