Ich möchte zuallererst inständig bitten von Glaubenskriegen Abstand zu nehmen. Es nützt niemandem hier zu erklären jemand hätte keine Ahnung und dies als Begründung für die eigene Argumentation zu nehmen, wenn scho dann bitte auch mit Begründung und Argumenten. Vielen Dank. Nun zur Sache. Als alter Atmega-Fan stelle ich mehr und mehr fest, dass immer weniger Peripherie für die alten 8bitter produziert wird. Gut, verständlich, die Dinger kommen in die Jahre. Aber was ist das "next best thing", der nächste Schritt, der neue Standard? XMega? Cortex? Oder überhaupt von Atmel weg? Microchip hat ja für so ziemlich jede Funktion 'n Chip gebastelt, da schaut's bei Atmel mit Peripherie eher mager aus (oder find ich nur nix?). Für mich steht jedenfalls ein Generationswechsel an, und nach gegebenen Möglichkeiten würd ich gerne vermeiden mich in etwas einzuarbeiten das keine Zukunft hat. Also bitte ich die informierten Gurus und Wahrsager ihre Glaskugeln abzustauben und mir die Zukunft der MCs darzulegen. Insbesondere würde mich interessieren in welche Richtung die Industrie geht. Schon weil für uns Bastler sicher kein MC-Hersteller produzieren wird, und die dort in fünf+ -stelligen Stückzahlen verbauten Chips sicher mal erstens verfügbarer und zweitens länger verfügbarer sein werden. Merci im Voraus!
Hi >Als alter Atmega-Fan stelle ich mehr und mehr fest, dass >immer weniger Peripherie für die alten 8bitter produziert wird. Was meinst du damit? MfG Spess
Heinz L. schrieb: > Also bitte ich die informierten Gurus und Wahrsager > ihre Glaskugeln abzustauben und mir die Zukunft der MCs darzulegen. Ich bin in dieser Leistungsklasse von 8051ern nach einer sehr kurzen und unangenehmen Kontaktaufnahme mit PICs auf die AVRs gekommen. Und jetzt werden die vom ARM abgelöst. Die anderen Sachen (MSP430, R8C, M16, ST10...) wurden zwischendurch auch ausprobiert, ab&an eingesetzt und werden jetzt auch vom ARM abgelöst. Da passt dann auch mal der GCC toll dazu... ;-)
Ich schließe mich Lothar an. Nachdem ich vor 20 Jahren ein Kenner des 8031 war habe ich mich gefragt wo es sich lohnen könnte nochmals tiefer in den Assemblersprache bzw. in eine Prozessorarchitektur neueren Datums einzusteigen. Da zwängte sich der der Thumb - Befehlssatz und der ARM praktisch auf. Sogar Microsoft unterstützt ARM - Prozessoren.... Gruß Thilo
P.S. ich bin außderem ziemlich sicher, dass in Zukunft die PSoC - Architektur einzieht. Es ergibt heute keinen Sinn mehr einen MC als Plattform mit unzähligen Features vollzupacken. (STM32, PIC usw..) Entweder man braucht den Großteil davon nicht oder man wählt aus unzähligen Derivaten denjenigen aus, dessen integrierte Peripherie passt. Die Smartphone - Industie zeigt die Zukunft auf. Es wird evtl. einen festgelegten Prozessor geben (was auch nicht sicher ist) und die Peripherie wird per IP (intellectual property) dazugekauft, und in den Chip gebrannt und siehe da - ich hab den MC den ich brauche. Gruß thilo
THaala schrieb: > Die Smartphone - Industie zeigt die Zukunft auf. Es wird evtl. einen > festgelegten Prozessor geben (was auch nicht sicher ist) und die > Peripherie wird per IP (intellectual property) dazugekauft, und in den > Chip gebrannt und siehe da - ich hab den MC den ich brauche. Das sind aber meist von den jew. Chip Herstellern vorgegebene universal Chips - nicht anders als ein STM32 - nur viel fetter und noch viel mehr zeug drin. TI OMAP z.B. - da ist alles mögliche drin und auch vieles was man im Smartphone sicher nicht braucht (z.B. 5 UARTs, 3 I2C, 4 SPI, 4x Audio, 4x SDIO, 2x USB Host, paar 100 GPIOs, usw. usf. - nur ein Beispiel) - da ist normalerweise nix wie in nem PSOC drin. Und kein normaler Smartphone Hersteller bekommt TI dazu custom IP in die Chips zu packen. Gut, wenn man wie Apple auf 100Mrd Dollar Devisen sitzt kann man natürlich seine eigenen Chips basteln ist klar (die kommen aber auch ins iPhone und ins iPAD und ins iTV also auch eher universal). HTC, LG, RIM oder Nokia können sich sowas aber z.B. nicht leisten. Auch Samsung fertigt wie TI hauptsächlich universal Chips ohne Custom IP... Einzig bei Qualcomm könnte man teilweise zustimmen, da kommt das Mobilfunk HF Zeug teilweise auch mit in den SoC rein, aber das ist so ziemlich der einzigste Hersteller der das macht. Dennoch ist es wie der OMAP ein Universalprozessor und wird an viele verschiedene Kunden identisch ausgeliefert.
THaala schrieb: > ich bin außderem ziemlich sicher, dass in Zukunft die PSoC - Architektur > einzieht. Glaube ich nicht. Das ist eine schon oft wiederbelebte Totgeburt aus der ASIC-Ecke. > Die Smartphone - Industie zeigt die Zukunft auf. Nicht jeder erreicht deren Stückzahlen. Und deshalb kann diese Industrie nur die Richtung für Volumenmärkte diktieren.
THaala schrieb: > ich bin außderem ziemlich sicher, dass in Zukunft die PSoC - Architektur > einzieht. Die Idee die hinter PSoC steht ist sicher sehr Interessant. Nur der Cypress PSoC so wie er jetzt ist, ist teilweise schon Murks. Manchmal möchte man das Teil halt gerne mit dem Hammer zerkloppen weil's mal wieder nicht will :)
Meine Meinung (oder Hoffnung :-) In Zukunft wird mehr standardisiert, das heißt z.B. - ein Handy-SoC muss aus Arm-Core und Anstueruerng für Display, SD, Sensorik (Acc, Gyro, Magnet), USB, WLAN, Bluetooth, ... haben. - in der PC-Welt dann ähnlich. - so Späße wie XMEGA werden klar gegen größere (32bit) Controller verlieren. - bei größeren Controllern hat sich bereits großteils ARM durchgesetzt. - am unteren Ende werden AVR8-bit und kleinere PICs möglicherweise den 8051 als Dinosaurier ablösen :-) Prophetenmodus an: Es wird die Zeit kommen, da ein Blinklicht standardmäßig mit 32bit-Controllern und Linux aufgebaut wird grusel :-)
Floh schrieb: > - am unteren Ende werden AVR8-bit und kleinere PICs möglicherweise den > 8051 als Dinosaurier ablösen :-) Der AVR wird den 8051 nie ablösen, eher umgekehrt. Peter
Heinz L. schrieb: > Für mich steht jedenfalls ein Generationswechsel an Dann muß sich aber was an Deinen Aufgaben geändert haben. Der AVR verbraucht sich ja nicht. Für Steuerungen war er vor 10 Jahren gut geeignet und ist es heute auch. Da gibt es keinen moralischen Verschleiß. Vermutlich willst Du nun aber komplexere Sachen machen, Z.B. Grafik, Touchscreen, Filesystem, MP3 usw. Da geht man dann besser zu irgendnem 32Bitter. Es gibt nicht die eierlegende Wollmilchsau-CPU. Sondern es hängt immer von der Aufgabe ab, die man damit lösen will. Ohne die geplante Anwendung zu nennen, ist Deine Frage daher weitgehend sinnfrei. Peter
Peter Dannegger schrieb: > Der AVR wird den 8051 nie ablösen, eher umgekehrt. Da spricht man von überleben... ;-)
Korrekt, Peter. Meine Aufgabenstellungen ändern sich. Früher war's eine einfache Servosteuerung mit lokalen Inputs, da reicht ein Atmega16 oder gar 8 mit seinen 8-16MHz problemlos. Aktuell steh ich vor einem Projekt, das neben USB und Ethernet auch noch eine Funkkomponente unterstützen muss, nebenbei soll's wie Du richtig identifiziert hast auch etwas ausgeben können zwecks Anzeige... und erst DANN kommen wir zum Thema was das Ding eigentlich tun soll. Und bis dorthin wären's bereits mindestens 2 chips weil spätestens mit KapTouch und USB ist ein Atmega8 bei der Vollbeschäftigung angekommen. Da nützt's mir auch wenig ein paar Generationen weiter zu greifen auf einen 168 oder 644, es geht nicht um den Speicher, es geht schlicht um Geschwindigkeit. Und die ist beim 8bit Atmel bei 20MHz ziemlich am Ende. Jetzt kann man natürlich hergehen und einen Chip für USB einbauen, einen für Ethernet, einen für CapTouch, einen für... nur damit war's das dann für den Einsatzzweck "mobil". Erstens wollte ich nicht das Volumensäquivalent eines Netbooks rumschleppen, andererseits wollte ich nicht 5 Kilo nur für'n Akku einplanen. Das Ziel ist, weniger Material mit mehr Leistung. Davon, dass GCC für Atmel eher suboptimalen Code erzeugt mal ganz abgesehen. Ich bin ehrlich kurz davor wieder zu ASM zurückzugehen, der Code wird 'ne ganze Ecke kleiner und, sehr ehrlich, auch leichter zu debuggen. Klingt komisch, ist (für mich) aber so. Dass es den allseeligmachenden Omnipotenz-MC nicht gibt und nie geben wird (und wenn macht er wahrscheinlich im Bereich Preis unglücklich) ist klar. Es geht hier auch nicht darum mich auf einen Chip "einzuschießen", es geht darum welcher MC-Familie die Zukunft gehört. Was mir bisher an den ATMegas (und ihren kleinen Tiny Verwandten) gefiel war die Kompatibilität des Wissens. Was für einen stimmte, stimmte auch für den anderen. Die Architektur war (von einigen Spezialfällen abgesehen) kompatibel. Was ich über den ADC des ATMega8 wußte passte auch für den des ATTiny15. Was ich über den UART des Atmega16 wußte stimmte auch für den 644. Wenn ich wußte wie ich die Register des einen anspreche stimmte dies auch fast 100% für jeden anderen aus der Familie. Ich wäre nun auf der Suche nach einer ähnlichen "Familie", die es mir erlaubt mit dem Wissen über ein Mitglied davon durch wenig zu- und nach Möglichkeit keinem Umlernen einen anderen MC der Familie zu verwenden. Das Stichwort ARM ist ja schon gefallen, und ich würde nun gerne wissen ob denn hier Zukunftssicherheit besteht, oder ob dies auch schon wieder Schnee von gestern ist und der ARM auch schon wieder am absteigenden Ast sitzt. Davon mal abgesehen, dass soviel ich weiß (aber da möge mich jemand der mehr über ARM weiß berichtigen), dass ARM ja keine MCs per se bereitstellt sondern nur den Kern dazu, und jeder MC-Hersteller bastelt dann das "Drumherum". Falls ich da nun richtig liegen sollte stellt sich mir hauptsächlich die Frage: Welches "Drumherum" ist das "richtige", sprich, welcher MC-Hersteller wird hier wohl das Rennen machen und die Zukunftssicherheit anbieten die ich mir wünsche? Vielen Dank nochmals für alle bereits gegebenen und noch kommenden Antworten!
Heinz L. schrieb: > Falls ich da nun richtig liegen sollte stellt sich > mir hauptsächlich die Frage: Welches "Drumherum" ist das "richtige", > sprich, welcher MC-Hersteller wird hier wohl das Rennen machen und die > Zukunftssicherheit anbieten die ich mir wünsche? Was denkst du denn wer vor Jahren das Rennen bei den kleinen µC gemacht hat? :) Man muss kein Hellseher sein um zu erahnen das es keinen Gewinner geben wird, denn auch bei ARM gibt es zich verschiedene Einsatzgebiete und verschiedene Vor- und Nachteile bei den Controllern. TI hat z.B. den LAN Phy schon an Board, EM hat sehr Stromsparende ARMs, NXP hat ein "all in One" CAN Bus bei einem seiner ARMs oder die Serie mit USB Bootloader, usw usw...
Oookay, verstanden. Aaaaber, wenn ich das Ganze richtig verstehe dann sollte ich die doch alle mehr oder weniger gleich anreden können, oder? Ist alles 'n ARM-Kern, was die Integratoren drumrum bauen ist mehr oder weniger "nur" die Peripherie mit Speicher, Interfaces, etc. Hab ich das so weit richtig? Weil das würde ja (zumindest theoretisch) bedeuten, dass der Assembler im Grunde genommen herstellerübergreifend weitestgehend ident anzureden ist. Oooooder?
>>> Das Stichwort ARM ist ja schon gefallen, und ich würde nun gerne wissen >>> Es bestehen ja Bestrebungen - gerade in der ARM - Welt, selbst die Aufrufe des MC an die Peripherie zu standardisieren (innerhalb der ARM-Familie...). In der neuesten Version 3.0 wird sogar ein Standard für die Vereinheitlichung von RTOS - Betriebsystem - Aufrufen gesetzt. Ich halte gerade das für zukunftsweisend. Schau mal hier: http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php Gruß Thilo
Es wird eine Sprache geben um Anforderungen an ein System zu formulieren. Dann etwas, was daraus die erforderliche Hard- und Software ermittelt und zusammenstellt. Wie bei der Fertigung, es geht zu Losgröße 1. Dann braucht man mich nicht mehr.
Heinz L. schrieb: > Aber was ist das "next > best thing", der nächste Schritt, der neue Standard? Hmm, du bist an einer Stelle angekommen, wo du dich umorientieren willst. Mit Sicherheit wirst du - wie alle anderen auch - nie den allerbesten uC und nie die allerbeste uC-Familie ausfindig machen können. Das läuft auf 2 Fragen hinaus: a) wo wird der allgemeine Trend hingehen? b) welche Ecke willst du dir dabei aussuchen? Da es dir mit den kleinen AVR's offenbar mittlerweile zu eng wird und du damals dich für AVR und nicht für PIC entschieden hast, wäre es wohl kein wirklich guter Rat für dich, jetzt zu PIC's umzuschwenken. Dort gibt es zwar all das, was du angesprochen hast, also recht einheitliche Peripherie-Bausteine, die man im kleinsten PIC wie im dicksten PIC antrifft, es gibt auch in manchen Dingen die gleiche "Denke" in den Strukturen - aber eben nicht wirklich familienübergreifend. Die Strukturen der Familien PIC16, PIC18, PIC24, PIC32 unterscheiden sich z.T. grundlegend. Den allgemeinen Trend kann man schon jetzt sehen: Er geht eindeutig in Richtung Cortex, was auf der letzten Embedded geradezu auffällig war. Es wäre aber ein Fehler, zu glauben, daß alle Hersteller exakt das gleiche Süppchen kochen. Der Familiensinn beschränkt sich deshalb eher auf die CPU. Trotzdem rate ich dir zu den Cortexen. Sind gute Prozessoren, haben einiges an Rechenleistung, sind für C-Programmierer besser geeignet als die AVR's, weil man mit so nem 32 Bit Zeiger überall hin zeigen kann und die ganzen Unterscheidungen, ob man denn nun in den Code oder den RAM zeigen will, einfach hinfällig sind. So ein vereinheitlichter riesiger Adreßraum hat halt seine guten Seiten. Ansonsten finde ich den voraussichtlichen Siegeszug der Cortexe aus genereller Sicht nicht gut. Nee, nicht weil die schlecht wären, sondern weil dies auf der anderen Seite eine Art digitales Artenaussterben nach sich zieht. Sowas wird zur Monokultur und verengt den Horizont der Elektroniker. In der Softwareszene kann man etwas recht ähnliches beobachten: C gibt es überall und alles andere ist ziemlich ausgestorben. Mag ja sein, daß viele Leute C besonders mögen - oder nur deshalb mögen, weil sie nichts anderes kennen gelernt haben, aber es ist ne Monokultur und die Erfahrung lehrt, daß dies schlecht ist. Natürlich will ich dir nicht raten "Werde ein Exot, um die CPU-Arten zu retten", aber vielleicht ist es auch für dich das Beste, eben nicht dich auf nur eine Sparte zu konzentrieren, sondern mit mehreren Gefilden vertraut zu sein. Vielleicht Cortex für's Geldverdienen und Fujitsu oder PIC oder NEC oder MSP nebenher. Atmel kennst du ja schon. W.S.
C sehe ich nicht als Beschränkung. Es ist eher eine lingua franca, überall erhältlich, eine Art Esperanto und zu 99% unabhängig von der zugrundeliegenden Hardware. Die Hardware wird an Wichtigkeit verlieren - die Funktionialität erhält sie ja aus dem "Programmieren". C ist da abstrakt genug und trotzdem schnell und relativ maschinennah. C ist es relativ egal ob da ein Cortex oder ein 6502 drunter werkelt.
Heinz L. schrieb: > Das Stichwort ARM ist ja schon gefallen, und ich würde nun gerne wissen > ob denn hier Zukunftssicherheit besteht, oder ob dies auch schon wieder > Schnee von gestern ist und der ARM auch schon wieder am absteigenden Ast > sitzt. Dagegen spricht zumindest die Tatsache, dass aktuell ungefähr jedes Embedded Device (allen voran die Smartphones auf Basis von Android) eigentlich durch die Bank hinweg auf ARM setzen. Heinz L. schrieb: > welcher MC-Hersteller wird hier wohl das Rennen machen und die > Zukunftssicherheit anbieten die ich mir wünsche? Ich glaube es dürfte im Interesse aller liegen, dass es einen solchen "MC-Hersteller" nie geben wird. Das würde dann nämlich einer Monopol Stellung entsprechen. Und das war aus Sicht der Kunden noch nie von Vorteil. Hier im Forum (und auch im Wiki) gibt es ja einige Vorstellungen von verschiedenen Plattformen bzw. Boards. Hast du dir diese denn schon einmal (näher) angesehen?
Ich denke je nach Einsatzgebiet wird es wohl auch der Preis machen, bei großen Stückzahlen kostet heute ein STM32 mit mehr Flash/RAM weniger als ein 8- oder 16-bit Prozessor. Wenn man dann nicht irgendwelche Spezialforderungen hat (z.B Stromverbrauch) dann nimmt man doch lieber den 32-bitter. Warum Golf fahren wenn man für weniger Geld auch einen Porsche bekommt
Ich lehne mich mal soweit aus dem Fenster und behaupte, dass es dem Programmierer egal ist ob ein ARM oder was Anderes unter der Haube steckt. Was ich damit sagen will ist ganz einfach, der Prozessorkern selbst, also das was ARM bereitstellt, wird in den meisten Fällen vom Compiler (bei den 32Bit Typen macht man doch eh kaum mehr ASM) abstrahiert. Es interessiert mich bei den 32Bit Prozessoren, die teilweise als Mikrocontroller (nicht Mikroprozessor!, also quasi als guter AVR Ersatz) 160MHz machen (aus dem Kopf ist das etwa der Takt der STM32F4) nicht wirklich, ob ein bestimmtes Konstrukt in 2 oder 3 CPU Takten abgearbeitet wird. Wirklich relevant für den Programmierer ist die Peripherie, also was vorhanden ist, und wie sie anzusprechen ist. Und hier unterscheiden sich die verschiedenen ARMs der verschiedenen Hersteller drastisch voneinander. Deshalb kann man meiner Meinung auch ARM als solches nicht wirklich gegen andere Prozessoren abwägen, denn wenn ich AVR sage, rede ich von einem einigermaßen einheitlichen Peripheriesystem, wenn ich aber ARM sage kann ich alles meinen, vom STM32L der Strom sparen soll und gut nen AVR ersetzen kann von der Leistung her bis zum Quadcore 1.5GHz Tegra3, oder auch den scheinbar in Arbeit befindlichen 64Bit ARM v8 der wohl dann irgendwo in Servern werkelt. Was ich sagen will, der Trend geht meiner Meinung nach ganz eindeutig und unumstößlich zum ARM, doch die eigentliche Frage ist, welche ARM Mikrcontroller Serie setzt sich im Mikrocontroller Bereich durch, also vorallem unter den Cortex M3 und M4, aber auch den kleineren.
Hallo, ich denke, dass in Hinblick auf die IPv6 Adressverfügbarkeit ein MC zukünftig direkt IP-Fähig (mit Schicht 4 Protokollen) sein muß, als auch in der Lage sein sollte, über USB direkt WiFI Sticks zu bedienen. Ob dazu jedes mal ein Betriebssystem implementiert werden muß, wage ich zu bezweifeln. Eine embedded WLAN-fähige MC Lösung darf zukünftig nicht über 25 Euro kosten. Wer das nicht bietet ist im Embedded System Market nicht konkurrenzfähig. Grüße
Ich denke, der klassische Mikrocontroller wird auf lange Sicht durch FPGA verdrängt. Und da sei es mal dahingestellt, ob im FPGA dann ein ARM-Kern aufgebaut wird oder ein klassischer 8051 oder sowas. Insofern würde ich mir wünschen, dass FPGA nochmal deutlich günstiger und vorallem kleiner (Gehäuse) werden. Das Peripherie-Wettrüsten hat jetzt lange funktioniert, aber der Kunde wünscht immer komplexere Peripherie. Irgendwann lohnt es nicht mehr, eine ganze Prozessorserie präventiv mit sowas zu erschlagen. Bestes Beispiel sind, mal wieder, die PIC: Hunderte Varianten gibt es für jeden erdenklichen Zweck. Die Peripherie ist bei genauerem Hinsehen doch eher uneinheitlich und vorallem kreuz und quer mit Silicon bugs gespickt. Das hat einfach keine Zukunft, hoffe ich :-}
Sven P. schrieb: > Ich denke, der klassische Mikrocontroller wird auf lange Sicht durch > FPGA verdrängt. Und da sei es mal dahingestellt, ob im FPGA dann ein > ARM-Kern aufgebaut wird oder ein klassischer 8051 oder sowas. Insofern > würde ich mir wünschen, dass FPGA nochmal deutlich günstiger und > vorallem kleiner (Gehäuse) werden. Also da muss schon viel passieren, damit sich DAS preislich lohnt.
@ Sven P. (haku) Benutzerseite >Ich denke, der klassische Mikrocontroller wird auf lange Sicht durch >FPGA verdrängt. Glaub ich nicht. Dazu ist die Siliziumeffizienz viel zu gering. Schau dir mal an wieviel FPGA-Logik man für einen einfachen AVR braucht, und da ht man noch nicht mal den Flash. Und dann schau dir an was das an Silizium und damit Preis kostet. > Und da sei es mal dahingestellt, ob im FPGA dann ein >ARM-Kern aufgebaut wird oder ein klassischer 8051 oder sowas. Insofern >würde ich mir wünschen, dass FPGA nochmal deutlich günstiger und >vorallem kleiner (Gehäuse) werden. Vergiss es. Der Trend geht genau in die andere Richtung. Und bei der Diskussion kommt auch eine gewisse Monokultur auf. Es ist eben NICHT so, dass es EINEN Universalprozessor geben wird. Dafür ist die Bandbreite der Anwendungen viel zu groß. Kleine AVRs oder was auch immer wird es ebenso in Zukunft geben wie größere ARMs und noch größere ATOM & Co. Klar sollte es möglichst keine Monokulturen oder Monopole der Anbieter geben. Aber schaut mal zurück in die Anfänge der Heimcomputer. Wieviele Dutzende verschiedene Systeme und Ansätze gab es? Wieviel hat ökonomisch wie technisch überlebt? Ein normaler Prozess. MFG Falk
In einem gewissen Bereich werden FPGA mit Hardcores (oder anders herum betrachtet Mikrocontroller mit FPGA-Peripherie) sicherlich die zahlreichen Mischlösungen ersetzen. Gerade im Industriebereich in mittleren Stückzahlen werden teure ASIC gerne durch FPGA ersetzt, und wenn dann noch der Prozessor integriert ist, warum nicht? Das spart dann Kosten und Platz. Von der anderen Seite versuchen die Prozessorhersteller, ihre Peripherie immer universeller zu machen. Das führt inzwischen sogar dazu, dass in einem Prozessor noch mehrere Coprozessoren eingesetzt werden, die die Aufgabe von spezieller Peripherie übernehmen können. Für kleinere Anwendungen ist das natürlich uninteressant. Aber hier geht der Trend wohl auch dahin, dass 8-Bitter so langsam von den kleinen 32-Bit-Kernen (Cortex M0 und Co.) ersetzt werden. Und bei ganz großen Stückzahlen wird man eher wieder spezialisierte Chips zu machen. Es lohnt sich nun einmal, einen speziellen Smartphone-SoC mit spezialisierter Peripherie zu bauen, wenn der dann von vielen Herstellern zu jeweils Millionen Stück verbaut wird.
Heinz L. schrieb: > Ich wäre nun auf der Suche nach einer ähnlichen "Familie", die es mir > erlaubt mit dem Wissen über ein Mitglied davon durch wenig zu- und nach > Möglichkeit keinem Umlernen einen anderen MC der Familie zu verwenden. Ich würde den Begriff "Familie" so deuten, dass es sich um die Familie eines Herstellers handelt - wie bei AVR, ohne second source. Dabei setze ich persönlich auf die STM32F4 (STM) und auch RX62/RX63 + RX210 (Renesas), die verschiedene Anwendungsbereiche abdecken können. Der RX210 z.B. ist recht preiswert und läuft mit Versorgungsspannungen ab 1,6V bis 5,5V. Ein idealer µC-Ersatz auch für ältere Designs. Wenn der Hase eines Tages in eine andere Richtung laufen sollte, dann passiert das zum einen nicht von heute auf morgen, und zum anderen ist "Umlernen" eigentlich immer angesagt.
> Die Smartphone - Industie zeigt die Zukunft auf. Es wird evtl. einen > festgelegten Prozessor geben (was auch nicht sicher ist) und die > Peripherie wird per IP (intellectual property) dazugekauft, und in den > Chip gebrannt und siehe da - ich hab den MC den ich brauche. Das funktioniert so nur in wirklichen Massenmärkten. Bei eventuellen, eher individuellen Maschinensteurerungen, für Bahntechnik, für Landwirtschaftliche Geräte, für Sondermaschinenbau (Auftragsfertigung) u.s.w. sieht es wieder ganz anders aus.
Falk Brunner schrieb: > @ Sven P. (haku) Benutzerseite > >>Ich denke, der klassische Mikrocontroller wird auf lange Sicht durch >>FPGA verdrängt. > > Glaub ich nicht. Dazu ist die Siliziumeffizienz viel zu gering. Schau > dir mal an wieviel FPGA-Logik man für einen einfachen AVR braucht, und > da ht man noch nicht mal den Flash. Und dann schau dir an was das an > Silizium und damit Preis kostet. Naja, ist denn das jetztige Vorgehen so viel effizienter? Statt weniger, flexibler aber aufwendigerer FPGA gibts dann halt zehntausend Derivate eines Prozessors inklusive Bugs, die keiner mehr so recht zu pflegen vermag. Und bei jedem Derivat wird präventiv mal mit fünf seriellen Schnittstellen, ADC und einem riesigen Timerklotz draufgeschossen. Im Schnitt könnte man doch quasi von jedem verbauten Mikrocontroller den halben Die wegoptimieren. Da liegen eh nur die Peripherieeinheiten drauf, die man im konkreten Design garnicht braucht, die aber halt beim Prozessor dabei waren. > Aber schaut mal zurück in die Anfänge der Heimcomputer. > Wieviele Dutzende verschiedene Systeme und Ansätze gab es? Wieviel hat > ökonomisch wie technisch überlebt? Ein normaler Prozess. Und wie viel davon hat abseits jeder technischen Zweckmäßigkeit durch Marketing überlebt? Grad Intel ist ja nicht gerade ein Vorzeigebeispiel, wie der normale Prozess zu technisch sinnvollen Lösungen führt... Aber du hast ingesamt schon Recht, ich betreibe da viel Wunschdenken :-/
Sven P. schrieb: > Naja, ist denn das jetztige Vorgehen so viel effizienter? Statt weniger, > flexibler aber aufwendigerer FPGA gibts dann halt zehntausend Derivate > eines Prozessors inklusive Bugs, die keiner mehr so recht zu pflegen > vermag. Und bei jedem Derivat wird präventiv mal mit fünf seriellen > Schnittstellen, ADC und einem riesigen Timerklotz draufgeschossen. Das liegt sicher daran, dass der Platz, Stromverbrauch und Preisaufschlag solcher Komponenten wirklich gegen null tendiert und wirklich keinen Aufpreis kostet. > Im Schnitt könnte man doch quasi von jedem verbauten Mikrocontroller den > halben Die wegoptimieren. Da liegen eh nur die Peripherieeinheiten > drauf, die man im konkreten Design garnicht braucht, die aber halt beim > Prozessor dabei waren. Die Logik verstehe ich nicht. Du willst statt einem fertigen Mikroprozessor einen universellen FPGA nehmen, nur um dann ein paar Module nicht einzubauen? Da nehm ich doch lieber den Mikrocontroller und benutze die Module einfach nicht. Das ist immer noch WESENTLICH effizienter (wie Falk sagte) als einen FPGA dafür herzunehmen.
Heinz L. schrieb: > Ich bin ehrlich kurz davor wieder zu ASM zurückzugehen, der > Code wird 'ne ganze Ecke kleiner und, sehr ehrlich, auch leichter zu > debuggen. Die Einsparung mit Assembler ist minimal (max 20%, wenns hoch kommt). Dafür ist der Schreib- und Debugaufwand ein Vielfaches (min 200%, eher 400%). Wenns bei Dir anders ist, dann hast Du mit C gerade erst angefangen. Ich verspreche Dir, das bessert sich schnell. Heinz L. schrieb: > Aktuell steh ich vor einem Projekt, > das neben USB und Ethernet Dann kannst Du Assembler eh voll vergessen. Die Libs sind alle in C und selber schreiben ist nur was für absolute Freaks, die zuviel Freizeit haben. Heinz L. schrieb: > Das Stichwort ARM ist ja schon gefallen, und ich würde nun gerne wissen > ob denn hier Zukunftssicherheit besteht Da sich die Hersteller wie wild drauf stürzen (Atmel, ST, NXP, TI), werden sie das schon gründlich untersucht haben. Bei den Cortex-Typen versucht man auch, die Unterschiede gering zu halten. NXP hat teilweise Cortex, die pinkompatibel zu älteren ARM7 sind. Peter
Simon K. schrieb: >> Im Schnitt könnte man doch quasi von jedem verbauten Mikrocontroller den >> halben Die wegoptimieren. Da liegen eh nur die Peripherieeinheiten >> drauf, die man im konkreten Design garnicht braucht, die aber halt beim >> Prozessor dabei waren. > Die Logik verstehe ich nicht. Du willst statt einem fertigen > Mikroprozessor einen universellen FPGA nehmen, nur um dann ein paar > Module nicht einzubauen? Da nehm ich doch lieber den Mikrocontroller und > benutze die Module einfach nicht. Das ist immer noch WESENTLICH > effizienter (wie Falk sagte) als einen FPGA dafür herzunehmen. Naja, ich könnte mir durchaus einen Mikrocontroller vorstellen, der eigentlich nur den Prozessor vorgibt und drumherum dann ein wenig FPGA-artiges bietet. Da könnte man dann als Entwickler genau den Timer drin realisieren, den man gerade braucht. Oder irgendein Protokollmodul oder was auch immer. Das ganze statt ungenutzter Siliziumfläche. Am Preis würde sich wohl kaum was ändern, statt Ingenieursleistung beim Hersteller gibts halt mehr Raum für FPGA-artige Strukturen. Oder werden z.B. die großen ATmega so exorbitant teurer, nur weil mehr Silizium drin steckt? (ernstgemeinte Frage) Aber wie gesagt, Wunschdenken...
Sven P. schrieb: > und drumherum dann ein wenig > FPGA-artiges bietet. Da könnte man dann als Entwickler genau den Timer > drin realisieren, den man gerade braucht. Oder irgendein Protokollmodul > oder was auch immer. Das ganze statt ungenutzter Siliziumfläche. Gibt / gab es doch auch mal: http://www.design-reuse.com/news/10280/atmel-fpslic-ii-dynamically-reconfigurable-soc-supports-silicon-sharing-peripherals-interfaces.html In eine ähnliche Richtung zielen die XMOS und Propeller
Ich finde generell die Entwicklung zu den immer größeren Leistungen eher bedenklich. Ich bin der Meinung, dass gerade für den Privat- und Hobbybedarf rein ausstattungstechnisch die z.Zt. vorliegenden Mikrocontroller vollständig ausreichend sind. Natürlich wird es immer Randbereiche geben in denen ich gewisse Erweiterungen (Portexpander, ext. ADC, ...) brauche aber das hält sich nun wirklich in Grenzen. Viel bedenklicher halte ich dahingegen, dass die Codequalität binnen der letzten Jahre massiv abgenommen hat. Als ich eingestiegen bin, habe ich mir von meinem ersten PIC ein Datenblatt genommen und habe mir im Anhang die ASM-Kommandos ausgedruckt und mir ein paar Basics aus div. Büchern rausgenommen. Ich hab mir das alles Step-by-Step aufgebaut. Das hilft mir heute noch beim tieferen Verständnis und vor Allem beim Debugging. Meine erste Anwendung war ein Blink-LED und irgendwann kam dann ein Lauflicht. Und UART kam eben erst dann, wenn ich vollständig verstanden hatte was zu tun ist, in welcher sequentiellen Reihenfolge was in welche Register geschrieben werden muss. Gerade die Generation "Arduino" ist meiner Ansicht nach in dieser Richtung ein ziemliches Übel. Ich verstehe die Faszination, dass jeder Anfänger (wirklich jeder) ohne Probleme auch komplexere Vorhaben realisieren kann, aber meiner Meinung nach fehlt nahezu allen Anwendern ein tieferes Verständnis für die Sache. Es wird einfach nur ein geringer Prozentsatz eines gesamten Mikrocontrollerwissens benötigt, den Rest erledigt die Software (bzw. Libraries). So braucht man für das einfachste Blinklicht schon x Libraries und weiß eigentlich gar nicht mehr wie die Implementierung auf dem Mikrocontroller eigentlich von statten geht. Dann werden auch Stichworte wie: Bitmanipulation, Timer, etc ... zu einem Sperrbereich den die wenigsten (und wenn dann wiederwillig) betreten. Was dabei rauskommt - ich glaube das ist jedem von uns hinreichend bekannt. Natürlich kommt man auch so zu Ziel - es gibt schließlich auch Quadrocopter die dank kalman.h, pid.h und summensignal.h durch die Gegend divergieren. Das hat dann was von Plug n' Play - aber das hat nichts mehr mit Mikrocontrollerprogrammierung zu tun. Wenn es an die Fehlersuche geht, dann haben die meisten ein großes Problem. Unbestritten ist sicherlich, dass es gerade Anfängern doch recht komplexe Projekte erlaubt. Ob das so gut ist, das ist eine interessante Frage. Ich konnte einfach damals als Anfänger noch keine solchen Projekte realisieren. Erst mit wachsender Erfahrung konnte man sich an komplexe Projekte heranwagen. Natürlich ist es eine heftige Arbeit eine gesamte Quadrocopterregelung in ASM zu basteln, aber schlecht für die eigene Bildung / Erfahrung wäre es auch nicht. Ich gehe auch in letzter Zeit (natürlich eher bei kleinen Projekte) immer mehr dazu über wieder in Assembler zu arbeiten. Natürlich verbrauchen Designhilfsmittel (wie der Arduino-"Compiler") Ressource wie ein Allergiker Taschentücher zur Heuschnupfenzeit. Daraus resultiert auch der "Drang" nach mehr Leistung. Für gewisse Anwendung (Bildverarbeitung, etc.) kann ich verstehen, dass Leistung nötig ist. Aber für solche kleinen Sachen wie Quadrocopter (diese Kategorie eben) ist mit Sicherheit nicht mehr Leistung sondern eher Wissen und Programmiergeschick erforderlich. Wenn ich wirklich Anwendungen wie Bilderverarbeitung / Bildererkennung machen möchte, dann sollte man generell einen Wechsel (z.B. jetzt zu Rasberry Pi) in Betracht ziehen. Denn ein PIC/Atmega/... ist mit Sicherheit nicht dazu gedacht Bildererkennung zu ermöglichen. Dafür gibt es nun wahrlich geeigneteres.
Sven P. schrieb: > Naja, ich könnte mir durchaus einen Mikrocontroller vorstellen, der > eigentlich nur den Prozessor vorgibt und drumherum dann ein wenig > FPGA-artiges bietet. Da könnte man dann als Entwickler genau den Timer > drin realisieren, den man gerade braucht. Oder irgendein Protokollmodul > oder was auch immer. Das ganze statt ungenutzter Siliziumfläche. Und was soll das bringen? Dann liegt statt ungenutzter Peripherie eben der Rest ungenutzter programmierbarer Logik im Chip wenn er nicht 100% ausgenutzt wird. Nur dass der PLD Block eben viel größer sein muss als der anderweitig eingebaute Peripherieblock. Ganz tolle Idee. Sven P. schrieb: > Am Preis würde sich wohl kaum was ändern, statt Ingenieursleistung beim > Hersteller gibts halt mehr Raum für FPGA-artige Strukturen. Denn die FPGA-artigen Strukturen muss keiner entwickeln. Die entstehen ganz automatisch wenn Silizium blank liegt... Der einzige Einsatzzweck für sowas sind Systeme, in denen sehr ungewöhnliche aber schnelle (parallel arbeitende) Peripherie benötigt wird, aber aus irgendwelchen Gründen (vielleicht Platzmangel) kein eigener FPGA/CPLD benutzt werden kann. Klingt für mich nicht nach großen Einsatzgebieten um ehrlich zu sein. Was dagegen meiner Meinung nach sinnvoll wäre ist eine Separation von IO Ressourcen, also Pins und Peripherie Ressourcen. Soll heißen, eine Schaltmatrix, mit der man intern jeder Peripherie auf jeden Pin legen kann. Das würde Routing und damit PCB Kosten erheblich vereinfachen, und bei vielen ARMs sind ja schon viele Pins wählbar, aber eben noch nicht alle.
@Sven P. (haku) Benutzerseite >Naja, ist denn das jetztige Vorgehen so viel effizienter? Ja. >Statt weniger, >flexibler aber aufwendigerer FPGA gibts dann halt zehntausend Derivate >eines Prozessors inklusive Bugs, die keiner mehr so recht zu pflegen >vermag. Du hast wohl ein kleines Trauma mit Bugs? Soooo wild ist das bei weitem nicht. Und die einzelnen Module der diversen Mikrocontroller werden ja nicht jedes mal von der Pike auf neu gemacht, da wird sinnvollerweise viel Cpoy & Paste betrieben. Nicht aus Faulheit, sondern weil es Unsinn ist, das Rad jedes Mal neu zu erfinden. Damit > Und bei jedem Derivat wird präventiv mal mit fünf seriellen >Schnittstellen, ADC und einem riesigen Timerklotz draufgeschossen. Oh Gott, jetzt haben die Mikrocontroller schon zuviel Resouren. War das nicht bisher eher anders? ;-) >Im Schnitt könnte man doch quasi von jedem verbauten Mikrocontroller den >halben Die wegoptimieren. Nö, nur wenn du deine exakte Anwendung kennst. >Und wie viel davon hat abseits jeder technischen Zweckmäßigkeit durch >Marketing überlebt? Jaja, der Techniker ist der natürliche Feind des Werbefuzzies. Aber so ist die Welt, LOGIK kommt da ganz am Ende, Psychiologie am Anfang! > Grad Intel ist ja nicht gerade ein Vorzeigebeispiel, > wie der normale Prozess zu technisch sinnvollen Lösungen führt... Siehe oben. Es ist eine Technikerillusion, dass immer nur das technisch Beste sich durchsetzt. >Aber du hast ingesamt schon Recht, ich betreibe da viel Wunschdenken :-/ ;-) MFG Falk
@ Sven P. (haku) Benutzerseite >Naja, ich könnte mir durchaus einen Mikrocontroller vorstellen, der >eigentlich nur den Prozessor vorgibt und drumherum dann ein wenig >FPGA-artiges bietet. Da könnte man dann als Entwickler genau den Timer >drin realisieren, den man gerade braucht. Oder irgendein Protokollmodul >oder was auch immer. Das ganze statt ungenutzter Siliziumfläche. In einem FPGA braucht man dazu aber schätzungsweise die dreifache Fläche gegenüber einem hardverdrahtetem Modul. Ausserdem ist es nicht so schnell und stromsparend, vor allem weil die FPGAs schon lange die schnellsten verfügbaren CMOS-Prozesse nutzen. Das sind aber nicht die stromsparensten, vor allem in Punkto Leckstrom, Sleep Mode etc. >Am Preis würde sich wohl kaum was ändern, Hast du eine Ahnung, wie die Preisgestaltung bei solchen Sachen aussieht. > statt Ingenieursleistung beim >Hersteller gibts halt mehr Raum für FPGA-artige Strukturen. Oder werden >z.B. die großen ATmega so exorbitant teurer, nur weil mehr Silizium drin >steckt? (ernstgemeinte Frage) Ja. Fläche ist heutzutage fast alles. OK, es kommen noch die Entwicklungs- und -Prozesskosten dazu, und die sind bei 45nm Technologie und weniger EXORBITANT. MfG Falk
FPGA mit MC-Core klingt erstmal gut, aber Du hast zuviele Möglichkeiten. Und damit steigt der Programmieraufwand astronomisch. Deshalb sieht man das nur sehr selten. Z.B. eine Menüführung mit einem Text-LCD 4*20 ist schnell realisiert. Aber nimmt man ein Grafik-LCD, hat man unendlich viele Möglichkeiten und man sitzt tagelang daran und ist mit dem Aussehen immer noch nicht zufrieden. Schon die Auswahl der Schriftarten, Farben und Größen ist eine Qual. Auch gab es mal den Ansatz einer CPU mit zur Laufzeit änderbarem Befehlssatz (Microcode), hat sich auch nicht durchsetzen können. Mehr Flexibilität bedeutet immer auch mehr Entwicklungsaufwand. Peter
Falk Brunner schrieb: > Oh Gott, jetzt haben die Mikrocontroller schon zuviel Resouren. War das > nicht bisher eher anders? ;-) Naja, nicht unbedingt zu viel, aber oft falsch verteilt. >>Im Schnitt könnte man doch quasi von jedem verbauten Mikrocontroller den >>halben Die wegoptimieren. > > Nö, nur wenn du deine exakte Anwendung kennst. Darum schrieb ich ja von jedem verbauten Mikrocontroller... Aber ich unterstriche das zur Sicherheit nochmal: >>Aber du hast ingesamt schon Recht, ich betreibe da viel Wunschdenken :-/ > > ;-) Ich bin wirklich nicht so naiv, wie ich manchmal schreibe :-}
Tokyo Drift schrieb: > Und was soll das bringen? Dann liegt statt ungenutzter Peripherie eben > der Rest ungenutzter programmierbarer Logik im Chip wenn er nicht 100% > ausgenutzt wird. Nur dass der PLD Block eben viel größer sein muss als > der anderweitig eingebaute Peripherieblock. Ganz tolle Idee. Das wäre mir immerhin noch lieber, als wenn 10 von 16 Timern vom Timer-Array brach liegen, ich aber dringend noch irgendeine serielle Schnittstelle brauche... > Sven P. schrieb: >> Am Preis würde sich wohl kaum was ändern, statt Ingenieursleistung beim >> Hersteller gibts halt mehr Raum für FPGA-artige Strukturen. > > Denn die FPGA-artigen Strukturen muss keiner entwickeln. Die entstehen > ganz automatisch wenn Silizium blank liegt... Also wenn du so argumentierst, dann konstruiert Microchip jeden Mikroprozessor von Grund auf neu. Anders kann ich mir die krummen und schiefen Bugs nicht erklären :-} Ich denke, ein Stück FPGA dürfte heute das kleinste Problem sein. > Was dagegen meiner Meinung nach sinnvoll wäre ist eine Separation von IO > Ressourcen, also Pins und Peripherie Ressourcen. Soll heißen, eine > Schaltmatrix, mit der man intern jeder Peripherie auf jeden Pin legen > kann. Das würde Routing und damit PCB Kosten erheblich vereinfachen, und > bei vielen ARMs sind ja schon viele Pins wählbar, aber eben noch nicht > alle. Wäre doch schon ein Anfang. Quasi die PIA :-)
Peter Dannegger schrieb: > FPGA mit MC-Core klingt erstmal gut, aber Du hast zuviele Möglichkeiten. > Und damit steigt der Programmieraufwand astronomisch. Deshalb sieht man > das nur sehr selten. Wieso sollte es? In einer professionellen Entwicklung gibt es einen Zweck zu erfüllen, und der lässt sich oft mit einem FPGA sehr effizient erfüllen. Ich kann mir nicht vorstellen, dass die Flexibilität den Aufwand astronomisch steigen lassen sollte. Und manche Dinge lassen sich nur durch harte Logik realisieren. Die Alternative zum FPGA ist dann ein ASIC. Und das lohnt sich oft nicht (und ist auch viel aufwändiger).
Sven P. schrieb: > Naja, ich könnte mir durchaus einen Mikrocontroller vorstellen, der > eigentlich nur den Prozessor vorgibt und drumherum dann ein wenig > FPGA-artiges bietet. Nennt sich PSoC: http://www.cypress.com/?id=1353
> Ich denke, ein Stück FPGA dürfte heute das kleinste Problem sein. Erzähl das mal den Leuten bei Xilinx. FPGA Gatter kommen nicht aus dem nichts, da steckt auch eine Menge Ingenieursleistung drinn. Ich bin mir sicher dass ein Mikrocontroller mit FPGA-Gattern und ohne Peripherie auch verdammt teuer ist. Außerdem, wo ist eigentlich das Problem, siehe Xilinx Zynq. http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/silicon-devices/index.htm Das ist ein Dual Core ARM Cortex A9 Prozessor, umgeben von einem Series 7 FPGA (wenn ich mich recht erinnere). Das sollte euch doch genug Rechenpower geben oder? Und jetzt guckt den Preis an, dann wird euch gleich schlecht und ihr versteht wieso das FPGA Zeug im Standard-µc Quatsch ist.
Mine Fields schrieb: > In einer professionellen Entwicklung gibt es einen > Zweck zu erfüllen, und der lässt sich oft mit einem FPGA sehr effizient > erfüllen. Es handelt sich dabei aber wirklich nur um sehr spezielle Zwecke. Für die Masse der Anwendungen, die ein MC mit seiner Peripherie erfüllen kann, wird sich niemand freiwillig noch einen FPGA aufbürden. Peter
Peter Dannegger schrieb: > Es handelt sich dabei aber wirklich nur um sehr spezielle Zwecke. > > Für die Masse der Anwendungen, die ein MC mit seiner Peripherie erfüllen > kann, wird sich niemand freiwillig noch einen FPGA aufbürden. Das kommt schon darauf an, wie man "sehr spezielle Zwecke" definiert. In der Industrie sind FPGA für bestimmte Aufgaben sehr beliebt und sind daher in bestimmten Branchen sehr weit verbreitet. Aber du hast schon recht, nur wenn man einen gewissen Vorteil hat wird man einen FPGA einsetzen, wenn eine Aufgabe durch einen Mikrocontroller genauso erfüllt werden kann, greift man nur selten zum FPGA.
Ich glaube übrigens, dass sich nur die MSP430 halten, auf lange Frist. Also, abgesehen von den ARMs natürlich. Und zwar für extrem stromsparende Anwendungen. Man sollte man das AVR Tutorial auf MSP430 umschreiben, und zwar in Verbindung mit dem Launchpad.
@ Tokyo Drift (tokyodrift) >Ich glaube übrigens, dass sich nur die MSP430 halten, auf lange Frist. >Also, abgesehen von den ARMs natürlich. Und zwar für extrem >stromsparende Anwendungen. [ ] Du kennst die normative Kraft des Faktischen.
Vielleicht sind die Veränderungen in der Softwarewelt ausschalggebender für die Entwcklung als die Prozessorarchitekur. Was die Prozessorarchitekuren angeht, lässt sich momentan der Trend hin zu Mehrkernprozessoren ( vielfach auch mit DSPs ) beobachten. Der ARM-Core spielt hier eine große Rolle. Aus Softwaresicht dürften Code-Generierungstools stark zulegen. Hier wären zu nennen MATLAB, LABVIEW und UML-Tools wie Enterprise Architekt oder Rhapsody. Ich denke, mit zunehmender Leistungsfähigkeit der Prozessoren werden abstraktere Programmiersprachen Einzug halten.
Tokyo Drift schrieb: > Ich glaube übrigens, dass sich nur die MSP430 halten, auf lange Frist. > Also, abgesehen von den ARMs natürlich. Und zwar für extrem > stromsparende Anwendungen. Wie kommst Du denn darauf? Stromsparoptionen hat heutzutage doch jeder MC. Man kann z.B. beim AVR Peripherie abschalten, den Takt teilen oder auch ganz abschalten und mit nem Interrupt wieder aufwachen. Ob der MSP im Power-Down vielleicht einige nA weniger braucht, interessiert keinen. Peter
Peter Dannegger schrieb: > Ob der MSP im Power-Down vielleicht einige nA weniger braucht, > interessiert keinen. Für die Waschmaschine interessiert das tatsächlich nicht, für den Heizungstemperaturleser/Verbrauchszähler interessiert das natürlich schon, also hält die Batterie nun 5 Jahre oder 20 Jahre... großer Unterschied.... Was die Zukunft der uCs angeht: Massenmarkt kann ich mir gut vorstellen, dass sich ein quasi-Standart etabliert. Das könnte Cortex Architektur sein z.B. für Handys. In der Industrie gibt es aber so viele Nieschen, da wirds verschiedene Architekturen geben, z.B. C166, 8051, MSP430 usw. die aus historischen Gründen beibehalten werden oder weil die Hersteller bestimmte Features können, z.B. Temperaturbereich, SIL usw. Für Hobby: Solange es AVR gibt und der Support für Bastler da ist, d.h. Free-Compiler und relativ günstige selbst lötbare Chips wird wohl AVR interessant bleiben.
Bernd S. schrieb: > Was die Zukunft der uCs angeht: Massenmarkt kann ich mir gut vorstellen, > dass sich ein quasi-Standart etabliert. Das könnte Cortex Architektur > sein z.B. für Handys. Bei Handys? Bestimmt nicht. Dort wird die Hardware ja praktisch schon immer im Betriebssystem komplett abstrahiert und virtualisiert, mit irgendnem Java Zeug, ist ja bei Android auch nicht anders, bei iOS weiß ichs nicht. Jedenfalls lässt es sich dort auch schnell mal zu einer anderen Arch wechseln, so ist es ja gedacht. Ich denke dass sich gerade bei Consumer- und Multimedia Electronics die Technologie schneller ändert als bei kleineren Geräten, wo der 0815-Anwender garnicht bedenkt, dass Technik drinnsteckt. Ich gehe eben davon aus, dass in naher Zukunft extrem viele (Haushalts-)Geräte Internetzugang bekommen und deshalb die 8051er und was da heutzutage werkelt durch die kleineren Cortex Prozessoren ersetzt wird. Und ich denke dass man diesen Umschwung dann auch im Hobby-Bereich zu spüren bekommt, denn wieso sollte ich AVR lernen, wenn in jedem Gerät ARM steckt?
chris schrieb: > Aus Softwaresicht dürften Code-Generierungstools stark zulegen. Hier > wären zu nennen MATLAB, LABVIEW und UML-Tools wie Enterprise Architekt > oder Rhapsody. Ich denke, mit zunehmender Leistungsfähigkeit der > Prozessoren werden abstraktere Programmiersprachen Einzug halten. Natürlich. Das hört man doch schon seit 20 Jahren... Und eigentlich nur von BWL'lern. Ein erfahrener Entwickler würde wissen das dies quatsch ist. Leider kann man nicht unendlich abstrakt werden, irgendwann muss man eben direkt sagen was man tun will oder aber man hat nur sehr stark eingeschränkte Möglichkeiten. Deine Vision das man jede SW mit ein paar Mausklicks erstellen kann, kannst du dir gleich wieder aus dem Kopf schlagen. gruß cyblord
Tokyo Drift schrieb: > Man sollte man das AVR Tutorial auf MSP430 umschreiben, und zwar in > Verbindung mit dem Launchpad. Das steht dir frei!
@ Klaus Wachtler (mfgkw) >>Tokyo Drift schrieb: >> Man sollte man das AVR Tutorial auf MSP430 umschreiben, und zwar in >> Verbindung mit dem Launchpad. >Das steht dir frei! Nicht ganz. Denn das würde ja heißen, das bestehende AVR-Tutorial zu löschen. Dagegen hätten sicher SEHR viele Leute etwas einzuwenden. Aber er darf gern eine MSP430 Version zusätzlich aufbauen. Natürlich mit vollständig getesteten Beispielen! MFG Falk
> Denn das würde ja heißen, das bestehende AVR-Tutorial zu löschen. > Ich rede ja auch nicht davon AVR hier zu löschen. Ich auch nicht, war blöd formuliert. > Das steht dir frei! Mhm wenn ich mal die Zeit dazu habe... Eventuell könnte man auch mal einen Thread dazu starten und das mit mehreren Leuten machen...
@ Guest (Gast) >Eventuell könnte man auch mal einen Thread dazu starten und das mit >mehreren Leuten machen... Klar, damit es dann wie in jeder WG zu dem berühmten Ausspruch kommt, "wir müssten mal" und am Ende sich doch kein Rad dreht . . .
Bernd S. schrieb: > Für die Waschmaschine interessiert das tatsächlich nicht, für den > Heizungstemperaturleser/Verbrauchszähler interessiert das natürlich > schon, also hält die Batterie nun 5 Jahre oder 20 Jahre... großer > Unterschied.... Wenn die Geräte die mittlerweile vorhandenen Möglichkeiten zum Harvesting nutzen würden bzw. die Entwicklung dort noch etwas weiter geht, ist/wird dies uninteressant... Energy Micro oder SiLabs aus der Cortex-Ecke... > Was die Zukunft der uCs angeht: Massenmarkt kann ich mir gut vorstellen, > dass sich ein quasi-Standart etabliert. Das könnte Cortex Architektur > sein z.B. für Handys. Gerade da würde ich nicht unbedingt drauf wetten: Die Architektur ist dort fast irrelevant. Der Aufwand das OS an die Architektur anzupassen (wenn nicht ehe schon geschehen) ist sehr gering verglichen mit dem Aufwand für das restliche System. Siehe bspw. http://www.mips.com/blog/ Lehrmann Michael schrieb: > Ich finde generell die Entwicklung zu den immer größeren Leistungen eher > bedenklich. Ich bin der Meinung, dass gerade für den Privat- und > Hobbybedarf rein ausstattungstechnisch die z.Zt. vorliegenden > Mikrocontroller vollständig ausreichend sind...Gerade die Generation > "Arduino" ist meiner Ansicht nach in dieser Richtung ein ziemliches Übel. Z.T. kann man zustimmen, z.T. würde ich sagen, lass sie mal machen: Irgendwer muss auch dort die Low-Level-Sachen machen und wäre mit den Fähigkeiten gefragt... Tokyo Drift schrieb: > Was dagegen meiner Meinung nach sinnvoll wäre ist eine Separation von IO > Ressourcen, also Pins und Peripherie Ressourcen. Soll heißen, eine > Schaltmatrix, mit der man intern jeder Peripherie auf jeden Pin legen > kann. Das würde Routing und damit PCB Kosten erheblich vereinfachen, und > bei vielen ARMs sind ja schon viele Pins wählbar, aber eben noch nicht > alle. Alles schon da: Microchip: Remappable Peripherals, SiLabs: 2x Crossbars in den neuen Cortex-M3, Cypress PSoC3/5. Glaskugel: Renesas wird auch zukünftig eigene Cores verwenden (die RX sind den div. Cortex min. ebenbürtig und als Gesamtpaket imo besser als viele Cortex-basierte Controller) Microchip wird im 32-Bit-Sektor weiter auf MIPS setzen. Ob die 16-Bitter (PIC24, dsPIC, ebenso die MSPs bei TI) mittelfristig noch eine Chance haben, eher unwahrscheinlich. Nischenarchitekturen 1) werden es noch schwerer haben: Kosten/Zeit, Toolset/chain usw. 1) u.a. http://www.hyperstone.com/products_e2_de.html (ein 32-Bit-Microcontroller/DSP aus DE), http://www.imsystech.com/products/im3910.htm (u.a. Java bzw. ladbarer Befehlssatz), http://www.ajile.com/index.php?option=com_content&view=article&id=3&Itemid=7, http://www.maxim-ic.com/products/microcontrollers/maxq/
Meiner Meinung nach werden das ARM Cortexe sich durchsetzen. ARM ist jetzt schon weit verbreitet und mit dem Thumb 2 Instruktionssatz in den Cortexen, der grob gesagt bei den wichtigsten Befehlen automatisch mit 16 Bit auskommt, sind die ARMs auch von der Codegröße besser geworden - abgesehen davon, dass es schnellen Speicher genug gibt. Um nochmal auf das Familien übergreifende Wissen zurückzukommen: Bei STM gibt es zum Beispiel Software Bibliotheken, die vom konkreten Mikrocontroller der STM32 Familie abstrahieren. Auch Adressen etc. werden einheitlich gewählt, so dass man auch Code, der direkt auf die Hardware zugreift recht universell einsetzen kann. Dafür wird aber jeder Hersteller weitestgehend sorgen. Die User Manuals besind auch recht gut - Wenn sie einen allerdings aufgrund ihrer schieren Größe fast erschlagen. Am selber lesen von Handbücher und Roadmaps der Hersteller wirst du aber wohl nicht drum rum kommen. Viel Erfolg dabei! LG Jan
Datasheets und Manuals lesen stört nicht, daran ist man doch ohnehin längst gewöhnt. :) Wesentlich wäre mir lediglich, dass ich Code einfach auf die nächste Generation portieren kann, optimalerweise ohne nennenswerten Änderungsaufwand. Hier scheint ARM das Rennen zu machen, wenn ich Eure Antworten richtig interpretiere. Nun gut denn. Ich glaub ich werd Euch bald mit Fragen quälen der Marke "Welchen ARM für den Anfang?" und "Kennt wer infoquellen für ARM Programmierung?" :)
chris schrieb: > Aus Softwaresicht dürften Code-Generierungstools stark zulegen. cyblord >>Natürlich. Das hört man doch schon seit 20 Jahren... Und eigentlich nur >>von BWL'lern. Ein erfahrener Entwickler würde wissen das dies quatsch >>ist. >>Leider kann man nicht unendlich abstrakt werden, irgendwann muss man >>eben direkt sagen was man tun will oder aber man hat nur sehr stark >>eingeschränkte Möglichkeiten. Tatsächlich muss auch bei den Code-Generierungstools und graphischen Programmierhilfen überlegen, was mam machen will. Insofern zeigt Deine Aussage nur, dass Du keine Ahnung hast, über was Du schreibst. Ich kann mich noch gut an die Zeiten des Umstiegs von Assembler auf C erinnern. Damals gab es auch einen Haufen Konservative, die glaubten auf dem alten Dampfer weiterfahren zu müssen.
Nenn doch einfach mal ein Beispiel was du gerne automatisch generiert hättest.
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.