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.
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:-)
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.
Alle die nicht durch neuentwicklung ersetzt werden, da man sonst viel
Testtiefe verliert. Die NASA bunkert immer mal wieder Alt-Prozessoren
als Ersatzteile:
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.
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.
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.
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?
Ä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.
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.
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.
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!
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.
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.
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.
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.
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".
...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...
...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.
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).
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).
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.
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.
... 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:-)
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.
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.
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.
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.
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.
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.
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!
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 ?
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.
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.
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?
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.
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
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.
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
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.
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.
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.
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.
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.
" 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."
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.
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 😉
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.
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.
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.
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:
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.
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...
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...
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.
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".
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?
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.
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?
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.
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.
