mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Umfrage: Mikrocontroller der Zukunft


Autor: Mika (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mit großem Interesse verfolge ich als Hobbyelektroniker die aktuellen 
Entwicklungen im Bereich der Mikrocontroller. Für mich gibt es 
eigentlich zwei wesentliche Trends: Auf der einen Seite gibt es den 
Trend zu immer größerer Rechenleistung und immer umfangreicheren 
Peripheriemodulen. Beispiele sind für mich der XMEGA von Atmel, der 
PIC32 von Microchip und natürlich die verschiedenen Implementierungen 
des ARM Cortex-M3. Auf der anderen Seite aber gibt es auch einen Trend 
zu extrem stromsparenden Mikrocontrollern. Klassischer Vertreter hier 
ist natürlich der MSP430 von TI. Aber auch Microchip scheint sich stark 
in diese Richtung zu bewegen.

Was sind für euch die aktuellen und zukünftigen Trends im Bereich der 
Mikrocontroller? Oder anders herum gefragt, wie sollte für euch ein 
Mikrocontroller sagen wir im Jahre 2015 aussehen?

Ich freue mich schon auf eine interessante Diskussion mit euch...

Viele Grüße,
Mika

Autor: Ein Plapperer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jeder Hersteller hat da was am Kochen. PIC und AVR sind beide in Richtug 
low power. Dasselbe fuer hoehere Leistung.

Autor: Tauwetter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich freue mich schon auf eine interessante Diskussion mit euch...


Die wird es, wie gewohnt, nicht geben :-)
Beim Renesas RX läuft mir das Wasser im Mund zusammen. Da bin ich 
sicherlich der Einzige. Im Jahre 2015 wird er wohl auch für private 
Endanwender verfügbar sein, wenn überhaupt :-)

Alle Anderen werden auf Cortex schwören. Darüber wird nicht diskutiert.

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tauwetter schrieb:

>Alle Anderen werden auf Cortex schwören. Darüber wird nicht
>diskutiert.

Nicht unbedingt Cortex, aber ARM an sich.
Die gehen ja den Weg, nur einen Core anzubieten, den beliebige 
µC-Hersteller in ihren Controller implementieren.

Zumindest ist es so, daß, wenn man sich mal für einen ganz anderen 
Hersteller entscheidet, man immer schon was bekanntes darin hat. Unter 
anderem gehören da auch Compiler und Assembler dazu.

Autor: Ein Plapperer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja. Ich hab mir mal den AVR32UC3 reingezogen, mag aber nicht darueber 
diskutieren.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Grundstromrichting ist immer die selbe höhere Rechenleistung+mehr 
Speicher. bei intrigierten Systemen wie Mikrocontrollern kommt 
zusätzlich die bessere Peripherie dazu.
ich seh die Zukunft in kombinierten Systemen aus FPGA/FPAA und 
Rechenkern wie die PSoc´s z.b. im dritten Quartal kommt da ein Derivat 
mit Cortex-M3 Kern und ziemlich guter Periferie die man frei auf den 
Pins verteilen kann heraus. Ich denke die Systeme werden in diese 
Richtung gehen. Ein Chip und etwas Leistungselektronik herum mehr werden 
die Schaltungen irgendwann nicht mehr ausmachen. Vllt werden dann sogar 
aufwenig herzustellende Leiterplatten überflüssig weil man die 
Leistungselektronik durch Paralellisierung auch noch in den Chip 
verlagert.

Autor: Uwe ... (uwegw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch in fünf (oder sogar 15) Jahren wird es wohl noch 
8bit-Mikrocontroller mit minimaler Ausstattung geben, weil sie für 
manche Anwendungen vollkommen ausreichend sind und sehr preisgünstig 
sind. Andererseits werden natürlich auch immer größere Controller 
gebaut, die die Lücke zwischen "einfachem" low-cost-µC und einem 
vollwertigen PC-System immer besser ausfüllen. Von daher würde ich mal 
vermuten, dass die Vielfalt der Mikrocontroller immer weiter zunehmen 
wird.

Autor: MagIO (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast Multicore Mikrocontroller vergessen. Zu nennen sind da der 
Propeller von Parallax und der XMOS. Das interessante daran ist, dass 
hier die Frage nach "welche Schnittstellen unterstützt der" wegfällt. 
Schnittstellen wie z.B. I2C, CAN, USART, USB .... haben dort keinerlei 
Hardware-Unterstützung, sondern werden in Software implementiert.
z.B. aus Sicht des Propeller:
Heute brauche ich einen uC mit 8 seriellen Schnittstellen ... kein 
Problem! Einfach 2 Cores mit fullduplexserial starten und man hat 8 
serielle Schnittstellen.
4 x Video out? Kein Problem 4 Cores mit nem Video-Treiber laden (ok .. 
hier gibts dann doch ein wenig Hilfe per Hardware ;o).

Zudem macht multicore die Programmierung wesentlich einfacher, da jeder 
Core unabhängig läuft. Man kann hier vieles (im Falle Propeller muss man 
alles), was auf anderen uC per Interrupt gemacht wird einfach in einen 
Core auslagern. Was also in so einem Controller vorgeht ist viel 
einfacher und ist damit auch nicht so Fehlerträchtig. Zudem kann man 
jede Bibliothek einfacher einbinden. Wenn 2 (oder mehr) Bibliotheken den 
gleichen Interrupt benötigen, dann wirds dagegen lustig.

In punkto Energieeffizienz ist das auch positiv. Rechenpower, die nicht 
benötigt wird, wird einfach stillgelegt (der Core wird nicht gestartet). 
Wird auf Ereignisse gewartet (z.B. Zustandsänderung an I/O-pins), dann 
kann der Core in einen Idle-State wechseln, wo er auch weniger Strom 
verbraucht. Sämtliche anderen techniken wie runtertakten und sleep-modes 
sind hier natürlich auch möglich.
Bei herkömmlichen uC gibt es meist eine main-loop, die überprüft, ob ein 
Interrupt irgendwelche daten gesammelt hat und etwas zu tun ist. Diese 
loop "verbrät" sozusagen die Rechenpower solange bis sie gebraucht wird.

Also ich denke, dass das die Zukunft sein müsste ... leider ist das, was 
am besten ist oft nicht das was sich auch durchsetzt.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht kommen sehr günstige FPGAs dazu. Irgendwas im Preissegment 
der aktuellen Mikroprozessoren; darauf dann angepasste skalierbare 
Cores?

Autor: Dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In meinen Augen ebenfalls Cortex. Schnell, reichlich ausgestattet und 
relativ günstig. Mit etwas Übung ist die Programmierung wesentlich 
unkomplizierter und weniger fehleranfällig als bei den kleinen AVR und 
PIC. Seit ich auf die STM32 umgestellt habe, schliesse ich meine 
Projekte im Schnitt um ca. 30% früher ab...........

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian U. schrieb:

>und ziemlich guter Periferie die man frei auf den
>Pins verteilen kann...

Das hat SiLabs ja in den 8051-Derivaten, und sowas finde ich auch gut. 
Die Verteilung erscheint mir noch nicht flexibel genug, sondern geht 
leider über die Crossbar nach einem festen Schema.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm Ferkes schrieb:

> Nicht unbedingt Cortex, aber ARM an sich.
> Die gehen ja den Weg, nur einen Core anzubieten, den beliebige
> µC-Hersteller in ihren Controller implementieren.

Einen? Allein unter den Cortexen komme ich auf mindesten 8 aktuelle: 
M0,M1,M3,M4,R4,A5,A8,A9.

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> In meinen Augen ebenfalls Cortex. Schnell, reichlich ausgestattet und
> relativ günstig. Mit etwas Übung ist die Programmierung wesentlich
> unkomplizierter und weniger fehleranfällig als bei den kleinen AVR und
> PIC. Seit ich auf die STM32 umgestellt habe, schliesse ich meine
> Projekte im Schnitt um ca. 30% früher ab...........

Sicher das es nicht ehr an den FWlibs liegt die nehmen ja einen quasi 
das denken ab so was gibs nicht wirklich für die kleinen µCs.

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

>Einen? Allein unter den Cortexen komme ich auf mindesten 8 aktuelle:
>M0,M1,M3,M4,R4,A5,A8,A9.

Na gut, ich hätte besser "den" anstatt "einen" geschrieben, so genau 
meinte ich das jetzt nicht.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau weil sie nur Cores anbieten, und keine fertigen Produkte, sind sie 
damit schon seit langer Zeit so erfolgreich. Da kann sich jeder 
dranhängen, der einen 32-Bitter im Programm braucht und die 
Resourcen/Risiken einer Eigenentwicklung scheut.

Weshalb es sinnvoller sein kann, einen Core einzukaufen als einen zu 
entwickeln, das kann man auch an den PIC30 von Mikrochip bewundern. 
Genauer gesagt, an den Erratasheets und den Compilerswitches zur 
Umgehung. Zwar sind ARMs auch nicht gänzlich fehlerfrei, aber es ist 
schon ein Unterschied. Ausserdem spart man sich viel Arbeit bei 
Compiler&Co.

Wenn man einen Core von einem Hersteller kauft, der damit selbst 
Produkte anbietet, dann macht man sich von der Konkurrenz abhängig. Bei 
ARM und MIPS nicht.

Autor: henky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Plapperer schrieb:
> Ja. Ich hab mir mal den AVR32UC3 reingezogen, mag aber nicht darueber
> diskutieren.
Ist der AVR32 nicht abgekündigt worden?

Autor: Michael H. (morph1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also ich finde es gehört in jeden controller ein PPS (PIC24F und einige 
PIC18FXXJYY) oder andernorts auch Crossbar genannt.

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

>Genau weil sie nur den Core anbieten und keine fertigen Produkte
>sind sie damit schon seit langer Zeit erfolgreich. Da kann sich
>jeder dranhängen, der einen 32-Bitter im Programm braucht und die
>Resourcen/Risiken einer Eigenentwicklung scheut.

Selbst hatte ich mal mit den LPC2000 von NXP zu tun, und fand das eben 
Klasse, da bei allen ARMen Unterstützung zu finden. Sei es irgendwelcher 
Code, oder auch nur, immer die selben Entwicklungstools zu verwenden.

Dann bietet ja ARM auch noch Peripherie an, wie z.B. den VIC. Aber, 
gleiches Prinzip wie beim Core. Irgendwann ist das auch voll ausgereift, 
ich meine, bei den LPC2000 wären die Errata schon viel weniger geworden.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ARM hatte freilich auch einen Startvorteil. Als für Handies und ähnliche 
Devices passende Triebwerke gesucht wurden, da war ARM da und hatte fix 
und fertige Designs im Angebot. Andere hatten zwar leistungsfähige(re) 
Prozessoren, hatten aber für die entscheidende Integration in 
Customchips nichts anzubieten.

Atmel bietet in zwei Linien ein Beispiel für die Vor- und Nachteile der 
Strategie eingekaufter Cores. Auf der 8-Bit Schiene waren dort die 
8051er präsent, aber für die müssen sie vermutlich Geld an Intel 
abdrücken. Also kam mit den AVRs ein eigenes Design, für das sie nichts 
zahlen müssen. In diesem Fall mit Erfolg.

Bei den 32-Bittern haben sie das folglich ähnlich gehalten. Die Brötchen 
verdient man mit den ARMs und versucht anschliessend, mit einem eigenen 
Design (AVR32) an Lizenzkosten zu sparen. Aber da zahlen sie vermutlich 
drauf und ich würde nicht wetten, dass die AVR32 in 5-10 Jahren noch 
existieren.

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

>ARM hatte freilich auch einen Startvorteil...

Wenn ich mich recht entsinne, haben die ARM-Gründer in ihrer Anfangszeit 
mit üblichen Entwicklungen mal schwer auf der Nase gelegen, wodurch sich 
dann die ARM-Idee erst entwickelte.

Irgendwo im Internet (sorry, ich hab den Link gerade nicht zur Hand) 
gibt es noch die ARM-Story, das ist auch mal ganz interessant zu lesen.

Apropos Handy, PDA, etc.: Da geht wohl sehr viel über ARM. Bin da 
zufällig mal auf einer Hacker-Seite für Nokia gelandet, auch ganz 
interessant sowas.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andere Hersteller wiederum haben andere spezielle Probleme.

Renesas beispielsweise hat als Merger mehrerer Hersteller mit jeweils 
ziemlich vollständigem Programm das Problem, so ziemlich in jedem Sektor 
gleich 2 Linien unterstützen zu müssen. Mit einer gewissen 
Verunsicherung als Folge, weil der Kunde ahnt, dass davon welche langsam 
aussterben werden.

Wobei Freescale das auch ganze ohne Merger geschafft hat. Immerhin 
bieten die mit 68xxx/Coldfire, PowerPC und M-Core gleich 3 komplett 
verschiedene Architekturen im gleichen Sektor an. Für mich ein Beispiel, 
wie man sich selbst auf den Füssen stehen kann.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm Ferkes schrieb:

> Wenn ich mich recht entsinne, haben die ARM-Gründer in ihrer Anfangszeit
> mit üblichen Entwicklungen mal schwer auf der Nase gelegen, wodurch sich
> dann die ARM-Idee erst entwickelte.

Ich bin sehr früh mit dem ARM(2?) in Kontakt gekommen, jedenfalls auf 
dem Papier, d.h. dem VLSI-Datasheet zu der im Acorn verwendeten 
IC-Familie. War noch die Zeit, als man mangels Internet auf der 
Systems/Electronica Informationen erschnüffelte/erschnorrte.

Im Unterschied zu den übrigen Entwicklungen hatte ARM die aufkommende 
RISC-Philosophie dazu verwendet, eine zu den gängigen Designs wie 680xx 
vergleichbare Leistung mit viel geringerem Aufwand zu erzielen. Der Rest 
der Welt bot statt dessen zum gleichen grossen Aufwand eine entsprechend 
höhere Leistung.

Damit war zwar anfangs die Acorn-Rechnerschiene gemeint, aber mir fiel 
damals bereits die besondere Eignung der Architektur für Embedded 
Systems auf. Natürlich hat ARM damals auch Fehler gemacht, 
beispielsweise beim Interrupt-Konzept und den dämlich realisierten 
dynamischen Shifts. Fehler, mit dem die klassischen ARMs so lange leben 
mussten, bis die Cortexe endlich klar Schiff machten.

Eine Eignung, die wohl ARM selbst ebenfalls auffiel. Und sie deshalb 
dieses kleine und an vergleichsweise einfache Herstellungsprozesse 
anpassungsfähige Design entsprechend anboten.

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

>Renesas beispielsweise hat als Merger mehrerer Hersteller mit
>jeweils ziemlich vollständigem Programm das Problem, so ziemlich
>in jedem Sektor gleich 2 Linien unterstützen zu müssen.

Renesas, das war doch mal eine Zusammenführung ähnlicher Produktlinien 
von Hitachi, Fujitsu, Mitsubishi? Sorry, mag sein, daß ich in der einen 
oder anderen Firma irre, ich bin da nicht ganz im Bilde.

>Mit einer gewissen Verunsicherung als Folge, weil der Kunde ahnt,
>dass davon welche langsam aussterben werden.

Klar, wie will man vernünftig mehrere gleiche bzw. ähnliche 
Produktlinien auf Dauer verwalten! Da läßt man irgendwann einen Teil 
absterben.

>ich würde nicht wetten, dass die AVR32 in 5-10 Jahren noch
>existieren.

So alte Dinger wie der 8051, wurden aber in der Vergangenheit auch alle 
5 Jahre schon mal totgesagt. Dabei lebt der heute besser als je zuvor. 
Irgendwie erinnert mich das Ding in dieser Eigenschaft an ARM, und lebt 
auch irgendwie bei zig Herstellern immer wieder weiter. OK, viele 
Derivate sind allerdings schon gestorben.

>Ich bin sehr früh mit dem ARM(2?) in Kontakt gekommen, jedenfalls
>auf dem Papier

Richtig bekannt wurde der ARM ja lange Zeit auch nicht, zumindest nicht 
in Entwicklerkreisen, die mit kleinen Controllern zu tun hatten. Zum 
ersten mal stellte ein Prof. den ARM in einer Vorlesung um das Jahr 2000 
vor. Zuvor sagte mir der Begriff rein nichts. Na ja, irgendwie war ich 
dann doch darauf sensibilisiert, und favorisierte später für eine 
Anwendung eben einen ARM-Controller. Es hing noch ein wenig mit Keil 
zusammen, da die auch schon die 8051-Tools lieferten, und bei denen ARM 
dazu kam. Mittlerweile ist Keil ja auch ARM.

Autor: Plan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Seit ich auf die STM32 umgestellt habe, schliesse ich meine
> Projekte im Schnitt um ca. 30% früher ab...........

Der Post ist zwar gaaanz weit oben, aber dem muss ich mich anschließen.
Ich würde fast sogar fast 50% sagen, wegen der sehr guten FW-LIB.

Ich fasse nicht mehr freiwillig einen 16/8-Bitter an.

Die Zukunft bringt den Cortex-M4 in Chips. Dann gibt es 150MHz und eine 
FPU.
Ich habe allerdings bisher kein Bedürftnis float zu verwenden. Somit 
wird der Cortex-M3 mir gut reichen.

Ich wünsche mir für die Zulunft auch in den Prozessoren funktionen, mit 
der man jede Pheriperie jedem Pin zuordnen kann, mit einer Matrix. Dann 
wäre manches Platinenlayout auch einlagig realisierbar.
Sonst fällt mir spontan nichts für die Wunschliste ein was es nicht 
bereits gibt.

Ich wollte auch mal den Renesas M16C als Standard Prozessor für mein 
Hoppy, doch die schlechte Verfügbarkeit und die haben auch nur eine 
Riesige Liste was die für die Zukunft planen. Nach einem Projekt hab ich 
den fallen lassen. (Damals gab es den STM32 leider nicht)

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Plan schrieb:

>Der Post ist zwar gaaanz weit oben, aber dem muss ich mich
>anschließen.

Das macht überhaupt nichts, er ist ja auch noch lauwarm.

>Ich fasse nicht mehr freiwillig einen 16/8-Bitter an.

Da wo Zahlenbereiche nicht >255 werden, und wo nicht viel gerechnet 
wird, sind 8 bit durchaus völlig OK.

Nachdem ich mich früher mit 8-Bittern herum schlug, allerdings sehr 
zufrieden, und ich dann die ARMs in die Finger bekam, hat mich so 
manches auch überzeugt.

Ich machte z.B. Meßreihen zwischen 8- und 32-Bittern bzgl. 
Energieverbrauch und Codegrößen bei ähnlicher Performance. In beiden 
Disziplinen hatten die 32-Bitter die Nase vorne, auch wenn es auf den 
ersten Blick scheint, daß da immer bits verschwendet werden, und die 
Bitbreite wegen der Hardware einen höheren Energieverbrauch nach sich 
ziehe.

Besonders schön sind z.B. 32-bit-Timer, die erst nach Minuten 
überlaufen, bei denen man den Überlauf nach Sekundenbruchteilen nicht 
per Software handeln muß.

>Ich habe allerdings bisher kein Bedürftnis float zu verwenden.
>Somit wird der Cortex-M3 mir gut reichen.

Gerade damit, sind 32 bit den 8 bit ja überlegen.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> ARM hatte freilich auch einen Startvorteil. Als für Handies und ähnliche
> Devices passende Triebwerke gesucht wurden, da war ARM da und hatte fix
> und fertige Designs im Angebot. Andere hatten zwar leistungsfähige(re)
> Prozessoren, hatten aber für die entscheidende Integration in
> Customchips nichts anzubieten.

Na ja, ARM war "damals" (Ende der 90er) weder der einzige Hersteller, 
noch der erste Hersteller.
Siemens hat eine ganze Zeit C166er in den Handys verbaut, SHs wurden von 
HP, Casio oder Ericsson eingesetzt, MIPS u.a. von Casio und div. 68ks 
von Palm, Handspring, Motorola oder Samsung.
Fertige Designs gab es von ARM auch nie (bzw. erst jetzt), die 
Integration der div. nötigen Controller (LCD, Touch, USB etc.) haben 
Firmen wie Samsung, TI und Motorola/Freescale gemacht, von MIPS(NEC, 
Toshiba)/Renesas/Motorola gab es zu der Zeit integrierte Lösungen.

> Im Unterschied zu den übrigen Entwicklungen hatte ARM die aufkommende
> RISC-Philosophie dazu verwendet, eine zu den gängigen Designs wie 680xx
> vergleichbare Leistung mit viel geringerem Aufwand zu erzielen.

Die Rechenleistung war bei gleichem Takt wesentlich höher (Faktor 4 und 
mehr)...

Autor: Ein Plapperer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Ein Plapperer schrieb:
>> Ja. Ich hab mir mal den AVR32UC3 reingezogen, mag aber nicht darueber
>> diskutieren.
>Ist der AVR32 nicht abgekündigt worden?
>

Der UC3 nicht, der AP7000 moeglicherweise schon.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Renesas beispielsweise hat als Merger mehrerer Hersteller mit jeweils
> ziemlich vollständigem Programm das Problem, so ziemlich in jedem Sektor
> gleich 2 Linien unterstützen zu müssen. Mit einer gewissen
> Verunsicherung als Folge, weil der Kunde ahnt, dass davon welche langsam
> aussterben werden.

Genau diese Frage habe ich mir als jemand der Renesas einsetzt, auch 
gestellt. Aber bei Licht betrachtet ist es mir vollkommen egal wie 
eigentlich der Prozessorkern aussieht. Ich sehe sowieso nur den 
C-Compiler.

Intressant finde ich aber bei Renesas das die integrierte Hardware wie 
Timer, I2C, usw ziemlich kompatibel ist und sie auch den Footprint ihrer 
Bauteile sehr kompatibel halten. Es koennte also sein das ich da 
irgendwann mal die Familie wechsel und es garnicht merke. :)

Olaf

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:

> Fertige Designs gab es von ARM auch nie

Es war bei mir von Cores die Rede, nicht von fertigen Telefonlösungen.

In Customchips integrierbare Cores entwickelte ARM Anfang der 90er, den 
in diesem Sektor nicht ganz unwichtigen ARM7TDMI gab es seit 1994. Ich 
glaube nicht, dass es damals viele von Kunden integrierbare 32-Bit Cores 
gab.

> Die Rechenleistung war bei gleichem Takt wesentlich höher (Faktor 4 und
> mehr)...

Rechenleistung pro Takt ist eine völlig sinnlose Zahl. Pro Watt ist 
sinnvoll, pro Chipfläche u.U. ebenfalls, absolut sowieso.

Ungefähre Zeitgenossen des mit 8MHz getakteten ARM2 waren die mit 16MHz 
getakteten Intel 386, Motorola 68020, MIPS R2000. Und ob ein ARM2 
wirklich 4x so schnell war, wie ein 8MHz R2000?

Aber Zahlenspiele hin oder her: Die ersten ARMs waren auf adäquate 
Leistung bei geringem Aufwand optimiert. 30000 Transistoren waren damals 
nicht wirklich viel.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
stimmt, schon der 68000 hatte 68000 davon.

Autor: Tauwetter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf = mein bester Freund!

Das Gesagte kann ich voll unterstreichen. Auch mir ist völlig wurscht, 
wie die internen Busse organisiert sind und wie die Kopplung zwischen 
Prozessorkern und I/O aussieht. Beim ARM kommt mir das immer wie 
zusammengestückelt vor. Eine Zeit lang war hier im Forum der 'spurios 
interrupt' beim ARM ein häufiges Thema. Das hat mich an die ersten 
8086-PCs erinnert, wo nach jedem Interrupt noch ein EOI kommen mußte, um 
den separaten Interruptcontroller wieder frei zu geben.

Die H8, H8S, H8SX, SHxx und RX wirken dagegen homogen.
Ignorieren will ich aber auch nicht, dass die diversen ARMe/Cortexe 
deutlich kostengünstiger erscheinen. Bei meinen Stückzahlen ist mir das 
allerdings egal. Die Funktionalität der Renesas Typen ist mir da 
wichtiger.

>... das Problem, so ziemlich in jedem Sektor ...

Ohne genaue Zahlen zu recherchieren hat Renesas eine gewisse Größe und 
'Marktdurchdingung', dass die durchaus auf mehreren Hochzeiten tanzen 
können.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tauwetter schrieb:

> Beim ARM kommt mir das immer wie zusammengestückelt vor.

Das ist es ja auch. Wobei man aber berücksichtigen sollte, dass 
Controller auf ARM Basis in dieser Stelle aufgrund der Baukastenstrukur 
oft erheblich ausführlicher dokumentiert sind, als (scheinbar?) homogene 
Lösungen.

Die Trennung in mehrere Busse wird man m.E. in allen Chips dieser 
Leistungsklasse finden. Es ist einfach nicht sinnvoll, den primären 
Highspeed-Bus direkt auch an ein 1-2 Dutzend Peripheriemodule zu führen.

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen Surprise Interrupt, den gibt es nun mal auf Grund der 
Pipeline-Architekturen, sicher nicht nur bei ARM. Da macht man ein 
einziges mal einen kleinen Surprise Interrupt Handler an den 
Interruptvektoren, dann ist das auch gegessen. Aber nur, wenn man den 
auch braucht.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die H8, H8S, H8SX, SHxx und RX wirken dagegen homogen.
> Ignorieren will ich aber auch nicht, dass die diversen ARMe/Cortexe
> deutlich kostengünstiger erscheinen. Bei meinen Stückzahlen ist mir das
> allerdings egal.

Ein R32C118 kostet unter 9Euro bei Kleinststueckzahlen. (10Stk)

Das ist doch gerade bei Firmen in der Industrie die Geraete in 
ueberschaubaren Stueckzahlen herstellen ein Witz. Bei dem Preis kann es 
sich fast noch lohnen das Moerderteil (32Bit, 50Mhz, Fliesskomma, 9x 
RS232, 6xI2C, DMA, 5V und 3.3V, 40kRam, 384k Flash, usw usw) als Ersatz 
fuer einen Tiny15 einzusetzen wenn ich nur ein paar Stunden 
Entwicklungszeit einspare weil mir der Typ vertraut ist. Da kann ja 
alleine ein Stecker an einem Gehaeuse schon teurer sein.

> Die Funktionalität der Renesas Typen ist mir da
> wichtiger.

Ja, es ist immer schon alles eingebaut von dem man heute noch nicht 
gewusst hat das man es morgen brauchen wuerde. Aber immer diese 
Entscheidungen die man treffen muss..nimm ich jetzt Timer A0, A1, A2, 
A3, A4 oder doch B0, B1, B2.
Oder das Risiko eines Arbeitsunfalls wenn einem das ausgedruckte 
Hardwaremanual mal auf den Fuss fallen sollte. :-D
Oder gar die grueblerischen Gedanken denen man nachhaengt wenn man 
ueberlegt ob es wirklich irgendwo einen Entwickler gibt der sechs 
einzelne I2C-Busse benutzt?

Olaf

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tauwetter schrieb:

> Das Gesagte kann ich voll unterstreichen. Auch mir ist völlig wurscht,
> wie die internen Busse organisiert sind und wie die Kopplung zwischen
> Prozessorkern und I/O aussieht.

Eine Herangehensweise ist es, ein Gerät als Blackbox zu betrachtet und 
nur die Ergebnisse zu sehen. Beispielsweise bei einem µC die maximal 
durch Pingewackel erreichbare Frequenz. Oder bei einer Datenbank das 
Ergebnis eines SQL-Statements.

Bei einer anderen Herangehensweise versucht man, die Struktur eines 
Gerätes zu verstehen und daraus Schlussfolgerungen zu ziehen. Indem man 
die implementierte Architektur eines µC verstanden hat. Oder eine 
Vorstellung davon hat, wie SQL Statements vom System ausgeführt werden.

Die erste Variante liefert exakte Ergebnisse, läuft aber oft auf 
Ausprobieren raus. Und sie hilft praktisch überhaupt nicht, wenn man 
irgendwo dran drehen will/muss, weil das Ergebnis unbefriedigend ist.

Die zweite Variante ist eher grobe Schätzung als exakt, kann sich auch 
als falsch erweisen, erlaubt aber mit gewisser Wahrscheinlichkeit 
Voraussagen über das zu erwartende Verhalten. Und liefert Ansätze, 
bestimmte Probleme vorneweg zu vermeiden.

Beides hat seine Berechtigung.

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:

>Ein R32C118 kostet unter 9Euro bei Kleinststueckzahlen. (10Stk)

Sicher, da hängt einiges von der Herstellerpolitik ab. Als Entwickler im 
Kleinunternehmen ist man bei weitem nicht wahlfrei.

Wir hatten die ARM7 z.B. als LPC21xx mit 1-7 Euro, je nach Flash-Größe, 
und zwischen 100 und 1000 Stück.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm Ferkes schrieb:

> Einen Surprise Interrupt, den gibt es nun mal auf Grund der
> Pipeline-Architekturen, sicher nicht nur bei ARM.

Auch mit Pipelining liesse sich das ohne diese Überraschung erledigen, 
nur hat ARM das eben nicht gemacht.

Die Spurious Interrupts jedoch sind prinzipiell schwer zu vermeiden, vor 
allem wenn man so dusselig konstruierte UARTs verwendet, wie den 
PC-UARTs in den LPC2000. Die Unterschiede bestehen eher darin, was dabei 
letztlich geschieht. Beim VIC, der dafür berühmt wurde, landet man im 
nichtvektorisierten Handler ohne recht zu wissen warum. Bei anderen 
Interrupt-Controllern landet man zwar im richtigen Vektor, weiss dann 
aber auch nicht warum. In meinen Augen ist die Sache ziemlich 
aufgeblasen worden, oft mangels Verständnis. Die eher verwirrende als 
hilfreiche Appnote von Philips/NXP hat dazu ebenfalls beigetragen.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> In meinen Augen ist die Sache ziemlich
> aufgeblasen worden, oft mangels Verständnis. Die eher verwirrende als
> hilfreiche Appnote von Philips/NXP hat dazu ebenfalls beigetragen.

Ist zwar Offtopic, aber hast du ein vernünftige Beschreibung zu dem 
Thema? Nur Interesse halber.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nö. Nur im Kopf. Könnte veilleicht auch mal irgendwo in einem älteren 
Forenbeitrag erwähnt worden sein.

Autor: Kai Klaas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Was sind für euch die aktuellen und zukünftigen Trends im Bereich der
>Mikrocontroller? Oder anders herum gefragt, wie sollte für euch ein
>Mikrocontroller sagen wir im Jahre 2015 aussehen?

Ist doch vollkommen wurscht, weil ich darauf überhaupt keinen Einfluß 
habe. Ich werde mit dem arbeiten müssen, was die Hersteller dann gerade 
anbieten.

Sage mir heute, was in 9 1/2 Wochen auf deinem Frühstücksbrötchen liegen 
wird und sage ich dir welchen Mikrocontroller ich 2015 verwenden werde.

Im Moment arbeite ich viel mit dem AT89S52, ein zuverlässiges 
Arbeitspferd mit ISP, aber keinerlei besonderen Features. Ich werde wohl 
in Zukunft auf SILABS umsteigen. Die niedrige Versorgungsspannung ist 
für gemischt analog digitale Systeme allerdings eher ungünstig. Und um 
die PICs zu verstehen, bin ich zu dämlich...

Kai Klaas

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
900ss D. schrieb:

> Ist zwar Offtopic, aber hast du ein vernünftige Beschreibung zu dem
> Thema? Nur Interesse halber.

Am ehesten hier: Beitrag "ARM7 mit VIC und Spurious Interrupts"

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da haben sich auch andere (English only) Gedanken darueber gemacht.
Die meisten kennen mich ja als Vertreter der ARM Schiene. Trotz des 
Artikels (Link unten) denke ich, dass z.B. AVR (8) und verschiedene PIC 
weiterhin stark sein werden. In Japan ohne Frage auch die Renesas/NEC 
Kombination, in Europa erwarte ich speziell im Automotive auch weiterhin 
starke Praesenz von Infineon und Freescale. Fuer den 
Ottonormalverbraucher, falls es den bei MCUs gibt denke ich wird ARM 
eine sehr starke Rolle spielen.
Artikel mit der Frage ob Cortex-M die uC Welt beherrschen wird, ich 
denke mal der ist mit guten Fakten unterlegt.
http://mcu-related.com/architectures/35-cortex-m3/...
Gruss, Robert

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Plan schrieb:
> Ich habe allerdings bisher kein Bedürftnis float zu verwenden. Somit
> wird der Cortex-M3 mir gut reichen.

Ich habe damit keine Skrupel.
Wenn es das Programmieren vereinfacht, setzte ich float auch auf nem 
ATtiny25 ein.

Der Einsatz von float hat absolut garnichts mit der CPU-Leistung zu tun.
Wenn z.B. alle 200ms ein Wert für den langsamen Menschen angezeigt 
werden soll, dann lacht mich mein ATtiny einfach nur aus ob des bissel 
float-Rechnens.

Du darfst also ruhig dem Cortex-M3 etwas zum float Rechnen geben, der 
freut sich doch drüber.
Extra ne CPU mit FPU nehmen, damit die CPU-Last um 0,001% sinkt, ist 
Unsinn.


Dagegen mag ich es nicht, wenn ich erstmal 10kB Konfigurationscode 
erzeugen muß, für PLL, MMU, diverse Busse, Clocks usw.
Da finde ich die 8-Bitter bequemer, einfach "main()" schreiben und los 
gehts.
Mir ist daher auch schon der MSP etwas zu kompliziert.


Auch habe ich etwas Bauchschmerzen, ob bei den Boliden auch auf die 
Störfestigkeit Wert gelegt wird und nicht alle Entwicklungspower nur für 
die CPU verbraucht wurde.
Z.B. ein definiertes Verhalten bei beliebigem (nichtmonotonen) Anstieg 
der VCC und auch bei Einbrüchen, daß z.B. die PLL kein Hickup kriegt und 
die CPU verrückte Befehle ausführt. Wenn die PLL sich verstellt, muß das 
Programm ja noch lange nicht abstürzen, es kann aber falsch rechnen.

Zumindest die älteren AMR7 von NXP hatten ja nen ziemlich heftigen 
PLL-Bug. Glaub, die PLL mußte erst abgeschaltet werden, wenn man 
bestimmte Register zugreifen wollte. Und der PLL-Fangbereich wurde 
nachträglich auch verkleinert, weil es wohl Probleme gab.


Die ersten AVRs hatten zu Anfang massive Probleme mit der 
Störfestigkeit. Seitdem setze ich grundsätzlich keine superneuen Chips 
mehr ein. Sie müssen mindestens schon 2 Jahre in Produktionsstückzahlen 
verfügbar sein. Daher habe ich mir auch die Xmega noch nicht angeguckt 
(und weil ich auch keine passende Aufgabe für sie habe).


Peter

Autor: Dideldum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

wahrscheinlich ist die C-Control Version 5.0 der Renner!
Viele Grüße
Dideldum

Autor: lassativ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube kaum,dass sich bis 2015 viel aendern wird.Falls wir bis dahin 
schon aus der Krise draussen sind...kann es sein,dass es auch fuer 
Bastler wieder etwas Neues gibt. Die X Versionen von 8051 werden aber 
weiterhin fuer ruhige Naechte sorgen,fuer zufriedene Programmierer und 
Kunden.
Warum auch das Beste wegwerfen ?

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die Zukunft bringt den Cortex-M4 in Chips. Dann gibt es 150MHz und eine
>FPU.

Vor allem aber bringt er einen DSP auf die Platine, die FPU ist 
optional.

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
>> Renesas beispielsweise hat als Merger mehrerer Hersteller mit jeweils
>> ziemlich vollständigem Programm das Problem, so ziemlich in jedem Sektor
>> gleich 2 Linien unterstützen zu müssen. Mit einer gewissen
>> Verunsicherung als Folge, weil der Kunde ahnt, dass davon welche langsam
>> aussterben werden.
>
> Genau diese Frage habe ich mir als jemand der Renesas einsetzt, auch
> gestellt. Aber bei Licht betrachtet ist es mir vollkommen egal wie
> eigentlich der Prozessorkern aussieht. Ich sehe sowieso nur den
> C-Compiler.
>
> Intressant finde ich aber bei Renesas das die integrierte Hardware wie
> Timer, I2C, usw ziemlich kompatibel ist und sie auch den Footprint ihrer
> Bauteile sehr kompatibel halten. Es koennte also sein das ich da
> irgendwann mal die Familie wechsel und es garnicht merke. :)
>
> Olaf

Da haben wohl beide schon recht mit dem evtl. Aussterben einer Linie. 
Renesas ist sehr kompatibel zwischen den verschiedenen H8Sxyz aber das 
ist auch NXP zwischen ARM7, Cortex-M3 und einigen ARM9. Die Frage ist, 
wenn z.B. der V850 von NEC den Vorzug erhaelt und eine Produktlinie z.B. 
M32 einfach stirbt? Dann ist es Essig mit der Kompatibilitaet. Wenn 
allerdings einer der ARM Hersteller sich vom Markt verabschiedet und das 
wird passieren, dann gibt es viele andere Hersteller, die Teile haben 
fuer diesselben Tools, zu aehnlichen Preisen mit sehr aehnlichem 
Echtzeitverhalten haben.

Was man aendern muss ist die Initialisierung der Peripherals. Das 
wiederum uebernimmt zu einem betraechtlichen Teil CMSIS bei ARM. Also 
von einem STM32 auf einen LPC1700 oder einen Stellaris umzusteigen ist 
deutlich einfacher als von einem SH2 auf einen V850 obwohl sie beide 
bald vom "selben Hersteller" sein werden.

Renesas ist derzeit der groesste MCU-Hersteller, somit kann Renesas auch 
bis zu einem gewissen Masse Standards setzen, doch persoenlich halte ich 
die Cortex-Varianten einfach fuer zukunftssicherer und ich denke mal das 
war die urspruengliche Frage.
Wenn es darum geht was man nicht einsetzen sollte, dann fallen mir auch 
ein paar ein, doch Renesas ist nicht dabei :-)

Robert
I am biased, I am a trainer and consultant for ARM-Cortex.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die Frage ist,
> wenn z.B. der V850 von NEC den Vorzug erhaelt und eine Produktlinie z.B.
> M32 einfach stirbt? Dann ist es Essig mit der Kompatibilitaet.

Also der M32 wurde mir schon nicht mehr fuer neue Designs empfohlen, 
sondern der R32.
Aber ich meinte eigentlich etwas anderes. Wie der Prozessor im inneren 
eigentlich aussieht ist mir vollkommen egal einfach weil ich nur in C 
programmiere. Und selbst wenn ich etwas sehr hardwarenahes machen 
wuerde, so waer das nur ein sehr kleiner spezieller Programmteil. Sowas 
anzupassen waere kein Problem. Was ich aber gut finde, das die 
eingebaute externe Hardware im Prozessor sehr kompatibel ist. Ich habe 
schon Applikationen vom H8 gelesen, den ich nicht nutze, die mich sehr 
stark an einen M16 erinnert haben.

> Wenn
> allerdings einer der ARM Hersteller sich vom Markt verabschiedet und das
> wird passieren, dann gibt es viele andere Hersteller, die Teile haben
> fuer diesselben Tools, zu aehnlichen Preisen mit sehr aehnlichem
> Echtzeitverhalten haben.

Also das Echtzeitverhalten meiner Software bestimme ich IMHO selber. Was 
mir an ARM nicht gefaellt das viele Hersteller den Core von jemand 
anderem kaufen und drumherum dann was anderes ist. Das sieht mir, von 
aussen betrachtet als nicht ARM-Nutzer, etwas chaotisch aus.

> Renesas ist derzeit der groesste MCU-Hersteller, somit kann Renesas auch
> bis zu einem gewissen Masse Standards setzen, doch persoenlich halte ich
> die Cortex-Varianten einfach fuer zukunftssicherer

Oh, ich denke auch da es ARMs noch lange geben wird. Allerdings habe ich 
den Eindruck die sind eher im Consumerbereich angesiedelt. Da wo man 
einen Core zukauft, eigene Hardware dranstrickt und das ganze dann als 
DVD-Video Player verkauft. Und ein Jahr spaeter gibt es nur noch das 
Nachfolgemodell wo man zwar noch denselben Compiler nutzen kann, aber 
sonst alles ganz anders ist. In der Industrie scheinen sie mir noch 
nicht recht angekommen zu sein oder? Also z.B in einem Autosteuergeraet 
oder einer ABS Elektronik? Kennt da einer Beispiele?

Olaf

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.