Neue Cortex-M0+-Familie von Atmel

Der Atmel-Süchtige schrieb:

> ...und eine Einschätzung von dritter Seite:
> http://www.elektroniknet.de/halbleiter/mikrocontroller/artikel/98530/

Das ist keine dritte Seite. Die leben von der Werbung, die Firmen in 
Auftrag geben.

> Tolle Teile!

Dafür sehe ich keine Belege

> Der Atmel-Süchtige

Begebe dich sofort in Behandlung. Heilung ist möglich (siehe ST).

elektronik.net: "Über die Daten der MCU hinsichtlich Energiesparmodi und 
Leistungsaufnahme gibt es in der ersten veröffentlichten 
Datenblattversion leider keine Angaben."

Kein Kommentar.

Warum soll ich jetzt davon begeistert sein? Mir wird das nicht ganz 
klar.
Der ARM LPC1114FN28 von Phillips begeister mich da eher:
http://avr.paslog.jp/article/2542408.html

Äh, tschuldigung ... NXP meinte ich.

Hier noch ein einfaches Schaltungsbeispiel:
http://vilaca.eu/lpc1114/

was für ein Schwachsinn in dem Bericht steht, soweit ich mich 
zurückerinnern kann, ist der Xmega bereits vor EnergyMicro Gründung 
entwickelt worden und da gab es schon das bekannte Event System...

ich finde das Sercom Design interessant, man kann nun wirklich eine 
schöne Plattform aufbauen. mir gefällt auch das BIST Modul, der Chip 
passt ganz gut zwischen Xmega und CM3, wenn man gute analoge Peripherie 
will mit gain stage kann man jetzt zwischen Xmega und CM0+ von Atmel 
wehln

Heiko Jakob schrieb:
> Sieht eher nach dem Sargnagel für die 32-bit AVRs aus :-(
> Mal gespannt wie lange sich die UC3s noch in der Roadmap von Amtel
> halten.

glaub nicht dass die so schnell von der Bildfläche verschwinden, für die 
32bit AVR kommt eher ein CortexM4 entgegen (DSP) und Atmel hat ja schon 
seit längerem die low power SAM4L Serie im Angebot, trotzdem hat sowohl 
Samsung als auch Microsoft den UC3L den Vorzug gegeben - hätte der 32Bit 
AVR keinen Markt dann wäre er also schon lange verschwunden denke ich.

UC3L im Microsoft Surface: 
http://www.ifixit.com/Teardown/Microsoft+Surface+Teardown/11275/2

UC3L im Samsung Galaxy Tab:
http://www.highbeam.com/doc/1G1-310928378.html

Wenn der 32Bit AVR in einer Foundry produziert wird, dann gibt es fast 
gar keinen Grund den abzukündigen - man muß ja keine Technologie 
vorrätig halten sondern bestellt seine Wafer einfach nach wenn jemand 
danach fragt.
Theoretisch könnte so ein Bauteil jahrelang weiterangeboten werden 
selbst wenn dafür in einer eigenen Fab kein Platz mehr ist.
Was aber gut sein kann dass Atmel keine neuen 32Bit AVR mehr designed, 
aber das heißt ja nicht dass der Baustein nicht mehr vorhanden ist. Noch 
ein wenig dann wird es auf CM3/CM4 auch keine weiterentwicklungen mehr 
geben, wird aber wohl eine weile weiterproduziert, kommt sicher 
irgendwann ein neuer Core und dann geht das ganze von vorn lso

>Warum soll ich jetzt davon begeistert sein?
Wegen SERCOM mit nur 2x-RX-Buffer braucht man es jedenfalls nicht.
(PIC24 zB hat da ein 8x FIFO)()

Mit 4 INT-Prioritäten hat SAMD20 auch nicht mehr als die ATXmegas.

Mal schauen, wann Steine mit 2xCAN  USB  Ethernet kommen...

Ich schrieb:
> Mal schauen, wann Steine mit 2xCAN  USB  Ethernet kommen...

... HDMI, SATA ...

Atmel musste auf jeden Fall was die Richtung tun, wer will schon ATMEGA 
Krücken haben, wenn zum selben Preis Cortexe zu haben sind. Mich wundert 
es sowieso, wie manche bei Neuentwicklungen die Technik auf dem Stand 
vor >10 Jahren einsetzt, nur weil man es schon immer gemacht hat? Aber 
jetzt zum Atmel Cortex Chip selbst. Ich habe mir die Teile angesehen und 
sehe keinen Grund die neuen Chips von Atmel den bereits länger 
vorhandenen von ST, NXP etc. vorzuziehen.

Christian Kreuzer schrieb:
> Schade, wieder ohne CAN, da bleibt wohl doch nur NXP.
>
> Christian_RX7

Oder ST

Jörg Wunsch schrieb:
> Beispielsweise Leute, die Betrieb bei 5 V brauchen (soll wohl in
> der Fahrzeugtechnik noch sehr verbreitet sein). Es gibt meines
> Wissens bislang keinen einzigen ARM, der das kann.
>
> Wenn du nur 'ne Fensterscheibe runterleiern willst, ist dir das als
> Anwender völlig wurscht, ob der Controller nun 8 Bit oder 32 auf
> einmal verarbeitet.  Schneller wird das Fenster davon sowieso nicht. :-)

In der Fahrzeugindustrie setzt man sowieso (wie in Luftfahrt + 
Raumfahrt) auf alte, wenn nicht veraltete Mikrocontroller. Meist 
Freescale oder Motorola HCxxxxx. Hat den einfachen Sinn, dass die sehr 
bekannt sind und vor allem robust. Die Teile sind schon so lange auf dem 
Markt, dass man jeden einzelnen Fehler auswendig kennt und die 
etablierten Teile sind zuverlässig wie keine anderen.

Aber das mag dem Hobbybastler so und so egal sein, kaum einer weiß ja 
von den Errata geschweige denn liest sie. Außerdem interessiert es 
niemanden wenn mal die blinkenden LEDs beim Hobbyprojekt ausgehen oder 
der µC sich verhaspelt. Wenn jedes halbe Jahr ein neuer Mikrocontroller 
raus kommt dann wird der einzelne nie so gut "erforscht" werden wie es 
besagte Klassiker sind.

Jörg Wunsch schrieb:
> Beispielsweise Leute, die Betrieb bei 5 V brauchen (soll wohl in
> der Fahrzeugtechnik noch sehr verbreitet sein). Es gibt meines
> Wissens bislang keinen einzigen ARM, der das kann.

Fujitsu und Toshiba müssten da etwas haben.

STM hat an einuigen pins 5V toleranz
LPC111x auch
Nuvoton auch
TI auch ...

gibt also einige die 5V abkönnen zumindest an den GPIOs
5V treiben war noch nie die stärke eines µC und meist nur eine 
krückenlösung

> Beispielsweise Leute, die Betrieb bei 5 V brauchen (soll wohl in
> der Fahrzeugtechnik noch sehr verbreitet sein). Es gibt meines
> Wissens bislang keinen einzigen ARM, der das kann.


XMC1100 von Infineon wäre so ein Teil. CM0 mit 5V

>> Beispielsweise Leute, die Betrieb bei 5 V brauchen (soll wohl in
>> der Fahrzeugtechnik noch sehr verbreitet sein). Es gibt meines
>> Wissens bislang keinen einzigen ARM, der das kann.
>Fujitsu und Toshiba müssten da etwas haben.
und Nuvoton

Marc N. schrieb:
>
> In der Fahrzeugindustrie setzt man sowieso (wie in Luftfahrt +
> Raumfahrt) auf alte, wenn nicht veraltete Mikrocontroller. Meist
> Freescale oder Motorola HCxxxxx.

Für die Luft+Raumfahrt ist die Aussage richtig, aber die Begründung 
unvollständig. Neben Zuverlässigkeit geht es hauptsächlich um 
Analysierbarkeit und Vorhersagbarkeit.

Zwei Dinge sind in den letzten Jahren doch ganz klar geworden:

- 8-Bitter sterben aus. Sie werden vom Cortex M0 verdrängt.
- Die Cortex-M-Serie ist im Moment bei kleinen Controllern das Maß der 
Dinge. Inzwischen baut fast jeder uC-Hersteller ARM-Kerne in ihre neuen 
Bausteine ein.

Dem konnte sich auch Atmel nicht entziehen.

Die Hersteller müssen sich jetzt eben umstellen. Früher war der 
Prozessorkern und die Toolchain noch Teil ihres Hauptgeschäftes. Jetzt 
müssen sie sich anhand der Peripherie und Support differenzieren.

>- 8-Bitter sterben aus
wetten dass nicht?
Frag mal Microship, die werden alles dran setzen auch weiterhin ihre 
(vom Grunde her seit Anf. der 70er Jahre(!!!) bestehende 8-Biter zu 
vermarkten.

MCUA schrieb:
> Frag mal Microship, die werden alles dran setzen auch weiterhin ihre
> (vom Grunde her seit Anf. der 70er Jahre(!!!) bestehende 8-Biter zu
> vermarkten.

Nicht wirklich. Wenn Microchip das tut, werden sie vom Markt 
verschwinden. Es gibt keinen vernünftigen Grund mehr, weiterhin auf 
8-Bitter zu setzen.

A. K. schrieb:
> Kaum. Es wird beide nebenher geben. Möglicherweise werden aber einige
> eher exotische Serien eingestampft. Das 51er bald aussterben kann man
> wohl ausschliessen.

Ganz aussterben natürlich nicht, aber sie werden nur noch für exotische 
Anwendungen überhaupt interessant.

A. K. schrieb:
> Je leistungsfähiger Cores werden, desto grösser ist das Risiko für den
> Hersteller. Denn ernsthafte Bugs können dann existenzbedrohend sein, und
> deren Wahrscheinlichkeit wächst mit der Komplexität. Als zuverlässig
> bekannte Cores einzukaufen ist weniger riskant.
>
> Weil zudem Toolchains und ihr Support auch nicht kostenlos vom Himmel
> fallen, ist stets die Frage, ob Ausgaben für eine eigene Architektur
> teurer oder billiger als Lizenzkosten sind. Software ist nicht unbedingt
> das Kerngeschäft eines Halbleiterherstellers.

Genau das sind die Gründe, wieso man auf Standard-Cores setzt und eigene 
Architekturen immer mehr aussterben werden.

Mehmet Kendi schrieb:
> Tatsache ist aber, dass ich bei Neuentwicklungen ganz gerne mal wieder
> einen 8-Bitter einsetze. Nicht jetzt unbedingt wegen dem Preis; aber sie
> sind schlicht einfacher in der Handhabung (Software).

Preislich liegen Cortex M0 schon lange gleich auf. Und auf der 
Toolchain-Seite wird sich noch einiges tun. Wobei ein Crossworks jetzt 
schon mindestens genauso komfortabel ist wie ein AVR-Studio.

gibt es die M0 von Atmel denn schon? wollte mir aus Neugier mal 
anschauen was die können. Aber die Datenblätter sind ein wenig 
merkwürdig. Es gibt nicht mal einen Abschnitt wo die maximal zulässigen 
Ströme drin stehen. Oder wie man den Quarz anzuschießen hat. Oder suche 
ich nur falsch?

http://www.atmel.com/devices/SAM_D20E14.aspx?tab=documents

Auch vermisse ich die Infos welche Hilfsmittel man zum "brennen" 
braucht.

>Ganz aussterben natürlich nicht, aber sie werden nur noch für exotische
>Anwendungen überhaupt interessant.
Nö. exotische Anwendungen bedeuten sehr geringe Stückzahlen.
Bei den (verfügbaren) 8-Bitern ist das Gegenteil der Fall.
Zudem sind 8-Biter in einigen Fällen leistungsfähiger und besser als 
32Biter.
(Es ist auch fraglich, ab man eine CPU als "32Biter"bezeichnen soll, 
bloss weil da ein paar 32-Bit-Register drin sind.)

>Genau das sind die Gründe, wieso man auf Standard-Cores setzt und eigene
>Architekturen immer mehr aussterben werden.
Würde ja heissen, dass es in Zukunft nur noch Cores eines -Einzigen- 
Herstellers gibt. Na dann gute Nacht.

>Wenn du die Leistungstreppe bis zum Ende erklimmst, dann landest du in
>der Masse bei einer einzigen ISA mit knapp über 2 Herstellern, mit
>langfristiger Option auf exakt einen.
wäre X86(?) , Alpha(?), PPC(?), Grossrechner mit 1 Mio Kernen (?).
Also dann muss 'jetzt' Microship den X86 nehmen und den in 8Piner 
einbauen???

Es ist doch nicht das absolute Ende der Leistungstreppe massgebend (das 
zudem extrem schwer zu definieren ist), sondern schlichtweg das, was man 
für einen bestimmten Preis bekommt.

Jörg Wunsch schrieb:
> Beispielsweise Leute, die Betrieb bei 5 V brauchen

Wenn hier schon Werbung für Atmel und Co gemacht wird, kann ich ja mal 
Toshiba empfehlen. Cortex-M3 basierende, echte 5V-Devices mit 
integriertem Spannungsregler für die interne Logik, die auf 1.5V läuft. 
Also draußen echte 5V-I/Os, intern stromsparende 1.5V für den Core.
Typen: M380 und M370 (für Motorcontrol).
http://www.toshiba-components.com/microcontroller/M37Sigma.html
Industrieanwendungen setzten zum Teil immernoch auf 5V. Damit ist auch 
die Anbindung an die Leistungselektronik ohne Level-Shifter leichter.
Für Automotive: M350
http://www.toshiba-components.com/automotive/autocortexm3.html

> gibt es die M0 von Atmel denn schon?
samples ja, production ende 2013

>wollte mir aus Neugier mal anschauen was die können. Aber die Datenblätter >sind 
ein wenig merkwürdig. Es gibt nicht mal einen Abschnitt wo die maximal >zulässigen 
Ströme drin stehen. Oder wie man den Quarz anzuschießen hat. > >Oder suche ich nur 
falsch?
nein, das datenblatt ist aj auch noch Preliminary.

>Auch vermisse ich die Infos welche Hilfsmittel man zum "brennen"
>braucht.
SAM D20 Xplained Pro Evaluation Kit hat debugger integriert (j-link)
Atmel Studio 6.1 hat Unterstützung eingebaut.

gruss
gerhard

MCUA schrieb:
> Nö. exotische Anwendungen bedeuten sehr geringe Stückzahlen.
> Bei den (verfügbaren) 8-Bitern ist das Gegenteil der Fall.
> Zudem sind 8-Biter in einigen Fällen leistungsfähiger und besser als
> 32Biter.

Mit exotisch meinte ich Dinge wie RF, wo man aufgrund des großen 
analogen Anteils andere Strukturbreiten fährt und deshalb die 
Siliziumfläche des Cores wieder eine ganz andere Rolle spielt. Riesige 
Stückzahlen gibt es dort aber auch. Für Standardanwendungen sind Cortex 
M0 im Moment fast unschlagbar, und das sowohl bei Einzelstücken als auch 
Millionenstückzahlen.

8-Bit-uC können wenn überhaupt noch mit größerer oder speziellerer 
Peripherie punkten, aber das liegt einfach daran, dass die M0 noch sehr 
neu sind. Man sieht ja auch schon, dass sich da sehr viel tut.

MCUA schrieb:
> Würde ja heissen, dass es in Zukunft nur noch Cores eines -Einzigen-
> Herstellers gibt. Na dann gute Nacht.

Wie schon erwähnt wurde ist das genau die Situation, die man auf dem PC- 
und Servermarkt hat. Dort sind vor ca. 5-8 Jahren die letzten 
nicht-x86-Massenprodukte ausgestorben - heute gibt es nur noch Exoten. 
Und selbst die Konsolenwelt wird gerade aufgeräumt und wird bald von x86 
dominiert.

Auch wenn sich eine Architektur durchsetzt, heißt das noch lange nicht, 
dass es auch nur einen Hersteller gibt. Das sieht man ja auch in der 
PC-Welt. Und im Embedded-Markt ist es ja so, dass es mehrere Hersteller 
gibt. Lediglich der Kern wird von einer Firma bereit gestellt, und es 
gibt ja auch Ansätze von anderen Firmen, kompatible Cores zu entwickeln 
(Qualcomm wurde ja schon genannt).

Besserwisser schrieb:
> Wenn hier schon Werbung für Atmel und Co gemacht wird, kann ich ja mal
> Toshiba empfehlen. Cortex-M3 basierende, echte 5V-Devices mit
> integriertem Spannungsregler für die interne Logik, die auf 1.5V läuft.

Gibt es die im DIP-Gehäuse und kannst Du mir die Bestellnummer von R* 
nennen? Oder soll ich mit RX210 kommen?
Ich habe mir erst einmal wieder ein paar hundert ATmega88 bestellt. 
Deren Möglichkeiten entsprechen meinen Fähigkeiten :-)

Jörg Wunsch schrieb:
> Ich glaube, die Siliziumfläche des Cores spielt auch bei normalen
> Controllern nicht die große Rolle.  Es überwiegt der Flächenverbrauch
> der Peripherie und des Speichers (Flash + SRAM) deutlich das
> bisschen Core. Damit ist es aber nun auch egal, ob der Core ein
> AVR oder ein CM0 ist.

Genau das meinte ich. Bei RF-Prozessen sieht das aber vielleicht etwas 
anders aus, weil man gröbere Strukturen hat. Die Chips haben eben viel 
weniger Flash und RAM und dafür mehr analoge Schaltung drauf.

Ja, es wird wohl auf die tatsächlich verwendete Technologie ankommen. 
Andere Hersteller setzen bei solchen Anwendungen immer noch stark auf 
den 8051, aber auch das ändert sich natürlich. Wenn das so funktioniert 
gibt es jedenfalls noch einen Grund weniger für 8-Bit-uC.

Andreas H. schrieb:
> Welche, von den hier
> diskutierten Teilen, haben den Entwicklungstools mit Qualifizierung für
> FDA,FAA,MIL etc ? (Gerne auch Drittanbieter)

Gutes Beispiel für eine exotische Anwendung (auch wenn da womöglich auch 
Millionenstückzahlen dahinterstecken können...)

Besserwisser schrieb:
> Also draußen echte 5V-I/Os, intern stromsparende 1.5V für den Core.
> Typen: M380 und M370 (für Motorcontrol).

Aber die Eingänge sind im Gegenzug auch nicht 3.3V kompatibel wie bei 
AVR...
Beim M374 war ich mal auf nem Workshop bei GLYN. Die Anwendung um einen 
Motor zu steuern war so am Poller (RAM mäßig) das byteweise am Stack der 
FreeRTOS Tasks gedreht werden musste damit es überhaupt lief.

>Auch wenn sich eine Architektur durchsetzt, heißt das noch lange nicht,
>dass es auch nur einen Hersteller gibt.
Doch, der eigentliche CPU-Hersteller ist dann nur Einer, nicht Mehrere.
Und nur Einer am Markt (egal welcher) ist immer schlecht!

>Das sieht man ja auch in der PC-Welt.
Ist total was anderes wie Embedd.Bereich, weil das an PC-Software (X86) 
festgemacht.
Im Embedd.Bereich ist das ja nirgentwo vorgeschrieben.
Und mit Sicherheit wird es auch in 20 Jahren noch einige verschiedene 
CPU-Archit f. Embedd geben.

Jörg Wunsch schrieb:
> Geschwindigkeit oder Wortbreiten sind für derartige Anwendungen
> völlig nachrangig. Oft genug laufen die zufriedenstellend schon mit
> einem Takt von 1 MHz. Nicht jede Applikation muss erst ein Windows
> booten, bevor sie arbeiten kann. :-))

Aha, es kommt bei solchen Anwendungen aber auf die Summe von Suspend und 
Run an. Da kann die CPU noch so wenig im Suspend verbrauchen und dann im 
Run alles wieder verbraten ;-).

MCUA schrieb:
> Doch, der eigentliche CPU-Hersteller ist dann nur Einer, nicht Mehrere.
> Und nur Einer am Markt (egal welcher) ist immer schlecht!

Nein! Siehe Krait, siehe OpenCores. Es gibt Möglichkeiten, alternative 
Implementationen einer Architektur zu entwickeln.

MCUA schrieb:
> Im Embedd.Bereich ist das ja nirgentwo vorgeschrieben.
> Und mit Sicherheit wird es auch in 20 Jahren noch einige verschiedene
> CPU-Archit f. Embedd geben.

Es gibt auch im PC- und Serverbereich noch verschiedene Architekturen. 
Die spielen keine Rolle mehr. Auch im Embedded-Bereich kommt das Thema 
Standardsoftware immer stärker. Es fängt bei der Toolchain an und hört 
bei Echtzeitbetriebssystemen und Standardbibliotheken auf.

>Auf dem SAM D20 Explained board befinden sich erstaunlich wenige
>Bauteile? Ist der Debugger auf der Rückseite oder in der MCU selbst
>integriert?
auf dem board ist der sog, Atmel Embedded Debugger bestückt, welcher 
eine SWD Schnittselle zum debuggen zur verfügugn stellt. diese kann auch 
für externe boards verwendet werden. am besten mal das user guide 
runterladen:
http://www.atmel.com/Images/Atmel-42102-SAMD20-Xplained-Pro_User-Guide.pdf

gruss
gerhard

Nö, das stimmt so nicht.

Nehmen wir den EFM32TG (oder "Tiny Gecko"):

Der verbraucht 210µA/MHz bei 1MHz und 150µA/Mhz bei 32MHz mit einem 
Cortex M3, der 1,25DMIPS/MHz hat.

Das heißt der Energieverbrauch bei gleicher Spannung ist 1.4 höher bei 
1MHz verglichen zu 32MHz.

Der SD20 soll auch 150µA/MHz können - für welche Frequenzen dies gilt, 
habe ich noch nicht finden können.
Allerdings mit einem Cortex M0+, d.h. mit 0.93 DMIPS/MHz.
Damit folgt dass diese MCU ca. 1.34x mehr Energie verbraucht als die mit 
Cortex M3.

D.h. für Anwendugen mit möglichst niedriegem Energieverbrauch lohnt sich 
der genaue Blick auf die Effizient der CPU und auch die µA/MHz-Werte 
über die jeweiligen Taktfrequenzen.

Dazu kommen natürlich die genannten Unterschiede bzgl. Wake-up-Zeiten 
(bei EFM32TG 2µs, beim SAM D20 habe ich noch keine Werte gefunden, und 
vor allem wieviel Strom im Standby verbraucht wird.

Beim Tiny Gecko kann ich Funktionen mit 1-2µA erledigen (Display 
ansteuern, UART, Captouch, etc.).

Gruß Cpt Haddock

Jörg Wunsch schrieb:
> Das ist das, was ich mit „relativ linear“ meinte; es ist eben nicht
> exakt linear.  (Offenbar auch bei den ARMs mit ihren kleinen
> Strukturen stärker nichtlinear als bei den AVRs mit ihren etwas
> größeren Strukturbreiten.)

Logisch, bei kleinen Strukturen nimmt die statische Stromaufnahme extrem 
zu. Ein großer FPGA im 28nm-Prozess kann schon einmal auf ein halbes 
Watt rein statische Leistungsaufnahme kommen.

>Es gibt Möglichkeiten, alternative
>Implementationen einer Architektur zu entwickeln.
Das ists aber keine andere Architektur, sondern fast das Gleiche in 
Grün.


>Es gibt auch im PC- und Serverbereich noch verschiedene Architekturen.
PC ist was andere als Server. Bei PC gibts fakt nur X86.

>..und hört bei Echtzeitbetriebssystemen und Standardbibliotheken auf.
Das benötigt gerade keine bestimmte CPU.
Aber alles was Standard-OSs oder -Bibl. sind, hat auch Einschränkungen 
(ua zu aufgeblähter Code, zu langsam, wegen Std auch eingeschränkt (da 
man auf spez uC-Features nicht eingehen kann)) gegenüber auf den konkr. 
Chip optimierte Software.
Und genau aus dem Grund wird noch lange nicht jede Appl mit Std-Softw 
gemacht. (Obwohl manche dass schon seit 20 Jahren proklamieren)

>>..und hört bei Echtzeitbetriebssystemen und Standardbibliotheken auf.
Das benötigt gerade keine bestimmte CPU.

Also wenn es nicht gerade um Hochsprachenfeindliche Krüppel-ISAs wie 
8051 und PIC geht, ist die ISA eines MCUs eigentlich auch ziemlich 
belanglos. Die Probleme bei der Portierung zwischen den Architekturen 
entstehen durch die Peripherie.

Gerade wenn hier mehr Flexibilität erreicht werden soll, helfen 
allerdings etwas mehr Rechenpower und 32Bit. Daher ist ein Schritt von 8 
auf 32Bit absehbar. Es muss aber keine ARM Monokultur werden. Von den 
Japanern gibt es noch einige interessante Alternativen. Auch MIPS ist 
noch nicht tot, wird aber wohl nicht im Low-End MCU bereich zu finden 
sein.

Nur schade, dass Atmel Ihre Produktlinien so breitwillig der Erosion 
überlassen...

>ist die ISA eines MCUs eigentlich auch ziemlich belanglos.
VonWegen. Die entscheidet über die Leistung (der CPU).

>>ist die ISA eines MCUs eigentlich auch ziemlich belanglos.
>VonWegen. Die entscheidet über die Leistung (der CPU).

Zur Info: ISA=Instruction Set Architecture.

Wie stark unterscheidet sich denn die Performance zwischen AVR und ARM 
bei Berechnung von 8 Bit Aufgaben? Oder ARM vs. MIPS? Der Unterschied, 
den die ISA ausmacht ist ab einem gewissen Level relativ marginal. (Wie 
gesagt, Antikes mal außen vor gelassen)

MCUA schrieb:
> Das ists aber keine andere Architektur, sondern fast das Gleiche in
> Grün.

Wie eben im PC-Markt und x86.

Es steht natürlich jedem frei, eigene Architekturen auf den Markt zu 
bringen und damit erfolgreich zu sein. Nur im Moment sieht es eben so 
aus, als würde sich ARM durchsetzen. Die 8-Bit-Architekturen werden 
jedenfalls nicht in der heutigen Breite überleben und eine wirkliche 
Konkurrenz für die Cortex M gibt es auch noch nicht.

MCUA schrieb:
> Aber alles was Standard-OSs oder -Bibl. sind, hat auch Einschränkungen
> (ua zu aufgeblähter Code, zu langsam, wegen Std auch eingeschränkt (da
> man auf spez uC-Features nicht eingehen kann)) gegenüber auf den konkr.
> Chip optimierte Software.

Vorurteile, die heutzutage oftmals gar nicht mehr zutreffen. Heutzutage 
setzt mal lieber auf einen stärkeren Core (eben z.B. einem Cortex M) und 
verwendet Standardbibliotheken. Time-To-Market wird heutzutage vielmals 
höher bewertet als Kostenoptimierung auf den letzten Cent. Wobei die 
Cortex-M ja sogar Kostenvorteile bieten.

MCUA schrieb:
> Und genau aus dem Grund wird noch lange nicht jede Appl mit Std-Softw
> gemacht. (Obwohl manche dass schon seit 20 Jahren proklamieren)

Meine Erfahrung ist eher, dass das mehr am Ego der Programmierer liegt 
als an "harten" Gründen.

8-Bit schrieb:
> Vorurteile, die heutzutage oftmals gar nicht mehr zutreffen. Heutzutage
> setzt mal lieber auf einen stärkeren Core (eben z.B. einem Cortex M) und
> verwendet Standardbibliotheken. Time-To-Market wird heutzutage vielmals
> höher bewertet als Kostenoptimierung auf den letzten Cent. Wobei die
> Cortex-M ja sogar Kostenvorteile bieten.

Was soll "man" jetzt mit dieser Aussage anfangen? Wer ist überhaupt 
"man"?
Persönlich nehme ich immer noch die Teile, die für die betreffende 
Anwendung sinnvoll sind.

Wenn ich mich nach "man" richten müßte, müßte ich jeden Sonntag mit dem 
Geländewagen zum Bäcker fahren. Ich laufe lieber!

Noch ein Nachtrag zum Thema Energiefreundlichkeit (s.a. oben):

Jörg Wunsch schrieb:
> Das ist das, was ich mit „relativ linear“ meinte; es ist eben nicht
> exakt linear.  (Offenbar auch bei den ARMs mit ihren kleinen
> Strukturen stärker nichtlinear als bei den AVRs mit ihren etwas
> größeren Strukturbreiten


Der AVR-8 hat 0.328DMIPS/MHz 
(http://www.ecrostech.com/Other/Resources/Dhrystone.htm)
Ein ATTiny hat ca. 375µA/MHz (1.5mA@3V@4MHz). D.h. er verbraucht bezogen 
auf DMIPS ~9x mehr als ein Tiny Gecko mit ARM Cortex M3.

Das ist nun natürlich bezogen auf einen rechenintensiven Benchmark. D.h. 
bei sehr einfachen Applikation ohne viel Anforderungen an die CPU (ud 
vielleicht noch in Assembler programmiert?!) wird der ATTiny seinen 
Dienst mit wenig Energie tun.

Die Zeiten der Autocodegeneratoren, Libraries, C/C++,... + mehr 
benötigte lokale Rechenperformance treiben die Rechenleistung nach oben.

Wie bei jedem Thema: Gute Analyse der eigenen Anforderungen und 
Benchmark mit eigenen Code auf den Eval-Boards der möglichen 
MCU-Kandidate.

Bei mir hat der Tiny Gecko (EFM32TG) gewonnen :-)

M. N. schrieb:
> Was soll "man" jetzt mit dieser Aussage anfangen? Wer ist überhaupt
> "man"?
> Persönlich nehme ich immer noch die Teile, die für die betreffende
> Anwendung sinnvoll sind.

Natürlich kannst du für dich machen, was du willst. Ich beschreibe nur 
die Situation, wenn es in der Industrie um Stückzahlen, Kosten, Qualität 
und Wartbarkeit geht.

8-Bit schrieb:
> Natürlich kannst du für dich machen, was du willst. Ich beschreibe nur
> die Situation, wenn es in der Industrie um Stückzahlen, Kosten, Qualität
> und Wartbarkeit geht.

Das ist eine gewagte Aussage. Hast Du Zahlen, dies zu belegen?
Wer ist denn die "Industrie"? Ein homogener Haufen, der irgendwelchen 
Maktprognosen-Gurus hinterherläuft? Das glaube ich nicht!

Ich sehe auch einen Unterschied, ob jemand in Stückzahlen Autos, 
Telefone, Fernseher oder Staubsauger herstellt. Gerade bei 
consumer-Elektronik ist es doch mit Qualität und Wartbarkeit eh nicht 
weit her.

Hoffentlich bleibt eine Vielzahl diverser Architekturen noch lange 
erhalten. Je nach Anwendung sind die Anforderungen immer unterschiedlich 
und somit bleibt auch Platz für persönliche Vorlieben und Abneigungen, 
denen sich keiner entziehen kann. Wer einen 8051 in der Muttermilch 
hatte, dem wird er weiterhin gut schmecken :-)
Wenn hier an einer Stelle um nA gefeilscht wird, ist das für Manche 
substantiell und für andere völlig belanglos.
Für Anwendungen, wo viel gerechnet werden muß, sind 32Bit Register eine 
Wohltat. Die braucht man aber überhaupt nicht, um ein paar IO-Pins 
wackeln zu lassen. Ganz zu schweigen von einem 4GB IO-Adressraum, wie er 
an anderer Stelle vor ein paar Tagen erwähnt wurde.

Um auf den Titel zurückzukommen: Atmel hat jetzt einen Cortex-M0+ im 
Angebot. Das ist ja schön, läßt mich aber völlig kalt.
Und aus Erfahrung gefragt: Können sie überhaupt liefern? Wenn nicht, 
wann denn? Und kontinuierlich oder mal für eine halbes Jahr kein 
einziges Stück?
Der Punkt fehlt in der obigen Auflistung: Verfügbarkeit :-)

M. N. schrieb:
> Das ist eine gewagte Aussage. Hast Du Zahlen, dies zu belegen?
> Wer ist denn die "Industrie"? Ein homogener Haufen, der irgendwelchen
> Maktprognosen-Gurus hinterherläuft? Das glaube ich nicht!

Natürlich gibt es unendlich viele Anwendungen und Nischen, in denen 
andere Lösungen sinnvoll sind. Ich spreche hauptsächlich von Automotive, 
Consumer und Industrieanwendungen. In den meisten Anwendungen haben dort 
32-Bit-uC die Nase vorne. Für Neuentwicklung versteht sich, es wird 
natürlich auch noch in vielen Jahren Altsysteme mit 8-Bit-uC geben (das 
ist wohl der Hauptgrund, wieso es noch recht viele 8051er gibt).

Marktprognosen interessiert keinen profesionellen Ingenieur. Es geht 
rein um die technische Weiterentwicklung. Die Cortex M sind eben heute 
in vielerlei Hinsicht das Maß der Dinge.

M. N. schrieb:
> Ich sehe auch einen Unterschied, ob jemand in Stückzahlen Autos,
> Telefone, Fernseher oder Staubsauger herstellt. Gerade bei
> consumer-Elektronik ist es doch mit Qualität und Wartbarkeit eh nicht
> weit her.

Wenn es um den Preis geht, sind die ARM-uC weit vorne. Heute bekommt man 
einen Cortex M4 für einen Preis, für den man vor vier Jahren gerade mal 
einen größeren Atmega oder MSP430 bekommen hat. Und wirklich billiger 
geworden sind die auch nicht.

M. N. schrieb:
> Wer einen 8051 in der Muttermilch
> hatte, dem wird er weiterhin gut schmecken :-)

Professionelle Ingenieure müssen anders denken. Da geht es um harte 
Fakten, nicht um Vorlieben und Gefühle.

M. N. schrieb:
> Und aus Erfahrung gefragt: Können sie überhaupt liefern? Wenn nicht,
> wann denn? Und kontinuierlich oder mal für eine halbes Jahr kein
> einziges Stück?

Atmel hat sich in dieser Hinsicht in den letzten Jahren massiv 
verbessert.

8-Bit schrieb:

> M. N. schrieb:
>> Und aus Erfahrung gefragt: Können sie überhaupt liefern? Wenn nicht,
>> wann denn? Und kontinuierlich oder mal für eine halbes Jahr kein
>> einziges Stück?
>
> Atmel hat sich in dieser Hinsicht in den letzten Jahren massiv
> verbessert.

Du reihst Behauptung an Behauptung. Kannst du wenigstens diese belegen.

Lohnt es sich denn überhaupt noch sich mit zb.8Bit AVR zubeschäftigen,
Denn wenn ich mir ansehe was ein Atmega128 kostet kriegt ich fast zum 
gleichen
Preis ein STM32F103ZET6

>Wenn es um den Preis geht, sind die ARM-uC weit vorne.
Das sind nicht die Einzigsten, die günstig sind.

>Ich spreche hauptsächlich von Automotive,
>Consumer und Industrieanwendungen.
AchNe. Also gehen alle 8Biter zu den Hobbyisten?

>In den meisten Anwendungen haben dort
>32-Bit-uC die Nase vorne.
Keineswegs.

>Professionelle Ingenieure müssen anders denken. Da geht es um harte
>Fakten, nicht um Vorlieben und Gefühle.
Jo. Und das Beste wird genommen.
Und das ist noch lange nicht immer ARM.


>Hoffentlich bleibt eine Vielzahl diverser Architekturen noch lange
>erhalten.
Mit Sicherheit.
Denn es gibt viel zu viele Anwendungen, als dass da nur eine Archit. 
Platz finden sollte.

Davis schrieb:
> Du reihst Behauptung an Behauptung. Kannst du wenigstens diese belegen.

Tut mir leid, geht nicht - NDA sei Dank.

MCUA schrieb:
> Das sind nicht die Einzigsten, die günstig sind.

Ja, andere 32-Bit-uC, zum Beispiel von TI, sind teilweise auch sehr 
günstig.

MCUA schrieb:
> AchNe. Also gehen alle 8Biter zu den Hobbyisten?

Wie gesagt - Altsysteme. Vor zwei/drei Jahren war die Situation noch 
ganz anders.

MCUA schrieb:
> Jo. Und das Beste wird genommen.
> Und das ist noch lange nicht immer ARM.

Aber immer öfter.

8-Bit schrieb:
> M. N. schrieb:
>> Wer einen 8051 in der Muttermilch
>> hatte, dem wird er weiterhin gut schmecken :-)
>
> Professionelle Ingenieure müssen anders denken. Da geht es um harte
> Fakten, nicht um Vorlieben und Gefühle.

Ach, wenn das so wäre, gäbe es keine Promo-Boards zum 'Anfüttern'. Würde 
ein STM32F407-Discovery-Board € 395,-- netto kosten, wäre es hier nie 
erwähnt worden und nicht bei mir auf dem Tisch gelandet. Allein die 
Lektüre des Datenblattes würde mir zum Schnuppern nicht reichen, auch 
wenn die dortigen Zahlen gut aussehen (und die Errata ganz woanders 
stehen).
Aber gut, ich bin ja kein professioneller Ingenieur, ich verdiene nur 
mein Geld mit dem Kram, von dem ich erwarte, dass er mir auch noch Spaß 
macht.


8-Bit schrieb:
> Davis schrieb:
>> Du reihst Behauptung an Behauptung. Kannst du wenigstens diese belegen.
>
> Tut mir leid, geht nicht - NDA sei Dank.

Wessen NDA? Oder NSA?
Mir kommt das Alles etwas vor, wie das Hochjubeln von Aktien. Wenn sie 
am nächsten Tag ins Bodenlose gefallen sind, kommt der nächste Experte, 
der das schon immer vorausgesagt hat.

M. N. schrieb:
> Ach, wenn das so wäre, gäbe es keine Promo-Boards zum 'Anfüttern'. Würde
> ein STM32F407-Discovery-Board € 395,-- netto kosten, wäre es hier nie
> erwähnt worden und nicht bei mir auf dem Tisch gelandet.

Die Verfügbarkeit von Entwicklungstools spielt natürlich eine gewisse 
Rolle. Und gerade bei Konzernen ist es einfacher, wenn man sich vom FAE 
ein paar Low-Cost-Eval-Kits kostenlos zuschicken lassen kann. Und 
natürlich spielt es bei gleichwertigen Produkten eine Rolle, ob man 
vielleicht als Student oder privat schon einmal mit dem ein oder anderen 
Baustein gearbeitet hat.

M. N. schrieb:
> Wessen NDA?

Wenn du deine Brötchen mit Entwicklung verdienst, solltest du eigentlich 
wissen, dass du Firmengeheimnisse nicht ausplaudern darfst. Aber du bist 
ja nur Bastler, wie du ja selbst sagst, da kannst du so etwas natürlich 
nicht wissen.

>> Du reihst Behauptung an Behauptung. Kannst du wenigstens diese belegen.
> Tut mir leid, geht nicht - NDA sei Dank.
Totaler Humbug.
Etwaige NDA-Kenntnisse haben nichts mit Markt-Kenntnissen zu tun.
Und wenn man eine F-i-r-m-a kennt, kennt man den M-a-r-k-t noch lange 
nicht!

MCUA schrieb:
> Totaler Humbug.
> Etwaige NDA-Kenntnisse haben nichts mit Markt-Kenntnissen zu tun.
> Und wenn man eine F-i-r-m-a kennt, kennt man den M-a-r-k-t noch lange
> nicht!

Also nochmal langsam. Es ging darum, dass jemand nach Belegen für das 
Lieferverhalten einer Firma fragt. Diese Belege kann ich nicht 
herausrücken, ohne Firmengeheimnisse zu verraten. Dazu gehören nämlich 
nicht nur technische Infos, sondern auch konkrete Angaben über 
Lieferzeiten, Stückzahlen, Preise, Abkündigungen (diese werden den 
großen Kunden nämlich schon viel früher mitgeteilt) usw.

Ich kann nur sagen, dass sich Atmel in dieser Hinsicht in den letzten 
zehn Jahren massiv gebessert hat, weil sie bei einigen großen Kunden 
Probleme bekommen haben.

8-Bit schrieb:
> Also nochmal langsam. Es ging darum, dass jemand nach Belegen für das
> Lieferverhalten einer Firma fragt.

Da hat sich etwas missverständlich entwickelt. Als Bastler ist mir Atmel 
im Grunde doch Schnuppe. Mir ging es um diese (Markt) Aussagen:

8-Bit schrieb:
> Es steht natürlich jedem frei, eigene Architekturen auf den Markt zu
> bringen und damit erfolgreich zu sein. Nur im Moment sieht es eben so
> aus, als würde sich ARM durchsetzen. Die 8-Bit-Architekturen werden
> jedenfalls nicht in der heutigen Breite überleben und eine wirkliche
> Konkurrenz für die Cortex M gibt es auch noch nicht.
> ...
> Heutzutage
> setzt mal lieber auf einen stärkeren Core (eben z.B. einem Cortex M) und
> verwendet Standardbibliotheken. Time-To-Market wird heutzutage vielmals
> höher bewertet als Kostenoptimierung auf den letzten Cent. Wobei die
> Cortex-M ja sogar Kostenvorteile bieten.

Das ist doch weichgespültes Marktgeschreie - konkrete Angaben bleiben 
aus! Und wenn Jemand Zahlen dazu liefert, möchte ich auch gerne wissen, 
von wem er bezahlt wird und welche Aktien er im Depot hat.

Du scheinst nur Cortex-M zu kennen, die auch ihre Schwächen haben. 
Diskussionen darüber gab es schon vor längerer Zeit.

Ich muß aber noch einmal hierauf zurückkommen:
8-Bit schrieb:
> Professionelle Ingenieure müssen anders denken. Da geht es um harte
> Fakten, nicht um Vorlieben und Gefühle.

Dabei fällt mir unweigerlich BER ein. Knallharte Profis basteln 
Milliarden in den Brandenburger Sand.

Jörg Wunsch schrieb:
> Aber s. o., batteriebetriebene Geräte verbrauchen oft nach meinen
> Erfahrungen einen nicht zu unterschätzenden Teil ihrer Energie in
> der Schlafphase. Die paar Dhrystones interessieren dort überhaupt
> nicht :), und man muss die Hardware insgesamt optimieren. Mit ihren
> kleinen Strukturgrößen haben die ARMs hier einen systembedingten
> Nachteil aufgrund ihrer viel größeren Leckströme, den sie nun durch
> technische Tricks erst allmählich wettmachen können. (Energymicro
> dürften die ersten gewesen sein, die in dieser Richtung was hatten.)

Hi Jörg, kann ich nur bestätigen! In diesem Feld hat sich der Tiny Gecko 
als sehr sparsam erwiesen. Ich kann viele Funktionen mit nur 1-2µA 
durchführen und dank eines Event Systems (bei Energy Micro heißt es PRS) 
Ablaufsteuerungen in den Deep Sleep Mode verlagern.
Aber dennoch: Ich kann sehr schön die Libs verwenden und in C 
programmieren ohne mir die Finger krumm zu programmieren und bekomme 
mehr Leistung zu weniger Energie. Das möchte ich nicht mehr vermissen.

So, nun reicht's für diesen Thread, der eher esoterisch wird. Es 
scheinen sich hier eher die Marketing-Heinis der Hersteller auszuweinen. 
Ich dachte das Forum ist für Bastler und Tüftler.

Mit diesen Worten eines knallharten Bastlers ... :-)

Schönes Wochenende!

M. N. schrieb:
> Das ist doch weichgespültes Marktgeschreie - konkrete Angaben bleiben
> aus! Und wenn Jemand Zahlen dazu liefert, möchte ich auch gerne wissen,
> von wem er bezahlt wird und welche Aktien er im Depot hat.

Ich hatte mal Aktien von Atmel, Infineon und TI. ARM hatte ich noch 
nicht, darüber ärgere ich mich jetzt. Ansonsten sitze ich auf 
Kundenseite und setze dabei unter anderen Atmel, Microchip, TI und 
Renesas ein. Wie du dir denken kannst, waren da nicht nur 
ARM-Prozessoren dabei.

Ich kann dir nur sagen, dass wir für Neuprojekte Angebote von 
verschiedensten Prozessoren verglichen haben und die neueren 32-Bit-uC 
hatten preislich immer die Nase vorne. Im Low-Cost-Bereich (ab 30-50 
Cent) ist der Cortex M0 fast unschlagbar. Der M4 hat noch mehr 
Konkurrenz, zum Beispiel durch den C2000. Dabei ging es um 5-6stellige 
Stückzahlen. Für einen Bastler ist das logischerweise weniger relevant, 
dem ist im Endeffekt egal, ob der Chip jetzt 1 oder 5 Euro kostet.

Und ich kann dir sagen, wie wir bei solchen Stückzahlen in der 
Entwicklung vorgehen. Wir haben zum Beispiel eine Anwendung, ganz 
einfaches Datenhandling, ein paar ADC-Kanäle auslesen, kleine Umrechnung 
und über die serielle Schnittstelle verteilen. So etwas kann jeder 
8-Bit-AVR problemlos. Wir setzen dort trotzdem einen 32-Bit-uC ein, weil 
wir damit auf die gleiche Softwareplattform einsetzen können, die wir 
auch für unsere größeren Anwendungen verwenden. Dadurch entfällt nicht 
nur Entwicklungs-, sondern vor allem Doku- und Testaufwand. Insgesamt 
etwa 2 Mannmonate. Und dabei ist der Prozessor sogar noch günstiger als 
die üblichen 8-Bit-AVR, dir wir sonst teilweise im Einsatz hatten.

Das war jetzt mal ein Beispiel, aber wir sind ja ständig mit den FAE der 
Hersteller in Kontakt und die plaudern auch mal aus dem Nähkästchen. Und 
da hört man auch etwas heraus, wie andere Firmen unterwegs sind. Und es 
sieht wohl so aus, als wären wir nicht die einzigen, die so arbeiten.

Vermutlich ist das jetzt auch für dich wieder nur "weichgespültes 
Marketinggeschrei", weil es nicht so ganz in dein Weltbild hineinpasst. 
Aber da kann ich dir jetzt auch nicht mehr helfen.

Im Automotive-Bereich gibt es noch andere Andorderungen z.B. an die 
Robustheit.
Da spielt der Temperaturbreich, EMV-Festigkeit und Flash-Lebensdauer ein 
Rolle. Also kurz: wie zuverlässig ist der Controller über Lebendauer. Da 
können Argumente wie größere Rechenleistung zu gleichem Preis schnell in 
den Hintergrund geraten.

8-Bit schrieb:
> Vermutlich ist das jetzt auch für dich wieder nur "weichgespültes
> Marketinggeschrei", weil es nicht so ganz in dein Weltbild hineinpasst.

Im Gegenteil, ich freue mich über Deine konkreten, konstruktiven 
Aussagen. Ich mag es nur nicht, wenn Leute vorgeben wollen, wohin der 
Hase läuft und alle hinterherlaufen sollen.

Meine Stückzahlen liegen nur im dreistelligen Bereich, daher ist der 
Einzelpreis nicht so entscheidend.
Vielleicht kennst Du ja die RX6x und die STM32F4xx. Letzterer ist schön 
schnell, aber Ersterer zehnmal 'schöner' zu programmieren. Mal sehen, 
wie ich mich entscheiden werde.

8-Bit schrieb:
> Im Low-Cost-Bereich (ab 30-50
> Cent) ist der Cortex M0 fast unschlagbar.

Dieses Teil, zu dem Preis, in einem TQFP32/48, dass man auch alle 
Interna nutzen kann: da bin ich dabei :-)

Chris D. schrieb:
> Das ist für mich der Hauptgrund gewesen, jetzt für Neuentwicklungen
> komplett auf 32 Bit (und da die STM32) zu gehen: man hat nur noch eine
> Plattform, die leistungsmäßig eben einen deutlich größeren Bereich
> abdeckt als bspw. die AVR-Serie.

Genau das meinte ich damit.

chris schrieb:
> Im Automotive-Bereich gibt es noch andere Andorderungen z.B. an die
> Robustheit.
> Da spielt der Temperaturbreich, EMV-Festigkeit und Flash-Lebensdauer ein
> Rolle. Also kurz: wie zuverlässig ist der Controller über Lebendauer. Da
> können Argumente wie größere Rechenleistung zu gleichem Preis schnell in
> den Hintergrund geraten.

Richtig. Mit ARM ist man an sich da nicht falsch unterwegs, schließlich 
sind bei den Cortex M doch sehr viele Erfahrungen aus dem sehr bewährten 
ARM7 eingeflossen. Es hängt dann eher von der Implementation und der 
Umgebung ab. Gerade die von dir erwähnten Punkte hängen eher an der 
Technologie, nicht an der Architektur des Rechenkerns.

M. N. schrieb:
> Im Gegenteil, ich freue mich über Deine konkreten, konstruktiven
> Aussagen. Ich mag es nur nicht, wenn Leute vorgeben wollen, wohin der
> Hase läuft und alle hinterherlaufen sollen.

Ich habe mit keinem Wort geschrieben, dass sich jemand nach meinen 
Aussagen richten muss. Ich habe lediglich eine Beobachtung beschrieben. 
Mag sein, dass das falsch ankam, aber das liegt auch an der 
Interpretation des Lesers.

M. N. schrieb:
> Dieses Teil, zu dem Preis, in einem TQFP32/48, dass man auch alle
> Interna nutzen kann: da bin ich dabei :-)

Gibt es, aber eben erst bei entsprechenden Stückzahlen.

Mal ein Beispiel:
Beim Übergang von MEGA auf den XMEGA ist es pi mal daumen beim gleichen 
Kern, aber leider komplett neue Onchip-Peripherie. Das war so als ob man 
einen komplett neuen Controller vor sich hatte (trotz IDE). IHMO ist 
beim Wechsel oft die OnChip-Peripherie das Problem. Sogar innerhalb der 
"Familie" bzw. des Kerns.

Natürlich würde auch die MCU-Linie nehmen, die meine Anwendungen am 
besten abdecken. Für den einen sind es ARM, für den anderen MSP, der 
nächste nimmt 8051...

Alle schreien ARM, aber clevere Entwickler gehen Hybrid und nutzen ARM 
UND AVR ;-)

http://www.kickstarter.com/projects/secretlabs/agent-the-worlds-smartest-watch

Wenn ich mich nicht täusche ist es ein tiny1634.

So jetzt mal meine Fragen:
- Warum nicht diese olle TinyGecko Familie?
- Warum überhaupt Hybrid und nicht EnergyMicro die ja so 
energieeffizient sein sollen?
- Warum wurde kein CortexM0(+) genommen, dann hätte man ja eine 
Toolchain nutzen können

Ich stell mal meine Behauptungen und Fragen auf:
- EM sei gar nicht so stromsparend wie der Name suggeriren soll
- Der Preis ob ein Cortex günstiger als ein AVR ist sei reine 
Verhandlungssache und vom Geschick des Einkäufers abhängig
- Wenn man einen AVR zum Mercedes-Preis verkaufen kann, warum soll man 
dann den Preis halbieren und zum CortexM0 Preis verkaufen? 
Offensichtlich ist einigen vielen Leuten der Preis wert
- Den End-Preis bestimmen die Distributoren, wenn sie ein Produkt teurer 
verkaufen können dann ist es ok. Offensichtlich lässt sich der Cortex 
lediglich über den Preis den Kunden schmackhaft machen, wäre der Preis 
dem AVR gleich, würden wohl mehrere beim AVR bleiben. Offensichtlich 
gibt es doch nicht genug Vorteile um den Cortex gut verkaufen zu können.
- Warum verkauft ein Produzent A z.b. einen AVR für 2.5Euro, wobei man 
bei einigen Konkurrenten (laut Marketing) mehr Leistung, 32Bit zum 
halben Preis bekommt? Warum hat man den Cortex, der ja 4x soviele Bits 
hat wie ein AVR (ich sag jetzt auch mal wie ein PIC oder ähnliche, damit 
es hier nicht so einschlägig wird ;-)), viel mehr MHz aufweist, nicht 
z.b. 4x teurer verkauft? Oder zumindest den Preis dem AVR 
gleichgestellt? Warum muß man den Preis den so niedrig ansetzen um 
überhaupt was verkaufen zu können? Taugt der Cortex doch nicht so wie 
ARM marketing es allen andrehen will?

Schon interessant oder? Warum verlieren die anderen Produzenten (ok 
Atmel hat jetzt auch einen Cortex der die 8Bitter ersetzen soll) 
freiwillig Geld? Wenn ich ein Produkt hätte, z.b. ein VW Golf der 7Liter 
verbraucht, und dieser 30000Euro kostet, und nun bringt ein Konkurrent 
eine Alternative zum Golf raus der nur noch 3.5Liter verbraucht, viel 
schneller fährt und mehr Zylinder hat (Bits), ja warum muß dieser 
Produzent dann noch den Preis auf 15000Euro setzen um dieses Fahrzeug 
verkaufen zu können?
Und warum kaufen dann Leute immer noch den Golf?

fragen über fragen, aber ich hab grad ne Flasche Wein auf ;-)

Matthias schrieb:
> gibt es doch nicht genug Vorteile um den Cortex gut verkaufen zu können.
> - Warum verkauft ein Produzent A z.b. einen AVR für 2.5Euro, wobei man
> bei einigen Konkurrenten (laut Marketing) mehr Leistung, 32Bit zum
> halben Preis bekommt?

Ganz einfach: Er wird ihn bald nicht mehr verkaufen - zumindest nicht 
für Neuprojekte. Es gibt aber genug Altprodukte, die logischerweise 
nicht mehr auf eine neue Architektur umgestellt werden können. Aber mit 
diesen Altprojekten wird auch die alte, teure Architektur (bzw. 
Technologie) aussterben.

Matthias schrieb:
> Warum muß man den Preis den so niedrig ansetzen um
> überhaupt was verkaufen zu können? Taugt der Cortex doch nicht so wie
> ARM marketing es allen andrehen will?

Den ARM kann man aufgrund der neueren Fertigungsprozesse viel billiger 
produzieren. Der Rest ist reines Gesetz des Marktes: Es gibt viel 
Konkurrenz und ein wichtiges Kriterium ist der Preis, besonders wenn man 
sich nicht mehr technisch hervorheben kann. Bei Low-Cost-uC ist das eben 
der Fall. Das ist im übrigen eine fast lehrbuchreife 
Penetrationsstrategie.

Matthias schrieb:
> ja warum muß dieser
> Produzent dann noch den Preis auf 15000Euro setzen um dieses Fahrzeug
> verkaufen zu können?

Weil es nicht nur einen Konkurrenten gibt, sondern viele. Sie 
konkurrieren schon lange nicht mehr mit dem Golf mit 7 Liter Verbrauch, 
sondern untereinander.

Matthias schrieb:
> Und warum kaufen dann Leute immer noch den Golf?

Hier hinkt der Vergleich. Wie erwähnt handelt es sich dabei meistens 
noch um Altprojekte, die entweder schon weit im Produktlebenszyklus 
stehen oder noch auf einer alten Softwareplattform basieren, die nicht 
mehr portiert werden soll. Das ist ein Prozess, der sich über Jahrzehnte 
zieht. Er hat aber erst vor etwa ein bis zwei Jahren begonnen. Wir 
stehen also noch ganz am Anfang, und deshalb kaufen natürlich noch viele 
die alten Prozessoren für einen teuren Preis.

Preisfrage: Wann verlangen diese Vorschriften tatsächlich eine 
zertifizierte Toolchain? Also wirklich zwingend verlangen, nicht nur 
empfehlen. Letzeres wird in quasi jeder Norm gemacht, man kann es aber 
auch quasi immer durch andere Methoden umgehen.

Chris D. schrieb:
> Das ist für mich der Hauptgrund gewesen, jetzt für Neuentwicklungen
> komplett auf 32 Bit (und da die STM32) zu gehen: man hat nur noch eine
> Plattform, die leistungsmäßig eben einen deutlich größeren Bereich
> abdeckt als bspw. die AVR-Serie.

Mich würde interessieren, mit welchen µCs Du zuvor gearbeitet hast, und 
ob diese mit ihrer Leistung nicht sowieso schon am Anschlag waren. Nur 
AVR?
Setzt Du auch die 'kleineren Brüder' STM32F051 ein?

Arc Net schrieb:
> Freescale MKL05Z8VLC4 liegt bei 250 Stück bei ~ 0,74 € (Digi Key)

Die gefallen mir nicht so recht. Auch wird wieder deutlich, das ARM nur 
der Kern ist, die Peripherie hängt wieder ganz von den Vorlieben (und 
der µC-Entwicklungsgeschichte) des jeweiligen Herstellers ab. Wenn man 
auf der einen Seite mit STM32 arbeitet und dann beispielsweise mit 
obigen Freescale-Typen, ist es mit gemeinsamen, erprobten Bibliotheken 
wieder Essig.

Um noch einmal auf die oben angesprochene 5V-Fähigkeit zu kommen: sobald 
im System MOSFETs, Motortreiber (L6203), o.ä. direkt angesteuert werden 
sollen/müssen, kann man dies mit 5V-µCs (AVR) sehr einfach erledigen.
Auch aus diesem Grund sind für mich die Cortex-M0 noch nicht so zündend, 
obwohl die Interrupt-Prioritäten schon ihren Reiz haben ...

Andreas H. schrieb:
> Wenn Du aber z.B. bei einem Medizingerät in den USA einen Case hast,
> dann musst DU nachweisen, dass Du nach dem aktuellen Stand der Technik
> gearbeitet hast. Und das schliesst z.B. auch ein, dass Du Dich
> bestmöglichst von der Brauchbarkeit Deiner Werkzeuge überzeugt hast.
> Und wie machst Du das ? Z.B. Indem Du Compiler benutzt, die von einer
> "fachkundigen Stelle" zertifiziert sind.

Das ist eine Möglichkeit, aber nicht die einzige und auch nicht in allen 
Fällen die beste. In den Normen EN61508 und DO178B sind jedenfalls 
alternative Wege vorgesehen, gerade weil auch den Gremien bekannt ist, 
dass man einen Compiler nicht so einfach mal zertifiziert.

Mal davon abgesehen, dass es durchaus Toolchains für Cortex M und Cortex 
R gibt, die für EN61508 oder DO178B vorgesehen sind.

Ich kann dir mal meine Erfahrungen mit der EN61508 (bis SIL3) mitteilen. 
Bei anderen Normen sieht es wohl ähnlich aus. Zumindest hat das eine 
kurze Recherche ergeben.

Wie gesagt, es gibt keine harte Forderung: "Du darfst nur einen 
zertifizierten Compiler nutzen." Solche harten Forderungen gibt es im 
Übrigen nur ganz selten; es gibt eigentlich immer einen gewissen 
Interpretationsspielraum. Und die Verwendung eines zertifizierten 
Compiler macht den Zertifizierungsprozess auch nicht wesentlich 
einfacher. Da spielen einfach zu viele andere Faktoren eine Rolle.

Zunächst einmal wird das Gesamtprodukt und der Entwicklungsprozess 
bewertet. Dabei ist der Einsatz der Tools nur eine kleine Facette. Viel 
wichtiger sind die Nachvollziehbarkeit der angewendeten 
Entwicklungsprozesse, eine saubere Dokumentation und vernünftig gewählte 
Testverfahren. Die Einhaltung von Coderichtlinien (Stichwort MISRA-C) 
sind auch wichtig.

Da gibt es dann noch die Bewährtheit. Es ist sehr vorteilhaft, wenn man 
mit einem Tool seit Jahren arbeitet. Man verwendet besser etwas 
bewährtes als auf einen unbekanntes Tool umzusteigen, nur weil es 
zertifiziert ist.

Tests habe ich schon erwähnt - man kann davon ausgehen, dass bei einer 
ausreichenden Testabdeckung einen Großteil der durch Compilerfehler 
entstehenden Probleme aufdecken kann.

Außerdem ist auch den Zertifizierungsgesellschaften klar, dass auch ein 
zertifiziertes Tool niemals komplett fehlerfrei sein kann. Und es gibt 
selbstverständlich auch systemaische Fehler, die nicht auf das Tool 
zurückzuführen sind. Außerdem gibt es ja auch zufällige Fehler 
(Soft-Error sagt dir sicherlich etwas). Deshalb muss man von Anfang an 
ein fehlertolerantes System entwickeln. Und man geht davon aus, dass ein 
solches System auch gegenüber Compilerfehler in einem ausreichenden Maße 
geschützt ist.

hallo,
damit dieser thread nich noch weiter von eigentlichen Thema abdriftet 
ein paar themenspezifische infos:

es gibt eine neue revision des datenblatts:
-) neues kapitel SAM D20 Schematic Checklist (beinhaltet auch die 
anschaltung der oszillatoren
-) div fehlerbehebungen/ergänzungen

allerdings fehlen immer noch die ac/dc characteristics.

gruss
gerhard

Andreas H. schrieb:
> 8-Bit schrieb:
>> In den Normen EN61508 und DO178B sind jedenfalls
>> alternative Wege vorgesehen, gerade weil auch den Gremien bekannt ist,
>> dass man einen Compiler nicht so einfach mal zertifiziert.
>
> Oh, das ist interessant. Hast Du da zufällig ein Beispiel parat ?
> Vielleicht wäre sowas bei uns ja auch anwendbar.
>
> Grüße
> Andreas
>
> P.S.: Du meinst aber DO178C, oder (die B ist outdated afaik) ?
>       A.

Kurz dazu:

- Im Zusammenhang mit der DO-178B existiert der Begriff 
Tool-Zertifizierung nicht. Man spricht dort von Tool-Qualification.

- Ex existieren keine Compiler, die im Sinne der 
DO-178B/Development-Tool- qualifizierbar wären. Es ist nicht möglich, 
ein komplexes Tool wie einen Compiler zu qualifizieren. Die Korrektheit 
des Compiler muss per Verifikation der erzeugten Artefakte nachgewiesen 
werden.

- Es gibt bereits eine DO-178C. Damit wird aber nicht automatisch die 
DO-178B ungültig/veraltet. Welche Version anzuwenden ist, bestimmt 
jeweils der übergeordnete System-Entwicklungsprozess (vereinfacht 
gesagt).

- Das Thema Tool-Qualification wurde in der DO-178C ausgelagert und in 
der DO-330 beschrieben

MISRA-C ist lediglich ein Codestandard. Ein Codestandard ist nur ein 
ganz kleiner Teil, der beispielsweise für DO178B (und bei anderen 
Normen, usw..) relevant ist.

Eine Zertifizierung nach "MISRA-C" gibt es nicht. Alleine die Aussage, 
ein Compiler sei nach MISRA-C zertifiziert, ergibt keinen Sinn.

Ein Compiler kann den Entwickler maximal bei der Einhaltung des MISRA-C 
unterstützen.

Für den Gesamtentwicklungsprozess ist damit nur ein kleiner (und der 
einfachste) Teil abgedeckt.

Andreas H. schrieb:
> EFA schrieb:
>> Ex existieren keine Compiler, die im Sinne der
>> DO-178B/Development-Tool- qualifizierbar wären. Es ist nicht möglich,
>> ein komplexes Tool wie einen Compiler zu qualifizieren.
>
> Sehe ich eigentlich genau so. Von unseren SW-Devs wurde mir das dann
> aber anders erklärt. Da werde ich mal nachhaken.
>
> Danke für die Infos :-)
>
> Grüße
> Andreas

Schick mir mal die Anschrift, dann gibts ein Q-Audit nach 
EN9100/AQAP2210 :)

Arc Net schrieb:
> EFA schrieb:
>> - Ex existieren keine Compiler, die im Sinne der
>> DO-178B/Development-Tool- qualifizierbar wären. Es ist nicht möglich,
>> ein komplexes Tool wie einen Compiler zu qualifizieren. Die Korrektheit
>> des Compiler muss per Verifikation der erzeugten Artefakte nachgewiesen
>> werden.
>
> Etwas weiter ist das Gebiet schon.
> http://compcert.inria.fr/ (formal verifizierte Compiler)
> und der bislang einzige formal verifizierte Kernel seL4
> 
http://www.ok-labs.com/whitepapers/sample/sel4-formal-verification-of-an-os-kernel

Formale verifikation ist nur eine Möglichkeit der Verifikation. Bei dem 
zweiten Link handelt es sich um einem Microkernel. Das ist nichts neues, 
zertifizierte OS/Kernel gibt es reichlich. Welche Verifikationsmethoden 
zur Anwendung kommen ist der Behörde egal (vereinfacht gesagt).

Bei dem Compiler (erster Link) handelt es sich um einen Compiler, bei 
dem gewisse Verifikationsaktivitäten durch formale Verifikation 
durchgeführt wurden. Von einer Zertifizierung oder Qualifizierung nach 
DO-178B ist das noch weit entfernt.

Arc Net schrieb:
> EFA schrieb:
>> Bei dem
>> zweiten Link handelt es sich um einem Microkernel. Das ist nichts neues,
>> zertifizierte OS/Kernel gibt es reichlich.
>
> seL4 ist der einzige formal verifizierte Kernel, d.h. div. Eigenschaften
> sind mathematisch bewiesen, das ist ein gewaltiger Unterschied zu einer
> wie auch immer gearteten Zertifizierung.
> Ähnliches gilt für den CompCert.

Das interessiert eine Certification Authority aber reichlich wenig. Auf 
den Seiten steht nichtmal, wie die Certification Baseline definiert ist. 
Das reicht schon als Aussage, dass es sich bei den Themen eher um 
akademische Projekte ohne praktische Relevanz handelt.

Für eine Zertifizierung, beispielsweise in der Luftfahrt, reich es nicht 
zu sagen "formal verifiziert" oder "mathematisch bewiesen". Dort 
schreibt die Certification Authority den Standard vor, nach dem zu 
zertifizieren ist.

Die Aussage "foraml zertifiziert" is zulassungstechnisch ohne Kontext 
erstmal belanglos.

Was nicht heissen soll dass es nicht etwas über die Qualität der 
Software aussagt.

8-Bit schrieb:

> - 8-Bitter sterben aus. Sie werden vom Cortex M0 verdrängt.

Diesen Trend kann ich absolut nicht erkennen. Mal ganz davon abgesehen, 
daß es in einer riesengroßen Zahl von Anwendungen rein um 
Bitmanipulationen geht und somit die Verarbeitungsbreite sowieso völlig 
Wurscht ist.

Viele Bits Verarbeitungsbreite blähen im Minimum zuverlässig den Code 
auf, erfordern deshalb mehr Speicher dafür. Soll der Code dadurch nicht 
schweinelangsam abgearbeitet werden, sind auch breitere Busse nötig. Das 
erhöht die Zahl der Pins, die Zahl der Layer, senkt die Ausbeute in der 
Fertigung auf allen Ebenen.

Sprich: Höhere Verarbeitungsbreiten sind nur dort sinnvoll, wo sie neben 
diesen ganzen Nachteilen auch irgendeinen Vorteil bescheren...

Wenn es denn bei reiner Bitmanipulation bleiben würde, wäre das 
vielleicht sogar richtig. Meistens spielt aber zumindest mal ein ADC mit 
oder es ist eine kleine Umrechnung notwendig. Oder man nutzt Timer mit 
16 oder 32 Bit. In all diesen Anwendung ist ein 32Bit-CPU schon 
vorteilhaft.

Dass die Codegröße bei 32-Bit ansteigt ist ein Mythos. In den meisten 
Fällen ist sie sogar geringer. Thumb-Code ist schon sehr effizient.

Die neuen 32-Bit-uC werden in einer viel moderneren Technologie 
gefertigt. Somit sind breitere Busse überhaupt kein Thema. Wieso sollte 
die Anzahl der Pins oder Layer steigen? Es gibt Cortex M0+ mit 8 Pin, 
und die kriegt man auch auf einer 1-Lagen-Karte zum laufen. Oder meinst 
du die Lagen auf dem Silizium? Das wird durch die neuere 
Prozesstechnologie kostentechnisch mehr als ausgeglichen.

8-Bit schrieb:

> Wenn es denn bei reiner Bitmanipulation bleiben würde, wäre das
> vielleicht sogar richtig. Meistens spielt aber zumindest mal ein ADC mit
> oder es ist eine kleine Umrechnung notwendig. Oder man nutzt Timer mit
> 16 oder 32 Bit. In all diesen Anwendung ist ein 32Bit-CPU schon
> vorteilhaft.

Nicht notwendigerweise. Wenn der 8Bitter eine 32Bit-Addition in vier 
Schritten erledigen muß, und der 32Bitter das in einer Operation 
erledigen kann, ist er trotzdem erst dann im Vorteil, wenn dieser eine 
Schritt bei gleichem Takt schneller erledigt ist als der 8Bitter seine 
vier.

Und das ist längst nicht immer der Fall...

> Dass die Codegröße bei 32-Bit ansteigt ist ein Mythos.

Nein, das liegt in der Natur der Sache. Wenn man die Möglichkeiten der 
größeren Verarbeitungsbreite wirklich nutzen will, braucht man mehr 
Operationen und die Operationen müssen zumindest zum Teil breitere 
Operatoren verarbeiten können. Beides führt unweigerlich dazu, daß sich 
die Zahl der Instruktionen pro Byte Codegröße verringern muß. Das ist so 
logisch, daß man darüber eigentlich überhaupt nicht diskutieren müßte.

Im Vergleich zum 8Bitter eingespart werden kann hingegen nur etwas, wenn 
dessen beschränkte Verarbeitungbreite für eine Aufgabe mehr 
Instruktionen erfordert als sie bei 32Bit Verarbeitungsbreite nötig 
sind. Nur ist das eben bei den meisten µC-Anwendungen eher selten der 
Fall. Für Bitmanipulationen wird's überhaupt nicht gebraucht. Für das 
Rechnen mit geringen Genauigkeiten und kleinen Zahlen ebenfalls nicht. 
Für Stringverarbeitung allenfalls bezüglich der Zeigerarithmetik, aber 
selbst die ist meist nur 16Bit breit, nicht 32.


Im Übrigen gibt es 32Bit-µC seit mindestens 20 Jahren. Sie konnten bis 
heute nicht die 8Bitter obsolet machen. Wahrscheinlich deshalb, weil 
andere Leute ebenfalls erkannt haben, daß eine höhere 
Verarbeitungsbreite nur dann einen Vorteil bringt, wenn man sie auch 
tatsächlich benötigt.

c-hater schrieb:
> Nicht notwendigerweise. Wenn der 8Bitter eine 32Bit-Addition in vier
> Schritten erledigen muß, und der 32Bitter das in einer Operation
> erledigen kann, ist er trotzdem erst dann im Vorteil, wenn dieser eine
> Schritt bei gleichem Takt schneller erledigt ist als der 8Bitter seine
> vier.
>
> Und das ist längst nicht immer der Fall...

Doch, bei Cortex Mx im Vergleich zu allen 8-Bittern ist das sehr wohl 
der Fall!

c-hater schrieb:
> Nein, das liegt in der Natur der Sache. Wenn man die Möglichkeiten der
> größeren Verarbeitungsbreite wirklich nutzen will, braucht man mehr
> Operationen und die Operationen müssen zumindest zum Teil breitere
> Operatoren verarbeiten können.

ARM Cortex arbeitet mit Thumb-Code, also 16-Bit Befehlsbreite. Viele 
8-Bit-Kerne arbeiten ebenfalls mit 16-Bit-Befehlsbreite, haben also 
absolut keinen Vorteil.

c-hater schrieb:
> Im Vergleich zum 8Bitter eingespart werden kann hingegen nur etwas, wenn
> dessen beschränkte Verarbeitungbreite für eine Aufgabe mehr
> Instruktionen erfordert als sie bei 32Bit Verarbeitungsbreite nötig
> sind.

Und das ist fast immer der Fall. Sobald du einen ADC hast (mindestens 10 
Bit Auflösung sind absolut üblich), arbeitest du mit 16-Bit-Werten. Mit 
8-Bit-Timern arbeitet auch kein Mensch mehr, selbst bei einfachen PWM 
möchte man schon mindestens 10-12-Bit Auflösung haben. Die Anwendungen, 
in denen du ausschließlich mit 8 Bit auskommst, kannst du an einer Hand 
abzählen.

c-hater schrieb:
> Für das
> Rechnen mit geringen Genauigkeiten und kleinen Zahlen ebenfalls nicht.

Mir ist ehrlich gesagt noch keine einzige Anwendung untergekommen, bei 
der ich mit 8-Bit-Zahlen ausgekommen bin. Und selbst wenn: Eine einzige 
simple Multiplikation, und dein 8-Bit-Kern verliert meilenweit gegen 
einen modernen Cortex M-Kern.

c-hater schrieb:
> Für Stringverarbeitung allenfalls bezüglich der Zeigerarithmetik, aber
> selbst die ist meist nur 16Bit breit, nicht 32.

Das ist ein gutes Beispiel, bei dem ein 8-Bitter schon überfordert ist. 
Selbst ein 16-Bit-Adressraum ist schon problematisch, aber wer gibt sich 
heute schon mit einem Adressraum von 64 KBbyte zufrieden? Bei einem 
8-Bit-uC muss man sich schon viele umständliche Tricks einfallen lassen, 
um überhaupt einen größeren Adressraum zu ermöglichen.

Und dabei geht es noch nicht mal um Stringoperationen; jeder 
Sprungbefehl wird zum "Pain in the ass".

c-hater schrieb:
> Im Übrigen gibt es 32Bit-µC seit mindestens 20 Jahren. Sie konnten bis
> heute nicht die 8Bitter obsolet machen. Wahrscheinlich deshalb, weil
> andere Leute ebenfalls erkannt haben, daß eine höhere
> Verarbeitungsbreite nur dann einen Vorteil bringt, wenn man sie auch
> tatsächlich benötigt.

Nein, weil bisher einfach der Kern auf dem Silizium eine große Rolle 
gespielt hat und die 32-Bit-Prozessoren einfach noch zu teuer waren. 
Inzwischen ist aber die Prozesstechnologie fortgeschritten. Die 
Strukturbreiten sind so klein geworden, dass der Kern auf dem Silizium 
keinen wesentlichen Platz mehr ein nimmt. Entscheidend ist eigentlich 
nur noch die Peripherie (die IO-Ports kann man nicht kleiner machen, 
solange die IO-Spannung so hoch beibt, Analog-Peripherie kann man auch 
nicht beliebig verkleinern) und der Speicher. Letzterer wird aber durch 
die 32-Bit-uC für die meisten Anwendungen sogar besser genutzt. Außerdem 
gab es noch nicht so hoch optimierte Kerne wie der M0.

Machmal ist die Geschwindigkeit und Effizienz nicht entscheidend, 
sondern wer ist insgesamt am guenstigsten....

8-Bit schrieb:
> Mit
> 8-Bit-Timern arbeitet auch kein Mensch mehr,

8-Bit schrieb:
> Mir ist ehrlich gesagt noch keine einzige Anwendung untergekommen, bei
> der ich mit 8-Bit-Zahlen ausgekommen bin.

8-Bit schrieb:
> Selbst ein 16-Bit-Adressraum ist schon problematisch, aber wer gibt sich
> heute schon mit einem Adressraum von 64 KBbyte zufrieden?

Geht's noch oder willst Du wieder nur provozieren?

M. N. schrieb:
> Geht's noch oder willst Du wieder nur provozieren?

Du darfst gerne Gegenbeispiele nennen.

Davis schrieb im Beitrag #3231502:
> Mach dich nicht noch lächerlicher, als du ohnehin schon bist. Zu deinem
> hohlen Geschwafel - ohne Inhalt - auch noch Gegenbeispiele zu fordern -
> ist dreist & dämlich. Untermaure erst einmal deine Behauptungen mit
> Beispielen, dann sehen wir weiter.

Was hast du denn schon beigetragen, außer dumme Kommentare?

Beispiele, gerne:

LED dimmen: mit 8 Bit nicht sinnvoll, zumindest nicht für 
Beleuchtungsanwendungen.

Motorsteuerungen: Mit 8-Bit-PWM undenkbar.

Auch bei einer einfachen Frequenzmessung ist man mit 8 Bit entweder in 
der Auflösung oder in der minimal messbaren Frequenz sehr beschränkt.

Einfache Systemtimer kann man mit 8-Bit-Timer natürlich realisieren. 
Wenn man aber beispielsweise auf einem mit 16 MHz getakteten Timer einen 
100ms-Tick realisieren will, braucht man einen Prescaler von 1/1.6*10^6 
Welche Timerperipherie bietet so etwas?

Zu Berechnungen habe ich ja schon ADC genannt. Jede Anwendung, die mit 
ADC-Daten rechnet, braucht mehr als 8 Bit. Ansonsten kann ich mir beim 
besten Willen keine Berechnung vorstellen, die mit einer 8-Bit-Zahl 
bequem durchzuführen ist.

Zum Thema Adressraum: 8 Bit Adressraum - nur 255 adressierbare Adressen 
sind ja wohl absoluter Blödsinn, darüber brauchen wir wohl nicht 
diskutieren. Und selbst 16 Bit werden heutzutage schnell knapp. Da gehen 
schon eine Menge für die Peripherieregister drauf. Mehr als 32kByte 
Flash geht nicht. Natürlich reicht das für viele einfache Anwendungen 
aus, aber dann ist die Architektur absolut nicht skalierbar. Und das ist 
heutzutage eben wichtig. Vor allem wenn man diese Skalierbarkeit 
geschenkt bekommt, wie es beim M0 eben der Fall ist.

@8-Bit

Nur weil der Kern 8-Bit ist, heisst es nicht, dass da nur 8-Bit 
Peripherals verbaut; siehe AVR.

Coder schrieb:
> @8-Bit
>
> Nur weil der Kern 8-Bit ist, heisst es nicht, dass da nur 8-Bit
> Peripherals verbaut; siehe AVR.

Natürlich, aber sobald du was mit den Ergebnissen anfangen willst, musst 
du auch mit entsprechenden Bitbreiten rechnen. Und dann ist der 
8-Bit-Kern nur noch eine Krücke.

Wenn jemand die Geschwindigkeit nicht benötigt, ist die Bit-Breite 
eigentlich egal. Wichtig ist, dass der Controller das kann, was er soll. 
Das heißt insbesondere, er hat die Peripherie, die ich benötige.

Die Argumente klingen ein wenig wie die Angst-Optimierungen bei der 
C-Programmierung. Es könnte zu langsam sein...

A. K. schrieb:
> Ich beziehe das mal auf den Datenadressraum, da der Codeadressraum mit
> der Breite der Datenverarbeitung in keiner Beziehung steht.

Ach nein? Schonmal einen Sprungbefehl ausgeführt? Ja, ich weiß, es gibt 
auch relative Sprünge, aber das ist ja auch nur eine Krücke.

A. K. schrieb:
> Als die 8051er frisch waren war das für den vorgesehen Einsatzzweck
> völlig ausreichend. Verglichen mit den Adressierungskrücken in den
> Vorgängern 8048 und F8 war das direkt angenehm.

Seit der Einführung des 8051 sind schon ein paar Jährchen vergangen, die 
Anforderungen und Einsatzwecke haben sich ein ganz wenig 
weiterentwickelt. Ewig Gestrige gibt es natürlich immer.

A. K. schrieb:
> Wenn man sich für getrennte Adressräume entscheidet, dann ist auch eine
> 8-Bit Architektur vorstellbar, die 4GB Code adressieren kann. AVRs
> schaffen im Rahmen des Befehssatzes der normalen Megas immerhin schon
> einige MB.

Denkbar ist vieles. Aber inwiefern hat man dann noch einen Vorteil in 
Bezug auf Ausführungsgeschwindigkeit und Codegröße?

A. K. schrieb:
> Die Crux ist eher, dass eine Adressraumtrennung die Programmierung
> deutlich komplizierter gestaltet. Weil man bei jedem Pointer
> berücksichtigen muss, in welchen Adressraum er zeigen soll.

Genau darum geht es mir doch.

Coder schrieb:
> Wenn jemand die Geschwindigkeit nicht benötigt, ist die Bit-Breite
> eigentlich egal. Wichtig ist, dass der Controller das kann, was er soll.
> Das heißt insbesondere, er hat die Peripherie, die ich benötige.

Und er muss ein Kostenziel erreichen. In dieser Hinsicht sind Cortex M0 
ganz vorne dabei.

@8-Bit
Bedauerlicherweise ist die Welt nicht so einfach. Schau nicht nur auf 
den Silizium-Preis: I.d.R. reden wir von wenigen Cent!?! Eine bestehende 
Infrastruktur portiert man nicht mal so eben. Und das kann richtig ins 
Geld gehen, insbesondere bei Software nach EN61508.

Nicht jeder arbeitet in einer Firma, die Millionen von MCU verbaut.

Coder schrieb:
> Bedauerlicherweise ist die Welt nicht so einfach. Schau nicht nur auf
> den Silizium-Preis: I.d.R. reden wir von wenigen Cent!?! Eine bestehende
> Infrastruktur portiert man nicht mal so eben. Und das kann richtig ins
> Geld gehen, insbesondere bei Software nach EN61508.

Deshalb wird es auch noch lange 8-Bit-uC geben. Das habe ich aber weiter 
oben schon geschrieben. Ich rede ganz explizit von einem Trend bei 
Neuentwicklungen.

A. K. schrieb:
> Die in Befehlen codierte Adressbreite für Code ist von der Adressbreite
> eines getrennten Datenadressraums völlig unabhängig. Wie schon gesagt,
> die ganz normalen AVRs können von der Codierung her 8MB Code
> adressieren.

Was sich aber immer noch auf die Codedichte auswirkt.

A. K. schrieb:
> Und das gilt in beiden Richtungen. 8-Bitter mit 512KB Code sind oft
> ebenso ausserhalb ihren optimalen Einsatzspektrums wie 32-Bitter mit 4KB
> Flash und 8 Pins. Die existieren deshalb, damit man ein grosses Spektrum
> abdecken kann, ohne Werkzeuge und Erfahrung auswechseln zu müssen.

Mit dem Cortex M0 wurde das sinnvolle Einsatzspektrum so verschoben, 
dass sich eben letztere auch kostentechnisch besser als vergleichbare 
8-Bitter darstellen und deshalb für Neuentwicklungen quasi keine 
Nachteile mehr bieten.

8-Bit schrieb:
> Coder schrieb:
>> Bedauerlicherweise ist die Welt nicht so einfach. Schau nicht nur auf
>> den Silizium-Preis: I.d.R. reden wir von wenigen Cent!?! Eine bestehende
>> Infrastruktur portiert man nicht mal so eben. Und das kann richtig ins
>> Geld gehen, insbesondere bei Software nach EN61508.
>
> Deshalb wird es auch noch lange 8-Bit-uC geben. Das habe ich aber weiter
> oben schon geschrieben. Ich rede ganz explizit von einem Trend bei
> Neuentwicklungen.

? meine Erfahrung im Berufsleben sagt. Werde schnell und kostengünstig 
fertig. Das gilt auch bei Neuentwicklung. "Alt" bewährtes und 
vorraussichtlich viele tausende Zeilen "fehlerfreierer" :-) Code sind 
unschlagbar günstig.

Man probiert im kleinem Rahmen natürlich immer mal etwas neues aus. By 
the way wechselt man von NXP Cortex M0+ zu einem Kinetis M0+ ist es ein 
fast neuer Controller; der Kern identisch, die Peripherie anders....

A. K. schrieb:
> Coder schrieb:
>> Man probiert im kleinem Rahmen natürlich immer mal etwas neues aus. By
>> the way wechselt man von NXP Cortex M0+ zu einem Kinetis M0+ ist es ein
>> fast neuer Controller; der Kern identisch, die Peripherie anders....
>
> Aber das Entwicklungssystem bleibt.

Ja richtig. Sag das mal deinem Firmware-Entwickler: Du darfst alle 
Treiber neu schreiben, alle Tests neumachen machen usw. aber das 
Entwicklungssystem bleibt ;-)

A. K. schrieb:
> Und das gilt in beiden Richtungen. 8-Bitter mit 512KB Code sind oft
> ebenso ausserhalb ihren optimalen Einsatzspektrums wie 32-Bitter mit 4KB
> Flash und 8 Pins.

Meine volle Zustimmung dazu!

8-Bit schrieb:
> Du darfst gerne Gegenbeispiele nennen.

8-Bit PWM reicht mir zur Helligkeitssteuerung von 7-Segm.-Anzeigen, für 
die Hintergrundbeleuchtung von TFTs und auch für die Steuerung von 
DC-Motoren.
10-Bit ADC-Werte kann man bequem und schnell genug mit 2 x 8-Bit 
verarbeiten. Die Bremse dabei ist meist der ADC selbst.
Vielfach lasse ich auch linksbündig wandeln und nehme nur das obere 
Byte. Zum Einlesen von Potis reicht das in der Regel aus.
Wenn dann 'hochpräzise' 24-Bit ADCs verwendet werden, sind diese so 
lahm, dass auch hier die 8-bittige Weiterverarbeitung nicht als Bremse 
wirkt.
Mehr darf ich nicht sagen. NDA - Du weißt :-)

@8-Bit
An Deiner Stelle würde ich z.B. vielmehr auf die möglichen 
Interruptprioritäten der Cortex-Mx verweisen. Hier ist ein 8-Bit AVR 
klar unterlegen, was aber nicht an seiner internen Busbreite liegt.

A. K. schrieb:
> Rein technisch gesehen ist das richtig. Wenn allerdings diese
> Neuentwicklung eines Produktes von jemandem durchgeführt werden muss,
> der seine 8-Bitter in- und auswendig kennt, aber ausser seinem eigenen
> noch nie einen Cortex dressiert hat, dann wird die Entscheidung u.U.
> nicht auf technischer Grundlage getroffen, sondern unter
> Berücksichtigung der zu investierenden Zeit.

Niemand behauptet, dass dieser Trend von heute auf morgen umgesetzt 
wird. Das ist natürlich ein jahrzehntelanger Prozess. Der neue Cortex M0 
von Atmel ist ja erst einer der ersten Hinweise auf diese Entwicklung.

Außerdem: Häufig ist alter Code eben nicht so fehlerfrei und arbeitsarm, 
wie du es gerade beschreibst, sondern eine schlecht wartbare Altlast. 
Häufig noch in Assembler geschrieben, weil man ja aufgrund der 
ineffizienten Architektur jedes Byte und jeden Prozessorzyklus 
ausquetschen musste. Da spart es enorm viel Zeit, wenn man auf eine 
moderne, hoch skalierbare Architektur umsteigen kann.

A. K. schrieb:
> Bei AVRs liegt die Grenze bei 8KB Code. Alles darüber unterscheidet sich
> in der Codedichte nicht, aufgrund der Entscheidung für eine
> Befehlscodierung in 16 Bits. Auch die PIC18 codieren 20 Bits
> Zieladresse, ausreichend für 2MB Code.

Ja, alles schön und gut. Ich erinnere dich mal an den Anstoß der 
Diskussion: Dort wurde behauptet, dass 8-Bitter viel effizienter sind 
und viel kleineren Code produzieren.

Im Moment lieferst du nur Argumente dafür, mit welchen Krücken 
8-Bit-Architekturen leben müssen, um noch halbwegs effizienten Code 
ausspucken zu können.

M. N. schrieb:
> 10-Bit ADC-Werte kann man bequem und schnell genug mit 2 x 8-Bit
> verarbeiten. Die Bremse dabei ist meist der ADC selbst.
> Vielfach lasse ich auch linksbündig wandeln und nehme nur das obere
> Byte. Zum Einlesen von Potis reicht das in der Regel aus.
> Wenn dann 'hochpräzise' 24-Bit ADCs verwendet werden, sind diese so
> lahm, dass auch hier die 8-bittige Weiterverarbeitung nicht als Bremse
> wirkt.

Und welchen enormen Vorteil hat man da noch bei einem 8-Bitter,w enn man 
ständig mit solchen Krücken herumwerkeln muss?

8-Bit schrieb:
> Außerdem: Häufig ist alter Code eben nicht so fehlerfrei und arbeitsarm,
> wie du es gerade beschreibst, sondern eine schlecht wartbare Altlast.

Entschuldigung, das war nicht auf dich, sondern auf folgenden Beitrag 
bezogen:

Coder schrieb:
> ? meine Erfahrung im Berufsleben sagt. Werde schnell und kostengünstig
> fertig. Das gilt auch bei Neuentwicklung. "Alt" bewährtes und
> vorraussichtlich viele tausende Zeilen "fehlerfreierer" :-) Code sind
> unschlagbar günstig.

M. N. schrieb:
> 8-Bit PWM reicht mir zur Helligkeitssteuerung von 7-Segm.-Anzeigen, für
> die Hintergrundbeleuchtung von TFTs und auch für die Steuerung von
> DC-Motoren.

Hintergrundbeleuchtung: Ja gut, wenn man keine Kennlinie braucht. 
Ansonsten sieht man schon ganz alt aus.

Und DC-Motoren sind ja fast schon genauso out wie 8-Bit-Prozessoren.

A. K. schrieb:
> Wie oft hast du schon erlebt, dass ein gut eingeführtes Produkt von
> Grund auf neu gebaut wurde, statt es inkrementell weiter zu entwickeln?
> Also in kommerziellem Rahmen natürlich. Nichtkommerziell ist das recht
> verbreitet.

Schon ein paar Mal, besonders natürlich wenn der Funktionsumfang gering 
ist und der alte Code schlecht wartbar war. Aber auch bei größeren 
Projekten habe ich das schon gesehen. Dazu muss man sagen, dass eine von 
Anfang an vernünftig gestaltete Plattform leicht auf eine günstigere 
oder leistungsfähigere Architektur portiert werden kann und es dann gar 
nicht mehr notwendig ist, etwas von Grund auf neu zu entwickeln.

Wenn die 8-bit so langsam und ineffizient sind, frage ich  mich, wie man 
denn jahrezehnte lang mit diesen controllertypen erfolgreich arbeiten 
konnte? Mein Arbeitgeber muss mich für die letzten 8 Jahre ja abmahnen 
:-)
Jede Entwicklungsabteilung macht seine eigene Rechnung auf. Und da kann 
man nicht pauschal sagen, die 32-Bitter kommen günstiger; es zählen noch 
eine Menge andere Faktoren.

Coder schrieb:
> Wenn die 8-bit so langsam und ineffizient sind, frage ich  mich, wie man
> denn jahrezehnte lang mit diesen controllertypen erfolgreich arbeiten
> konnte? Mein Arbeitgeber muss mich für die letzten 8 Jahre ja abmahnen
> :-)

Ganz einfach: Weil sie bis vor 1-3 Jahren noch die günstigest 
Alternative waren und tatsächlich für die meisten Anwendungen - wenn 
auch oft mit Kompromissen im Design ausgereicht haben.

Coder schrieb:
> Jede Entwicklungsabteilung macht seine eigene Rechnung auf. Und da kann
> man nicht pauschal sagen, die 32-Bitter kommen günstiger; es zählen noch
> eine Menge andere Faktoren.

Richtig, und deshalb geht der Trend in Richtung 32 Bit. In Bezug auf 
Bauteilkosten sind sie inzwischen ganz vorne dabei. Sie ermöglichen 
außerdem besser skalierbaren und wartbaren Code. Das alles spricht sehr 
stark dafür, dass sich 32-Bit-uC durchsetzen werden und die 8-Bitter in 
immer mehr Anwendungen ersetzen werden. Es wird ohne Zweifel in den 
nächsten Jahren immer noch viele Anwendungen für 8-Bit-Architekturen 
geben.

8-Bit schrieb:

>> 10-Bit ADC-Werte kann man bequem und schnell genug mit 2 x 8-Bit
>> verarbeiten. Die Bremse dabei ist meist der ADC selbst.
>> Vielfach lasse ich auch linksbündig wandeln und nehme nur das obere
>> Byte. Zum Einlesen von Potis reicht das in der Regel aus.
>> Wenn dann 'hochpräzise' 24-Bit ADCs verwendet werden, sind diese so
>> lahm, dass auch hier die 8-bittige Weiterverarbeitung nicht als Bremse
>> wirkt.
>
> Und welchen enormen Vorteil hat man da noch bei einem 8-Bitter,w enn man
> ständig mit solchen Krücken herumwerkeln muss?

Seit Anfang des Jahres nehme ich einen C-Compiler, der das für mich 
erledigt.

8-Bit schrieb:
>> 8-Bit PWM reicht mir zur Helligkeitssteuerung von 7-Segm.-Anzeigen, für
>> die Hintergrundbeleuchtung von TFTs und auch für die Steuerung von
>> DC-Motoren.
>
> Hintergrundbeleuchtung: Ja gut, wenn man keine Kennlinie braucht.
> Ansonsten sieht man schon ganz alt aus.

Du kaufst immer nur TFTs mit Kennlinie der Hintergrundbeleuchtung?
Alles klar!

> Und DC-Motoren sind ja fast schon genauso out wie 8-Bit-Prozessoren.

Nomen est omen - bei Deinem Auto ist der Scheibenwischermotor ein 
Scheibenläufer und die Seitenscheiben werden mit BLDC-Motoren bewegt?
Alles klar!

Nur mal so am Rande:

Wenn Du an 10000 Controller 600€ sparst, weil dein M0 ein bissl 
günstiger aber für 100K€ Software neu entwickelst (Zulassungen usw.!!) 
ist deine rechnung nicht gut. So viel  zu den anderen Faktoren, die du 
mir im Munde umdrehst. Sorry.

Nicht jede Firma hat Multimillionen Stückzahlen!

Als hobbyst ist das andere sache..

Nö MSP430 rulez :-)

Coder schrieb:

> Nö MSP430 rulez :-)

Aber nur in Legoland.

Popcorn Thread?

M. N. schrieb:
> Seit Anfang des Jahres nehme ich einen C-Compiler, der das für mich
> erledigt.

Natürlich, aber der Ausgangspunkt der ganzen Diskussion war doch die 
Behauptung, dass 8-bitter soooo viel effizienteren Code produzieren.

Also noch einmal konkret die Frage: Welchen erheblichen technischen 
Vorteil haben jetzt die 8-bitter wirklich gegenüber einem Cortex-M0?

Coder schrieb:
> Wenn Du an 10000 Controller 600€ sparst, weil dein M0 ein bissl
> günstiger aber für 100K€ Software neu entwickelst (Zulassungen usw.!!)
> ist deine rechnung nicht gut. So viel  zu den anderen Faktoren, die du
> mir im Munde umdrehst. Sorry.

Richtig, deshalb legt man ja besonderen Wert auf Wartbarkeit und 
Skalierbarkeit. Und das geht mit den moderneren 32-Bit-Architekturen 
einfach besser, und spart deshalb - vernünftig eingesetzt - richtig viel 
Geld. Gerade bei kleineren und mittleren Stückzahlen. Natürlich ist es 
nicht sinnvoll, auf Teufel komm raus umzusteigen, wenn man schon eine 
fertige Codebasis für eine andere Architektur hat. Aber das habe ich 
auch nie behauptet.

Und noch einmal, weil es hier wohl keiner kapiert: Ich behaupte nicht, 
dass jetzt sofort jeder auf ARM umsteigen muss und dass es in jedem Fall 
sinnvoll ist. Es geht um einen allgemeinen Trend und einen Prozess, der 
sich über Jahrzehnte hin ziehen wird.

8-Bit schrieb:
> Ich behaupte nicht,
> dass jetzt sofort jeder auf ARM umsteigen muss und dass es in jedem Fall
> sinnvoll ist. Es geht um einen allgemeinen Trend und einen Prozess, der
> sich über Jahrzehnte hin ziehen wird.

Da sind wir uns ja endlich einig und kein Grund mehr, sich mit Händen 
und Füßen dagegen zu wehren: die 8-Bitter werden uns überleben.

M. N. schrieb:
> Da sind wir uns ja endlich einig und kein Grund mehr, sich mit Händen
> und Füßen dagegen zu wehren: die 8-Bitter werden uns überleben.

Natürlich werden ein paar Exoten überleben, aber auf breiter Linie 
werden sie durch die 32-bitter ersetzt.

>Die neuen 32-Bit-uC werden in einer viel moderneren Technologie
>gefertigt. Somit sind breitere Busse überhaupt kein Thema.
Wenn die Busse schon "so breit" sind, warum kann ein ARM dann nicht 
statt seinem Flaschenhals cont. (in 4 oder 8 Bit incr.) von 8..128 Bits 
OPCode einlesen?


>Ich hab hier nen 64-Bitter Baujahr 1992, zugegeben es ist kein µC
>sondern eine "normale" MIPS R4k4, aber damals(TM) gab's keinen
>Unterschied zwischen µC und normaler CPU.
Is ja interessant.
Die Leute in '92 kannten also keinen Unterschied zwischen einem HC11- / 
8051-uC (mit interner Periferie) und verschiedenen Derivaten davon, zu 
einer PC-CPU (ohne spez Periferie)?
(Und auch von MIPS gab es damals schon Controller)


>aber wer gibt sich
>heute schon mit einem Adressraum von 64 KBbyte zufrieden?
Jede Menge Leute.
Die weit überwiegende Anzahl an Controllern hat deutlich < 64 kB RAM / 
ROM (bzw Flash).


> LED dimmen: mit 8 Bit nicht sinnvoll, zumindest nicht für
> Beleuchtungsanwendungen.
Für das kleine Zeugs würde wohl (oft) ein 4 Biter reichen


>Alle drei lassen Portzugriffe in einem Befehlstakt zu,
in einem Befehlstakt ????????
ARM hat nichtmal ein Befehl, um ein Bit (oder mehr) zu setzen (*), 
geschweige denn, das mit einem Takt zu machen!
((*) nat. angewandt auf MEM oder IO)
Selbst ein PIC (aus den 70ern !) kann das besser.

>Ey - also ich finde den LPC810 toll.
dito


>Dass die Befehlslänge von AVR und Thumb identisch ist...
heisst aber noch lange nicht, dass deshalb auch Befehle identisch sind.


>Die Crux ist eher, dass eine Adressraumtrennung die Programmierung
>deutlich komplizierter gestaltet. Weil man bei jedem Pointer
>berücksichtigen muss, in welchen Adressraum er zeigen soll.
Nö. Adressraumtrennung hat man fakt. immer, denn Daten sind was anderes 
als Code (selbst wenn log. gesehen diese Bereiche sich überlappen 
könnten), also muss man auch immer die Richtigkeit des Pointers (sofern 
man den überhaupt braucht) berücksichtigen.
Wenn Busse (Code/Daten) sich logisch gesehen überlappen können, heisst 
das noch lange nicht, dass sie sich physikalsich gesehen überlappen.
Somit gibt es die typische (uralt) Trennung von Neumann / Harvard nicht 
mehr.


>Renesas 16-Bitter M16C(&Co) variieren das, indem sie einen gut
>adressierbaren 64K Datenadressraum in einen für Daten weit schlechter
>adressierbaren 1MB Gesamtadressraum einbetten.
Nö. M16C(&Co) haben grösseren Datenadressraum.
(Die grösseren der Reihe haben auch mehrere 32 Bit Reg. Insbes. sind 
deren Adressierungs-Möglichkeiten zigmal besser als bei ARM. (was aber 
nicht heissen soll, das die für jegliche Anwendung am besten geeignet 
sind, denn oft sind schlichtweg die Kosten entscheidend))

>Es gibt nicht mal einen Abschnitt wo die maximal zulässigen
>Ströme drin stehen.
Current out of a GND pin 50mA , nix 400mA.


>Die definition von µC war damals eine andere als heute.
Nö.