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.
:
Gesperrt durch Admin
Philipp Klaus K. schrieb: > AVR In 10 Jahren sicher noch relevant, immerhin wurden jetzt gerade komplett neue Serien herausgebracht, sicher nicht zum Spaß.
Philipp Klaus K. schrieb: > * PIC Die dürften auch in >10 Jahren noch relevant sein, sind in zahlreichen Geräten als Steuer-µC eingebaut
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!
:
Bearbeitet durch User
Beitrag #7418569 wurde vom Autor gelöscht.
Beitrag #7418572 wurde von einem Moderator gelöscht.
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.
:
Bearbeitet durch User
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.
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.
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.
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
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.
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.
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.
Beitrag #7418748 wurde von einem Moderator gelöscht.
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.
Beitrag #7418770 wurde vom Autor gelöscht.
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!
Beitrag #7418779 wurde von einem Moderator gelöscht.
Beitrag #7418780 wurde vom Autor gelöscht.
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
Beitrag #7418788 wurde von einem Moderator gelöscht.
Beitrag #7418800 wurde von einem Moderator gelöscht.
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.
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.
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.
Beitrag #7419146 wurde von einem Moderator gelöscht.
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.
Beitrag #7419174 wurde von einem Moderator gelöscht.
Beitrag #7419177 wurde von einem Moderator gelöscht.
Beitrag #7419218 wurde von einem Moderator gelöscht.
Beitrag #7419260 wurde von einem Moderator gelöscht.
Beitrag #7419284 wurde von einem Moderator gelöscht.
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.
Beitrag #7419318 wurde von einem Moderator gelöscht.
Beitrag #7419509 wurde von einem Moderator gelöscht.
Beitrag #7419519 wurde von einem Moderator gelöscht.
Beitrag #7419524 wurde von einem Moderator gelöscht.
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...
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.
Angehängte Dateien:
-
AVR_Cores.png
94 KB
> 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).
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).
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...
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.
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.
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?
:
Bearbeitet durch User
Wird der CDP1802 immernoch in der Luft- und Raumfahrt eingesetzt?
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:-)
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.
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.
Bei der aktuellen Inflationsrate haben 8-Bit CPUs in 10 Jahren fast 16 Bit! ;-)
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/
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.
:
Bearbeitet durch User
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.
Beitrag #7419967 wurde von einem Moderator gelöscht.
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!
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 ?
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.
:
Bearbeitet durch User
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
> 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?
Beitrag #7420111 wurde von einem Moderator gelöscht.
> 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.
Beitrag #7420141 wurde von einem Moderator gelöscht.
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.
Beitrag #7420159 wurde von einem Moderator gelöscht.
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.
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
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
Beitrag #7420210 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
st8_nRND.png
9,5 KB
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.
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!
Beitrag #7420694 wurde von einem Moderator gelöscht.
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
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.
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.
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.
Beitrag #7421132 wurde von einem Moderator gelöscht.
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.
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.
Beitrag #7421152 wurde von einem Moderator gelöscht.
" 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.
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 😉
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.
> 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.
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. ;-)
:
Bearbeitet durch User
(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 ...
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.
DSGV-Violator schrieb: > Verwirr hier mal nicht Addressraum unbd Registerbreite. Ich habe deinen Unsinn mit ARM-Thumb nur konsequent weitergeführt. ;-)
"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
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.
Beitrag #7421455 wurde von einem Moderator gelöscht.
Beitrag #7421554 wurde von einem Moderator gelöscht.
Beitrag #7421628 wurde von einem Moderator gelöscht.
Beitrag #7421631 wurde vom Autor gelöscht.
Beitrag #7421640 wurde von einem Moderator gelöscht.
Beitrag #7421642 wurde von einem Moderator gelöscht.
Beitrag #7421667 wurde von einem Moderator gelöscht.
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...
Beitrag #7421784 wurde von einem Moderator gelöscht.
Beitrag #7421813 wurde von einem Moderator gelöscht.
Beitrag #7421885 wurde von einem Moderator gelöscht.
Beitrag #7421895 wurde von einem Moderator gelöscht.
Beitrag #7421922 wurde von einem Moderator gelöscht.
Beitrag #7422054 wurde von einem Moderator gelöscht.
Beitrag #7422166 wurde von einem Moderator gelöscht.
Beitrag #7422276 wurde von einem Moderator gelöscht.
Der ASM-Fanatiker ist wieder da! ;-)
Könnte er nicht auf 7 Bit umsteigen? Primzahlen sind so viel schöner, und wenigsten originell.
Beitrag #7422334 wurde von einem Moderator gelöscht.
Beitrag #7422338 wurde von einem Moderator gelöscht.
Beitrag #7422351 wurde von einem Moderator gelöscht.
Schon, aber der nahm alle mit, bis auf einen - And I only am escaped alone to tell thee.
Beitrag #7422362 wurde von einem Moderator gelöscht.
Beitrag #7422368 wurde von einem Moderator gelöscht.
Beitrag #7422369 wurde von einem Moderator gelöscht.
Beitrag #7422488 wurde von einem Moderator gelöscht.
Beitrag #7422581 wurde von einem Moderator gelöscht.
Beitrag #7422612 wurde von einem Moderator gelöscht.
Beitrag #7422634 wurde von einem Moderator gelöscht.
Beitrag #7422663 wurde von einem Moderator gelöscht.
Beitrag #7422677 wurde von einem Moderator gelöscht.
Beitrag #7422680 wurde vom Autor gelöscht.
Beitrag #7422699 wurde von einem Moderator gelöscht.
Beitrag #7422962 wurde von einem Moderator gelöscht.
Beitrag #7422994 wurde von einem Moderator gelöscht.
Beitrag #7423087 wurde von einem Moderator gelöscht.
Beitrag #7423115 wurde von einem Moderator gelöscht.
Beitrag #7423142 wurde von einem Moderator gelöscht.
Beitrag #7423158 wurde von einem Moderator gelöscht.
Beitrag #7423172 wurde von einem Moderator gelöscht.
Beitrag #7423212 wurde von einem Moderator gelöscht.
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.
Beitrag #7423259 wurde von einem Moderator gelöscht.
Beitrag #7423289 wurde von einem Moderator gelöscht.
Beitrag #7423296 wurde von einem Moderator gelöscht.
Beitrag #7423303 wurde von einem Moderator gelöscht.
>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
Beitrag #7423310 wurde von einem Moderator gelöscht.
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".
Beitrag #7423320 wurde von einem Moderator gelöscht.
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?
:
Bearbeitet durch User
> Die Erfordernisse von Bild/Ton Massendaten > spezielle SIMD Befehle ein, > Auch bei Mikrocontroller hat das Einzug gehalten. Nein.
DSGV-Violator schrieb: >> spezielle SIMD Befehle ein, > >> Auch bei Mikrocontroller hat das Einzug gehalten. > > Nein. Ab Cortex M4.
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.
Stefan F. schrieb: > allerdings wirklich komplexer, was Funktionsumfang, Seiteneffekte und > Konfiguration betrifft. Die Errata-Liste ist ebenfalls länger.
Beitrag #7423529 wurde von einem Moderator gelöscht.
Beitrag #7423564 wurde von einem Moderator gelöscht.
Beitrag #7423616 wurde von einem Moderator gelöscht.
Beitrag #7423645 wurde von einem Moderator gelöscht.
Beitrag #7423684 wurde von einem Moderator gelöscht.
Beitrag #7423719 wurde von einem Moderator gelöscht.
Beitrag #7423842 wurde von einem Moderator gelöscht.
Beitrag #7423867 wurde von einem Moderator gelöscht.
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".
:
Bearbeitet durch User
Beitrag #7423870 wurde von einem Moderator gelöscht.
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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Beitrag #7424009 wurde von einem Moderator gelöscht.
Beitrag #7424109 wurde von einem Moderator gelöscht.
Beitrag #7424136 wurde von einem Moderator gelöscht.
Beitrag #7424204 wurde von einem Moderator gelöscht.
Beitrag #7424233 wurde von einem Moderator gelöscht.
Beitrag #7424367 wurde von einem Moderator gelöscht.
Beitrag #7424456 wurde von einem Moderator gelöscht.
Beitrag #7424567 wurde von einem Moderator gelöscht.
Beitrag #7424581 wurde von einem Moderator gelöscht.
Beitrag #7424614 wurde von einem Moderator gelöscht.
Beitrag #7424624 wurde von einem Moderator gelöscht.
Beitrag #7424635 wurde von einem Moderator gelöscht.
Beitrag #7424662 wurde von einem Moderator gelöscht.
Beitrag #7424703 wurde von einem Moderator gelöscht.
Beitrag #7424716 wurde von einem Moderator gelöscht.
Beitrag #7424727 wurde von einem Moderator gelöscht.
Beitrag #7424762 wurde vom Autor gelöscht.
Beitrag #7424774 wurde von einem Moderator gelöscht.
Beitrag #7424862 wurde von einem Moderator gelöscht.
Beitrag #7424884 wurde von einem Moderator gelöscht.
Beitrag #7424889 wurde von einem Moderator gelöscht.
Beitrag #7424906 wurde von einem Moderator gelöscht.
Beitrag #7424914 wurde von einem Moderator gelöscht.
Beitrag #7425086 wurde von einem Moderator gelöscht.
Beitrag #7425137 wurde von einem Moderator gelöscht.
Beitrag #7425139 wurde von einem Moderator gelöscht.
Beitrag #7425142 wurde von einem Moderator gelöscht.
Beitrag #7425154 wurde von einem Moderator gelöscht.
Beitrag #7425170 wurde von einem Moderator gelöscht.
Beitrag #7425230 wurde von einem Moderator gelöscht.
Beitrag #7425233 wurde von einem Moderator gelöscht.
Beitrag #7425300 wurde von einem Moderator gelöscht.
Beitrag #7425306 wurde vom Autor gelöscht.
Beitrag #7425345 wurde von einem Moderator gelöscht.
Beitrag #7425412 wurde von einem Moderator gelöscht.
Beitrag #7425484 wurde von einem Moderator gelöscht.
Beitrag #7425553 wurde von einem Moderator gelöscht.
Beitrag #7425565 wurde von einem Moderator gelöscht.
Beitrag #7425591 wurde von einem Moderator gelöscht.
Beitrag #7425606 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.
Thread beobachten
Seitenaufteilung abschalten