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
Jeder Hersteller hat da was am Kochen. PIC und AVR sind beide in Richtug low power. Dasselbe fuer hoehere Leistung.
>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.
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.
Ja. Ich hab mir mal den AVR32UC3 reingezogen, mag aber nicht darueber diskutieren.
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.
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.
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.
Vielleicht kommen sehr günstige FPGAs dazu. Irgendwas im Preissegment der aktuellen Mikroprozessoren; darauf dann angepasste skalierbare Cores?
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...........
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.
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.
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.
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.
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.
Ein Plapperer schrieb: > Ja. Ich hab mir mal den AVR32UC3 reingezogen, mag aber nicht darueber > diskutieren. Ist der AVR32 nicht abgekündigt worden?
also ich finde es gehört in jeden controller ein PPS (PIC24F und einige PIC18FXXJYY) oder andernorts auch Crossbar genannt.
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.
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.
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.
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.
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.
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.
> 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)
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.
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)...
>>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.
> 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
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.
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.
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.
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.
> 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
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.
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.
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.
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.
Nö. Nur im Kopf. Könnte veilleicht auch mal irgendwo in einem älteren Forenbeitrag erwähnt worden sein.
>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
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"
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/93-cortex-m Gruss, Robert
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
Hi, wahrscheinlich ist die C-Control Version 5.0 der Renner! Viele Grüße Dideldum
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 ?
>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.
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.
> 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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.