Forum: Mikrocontroller und Digitale Elektronik Das Ende von 8bit?


von Paul R. (atmega9)


Lesenswert?

Hallo!

Ich weiß, dieses Thema hatten wir schon oft durch, ist aber schon wieder 
relativ lange her. Und zwar folgendes: Bis auf die PIC-Controller haben 
fast alle Hersteller auf 32 Bitter gesetzt. Sie sollten angeblich nach 
und nach alle 8 bit MCUs ablösen. Trotzdem kommt es mir so vor, als 
würde das nicht funktionieren. Laut Wikipedia haben die 8 bit MCUs immer 
noch den größten Marktanteil. Auch gibt es viele andere Gründe, die 
gegen den Umstieg auf 32 bit sprechen; größerer Stromverbrauch, 
schwierige Einarbeitung, oft nur mit Echtzeit-OS ordentlich nutzbar etc.
Meine Frage daher: Ist das Aussterben von 8 bit MCUs und speziell den 
AVRs nur ein Wunsch der Hersteller oder werden diese wohl so bald nicht 
verschwinden? Ich weiß, niemand kann diese Frage zu 100% beantworten, 
mich würden einfach nur verschiedene Ansichten und Meinungen 
interessieren.

PS.: Schaffen wir es diesmal auch ohne Glaubenskrieg?

Gruß
  mega9

von Christian S. (solder)


Lesenswert?

Auf die paar Assemblerprogrammierer (wie mich) wird man wohl keine 
Rücksicht nehmen. Für C-Programmierer oder andere Hochsprachen ist es 
wohl egal, ob der Prozessor 8 oder mehr Bit hat. Also woran liegt es? 
Stromverbrauch spielt natürlich eine Rolle, Preis ist auch wichtig. Für 
kleine Projekte die Bauform. Aber warum sollte ein ATTiny13 nicht auch 
32 Bit haben können? Bauen könnte man das sicher. Offenbar verkaufen 
sich die 8 Bitter gut genug, dass die Hersteller einfach weiter 
produzieren und immer wieder auch kleine Performanceanpassungen 
nachschieben. Für den Anwender reichen die 8 Bit. Also werden sie weiter 
genommen. Der Umstieg käme wohl erst, wenn keine 8 Bitter mehr 
produziert würden.

von Jay (Gast)


Lesenswert?

Nicht zu vergessen, viele 8-Biter sind einfacher als die 32-Biter.

Jetzt werden gleich die Superhacker hier im Forum aufschlagen und 
verkünden, warum das für sie natürlich kein Problem ist, und jeder der 
ein Problem damit hat ist sowieso nicht ...

Es geht aber um etwas anderes. Wer sehr robuste Systeme bauen muss, und 
Clever ist, der eliminiert so viele potentielle Fehlerquellen wie 
möglich. Die Wahl einfacherer Mikrocontroller gehört dazu.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Paul R. schrieb:
> Meine Frage daher: Ist das Aussterben von 8 bit MCUs und speziell den
> AVRs nur ein Wunsch der Hersteller oder werden diese wohl so bald nicht
> verschwinden?
Sie werden die nächsten 15 Jahre garantiert nicht verschwinden. Du 
kannst auch heute noch 4-Bit uC kaufen:
http://global.epson.com/products/semicon/products/mcu/4bit_index.html
http://www.emmicroelectronic.com/products/microcontrollers/multi-io/em6607

von Paul R. (atmega9)


Lesenswert?

Jay schrieb:
> wer sehr robuste Systeme bauen muss, und
> Clever ist

Und wer gut programmiert, braucht oft gar keine 100Mhz...

von 6a66 (Gast)


Lesenswert?

Paul R. schrieb:
> Sie sollten angeblich nach
> und nach alle 8 bit MCUs ablösen.

Paul R. schrieb:
> Laut Wikipedia haben die 8 bit MCUs immer
> noch den größten Marktanteil.

Und das werden sie auch noch LAAAANGE behalten da der Markt immer noch 
nach noch geringeren Kosten schreit und 8 bit halt schon ewig im Markt 
ist. Alles andere ist Marketinggesülze.

Aber die 32bitter haben trotzdem ihre Berechtigung und werden sich auf 
lange Sicht sicher durchsetzten.

rgds

von Paul R. (atmega9)


Lesenswert?

6a66 schrieb:
> werden sie auch noch LAAAANGE behalten

6a66 schrieb:
> werden sich auf
> lange Sicht sicher durchsetzten.

Will sagen die Zeit ist die nächsten Jahre noch nicht reif?

von Ingo L. (corrtexx)


Lesenswert?

Es gibt IMHO keine Notwendigkeit die 8bitter abzuschaffen. In jedem 
kleinen Gerät werkelt meist irgendwo n 8bitter. Natürlich ist ein 
32bitter performanter, aber warum sollte jemand in ein Auto zum Steuern 
der el. Fensterheber statt eines Tiny10 plötzlich einen 32bitter 
einbauen wollen? Da gibts einfach keine Notwendigkeit für...

von MaWin (Gast)


Lesenswert?

Paul R. schrieb:
> PS.: Schaffen wir es diesmal auch ohne Glaubenskrieg?

Nein.

Sie die 4-bitter ausgestorben ?

Fast.

Dabei eigenen sie sich zum Berechnung von Dezimalzahlen (Uhren, 
Taschenrechner) besser als 8 bitter.

Was ist mit 16-bittern (MSP430, MB90, M16C, PIC24) erfreuen die sich 
nicht gutem C-Supports und man merkt gar nict ob 16 oder 32 bit ?

Ach, die kennst du gar nicht ?

Da liegt das Problem. Exoten verbreiten sich nicht (was übrigens Gründe 
hat, an den Prozessoren ist einiges vergurkt oder die 
Entwicklungsumgebungen waren schlecht).

Es gibt unter Hobbyisten wohl genau 2 Pfade:

AVR und ARM(Cortex).

Alles andere ist exotisch.

Manche Firmen quälen sich mit C166 oder 8051 oder PIC32 ab, als Hobbyist 
muss amn sich das nicht antun. Man nimmt, was billig ist (inkl. 
Entwicklungsumgebung) zu dem es viel vorgemachtes gibt.

Exoten (aktuell 8266 mit LUA) nutz man wenn sie herausragende Features 
bieten.

von Holm T. (Gast)


Lesenswert?

Christian S. schrieb:
> Auf die paar Assemblerprogrammierer (wie mich) wird man wohl keine
> Rücksicht nehmen. Für C-Programmierer oder andere Hochsprachen ist es
> wohl egal, ob der Prozessor 8 oder mehr Bit hat.

...verstehschni.

Wieso möchtest Du als Assemblerprogrammierer hinsichtlich 8 Bit 
überhaupt Rücksicht genommen haben? Bit Du Assemblerprogrammierer oder 
AVR-Assemblerprogrammierer? Was stört Dich bei der 
Assemblerprogrammierung eines MC68000, der ja von der Busbreite her 16 
Bit aber von der Programmierstruktur her ein 32 Bitter ist? 
Normalerweise sind sich Assemblerprogrammierer einig das der MC86000 
oder die PDP11 die"schönsten" Architekturen überhaupt sind und beide 
sind sehr gut in Assembler zu programmieren...

Gut, die ARMs sind RISC CPUs, man rennt da mit kleinen Schritten mit der 
Kirche ums Dorf, aber die sind auch assemblerprogrammierbar....

Ansonsten ist das doch völlig egal, der Unterschied betrifft doch beim 
Programmieren hauptsächlich die Länge der Variablen, ob eine Integer 3 
nun 10 Nullen davor hat sollte weitestgehend egal sein.
Die Hohe Komplexität der Herstellungstechnologie von 32Bit µCs bringt es 
halt mit sich das auch versucht wird eine Leistungsfähige Peripherie zu 
integrieren und das ist das was die Dinger auch schwierig zu 
programmieren macht, nicht die Tatsache das die interne Busbreite größer 
ist.



Gruß,

Holm

von Paul R. (atmega9)


Lesenswert?

Ingo L. schrieb:
> Natürlich ist ein
> 32bitter performanter, aber warum sollte jemand in ein Auto zum Steuern
> der el. Fensterheber statt eines Tiny10 plötzlich einen 32bitter
> einbauen wollen? Da gibts einfach keine Notwendigkeit für..

Das ist das Problem, wenn man in einer Welt voller Überfluss lebt...

von Fitzebutze (Gast)


Lesenswert?

Jay schrieb:
> Nicht zu vergessen, viele 8-Biter sind einfacher als die 32-Biter.

Naja, nicht immer. So einige 8-bitter sind von hinten durch die Brust 
designt, dazu würde ich gerade die beliebten AVR zählen.
Der Sprung von 8 auf 32 bit ist nicht gerade kompliziert, und 
typischerweise kriegt man davon a priori nix mit mit nem C-Compiler.

>
> Jetzt werden gleich die Superhacker hier im Forum aufschlagen und
> verkünden, warum das für sie natürlich kein Problem ist, und jeder der
> ein Problem damit hat ist sowieso nicht ...
>
> Es geht aber um etwas anderes. Wer sehr robuste Systeme bauen muss, und
> Clever ist, der eliminiert so viele potentielle Fehlerquellen wie
> möglich. Die Wahl einfacherer Mikrocontroller gehört dazu.

Ich möchte mal behaupten, dass ein 32 bit ARM Cortex M0 robuster zu 
programmieren ist als ein AVR oder das n'te 8051 Derivat.
Es gibt da einen Klassiker:
1
uint16_t count;
2
...
3
count++;

Der count++ wird typischerweise als 'ADD' mit gefolgtem 'ADD mit Carry' 
umgesetzt. Also nicht atomisch ('atomic'). Schlägt jetzt ein Interrupt 
zwischen den beiden ADD zu, können die lustigsten Sachen passieren.
Versuch z.B. mal einen wirklich robusten Mutex z.B. auf einem AVR 
umzusetzen. Mal abgesehen von einigen idiotischen Designs mancher 
Interrupt-Controller (also die Schuld der HW, das gabs beim ARM7 aber 
zugegebenermassen auch), laufen da eine Menge Programmierer rein.

Zum Argument Stromverbrauch: ein 16bittiger msp430 ist im Schnitt 
sparsamer als die AVR-Architektur und die neueren M0-Kerne nähern sich 
der Marke auch langsam. Also auch kein Argument mehr, genausowenig wie 
die oft angeführte Code-Dichte.

von M. M. (blackcow)


Lesenswert?

Fitzebutze schrieb:
> Der count++ wird typischerweise als 'ADD' mit gefolgtem 'ADD mit Carry'
> umgesetzt. Also nicht atomisch ('atomic'). Schlägt jetzt ein Interrupt
> zwischen den beiden ADD zu, können die lustigsten Sachen passieren.

Deswegen wird doch das SREG auf dem Stack gespeichert? Oder spielst du 
auf den Zugriff der nicht komplett inkrementierten Variable in 
Interruptroutine an?

von Bastler (Gast)


Lesenswert?

Also ich verwende STM8 UND STM32.
Jeder von beiden hat seine Daseinsberechtigung!

von Operator S. (smkr)


Lesenswert?

Einem Glaubenskrieg begegnet man am besten mit Fakten.

Paul R. schrieb:
> Laut Wikipedia haben die 8 bit MCUs immer
> noch den größten Marktanteil.

Würde mich auch wundern wenn es anders wäre. 8 Bit µC gibt es seit 40 
Jahren, die Cortex-M 32 Bit waren dagegen die ersten µC, welche eine 
breite Akzeptanz erhalten haben. Vorgänger wie der AVR32 und andere 
konnten nicht diese Verbreitung erhalten, wie es ARM jetzt geschafft 
hat. Vor erst rund 8 Jahren kamen die Cortex-M in den Markt, mit dem 
Nachteil, dass Firmen ihre Treiber und Anwendungen schon Jahre zuvor für 
die 8 Bitter programmiert und getestet haben.
ARM versucht dem mit einheitlicher Schnittstelle (CMSIS) und die 
Hersteller mit eigenen Libraries entgegenzuwirken und den Firmen diese 
Arbeit abnehmen. Dies scheint sich aber nur bedingt auszuzahlen, da 
Firmen immernoch lieber den eigenen Code schreiben (nur was man selber 
gemacht hat, hat man im Griff) und für Hobbyentwickler ist es zu 
kompliziert seit Arduino und co.
Für die 8 Bitter spricht also die jahrelang geprobte Zuverlässigkeit und 
der Einsatz in bereits Entwickelten Geräten, die ohne Grund nicht 
einfach neu designt werden.
Bleibt noch der Preis und da scheint ein Cortex-M0 bei gleichwwertigem 
Funktionsumfang die 8 Bitter im Preis zu schlagen. Das wäre dann auch 
ein gewichtiger Grund für Firmen, sich auf eine neue Architektur 
einzulassen.


Paul R. schrieb:
> gegen den Umstieg auf 32 bit sprechen; größerer Stromverbrauch,
> schwierige Einarbeitung, oft nur mit Echtzeit-OS ordentlich nutzbar etc.

Bei der Einarbeitung würde ich dir noch zustimmen, beim Rest nicht.

von 6a66 (Gast)


Lesenswert?

Paul R. schrieb:
> 6a66 schrieb:
>> werden sie auch noch LAAAANGE behalten
>
> 6a66 schrieb:
>> werden sich auf
>> lange Sicht sicher durchsetzten.
>
> Will sagen die Zeit ist die nächsten Jahre noch nicht reif?

Heisst: jedem Tierchen sein Pläsierchen, jedem Produkt seinen uC. Früher 
ging's mit 4bit, später mit 8bit. Und irgendwann brauchte man zum tippen 
dieses Beitrags keinen Pentium mit 100MHz mehr sondern einen quadcore 
mit >2GHz und endlos Speicher. Eine ähnliche Entwicklung findet auch bei 
den anderen Produkten im Markt statt, da "muss" man heute nicht mehr den 
8bitter verwenden sondern wegen vieler Faktoren den 32bitter. Also wird 
die Umorientierung immer weiter fortschreiten wo es nötig ist. Wann und 
wo da welche Märkte überholen ist reines Marketiggequatsche und 
Glaskugellesen. Was hast Du davon solchen Märchen und Hypes zu folgen?

rgds

von Paul R. (atmega9)


Lesenswert?

Operator S. schrieb:
> Firmen immernoch lieber den eigenen Code schreiben

Das ist wohl ein allgemeines Problem mit closed-source Software unserer 
Zeit. Es muss möglichst schnell fertig sein. Das beste Beispiel ist 
Software die per RAD erzeugt wird.

von 6a66 (Gast)


Lesenswert?

Operator S. schrieb:
> Bleibt noch der Preis und da scheint ein Cortex-M0 bei gleichwwertigem
> Funktionsumfang die 8 Bitter im Preis zu schlagen.

Großteils subventioniert um Marktanteile zu schaffen. Die meisten 
8-bitter laufen auf angeschriebenen Linien und ausgeknautschen 
Prozessen.

rgds

von Alter_Walder (Gast)


Lesenswert?

Paul R. schrieb:
> Ingo L. schrieb:
>> Natürlich ist ein
>> 32bitter performanter, aber warum sollte jemand in ein Auto zum Steuern
>> der el. Fensterheber statt eines Tiny10 plötzlich einen 32bitter
>> einbauen wollen? Da gibts einfach keine Notwendigkeit für..
>
> Das ist das Problem, wenn man in einer Welt voller Überfluss lebt...

Naja wenn da jemand mit AutoSar anfängt, dann brauch man ja fast ein den 
32er nur für den ganzen Overhead der da erzeugt wird.

Das schöne an den 8bittern ist ja eigentlich die einfache Peripherie. 
Für Kleinkram ist das doch ideal. Wenn ich nen Fensterheber als Beispiel 
hohle braucht man halt bischen standard ADC, evtl. nen PWM-Ausgang und 
LIN/CAN. (LIN is ja quasi UART). Da mit einem Timer anzukommen der 38 
Synchrone Phasen mit ADC-Triggerung und Totzeit-Gewurschdel noch drin 
hat ist doch eigentlich nur Nervig bei der Entwicklung. Da muss man ja 
erstmal 200 Register setzen damit das Ding überhaupt was macht.
Ich hab eh das gefühl dass viele µC-Pherieferien im 32bit-Sektor 
Speziallösungen von großen Firmen sind, die man halt auch so auf dem 
Markt anbietet.


Wie sieht das eigentlich mit Die-Fläche aus? So ein AVR ist doch 
Platzmässig bestimmt wesentlich kleiner als ein ARM Cortex M3 mit 
gleicher Ausstattung? Müsste ja dann extrem viel billiger sein.

von ui (Gast)


Lesenswert?

Grundsätzlich glaube ich, das 8Bit für viele Dinge absolut ausreicht.
Allerdings, und das darf man auch zugeben, gibt es heute viele tolle HW, 
die einem SW abnehmen. Als Beispiel sei nur mal ein DMA genannt. Ein 
tolles Stück HW, das ich noch nie in einem AVR gesehen hab.

Abgesehen davon ist das meiste Glaubensfragen. Vieles existiert schon so 
wie's ist, deswegen bleibts so.
Die Automobilindustrie setzt nach wie vor ganz enorm PowerPC 
Architekturen ein. Ist auch eine schöne Architektur.

von Bitwurschtler (Gast)


Lesenswert?

Das ist IMHO keine Frage der Hardware und ihrer Performance sondern eine 
der Entwicklungsumgebung.

Im FPGA-Bereich haben 32b softcores die 8 bit cores verdrängt weil bspw 
ein Picoblaz grausam zu programmieren ist, während es für den mikroblaze 
ein KlickiBunti SDK gibt.

Ähnlich 8 bit µC. Die die es nur mit Assembler gibt fallen immer mehr 
zurück, während die mit GUI C-Umgebung (Arduino) munter am Leben sind.


Und immer öfters wird nach RTOS geschrieen, auch wenn es nur ein paar 
Tasten und eine LCD-Zeile zu bedienen gibt - also mehr HAL als Hardware.


Es ist also die Bequemlichkeit der Entwickler die den 8 Bittern den 
Todesstoß versetzt, nicht der technische Fortschritt. Oder ein 
Glaubenskrieg.

Meine These dazu,

von ui (Gast)


Lesenswert?

Alter_Walder schrieb:
> Naja wenn da jemand mit AutoSar anfängt, dann brauch man ja fast ein den
> 32er nur für den ganzen Overhead der da erzeugt wird.

So ein Bockmist hab ich selten gehört.
Auf welchen Overhead sprichst du an? RTE? Oder das ganze Zeugs darunter? 
Betriebssystem?
Bevor man solche unqualifizerten Aussagen einfach so in dem Raum 
schmeißt, sollte man sich damit mal beschäftigen.
Wie immer in der Informatik gilt auch da: "Das kommt drauf an".

von m.n. (Gast)


Lesenswert?

ui schrieb:
> Als Beispiel sei nur mal ein DMA genannt. Ein
> tolles Stück HW, das ich noch nie in einem AVR gesehen hab.

ui schrieb:
> Bevor man solche unqualifizerten Aussagen einfach so in dem Raum
> schmeißt, sollte man sich damit mal beschäftigen.

Sieh Dir mal die Xmega an!

Viel wichtiger als die Bits ist doch, daß es die Teile im DIL-Gehäuse 
gibt ;-)

von ui (Gast)


Lesenswert?

Bitwurschtler schrieb:
> Ähnlich 8 bit µC. Die die es nur mit Assembler gibt fallen immer mehr
> zurück, während die mit GUI C-Umgebung (Arduino) munter am Leben sind.
>
> Und immer öfters wird nach RTOS geschrieen, auch wenn es nur ein paar
> Tasten und eine LCD-Zeile zu bedienen gibt - also mehr HAL als Hardware.
>
> Es ist also die Bequemlichkeit der Entwickler die den 8 Bittern den
> Todesstoß versetzt, nicht der technische Fortschritt. Oder ein
> Glaubenskrieg.

Gibt übrigens einen Ausdruck für sowas: Abstraktion. Die erkauft man 
sich mit Overhead.
Hat auch gewaltige Vorteile (gerade für heutige Elektronikprodukte, die 
möglichst schnell auf den Markt sollen): Man braucht sich mit den 
Details erstmal nicht rumschlagen, sondern erst, wenn durch die 
Abstraktion Fehler entstanden sind.

von ui (Gast)


Lesenswert?

m.n. schrieb:
> Sieh Dir mal die Xmega an!

wie war das mit 32-bit Architekturen, die sich nicht durgesetzt haben^^ 
;)
Außerdem, dann sind wir ja genau da: Kein DMA für 8-bitter!

von Paul R. (atmega9)


Lesenswert?

Alter_Walder schrieb:
> Wie sieht das eigentlich mit Die-Fläche aus? So ein AVR ist doch
> Platzmässig bestimmt wesentlich kleiner als ein ARM Cortex M3 mit
> gleicher Ausstattung? Müsste ja dann extrem viel billiger sein.

Die Die-Größe von AVRs wurde in den letzten Jahren nicht viel 
verbessert. Könnte man aber.

von m.n. (Gast)


Lesenswert?

ui schrieb:
> m.n. schrieb:
>> Sieh Dir mal die Xmega an!
>
> wie war das mit 32-bit Architekturen, die sich nicht durgesetzt haben^^
> ;)
> Außerdem, dann sind wir ja genau da: Kein DMA für 8-bitter!

Alter, hol mal Luft und sieh Dir mal die Xmega genauer an :-(

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

ui schrieb:
>> Sieh Dir mal die Xmega an!
>
> wie war das mit 32-bit Architekturen, die sich nicht durgesetzt haben^^
> ;)

XMegas sind 8-Bitter.

Einer der vielen Gründe für die 8-Bitter sind auch die Lizenzen, die 
sehr viele Fromen immer noch für die 8051 Architektur haben (das fängt 
bei TI und Silabs an und hört bei Winbond auf) und keine Gründe sehen, 
warum sie das für einfachere Steuerungsaufgaben nicht benutzen sollten.
Gerade der 8051 ist ja ein Musterbeispiel für sauberen Code und 
vielseitige Architektur.

: Bearbeitet durch User
von Jens W. (jensw)


Lesenswert?

Der Markt liefert das was benötigt wird. Also liegt das Problem beim 
Design.
Die Komplexität der Elektroniken steigt stetig (ich kenne das aus 
automotive).
Da hat man meist schon irrsinnige Anforderungen. Ich frage mich, warum 
ein Fensterheber LIN/CAN braucht.
Auch Spoiler werden sicherheitsrelevant geplant. Da ist für 8-bitter 
kein Platz mehr. Auch wenn die Funktion (Spoiler raus und rein) leicht 
zu bewältigen wäre. Das Drumrum machts aus.

Also wird die Entwicklung auch von den Konzernen getrieben. Da lässt 
sich dann leicht über Sinn und Unsinn streiten.
Auch geht der Trend in Richtung automatischer Codeerzeugung und so 
weiter.
Da wird der Speicher dann schnell zu klein. Und wenn man schon 500kB 
Flash braucht liegt es auch nahe auf 32bit umzusteigen.

Ich hänge sehr an den 8-bittern aber die Entwicklung werden wir leider 
nicht aufhalten können.

von Bitwurschtler (Gast)


Lesenswert?

ui schrieb:

>> Es ist also die Bequemlichkeit der Entwickler die den 8 Bittern den
>> Todesstoß versetzt, nicht der technische Fortschritt. Oder ein
>> Glaubenskrieg.
>
> Gibt übrigens einen Ausdruck für sowas: Abstraktion. Die erkauft man
> sich mit Overhead.
> Hat auch gewaltige Vorteile (gerade für heutige Elektronikprodukte, die
> möglichst schnell auf den Markt sollen): Man braucht sich mit den
> Details erstmal nicht rumschlagen, sondern erst, wenn durch die
> Abstraktion Fehler entstanden sind.

Ja aber was will man bei 4 Buttons und einem Statusdisplay noch 
abstrahieren?
Und welchen Vorteil so das bringen wenn auf der Kaffeemaschine ein Linux 
läuft?

Mehr heiße Luft als Power - mehr HAL als Hardware. So seh ich das.

von Paul R. (atmega9)


Lesenswert?

Bitwurschtler schrieb:
> Und welchen Vorteil so das bringen wenn auf der Kaffeemaschine ein Linux
> läuft?

Das kann man auf die Packung schreiben. Alles Marketing.

von Fitzebutze (Gast)


Lesenswert?

>
> Deswegen wird doch das SREG auf dem Stack gespeichert? Oder spielst du
> auf den Zugriff der nicht komplett inkrementierten Variable in
> Interruptroutine an?

Genau das.
Der Prozessorstatus ist nicht das Problem, wenn's da einen Bug gäbe, 
würde es sofort knallen. Fies ist, wenn es bloss alle paar Tage knallt..

von Alter_Walder (Gast)


Lesenswert?

ui schrieb:
> Alter_Walder schrieb:
>> Naja wenn da jemand mit AutoSar anfängt, dann brauch man ja fast ein den
>> 32er nur für den ganzen Overhead der da erzeugt wird.
>
> So ein Bockmist hab ich selten gehört.
> Auf welchen Overhead sprichst du an? RTE? Oder das ganze Zeugs darunter?
> Betriebssystem?
> Bevor man solche unqualifizerten Aussagen einfach so in dem Raum
> schmeißt, sollte man sich damit mal beschäftigen.
> Wie immer in der Informatik gilt auch da: "Das kommt drauf an".

Ja in der Tat es kommt drauf an.
Die Implementierung mit OS und RTE, die mir hier aufgewzungen wurde 
würde ein AVR richtig gut auslasten :D. Eine Bewertung der Qualität 
dieser Implementierung steht mir nicht zu, weils die erste ist mit der 
ich zu tun hab. (An sich ist die Idee dahinter ja sinnvoll)


Aber naja die 32er werden wohl interessant wenn man sich schnell und 
einfach einsetzen kann. Wie die ATmegas halt.

Die IDEs die von den Herstellern angeboten werden sind doch eh alles 
Eclipse-Derivate. Manche haben noch ein paar Plugins um die 
Pheripherie-Bibs einfacher benutzbar zu machen. Aber im grunde genommen 
ist es immer das gleiche.

Was mich aber an diesen Bibs immer stört, ist das man da zwar schnell 
mal was zusammenwurschdeln kann, aber nicht wirklich genau weis wie die 
manchmal doch recht komplexe Peripherie funktioniert. Ich hab da immer 
so ein gefühl wie bei meiner alten Schrottkarre. Fährt zwar aber man 
weis nicht wie lange noch oder warum noch.

von ui (Gast)


Lesenswert?

Matthias S. schrieb:
> XMegas sind 8-Bitter.

m.n. schrieb:
> Alter, hol mal Luft und sieh Dir mal die Xmega genauer an :-(

oh sorry, mein Fehler :/

Bitwurschtler schrieb:
> Und welchen Vorteil so das bringen wenn auf der Kaffeemaschine ein Linux
> läuft?

Anbindung ans WLAN ist rel. einfach? Ich brauchs zwar nicht, aber so 
wird heute gedacht. Oder Anbindung ans Handy? Auf Linux entwickeln ist 
dann doch nochmal um ein gutes Einfacher als Bare-Metal.

Bitwurschtler schrieb:
> Ja aber was will man bei 4 Buttons und einem Statusdisplay noch
> abstrahieren?

Naja... Ein sehr überspitztes Beispiel.
Aber gerade Arduino hat ja sehr viele Hobbyisten in die Welt der µC 
gebracht. Arduino abstrahiert ja auch enorm von der HW. Wenn man auf 
einem Arduino dann mal komplexere Dinge machen will, stellt man auch 
sehr schnell fest, dass
- der Speicher zu klein ist
- das Ding zu langsam ist (Hallo Abstraktionsoverhead)
- manche Berechnungen ewig dauern (float)

Und das erkauft man sich halt dann mit einer einfacheren Programmierung. 
(Ich sag nicht das das gut ist, das ist eine reine Beobachtung)

von Bitwurschtler (Gast)


Lesenswert?

Paul R. schrieb:
> Bitwurschtler schrieb:
>> Und welchen Vorteil so das bringen wenn auf der Kaffeemaschine ein Linux
>> läuft?
>
> Das kann man auf die Packung schreiben. Alles Marketing.

Und genau so ist es für andere ein Kaufargument das gerade wenig 
Computer-Hokus-Pokus drin ist: 
http://www.heise.de/ct/ausgabe/2016-15-Schlagseite-3254925.html ;-)

von 6a66 (Gast)


Lesenswert?

Bitwurschtler schrieb:
> also die Bequemlichkeit der Entwickler die den 8 Bittern den
> Todesstoß versetzt,

Nein, das Gewinnstreben des Managements das fordert Produkte schneller 
umzusetzen, Entwickler leichter ausgetauschbar sind, Abteilungen 
leichter verlagerbar werden. Und Kunden permanent nach billigeren 
Produkten mit mehr Funktionen schreien egal ob die besser sind oder 
nicht oder die Funktionen überhaupt benötigt werden.

rgds

von Paul R. (atmega9)


Lesenswert?

ui schrieb:
>> Und welchen Vorteil so das bringen wenn auf der Kaffeemaschine ein Linux
>> läuft?
>
> Anbindung ans WLAN ist rel. einfach?

Ja. Mit ESP2866.

von 6a66 (Gast)


Lesenswert?

Bitwurschtler schrieb:
> Und genau so ist es für andere ein Kaufargument das gerade wenig
> Computer-Hokus-Pokus drin ist:
> http://www.heise.de/ct/ausgabe/2016-15-Schlagseite-3254925.html ;-)

Die sind aber leider in der Minderzahl :) Auch wenn es sinnvoll wäre.

rgds

von Dussel (Gast)


Lesenswert?

Alter_Walder schrieb:
> Was mich aber an diesen Bibs immer stört, ist das man da zwar schnell
> mal was zusammenwurschdeln kann, aber nicht wirklich genau weis wie die
> manchmal doch recht komplexe Peripherie funktioniert.
Das kenne ich, weil ich alles genau wissen will und niemandem so recht 
vertraue, aber ich denke, da muss man sich dran gewöhnen. Auf einem 
Computer mache ich mir auch keine Gedanken darüber, wie ein 'cout<<' 
arbeitet, sondern nutze es einfach, mit der Erfahrung, dass es 
normalerweise funktioniert.
Bibliotheken können auch fehlerhaft sein, aber ich denke, es lohnt sich 
nicht, deswegen ewig Zeit mit jeder einzelnen davon zu verschwenden.

von ui (Gast)


Lesenswert?

Alter_Walder schrieb:
> Ja in der Tat es kommt drauf an.
> Die Implementierung mit OS und RTE, die mir hier aufgewzungen wurde
> würde ein AVR richtig gut auslasten :D. Eine Bewertung der Qualität
> dieser Implementierung steht mir nicht zu, weils die erste ist mit der
> ich zu tun hab. (An sich ist die Idee dahinter ja sinnvoll)

schau dir mal Erika Autosar OS an. Läuft auch stabil auf einem AVR :) 
und da ist noch jede Menge Platz für Tasks :)

von Gerhard O. (gerhard_)


Lesenswert?

Ich könnte mir vorstellen, daß hauptsächlich die IoT Bewegung die 
8-Bitter langsam aber sicher wie ein Hawaiischer Lavafluß ablösen wird.

Wo früher ein 8-Bitter die markttechnischen und ingenieurmäßigen alle 
Anforderungen erfüllten, muß wegen der drastisch erhöhten 
Vernetzungsfunktionen ein leistungsfähiger uC her um alle neuen 
Andorderungen zu erfüllen.

Die Entwicklung is dann mit 32- Bittern wahrscheinlich wegen dem 
reicheren Code Ökusystem wahrscheinlich zweckmäßiger. Dazu kommt, daß 
die Halbleiterfirmen die potenziellen Vermarkterfirmen mit 
leistungsfähigen Bausteinen zu füttern. Diese Vorgehensweise setzt dann 
Trends...

Ist allerdings nur meine Vorstellung um das Warum.

: Bearbeitet durch User
von Bitwurschtler (Gast)


Lesenswert?

6a66 schrieb:
> Nein, das Gewinnstreben des Managements das fordert Produkte schneller
> umzusetzen, Entwickler leichter ausgetauschbar sind, Abteilungen
> leichter verlagerbar werden.

Tausch mal einen 32 bit Windows Entwickler mit einem 32bit Linux Guru 
aus - das ist nicht einfach DAS ist ein Glaubenskrieg. Dagegen ist so 
einem 8bit Bitwurschtler wurscht welche Nummer auf dem Gehäuse steht, 
Hauptsache man kann sich "Wahrer Bit-Magier" beweisen ;-)

"Schneller fertig" zieh ich auch bei 32bit Kaffemaschine im Vgl zu 8 bit 
Maschine auch in Zweifel...
Gewinnstreben ... mit Kapitalismuskritik hat die 8 bit Diskussion wenig 
gemein, auch wenn das scheinen mag wenn man schaut wie lang der Ostblock 
auf 8bit setzte: 
http://www.robotrontechnik.de/html/computer/industrieroboter.htm

Eher im Gegenteil: mit 8bit ist die Marge besser weil IT-Kosten 
(Lizenzen/Schulung) geringer.

von Paul R. (atmega9)


Lesenswert?

Gerhard O. schrieb:
> Ich könnte mir vorstellen, daß hauptsächlich die IoT Bewegung die
> 8-Bitter langsam aber sicher wie ein Hawaiischer Lavafluß ablösen wird.

Wobei IoT IMHO noch nicht wirklich durchstartet. Sinnlose Funktionen, 
astronomische Preise und Sicherheitslücken à la MS Vista erfreuen nicht 
gerade. DIY Iot-Geräte werden trotzdem noch immer meistens mit 
entsprechender Zusatzhardware gebaut.

Aber die Frage ist ja nicht ob 32 bit besser ist. Klar, in Bereichen, wo 
er benötigt wird schon. In anderen eben nicht. Dass die Entwicklung 
weitergeht ist auch klar. Ich frag mich eher wie lange es z.B noch den 
AVR gibt.

von ui (Gast)


Lesenswert?

Paul R. schrieb:
> Ich frag mich eher wie lange es z.B noch den
> AVR gibt.

Solang bis microchip sagt, den stellt ihr jetzt ein.

von (prx) A. K. (prx)


Lesenswert?

Paul R. schrieb:
> Ich frag mich eher wie lange es z.B noch den AVR gibt.

So lange wie die Produktion sich lohnt, also wie er in ausreichender 
Stückzahl nachgefragt wird. Nur ein Teil jener Kunden, die von AVR weg 
migrieren, wird statt dessen andere Microchip Controller verwenden. Der 
anzunehmend grössere Teil geht verloren.

von TriHexagon (Gast)


Lesenswert?

8-Bit wird es noch lange zu kaufen geben, das ist klar. Aber gibt es 
heute noch 8-Bit Familien die aktiv weiterentwickelt werden?

von Lothar (Gast)


Lesenswert?

Fitzebutze schrieb:
> Ich möchte mal behaupten, dass ein 32 bit ARM Cortex M0 robuster zu
> programmieren ist als ein AVR oder das n'te 8051 Derivat

Keineswegs: Stichwort M0 unaligned load hardfault

ui schrieb:
> Außerdem, dann sind wir ja genau da: Kein DMA für 8-bitter!

EFM8 8051 haben DMA

Alter_Walder schrieb:
> Wie sieht das eigentlich mit Die-Fläche aus? So ein AVR ist doch
> Platzmässig bestimmt wesentlich kleiner als ein ARM Cortex M3 mit
> gleicher Ausstattung?

8051 und M0 sind wesentlich kleiner zu haben als AVR:

http://www.mouser.de/ProductDetail/NXP-Semiconductors/LPC11A04UK118/?qs=sGAEpiMZZMuleuVm2ofeXwSxz7NGthrP
http://www.mouser.de/ProductDetail/Silicon-Labs/EFM8SB10F8G-A-CSP16/?qs=sGAEpiMZZMvqv2n3s2xjsX2zyxTNAb3cPBEqS5R1MUb1XG5hxpFxUA%3d%3d

MaWin schrieb:
> Es gibt unter Hobbyisten wohl genau 2 Pfade:
> AVR und ARM(Cortex)

Und in der Industrie nur 8051 und ARM ...

von Paul R. (atmega9)


Lesenswert?

TriHexagon schrieb:
> 8-Bit wird es noch lange zu kaufen geben, das ist klar. Aber gibt es
> heute noch 8-Bit Familien die aktiv weiterentwickelt werden?

In irgendeiner Elektor war mal was über die neuen AVR-Typen. Ich such 
dir die Nummer raus, wenns dich interessiert. Die wurden schon ein 
bisschen weiterentwickelt, gibts halt nur noch in SMD.

von Fitzebutze (Gast)


Lesenswert?

Paul R. schrieb:
> Gerhard O. schrieb:
>> Ich könnte mir vorstellen, daß hauptsächlich die IoT Bewegung die
>> 8-Bitter langsam aber sicher wie ein Hawaiischer Lavafluß ablösen wird.
>
> Wobei IoT IMHO noch nicht wirklich durchstartet. Sinnlose Funktionen,
> astronomische Preise und Sicherheitslücken à la MS Vista erfreuen nicht
> gerade. DIY Iot-Geräte werden trotzdem noch immer meistens mit
> entsprechender Zusatzhardware gebaut.
>

Der Hype wird seit ein paar Jahren immer wieder auf der Embedded World 
aufgewärmt, und wenn man dann genau hinschaut, ist es doch wieder der 
alte Käse.
Eine IP-Implementation schreit natürlich schon ein bisschen nach 32 bit, 
aber wenn für ein Ding im Internet gleich ein Linux hermuss, kann man's 
gleich sein lassen - zumindest wenn es simpel, robust und sparsam sein 
soll.
Die bisher interessanten Sachen in dem Bereich schienen mir:
- cc430 (msp430 architektur, aber 16 bit): Leider dank des grottigen 
Simpliciti-Stacks nicht wirklich von den Usern geliebt worden
- ESP8266/Xtensa 32 bit: Interessantes Konzept, nur auch leider nicht 
reif für die Industrie, das SDK ist nahezu unbrauchbar und 
hardwareseitig dürfte es auch noch einige Redesigns nötig haben.
- Wiznet-51xx etc. (TCP-Stack aufm Silicon). Da kann man auch seinen 
8-Bitter noch ranhängen, wenn man unbedingt will.

> Aber die Frage ist ja nicht ob 32 bit besser ist. Klar, in Bereichen, wo
> er benötigt wird schon. In anderen eben nicht. Dass die Entwicklung
> weitergeht ist auch klar. Ich frag mich eher wie lange es z.B noch den
> AVR gibt.

Ich kenne (paranoide) Leute, die setzen die Dinger in der Industrie 
schon jetzt nicht mehr ein oder suchen sich nen vertrauenswürdigen 
Broker, der die Teile noch eine Weile lang führt. Ansonsten dürfte aber 
die Arduinobastler-Community auch noch etwas Monete umsetzen. Nur gibt's 
halt keine Garantie, wie lange es Typ XYZ noch gibt. Dürfte aber ähnlich 
wie beim PIC sein.

Für mich geht der logische Weg in die Richtung, die Espressif verfolgt 
hat: Simplen, Code-kompakten 32-Bit-Core, der nicht viel kostet, zu nem 
fertigen SoC machen. ARM ist vom Core her zu teuer, könnte sein, dass 
uns aus der MIPS-Ecke noch einige Überraschungen aus China blühen (Wie 
schon die Mediatek-76xx chipsets).

von TriHexagon (Gast)


Lesenswert?

Paul R. schrieb:
> TriHexagon schrieb:
>> 8-Bit wird es noch lange zu kaufen geben, das ist klar. Aber gibt es
>> heute noch 8-Bit Familien die aktiv weiterentwickelt werden?
>
> In irgendeiner Elektor war mal was über die neuen AVR-Typen. Ich such
> dir die Nummer raus, wenns dich interessiert. Die wurden schon ein
> bisschen weiterentwickelt, gibts halt nur noch in SMD.

Interessieren würde es mich schon, nur habe ich leider keine Elektor zur 
Hand. Im Internet finde ich leider nichts drüber...

von Lothar (Gast)


Lesenswert?

TriHexagon schrieb:
> Aber gibt es heute noch 8-Bit Familien die aktiv weiterentwickelt

EFM8 8051 sind erst 2015 rausgekommen, EFM8LB erst dieses Jahr. Wir 
evaluieren grade die Umstellung von einem ARM Design, denn EFM8LB hat 
14-bit 1MSPS ADC und 4x 12-bit DAC, da gibt es aktuell keinen ARM

http://www.silabs.com/products/mcu/8-bit/Pages/efm8.aspx
http://www.silabs.com/products/mcu/8-bit/efm8-laser-bee/Pages/efm8-laser-bee.aspx

von Paul R. (atmega9)


Lesenswert?

Ist in Elektor Nr.541/542. Seite 34 35:

seit Anfang 2015 AVR B-Typen
130nm-Prozess
genauer RC-Oszillatoren
Seriennummer
mehr I/O
Capacitive Touch in HW
neue ATtinys

nur im SMD-Gehäuse

Eval-Bords: http://www.atmel.com/webdoc/atmega168pbxmini/index.html

von H-G S. (haenschen)


Lesenswert?

Also mich beschleicht ständig das Gefühl dass die uns unbedingt ihren 
PC-gebundenen C-Code-per-USB-Ramsch aufdrängen wollen.

Vielleicht damit sie jeden jederzeit ausspähen können -> NSA und Co.


Fast habe ich Angst da ich ja im Moment etwas PC-unabhängiges bastle, 
hoffentlich kriege ich da keine Repressalien  :-)

von Paul R. (atmega9)


Lesenswert?

H-G S. schrieb:
> Fast habe ich Angst da ich ja im Moment etwas PC-unabhängiges bastle,
> hoffentlich kriege ich da keine Repressalien  :-)

Pass auf, dass du keinen NSL kriegst... :D

von Dauergast (Gast)


Lesenswert?

Die Notwendigkeit von Authentifizierung und (asymmetrischer) 
Verschlüsselung verbannt 8bit in den Bereich der Interfaceschaltungen 
für dumme Sensoren/Aktoren. Sobald es die nicht mehr gibt, war's das.

von Paul R. (atmega9)


Lesenswert?

Dauergast schrieb:
> Die Notwendigkeit von Authentifizierung und (asymmetrischer)
> Verschlüsselung verbannt 8bit in den Bereich der Interfaceschaltungen
> für dumme Sensoren/Aktoren. Sobald es die nicht mehr gibt, war's das.

Diese Aussage finde ich ziemlich sinnlos. Die meisten 8bit AVR Typen 
sind nicht gar dafür gebaut Verschlüsselung zu betreiben. Eigentlich 
auch die 32 bit Typen nicht. Verschlüsselung und Authentifizierung 
benötigt man außerdem IMHO nur wenn es um Netzwerk geht. In solch einem 
Fall kommt dann (fast) immer ein OS (meist Linux) zum Einsatz. Ich habe 
noch keinen gesehen, der den kompletten TCP/IP Stack selbst 
implementiert hat. Das ist schließlich auch nicht die Aufgabe eines MC.

von Lurchi (Gast)


Lesenswert?

Die 32 Bit µC sind nur konkurrenzfähig, wenn sie mit kleinen Strukturen 
hergestellt werden. Entsprechend ist die Die Fläche nicht ganz günstig 
und die Spannung gering.

Für Anwendungen die kräftige Treiber brauchen oder mit höherer Spannung 
laufen sollen, wird man auch in Zukunft noch eher die älteren FABs für 
eher größere Strukturen nutzen und da dann halt weiter 8 Bit µC 
produzieren. Für viele Aufgaben ist die Rechenleistung und Compiler 
Unterstützung ja auch vollkommen ausreichend. Selbst wenn nur die 
Anwendungen übrig bleiben, die mit 1 MHz oder weniger laufen ist das 
noch ein recht großer Marktanteil.

Für die 4/8 Bit µC ohne Unterstützung durch C Compiler könnte es aber 
ggf. schon zu Ende gehen. Aber selbst da ist ggf. noch genügend Bedarf 
für alte Produkte um weiter zu produzieren so lange die alten Masken / 
Prozesse laufen. Bei so etwas wie RFID kommen auch noch Anwendungen mit 
hoher Stückzahl und geringen Anforderung dazu - ggf. sogar Raum für neue 
4 oder 6 Bit µCs.

Für kleine Anwendungen und hohe Anforderungen an die Zuverlässigkeit hat 
der eher einfache 8 Bit µC in Assembler Programmiert auch Vorteile - 
Compiler Bugs entfallen und die Errata List ist meist auch viel kürzer. 
So etwas wie ein 8051 ganz ohne Errata und gut geprüft wäre z.B. 
durchaus möglich - die ARMs dürften da noch einige Zeit von träumen.

von c-hater (Gast)


Lesenswert?

MaWin schrieb:

> Sie die 4-bitter ausgestorben ?
>
> Fast.
>
> Dabei eigenen sie sich zum Berechnung von Dezimalzahlen (Uhren,
> Taschenrechner) besser als 8 bitter.

Inwiefern? Das wäre (bestenfalls) nur dann der Fall, wenn es um ein 
einzelnes BCD-Digit ginge. Geht es aber praktisch nie. Und selbst wenn 
das doch ausnahmsweise mal der Fall sein sollte: alle brauchbaren 
8-Bitter stellen natürlich spezielle Features zur effizienten 
BCD-Behandlung bereit, mit denen man notfalls auch ein einzelnes Digit 
erschlagen bekommt...

Allerdings: auch µC mit mit noch höherer Verarbeitungbreite stellen oft 
spezielle Instruktionen und/oder Flags für den effizienten Umgang mit 
BCD-Zeugs bereit. Das "Problem" ist nur: C-Frickler können nicht 
unmittelbar davon profitieren. Deswegen ist (wie immer) die ultimative 
Lösung: Assembler.

Naja, in vielen Fällen greift immerhin ein etwas begabterer C-Fetischist 
den völligen C-Idioten mit einer entsprechenden Lib unter die Arme. Wohl 
nur deshalb, damit die auf keinen Fall merken, wie beschränkt sie 
eigentlich durch C sind und so weiter so treudoof durch's Leben 
stolpern, wie es ihre Bibel und ihre Propheten vorgeben...

von Axel S. (a-za-z0-9)


Lesenswert?

Paul R. schrieb:
> Bis auf die PIC-Controller haben
> fast alle Hersteller auf 32 Bitter gesetzt.

Dieser Satz ergibt für mich keinen Sinn. Was heißt "auf 32 Bit gesetzt"? 
Und wieso sollen gerade PIC da außen vor sein, wo es doch sogar eine 
PIC32 Familie gibt? Ist es nicht vielmehr so, daß nahezu alle Hersteller 
von µC mehrere Pferde von 8 Bit bis 32 Bit im Rennen haben?

> Sie sollten angeblich nach und nach alle 8 bit MCUs ablösen.

Sagt wer? Ich halte mich da eher an Mark Twain: "Vorhersagen sind 
schwierig. Vor allem, wenn sie die Zukunft betreffen".

> Trotzdem kommt es mir so vor, als würde das nicht funktionieren.
> Laut Wikipedia haben die 8 bit MCUs immer noch den größten Marktanteil.

So ist das wohl.

> Meine Frage daher: Ist das Aussterben von 8 bit MCUs und speziell den
> AVRs nur ein Wunsch der Hersteller

Warum sollte das ein Wunsch der Hersteller sein? Wenn du ein Bäcker 
wärst und du würdest Brötchen und Baguettes verkaufen, würdest du dir 
dann wünschen daß die Brötchen von Baguettes verdrängt werden? Oder 
würdest du nicht weiter Brötchen und Baguettes backen, solange sich 
beide gut verkaufen?

Aber gut, betrachten wir einfach mal die vielfach (wenn auch nicht von 
den Herstellern) geäußerte Prognose, 32-Bitter würden die 8-Bitter über 
kurz oder lang verdrängen. Und fragen uns, warum das anscheinend nicht 
passiert. Dann gibt es eine Menge Gründe:

- 8-Bitter sind immer noch billiger als 32-Bitter. Gerade im Massenmarkt 
zählt da jeder Cent. Beim Bastler ist das natürlich anders.

- 8-Bitter sind tendenziell robuster und leichter zu verarbeiten. Sie 
können 5V, kommen in China-tauglichen Gehäusen, brauchen keine teuren 
Mehrlagenplatinen mit Versorgungslagen.

- existierende Designs mit 8-Bittern werden nicht ohne sehr triftigen 
Grund auf 32 Bit umgestellt. Wenn überhaupt, dann sterben diese Designs 
aus und werden von Neudesigns ersetzt.

- 8-Bitter sind für viele oder gar die meisten Anwendungen vollkommen 
ausreichend, was Geschwindigkeit und Resourcen angeht. Das könnte sich 
mit dem IoT Hype ändern. Aber darauf wetten würde ich nicht.

- als Firma legt man sich auf einen oder einige wenige µC, bestenfalls 
µC-Famlien fest. Das liegt daran, daß Tools (Hard- und Software) und 
Mitarbeiter (respektive deren Ausbildung) Geld kosten. So eine 
Investition wirft man nicht ohne sehr guten Grund weg.

von (prx) A. K. (prx)


Lesenswert?

c-hater schrieb:
> Allerdings: auch µC mit mit noch höherer Verarbeitungbreite stellen oft
> spezielle Instruktionen und/oder Flags für den effizienten Umgang mit
> BCD-Zeugs bereit.

Welche aktuell verbreiteten 32- und 64-Bit Prozessoren enthalten 
eigentlich BCD-Operationen, abgesehen von x86? Insbesondere auch in 
voller Breite, denn in 8 Bits wärs ja absurd.

> nur deshalb, damit die auf keinen Fall merken, wie beschränkt sie
> eigentlich durch C sind und so weiter so treudoof durch's Leben
> stolpern, wie es ihre Bibel und ihre Propheten vorgeben...

Kein Zweifel, der Bedarf für dezimale Arithmetik ist in bestimmten 
Märkten vorhanden, der Rundungseffekte wegen. Dies allerdings auf einem 
64-Bit Boliden mit BCD-Arithmetik durchzuführen ist ungefähr so 
sinnvoll, wie Taschenrechner aus Röhren aufzubauen.

Mit IEEE 854 wurde schon vor Jahrzehnten ein Standard für dezimale 
Fliesskommaverarbeitung definiert und mit IEEE 754-2008 konkretisiert. 
Wer dahinter aber BCD-Arithmetik vermutet, der liegt falsch.

Es gibt es Prozessoren, die dezimale Fliesskommaformate in Hardware 
unterstützen (z.B. IBM ab POWER6). Selbstverständlich haben solche 
Datenformate in die entsprechenden Compiler Einzug gehalten, sowie als 
optionale Erweiterung in den C Standard. Folglich ist ein Rückgriff auf 
Assembler nur jenen empfohlen, die noch treudoof in BCD Formaten denken.

: Bearbeitet durch User
von ... (Gast)


Lesenswert?

Hier mal meine Erfahrung bzgl. 8 oder 32 bit im Heimbereich.

Ein ca. 2-3 Jahre genutzter (SD-)Sat-Receiver. Eine Recherche
ergab MIPS-basiert. MPEG2-Dekoder in Software.
Abstuerze jeden Tag: Einer bis Mehrere.
Immerhin waren die Entwickler so clever, der Konstruktion
ein Watchdog auf das Video-Out-Signal zu spendieren.
Dann machte der Receiver einen richtigen Kaltstart, inklusive
dem Erloeschen der Betriebs-LED.

Seine Nachfolger sind jetzt 8051-basiert mit HW-MPEG-Dekoder.
Abstuerze sind bis jetzt noch nie aufgetreten, trotz erweitertem
Funktionsumfang.

von Dieter F. (Gast)


Lesenswert?

Paul R. schrieb:
> Bis auf die PIC-Controller haben
> fast alle Hersteller auf 32 Bitter gesetzt.

Kannst Du das belegen?

von 2⁵ (Gast)


Lesenswert?

... schrieb:
> Eine Recherche ergab MIPS-basiert. MPEG2-Dekoder in Software.
[...]
> Seine Nachfolger sind jetzt 8051-basiert mit HW-MPEG-Dekoder.

Ein SUUUPER Beispiel für 8-bit vs 32-bit! Respekt! Das die Entwickler 
beim
ersten Pfusch abgeliefert haben, lag natürlich daran, das der µC 32 Bit 
hatte!

von ... (Gast)


Lesenswert?

> Ein SUUUPER Beispiel

Nennt sich pars pro toto.

von (prx) A. K. (prx)


Lesenswert?

A. K. schrieb:
> Welche aktuell verbreiteten 32- und 64-Bit Prozessoren enthalten
> eigentlich BCD-Operationen, abgesehen von x86? Insbesondere auch in
> voller Breite, denn in 8 Bits wärs ja absurd.

In x86-64 sind die AAx/DAx Befehle übrigens rausgeflogen, und x87 mit 
seinem BCD-Format ebenfalls. Das sind zwar keine µCs, suggeriert aber 
ebenfalls, dass die Zukunft von BCD in der Vergangenheit liegt.

von Paul R. (atmega9)


Lesenswert?

Dieter F. schrieb:
> Paul R. schrieb:
>> Bis auf die PIC-Controller haben
>> fast alle Hersteller auf 32 Bitter gesetzt.
>
> Kannst Du das belegen?

Ist nur meine Meinung basierend auf Werbung in diversen Medien. Immerhin 
werden von MC die PICs immer noch beworben. Andere Hersteller machen das 
nicht mehr wirklich. Ist aber nur meine subjektive Meinung...

von Dauergast (Gast)


Lesenswert?

Paul R. schrieb:

>> Authentifizierung und (asymmetrischer) Verschlüsselung

> Die meisten 8bit AVR Typen sind nicht gar dafür gebaut
> Verschlüsselung zu betreiben.

Genau. Es fehlen RAM und Rechenleistung. Da hilft auch Aufbohren nicht 
viel.

> Eigentlich auch die 32 bit Typen nicht.

Die schaffen derzeit gängige Verfahren aber problemlos, oft auch mit 
Hardwareunterstützung für Verschlüsselung und Keyablage.

> Verschlüsselung und Authentifizierung benötigt man außerdem IMHO
> nur wenn es um Netzwerk geht.

Da hast Du natürlich Recht, ein handelsüblicher Nagelknipser braucht 
sowas derzeit nicht. Nicht mal 8bit ... naja, es sei denn, man verlegt 
ihn ständig, da wäre dann ein Ortungssystem schon sinnvoll ... aber nur, 
wenn nicht jeder drauf zugreifen kann. Ach Mist, der profitiert also 
auch von 32bit.

> In solch einem Fall kommt dann (fast) immer ein OS
> (meist Linux) zum Einsatz.

Nein, wozu auch ? Braucht man nicht.

> Ich habe noch keinen gesehen, der den kompletten TCP/IP
> Stack selbst implementiert hat.

Nein, wozu auch? Gibt's doch schon.

> Das ist schließlich auch nicht die Aufgabe eines MC.

OMG, das solltest Du unbedingt ARM, ST, TI, Renesas, Infineon und 
Konsorten mitteilen. Die entwickeln ja offenbar völlig an den Aufgaben 
eines MC vorbei ;-)

von HVV (Gast)


Lesenswert?

A. K. schrieb:
> In x86-64 sind die AAx/DAx Befehle übrigens rausgeflogen, und x87 mit
> seinem BCD-Format ebenfalls.

Schon im Pentium 1 gab es keinen 'echten' math. Coprozessor mehr, nur 
dessen Register, die ganze Fliesskommaarithmetik wurde von den ALUs 
erledigt.

von Karl (Gast)


Lesenswert?

> Andere Hersteller machen das nicht mehr wirklich.

Worin liegt der Unterschied zwischen "nicht mehr wirklich" und "nicht 
mehr"?

> Ist aber nur meine subjektive Meinung...

Worin ist der Unterschied zwischen "subjektive Meinung" und "Meinung"?

von Paul R. (atmega9)


Lesenswert?

Ich denke, wir reden schon wieder ein bisschen am Thema vorbei...

von 2⁵ (Gast)


Lesenswert?

Ist doch eigentlich ganz einfach:

1) Es gibt mehr Designs in 8-Bit, da länger auf dem Markt
2) Dadurch haben viele Entwickler gute oder bessere Erfahrung mit 8-bit 
µC als im Vergleich mit 32 bit. Also machen sie neuen Designs auch in 
8-Bit, wenn 3) zutrifft.
3) Für viele Design ist ein 8-bit µC ausreichend
4) Ein Redesign 8 auf 32 Bit macht man nur, wenn man muss! Also laufen 
diese 8-bit Designs in der Produktion oft lang.
5) Oft laufen noch 8-Bitter als Aktoren/Sensoren zusammen mit 32-Bit 
Hauptprozessoren, d.h. auf einen 32-bit µC kommen mehrere 8-bit.
6) Auch wenn der Preis der Cortex-M0 jetzt schon oft den von 8-bit µC 
unterbietet, ist oft die Stückzahl nicht so groß, dass ich a) deswegen 
ein Redesign bei einem bestehenden Produkt lohnt oder dass man 
Entwickler-Know-How über Bord wirft.

Klar, ein Entwickler, der gute Erfahrungen mit Cortex-Mx Prozessoren 
hat, wird für ein Neudesign, welches zwar prinzipiell mit einem 8-Bit µC 
auskommen würde, einen Cortex-M0 nehmen.

von (prx) A. K. (prx)


Lesenswert?

HVV schrieb:
> Schon im Pentium 1 gab es keinen 'echten' math. Coprozessor mehr, nur
> dessen Register, die ganze Fliesskommaarithmetik wurde von den ALUs
> erledigt.

Die Fliesskommaeinheit ist in besagtem Pentium zwar im Prozessor und im 
Befehlsablauf integriert und somit kein Koprozessor mehr - aber die 
Berechnungen der Integer- und der Fliesskommaoperationen erfolgten 
vollständig voneinander getrennt. Gemeinsam verwendete ALUs gab es nicht 
im Pentium 1 und nicht danach. Ausser bei der Integer-Multiplikation, 
die über Konvertierung und Fliesskommarechnung implementiert war 
(Division weiss ich nicht mehr).

Aber worauf ich raus wollte: In x86-64 flogen die entsprechenden Befehle 
und Register raus. Im 64-Bit Modus ist für Fliesskommarechnung nur noch 
SSE vorgesehen. Den Register-Stack und die Befehle des x87-Befehlssatzes 
gibt es darin (offiziell) nicht mehr. Und damit auch nicht mehr das 
x87-BCD-Format.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Karl schrieb:
> Worin ist der Unterschied zwischen "subjektive Meinung" und "Meinung"?

Ganz einfach: Meine Meinung ist selbstverständlich stets objektiv. 
Sofern deine Meinung damit nicht übereinstimmt ist sie demzufolge 
subjektiv. ;-)

von c-hater (Gast)


Lesenswert?

Dauergast schrieb:

> Die Notwendigkeit von Authentifizierung und (asymmetrischer)
> Verschlüsselung verbannt 8bit in den Bereich der Interfaceschaltungen
> für dumme Sensoren/Aktoren. Sobald es die nicht mehr gibt, war's das.

Also:

1. Es wird wohl in absehbarer Zukunft immer "dumme" Sensoren und Aktoren 
geben. Die sind nämlich einfach am billigsten herzustellen.

2. Es gibt keine generelle Notwendigkeit für Authentifizierung und 
(asymmetrische) Verschlüsselung. Die wird allein durch die Apologeten 
des "allways on" für jedes verschissene Device herbeigehypet. Nö: In 
meinem LAN ist es SICHER. Das einzige Device, was wirklich starke 
Authentifizierung und Verschlüsselung beherrschen muß, ist mein 
VPN-Gateway in Richtung des ungesicherten öffentlichen Netzes.

So einfach ist das. Alles darüber hinaus gehende kann man durch 
Fraktionierung des LAN simpelst abbilden. Der Kern ist immer: Wer das 
Netzwerk seines LAN tatsächlich beherrscht, der braucht keine starke 
Kryptographie für jeden verschissenen Endpunkt.

Und wer das nicht beherrscht, wird auch mit starker Kryptographie für 
jeden Endpunkt am Ende keine Sicherheit herstellen können. Dazu ist das 
System jedes einzelnen Endpunktes dann bereits viel zu komplex. Man 
stelle sich vor: Update-Orgien wie für Windows oder Linux, und das für 
jeden einzelnen verschissenen Sensor oder Aktor. Wer will das am Ende 
noch beherrschen...

von Holm T. (Gast)


Lesenswert?

Operator S. schrieb:
> Einem Glaubenskrieg begegnet man am besten mit Fakten.
>
> Paul R. schrieb:
>> Laut Wikipedia haben die 8 bit MCUs immer
>> noch den größten Marktanteil.
>
> Würde mich auch wundern wenn es anders wäre. 8 Bit µC gibt es seit 40
> Jahren, die Cortex-M 32 Bit waren dagegen die ersten µC, welche eine
> breite Akzeptanz erhalten haben.

Damit strafst Du die Motorola 683xx und Coldfire mit unverdienter 
Mißachtung.

Gruß,

Holm

von Dieter F. (Gast)


Lesenswert?

Paul R. schrieb:
> Ist nur meine Meinung basierend auf Werbung in diversen Medien.

Blubb :-)

von Dauergast (Gast)


Lesenswert?

c-hater schrieb:
> In meinem LAN ist es SICHER.

Wenn

- Du Dich auskennst
- alle Mitnutzer Deines LANs sich ebenfalls auskennen
- und/oder sich strikt an Deine Regeln halten
- Niemand fremde Devices (IP-Cam, Handy, Spielekonsole) benutzt

könnte es in Deinem LAN ziemlich sicher sein.

Der Anteil privat betriebener Netze, auf die das zutrifft, liegt 
vermutlich bei 0,irgendwas %.

> Wer will das am Ende noch beherrschen...

DAS ist eine ganz andere Frage, bei der ich auch ganz bei Dir bin - 
allerdings ist Fachwissen dabei auch nicht das Allheilmittel (siehe z.B. 
Heartbleed). Aber es können ja auch nicht alle in den Wald umziehen und 
sich von Krabbelgetier ernähren :-)

von Lothar (Gast)


Lesenswert?

2⁵ schrieb:
> Klar, ein Entwickler, der gute Erfahrungen mit Cortex-Mx Prozessoren
> hat, wird für ein Neudesign, welches zwar prinzipiell mit einem 8-Bit µC
> auskommen würde, einen Cortex-M0 nehmen

Keineswegs, wir nehmen ARM oder 8051 je nach Projekt, haben mit Keil 
auch dieselbe Toolchain. ARM meist wegen der Rechenleistung, 8051 wegen 
für ARM nicht verfügbarer Peripherie z.B. analog oder USB mit internem 
Oszillator. Bei ARM ist M3 meist der Vorzug vor M0 zu geben, bei 
gleichem Takt deutlich schneller zum praktisch selben Preis.

von Dieter F. (Gast)


Lesenswert?

Dauergast schrieb:

Lothar schrieb:

Schön, nicht erkannt: TROLL!

von MaWin (Gast)


Lesenswert?

c-hater schrieb:
> Inwiefern?

Aus genau demselben Grund, warum ein 8 bitter besser zur 
zeichenorientierten Bearbeitung geeignet ist als ein 32 bitter.

Die Schleifen und Adressen etc. gehen über die native Elementbreite.

Keine Fragen des aligments und paddings. Keine doppelten Abfragen
ob nun das carry oder half carry gesetzt war. Kein Verschnitt im
Speicher weil das nächste Element erst an 8 bzw. 32 bit Grenze
anfangen darf.

von (prx) A. K. (prx)


Lesenswert?

MaWin schrieb:
> Aus genau demselben Grund, warum ein 8 bitter besser zur
> zeichenorientierten Bearbeitung geeignet ist als ein 32 bitter.

Der 32-Bitter hat dann zwar ein paar ungenutze Bits im Register übrig, 
aber weshalb sollte er dabei schlechter sein als der 8-Bitter?

Bei 4 vs 8 Bits für Digits sieht es etwas anders aus, weil der 8-Bitter 
keine 4-Bit Objekte adressieren kann. Der 32-Bitter kann aber Bytes 
adressieren.

: Bearbeitet durch User
von Conte (Gast)


Lesenswert?

A. K. schrieb:
> Der 32-Bitter hat dann zwar ein paar ungenutze Bits im Register übrig,
> aber weshalb sollte er dabei schlechter sein als der 8-Bitter?

Genau richtig!

Was seid Ihr denn für Elektronik Gruftis ?

Das ganze kleinbitige uC Zeugsel verschwindet alles!
Genauso wie die DIL Bausteine und die bedrahteten
Widerstände!


Die Dinger gibt es nur deshalb noch zu kaufen, weil sie
in der weisen Ware massenweise ihr Unwesen treiben)

Wer was auf sich hält, das kann man auch hier in den Foren feststellen,

verbaut die ARM's von ST genauer gesagt die STM32F4xxx aufwärts.

von Conte (Gast)


Lesenswert?

Moby A. schrieb im Beitrag #4647617:
> die Programmierung mit mehr Intelligenz
> dramatisch zu vereinfachen

Ist ja bereits jetzt schon der Fall!
Wenn ich da an HAL denke - ein super Tool.

von R1206 (Gast)


Lesenswert?

6a66 schrieb:
> Und irgendwann brauchte man zum tippen
> dieses Beitrags keinen Pentium mit 100MHz mehr sondern einen quadcore
> mit >2GHz und endlos Speicher.

Du hast recht!
ich habe gerade  auf meinen PC den DDR upgegradet auf 32 Gigis.

Dann habe ich den Ressourcenmonitor aufgerufen
und dann noch die HP42 Emulation aufgerufen.

Da kann man zusehen, also ich sehe das bei meinen Penti,
wie der hellblaue Bereich der Balkenanzeige  sofort kleiner wird.

Ich frage mich wo soll das ganze hinführen?

Ich warte bereits auf die ersten Cortex ARM's
die 1 Gig Ram haben und 4 Gig Flash besitzen.

Und wenn man dann hier in den Foren liest
scheitern die meisten Cortex Novizen mit dem Blinker Programm.
(das Programm  mit der LED)
Bei mir war das leider auch der Fall.

Da meine ich es ist gescheiter man bleibt doch bei den 8 Bitern.

Seht ihr das genau so ?

von Operator S. (smkr)


Lesenswert?

Holm T. schrieb:
> Damit strafst Du die Motorola 683xx und Coldfire mit unverdienter
> Mißachtung.

Tatsächlich habe ich noch nie etwas von denen gehört, ich ging immer 
davon aus, dass dies µProzessoren sind. Danke für die Richtigstellung.

von Le X. (lex_91)


Lesenswert?

A. K. schrieb:
> In x86-64 sind die AAx/DAx Befehle übrigens rausgeflogen, und x87 mit
> seinem BCD-Format ebenfalls. Das sind zwar keine µCs, suggeriert aber
> ebenfalls, dass die Zukunft von BCD in der Vergangenheit liegt.

War ein Ziel dieser Architektur nicht immer abwärtskompatibel zu 
bleiben?
D.h. ein aktueller x86-64 wäre nicht in der Lage ein 15 Jahre altes 
Programm auszuführen in dem diese Befehle verwendet werden?

Oder emuliert die CPU dann in Eigenregie diese Befehle?

von (prx) A. K. (prx)


Lesenswert?

Le X. schrieb:
> War ein Ziel dieser Architektur nicht immer abwärtskompatibel zu
> bleiben?

Ist sie auch.

> D.h. ein aktueller x86-64 wäre nicht in der Lage ein 15 Jahre altes
> Programm auszuführen in dem diese Befehle verwendet werden?

In den 16-Bit (8086/286) und 32-Bit Modi (ab 386) existieren diese 
Befehle noch. Im 64-Bit Modus hingegen nicht mehr.

von Tim  . (cpldcpu)


Lesenswert?

Schwachsinnsdiskussion. Vor allem wird wieder übersehen, dass ein 
Großteil der Controller-Cores gar nicht in stand-alone MCUs verbaut 
wird.

Mich interessiert nur RISC V.

von (prx) A. K. (prx)


Lesenswert?

Tim  . schrieb:
> Schwachsinnsdiskussion. Vor allem wird wieder übersehen, dass ein
> Großteil der Controller-Cores gar nicht in stand-alone MCUs verbaut
> wird.

Die ARM, MIPS und POWER(PC) Architekturen finden sich in beiden Welten.

von Tim  . (cpldcpu)


Lesenswert?

A. K. schrieb:
> Die ARM, MIPS und POWER(PC) Architekturen finden sich in beiden Welten.

Aber dafür gibt es im SOC-Bereic Tensilica, Andes, ARC usw. All diese 
wurden schon in Mrd-Stückzahlen eingesetzt... und 8051.

: Bearbeitet durch User
von Ludwig (Gast)


Lesenswert?

Tim  . schrieb:

> Mich interessiert nur RISC V.

Kannst du kurz schildern, welche Vorteile diese Architektur hat im 
Gegensatz zum Mainstream? Was gibt es an interessanter RISC V Hardware 
zu kaufen?

von Tim  . (cpldcpu)


Lesenswert?

Ludwig schrieb:
> welche Vorteile diese Architektur hat im
> Gegensatz zum Mainstream?

Keine Lizenzgebühren, große Unterstützerbasis, skaliert besser als ARM, 
in einigen Beispielimplementationen energieeffizienter.

> Was gibt es an interessanter RISC V Hardware
> zu kaufen?

Bisher gibt es keine standalone MCUs auf dem Markt, dafür aber einige 
embedded implementationen. Es gibt bereits eine Menge softcores.

https://riscv.org/
http://www.lowrisc.org/

von Ludwig (Gast)


Lesenswert?

Tim  . schrieb:
> Ludwig schrieb:
>> welche Vorteile diese Architektur hat im
>> Gegensatz zum Mainstream?
>
> Keine Lizenzgebühren, große Unterstützerbasis, skaliert besser als ARM,
> in einigen Beispielimplementationen energieeffizienter.
>
>> Was gibt es an interessanter RISC V Hardware
>> zu kaufen?
>
> Bisher gibt es keine standalone MCUs auf dem Markt, dafür aber einige
> embedded implementationen. Es gibt bereits eine Menge softcores.
>
> https://riscv.org/
> http://www.lowrisc.org/

Vielen Dank für deine Antwort.

von Paul R. (atmega9)


Lesenswert?

Conte schrieb:
> Das ganze kleinbitige uC Zeugsel verschwindet alles!
> Genauso wie die DIL Bausteine und die bedrahteten
> Widerstände!

Da muss ich Moby AVR (moby-project) absolut recht geben. Wirklich 
eingestellt werden bedrahtete Bauteile sicher nicht in (ich versuche 
mal eine vorsichtige Schätzung) den nächsten 50 Jahren. Steinigt mich, 
falls ich falsch liege. Zwar werden heute nahezu ausschließlich SMDs in 
Consumer-Elektronik verbaut, trotzdem werden DIPs und andere Bedrahtete 
noch hergestellt.

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

Natürlich gibt's noch lange 8 Bitter. Die werden von 32 Bit genau so 
wenig verdrängt, wie der Radio die Zeitung, die E-Mail den Brief, das TV 
das Kino oder das Internet alles zusammen verdrängt hat. Es wird halt 
mal alles etwas durchgefegt, aufgeräumt, es gibt Veränderungen aber am 
Ende bleibt es wohl noch lange nebeneinander bestehen.

von Paul R. (atmega9)


Lesenswert?

Als Beispiel fällt mir da noch DAB ein...

von Operator S. (smkr)


Lesenswert?

Tim  . schrieb:
> Bisher gibt es keine standalone MCUs auf dem Markt, dafür aber einige
> embedded implementationen. Es gibt bereits eine Menge softcores.
>
> https://riscv.org/
> http://www.lowrisc.org/

Ich mag ja deinen Enthusiasmus für diese Architektur verstehen, nur zu 
sagen:

Tim  . schrieb:
> Mich interessiert nur RISC V.

scheint doch einen sehr eingeschränkten Horizont zu offenbahren.
Selbst wenn wir uns nur auf den Softcore Bereich beschränken, so sind da 
andere Cores in der Vorreiterrolle.

Selbst der preissensible Consumermarkt setzt auf Cortex-A cores, trotz 
Lizenzgebühren.

Die Geschichte hat uns leider gelehrt, dass es nicht auf die 
technische Überlegenheit für eine Verbreitung und Akzeptanz der 
Technologie ankommt.

von (prx) A. K. (prx)


Lesenswert?

Zur µC-Infrastruktur gehört mehr als nur die Architektur, oder auch ein 
für die dafür gängigsten Herstellungsprozesse gebauter Core, der sie 
implementiert. Neben den I/O-Modulen, die oft vom Hersteller des µC 
gebaut werden, kommen noch andere generischere Module dazu, wie etwa 
Interrupt-Controller, Debug-Interface mit/ohne Trace-Möglichkeit und 
interne Busse.

Als Luminary Micro (m.W. als erster) die Cortex M Familie nutzte, 
konnten sie auf einen Baukasten von ARM zurückgreifen, in denen die 
viele Module schon fertig vorhanden waren. Die ersten LM3 waren in 
weiten Teilen aus Fertigmodulen von ARM zusammengesetzt. Das führt nicht 
unbedingt zum bestmöglichen Design, erleichtert die Entwicklung aber 
erheblich und reduziert den Umfang der Vorfinanzierung in der 
Entwicklung.

Lizenzgebühren können daher auch Kosten gegenüber Eigenentwicklung 
einsparen. Auch weil Fähigkeiten und Bugs der eingekauften Produkte 
bekannt sind. Eigenentwicklungen komplexer Produkte führen erst einmal 
zu eigenen Bugs, mit denen oft nicht nur die Entwickler der µCs selbst 
zu kämpfen haben, sondern auch die Anwender.

: Bearbeitet durch User
von H-G S. (haenschen)


Lesenswert?

Paul R. schrieb:
> H-G S. schrieb:
>> Fast habe ich Angst da ich ja im Moment etwas PC-unabhängiges bastle,
>> hoffentlich kriege ich da keine Repressalien  :-)
>
> Pass auf, dass du keinen NSL kriegst... :D


Kurz nachdem ich den Text postete brach die Internetverbindung meines PC 
ab :-)


BTT: es scheint dass der Adressraum eines 8-Bitters etwas knapp ist.

: Bearbeitet durch User
von Axel S. (a-za-z0-9)


Lesenswert?

H-G S. schrieb:
> BTT: es scheint dass der Adressraum eines 8-Bitters etwas knapp ist.

Wie groß ist "der" Adreßraum eines 8-Bitters denn deiner Meinung nach?

Das war eine Fangfrage, es gibt gar nicht "den" Adreßraum. Bloß weil 
viele 8-Bitter einen 16-Bit Adreßraum haben, ist das nicht 
notwendigerweise bei allen so. ATmegas gibt es z.B. auch mit 128KB Flash 
(ganz abgesehen davon, daß sie als Harvard-Architektur sowieso gleich 
mehrere Adreßräume haben). STM8 hat einen unified Adreßraum mit 24-Bit 
Adressen. etc. pp.

von Stefan K. (stefan64)


Lesenswert?

Die Größe des Adressraums finde ich auch die viel entscheidendere Frage. 
Ob Daten 8 oder 32 Bit breit manipuliert werden, ist letztlich die 
Aufgabe des Compilers und tangiert den Programmierer eher wenig.

Sobald der benötigte Adressraum aber überschritten wird, wird es sowohl 
für Chipdesigner als auch für Programmierer unangenehm (far-Pointer, 
A20-Gates, etc).

Beim AVR kommt noch die Unterscheidung zwischen Flash und RAM hinzu, was 
der Havard-Architektur geschuldet ist. Auch beim 8051 ist es ganz 
selbstverständlich, daß komplett unterschiedliche Befehle benutzt werden 
müssen, je nachdem, in welchem Daten- oder Flashbereich die Daten 
stehen.

Der bei 32Bit-Controllern übliche (68000, ARM) lineare Adressraum hat 
alle damit auftretenden Probleme nicht. Insgesamt ist daher eine 
32Bit-CPU einfacher zu handhaben, und das betrifft sowohl Chipdesigner, 
Compilerbauer als auch Programmierer. Ich rede hier ausschliesslich von 
der CPU, natürlich ist ein CORTEX-M komplexer und schwieriger zu 
handhaben als ein AVR. Dies liegt aber nicht an der CPU, sondern an der 
wesentlich komplexeren Peripherie, die dafür auch deutlich mehr 
Möglichkeiten bietet.

Natürlich sterben AVR etc. nicht so schnell aus. Schon allein wegen den 
unzähligen Produktlinien, in denen diese Controller eingesetzt werden. 
Einen Vorteil in der Produktion oder im Preis haben sie aber nicht mehr, 
selbst bei kleineren Controllern verschwindet die Die-Fläche des Cores 
gegenüber der von RAM und Flash.

Viele Grüße, Stefan

von (prx) A. K. (prx)


Lesenswert?

Stefan K. schrieb:
> selbst bei kleineren Controllern verschwindet die Die-Fläche des Cores
> gegenüber der von RAM und Flash.

http://flylogic.net/chippics/atmega88/atmega88c_lrg.jpg

von Amateur (Gast)


Lesenswert?

Der Friedhof, auf dem die beerdigten 8-Bit Prozessoren liegen, wurde 
bereits vor Jahren - wegen Überfüllung - geschlossen.

Natürlich kannst Du Dich, im morgendlichen Berufsverkehr, auch mit einem 
Formel-1-Renner bewegen. Würde mich aber nicht wundern, wenn der olle 
Käfer, der vorhin noch hinter Dir war, plötzlich vor Dir steht.

Genau, wie der alte Käfer, für den Berufsverkehr besser geeignet ist, 
als irgendein Bolide, so gibt es auch so etwas wie einen "angepassten 
Prozessor" für die/Deine Entwicklung.

Hast Du riesige Mengen an Daten zu bewältigen, brauchst Du eine 
Reaktionszeit im Pikosekunden Bereich, arbeitest Du ausschließlich mit 
großen Zahlen, so gilt: 16 Bit sind schneller und 32 Bit eventuell noch 
besser.

Wie kommt es aber, dass die überwiegende Anzahl an Prozessoren 8 Bit 
haben – ist bis auf weiteres immer noch so. Nur Idioten sind es nicht; 
die bestehenden Bibliotheken lassen das Beibehalten des schmaleren 
Busses auch nicht übermäßig plausibel erscheinen. Selbst das: "Das haben 
wir immer schon so gemacht", zieht nicht immer. Höchstens das: "Wir 
haben alle Tools und auch die zugehörige Hardware im Haus", sowie "alle 
kennen sich damit aus", kann sich noch Lebensverlängernd auswirken.

Die Antwort ist so einfach, dass es fast lachhaft ist: Die 8-Bitter 
reichen aus. Meist sind sie auch preiswerter. Übrigens: Oft bedeutet 2 
mal 8 tatsächlich 16, will sagen, dass Dein eingebauter Speicher, 
plötzlich nur noch halb so groß - in Werten - ist. Viele 16- bzw. 
32-Bitter müssen für den Zugriff auf 8-Bit Daten sogar Zwischenschritte 
machen. Auch der Programmspeicher - gerechnet in Programmschritten - 
wird plötzlich kleiner.

Also ich bin nicht gegen "größere" Rechner, sondern für passende.

von H-G S. (haenschen)


Lesenswert?

Mich stört im Moment eher dieses gepipelinete CPU-Design.

Wenn man ein zeitkritisches Problem lösen muss und nicht weiss wie genau 
die Pipeline reagiert oder man auf ungenaue Interrupt-Abarbeitung 
zurückgreifen muss.

von Stefan K. (stefan64)


Lesenswert?

Amateur schrieb:
> Die Antwort ist so einfach, dass es fast lachhaft ist: Die 8-Bitter
> reichen aus. Meist sind sie auch preiswerter.

Das ist eben leider nicht mehr so.

STM32F070F6P6:       32kb Flash, 1000 Stück bei Mouser: 0,67€
556-ATMEGA328PB-MU:  32kb Flash, 1000 Stück bei Mouser: 1,22€

Und der Grund ist ganz einfach: der Atmega ist in tausenden Projekten 
verbaut. Aus Preisgründen wird man sich für ihn für neue Produkte eh 
nicht mehr entscheiden. Also werden jetzt die laufenden Produkte 
gemolken. Der Preiskrieg findet eher bei den aktuellen 
Mcrocontroller-Produkten statt, und das sind immer mehr die 32-Bitter.

Ich behaupte nicht, das es nicht genügend Gründe gibt, bei den bisher 
verwendeten 8-Bittern zu bleiben. Ein Umstieg kostet immer erstmal Geld. 
Wird aber - z.B. weil in einem größeren Projekt die Leistung gebraucht 
wird - auf einen 32-Bitter umgestellt, dann zählt eben die alte 
8-Bit-Erfahrung nicht mehr und auch folgende Kleinprojekte werden dann 
mehr in 32Bit ausgeführt.

Viele Grüße, Stefan

von Lurchi (Gast)


Lesenswert?

Die 8 Bit µC mit viel Speicher (so ab 16 Kbytes aufwärts) sind auch 
tatsächlich relativ teuer, weil bei den groben Strukturen der Speicher 
einiges an Fläche benötigt. Da wird dann bei viel Speicher der 32 Bit µC 
tatsächlich günstiger.

Viele Anwendungen für 8 Bit µC kommen aber mit wenig Speicher (z.B. 4 K) 
aus.

von avr (Gast)


Lesenswert?

Stefan K. schrieb:
> Das ist eben leider nicht mehr so.

Oh doch, das ist genau so. Nur weil du ein schlechtest Beispiel wählst, 
wird die Aussage nicht wahr.

STM8S005K6T6CTR aus dem gleichen Haus schlägt den 32-bitter. Tatsächlich 
geht die STM8-Serie bis unter 20cent/Stück. EFM8 geht in die ähnliche 
Richtung, teilweise mit recht interessanter Peripherie. Oder finde mal 
einen 32-Bit USB-µC, der preislich nur ansatzweise an die EFM8UB-Serie 
herankommt.

Abgesehen davon sind 1000 Stück keine große Stückzahl. Da machen 
50cent/µC Mehrkosten nicht viel aus. Interessant wird es Richtung 
6-stelligem Bereich.

von Lothar (Gast)


Lesenswert?

Stefan K. schrieb:
> STM32F070F6P6:       32kb Flash, 1000 Stück bei Mouser: 0,67€
> 556-ATMEGA328PB-MU:  32kb Flash, 1000 Stück bei Mouser: 1,22€

  EFM8BB31F32G:        32kb Flash, 1000 Stück bei Mouser: 0,76€

Dieser 8051 mit 50 MHz hat aber nicht nur 13x 12-Bit ADC mit DMA sondern 
auch 2x 12-Bit DAC

von mse2 (Gast)


Lesenswert?

Paul R. schrieb:
> Ist das Aussterben von 8 bit MCUs und speziell den
> AVRs nur ein Wunsch der Hersteller oder werden diese wohl so bald nicht
> verschwinden?
Ich war vor ein paar Wochen bei einem von einem Distrubutor 
veranstalteten Seminar, bei dem auch Vertreter von Microchip und Atmel 
vertreten waren. Beide beteuerten, dass sie durchaus noch eine längere 
Zukunft für ihre 8-Bit-Typen sähen. U.a. ist bietet das IoT einen großen 
Wachstumsmarkt mit den Anforderungen kurzes Time-To-Market, billig, 
klein, stromsparend, wobei sehr oft keine große Rechenleistung gefordert 
ist. Hier können die 8-Bitter noch sehr lange punkten.

von Lothar (Gast)


Lesenswert?

mse2 schrieb:
> bietet das IoT einen großen Wachstumsmarkt mit den Anforderungen
> kurzes Time-To-Market, billig

Solange Microchip die AVR Preise nicht Richtung PIC senkt wird AVR hier 
nichts reissen. Zumal 8051 hier noch vor PIC ganz weit vorn ist.

von Stefan K. (stefan64)


Lesenswert?

avr schrieb:
> STM8S005K6T6CTR aus dem gleichen Haus schlägt den 32-bitter. Tatsächlich
> geht die STM8-Serie bis unter 20cent/Stück.

Beim gleichen Distri unter denselben Bedingungen verglichen:

STM8S005K6T6CTR:         32kb Flash, 1000 Stück bei Mouser: 0,68€

EFM8BB31F32G-A-QFN32:    32kb Flash, 980 Stück bei Mouser: 0,71@

Sprich:
Aktuelle Microcontroller liegen in ähnlichen Preisregionen, ob ein 8- 
oder 32-Bit-Core verbaut ist, spielt keine große Rolle mehr.

Stückzahlen im 6-stelligem Bereich haben wir bei uns nicht laufen.

Viele Grüße, Stefan

von avr (Gast)


Lesenswert?

Stefan K. schrieb:
> Aktuelle Microcontroller liegen in ähnlichen Preisregionen, ob ein 8-
> oder 32-Bit-Core verbaut ist, spielt keine große Rolle mehr.

Ich hab einen Controller mit gleich viel Flash herausgesucht. Deswegen 
kannst du doch nicht gleich eine Behauptung für alle Controller 
aufstellen.

STM8S003F3U6TR      8KB 0,353€
EFM8BB10F2G-A-QFN20 2KB 0,281€

Wenn ihr natürlich nur 1000 Stück verbaut, ist das natürlich egal. Das 
sind keine großen Stückzahlen.

von Tim  . (cpldcpu)


Lesenswert?

> Lizenzgebühren können daher auch Kosten gegenüber Eigenentwicklung
> einsparen. Auch weil Fähigkeiten und Bugs der eingekauften Produkte
> bekannt sind. Eigenentwicklungen komplexer Produkte führen erst einmal
> zu eigenen Bugs, mit denen oft nicht nur die Entwickler der µCs selbst
> zu kämpfen haben, sondern auch die Anwender.

Wenn Du einen SOC in >10 mio Stückzahlen herstellst, sind 0.05 USD 
Lizenzgebühren relevant. Dafür kann man einen Ingenieur bezahlen, der 
sich in einen neuen Core einarbeitet. In solchen Bereichen macht ARM 
keine Freude. Deswegen findet man dort auch Dinge wie Andes Core, ARC, 
OpenMSP430 und demnächst wohl auch häufiger eine RISC V Implementierung.

Das oben genannte Peripherieproblem spielt hier kaum keine Rolle, da 
sowieso auf standardisierte Busse zurückgegriffen wird.

Bis RISC V für MCUs relevant wird, wird es aber wohl noch etwas dauern. 
Ich setzte da auf die ganzen Fabless-Startups in China, die in den 
Startlöchern stehen. Irgendwie müssen die neuen Fabs ja gefüllt 
werden...

: Bearbeitet durch User
von Stefan K. (stefan64)


Lesenswert?

avr schrieb:
> Ich hab einen Controller mit gleich viel Flash herausgesucht. Deswegen
> kannst du doch nicht gleich eine Behauptung für alle Controller
> aufstellen.

Ich habe Controller mit gleicher Flash-Größe (32kb) bei denselben 
Stückzahlen (1000 Stück) verglichen, und da sind die Preise nahezu 
identisch, egal welcher Core vebaut ist.
Natürlich kann es sein, dass sich die Preise bei hohen Stückzahlen etwas 
verschieben, wobei ich mir nicht vorstellen kann, daß z.B. ST bei seiner 
STM8-Serie einen wesentlich anderen Stückzahlen-Rabatt als bei seiner 
STM32-Serie vergibt.

Viele Grüße, Stefan

von Carl D. (jcw2)


Lesenswert?

Le X. schrieb:
> A. K. schrieb:
>> In x86-64 sind die AAx/DAx Befehle übrigens rausgeflogen, und x87 mit
>> seinem BCD-Format ebenfalls. Das sind zwar keine µCs, suggeriert aber
>> ebenfalls, dass die Zukunft von BCD in der Vergangenheit liegt.
>
> War ein Ziel dieser Architektur nicht immer abwärtskompatibel zu
> bleiben?
> D.h. ein aktueller x86-64 wäre nicht in der Lage ein 15 Jahre altes
> Programm auszuführen in dem diese Befehle verwendet werden?
>
> Oder emuliert die CPU dann in Eigenregie diese Befehle?

So wie ein ARM auch Thumb spricht, kann auch ein x86 mehrere 
Befehlssätze ausführen.
BCD gibt es natürlich auch in der x64-Welt, nur nicht Byteweise und auch 
nur per Software, aber viel schneller als die 8080 Relikte.

Bei der Frage, welche Architektur, kann manchmal die Einheitlichkeit 
entscheidend sein. Wenn die Motorsteuerung mit 32bit ARM läuft, dann 
wird man für den LIN-Knoten in der Tür vielleicht lieber ARM als PIC 
nehmen, es sei denn diese sind auf Grund der Menge um viele 
Programmierer-Tagessätze teurer. Ein entsprechender Bonusplan im Einkauf 
kann aber auch entscheidend sein.

von Lothar (Gast)


Lesenswert?

Gerhard O. schrieb im Beitrag #4648736:
> Jedenfalls finde ich es immer etwas spassig wenn beim uC so mit die
> Cents geknausert wird und der Rest des Gerätes noch um ein Vielfaches
> minderwertiger ist

Anders als bei Mechanik, Elektrik und Design wo besser tatsächlich mehr 
kostet, muss das in der Elektronik nicht so sein. Ein robuster uC kann, 
wenn in Stückzahlen nachgefragt, günstig sein, und ein schlecht 
designter uC kann teuer sein. Bei einem hochwertigen Gerät sollte das 
dann während der Entwicklung bemerkt werden.

von Gerhard O. (gerhard_)


Lesenswert?

Lothar schrieb:
> Gerhard O. schrieb im Beitrag #4648736:
>> Jedenfalls finde ich es immer etwas spassig wenn beim uC so mit die
>> Cents geknausert wird und der Rest des Gerätes noch um ein Vielfaches
>> minderwertiger ist
>
> Anders als bei Mechanik, Elektrik und Design wo besser tatsächlich mehr
> kostet, muss das in der Elektronik nicht so sein. Ein robuster uC kann,
> wenn in Stückzahlen nachgefragt, günstig sein, und ein schlecht
> designter uC kann teuer sein. Bei einem hochwertigen Gerät sollte das
> dann während der Entwicklung bemerkt werden.

Tut mir leid, Lothar, ich löschte meinen Beitrag wieder weil es mir 
irgendwie im Nachhinein als unpassend erschien.

Grüße,
Gerhard

von Gerhard O. (gerhard_)


Lesenswert?

Lothar schrieb:
> Gerhard O. schrieb im Beitrag #4648736:
>> Jedenfalls finde ich es immer etwas spassig wenn beim uC so mit die
>> Cents geknausert wird und der Rest des Gerätes noch um ein Vielfaches
>> minderwertiger ist
>
> Anders als bei Mechanik, Elektrik und Design wo besser tatsächlich mehr
> kostet, muss das in der Elektronik nicht so sein. Ein robuster uC kann,
> wenn in Stückzahlen nachgefragt, günstig sein, und ein schlecht
> designter uC kann teuer sein. Bei einem hochwertigen Gerät sollte das
> dann während der Entwicklung bemerkt werden.

Das sehe ich genau so.

von stefan (Gast)


Lesenswert?

Stefan K. schrieb:
> Das ist eben leider nicht mehr so.
>
> STM32F070F6P6:       32kb Flash, 1000 Stück bei Mouser: 0,67€
> 556-ATMEGA328PB-MU:  32kb Flash, 1000 Stück bei Mouser: 1,22€

Ich finde der Vergleich hinkt. ST pflegt seine Controller kaum, und je 
“billiger“ dann geht die Pflege auf 0. Schonmal die Errata Liste des 
erwähnten stm8s003 gesehen? Ja ist billig aber mit sehr vielen 
Einschränkungen. Ein Tapeout mit neuer Revision kann einige hundert k$ 
Kosten und das rentiert sich bei billig nicht. Wie lange ist stm8s auf 
dem Markt und wann wurden die teilweise kritische Errata gefixt? Das 
zeigt dass es St Qualität egal ist, hauptsache die Kunden fallen auf den 
niedrigen Preis rein.

von Carsten S. (dg3ycs)


Lesenswert?

Stefan K. schrieb:
> Ich habe Controller mit gleicher Flash-Größe (32kb) bei denselben
> Stückzahlen (1000 Stück) verglichen, und da sind die Preise nahezu
> identisch, egal welcher Core vebaut ist.

ISt durchaus richtig...
Dennoch hast du dabei einen Denkfehler!

Die Domäne der 8 Bitter wird in der Zukunft vor allem bei den einfachen 
Anwendungen liegen. Anwendungen wo man mit einigen hundert bis zu 
wenigen tausend kByte an Speicher auskommt.

Anwendungen wo die 2kByte Progammspeicher und 256 Byte RAM des weiter 
oben genannten EFM8BB10F2G mehr als genug sind.

Wenn aber klar ist, das ich z.B. 1,5 kByte Flash und 180Byte Ram für 
mein High Volume Produkt benötige, dann Interessiert mich einzig der 
Preis den ich für die Bausteine bezahle die diese Anforderungen 
erfüllen.

Bei den CortexM0 waren jetzt 4kByte Flash und 1kByte RAM das kleinste 
was ich auf die Schnelle gefunden habe. Mag sein das es kleinere gibt, 
ist aber dann WEIT abseits des Mainstream - und auch des Bereiches in 
dem die echten Kampfpreise gemacht werden. (Die sind ja manchmal sogar 
nur für ganz ausgewählte Typen eines HErstellers so niedrig... Ist aber 
von Hersteller zu Hersteller unterschiedlich )

Dafür zahle ich rund 40ct.

Bei den 8 Bittern bekomme ich aber problemlos Typen mit nur wenigen 
hundert kByte Flash und sogar unter 100Byte RAM wenn ich möchte.
Oder halt den genannten EFM8 mit 2kByte/256Byte für ~20ct.

Klar, der M0 kann mehr im direkten Vergleich. Aber ich kann mit dem 
"mehr" in diesem Fall nichts Anfangen. Mich interessiert nur was ich 
brauche.

(Wobei man wenn man es genau betrachten wollte auch die Speichergrößen 
nicht direkt vergleichen dürfte. Wenn man schon die Preise anhand der 
Leistngsmerkmale vergleichen will, dann muss man für einfache 
Anwendungen bei den 32Bittern welche nehmen deren RAM 4x so groß ist wie 
der von 8 Bittern. Denn bei einfachen Projekten hat man es in der 
absoluten Überzahl der Fälle mit 8Bit Werten zu tun. Die Zahl an 
"breiteren" variablen hält sich bei solchen Projekten meist in sehr 
übeschaubaren Grenzen.
Auf einem 32Bitter bedeutet das aber das man entweder Klimmzüge machen 
muss um mehrere Variablen in eine Speicherzelle zu quetschen oder aber 
das man pro Variable 3 Byte einfach ungenutzt verschenkt...
Aber wie gesagt, das ist eh irrelevant da man wie schon geschrieben ja 
beim driekten Vergleich eh einer Milchmädchenrechnung auf dem Leim geht)

Daher ist der Vergleich anahnd identischer Leistungsmerkmale absolut 
witzlos. Das ist "Bastlerdenke" wo man sich erst den tollsten Controller 
aussucht und dann die Projekte die man damit macht...

Man muss den Vergleich von der Seite der Projekte aufziehen. Also nach 
der Art: Das möche ich machen, welche Leistungsmerkmale brauche ich...

Und da liegen für viele einfache bis mittlere Anforderungen die 8Bitter 
immer noch sehr weit vorn.
Wenn es dann aber komplexer wird, dann kehrt sich das hingegen sehr 
schnell um. Da ziehen die 32Bitter dann schnell vorbei!
Zumindest so lange man nicht auf Spezialperiepherie angewiesen ist

Wenn denn Spezialperipherie in Spiel kommt, da liegen die 8 Bitter zur 
Zeit definitiv noch weit vorn. (Wobei das keine Frage der Technologie 
sondern der Produktstrategie die HErsteller ist)
Die gängigen 32Bitter haben üblicherweise Standardperipherie bis zum 
Abwinken. Timer, AD Kanäle usw. bis zum Abwinken. Was der Baukasten 
hergibt!

Aber wird es etwas spezieller und es geht um Periperie die im schönen 
ARM/MIPS usw. IP Baukasten nicht mehr Berücksichtigt ist, dann wird es 
eng.
Wobei man in der 8Bit Welt die tollste Auswahl hat.
Aber wie gesagt, das ist keine Frage der Technologie sondern einfach von 
den Strategen so vorgesehen. Es zeigt aber sicher auch in welchen 
Einsatzbereichen die Hersteller die Zukunft für das jeweilige Produkt 
sehen.
Bei den 8Bittern halt im absoluten LowEnd bereich UND aber im Bereich 
der Datenerfassung (Sensorik) mit wenig Rechenbedarf, aber viel 
Spezialtechnik.
Bei den 32Bittern im Bereich der Datenverarbeitung und komplexer 
Steuerung...

Gruß
Carsten

: Bearbeitet durch User
von Uwe Bonnes (Gast)


Lesenswert?

Carsten S. schrieb:
> Auf einem 32Bitter bedeutet das aber das man entweder Klimmzüge machen
> muss um mehrere Variablen in eine Speicherzelle zu quetschen oder aber
> das man pro Variable 3 Byte einfach ungenutzt verschenkt...

Auf welcher Architectur hats Du den gearbeitet.

Arm Cortex kann Byte-Zugriffe...

von Michael S. (rbs_phoenix)


Lesenswert?

Ich denke auch, dass es noch recht lange 8bitter geben wird. Und wenn es 
der blöde PIC16F84A ist ;)
Vorallem interessieren sich die Hersteller auch "nur" für die Zahlen bzw 
Umsätze. Und da spielen die "paar" abgenommenen µCs von Hobbyisten keine 
große Rolle. Die Hersteller bringen aber immernoch neue 8bitter raus, 
zumindest Microchip und ST (werden aber sicherlich nicht die einzigen 
sein). Wieso sollten sie das machen, wenn es keine Abnehmer gibt? Wenn 
ich mich richtig erinnere, baut AUDI in die Scheinwerfer 8bit- oder 
16bit-PICs ein.

Ich gucke bei jedem Projekt neu, welchen µC ich nehme. Da ich bisher 
alles mit PICs gemacht habe, kenne ich nur diese Seite. Doch ich denke, 
dass es bei ARMs nicht anders aussieht. Ich finde nämlich schon, dass 
die 32bitter umständlicher (wenn es natürlich auch nicht unmöglich ist) 
zu handhaben sind. Gefühlt 100 Taktquellen, die Config-Register für 
Timer, SPI, PWM, ADC usw sind um ein vielfaches mehr.. Da braucht man ja 
schon nen kByte Flash nur fürs Initialisieren der Module und bis die CPU 
so läuft, wie sie soll. Das ist bei nem 8bitter m.M.n. deutlich 
einfacher, schneller programmiert und platzsparender.

Das Argument, dass es ein 32bitter genausogut kann und preislich kaum 
ein Unterschied ist, mag stimmen. Trotzdem bin ich kein Fan von dieser 
Ressourcenverschwendung. Ist wohl eine Einstellungssache. Ich denke, 
dass diese "Hauptsache schnell was neues, kack egal, ob es effizient 
oder sauber ist, es geht ja"-Einstellung fast gefährlich ist. Das ist 
aber nicht nur in der Elektronik so, sondern auch bei Filmen oder 
Spielen. Und auch hier wird nur das verkauft, was von der Mehrheit 
verlangt wird. Mir geht das irgendwie auf die Nerven. Es ist schon 
soweit, dass die Blitz-LED-Anschalt-App fürs Android-Phone 5MB groß ist, 
was vmtl nur das Setzen eines Bits ist. Aber hey... Es geht ja auch so 
und der Speicher ist ja groß genug. So kann man den Fortschritt auch 
voran treiben. Irgendwann sind in den Handys ultrakleine, stromsparende 
Terabyte-Speicher verbaut, auf dem die 4GByte-Facebook-App installiert 
ist, die einfach nur Kommentare und Bilder anzeigen kann. Zusammen mit 
dem 2GByte Messenger, der.... Nachrichten verschicken und empfangen 
kann. Aber der Platz ist ja da und der Hexadeci-1.8GHz-Core kann 
gleichzeitig die unscharfen 30Megapixel Selfies über das 8G-Netz 
jagen...

Mich würde mal interessieren, wie sehr man die heutige Hardware 
ausreizen kann. Vermutlich würden einige das hinkriegen, wo die meisten 
nach deutlich mehr Power schreien.

Ich jedenfalls schaue zuerst, was der µC für mein Projekt können und 
haben muss, gebe diese Sachen dann bei der Microchip-µC-Suche an und 
gucke die Liste durch, die ich erstmal nach Preis sortiere. Wobei ich 
zuerst die 32bitter ausblende. Und trotzdem finde ich immer einen 
passenden µC.

Meine Meinung ;)

: Bearbeitet durch User
von Chris F. (chfreund) Benutzerseite


Lesenswert?

Paul R. schrieb:
> 6a66 schrieb:
>> werden sich auf lange Sicht sicher durchsetzten.
> Will sagen die Zeit ist die nächsten Jahre noch nicht reif?

Wenn ein Hersteller hunderttausend Stück von einem Massengerät 
herstellen soll und für die Anwendung ein 4Bit-MC mit 512 Anweisungen 
reicht, dann wird das Teil auch verbaut. Deswegen hat so eine 
Kaffeepadmaschine auch ein Kondensatornetzteil für die Speisung der 
Elektronik und den einfachstmöglichen MC.

Bei manchen Sachen braucht man einfach nicht mehr. Vielleicht gibt es in 
100 Jahren nur noch irgendeinen einzigen allpurpose-MC der alles kann, 
kaum Leistung braucht und den man überall draufdrucken kann und man 
stellt einfach nur noch dieses Ding her weil es das günstigste ist und 
für alles nutzbar.

Bis dahin werden passende Bauteile für die Anwendung auf Grund von 
wirtschaftlichen Erwägungen gewählt und je weniger Chipfläche desto 
günstiger sind die Chips herstellbar. Mit fortschreitender Technik wird 
versucht die Dinger noch günstiger zu machen und nicht noch komplexer.

: Bearbeitet durch User
von Clemens L. (c_l)


Lesenswert?

Paul R. schrieb:
> Ist das Aussterben von 8 bit MCUs [...] nur ein Wunsch der Hersteller
> oder werden diese wohl so bald nicht verschwinden?

Es ist durchaus möglich -- Texas Instruments hat praktisch keine 
8-Bitter mehr, und fährt mit den MSP430s gar nicht mal so schlecht. (Ein 
MSP430G2001 z.B. hätte anderswo einen 8-Bit-Kern.)

16 Bits sind aber auch nicht 32 Bits, und die anderen Hersteller sind 
nicht kollektiv dem Wahnsinn verfallen, wenn sie trotzdem noch 8-Bitter 
herstellen.

von Heiner (Gast)


Lesenswert?

weil oben die Frage kam, ob es neue, weiterentwickelte 8 Bitter gibt:
z.B. Microchip hat die neueren 8 Bit PIC's mit CLC's (configurable logic 
cell) ausgestattet + ECC Flash.

lg Heiner

von Lothar (Gast)


Lesenswert?

Michael S. schrieb:
> Ich gucke bei jedem Projekt neu, welchen µC ich nehme. Da ich bisher
> alles mit PICs gemacht habe, kenne ich nur diese Seite

Microchip setzt doch grade auf PIC32 in ganz kleinen Packages als 
Drop-in ab PIC10 und teilweise sogar billiger:

http://www.microchip.com/promo/pic32mm

> Ich jedenfalls schaue zuerst, was der µC für mein Projekt können und
> haben muss

Soweit die Theorie. In der Praxis gibt es schon eine Toolchain, in der 
Industrie fast immer 8051 und ARM und da wird dann zuerst gesucht.

von Thomas E. (picalic)


Lesenswert?

Lothar schrieb:
> Microchip setzt doch grade auf PIC32 in ganz kleinen Packages als
> Drop-in ab PIC10 und teilweise sogar billiger:

Wie soll denn so ein sauteurer (ca. das doppelte eines PIC10F200) und 
stromfressender (0,5 mA bei 1MHz!) Bolide mit extrem vielen Pins (min. 
20) einen 10F200 im 6-Pin SOT23-Gehäuse, der in einem Akku-betriebenen 
System (VCC = 3,0 .. 4,2V!) eingesetzt wird, sinnvoll ersetzen?

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Michael S. schrieb:
> Da braucht man ja
> schon nen kByte Flash nur fürs Initialisieren der Module und bis die CPU
> so läuft, wie sie soll. Das ist bei nem 8bitter m.M.n. deutlich
> einfacher, schneller programmiert und platzsparender.

Das ist nur die halbe Wahrheit. Die üblichen 8 Bitter benötigen deutlich 
weniger an Feinheit bei den Strukturen als 32 Bitter - logo, wo hier nur 
8 Datenleitungen quer über den Chip gezogen werden müssen, sind es dort 
eben 32. Das ist so ähnlich wie Leiterplatte routen. Man kommt also mit 
gröberen Strukturen aus und das ist regelmäßig ein deutlicher Vorteil in 
der langfristigen Zuverlässigkeit des Chips. Auch unter Streßbedingungen 
wie Temperatur und kosmische Strahlung. Aber ebenso bei der 
Nutzungsdauer - wie lange bleiben die Ladungen auf einem floating gate 
erhalten? Mal so im Vergleich zum maskenprogrammierten Chip?

Kurzum, eine simpler gestrickter 8 Bitter mit deutlich gröberen 
Strukturen auf dem Stein ist per se zuverlässiger als ein 32 Bitter, der 
notwendigerweise mit feineren Strukturen und kleineren Ladungen auf dem 
Flash-Speicher daherkommen muss als ersterer.



m.n. schrieb:
> Sieh Dir mal die Xmega an!

langsam bitte...
Thema war DMA.
Ich frag dich mal, wozu man ne DMA tatsächlich braucht. Bei dedizierten 
Peripherie-Cores wie z.B. einem TFT-Controller mit DMA-Fähigkeit sieht 
man das sofort ein. Aber ein ganz gewöhnlicher DMA, dessen Fähigkeit 
sich auf das Umschaufeln von  A nach B erschöpft? Wozu sowas? 
Letztendlich sind es immer wieder Daten, die verarbeitet werden sollen 
und das kann nur ne CPU per ausreichend klugem Programm - aber keine 
DMA. Und ob die CPU die Daten von A oer von B holen muß, ist wumpe.

Ich halte den Beitrag, auf den du geantwortet hast, für pure Trollerei.

W.S.

von Stefan (Gast)


Lesenswert?

Heiner schrieb im Beitrag #4650875:
> Thomas E. schrieb:
>> Lothar schrieb:
>>> Microchip setzt doch grade auf PIC32 in ganz kleinen Packages als
>>> Drop-in ab PIC10 und teilweise sogar billiger:
>>
>> Wie soll denn so ein sauteurer (ca. das doppelte eines PIC10F200) und
>> stromfressender (0,5 mA bei 1MHz!) Bolide mit extrem vielen Pins (min.
>> 20) einen 10F200 im 6-Pin SOT23-Gehäuse, der in einem Akku-betriebenen
>> System (VCC = 3,0 .. 4,2V!) eingesetzt wird, sinnvoll ersetzen?
>
> Full Ack, Hauptsache blub, blub.
>
> lg Heiner

Ich finde das Marketing Gebrabbel von Microchip auch unerträglich. Klar, 
solange es um Kaffeemaschinen und LED Leuchten geht sind PICs die erste 
Wahl. Damit haben sie ja auch großen Erfolg.
Doch sobald es ans Eingemachte geht - richtige Anwendungen - bleiben nur 
noch ARM und Renesas. PIC32 interessiert doch niemanden. Das hat 
Microchip ja auch selbst inzwischen erkannt und gerade noch rechtzeitig 
Atmel gekauft. Sonst hätten sie eher früher als später einräumen müssen 
dass der PIC32 gegenüber dem Cortex-M nie eine Chance hatte.

PS: Ich brauche aktuell einen PIC (gerne 8Bit) der >= 5 Touch-Buttons 
abfragen kann und mit einer CR2032 versorgt mind. 1 Jahr lang läuft.

von Gerhard O. (gerhard_)


Lesenswert?


von Michael S. (rbs_phoenix)


Lesenswert?

Lothar schrieb:
>> Ich jedenfalls schaue zuerst, was der µC für mein Projekt können und
>> haben muss
>
> Soweit die Theorie. In der Praxis gibt es schon eine Toolchain, in der
> Industrie fast immer 8051 und ARM und da wird dann zuerst gesucht.

Daher schrieb ich auch, dass ich es so mache. Und da ist es auch in 
der Praxis so, dass ich die IDE und ein Programmer für PICs habe, dazu 
Erfahrung mit PICs. Und solange ich mit den verschiedenen PICs zurecht 
komme und für mich ausreichend Power haben, wechsle ich nicht zu einer 
anderen Familie. Andere Datenblattaufmachung, neue Tools/Hardware und 
IDE, Zeit zum Einarbeiten und nur, damit ich sagen kann, ich habs mit 
einem ARM statt PIC18 gemacht? Ne, da investiere ich lieber die Zeit und 
Geld in wichtiges.

W.S. schrieb:
> Michael S. schrieb:
>> Da braucht man ja
>> schon nen kByte Flash nur fürs Initialisieren der Module und bis die CPU
>> so läuft, wie sie soll. Das ist bei nem 8bitter m.M.n. deutlich
>> einfacher, schneller programmiert und platzsparender.
>
> Das ist nur die halbe Wahrheit. Die üblichen 8 Bitter benötigen deutlich
> weniger an Feinheit bei den Strukturen als 32 Bitter - logo, wo hier nur
> 8 Datenleitungen quer über den Chip gezogen werden müssen, sind es dort
> eben 32. Das ist so ähnlich wie Leiterplatte routen. Man kommt also mit
> gröberen Strukturen aus und das ist regelmäßig ein deutlicher Vorteil in
> der langfristigen Zuverlässigkeit des Chips. Auch unter Streßbedingungen
> wie Temperatur und kosmische Strahlung. Aber ebenso bei der
> Nutzungsdauer - wie lange bleiben die Ladungen auf einem floating gate
> erhalten? Mal so im Vergleich zum maskenprogrammierten Chip?

Was die Struktur im Inneren angeht, da bin ich der falsche Mann für, da 
kenne ich mich nicht gut genug aus. Mir ging es um die Programmierung 
und das Hintergrundwissen. Natürlich, die Module im PIC32 haben deutlich 
mehr Funktionalität und die muss konfigurierbar sein. Doch das ganze 
kram habe ich noch nie gebraucht und dann sind die Module in 8bit PICs 
zwar "schlechter" oder eher "simpler", gehen einem aber dadurch auch 
schneller von der Hand. Mir zumindest.


Stefan schrieb:
> Ich finde das Marketing Gebrabbel von Microchip auch unerträglich. Klar,
> solange es um Kaffeemaschinen und LED Leuchten geht sind PICs die erste
> Wahl. Damit haben sie ja auch großen Erfolg.
> Doch sobald es ans Eingemachte geht - richtige Anwendungen - bleiben nur
> noch ARM und Renesas.

Definiere richtige Anwendungen.. Wenn ich mich in meiner Wohnung 
umgucke, sehe ich viele elektronische Geräte. Doch mein Smartphone, mein 
PC und der Fernseher sind die einzigen Geräte, bei denen es wirklich um 
Datendurchsatz geht. Ist die Entwicklung von Waschmaschinen, 
Kaffeeautomaten, DECT Telefonen unrelevant und zählt zu den nicht 
richtigen Anwendungen?
Was ist mit Geräten mit digitalen Filtern und ähnlichen. Da werkelt auch 
öfter mal ein DSP drin. Auch keine richtige Anwendung?
Ich denke auch, wenn es ums "eingemachte" geht, sind sehr oft SOCs 
zusehen. Und dort ist dann ein uC mit eingebaut, um die ganze 
Funktionalität verarbeiten zu können. Also auch nicht immer die blanken 
ARMs a la STM32F4 oder ähnliches. Dort wird dann sicherlich ein 
schneller 32bitter eingebaut, um alle Kunden zu bekommen und nicht nur 
die, denen ein 8051 reichen würde.

Versteh(t) mich nicht falsch, ARMs und konsorten haben 100%ig 
Einsetzungsgebiete, wo sie die beste Wahl sind. Vielleicht sind es auch 
viele. Aber man kann nicht sagen, dass ein ARM oder anderer 32bitter 
IMMER die beste Wahl ist. Und solange das der Fall ist, wird es auch 
immer was anderes geben.

von Axel S. (a-za-z0-9)


Lesenswert?

Stefan schrieb:
> Ich finde das Marketing Gebrabbel von Microchip auch unerträglich.

Jedwedes Marketinggebrabbel ist unerträglich. Das ist seine Natur.
So wie Wasser naß ist und Feuer heiß.

> Klar, solange es um Kaffeemaschinen und LED Leuchten geht sind
> PICs die erste Wahl.

Ich finde ja, PICs sind nie die erste Wahl.
OK, über Geschmack soll man nicht streiten.

> Doch sobald es ans Eingemachte geht - richtige Anwendungen - bleiben nur
> noch ARM und Renesas.

Was unterscheidet "richtige Anwendungen" von Kaffeemaschinen?
Die Frage ist ernst gemeint.

> PIC32 interessiert doch niemanden. Das hat
> Microchip ja auch selbst inzwischen erkannt und gerade noch rechtzeitig
> Atmel gekauft. Sonst hätten sie eher früher als später einräumen müssen
> dass der PIC32 gegenüber dem Cortex-M nie eine Chance hatte.

Um ehrlich zu sein, ich habe Microchip als µC-Hersteller recht früh 
unter "ignorieren, lohnt nicht" abgelegt. Aber PIC32 ist MIPS. Das ist 
eine prima Architektur. Vielleicht hat Microchip die ja im Detail 
versaubeutelt, aber im Prinzip finde ich einen µC auf MIPS Basis sehr 
sexy. So viel netter ist ARM da nicht.

> PS: Ich brauche aktuell einen PIC (gerne 8Bit) der >= 5 Touch-Buttons
> abfragen kann und mit einer CR2032 versorgt mind. 1 Jahr lang läuft.

Die erste Frage wäre hier, warum du dich auf PIC festlegst. Fast jeder 
µC kann 5 Touchbuttons und low-power an 2.9..3.2V.

von Lothar (Gast)


Lesenswert?

Axel S. schrieb:
> Ich finde ja, PICs sind nie die erste Wahl

In der Industrie sind tatsächlich 8051 und ARM erste Wahl, aber wenn es 
auf jeden Cent ankommt sind die PIC tatsächlich unschlagbar günstig. So 
sind z.B. in fast allen LED-Lampen SOT23 PIC

> Aber PIC32 ist MIPS. Das ist eine prima Architektur. Vielleicht hat
> Microchip die ja im Detail versaubeutelt

Als erstes haben Sie die "microMIPS ISA" eingeführt die dem ARM Thumb 
entspricht, und sich damit dieselben Probleme geholt.

von Jobst M. (jobstens-de)


Lesenswert?

Axel S. schrieb:
> Ich finde ja, PICs sind nie die erste Wahl.

Stimmt. War bei mir auch so.

Und dann sucht man auf einmal einen µC mit 6 x I²S fähigem SPI und 
SD-Interface und findet nur den PIC32MZ.
Eine Rakete mit 200MHz. Geiles Teil. Aber nicht günstig ... :-/

Bei den Preisen werden die im 32-Bit-Brei nicht viel mitrühren ...

Aber ich finde das Teil cool!

Dennoch habe ich hier bestimmt noch 200 8-Bitter rumfliegen (8051, AVRs)
Wenn die passen, werden die auch noch eingesetzt.
Vorteil dieser kleinen Dinger: Man kann genau sagen, zu welchem 
Zeitpunkt welcher Befehl ausgeführt wird und damit, wann welcher Ausgang 
kippt. Das kann man bei moderneren, schnelleren Architekturen wie ARM 
und PIC32 mit Pipeline, Cache, eigenem Peripherietakt und Co. vergessen.



Gruß

Jobst

von (prx) A. K. (prx)


Lesenswert?

Lothar schrieb:
> Als erstes haben Sie die "microMIPS ISA" eingeführt die dem ARM Thumb
> entspricht, und sich damit dieselben Probleme geholt.

Welche?

: Bearbeitet durch User
von Gerhard O. (gerhard_)


Lesenswert?

Wie schon so oft, fürchte ich, dreht sich alles wieder um des Kaisers 
Bart!

Wie sagt das Sprichwort? "Jedem Tierchen sein Pläsierchen!"

Ich bin mir fast sicher was der Eine nicht mag, mag vielleicht jemand 
anders. Jeder uC hat seine Eigenheiten, Stärken und Schwächen. Das 
Genietum des Ingenieurs besteht nun darin diese zu berücksichtigen und 
konsequent die richtige Wahl für den Einsatz zu treffen.

Wir dürfen auch die Entwickler der uC und Architekturen Befehlssätze 
nicht gerade für blöd einschätzen. Sicher man hat nicht immer ein gute 
Hand gehabt und manchmal muß dann den eingeschlagen Architekturweg gehen 
und die Suppe auslöffeln. Beispiele gibt es ja genug in der Literatur.

Ich bin mir sicher wenn alles gesagt und getan wurde, daß die meisten uC 
ihre Aufgaben mehr oder weniger gut erfüllen solange die korrekte Wahl 
der Schlüsseleigenschaften bewirkt wurde. Und wenn sich ein uC schwer 
tut oder wegen der Art seiner Konstruktion nicht deterministisch genug 
ist, muß eben in manchen Fällen das Problem mit entsprechendem Hardware 
Design durch Verwendung von FPGAs und CPLDs oder altmodische zusätzliche 
Digital Bausteine gelöst werden.

Was die Sache vergleichsmäßig schwer macht sind die potenziellen 
Einsatzextreme. An einem Ende gibt es langsame Steueraufaben im ms zu s 
Bereich und am anderen Ende kodiert man Video und alles geht im ns 
Bereich ab.

Letzten Endes zählt nur wirklich ob die Aufgabe gut genug gelöst wurde 
und das Design die Anforderungen ausreichend gut erfüllt.

Bis jetzt habe ich noch nie auf einen anderen als den ursprünglichen uC 
umsteigen müssen. in den letzten 16 Jahren ziehten wir bei uns mit PICs, 
DSPPIC, AVRs, moderne 8051s, ARM7, Und zuletzt ARM-Cortex-M3/4 alles 
durch. Bei keinem uC gab es überwältigende Probleme. Ist nur eine Frage 
der Einarbeitung.

Es wird so oft die Komplexität der STM32 Peripherien bemängelt. War 
alles nicht so schlimm. Man muß sich nur einige Tage konsequent 
praktisch einarbeiten.

In einer höheren Programmiersprache verwischen sich sowieso oft die 
Unterschiede zwischen den einzelnen uC Typen. Was wichtiger ist, gute 
Entwicklungswerkzeuge zu haben auf die man sich verlassen kann. Man mag 
über einige kommerzielle Werkzeuge lästern, aber einige Teure sind, wie 
die Vergangenheit gezeigt hat, ihr Geld wert. Ich möchte jetzt natürlich 
keine Namen nennen.

Auch zahlt es sich in manchen Fällen aus professionell geschriebene und 
getestete Bibliotheken zu verwenden. Das spart einen in manchen Fällen 
viel Geld in nicht verlorener Zeit durch Fehlersuche und macht 
möglicherweise den Unterschied aus ein Projekt termingemäß fertig zu 
kriegen.

Was auch oft zu leicht genommen wird, gut funktionierende Hardware zur 
Verfügung zu haben. Wie oft wurde schon die FW beschuldigt, wenn dann 
letzten Endes fehlerhaftes HW-design oder ungünstiges Komponenten oder 
Bord Design die wirkliche Ursache war. Manche, die z.B mit SD-Karten zu 
tun hatten, können wahrscheinlich ein Lied davon singen.

Auch ist es wichtig den Feind gut zu kennen. Oft kommt man mit den Typen 
und Werkzeugen, Sprachen am schnellsten zum Ziel mit denen man schon 
einige Erfahrung hatte.

Ihr könnt mich jetzt dafür steinigen oder ignorieren, aber so sehe ich 
das.


Grüße,
Gerhard

P.S. Da ich mich nicht als professioneller Entwickler ansehe kann ich 
mir solche lockeren Sprüche erlauben:-)

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Michael S. schrieb:
> Ich denke auch, wenn es ums "eingemachte" geht, sind sehr oft SOCs
> zusehen. Und dort ist dann ein uC mit eingebaut, um die ganze
> Funktionalität verarbeiten zu können. Also auch nicht immer die blanken
> ARMs a la STM32F4 oder ähnliches. Dort wird dann sicherlich ein
> schneller 32bitter eingebaut, um alle Kunden zu bekommen und nicht nur
> die, denen ein 8051 reichen würde.

Guck dir mal den ellenlangen Thread an, wo es um die WinCE-Settop-Box 
von Pollin ging. Das ist ein typisches Beispiel. Bei der besagten 
Pollin-Box steckt ein älterer Media-Prozessor drin. Konkret sind rund 
80% der Chipfläche durch zwei fette 64 Bit Trimedia-DSP's belegt. Der 
Rest ist Display-Ansteuerung, Huffman-Hardware, sonstige Peripherie, und 
ganz in der Ecke ein 32 Bit MIPS, der für's householding da ist. Auf dem 
lief dann auch das WinCE - und all die Linuxer, denen es ja so unendlich 
wichtig war, dort ein Linux draufzubekommen, haben die eigentliche 
Hauptattraktion, nämlich die zwei fetten DSP überhaupt nicht zur 
Kenntnis genommen. Ähnlich sieht es bei den üblichen DVD-Playern aus. 
Allerdings haben die jahrelang verwendet gewesenen Chips von ESS ne MIPS 
+ nen schmaler aufgestellten 64 Bit DSP als eigentliche Arbeitspferde 
drin und für's householding nen 8051.


Axel S. schrieb:
> aber im Prinzip finde ich einen µC auf MIPS Basis sehr
> sexy.

Ähemm, hüstel... sexy?
Nun ja, wir haben alle unsere persönlichen Präferenzen, gelle?

Sachlich gesehen sind die PIC32 durchaus gute Prozessoren, aber an der 
Peripherie fehlt es deutlich. Wenn ich bedenke, daß einige Varianten ne 
MMU eingebaut haben, ohne wenigstens einen Anschluß für ein externes 
SDRAM zu haben, und ohne einen dedizierten richtigen TFT-Controller zu 
enthalten, kommt mir das Kopfschütteln. Hätte MicroChip ihren PIC32 nen 
richtigen externen 32 bit breiten Busanschluß gegönnt, der heutzutage 
mit LPDDRAM klarkommen sollte, dazu einen richtigen TFT-Controller, der 
auf den externen DDRAM echt paketweise zugreift und damit den Bus nicht 
gar zu sehr zum Flaschenhals werden läßt, dann wären sie damit den 
Cortexen davongezogen.

Ist aber nicht. Die Bastellösung von MicroChip ist und bleibt lausig und 
uneffektiv.

Man muß dazu sagen, daß NXP ne glückliche Hand gehabt hat, als sie die 
Blue-Streak's von Sharp aufgekauft hatten. Damit war das Knowhow für 
TFT-Controller im ARM-Umfeld bei NXP vorhanden. ST hat das erst viele 
Jahre danach kapiert und ne Menge von NXP kopiert. Aber bei MicroChip 
ist bis heute der Groschen nicht gefallen.

W.S.

von (prx) A. K. (prx)


Lesenswert?

W.S. schrieb:
> Pollin-Box steckt ein älterer Media-Prozessor drin. Konkret sind rund
> 80% der Chipfläche durch zwei fette 64 Bit Trimedia-DSP's belegt.

Das ist beim Raspberry Pi nicht viel anders, besonders beim ersten. Der 
besteht in der Hauptsache aus einem Mediaprozessor mit eigenen Programm, 
dem zwecks Linux-Betriebssystem ein ARM angeflanscht ist. Gebootet wird 
erst der Mediaprozessor, der wiederum dem ARM startet. Wenn man den RPi 
nicht an TV/Monitor betreibt, ist der Medieprozessor völlig für den A...

von W.S. (Gast)


Lesenswert?

Gerhard O. schrieb:
> Bis jetzt habe ich noch nie auf einen anderen als den ursprünglichen uC
> umsteigen müssen.

Da hast du entweder großes Glück gehabt oder ein Arbeitsumfeld, das dich 
davor geschützt hat. Mir ist sowas öfters passiert: 
Mitsubishi-->gestorben. NEC-->gestorben. Fujitsu-->gestorben. 
Hitachi-->naja, quasi gestorben, sprich umgerührt und nen Renesas draus 
gebacken.

Deshalb ist ein ziemlicher Teil meines persönlichen Code-Portfolios auch 
so ausgelegt, daß er sowohl bigendian als auch littleendian abkann. Das 
hab ich bislang bei feilgebotenen Bibliotheken anderer Leute noch nicht 
so gesehen.

Allerdings sehe ich durchaus, daß sowas mit der Zeit bedeutungslos wird, 
weil die Szene in Richtung Cortex Monokultur geht. Nun ja, jedenfalls 
die hier im Blickfeld befindliche Szene.

W.S.

von Lothar (Gast)


Lesenswert?

W.S. schrieb:
> für's householding nen 8051

Stimmt - und nicht nur in SoC auch in SiP kommt meist ein 8051 zum Zug - 
kein AVR oder PIC:

https://www.elektormagazine.de/news/gas-sensoren-in-smartphones-aber-mit-einem-8051

von TriHexagon (Gast)


Lesenswert?

Lothar schrieb:
> TriHexagon schrieb:
>> Aber gibt es heute noch 8-Bit Familien die aktiv weiterentwickelt
>
> EFM8 8051 sind erst 2015 rausgekommen, EFM8LB erst dieses Jahr. Wir
> evaluieren grade die Umstellung von einem ARM Design, denn EFM8LB hat
> 14-bit 1MSPS ADC und 4x 12-bit DAC, da gibt es aktuell keinen ARM
>
> http://www.silabs.com/products/mcu/8-bit/Pages/efm8.aspx
> 
http://www.silabs.com/products/mcu/8-bit/efm8-laser-bee/Pages/efm8-laser-bee.aspx

Oh die hatte ich ja noch gar nicht auf dem Schirm, sehen aber gut aus. 
Was hindert die Hersteller eigentlich solche Peripherie in 32-Bit µCs 
einzubauen?

Paul R. schrieb:
> Ist in Elektor Nr.541/542. Seite 34 35:
>
> seit Anfang 2015 AVR B-Typen
> 130nm-Prozess
> genauer RC-Oszillatoren
> Seriennummer
> mehr I/O
> Capacitive Touch in HW
> neue ATtinys
>
> nur im SMD-Gehäuse
>
> Eval-Bords: http://www.atmel.com/webdoc/atmega168pbxmini/index.html

Danke. Tatsächlich, gerade bei Atmel hab ich nicht mehr damit gerechnet.

W.S. schrieb:
> Deshalb ist ein ziemlicher Teil meines persönlichen Code-Portfolios auch
> so ausgelegt, daß er sowohl bigendian als auch littleendian abkann. Das
> hab ich bislang bei feilgebotenen Bibliotheken anderer Leute noch nicht
> so gesehen.
>
> Allerdings sehe ich durchaus, daß sowas mit der Zeit bedeutungslos wird,
> weil die Szene in Richtung Cortex Monokultur geht. Nun ja, jedenfalls
> die hier im Blickfeld befindliche Szene.

Soweit ich mich richtig erinnere, können die Cortexe sowieso beides.

von Gerhard O. (gerhard_)


Lesenswert?

W.S. schrieb:
> Mitsubishi-->gestorben. NEC-->gestorben. Fujitsu-->gestorben.
> Hitachi-->naja, quasi gestorben, sprich umgerührt und nen Renesas draus
> gebacken.

Das ist ja schockierend! Da haben wir scheinbar großes Glück gehabt. Wir 
hatten andererseits große Probleme bei der Beschaffung von SDRAM, FLASH, 
und TFT-LCDs wegen Abkündigungen. Drei Mal mußten wir innerhalb 7 Jahren 
auf Parallel Typen von SDRAM zugreifen. Im Falle der TFT-LCD mit 
industriellen Eigenschaften muß man froh sein 5 Jahre+ schaffen zu 
können. Die uC machten uns eigentlich diesbezüglich die geringsten 
Schwierigkeiten. Alles was wir bis jetzt verwendet haben ist immer noch 
im normalen Handel lieferbar.

von (prx) A. K. (prx)


Lesenswert?

W.S. schrieb:
> Ich frag dich mal, wozu man ne DMA tatsächlich braucht. Bei dedizierten
> Peripherie-Cores wie z.B. einem TFT-Controller mit DMA-Fähigkeit sieht
> man das sofort ein. Aber ein ganz gewöhnlicher DMA, dessen Fähigkeit
> sich auf das Umschaufeln von  A nach B erschöpft?

DMA ist bei mem-to-mem eher selten sinnvoll. Gewöhnlich ist eine Seite 
eine Peripherie-Einheit wie UART, SPI oder auch ein Port (z.B. per Timer 
getriggert).

Um nicht bei jedem Peripheriemodul das Rad neu zu erfinden macht man den 
DMA-Controller zentral und konfigurierbar und verbindet nur die Events 
der Module mit dem DMA-Controller.

> Wozu sowas?

Wenn alle paar µs ein ADC-Wort per SPI ansteht, dann sind Interrupts für 
jedes einzelne Wort unökonomisch bis unrealistisch. Die CPU wird solche 
Daten wahrscheinlich blockweise bearbeiten, oder auch nur so wie sie 
reinkamen per Ethernet wieder rausfeuern.

von Scelumbro (Gast)


Lesenswert?

A. K. schrieb:
> W.S. schrieb:
>> Pollin-Box steckt ein älterer Media-Prozessor drin. Konkret sind rund
>> 80% der Chipfläche durch zwei fette 64 Bit Trimedia-DSP's belegt.
>
> Das ist beim Raspberry Pi nicht viel anders, besonders beim ersten. Der
> besteht in der Hauptsache aus einem Mediaprozessor mit eigenen Programm,
> dem zwecks Linux-Betriebssystem ein ARM angeflanscht ist. Gebootet wird
> erst der Mediaprozessor, der wiederum dem ARM startet. Wenn man den RPi
> nicht an TV/Monitor betreibt, ist der Medieprozessor völlig für den A...

Da wir gerade über Abkündigungen reden. Die Tatsache, das der RPi SOc 
eine Multimediprozessor mit angeflanschtem ARM ist, macht der Foundation 
noch große Probleme. Den der Multimediaprozesor ist für RAM, GPIOs und 
Schnittstellen zuständig, wird aber von Broadcom nicht mehr 
weiterentwickelt, das zuständige Team ist aufgelöst. Deswegen wird es 
weder USB 3 noch mehr als 1GB RAM für den RPI geben.Es sei den sie geben 
die Abwärtskompatibilität auf und steigen auf einen neuen Grafikern um - 
mit all den Closed -Source Problemen.

von Lothar (Gast)


Lesenswert?

W.S. schrieb:
> wozu man ne DMA tatsächlich braucht

Bei den aktuellen 8051 z.B. um ADC Daten ohne CPU Last im RAM abzulegen. 
Das Programm kann dann warten, bis ausreichend Daten vorhanden sind und 
dann Filter o.ä. machen z.B. EFM8LB

Bei den ARM geht der Trend allerdings weg von DMA hin zu asymmetrischen 
Cores z.B. ein M0 beschäftigt sich mit dem ADC und holt Daten ab und ein 
M4 macht den Filter z.B. LPC4300

von W.S. (Gast)


Lesenswert?

Moby A. schrieb im Beitrag #4651674:
> Auf dem Xmega z.B. zum Eventsystem-gesteuerten Einlesen und Ausgeben von
> Puffern von/auf UART. Letzteres ist nach wie vor eine ganz feine
> Schnittstelle...

Lothar schrieb:
> Bei den aktuellen 8051 z.B. um ADC Daten ohne CPU Last im RAM abzulegen.
> Das Programm kann dann warten, bis ausreichend Daten vorhanden sind und
> dann Filter o.ä. machen

Kopfschüttel...

Also mal ganz generell:
Wenn Input-Daten anliegen, die in irgend einer Weise verarbeitet werden 
sollen, ist in jedem Falle Rechenzeit der CPU vonnöten, um eben diese 
Verarbeitung vorzunehmen. Da nützt es garnichts, wenn zuvor ein DMA 
die Daten von irgend einer Schnittstelle in irgend einen RAM befördert. 
Also könnte die CPU die Daten auch gleich aus der Schnittstelle lesen 
und verarbeiten. Das Einzige, was man bei irgendwelcher blockweiser 
Verarbeitung einsparen könnte, wäre der Overhead, der für einen 
Interrupt erforderlich ist. Der wird allerdings aufgefressen durch die 
Notwendigkeit, den DMA zu konfigurieren bzw. im Fluge umzukonfigurieren, 
ohne dabei ein oder mehrere Daten zu verlieren.

Ein wenig anders ist die Ausgabe zu einer Schnittstelle: Da kommen Daten 
asynchron herein und sie kommen nachdem der DMA bereits programmiert 
wurde. Ein DMA kann einen ganzen Block von Daten in geordneter Weise 
irgend wohin schaufeln. Aber er kann nicht auf Daten reagieren, die 
nach seiner Konfigurierung hereinkommen. Also geht alles nur 
blockweise und genau das ist das Gegenteil dessen, was man bei einer 
asynchronen Schnittstelle wie einem UART in Wirklichkeit haben will. 
Nein, dazu ist ein Treiber vonnöten und dieser muß puffern und mit 
völlig asynchron hereinkommenden und herauszugebenden Daten klarkommen. 
Ein DMA kann das prinzipiell nicht.

W.S.

von Carsten S. (dg3ycs)


Lesenswert?

Stefan schrieb:
> Das hat
> Microchip ja auch selbst inzwischen erkannt und gerade noch rechtzeitig
> Atmel gekauft. Sonst hätten sie eher früher als später einräumen müssen
> dass der PIC32 gegenüber dem Cortex-M nie eine Chance hatte.

Jetzt mal ganz unabhängig von der Frage wie gut (oder schlecht) die PIC 
32 tatsächlich sind...
Wie kann man bloß ernsthaft auf den Gedanken kommen das die ARM eine 
wesentliche Rolle bei der Entscheidung zur Übernahme von ATMEL gespielt 
haben könnten? Da muss man doch schon iemlich fanatisher ARM Fan sein, 
oder?

OK, sicher ist es ein netter Nebeneffekt das Microchip durch den Kauf 
neben den eigenen 8 & 16 Bit Pic architekturen, MIPS, sowie diversen 
8051 nun auch die ARM noch im Bestand hat (und natürlich die AVR)

Aber jetzt mal ehrlich:
Da ist jemand durchaus eher einer der Großen der Branche. So richtig mit 
eigenen FABs usw. Jemand dessen Geschäft die letzten Jahre gut gelaufen 
ist und der schon einige kleinere  und mittlere Firmen zur 
Sortimentsergänzung in der letzten Zeit zugekauft hat.

Versetzen wir uns mal in die Lage dessen Vorstandsvorsitzenden, also von 
jemanden der bestimmt wo es langgeht und dessen Gehalt zum großen Teil 
vom Gewinn bestimmt wird:

Mal angenommen die Behauptung das dieser Erkannt hat das ihm in einem 
Bereich ein wichtiges Produkt fehlt - Ein Produkt auf Basis eines 
geprüften, bereits entwickelten und damit jederzeit Lizensierbaren IP 
Cores, dann überprüft man natürlich die Möglichkeiten.
Soweit ist es ja noch Nachvollziehbar.

Aber wenn ich an diesem Punkt bin und es zeigen sich dann drei 
Möglichkeiten zeigen:

1. Ich mache es so wie andere große und vor allem unzählige kleine 
Halbleiterhersteller vor mir. Ich erwerbe eine Lizenz für den IP Core, 
verheirate den mit meiner eigenen Peripherie sofern nicht bereits 
ausreichend Perpherie als IP erworben werden kann und bringe das Teil 
unter meinem Namen in dem Markt.
Im Gegensatz zu den vielen kleinen und mittleren Fabless Herstellern die 
bereits diesen Weg gegangen sind habe ich Experten für wirklich ALLE 
stationen der µC Entwicklung und Herstellung im Haus und verfüge auch 
noch über eigene Fabriken so das sich da keine wirklichen Hindernisse 
auftun.
Kosten sind gut kalkulierbar. Die Worst Case Zeitschiene lässt sich 
Anhand derer (Kleinfirmen) die dieses Produkt ohne jede große 
Vorerfahrung vor mir in den Markt gebracht haben auch gut abschätzen.

Zudem habe ich in den letzten Jahren noch eine reihe kleinerer Firmen 
zugekauft, so das ich das Produkt auch unter deren Namen in den MArkt 
bringen könnte wenn ich nicht meinen Namen draufschreiben will.

2. Ich mache es wie in den Jahren vorher schon öfter Erfolgreich 
Praktiziert: Wenn mir eine Technologie im Portfolio fehlt kaufe ich 
einen kleinen Hersteller der diese Technologie bereits im Programm hat 
auf und gliedere den ein. Die Produkte kann ich dann über meine eigenen 
Fabs herstellen lassen oder wenn die Kapazität nicht reicht 
Fremdvergeben.
Da es ein Überschaubarer Betrag ist geht das ganze ohen große Wehen und 
Risiko für mich über die Bühne. Erregt kein großes Aufsehen und wenn es 
schief geht unschön, aber nicht existentiell.

3. Ich suche mir ein anderes, so gerade mit Kraftanstrengung noch 
schluckbares Schwergewicht aus, ds durch einen Schrumpfungsprozess aber 
eigendlich nur noch aus Lizenzrechten, Kunden und Namen besteht aus 
(Kein Fabs, keine besonderen Herstellungstechnologien usw. also nichts 
was für meine Bestandsprodukte sinnvoll ist) der neben vielen anderen 
Sachen halt auch das gewünschte Produkt im Portfolio hat.
Diesen Kaufe ich in einem Bieterwettstreit mit einem anderen Mitbieter 
für einen Betrag der mein eigenes Unternehmen im Falle eines 
Misserfolges in existentielle Probleme bringen könnte. Eine Übernahme 
die Wellen schlägt und mir auch einigen Gegenwind von teilen meiner 
Aktionäre einbringen wird.


Jetzt mal ehrlich:
Wer glaubt tatsächlich das bei dieser Auswahl auch nur der HAUCH einer 
Chance bestehen würde das die Entscheidung auf Möglichkeit drei fällt?

nee, für den Atmel Kauf waren ganz andere Dinge als "ARM" 
ausschlaggebend. Das war höchstens ein netter Beifang. Aber keinesfalls 
mehr!
>
> PS: Ich brauche aktuell einen PIC (gerne 8Bit) der >= 5 Touch-Buttons
> abfragen kann und mit einer CR2032 versorgt mind. 1 Jahr lang läuft.

Eine der ALLERWICHTIGSTEN Randbedingungen für solche Anfragen hast du 
hier vergessen. Wie sieht es mit dem Verhältnis der StandbyPahsen zu den 
Betriebsphasen aus? Und überhaupt, was ist als Standby möglich?
DeepSleep - Das mit Watchdog oder ohne?
Oder muss der durchgehend im Idle Modus laufen?

Das sind die entscheidenden Parameter bei der Auswahl...

Aber um mal einen Typ ins Blaue zu werfen:
PIC16F18313 könnte was für dich sein...

Gruß
Carsten

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.