Hallo! Ich weiß, dieses Thema hatten wir schon oft durch, ist aber schon wieder relativ lange her. Und zwar folgendes: Bis auf die PIC-Controller haben fast alle Hersteller auf 32 Bitter gesetzt. Sie sollten angeblich nach und nach alle 8 bit MCUs ablösen. Trotzdem kommt es mir so vor, als würde das nicht funktionieren. Laut Wikipedia haben die 8 bit MCUs immer noch den größten Marktanteil. Auch gibt es viele andere Gründe, die gegen den Umstieg auf 32 bit sprechen; größerer Stromverbrauch, schwierige Einarbeitung, oft nur mit Echtzeit-OS ordentlich nutzbar etc. Meine Frage daher: Ist das Aussterben von 8 bit MCUs und speziell den AVRs nur ein Wunsch der Hersteller oder werden diese wohl so bald nicht verschwinden? Ich weiß, niemand kann diese Frage zu 100% beantworten, mich würden einfach nur verschiedene Ansichten und Meinungen interessieren. PS.: Schaffen wir es diesmal auch ohne Glaubenskrieg? Gruß mega9
Auf die paar Assemblerprogrammierer (wie mich) wird man wohl keine Rücksicht nehmen. Für C-Programmierer oder andere Hochsprachen ist es wohl egal, ob der Prozessor 8 oder mehr Bit hat. Also woran liegt es? Stromverbrauch spielt natürlich eine Rolle, Preis ist auch wichtig. Für kleine Projekte die Bauform. Aber warum sollte ein ATTiny13 nicht auch 32 Bit haben können? Bauen könnte man das sicher. Offenbar verkaufen sich die 8 Bitter gut genug, dass die Hersteller einfach weiter produzieren und immer wieder auch kleine Performanceanpassungen nachschieben. Für den Anwender reichen die 8 Bit. Also werden sie weiter genommen. Der Umstieg käme wohl erst, wenn keine 8 Bitter mehr produziert würden.
Nicht zu vergessen, viele 8-Biter sind einfacher als die 32-Biter. Jetzt werden gleich die Superhacker hier im Forum aufschlagen und verkünden, warum das für sie natürlich kein Problem ist, und jeder der ein Problem damit hat ist sowieso nicht ... Es geht aber um etwas anderes. Wer sehr robuste Systeme bauen muss, und Clever ist, der eliminiert so viele potentielle Fehlerquellen wie möglich. Die Wahl einfacherer Mikrocontroller gehört dazu.
Paul R. schrieb: > Meine Frage daher: Ist das Aussterben von 8 bit MCUs und speziell den > AVRs nur ein Wunsch der Hersteller oder werden diese wohl so bald nicht > verschwinden? Sie werden die nächsten 15 Jahre garantiert nicht verschwinden. Du kannst auch heute noch 4-Bit uC kaufen: http://global.epson.com/products/semicon/products/mcu/4bit_index.html http://www.emmicroelectronic.com/products/microcontrollers/multi-io/em6607
Jay schrieb: > wer sehr robuste Systeme bauen muss, und > Clever ist Und wer gut programmiert, braucht oft gar keine 100Mhz...
Paul R. schrieb: > Sie sollten angeblich nach > und nach alle 8 bit MCUs ablösen. Paul R. schrieb: > Laut Wikipedia haben die 8 bit MCUs immer > noch den größten Marktanteil. Und das werden sie auch noch LAAAANGE behalten da der Markt immer noch nach noch geringeren Kosten schreit und 8 bit halt schon ewig im Markt ist. Alles andere ist Marketinggesülze. Aber die 32bitter haben trotzdem ihre Berechtigung und werden sich auf lange Sicht sicher durchsetzten. rgds
6a66 schrieb: > werden sie auch noch LAAAANGE behalten 6a66 schrieb: > werden sich auf > lange Sicht sicher durchsetzten. Will sagen die Zeit ist die nächsten Jahre noch nicht reif?
Es gibt IMHO keine Notwendigkeit die 8bitter abzuschaffen. In jedem kleinen Gerät werkelt meist irgendwo n 8bitter. Natürlich ist ein 32bitter performanter, aber warum sollte jemand in ein Auto zum Steuern der el. Fensterheber statt eines Tiny10 plötzlich einen 32bitter einbauen wollen? Da gibts einfach keine Notwendigkeit für...
Paul R. schrieb: > PS.: Schaffen wir es diesmal auch ohne Glaubenskrieg? Nein. Sie die 4-bitter ausgestorben ? Fast. Dabei eigenen sie sich zum Berechnung von Dezimalzahlen (Uhren, Taschenrechner) besser als 8 bitter. Was ist mit 16-bittern (MSP430, MB90, M16C, PIC24) erfreuen die sich nicht gutem C-Supports und man merkt gar nict ob 16 oder 32 bit ? Ach, die kennst du gar nicht ? Da liegt das Problem. Exoten verbreiten sich nicht (was übrigens Gründe hat, an den Prozessoren ist einiges vergurkt oder die Entwicklungsumgebungen waren schlecht). Es gibt unter Hobbyisten wohl genau 2 Pfade: AVR und ARM(Cortex). Alles andere ist exotisch. Manche Firmen quälen sich mit C166 oder 8051 oder PIC32 ab, als Hobbyist muss amn sich das nicht antun. Man nimmt, was billig ist (inkl. Entwicklungsumgebung) zu dem es viel vorgemachtes gibt. Exoten (aktuell 8266 mit LUA) nutz man wenn sie herausragende Features bieten.
Christian S. schrieb: > Auf die paar Assemblerprogrammierer (wie mich) wird man wohl keine > Rücksicht nehmen. Für C-Programmierer oder andere Hochsprachen ist es > wohl egal, ob der Prozessor 8 oder mehr Bit hat. ...verstehschni. Wieso möchtest Du als Assemblerprogrammierer hinsichtlich 8 Bit überhaupt Rücksicht genommen haben? Bit Du Assemblerprogrammierer oder AVR-Assemblerprogrammierer? Was stört Dich bei der Assemblerprogrammierung eines MC68000, der ja von der Busbreite her 16 Bit aber von der Programmierstruktur her ein 32 Bitter ist? Normalerweise sind sich Assemblerprogrammierer einig das der MC86000 oder die PDP11 die"schönsten" Architekturen überhaupt sind und beide sind sehr gut in Assembler zu programmieren... Gut, die ARMs sind RISC CPUs, man rennt da mit kleinen Schritten mit der Kirche ums Dorf, aber die sind auch assemblerprogrammierbar.... Ansonsten ist das doch völlig egal, der Unterschied betrifft doch beim Programmieren hauptsächlich die Länge der Variablen, ob eine Integer 3 nun 10 Nullen davor hat sollte weitestgehend egal sein. Die Hohe Komplexität der Herstellungstechnologie von 32Bit µCs bringt es halt mit sich das auch versucht wird eine Leistungsfähige Peripherie zu integrieren und das ist das was die Dinger auch schwierig zu programmieren macht, nicht die Tatsache das die interne Busbreite größer ist. Gruß, Holm
Ingo L. schrieb: > Natürlich ist ein > 32bitter performanter, aber warum sollte jemand in ein Auto zum Steuern > der el. Fensterheber statt eines Tiny10 plötzlich einen 32bitter > einbauen wollen? Da gibts einfach keine Notwendigkeit für.. Das ist das Problem, wenn man in einer Welt voller Überfluss lebt...
Jay schrieb: > Nicht zu vergessen, viele 8-Biter sind einfacher als die 32-Biter. Naja, nicht immer. So einige 8-bitter sind von hinten durch die Brust designt, dazu würde ich gerade die beliebten AVR zählen. Der Sprung von 8 auf 32 bit ist nicht gerade kompliziert, und typischerweise kriegt man davon a priori nix mit mit nem C-Compiler. > > Jetzt werden gleich die Superhacker hier im Forum aufschlagen und > verkünden, warum das für sie natürlich kein Problem ist, und jeder der > ein Problem damit hat ist sowieso nicht ... > > Es geht aber um etwas anderes. Wer sehr robuste Systeme bauen muss, und > Clever ist, der eliminiert so viele potentielle Fehlerquellen wie > möglich. Die Wahl einfacherer Mikrocontroller gehört dazu. Ich möchte mal behaupten, dass ein 32 bit ARM Cortex M0 robuster zu programmieren ist als ein AVR oder das n'te 8051 Derivat. Es gibt da einen Klassiker:
1 | uint16_t count; |
2 | ... |
3 | count++; |
Der count++ wird typischerweise als 'ADD' mit gefolgtem 'ADD mit Carry' umgesetzt. Also nicht atomisch ('atomic'). Schlägt jetzt ein Interrupt zwischen den beiden ADD zu, können die lustigsten Sachen passieren. Versuch z.B. mal einen wirklich robusten Mutex z.B. auf einem AVR umzusetzen. Mal abgesehen von einigen idiotischen Designs mancher Interrupt-Controller (also die Schuld der HW, das gabs beim ARM7 aber zugegebenermassen auch), laufen da eine Menge Programmierer rein. Zum Argument Stromverbrauch: ein 16bittiger msp430 ist im Schnitt sparsamer als die AVR-Architektur und die neueren M0-Kerne nähern sich der Marke auch langsam. Also auch kein Argument mehr, genausowenig wie die oft angeführte Code-Dichte.
Fitzebutze schrieb: > Der count++ wird typischerweise als 'ADD' mit gefolgtem 'ADD mit Carry' > umgesetzt. Also nicht atomisch ('atomic'). Schlägt jetzt ein Interrupt > zwischen den beiden ADD zu, können die lustigsten Sachen passieren. Deswegen wird doch das SREG auf dem Stack gespeichert? Oder spielst du auf den Zugriff der nicht komplett inkrementierten Variable in Interruptroutine an?
Einem Glaubenskrieg begegnet man am besten mit Fakten. Paul R. schrieb: > Laut Wikipedia haben die 8 bit MCUs immer > noch den größten Marktanteil. Würde mich auch wundern wenn es anders wäre. 8 Bit µC gibt es seit 40 Jahren, die Cortex-M 32 Bit waren dagegen die ersten µC, welche eine breite Akzeptanz erhalten haben. Vorgänger wie der AVR32 und andere konnten nicht diese Verbreitung erhalten, wie es ARM jetzt geschafft hat. Vor erst rund 8 Jahren kamen die Cortex-M in den Markt, mit dem Nachteil, dass Firmen ihre Treiber und Anwendungen schon Jahre zuvor für die 8 Bitter programmiert und getestet haben. ARM versucht dem mit einheitlicher Schnittstelle (CMSIS) und die Hersteller mit eigenen Libraries entgegenzuwirken und den Firmen diese Arbeit abnehmen. Dies scheint sich aber nur bedingt auszuzahlen, da Firmen immernoch lieber den eigenen Code schreiben (nur was man selber gemacht hat, hat man im Griff) und für Hobbyentwickler ist es zu kompliziert seit Arduino und co. Für die 8 Bitter spricht also die jahrelang geprobte Zuverlässigkeit und der Einsatz in bereits Entwickelten Geräten, die ohne Grund nicht einfach neu designt werden. Bleibt noch der Preis und da scheint ein Cortex-M0 bei gleichwwertigem Funktionsumfang die 8 Bitter im Preis zu schlagen. Das wäre dann auch ein gewichtiger Grund für Firmen, sich auf eine neue Architektur einzulassen. Paul R. schrieb: > gegen den Umstieg auf 32 bit sprechen; größerer Stromverbrauch, > schwierige Einarbeitung, oft nur mit Echtzeit-OS ordentlich nutzbar etc. Bei der Einarbeitung würde ich dir noch zustimmen, beim Rest nicht.
Paul R. schrieb: > 6a66 schrieb: >> werden sie auch noch LAAAANGE behalten > > 6a66 schrieb: >> werden sich auf >> lange Sicht sicher durchsetzten. > > Will sagen die Zeit ist die nächsten Jahre noch nicht reif? Heisst: jedem Tierchen sein Pläsierchen, jedem Produkt seinen uC. Früher ging's mit 4bit, später mit 8bit. Und irgendwann brauchte man zum tippen dieses Beitrags keinen Pentium mit 100MHz mehr sondern einen quadcore mit >2GHz und endlos Speicher. Eine ähnliche Entwicklung findet auch bei den anderen Produkten im Markt statt, da "muss" man heute nicht mehr den 8bitter verwenden sondern wegen vieler Faktoren den 32bitter. Also wird die Umorientierung immer weiter fortschreiten wo es nötig ist. Wann und wo da welche Märkte überholen ist reines Marketiggequatsche und Glaskugellesen. Was hast Du davon solchen Märchen und Hypes zu folgen? rgds
Operator S. schrieb: > Firmen immernoch lieber den eigenen Code schreiben Das ist wohl ein allgemeines Problem mit closed-source Software unserer Zeit. Es muss möglichst schnell fertig sein. Das beste Beispiel ist Software die per RAD erzeugt wird.
Operator S. schrieb: > Bleibt noch der Preis und da scheint ein Cortex-M0 bei gleichwwertigem > Funktionsumfang die 8 Bitter im Preis zu schlagen. Großteils subventioniert um Marktanteile zu schaffen. Die meisten 8-bitter laufen auf angeschriebenen Linien und ausgeknautschen Prozessen. rgds
Paul R. schrieb: > Ingo L. schrieb: >> Natürlich ist ein >> 32bitter performanter, aber warum sollte jemand in ein Auto zum Steuern >> der el. Fensterheber statt eines Tiny10 plötzlich einen 32bitter >> einbauen wollen? Da gibts einfach keine Notwendigkeit für.. > > Das ist das Problem, wenn man in einer Welt voller Überfluss lebt... Naja wenn da jemand mit AutoSar anfängt, dann brauch man ja fast ein den 32er nur für den ganzen Overhead der da erzeugt wird. Das schöne an den 8bittern ist ja eigentlich die einfache Peripherie. Für Kleinkram ist das doch ideal. Wenn ich nen Fensterheber als Beispiel hohle braucht man halt bischen standard ADC, evtl. nen PWM-Ausgang und LIN/CAN. (LIN is ja quasi UART). Da mit einem Timer anzukommen der 38 Synchrone Phasen mit ADC-Triggerung und Totzeit-Gewurschdel noch drin hat ist doch eigentlich nur Nervig bei der Entwicklung. Da muss man ja erstmal 200 Register setzen damit das Ding überhaupt was macht. Ich hab eh das gefühl dass viele µC-Pherieferien im 32bit-Sektor Speziallösungen von großen Firmen sind, die man halt auch so auf dem Markt anbietet. Wie sieht das eigentlich mit Die-Fläche aus? So ein AVR ist doch Platzmässig bestimmt wesentlich kleiner als ein ARM Cortex M3 mit gleicher Ausstattung? Müsste ja dann extrem viel billiger sein.
Grundsätzlich glaube ich, das 8Bit für viele Dinge absolut ausreicht. Allerdings, und das darf man auch zugeben, gibt es heute viele tolle HW, die einem SW abnehmen. Als Beispiel sei nur mal ein DMA genannt. Ein tolles Stück HW, das ich noch nie in einem AVR gesehen hab. Abgesehen davon ist das meiste Glaubensfragen. Vieles existiert schon so wie's ist, deswegen bleibts so. Die Automobilindustrie setzt nach wie vor ganz enorm PowerPC Architekturen ein. Ist auch eine schöne Architektur.
Das ist IMHO keine Frage der Hardware und ihrer Performance sondern eine der Entwicklungsumgebung. Im FPGA-Bereich haben 32b softcores die 8 bit cores verdrängt weil bspw ein Picoblaz grausam zu programmieren ist, während es für den mikroblaze ein KlickiBunti SDK gibt. Ähnlich 8 bit µC. Die die es nur mit Assembler gibt fallen immer mehr zurück, während die mit GUI C-Umgebung (Arduino) munter am Leben sind. Und immer öfters wird nach RTOS geschrieen, auch wenn es nur ein paar Tasten und eine LCD-Zeile zu bedienen gibt - also mehr HAL als Hardware. Es ist also die Bequemlichkeit der Entwickler die den 8 Bittern den Todesstoß versetzt, nicht der technische Fortschritt. Oder ein Glaubenskrieg. Meine These dazu,
Alter_Walder schrieb: > Naja wenn da jemand mit AutoSar anfängt, dann brauch man ja fast ein den > 32er nur für den ganzen Overhead der da erzeugt wird. So ein Bockmist hab ich selten gehört. Auf welchen Overhead sprichst du an? RTE? Oder das ganze Zeugs darunter? Betriebssystem? Bevor man solche unqualifizerten Aussagen einfach so in dem Raum schmeißt, sollte man sich damit mal beschäftigen. Wie immer in der Informatik gilt auch da: "Das kommt drauf an".
ui schrieb: > Als Beispiel sei nur mal ein DMA genannt. Ein > tolles Stück HW, das ich noch nie in einem AVR gesehen hab. ui schrieb: > Bevor man solche unqualifizerten Aussagen einfach so in dem Raum > schmeißt, sollte man sich damit mal beschäftigen. Sieh Dir mal die Xmega an! Viel wichtiger als die Bits ist doch, daß es die Teile im DIL-Gehäuse gibt ;-)
Bitwurschtler schrieb: > Ähnlich 8 bit µC. Die die es nur mit Assembler gibt fallen immer mehr > zurück, während die mit GUI C-Umgebung (Arduino) munter am Leben sind. > > Und immer öfters wird nach RTOS geschrieen, auch wenn es nur ein paar > Tasten und eine LCD-Zeile zu bedienen gibt - also mehr HAL als Hardware. > > Es ist also die Bequemlichkeit der Entwickler die den 8 Bittern den > Todesstoß versetzt, nicht der technische Fortschritt. Oder ein > Glaubenskrieg. Gibt übrigens einen Ausdruck für sowas: Abstraktion. Die erkauft man sich mit Overhead. Hat auch gewaltige Vorteile (gerade für heutige Elektronikprodukte, die möglichst schnell auf den Markt sollen): Man braucht sich mit den Details erstmal nicht rumschlagen, sondern erst, wenn durch die Abstraktion Fehler entstanden sind.
m.n. schrieb: > Sieh Dir mal die Xmega an! wie war das mit 32-bit Architekturen, die sich nicht durgesetzt haben^^ ;) Außerdem, dann sind wir ja genau da: Kein DMA für 8-bitter!
Alter_Walder schrieb: > Wie sieht das eigentlich mit Die-Fläche aus? So ein AVR ist doch > Platzmässig bestimmt wesentlich kleiner als ein ARM Cortex M3 mit > gleicher Ausstattung? Müsste ja dann extrem viel billiger sein. Die Die-Größe von AVRs wurde in den letzten Jahren nicht viel verbessert. Könnte man aber.
ui schrieb: > m.n. schrieb: >> Sieh Dir mal die Xmega an! > > wie war das mit 32-bit Architekturen, die sich nicht durgesetzt haben^^ > ;) > Außerdem, dann sind wir ja genau da: Kein DMA für 8-bitter! Alter, hol mal Luft und sieh Dir mal die Xmega genauer an :-(
ui schrieb: >> Sieh Dir mal die Xmega an! > > wie war das mit 32-bit Architekturen, die sich nicht durgesetzt haben^^ > ;) XMegas sind 8-Bitter. Einer der vielen Gründe für die 8-Bitter sind auch die Lizenzen, die sehr viele Fromen immer noch für die 8051 Architektur haben (das fängt bei TI und Silabs an und hört bei Winbond auf) und keine Gründe sehen, warum sie das für einfachere Steuerungsaufgaben nicht benutzen sollten. Gerade der 8051 ist ja ein Musterbeispiel für sauberen Code und vielseitige Architektur.
:
Bearbeitet durch User
Der Markt liefert das was benötigt wird. Also liegt das Problem beim Design. Die Komplexität der Elektroniken steigt stetig (ich kenne das aus automotive). Da hat man meist schon irrsinnige Anforderungen. Ich frage mich, warum ein Fensterheber LIN/CAN braucht. Auch Spoiler werden sicherheitsrelevant geplant. Da ist für 8-bitter kein Platz mehr. Auch wenn die Funktion (Spoiler raus und rein) leicht zu bewältigen wäre. Das Drumrum machts aus. Also wird die Entwicklung auch von den Konzernen getrieben. Da lässt sich dann leicht über Sinn und Unsinn streiten. Auch geht der Trend in Richtung automatischer Codeerzeugung und so weiter. Da wird der Speicher dann schnell zu klein. Und wenn man schon 500kB Flash braucht liegt es auch nahe auf 32bit umzusteigen. Ich hänge sehr an den 8-bittern aber die Entwicklung werden wir leider nicht aufhalten können.
ui schrieb: >> Es ist also die Bequemlichkeit der Entwickler die den 8 Bittern den >> Todesstoß versetzt, nicht der technische Fortschritt. Oder ein >> Glaubenskrieg. > > Gibt übrigens einen Ausdruck für sowas: Abstraktion. Die erkauft man > sich mit Overhead. > Hat auch gewaltige Vorteile (gerade für heutige Elektronikprodukte, die > möglichst schnell auf den Markt sollen): Man braucht sich mit den > Details erstmal nicht rumschlagen, sondern erst, wenn durch die > Abstraktion Fehler entstanden sind. Ja aber was will man bei 4 Buttons und einem Statusdisplay noch abstrahieren? Und welchen Vorteil so das bringen wenn auf der Kaffeemaschine ein Linux läuft? Mehr heiße Luft als Power - mehr HAL als Hardware. So seh ich das.
Bitwurschtler schrieb: > Und welchen Vorteil so das bringen wenn auf der Kaffeemaschine ein Linux > läuft? Das kann man auf die Packung schreiben. Alles Marketing.
> > Deswegen wird doch das SREG auf dem Stack gespeichert? Oder spielst du > auf den Zugriff der nicht komplett inkrementierten Variable in > Interruptroutine an? Genau das. Der Prozessorstatus ist nicht das Problem, wenn's da einen Bug gäbe, würde es sofort knallen. Fies ist, wenn es bloss alle paar Tage knallt..
ui schrieb: > Alter_Walder schrieb: >> Naja wenn da jemand mit AutoSar anfängt, dann brauch man ja fast ein den >> 32er nur für den ganzen Overhead der da erzeugt wird. > > So ein Bockmist hab ich selten gehört. > Auf welchen Overhead sprichst du an? RTE? Oder das ganze Zeugs darunter? > Betriebssystem? > Bevor man solche unqualifizerten Aussagen einfach so in dem Raum > schmeißt, sollte man sich damit mal beschäftigen. > Wie immer in der Informatik gilt auch da: "Das kommt drauf an". Ja in der Tat es kommt drauf an. Die Implementierung mit OS und RTE, die mir hier aufgewzungen wurde würde ein AVR richtig gut auslasten :D. Eine Bewertung der Qualität dieser Implementierung steht mir nicht zu, weils die erste ist mit der ich zu tun hab. (An sich ist die Idee dahinter ja sinnvoll) Aber naja die 32er werden wohl interessant wenn man sich schnell und einfach einsetzen kann. Wie die ATmegas halt. Die IDEs die von den Herstellern angeboten werden sind doch eh alles Eclipse-Derivate. Manche haben noch ein paar Plugins um die Pheripherie-Bibs einfacher benutzbar zu machen. Aber im grunde genommen ist es immer das gleiche. Was mich aber an diesen Bibs immer stört, ist das man da zwar schnell mal was zusammenwurschdeln kann, aber nicht wirklich genau weis wie die manchmal doch recht komplexe Peripherie funktioniert. Ich hab da immer so ein gefühl wie bei meiner alten Schrottkarre. Fährt zwar aber man weis nicht wie lange noch oder warum noch.
Matthias S. schrieb: > XMegas sind 8-Bitter. m.n. schrieb: > Alter, hol mal Luft und sieh Dir mal die Xmega genauer an :-( oh sorry, mein Fehler :/ Bitwurschtler schrieb: > Und welchen Vorteil so das bringen wenn auf der Kaffeemaschine ein Linux > läuft? Anbindung ans WLAN ist rel. einfach? Ich brauchs zwar nicht, aber so wird heute gedacht. Oder Anbindung ans Handy? Auf Linux entwickeln ist dann doch nochmal um ein gutes Einfacher als Bare-Metal. Bitwurschtler schrieb: > Ja aber was will man bei 4 Buttons und einem Statusdisplay noch > abstrahieren? Naja... Ein sehr überspitztes Beispiel. Aber gerade Arduino hat ja sehr viele Hobbyisten in die Welt der µC gebracht. Arduino abstrahiert ja auch enorm von der HW. Wenn man auf einem Arduino dann mal komplexere Dinge machen will, stellt man auch sehr schnell fest, dass - der Speicher zu klein ist - das Ding zu langsam ist (Hallo Abstraktionsoverhead) - manche Berechnungen ewig dauern (float) Und das erkauft man sich halt dann mit einer einfacheren Programmierung. (Ich sag nicht das das gut ist, das ist eine reine Beobachtung)
Paul R. schrieb: > Bitwurschtler schrieb: >> Und welchen Vorteil so das bringen wenn auf der Kaffeemaschine ein Linux >> läuft? > > Das kann man auf die Packung schreiben. Alles Marketing. Und genau so ist es für andere ein Kaufargument das gerade wenig Computer-Hokus-Pokus drin ist: http://www.heise.de/ct/ausgabe/2016-15-Schlagseite-3254925.html ;-)
Bitwurschtler schrieb: > also die Bequemlichkeit der Entwickler die den 8 Bittern den > Todesstoß versetzt, Nein, das Gewinnstreben des Managements das fordert Produkte schneller umzusetzen, Entwickler leichter ausgetauschbar sind, Abteilungen leichter verlagerbar werden. Und Kunden permanent nach billigeren Produkten mit mehr Funktionen schreien egal ob die besser sind oder nicht oder die Funktionen überhaupt benötigt werden. rgds
ui schrieb: >> Und welchen Vorteil so das bringen wenn auf der Kaffeemaschine ein Linux >> läuft? > > Anbindung ans WLAN ist rel. einfach? Ja. Mit ESP2866.
Bitwurschtler schrieb: > Und genau so ist es für andere ein Kaufargument das gerade wenig > Computer-Hokus-Pokus drin ist: > http://www.heise.de/ct/ausgabe/2016-15-Schlagseite-3254925.html ;-) Die sind aber leider in der Minderzahl :) Auch wenn es sinnvoll wäre. rgds
Alter_Walder schrieb: > Was mich aber an diesen Bibs immer stört, ist das man da zwar schnell > mal was zusammenwurschdeln kann, aber nicht wirklich genau weis wie die > manchmal doch recht komplexe Peripherie funktioniert. Das kenne ich, weil ich alles genau wissen will und niemandem so recht vertraue, aber ich denke, da muss man sich dran gewöhnen. Auf einem Computer mache ich mir auch keine Gedanken darüber, wie ein 'cout<<' arbeitet, sondern nutze es einfach, mit der Erfahrung, dass es normalerweise funktioniert. Bibliotheken können auch fehlerhaft sein, aber ich denke, es lohnt sich nicht, deswegen ewig Zeit mit jeder einzelnen davon zu verschwenden.
Alter_Walder schrieb: > Ja in der Tat es kommt drauf an. > Die Implementierung mit OS und RTE, die mir hier aufgewzungen wurde > würde ein AVR richtig gut auslasten :D. Eine Bewertung der Qualität > dieser Implementierung steht mir nicht zu, weils die erste ist mit der > ich zu tun hab. (An sich ist die Idee dahinter ja sinnvoll) schau dir mal Erika Autosar OS an. Läuft auch stabil auf einem AVR :) und da ist noch jede Menge Platz für Tasks :)
Ich könnte mir vorstellen, daß hauptsächlich die IoT Bewegung die 8-Bitter langsam aber sicher wie ein Hawaiischer Lavafluß ablösen wird. Wo früher ein 8-Bitter die markttechnischen und ingenieurmäßigen alle Anforderungen erfüllten, muß wegen der drastisch erhöhten Vernetzungsfunktionen ein leistungsfähiger uC her um alle neuen Andorderungen zu erfüllen. Die Entwicklung is dann mit 32- Bittern wahrscheinlich wegen dem reicheren Code Ökusystem wahrscheinlich zweckmäßiger. Dazu kommt, daß die Halbleiterfirmen die potenziellen Vermarkterfirmen mit leistungsfähigen Bausteinen zu füttern. Diese Vorgehensweise setzt dann Trends... Ist allerdings nur meine Vorstellung um das Warum.
:
Bearbeitet durch User
6a66 schrieb: > Nein, das Gewinnstreben des Managements das fordert Produkte schneller > umzusetzen, Entwickler leichter ausgetauschbar sind, Abteilungen > leichter verlagerbar werden. Tausch mal einen 32 bit Windows Entwickler mit einem 32bit Linux Guru aus - das ist nicht einfach DAS ist ein Glaubenskrieg. Dagegen ist so einem 8bit Bitwurschtler wurscht welche Nummer auf dem Gehäuse steht, Hauptsache man kann sich "Wahrer Bit-Magier" beweisen ;-) "Schneller fertig" zieh ich auch bei 32bit Kaffemaschine im Vgl zu 8 bit Maschine auch in Zweifel... Gewinnstreben ... mit Kapitalismuskritik hat die 8 bit Diskussion wenig gemein, auch wenn das scheinen mag wenn man schaut wie lang der Ostblock auf 8bit setzte: http://www.robotrontechnik.de/html/computer/industrieroboter.htm Eher im Gegenteil: mit 8bit ist die Marge besser weil IT-Kosten (Lizenzen/Schulung) geringer.
Gerhard O. schrieb: > Ich könnte mir vorstellen, daß hauptsächlich die IoT Bewegung die > 8-Bitter langsam aber sicher wie ein Hawaiischer Lavafluß ablösen wird. Wobei IoT IMHO noch nicht wirklich durchstartet. Sinnlose Funktionen, astronomische Preise und Sicherheitslücken à la MS Vista erfreuen nicht gerade. DIY Iot-Geräte werden trotzdem noch immer meistens mit entsprechender Zusatzhardware gebaut. Aber die Frage ist ja nicht ob 32 bit besser ist. Klar, in Bereichen, wo er benötigt wird schon. In anderen eben nicht. Dass die Entwicklung weitergeht ist auch klar. Ich frag mich eher wie lange es z.B noch den AVR gibt.
Paul R. schrieb: > Ich frag mich eher wie lange es z.B noch den > AVR gibt. Solang bis microchip sagt, den stellt ihr jetzt ein.
Paul R. schrieb: > Ich frag mich eher wie lange es z.B noch den AVR gibt. So lange wie die Produktion sich lohnt, also wie er in ausreichender Stückzahl nachgefragt wird. Nur ein Teil jener Kunden, die von AVR weg migrieren, wird statt dessen andere Microchip Controller verwenden. Der anzunehmend grössere Teil geht verloren.
8-Bit wird es noch lange zu kaufen geben, das ist klar. Aber gibt es heute noch 8-Bit Familien die aktiv weiterentwickelt werden?
Fitzebutze schrieb: > Ich möchte mal behaupten, dass ein 32 bit ARM Cortex M0 robuster zu > programmieren ist als ein AVR oder das n'te 8051 Derivat Keineswegs: Stichwort M0 unaligned load hardfault ui schrieb: > Außerdem, dann sind wir ja genau da: Kein DMA für 8-bitter! EFM8 8051 haben DMA Alter_Walder schrieb: > Wie sieht das eigentlich mit Die-Fläche aus? So ein AVR ist doch > Platzmässig bestimmt wesentlich kleiner als ein ARM Cortex M3 mit > gleicher Ausstattung? 8051 und M0 sind wesentlich kleiner zu haben als AVR: http://www.mouser.de/ProductDetail/NXP-Semiconductors/LPC11A04UK118/?qs=sGAEpiMZZMuleuVm2ofeXwSxz7NGthrP http://www.mouser.de/ProductDetail/Silicon-Labs/EFM8SB10F8G-A-CSP16/?qs=sGAEpiMZZMvqv2n3s2xjsX2zyxTNAb3cPBEqS5R1MUb1XG5hxpFxUA%3d%3d MaWin schrieb: > Es gibt unter Hobbyisten wohl genau 2 Pfade: > AVR und ARM(Cortex) Und in der Industrie nur 8051 und ARM ...
TriHexagon schrieb: > 8-Bit wird es noch lange zu kaufen geben, das ist klar. Aber gibt es > heute noch 8-Bit Familien die aktiv weiterentwickelt werden? In irgendeiner Elektor war mal was über die neuen AVR-Typen. Ich such dir die Nummer raus, wenns dich interessiert. Die wurden schon ein bisschen weiterentwickelt, gibts halt nur noch in SMD.
Paul R. schrieb: > Gerhard O. schrieb: >> Ich könnte mir vorstellen, daß hauptsächlich die IoT Bewegung die >> 8-Bitter langsam aber sicher wie ein Hawaiischer Lavafluß ablösen wird. > > Wobei IoT IMHO noch nicht wirklich durchstartet. Sinnlose Funktionen, > astronomische Preise und Sicherheitslücken à la MS Vista erfreuen nicht > gerade. DIY Iot-Geräte werden trotzdem noch immer meistens mit > entsprechender Zusatzhardware gebaut. > Der Hype wird seit ein paar Jahren immer wieder auf der Embedded World aufgewärmt, und wenn man dann genau hinschaut, ist es doch wieder der alte Käse. Eine IP-Implementation schreit natürlich schon ein bisschen nach 32 bit, aber wenn für ein Ding im Internet gleich ein Linux hermuss, kann man's gleich sein lassen - zumindest wenn es simpel, robust und sparsam sein soll. Die bisher interessanten Sachen in dem Bereich schienen mir: - cc430 (msp430 architektur, aber 16 bit): Leider dank des grottigen Simpliciti-Stacks nicht wirklich von den Usern geliebt worden - ESP8266/Xtensa 32 bit: Interessantes Konzept, nur auch leider nicht reif für die Industrie, das SDK ist nahezu unbrauchbar und hardwareseitig dürfte es auch noch einige Redesigns nötig haben. - Wiznet-51xx etc. (TCP-Stack aufm Silicon). Da kann man auch seinen 8-Bitter noch ranhängen, wenn man unbedingt will. > Aber die Frage ist ja nicht ob 32 bit besser ist. Klar, in Bereichen, wo > er benötigt wird schon. In anderen eben nicht. Dass die Entwicklung > weitergeht ist auch klar. Ich frag mich eher wie lange es z.B noch den > AVR gibt. Ich kenne (paranoide) Leute, die setzen die Dinger in der Industrie schon jetzt nicht mehr ein oder suchen sich nen vertrauenswürdigen Broker, der die Teile noch eine Weile lang führt. Ansonsten dürfte aber die Arduinobastler-Community auch noch etwas Monete umsetzen. Nur gibt's halt keine Garantie, wie lange es Typ XYZ noch gibt. Dürfte aber ähnlich wie beim PIC sein. Für mich geht der logische Weg in die Richtung, die Espressif verfolgt hat: Simplen, Code-kompakten 32-Bit-Core, der nicht viel kostet, zu nem fertigen SoC machen. ARM ist vom Core her zu teuer, könnte sein, dass uns aus der MIPS-Ecke noch einige Überraschungen aus China blühen (Wie schon die Mediatek-76xx chipsets).
Paul R. schrieb: > TriHexagon schrieb: >> 8-Bit wird es noch lange zu kaufen geben, das ist klar. Aber gibt es >> heute noch 8-Bit Familien die aktiv weiterentwickelt werden? > > In irgendeiner Elektor war mal was über die neuen AVR-Typen. Ich such > dir die Nummer raus, wenns dich interessiert. Die wurden schon ein > bisschen weiterentwickelt, gibts halt nur noch in SMD. Interessieren würde es mich schon, nur habe ich leider keine Elektor zur Hand. Im Internet finde ich leider nichts drüber...
TriHexagon schrieb: > Aber gibt es heute noch 8-Bit Familien die aktiv weiterentwickelt EFM8 8051 sind erst 2015 rausgekommen, EFM8LB erst dieses Jahr. Wir evaluieren grade die Umstellung von einem ARM Design, denn EFM8LB hat 14-bit 1MSPS ADC und 4x 12-bit DAC, da gibt es aktuell keinen ARM http://www.silabs.com/products/mcu/8-bit/Pages/efm8.aspx http://www.silabs.com/products/mcu/8-bit/efm8-laser-bee/Pages/efm8-laser-bee.aspx
Ist in Elektor Nr.541/542. Seite 34 35: seit Anfang 2015 AVR B-Typen 130nm-Prozess genauer RC-Oszillatoren Seriennummer mehr I/O Capacitive Touch in HW neue ATtinys nur im SMD-Gehäuse Eval-Bords: http://www.atmel.com/webdoc/atmega168pbxmini/index.html
Also mich beschleicht ständig das Gefühl dass die uns unbedingt ihren PC-gebundenen C-Code-per-USB-Ramsch aufdrängen wollen. Vielleicht damit sie jeden jederzeit ausspähen können -> NSA und Co. Fast habe ich Angst da ich ja im Moment etwas PC-unabhängiges bastle, hoffentlich kriege ich da keine Repressalien :-)
H-G S. schrieb: > Fast habe ich Angst da ich ja im Moment etwas PC-unabhängiges bastle, > hoffentlich kriege ich da keine Repressalien :-) Pass auf, dass du keinen NSL kriegst... :D
Die Notwendigkeit von Authentifizierung und (asymmetrischer) Verschlüsselung verbannt 8bit in den Bereich der Interfaceschaltungen für dumme Sensoren/Aktoren. Sobald es die nicht mehr gibt, war's das.
Dauergast schrieb: > Die Notwendigkeit von Authentifizierung und (asymmetrischer) > Verschlüsselung verbannt 8bit in den Bereich der Interfaceschaltungen > für dumme Sensoren/Aktoren. Sobald es die nicht mehr gibt, war's das. Diese Aussage finde ich ziemlich sinnlos. Die meisten 8bit AVR Typen sind nicht gar dafür gebaut Verschlüsselung zu betreiben. Eigentlich auch die 32 bit Typen nicht. Verschlüsselung und Authentifizierung benötigt man außerdem IMHO nur wenn es um Netzwerk geht. In solch einem Fall kommt dann (fast) immer ein OS (meist Linux) zum Einsatz. Ich habe noch keinen gesehen, der den kompletten TCP/IP Stack selbst implementiert hat. Das ist schließlich auch nicht die Aufgabe eines MC.
Die 32 Bit µC sind nur konkurrenzfähig, wenn sie mit kleinen Strukturen hergestellt werden. Entsprechend ist die Die Fläche nicht ganz günstig und die Spannung gering. Für Anwendungen die kräftige Treiber brauchen oder mit höherer Spannung laufen sollen, wird man auch in Zukunft noch eher die älteren FABs für eher größere Strukturen nutzen und da dann halt weiter 8 Bit µC produzieren. Für viele Aufgaben ist die Rechenleistung und Compiler Unterstützung ja auch vollkommen ausreichend. Selbst wenn nur die Anwendungen übrig bleiben, die mit 1 MHz oder weniger laufen ist das noch ein recht großer Marktanteil. Für die 4/8 Bit µC ohne Unterstützung durch C Compiler könnte es aber ggf. schon zu Ende gehen. Aber selbst da ist ggf. noch genügend Bedarf für alte Produkte um weiter zu produzieren so lange die alten Masken / Prozesse laufen. Bei so etwas wie RFID kommen auch noch Anwendungen mit hoher Stückzahl und geringen Anforderung dazu - ggf. sogar Raum für neue 4 oder 6 Bit µCs. Für kleine Anwendungen und hohe Anforderungen an die Zuverlässigkeit hat der eher einfache 8 Bit µC in Assembler Programmiert auch Vorteile - Compiler Bugs entfallen und die Errata List ist meist auch viel kürzer. So etwas wie ein 8051 ganz ohne Errata und gut geprüft wäre z.B. durchaus möglich - die ARMs dürften da noch einige Zeit von träumen.
MaWin schrieb: > Sie die 4-bitter ausgestorben ? > > Fast. > > Dabei eigenen sie sich zum Berechnung von Dezimalzahlen (Uhren, > Taschenrechner) besser als 8 bitter. Inwiefern? Das wäre (bestenfalls) nur dann der Fall, wenn es um ein einzelnes BCD-Digit ginge. Geht es aber praktisch nie. Und selbst wenn das doch ausnahmsweise mal der Fall sein sollte: alle brauchbaren 8-Bitter stellen natürlich spezielle Features zur effizienten BCD-Behandlung bereit, mit denen man notfalls auch ein einzelnes Digit erschlagen bekommt... Allerdings: auch µC mit mit noch höherer Verarbeitungbreite stellen oft spezielle Instruktionen und/oder Flags für den effizienten Umgang mit BCD-Zeugs bereit. Das "Problem" ist nur: C-Frickler können nicht unmittelbar davon profitieren. Deswegen ist (wie immer) die ultimative Lösung: Assembler. Naja, in vielen Fällen greift immerhin ein etwas begabterer C-Fetischist den völligen C-Idioten mit einer entsprechenden Lib unter die Arme. Wohl nur deshalb, damit die auf keinen Fall merken, wie beschränkt sie eigentlich durch C sind und so weiter so treudoof durch's Leben stolpern, wie es ihre Bibel und ihre Propheten vorgeben...
Paul R. schrieb: > Bis auf die PIC-Controller haben > fast alle Hersteller auf 32 Bitter gesetzt. Dieser Satz ergibt für mich keinen Sinn. Was heißt "auf 32 Bit gesetzt"? Und wieso sollen gerade PIC da außen vor sein, wo es doch sogar eine PIC32 Familie gibt? Ist es nicht vielmehr so, daß nahezu alle Hersteller von µC mehrere Pferde von 8 Bit bis 32 Bit im Rennen haben? > Sie sollten angeblich nach und nach alle 8 bit MCUs ablösen. Sagt wer? Ich halte mich da eher an Mark Twain: "Vorhersagen sind schwierig. Vor allem, wenn sie die Zukunft betreffen". > Trotzdem kommt es mir so vor, als würde das nicht funktionieren. > Laut Wikipedia haben die 8 bit MCUs immer noch den größten Marktanteil. So ist das wohl. > Meine Frage daher: Ist das Aussterben von 8 bit MCUs und speziell den > AVRs nur ein Wunsch der Hersteller Warum sollte das ein Wunsch der Hersteller sein? Wenn du ein Bäcker wärst und du würdest Brötchen und Baguettes verkaufen, würdest du dir dann wünschen daß die Brötchen von Baguettes verdrängt werden? Oder würdest du nicht weiter Brötchen und Baguettes backen, solange sich beide gut verkaufen? Aber gut, betrachten wir einfach mal die vielfach (wenn auch nicht von den Herstellern) geäußerte Prognose, 32-Bitter würden die 8-Bitter über kurz oder lang verdrängen. Und fragen uns, warum das anscheinend nicht passiert. Dann gibt es eine Menge Gründe: - 8-Bitter sind immer noch billiger als 32-Bitter. Gerade im Massenmarkt zählt da jeder Cent. Beim Bastler ist das natürlich anders. - 8-Bitter sind tendenziell robuster und leichter zu verarbeiten. Sie können 5V, kommen in China-tauglichen Gehäusen, brauchen keine teuren Mehrlagenplatinen mit Versorgungslagen. - existierende Designs mit 8-Bittern werden nicht ohne sehr triftigen Grund auf 32 Bit umgestellt. Wenn überhaupt, dann sterben diese Designs aus und werden von Neudesigns ersetzt. - 8-Bitter sind für viele oder gar die meisten Anwendungen vollkommen ausreichend, was Geschwindigkeit und Resourcen angeht. Das könnte sich mit dem IoT Hype ändern. Aber darauf wetten würde ich nicht. - als Firma legt man sich auf einen oder einige wenige µC, bestenfalls µC-Famlien fest. Das liegt daran, daß Tools (Hard- und Software) und Mitarbeiter (respektive deren Ausbildung) Geld kosten. So eine Investition wirft man nicht ohne sehr guten Grund weg.
c-hater schrieb: > Allerdings: auch µC mit mit noch höherer Verarbeitungbreite stellen oft > spezielle Instruktionen und/oder Flags für den effizienten Umgang mit > BCD-Zeugs bereit. Welche aktuell verbreiteten 32- und 64-Bit Prozessoren enthalten eigentlich BCD-Operationen, abgesehen von x86? Insbesondere auch in voller Breite, denn in 8 Bits wärs ja absurd. > nur deshalb, damit die auf keinen Fall merken, wie beschränkt sie > eigentlich durch C sind und so weiter so treudoof durch's Leben > stolpern, wie es ihre Bibel und ihre Propheten vorgeben... Kein Zweifel, der Bedarf für dezimale Arithmetik ist in bestimmten Märkten vorhanden, der Rundungseffekte wegen. Dies allerdings auf einem 64-Bit Boliden mit BCD-Arithmetik durchzuführen ist ungefähr so sinnvoll, wie Taschenrechner aus Röhren aufzubauen. Mit IEEE 854 wurde schon vor Jahrzehnten ein Standard für dezimale Fliesskommaverarbeitung definiert und mit IEEE 754-2008 konkretisiert. Wer dahinter aber BCD-Arithmetik vermutet, der liegt falsch. Es gibt es Prozessoren, die dezimale Fliesskommaformate in Hardware unterstützen (z.B. IBM ab POWER6). Selbstverständlich haben solche Datenformate in die entsprechenden Compiler Einzug gehalten, sowie als optionale Erweiterung in den C Standard. Folglich ist ein Rückgriff auf Assembler nur jenen empfohlen, die noch treudoof in BCD Formaten denken.
:
Bearbeitet durch User
Hier mal meine Erfahrung bzgl. 8 oder 32 bit im Heimbereich. Ein ca. 2-3 Jahre genutzter (SD-)Sat-Receiver. Eine Recherche ergab MIPS-basiert. MPEG2-Dekoder in Software. Abstuerze jeden Tag: Einer bis Mehrere. Immerhin waren die Entwickler so clever, der Konstruktion ein Watchdog auf das Video-Out-Signal zu spendieren. Dann machte der Receiver einen richtigen Kaltstart, inklusive dem Erloeschen der Betriebs-LED. Seine Nachfolger sind jetzt 8051-basiert mit HW-MPEG-Dekoder. Abstuerze sind bis jetzt noch nie aufgetreten, trotz erweitertem Funktionsumfang.
Paul R. schrieb: > Bis auf die PIC-Controller haben > fast alle Hersteller auf 32 Bitter gesetzt. Kannst Du das belegen?
... schrieb: > Eine Recherche ergab MIPS-basiert. MPEG2-Dekoder in Software. [...] > Seine Nachfolger sind jetzt 8051-basiert mit HW-MPEG-Dekoder. Ein SUUUPER Beispiel für 8-bit vs 32-bit! Respekt! Das die Entwickler beim ersten Pfusch abgeliefert haben, lag natürlich daran, das der µC 32 Bit hatte!
A. K. schrieb: > Welche aktuell verbreiteten 32- und 64-Bit Prozessoren enthalten > eigentlich BCD-Operationen, abgesehen von x86? Insbesondere auch in > voller Breite, denn in 8 Bits wärs ja absurd. In x86-64 sind die AAx/DAx Befehle übrigens rausgeflogen, und x87 mit seinem BCD-Format ebenfalls. Das sind zwar keine µCs, suggeriert aber ebenfalls, dass die Zukunft von BCD in der Vergangenheit liegt.
Dieter F. schrieb: > Paul R. schrieb: >> Bis auf die PIC-Controller haben >> fast alle Hersteller auf 32 Bitter gesetzt. > > Kannst Du das belegen? Ist nur meine Meinung basierend auf Werbung in diversen Medien. Immerhin werden von MC die PICs immer noch beworben. Andere Hersteller machen das nicht mehr wirklich. Ist aber nur meine subjektive Meinung...
Paul R. schrieb: >> Authentifizierung und (asymmetrischer) Verschlüsselung > Die meisten 8bit AVR Typen sind nicht gar dafür gebaut > Verschlüsselung zu betreiben. Genau. Es fehlen RAM und Rechenleistung. Da hilft auch Aufbohren nicht viel. > Eigentlich auch die 32 bit Typen nicht. Die schaffen derzeit gängige Verfahren aber problemlos, oft auch mit Hardwareunterstützung für Verschlüsselung und Keyablage. > Verschlüsselung und Authentifizierung benötigt man außerdem IMHO > nur wenn es um Netzwerk geht. Da hast Du natürlich Recht, ein handelsüblicher Nagelknipser braucht sowas derzeit nicht. Nicht mal 8bit ... naja, es sei denn, man verlegt ihn ständig, da wäre dann ein Ortungssystem schon sinnvoll ... aber nur, wenn nicht jeder drauf zugreifen kann. Ach Mist, der profitiert also auch von 32bit. > In solch einem Fall kommt dann (fast) immer ein OS > (meist Linux) zum Einsatz. Nein, wozu auch ? Braucht man nicht. > Ich habe noch keinen gesehen, der den kompletten TCP/IP > Stack selbst implementiert hat. Nein, wozu auch? Gibt's doch schon. > Das ist schließlich auch nicht die Aufgabe eines MC. OMG, das solltest Du unbedingt ARM, ST, TI, Renesas, Infineon und Konsorten mitteilen. Die entwickeln ja offenbar völlig an den Aufgaben eines MC vorbei ;-)
A. K. schrieb: > In x86-64 sind die AAx/DAx Befehle übrigens rausgeflogen, und x87 mit > seinem BCD-Format ebenfalls. Schon im Pentium 1 gab es keinen 'echten' math. Coprozessor mehr, nur dessen Register, die ganze Fliesskommaarithmetik wurde von den ALUs erledigt.
> Andere Hersteller machen das nicht mehr wirklich. Worin liegt der Unterschied zwischen "nicht mehr wirklich" und "nicht mehr"? > Ist aber nur meine subjektive Meinung... Worin ist der Unterschied zwischen "subjektive Meinung" und "Meinung"?
Ist doch eigentlich ganz einfach: 1) Es gibt mehr Designs in 8-Bit, da länger auf dem Markt 2) Dadurch haben viele Entwickler gute oder bessere Erfahrung mit 8-bit µC als im Vergleich mit 32 bit. Also machen sie neuen Designs auch in 8-Bit, wenn 3) zutrifft. 3) Für viele Design ist ein 8-bit µC ausreichend 4) Ein Redesign 8 auf 32 Bit macht man nur, wenn man muss! Also laufen diese 8-bit Designs in der Produktion oft lang. 5) Oft laufen noch 8-Bitter als Aktoren/Sensoren zusammen mit 32-Bit Hauptprozessoren, d.h. auf einen 32-bit µC kommen mehrere 8-bit. 6) Auch wenn der Preis der Cortex-M0 jetzt schon oft den von 8-bit µC unterbietet, ist oft die Stückzahl nicht so groß, dass ich a) deswegen ein Redesign bei einem bestehenden Produkt lohnt oder dass man Entwickler-Know-How über Bord wirft. Klar, ein Entwickler, der gute Erfahrungen mit Cortex-Mx Prozessoren hat, wird für ein Neudesign, welches zwar prinzipiell mit einem 8-Bit µC auskommen würde, einen Cortex-M0 nehmen.
HVV schrieb: > Schon im Pentium 1 gab es keinen 'echten' math. Coprozessor mehr, nur > dessen Register, die ganze Fliesskommaarithmetik wurde von den ALUs > erledigt. Die Fliesskommaeinheit ist in besagtem Pentium zwar im Prozessor und im Befehlsablauf integriert und somit kein Koprozessor mehr - aber die Berechnungen der Integer- und der Fliesskommaoperationen erfolgten vollständig voneinander getrennt. Gemeinsam verwendete ALUs gab es nicht im Pentium 1 und nicht danach. Ausser bei der Integer-Multiplikation, die über Konvertierung und Fliesskommarechnung implementiert war (Division weiss ich nicht mehr). Aber worauf ich raus wollte: In x86-64 flogen die entsprechenden Befehle und Register raus. Im 64-Bit Modus ist für Fliesskommarechnung nur noch SSE vorgesehen. Den Register-Stack und die Befehle des x87-Befehlssatzes gibt es darin (offiziell) nicht mehr. Und damit auch nicht mehr das x87-BCD-Format.
:
Bearbeitet durch User
Karl schrieb: > Worin ist der Unterschied zwischen "subjektive Meinung" und "Meinung"? Ganz einfach: Meine Meinung ist selbstverständlich stets objektiv. Sofern deine Meinung damit nicht übereinstimmt ist sie demzufolge subjektiv. ;-)
Dauergast schrieb: > Die Notwendigkeit von Authentifizierung und (asymmetrischer) > Verschlüsselung verbannt 8bit in den Bereich der Interfaceschaltungen > für dumme Sensoren/Aktoren. Sobald es die nicht mehr gibt, war's das. Also: 1. Es wird wohl in absehbarer Zukunft immer "dumme" Sensoren und Aktoren geben. Die sind nämlich einfach am billigsten herzustellen. 2. Es gibt keine generelle Notwendigkeit für Authentifizierung und (asymmetrische) Verschlüsselung. Die wird allein durch die Apologeten des "allways on" für jedes verschissene Device herbeigehypet. Nö: In meinem LAN ist es SICHER. Das einzige Device, was wirklich starke Authentifizierung und Verschlüsselung beherrschen muß, ist mein VPN-Gateway in Richtung des ungesicherten öffentlichen Netzes. So einfach ist das. Alles darüber hinaus gehende kann man durch Fraktionierung des LAN simpelst abbilden. Der Kern ist immer: Wer das Netzwerk seines LAN tatsächlich beherrscht, der braucht keine starke Kryptographie für jeden verschissenen Endpunkt. Und wer das nicht beherrscht, wird auch mit starker Kryptographie für jeden Endpunkt am Ende keine Sicherheit herstellen können. Dazu ist das System jedes einzelnen Endpunktes dann bereits viel zu komplex. Man stelle sich vor: Update-Orgien wie für Windows oder Linux, und das für jeden einzelnen verschissenen Sensor oder Aktor. Wer will das am Ende noch beherrschen...
Operator S. schrieb: > Einem Glaubenskrieg begegnet man am besten mit Fakten. > > Paul R. schrieb: >> Laut Wikipedia haben die 8 bit MCUs immer >> noch den größten Marktanteil. > > Würde mich auch wundern wenn es anders wäre. 8 Bit µC gibt es seit 40 > Jahren, die Cortex-M 32 Bit waren dagegen die ersten µC, welche eine > breite Akzeptanz erhalten haben. Damit strafst Du die Motorola 683xx und Coldfire mit unverdienter Mißachtung. Gruß, Holm
c-hater schrieb: > In meinem LAN ist es SICHER. Wenn - Du Dich auskennst - alle Mitnutzer Deines LANs sich ebenfalls auskennen - und/oder sich strikt an Deine Regeln halten - Niemand fremde Devices (IP-Cam, Handy, Spielekonsole) benutzt könnte es in Deinem LAN ziemlich sicher sein. Der Anteil privat betriebener Netze, auf die das zutrifft, liegt vermutlich bei 0,irgendwas %. > Wer will das am Ende noch beherrschen... DAS ist eine ganz andere Frage, bei der ich auch ganz bei Dir bin - allerdings ist Fachwissen dabei auch nicht das Allheilmittel (siehe z.B. Heartbleed). Aber es können ja auch nicht alle in den Wald umziehen und sich von Krabbelgetier ernähren :-)
2⁵ schrieb: > Klar, ein Entwickler, der gute Erfahrungen mit Cortex-Mx Prozessoren > hat, wird für ein Neudesign, welches zwar prinzipiell mit einem 8-Bit µC > auskommen würde, einen Cortex-M0 nehmen Keineswegs, wir nehmen ARM oder 8051 je nach Projekt, haben mit Keil auch dieselbe Toolchain. ARM meist wegen der Rechenleistung, 8051 wegen für ARM nicht verfügbarer Peripherie z.B. analog oder USB mit internem Oszillator. Bei ARM ist M3 meist der Vorzug vor M0 zu geben, bei gleichem Takt deutlich schneller zum praktisch selben Preis.
c-hater schrieb: > Inwiefern? Aus genau demselben Grund, warum ein 8 bitter besser zur zeichenorientierten Bearbeitung geeignet ist als ein 32 bitter. Die Schleifen und Adressen etc. gehen über die native Elementbreite. Keine Fragen des aligments und paddings. Keine doppelten Abfragen ob nun das carry oder half carry gesetzt war. Kein Verschnitt im Speicher weil das nächste Element erst an 8 bzw. 32 bit Grenze anfangen darf.
MaWin schrieb: > Aus genau demselben Grund, warum ein 8 bitter besser zur > zeichenorientierten Bearbeitung geeignet ist als ein 32 bitter. Der 32-Bitter hat dann zwar ein paar ungenutze Bits im Register übrig, aber weshalb sollte er dabei schlechter sein als der 8-Bitter? Bei 4 vs 8 Bits für Digits sieht es etwas anders aus, weil der 8-Bitter keine 4-Bit Objekte adressieren kann. Der 32-Bitter kann aber Bytes adressieren.
:
Bearbeitet durch User
A. K. schrieb: > Der 32-Bitter hat dann zwar ein paar ungenutze Bits im Register übrig, > aber weshalb sollte er dabei schlechter sein als der 8-Bitter? Genau richtig! Was seid Ihr denn für Elektronik Gruftis ? Das ganze kleinbitige uC Zeugsel verschwindet alles! Genauso wie die DIL Bausteine und die bedrahteten Widerstände! Die Dinger gibt es nur deshalb noch zu kaufen, weil sie in der weisen Ware massenweise ihr Unwesen treiben) Wer was auf sich hält, das kann man auch hier in den Foren feststellen, verbaut die ARM's von ST genauer gesagt die STM32F4xxx aufwärts.
Moby A. schrieb im Beitrag #4647617: > die Programmierung mit mehr Intelligenz > dramatisch zu vereinfachen Ist ja bereits jetzt schon der Fall! Wenn ich da an HAL denke - ein super Tool.
6a66 schrieb: > Und irgendwann brauchte man zum tippen > dieses Beitrags keinen Pentium mit 100MHz mehr sondern einen quadcore > mit >2GHz und endlos Speicher. Du hast recht! ich habe gerade auf meinen PC den DDR upgegradet auf 32 Gigis. Dann habe ich den Ressourcenmonitor aufgerufen und dann noch die HP42 Emulation aufgerufen. Da kann man zusehen, also ich sehe das bei meinen Penti, wie der hellblaue Bereich der Balkenanzeige sofort kleiner wird. Ich frage mich wo soll das ganze hinführen? Ich warte bereits auf die ersten Cortex ARM's die 1 Gig Ram haben und 4 Gig Flash besitzen. Und wenn man dann hier in den Foren liest scheitern die meisten Cortex Novizen mit dem Blinker Programm. (das Programm mit der LED) Bei mir war das leider auch der Fall. Da meine ich es ist gescheiter man bleibt doch bei den 8 Bitern. Seht ihr das genau so ?
Holm T. schrieb: > Damit strafst Du die Motorola 683xx und Coldfire mit unverdienter > Mißachtung. Tatsächlich habe ich noch nie etwas von denen gehört, ich ging immer davon aus, dass dies µProzessoren sind. Danke für die Richtigstellung.
A. K. schrieb: > In x86-64 sind die AAx/DAx Befehle übrigens rausgeflogen, und x87 mit > seinem BCD-Format ebenfalls. Das sind zwar keine µCs, suggeriert aber > ebenfalls, dass die Zukunft von BCD in der Vergangenheit liegt. War ein Ziel dieser Architektur nicht immer abwärtskompatibel zu bleiben? D.h. ein aktueller x86-64 wäre nicht in der Lage ein 15 Jahre altes Programm auszuführen in dem diese Befehle verwendet werden? Oder emuliert die CPU dann in Eigenregie diese Befehle?
Le X. schrieb: > War ein Ziel dieser Architektur nicht immer abwärtskompatibel zu > bleiben? Ist sie auch. > D.h. ein aktueller x86-64 wäre nicht in der Lage ein 15 Jahre altes > Programm auszuführen in dem diese Befehle verwendet werden? In den 16-Bit (8086/286) und 32-Bit Modi (ab 386) existieren diese Befehle noch. Im 64-Bit Modus hingegen nicht mehr.
Schwachsinnsdiskussion. Vor allem wird wieder übersehen, dass ein Großteil der Controller-Cores gar nicht in stand-alone MCUs verbaut wird. Mich interessiert nur RISC V.
Tim . schrieb: > Schwachsinnsdiskussion. Vor allem wird wieder übersehen, dass ein > Großteil der Controller-Cores gar nicht in stand-alone MCUs verbaut > wird. Die ARM, MIPS und POWER(PC) Architekturen finden sich in beiden Welten.
A. K. schrieb: > Die ARM, MIPS und POWER(PC) Architekturen finden sich in beiden Welten. Aber dafür gibt es im SOC-Bereic Tensilica, Andes, ARC usw. All diese wurden schon in Mrd-Stückzahlen eingesetzt... und 8051.
:
Bearbeitet durch User
Tim . schrieb: > Mich interessiert nur RISC V. Kannst du kurz schildern, welche Vorteile diese Architektur hat im Gegensatz zum Mainstream? Was gibt es an interessanter RISC V Hardware zu kaufen?
Ludwig schrieb: > welche Vorteile diese Architektur hat im > Gegensatz zum Mainstream? Keine Lizenzgebühren, große Unterstützerbasis, skaliert besser als ARM, in einigen Beispielimplementationen energieeffizienter. > Was gibt es an interessanter RISC V Hardware > zu kaufen? Bisher gibt es keine standalone MCUs auf dem Markt, dafür aber einige embedded implementationen. Es gibt bereits eine Menge softcores. https://riscv.org/ http://www.lowrisc.org/
Tim . schrieb: > Ludwig schrieb: >> welche Vorteile diese Architektur hat im >> Gegensatz zum Mainstream? > > Keine Lizenzgebühren, große Unterstützerbasis, skaliert besser als ARM, > in einigen Beispielimplementationen energieeffizienter. > >> Was gibt es an interessanter RISC V Hardware >> zu kaufen? > > Bisher gibt es keine standalone MCUs auf dem Markt, dafür aber einige > embedded implementationen. Es gibt bereits eine Menge softcores. > > https://riscv.org/ > http://www.lowrisc.org/ Vielen Dank für deine Antwort.
Conte schrieb: > Das ganze kleinbitige uC Zeugsel verschwindet alles! > Genauso wie die DIL Bausteine und die bedrahteten > Widerstände! Da muss ich Moby AVR (moby-project) absolut recht geben. Wirklich eingestellt werden bedrahtete Bauteile sicher nicht in (ich versuche mal eine vorsichtige Schätzung) den nächsten 50 Jahren. Steinigt mich, falls ich falsch liege. Zwar werden heute nahezu ausschließlich SMDs in Consumer-Elektronik verbaut, trotzdem werden DIPs und andere Bedrahtete noch hergestellt.
:
Bearbeitet durch User
Natürlich gibt's noch lange 8 Bitter. Die werden von 32 Bit genau so wenig verdrängt, wie der Radio die Zeitung, die E-Mail den Brief, das TV das Kino oder das Internet alles zusammen verdrängt hat. Es wird halt mal alles etwas durchgefegt, aufgeräumt, es gibt Veränderungen aber am Ende bleibt es wohl noch lange nebeneinander bestehen.
Tim . schrieb: > Bisher gibt es keine standalone MCUs auf dem Markt, dafür aber einige > embedded implementationen. Es gibt bereits eine Menge softcores. > > https://riscv.org/ > http://www.lowrisc.org/ Ich mag ja deinen Enthusiasmus für diese Architektur verstehen, nur zu sagen: Tim . schrieb: > Mich interessiert nur RISC V. scheint doch einen sehr eingeschränkten Horizont zu offenbahren. Selbst wenn wir uns nur auf den Softcore Bereich beschränken, so sind da andere Cores in der Vorreiterrolle. Selbst der preissensible Consumermarkt setzt auf Cortex-A cores, trotz Lizenzgebühren. Die Geschichte hat uns leider gelehrt, dass es nicht auf die technische Überlegenheit für eine Verbreitung und Akzeptanz der Technologie ankommt.
Zur µC-Infrastruktur gehört mehr als nur die Architektur, oder auch ein für die dafür gängigsten Herstellungsprozesse gebauter Core, der sie implementiert. Neben den I/O-Modulen, die oft vom Hersteller des µC gebaut werden, kommen noch andere generischere Module dazu, wie etwa Interrupt-Controller, Debug-Interface mit/ohne Trace-Möglichkeit und interne Busse. Als Luminary Micro (m.W. als erster) die Cortex M Familie nutzte, konnten sie auf einen Baukasten von ARM zurückgreifen, in denen die viele Module schon fertig vorhanden waren. Die ersten LM3 waren in weiten Teilen aus Fertigmodulen von ARM zusammengesetzt. Das führt nicht unbedingt zum bestmöglichen Design, erleichtert die Entwicklung aber erheblich und reduziert den Umfang der Vorfinanzierung in der Entwicklung. Lizenzgebühren können daher auch Kosten gegenüber Eigenentwicklung einsparen. Auch weil Fähigkeiten und Bugs der eingekauften Produkte bekannt sind. Eigenentwicklungen komplexer Produkte führen erst einmal zu eigenen Bugs, mit denen oft nicht nur die Entwickler der µCs selbst zu kämpfen haben, sondern auch die Anwender.
:
Bearbeitet durch User
Paul R. schrieb: > H-G S. schrieb: >> Fast habe ich Angst da ich ja im Moment etwas PC-unabhängiges bastle, >> hoffentlich kriege ich da keine Repressalien :-) > > Pass auf, dass du keinen NSL kriegst... :D Kurz nachdem ich den Text postete brach die Internetverbindung meines PC ab :-) BTT: es scheint dass der Adressraum eines 8-Bitters etwas knapp ist.
:
Bearbeitet durch User
H-G S. schrieb: > BTT: es scheint dass der Adressraum eines 8-Bitters etwas knapp ist. Wie groß ist "der" Adreßraum eines 8-Bitters denn deiner Meinung nach? Das war eine Fangfrage, es gibt gar nicht "den" Adreßraum. Bloß weil viele 8-Bitter einen 16-Bit Adreßraum haben, ist das nicht notwendigerweise bei allen so. ATmegas gibt es z.B. auch mit 128KB Flash (ganz abgesehen davon, daß sie als Harvard-Architektur sowieso gleich mehrere Adreßräume haben). STM8 hat einen unified Adreßraum mit 24-Bit Adressen. etc. pp.
Die Größe des Adressraums finde ich auch die viel entscheidendere Frage. Ob Daten 8 oder 32 Bit breit manipuliert werden, ist letztlich die Aufgabe des Compilers und tangiert den Programmierer eher wenig. Sobald der benötigte Adressraum aber überschritten wird, wird es sowohl für Chipdesigner als auch für Programmierer unangenehm (far-Pointer, A20-Gates, etc). Beim AVR kommt noch die Unterscheidung zwischen Flash und RAM hinzu, was der Havard-Architektur geschuldet ist. Auch beim 8051 ist es ganz selbstverständlich, daß komplett unterschiedliche Befehle benutzt werden müssen, je nachdem, in welchem Daten- oder Flashbereich die Daten stehen. Der bei 32Bit-Controllern übliche (68000, ARM) lineare Adressraum hat alle damit auftretenden Probleme nicht. Insgesamt ist daher eine 32Bit-CPU einfacher zu handhaben, und das betrifft sowohl Chipdesigner, Compilerbauer als auch Programmierer. Ich rede hier ausschliesslich von der CPU, natürlich ist ein CORTEX-M komplexer und schwieriger zu handhaben als ein AVR. Dies liegt aber nicht an der CPU, sondern an der wesentlich komplexeren Peripherie, die dafür auch deutlich mehr Möglichkeiten bietet. Natürlich sterben AVR etc. nicht so schnell aus. Schon allein wegen den unzähligen Produktlinien, in denen diese Controller eingesetzt werden. Einen Vorteil in der Produktion oder im Preis haben sie aber nicht mehr, selbst bei kleineren Controllern verschwindet die Die-Fläche des Cores gegenüber der von RAM und Flash. Viele Grüße, Stefan
Stefan K. schrieb: > selbst bei kleineren Controllern verschwindet die Die-Fläche des Cores > gegenüber der von RAM und Flash. http://flylogic.net/chippics/atmega88/atmega88c_lrg.jpg
Der Friedhof, auf dem die beerdigten 8-Bit Prozessoren liegen, wurde bereits vor Jahren - wegen Überfüllung - geschlossen. Natürlich kannst Du Dich, im morgendlichen Berufsverkehr, auch mit einem Formel-1-Renner bewegen. Würde mich aber nicht wundern, wenn der olle Käfer, der vorhin noch hinter Dir war, plötzlich vor Dir steht. Genau, wie der alte Käfer, für den Berufsverkehr besser geeignet ist, als irgendein Bolide, so gibt es auch so etwas wie einen "angepassten Prozessor" für die/Deine Entwicklung. Hast Du riesige Mengen an Daten zu bewältigen, brauchst Du eine Reaktionszeit im Pikosekunden Bereich, arbeitest Du ausschließlich mit großen Zahlen, so gilt: 16 Bit sind schneller und 32 Bit eventuell noch besser. Wie kommt es aber, dass die überwiegende Anzahl an Prozessoren 8 Bit haben – ist bis auf weiteres immer noch so. Nur Idioten sind es nicht; die bestehenden Bibliotheken lassen das Beibehalten des schmaleren Busses auch nicht übermäßig plausibel erscheinen. Selbst das: "Das haben wir immer schon so gemacht", zieht nicht immer. Höchstens das: "Wir haben alle Tools und auch die zugehörige Hardware im Haus", sowie "alle kennen sich damit aus", kann sich noch Lebensverlängernd auswirken. Die Antwort ist so einfach, dass es fast lachhaft ist: Die 8-Bitter reichen aus. Meist sind sie auch preiswerter. Übrigens: Oft bedeutet 2 mal 8 tatsächlich 16, will sagen, dass Dein eingebauter Speicher, plötzlich nur noch halb so groß - in Werten - ist. Viele 16- bzw. 32-Bitter müssen für den Zugriff auf 8-Bit Daten sogar Zwischenschritte machen. Auch der Programmspeicher - gerechnet in Programmschritten - wird plötzlich kleiner. Also ich bin nicht gegen "größere" Rechner, sondern für passende.
Mich stört im Moment eher dieses gepipelinete CPU-Design. Wenn man ein zeitkritisches Problem lösen muss und nicht weiss wie genau die Pipeline reagiert oder man auf ungenaue Interrupt-Abarbeitung zurückgreifen muss.
Amateur schrieb: > Die Antwort ist so einfach, dass es fast lachhaft ist: Die 8-Bitter > reichen aus. Meist sind sie auch preiswerter. Das ist eben leider nicht mehr so. STM32F070F6P6: 32kb Flash, 1000 Stück bei Mouser: 0,67€ 556-ATMEGA328PB-MU: 32kb Flash, 1000 Stück bei Mouser: 1,22€ Und der Grund ist ganz einfach: der Atmega ist in tausenden Projekten verbaut. Aus Preisgründen wird man sich für ihn für neue Produkte eh nicht mehr entscheiden. Also werden jetzt die laufenden Produkte gemolken. Der Preiskrieg findet eher bei den aktuellen Mcrocontroller-Produkten statt, und das sind immer mehr die 32-Bitter. Ich behaupte nicht, das es nicht genügend Gründe gibt, bei den bisher verwendeten 8-Bittern zu bleiben. Ein Umstieg kostet immer erstmal Geld. Wird aber - z.B. weil in einem größeren Projekt die Leistung gebraucht wird - auf einen 32-Bitter umgestellt, dann zählt eben die alte 8-Bit-Erfahrung nicht mehr und auch folgende Kleinprojekte werden dann mehr in 32Bit ausgeführt. Viele Grüße, Stefan
Die 8 Bit µC mit viel Speicher (so ab 16 Kbytes aufwärts) sind auch tatsächlich relativ teuer, weil bei den groben Strukturen der Speicher einiges an Fläche benötigt. Da wird dann bei viel Speicher der 32 Bit µC tatsächlich günstiger. Viele Anwendungen für 8 Bit µC kommen aber mit wenig Speicher (z.B. 4 K) aus.
Stefan K. schrieb: > Das ist eben leider nicht mehr so. Oh doch, das ist genau so. Nur weil du ein schlechtest Beispiel wählst, wird die Aussage nicht wahr. STM8S005K6T6CTR aus dem gleichen Haus schlägt den 32-bitter. Tatsächlich geht die STM8-Serie bis unter 20cent/Stück. EFM8 geht in die ähnliche Richtung, teilweise mit recht interessanter Peripherie. Oder finde mal einen 32-Bit USB-µC, der preislich nur ansatzweise an die EFM8UB-Serie herankommt. Abgesehen davon sind 1000 Stück keine große Stückzahl. Da machen 50cent/µC Mehrkosten nicht viel aus. Interessant wird es Richtung 6-stelligem Bereich.
Stefan K. schrieb: > STM32F070F6P6: 32kb Flash, 1000 Stück bei Mouser: 0,67€ > 556-ATMEGA328PB-MU: 32kb Flash, 1000 Stück bei Mouser: 1,22€ EFM8BB31F32G: 32kb Flash, 1000 Stück bei Mouser: 0,76€ Dieser 8051 mit 50 MHz hat aber nicht nur 13x 12-Bit ADC mit DMA sondern auch 2x 12-Bit DAC
Paul R. schrieb: > Ist das Aussterben von 8 bit MCUs und speziell den > AVRs nur ein Wunsch der Hersteller oder werden diese wohl so bald nicht > verschwinden? Ich war vor ein paar Wochen bei einem von einem Distrubutor veranstalteten Seminar, bei dem auch Vertreter von Microchip und Atmel vertreten waren. Beide beteuerten, dass sie durchaus noch eine längere Zukunft für ihre 8-Bit-Typen sähen. U.a. ist bietet das IoT einen großen Wachstumsmarkt mit den Anforderungen kurzes Time-To-Market, billig, klein, stromsparend, wobei sehr oft keine große Rechenleistung gefordert ist. Hier können die 8-Bitter noch sehr lange punkten.
mse2 schrieb: > bietet das IoT einen großen Wachstumsmarkt mit den Anforderungen > kurzes Time-To-Market, billig Solange Microchip die AVR Preise nicht Richtung PIC senkt wird AVR hier nichts reissen. Zumal 8051 hier noch vor PIC ganz weit vorn ist.
avr schrieb: > STM8S005K6T6CTR aus dem gleichen Haus schlägt den 32-bitter. Tatsächlich > geht die STM8-Serie bis unter 20cent/Stück. Beim gleichen Distri unter denselben Bedingungen verglichen: STM8S005K6T6CTR: 32kb Flash, 1000 Stück bei Mouser: 0,68€ EFM8BB31F32G-A-QFN32: 32kb Flash, 980 Stück bei Mouser: 0,71@ Sprich: Aktuelle Microcontroller liegen in ähnlichen Preisregionen, ob ein 8- oder 32-Bit-Core verbaut ist, spielt keine große Rolle mehr. Stückzahlen im 6-stelligem Bereich haben wir bei uns nicht laufen. Viele Grüße, Stefan
Stefan K. schrieb: > Aktuelle Microcontroller liegen in ähnlichen Preisregionen, ob ein 8- > oder 32-Bit-Core verbaut ist, spielt keine große Rolle mehr. Ich hab einen Controller mit gleich viel Flash herausgesucht. Deswegen kannst du doch nicht gleich eine Behauptung für alle Controller aufstellen. STM8S003F3U6TR 8KB 0,353€ EFM8BB10F2G-A-QFN20 2KB 0,281€ Wenn ihr natürlich nur 1000 Stück verbaut, ist das natürlich egal. Das sind keine großen Stückzahlen.
> Lizenzgebühren können daher auch Kosten gegenüber Eigenentwicklung > einsparen. Auch weil Fähigkeiten und Bugs der eingekauften Produkte > bekannt sind. Eigenentwicklungen komplexer Produkte führen erst einmal > zu eigenen Bugs, mit denen oft nicht nur die Entwickler der µCs selbst > zu kämpfen haben, sondern auch die Anwender. Wenn Du einen SOC in >10 mio Stückzahlen herstellst, sind 0.05 USD Lizenzgebühren relevant. Dafür kann man einen Ingenieur bezahlen, der sich in einen neuen Core einarbeitet. In solchen Bereichen macht ARM keine Freude. Deswegen findet man dort auch Dinge wie Andes Core, ARC, OpenMSP430 und demnächst wohl auch häufiger eine RISC V Implementierung. Das oben genannte Peripherieproblem spielt hier kaum keine Rolle, da sowieso auf standardisierte Busse zurückgegriffen wird. Bis RISC V für MCUs relevant wird, wird es aber wohl noch etwas dauern. Ich setzte da auf die ganzen Fabless-Startups in China, die in den Startlöchern stehen. Irgendwie müssen die neuen Fabs ja gefüllt werden...
:
Bearbeitet durch User
avr schrieb: > Ich hab einen Controller mit gleich viel Flash herausgesucht. Deswegen > kannst du doch nicht gleich eine Behauptung für alle Controller > aufstellen. Ich habe Controller mit gleicher Flash-Größe (32kb) bei denselben Stückzahlen (1000 Stück) verglichen, und da sind die Preise nahezu identisch, egal welcher Core vebaut ist. Natürlich kann es sein, dass sich die Preise bei hohen Stückzahlen etwas verschieben, wobei ich mir nicht vorstellen kann, daß z.B. ST bei seiner STM8-Serie einen wesentlich anderen Stückzahlen-Rabatt als bei seiner STM32-Serie vergibt. Viele Grüße, Stefan
Le X. schrieb: > A. K. schrieb: >> In x86-64 sind die AAx/DAx Befehle übrigens rausgeflogen, und x87 mit >> seinem BCD-Format ebenfalls. Das sind zwar keine µCs, suggeriert aber >> ebenfalls, dass die Zukunft von BCD in der Vergangenheit liegt. > > War ein Ziel dieser Architektur nicht immer abwärtskompatibel zu > bleiben? > D.h. ein aktueller x86-64 wäre nicht in der Lage ein 15 Jahre altes > Programm auszuführen in dem diese Befehle verwendet werden? > > Oder emuliert die CPU dann in Eigenregie diese Befehle? So wie ein ARM auch Thumb spricht, kann auch ein x86 mehrere Befehlssätze ausführen. BCD gibt es natürlich auch in der x64-Welt, nur nicht Byteweise und auch nur per Software, aber viel schneller als die 8080 Relikte. Bei der Frage, welche Architektur, kann manchmal die Einheitlichkeit entscheidend sein. Wenn die Motorsteuerung mit 32bit ARM läuft, dann wird man für den LIN-Knoten in der Tür vielleicht lieber ARM als PIC nehmen, es sei denn diese sind auf Grund der Menge um viele Programmierer-Tagessätze teurer. Ein entsprechender Bonusplan im Einkauf kann aber auch entscheidend sein.
Gerhard O. schrieb im Beitrag #4648736: > Jedenfalls finde ich es immer etwas spassig wenn beim uC so mit die > Cents geknausert wird und der Rest des Gerätes noch um ein Vielfaches > minderwertiger ist Anders als bei Mechanik, Elektrik und Design wo besser tatsächlich mehr kostet, muss das in der Elektronik nicht so sein. Ein robuster uC kann, wenn in Stückzahlen nachgefragt, günstig sein, und ein schlecht designter uC kann teuer sein. Bei einem hochwertigen Gerät sollte das dann während der Entwicklung bemerkt werden.
Lothar schrieb: > Gerhard O. schrieb im Beitrag #4648736: >> Jedenfalls finde ich es immer etwas spassig wenn beim uC so mit die >> Cents geknausert wird und der Rest des Gerätes noch um ein Vielfaches >> minderwertiger ist > > Anders als bei Mechanik, Elektrik und Design wo besser tatsächlich mehr > kostet, muss das in der Elektronik nicht so sein. Ein robuster uC kann, > wenn in Stückzahlen nachgefragt, günstig sein, und ein schlecht > designter uC kann teuer sein. Bei einem hochwertigen Gerät sollte das > dann während der Entwicklung bemerkt werden. Tut mir leid, Lothar, ich löschte meinen Beitrag wieder weil es mir irgendwie im Nachhinein als unpassend erschien. Grüße, Gerhard
Lothar schrieb: > Gerhard O. schrieb im Beitrag #4648736: >> Jedenfalls finde ich es immer etwas spassig wenn beim uC so mit die >> Cents geknausert wird und der Rest des Gerätes noch um ein Vielfaches >> minderwertiger ist > > Anders als bei Mechanik, Elektrik und Design wo besser tatsächlich mehr > kostet, muss das in der Elektronik nicht so sein. Ein robuster uC kann, > wenn in Stückzahlen nachgefragt, günstig sein, und ein schlecht > designter uC kann teuer sein. Bei einem hochwertigen Gerät sollte das > dann während der Entwicklung bemerkt werden. Das sehe ich genau so.
Stefan K. schrieb: > Das ist eben leider nicht mehr so. > > STM32F070F6P6: 32kb Flash, 1000 Stück bei Mouser: 0,67€ > 556-ATMEGA328PB-MU: 32kb Flash, 1000 Stück bei Mouser: 1,22€ Ich finde der Vergleich hinkt. ST pflegt seine Controller kaum, und je “billiger“ dann geht die Pflege auf 0. Schonmal die Errata Liste des erwähnten stm8s003 gesehen? Ja ist billig aber mit sehr vielen Einschränkungen. Ein Tapeout mit neuer Revision kann einige hundert k$ Kosten und das rentiert sich bei billig nicht. Wie lange ist stm8s auf dem Markt und wann wurden die teilweise kritische Errata gefixt? Das zeigt dass es St Qualität egal ist, hauptsache die Kunden fallen auf den niedrigen Preis rein.
Stefan K. schrieb: > Ich habe Controller mit gleicher Flash-Größe (32kb) bei denselben > Stückzahlen (1000 Stück) verglichen, und da sind die Preise nahezu > identisch, egal welcher Core vebaut ist. ISt durchaus richtig... Dennoch hast du dabei einen Denkfehler! Die Domäne der 8 Bitter wird in der Zukunft vor allem bei den einfachen Anwendungen liegen. Anwendungen wo man mit einigen hundert bis zu wenigen tausend kByte an Speicher auskommt. Anwendungen wo die 2kByte Progammspeicher und 256 Byte RAM des weiter oben genannten EFM8BB10F2G mehr als genug sind. Wenn aber klar ist, das ich z.B. 1,5 kByte Flash und 180Byte Ram für mein High Volume Produkt benötige, dann Interessiert mich einzig der Preis den ich für die Bausteine bezahle die diese Anforderungen erfüllen. Bei den CortexM0 waren jetzt 4kByte Flash und 1kByte RAM das kleinste was ich auf die Schnelle gefunden habe. Mag sein das es kleinere gibt, ist aber dann WEIT abseits des Mainstream - und auch des Bereiches in dem die echten Kampfpreise gemacht werden. (Die sind ja manchmal sogar nur für ganz ausgewählte Typen eines HErstellers so niedrig... Ist aber von Hersteller zu Hersteller unterschiedlich ) Dafür zahle ich rund 40ct. Bei den 8 Bittern bekomme ich aber problemlos Typen mit nur wenigen hundert kByte Flash und sogar unter 100Byte RAM wenn ich möchte. Oder halt den genannten EFM8 mit 2kByte/256Byte für ~20ct. Klar, der M0 kann mehr im direkten Vergleich. Aber ich kann mit dem "mehr" in diesem Fall nichts Anfangen. Mich interessiert nur was ich brauche. (Wobei man wenn man es genau betrachten wollte auch die Speichergrößen nicht direkt vergleichen dürfte. Wenn man schon die Preise anhand der Leistngsmerkmale vergleichen will, dann muss man für einfache Anwendungen bei den 32Bittern welche nehmen deren RAM 4x so groß ist wie der von 8 Bittern. Denn bei einfachen Projekten hat man es in der absoluten Überzahl der Fälle mit 8Bit Werten zu tun. Die Zahl an "breiteren" variablen hält sich bei solchen Projekten meist in sehr übeschaubaren Grenzen. Auf einem 32Bitter bedeutet das aber das man entweder Klimmzüge machen muss um mehrere Variablen in eine Speicherzelle zu quetschen oder aber das man pro Variable 3 Byte einfach ungenutzt verschenkt... Aber wie gesagt, das ist eh irrelevant da man wie schon geschrieben ja beim driekten Vergleich eh einer Milchmädchenrechnung auf dem Leim geht) Daher ist der Vergleich anahnd identischer Leistungsmerkmale absolut witzlos. Das ist "Bastlerdenke" wo man sich erst den tollsten Controller aussucht und dann die Projekte die man damit macht... Man muss den Vergleich von der Seite der Projekte aufziehen. Also nach der Art: Das möche ich machen, welche Leistungsmerkmale brauche ich... Und da liegen für viele einfache bis mittlere Anforderungen die 8Bitter immer noch sehr weit vorn. Wenn es dann aber komplexer wird, dann kehrt sich das hingegen sehr schnell um. Da ziehen die 32Bitter dann schnell vorbei! Zumindest so lange man nicht auf Spezialperiepherie angewiesen ist Wenn denn Spezialperipherie in Spiel kommt, da liegen die 8 Bitter zur Zeit definitiv noch weit vorn. (Wobei das keine Frage der Technologie sondern der Produktstrategie die HErsteller ist) Die gängigen 32Bitter haben üblicherweise Standardperipherie bis zum Abwinken. Timer, AD Kanäle usw. bis zum Abwinken. Was der Baukasten hergibt! Aber wird es etwas spezieller und es geht um Periperie die im schönen ARM/MIPS usw. IP Baukasten nicht mehr Berücksichtigt ist, dann wird es eng. Wobei man in der 8Bit Welt die tollste Auswahl hat. Aber wie gesagt, das ist keine Frage der Technologie sondern einfach von den Strategen so vorgesehen. Es zeigt aber sicher auch in welchen Einsatzbereichen die Hersteller die Zukunft für das jeweilige Produkt sehen. Bei den 8Bittern halt im absoluten LowEnd bereich UND aber im Bereich der Datenerfassung (Sensorik) mit wenig Rechenbedarf, aber viel Spezialtechnik. Bei den 32Bittern im Bereich der Datenverarbeitung und komplexer Steuerung... Gruß Carsten
:
Bearbeitet durch User
Carsten S. schrieb: > Auf einem 32Bitter bedeutet das aber das man entweder Klimmzüge machen > muss um mehrere Variablen in eine Speicherzelle zu quetschen oder aber > das man pro Variable 3 Byte einfach ungenutzt verschenkt... Auf welcher Architectur hats Du den gearbeitet. Arm Cortex kann Byte-Zugriffe...
Ich denke auch, dass es noch recht lange 8bitter geben wird. Und wenn es der blöde PIC16F84A ist ;) Vorallem interessieren sich die Hersteller auch "nur" für die Zahlen bzw Umsätze. Und da spielen die "paar" abgenommenen µCs von Hobbyisten keine große Rolle. Die Hersteller bringen aber immernoch neue 8bitter raus, zumindest Microchip und ST (werden aber sicherlich nicht die einzigen sein). Wieso sollten sie das machen, wenn es keine Abnehmer gibt? Wenn ich mich richtig erinnere, baut AUDI in die Scheinwerfer 8bit- oder 16bit-PICs ein. Ich gucke bei jedem Projekt neu, welchen µC ich nehme. Da ich bisher alles mit PICs gemacht habe, kenne ich nur diese Seite. Doch ich denke, dass es bei ARMs nicht anders aussieht. Ich finde nämlich schon, dass die 32bitter umständlicher (wenn es natürlich auch nicht unmöglich ist) zu handhaben sind. Gefühlt 100 Taktquellen, die Config-Register für Timer, SPI, PWM, ADC usw sind um ein vielfaches mehr.. Da braucht man ja schon nen kByte Flash nur fürs Initialisieren der Module und bis die CPU so läuft, wie sie soll. Das ist bei nem 8bitter m.M.n. deutlich einfacher, schneller programmiert und platzsparender. Das Argument, dass es ein 32bitter genausogut kann und preislich kaum ein Unterschied ist, mag stimmen. Trotzdem bin ich kein Fan von dieser Ressourcenverschwendung. Ist wohl eine Einstellungssache. Ich denke, dass diese "Hauptsache schnell was neues, kack egal, ob es effizient oder sauber ist, es geht ja"-Einstellung fast gefährlich ist. Das ist aber nicht nur in der Elektronik so, sondern auch bei Filmen oder Spielen. Und auch hier wird nur das verkauft, was von der Mehrheit verlangt wird. Mir geht das irgendwie auf die Nerven. Es ist schon soweit, dass die Blitz-LED-Anschalt-App fürs Android-Phone 5MB groß ist, was vmtl nur das Setzen eines Bits ist. Aber hey... Es geht ja auch so und der Speicher ist ja groß genug. So kann man den Fortschritt auch voran treiben. Irgendwann sind in den Handys ultrakleine, stromsparende Terabyte-Speicher verbaut, auf dem die 4GByte-Facebook-App installiert ist, die einfach nur Kommentare und Bilder anzeigen kann. Zusammen mit dem 2GByte Messenger, der.... Nachrichten verschicken und empfangen kann. Aber der Platz ist ja da und der Hexadeci-1.8GHz-Core kann gleichzeitig die unscharfen 30Megapixel Selfies über das 8G-Netz jagen... Mich würde mal interessieren, wie sehr man die heutige Hardware ausreizen kann. Vermutlich würden einige das hinkriegen, wo die meisten nach deutlich mehr Power schreien. Ich jedenfalls schaue zuerst, was der µC für mein Projekt können und haben muss, gebe diese Sachen dann bei der Microchip-µC-Suche an und gucke die Liste durch, die ich erstmal nach Preis sortiere. Wobei ich zuerst die 32bitter ausblende. Und trotzdem finde ich immer einen passenden µC. Meine Meinung ;)
:
Bearbeitet durch User
Paul R. schrieb: > 6a66 schrieb: >> werden sich auf lange Sicht sicher durchsetzten. > Will sagen die Zeit ist die nächsten Jahre noch nicht reif? Wenn ein Hersteller hunderttausend Stück von einem Massengerät herstellen soll und für die Anwendung ein 4Bit-MC mit 512 Anweisungen reicht, dann wird das Teil auch verbaut. Deswegen hat so eine Kaffeepadmaschine auch ein Kondensatornetzteil für die Speisung der Elektronik und den einfachstmöglichen MC. Bei manchen Sachen braucht man einfach nicht mehr. Vielleicht gibt es in 100 Jahren nur noch irgendeinen einzigen allpurpose-MC der alles kann, kaum Leistung braucht und den man überall draufdrucken kann und man stellt einfach nur noch dieses Ding her weil es das günstigste ist und für alles nutzbar. Bis dahin werden passende Bauteile für die Anwendung auf Grund von wirtschaftlichen Erwägungen gewählt und je weniger Chipfläche desto günstiger sind die Chips herstellbar. Mit fortschreitender Technik wird versucht die Dinger noch günstiger zu machen und nicht noch komplexer.
:
Bearbeitet durch User
Paul R. schrieb: > Ist das Aussterben von 8 bit MCUs [...] nur ein Wunsch der Hersteller > oder werden diese wohl so bald nicht verschwinden? Es ist durchaus möglich -- Texas Instruments hat praktisch keine 8-Bitter mehr, und fährt mit den MSP430s gar nicht mal so schlecht. (Ein MSP430G2001 z.B. hätte anderswo einen 8-Bit-Kern.) 16 Bits sind aber auch nicht 32 Bits, und die anderen Hersteller sind nicht kollektiv dem Wahnsinn verfallen, wenn sie trotzdem noch 8-Bitter herstellen.
weil oben die Frage kam, ob es neue, weiterentwickelte 8 Bitter gibt: z.B. Microchip hat die neueren 8 Bit PIC's mit CLC's (configurable logic cell) ausgestattet + ECC Flash. lg Heiner
Michael S. schrieb: > Ich gucke bei jedem Projekt neu, welchen µC ich nehme. Da ich bisher > alles mit PICs gemacht habe, kenne ich nur diese Seite Microchip setzt doch grade auf PIC32 in ganz kleinen Packages als Drop-in ab PIC10 und teilweise sogar billiger: http://www.microchip.com/promo/pic32mm > Ich jedenfalls schaue zuerst, was der µC für mein Projekt können und > haben muss Soweit die Theorie. In der Praxis gibt es schon eine Toolchain, in der Industrie fast immer 8051 und ARM und da wird dann zuerst gesucht.
Lothar schrieb: > Microchip setzt doch grade auf PIC32 in ganz kleinen Packages als > Drop-in ab PIC10 und teilweise sogar billiger: Wie soll denn so ein sauteurer (ca. das doppelte eines PIC10F200) und stromfressender (0,5 mA bei 1MHz!) Bolide mit extrem vielen Pins (min. 20) einen 10F200 im 6-Pin SOT23-Gehäuse, der in einem Akku-betriebenen System (VCC = 3,0 .. 4,2V!) eingesetzt wird, sinnvoll ersetzen?
:
Bearbeitet durch User
Michael S. schrieb: > Da braucht man ja > schon nen kByte Flash nur fürs Initialisieren der Module und bis die CPU > so läuft, wie sie soll. Das ist bei nem 8bitter m.M.n. deutlich > einfacher, schneller programmiert und platzsparender. Das ist nur die halbe Wahrheit. Die üblichen 8 Bitter benötigen deutlich weniger an Feinheit bei den Strukturen als 32 Bitter - logo, wo hier nur 8 Datenleitungen quer über den Chip gezogen werden müssen, sind es dort eben 32. Das ist so ähnlich wie Leiterplatte routen. Man kommt also mit gröberen Strukturen aus und das ist regelmäßig ein deutlicher Vorteil in der langfristigen Zuverlässigkeit des Chips. Auch unter Streßbedingungen wie Temperatur und kosmische Strahlung. Aber ebenso bei der Nutzungsdauer - wie lange bleiben die Ladungen auf einem floating gate erhalten? Mal so im Vergleich zum maskenprogrammierten Chip? Kurzum, eine simpler gestrickter 8 Bitter mit deutlich gröberen Strukturen auf dem Stein ist per se zuverlässiger als ein 32 Bitter, der notwendigerweise mit feineren Strukturen und kleineren Ladungen auf dem Flash-Speicher daherkommen muss als ersterer. m.n. schrieb: > Sieh Dir mal die Xmega an! langsam bitte... Thema war DMA. Ich frag dich mal, wozu man ne DMA tatsächlich braucht. Bei dedizierten Peripherie-Cores wie z.B. einem TFT-Controller mit DMA-Fähigkeit sieht man das sofort ein. Aber ein ganz gewöhnlicher DMA, dessen Fähigkeit sich auf das Umschaufeln von A nach B erschöpft? Wozu sowas? Letztendlich sind es immer wieder Daten, die verarbeitet werden sollen und das kann nur ne CPU per ausreichend klugem Programm - aber keine DMA. Und ob die CPU die Daten von A oer von B holen muß, ist wumpe. Ich halte den Beitrag, auf den du geantwortet hast, für pure Trollerei. W.S.
Heiner schrieb im Beitrag #4650875: > Thomas E. schrieb: >> Lothar schrieb: >>> Microchip setzt doch grade auf PIC32 in ganz kleinen Packages als >>> Drop-in ab PIC10 und teilweise sogar billiger: >> >> Wie soll denn so ein sauteurer (ca. das doppelte eines PIC10F200) und >> stromfressender (0,5 mA bei 1MHz!) Bolide mit extrem vielen Pins (min. >> 20) einen 10F200 im 6-Pin SOT23-Gehäuse, der in einem Akku-betriebenen >> System (VCC = 3,0 .. 4,2V!) eingesetzt wird, sinnvoll ersetzen? > > Full Ack, Hauptsache blub, blub. > > lg Heiner Ich finde das Marketing Gebrabbel von Microchip auch unerträglich. Klar, solange es um Kaffeemaschinen und LED Leuchten geht sind PICs die erste Wahl. Damit haben sie ja auch großen Erfolg. Doch sobald es ans Eingemachte geht - richtige Anwendungen - bleiben nur noch ARM und Renesas. PIC32 interessiert doch niemanden. Das hat Microchip ja auch selbst inzwischen erkannt und gerade noch rechtzeitig Atmel gekauft. Sonst hätten sie eher früher als später einräumen müssen dass der PIC32 gegenüber dem Cortex-M nie eine Chance hatte. PS: Ich brauche aktuell einen PIC (gerne 8Bit) der >= 5 Touch-Buttons abfragen kann und mit einer CR2032 versorgt mind. 1 Jahr lang läuft.
Hier ein EDN Artikel zum Thema: http://www.edn.com/electronics-blogs/embedded-insights/4440832/8-bit-isn-t-dying--it-s-growing
Lothar schrieb: >> Ich jedenfalls schaue zuerst, was der µC für mein Projekt können und >> haben muss > > Soweit die Theorie. In der Praxis gibt es schon eine Toolchain, in der > Industrie fast immer 8051 und ARM und da wird dann zuerst gesucht. Daher schrieb ich auch, dass ich es so mache. Und da ist es auch in der Praxis so, dass ich die IDE und ein Programmer für PICs habe, dazu Erfahrung mit PICs. Und solange ich mit den verschiedenen PICs zurecht komme und für mich ausreichend Power haben, wechsle ich nicht zu einer anderen Familie. Andere Datenblattaufmachung, neue Tools/Hardware und IDE, Zeit zum Einarbeiten und nur, damit ich sagen kann, ich habs mit einem ARM statt PIC18 gemacht? Ne, da investiere ich lieber die Zeit und Geld in wichtiges. W.S. schrieb: > Michael S. schrieb: >> Da braucht man ja >> schon nen kByte Flash nur fürs Initialisieren der Module und bis die CPU >> so läuft, wie sie soll. Das ist bei nem 8bitter m.M.n. deutlich >> einfacher, schneller programmiert und platzsparender. > > Das ist nur die halbe Wahrheit. Die üblichen 8 Bitter benötigen deutlich > weniger an Feinheit bei den Strukturen als 32 Bitter - logo, wo hier nur > 8 Datenleitungen quer über den Chip gezogen werden müssen, sind es dort > eben 32. Das ist so ähnlich wie Leiterplatte routen. Man kommt also mit > gröberen Strukturen aus und das ist regelmäßig ein deutlicher Vorteil in > der langfristigen Zuverlässigkeit des Chips. Auch unter Streßbedingungen > wie Temperatur und kosmische Strahlung. Aber ebenso bei der > Nutzungsdauer - wie lange bleiben die Ladungen auf einem floating gate > erhalten? Mal so im Vergleich zum maskenprogrammierten Chip? Was die Struktur im Inneren angeht, da bin ich der falsche Mann für, da kenne ich mich nicht gut genug aus. Mir ging es um die Programmierung und das Hintergrundwissen. Natürlich, die Module im PIC32 haben deutlich mehr Funktionalität und die muss konfigurierbar sein. Doch das ganze kram habe ich noch nie gebraucht und dann sind die Module in 8bit PICs zwar "schlechter" oder eher "simpler", gehen einem aber dadurch auch schneller von der Hand. Mir zumindest. Stefan schrieb: > Ich finde das Marketing Gebrabbel von Microchip auch unerträglich. Klar, > solange es um Kaffeemaschinen und LED Leuchten geht sind PICs die erste > Wahl. Damit haben sie ja auch großen Erfolg. > Doch sobald es ans Eingemachte geht - richtige Anwendungen - bleiben nur > noch ARM und Renesas. Definiere richtige Anwendungen.. Wenn ich mich in meiner Wohnung umgucke, sehe ich viele elektronische Geräte. Doch mein Smartphone, mein PC und der Fernseher sind die einzigen Geräte, bei denen es wirklich um Datendurchsatz geht. Ist die Entwicklung von Waschmaschinen, Kaffeeautomaten, DECT Telefonen unrelevant und zählt zu den nicht richtigen Anwendungen? Was ist mit Geräten mit digitalen Filtern und ähnlichen. Da werkelt auch öfter mal ein DSP drin. Auch keine richtige Anwendung? Ich denke auch, wenn es ums "eingemachte" geht, sind sehr oft SOCs zusehen. Und dort ist dann ein uC mit eingebaut, um die ganze Funktionalität verarbeiten zu können. Also auch nicht immer die blanken ARMs a la STM32F4 oder ähnliches. Dort wird dann sicherlich ein schneller 32bitter eingebaut, um alle Kunden zu bekommen und nicht nur die, denen ein 8051 reichen würde. Versteh(t) mich nicht falsch, ARMs und konsorten haben 100%ig Einsetzungsgebiete, wo sie die beste Wahl sind. Vielleicht sind es auch viele. Aber man kann nicht sagen, dass ein ARM oder anderer 32bitter IMMER die beste Wahl ist. Und solange das der Fall ist, wird es auch immer was anderes geben.
Stefan schrieb: > Ich finde das Marketing Gebrabbel von Microchip auch unerträglich. Jedwedes Marketinggebrabbel ist unerträglich. Das ist seine Natur. So wie Wasser naß ist und Feuer heiß. > Klar, solange es um Kaffeemaschinen und LED Leuchten geht sind > PICs die erste Wahl. Ich finde ja, PICs sind nie die erste Wahl. OK, über Geschmack soll man nicht streiten. > Doch sobald es ans Eingemachte geht - richtige Anwendungen - bleiben nur > noch ARM und Renesas. Was unterscheidet "richtige Anwendungen" von Kaffeemaschinen? Die Frage ist ernst gemeint. > PIC32 interessiert doch niemanden. Das hat > Microchip ja auch selbst inzwischen erkannt und gerade noch rechtzeitig > Atmel gekauft. Sonst hätten sie eher früher als später einräumen müssen > dass der PIC32 gegenüber dem Cortex-M nie eine Chance hatte. Um ehrlich zu sein, ich habe Microchip als µC-Hersteller recht früh unter "ignorieren, lohnt nicht" abgelegt. Aber PIC32 ist MIPS. Das ist eine prima Architektur. Vielleicht hat Microchip die ja im Detail versaubeutelt, aber im Prinzip finde ich einen µC auf MIPS Basis sehr sexy. So viel netter ist ARM da nicht. > PS: Ich brauche aktuell einen PIC (gerne 8Bit) der >= 5 Touch-Buttons > abfragen kann und mit einer CR2032 versorgt mind. 1 Jahr lang läuft. Die erste Frage wäre hier, warum du dich auf PIC festlegst. Fast jeder µC kann 5 Touchbuttons und low-power an 2.9..3.2V.
Axel S. schrieb: > Ich finde ja, PICs sind nie die erste Wahl In der Industrie sind tatsächlich 8051 und ARM erste Wahl, aber wenn es auf jeden Cent ankommt sind die PIC tatsächlich unschlagbar günstig. So sind z.B. in fast allen LED-Lampen SOT23 PIC > Aber PIC32 ist MIPS. Das ist eine prima Architektur. Vielleicht hat > Microchip die ja im Detail versaubeutelt Als erstes haben Sie die "microMIPS ISA" eingeführt die dem ARM Thumb entspricht, und sich damit dieselben Probleme geholt.
Axel S. schrieb: > Ich finde ja, PICs sind nie die erste Wahl. Stimmt. War bei mir auch so. Und dann sucht man auf einmal einen µC mit 6 x I²S fähigem SPI und SD-Interface und findet nur den PIC32MZ. Eine Rakete mit 200MHz. Geiles Teil. Aber nicht günstig ... :-/ Bei den Preisen werden die im 32-Bit-Brei nicht viel mitrühren ... Aber ich finde das Teil cool! Dennoch habe ich hier bestimmt noch 200 8-Bitter rumfliegen (8051, AVRs) Wenn die passen, werden die auch noch eingesetzt. Vorteil dieser kleinen Dinger: Man kann genau sagen, zu welchem Zeitpunkt welcher Befehl ausgeführt wird und damit, wann welcher Ausgang kippt. Das kann man bei moderneren, schnelleren Architekturen wie ARM und PIC32 mit Pipeline, Cache, eigenem Peripherietakt und Co. vergessen. Gruß Jobst
Lothar schrieb: > Als erstes haben Sie die "microMIPS ISA" eingeführt die dem ARM Thumb > entspricht, und sich damit dieselben Probleme geholt. Welche?
:
Bearbeitet durch User
Wie schon so oft, fürchte ich, dreht sich alles wieder um des Kaisers Bart! Wie sagt das Sprichwort? "Jedem Tierchen sein Pläsierchen!" Ich bin mir fast sicher was der Eine nicht mag, mag vielleicht jemand anders. Jeder uC hat seine Eigenheiten, Stärken und Schwächen. Das Genietum des Ingenieurs besteht nun darin diese zu berücksichtigen und konsequent die richtige Wahl für den Einsatz zu treffen. Wir dürfen auch die Entwickler der uC und Architekturen Befehlssätze nicht gerade für blöd einschätzen. Sicher man hat nicht immer ein gute Hand gehabt und manchmal muß dann den eingeschlagen Architekturweg gehen und die Suppe auslöffeln. Beispiele gibt es ja genug in der Literatur. Ich bin mir sicher wenn alles gesagt und getan wurde, daß die meisten uC ihre Aufgaben mehr oder weniger gut erfüllen solange die korrekte Wahl der Schlüsseleigenschaften bewirkt wurde. Und wenn sich ein uC schwer tut oder wegen der Art seiner Konstruktion nicht deterministisch genug ist, muß eben in manchen Fällen das Problem mit entsprechendem Hardware Design durch Verwendung von FPGAs und CPLDs oder altmodische zusätzliche Digital Bausteine gelöst werden. Was die Sache vergleichsmäßig schwer macht sind die potenziellen Einsatzextreme. An einem Ende gibt es langsame Steueraufaben im ms zu s Bereich und am anderen Ende kodiert man Video und alles geht im ns Bereich ab. Letzten Endes zählt nur wirklich ob die Aufgabe gut genug gelöst wurde und das Design die Anforderungen ausreichend gut erfüllt. Bis jetzt habe ich noch nie auf einen anderen als den ursprünglichen uC umsteigen müssen. in den letzten 16 Jahren ziehten wir bei uns mit PICs, DSPPIC, AVRs, moderne 8051s, ARM7, Und zuletzt ARM-Cortex-M3/4 alles durch. Bei keinem uC gab es überwältigende Probleme. Ist nur eine Frage der Einarbeitung. Es wird so oft die Komplexität der STM32 Peripherien bemängelt. War alles nicht so schlimm. Man muß sich nur einige Tage konsequent praktisch einarbeiten. In einer höheren Programmiersprache verwischen sich sowieso oft die Unterschiede zwischen den einzelnen uC Typen. Was wichtiger ist, gute Entwicklungswerkzeuge zu haben auf die man sich verlassen kann. Man mag über einige kommerzielle Werkzeuge lästern, aber einige Teure sind, wie die Vergangenheit gezeigt hat, ihr Geld wert. Ich möchte jetzt natürlich keine Namen nennen. Auch zahlt es sich in manchen Fällen aus professionell geschriebene und getestete Bibliotheken zu verwenden. Das spart einen in manchen Fällen viel Geld in nicht verlorener Zeit durch Fehlersuche und macht möglicherweise den Unterschied aus ein Projekt termingemäß fertig zu kriegen. Was auch oft zu leicht genommen wird, gut funktionierende Hardware zur Verfügung zu haben. Wie oft wurde schon die FW beschuldigt, wenn dann letzten Endes fehlerhaftes HW-design oder ungünstiges Komponenten oder Bord Design die wirkliche Ursache war. Manche, die z.B mit SD-Karten zu tun hatten, können wahrscheinlich ein Lied davon singen. Auch ist es wichtig den Feind gut zu kennen. Oft kommt man mit den Typen und Werkzeugen, Sprachen am schnellsten zum Ziel mit denen man schon einige Erfahrung hatte. Ihr könnt mich jetzt dafür steinigen oder ignorieren, aber so sehe ich das. Grüße, Gerhard P.S. Da ich mich nicht als professioneller Entwickler ansehe kann ich mir solche lockeren Sprüche erlauben:-)
:
Bearbeitet durch User
Michael S. schrieb: > Ich denke auch, wenn es ums "eingemachte" geht, sind sehr oft SOCs > zusehen. Und dort ist dann ein uC mit eingebaut, um die ganze > Funktionalität verarbeiten zu können. Also auch nicht immer die blanken > ARMs a la STM32F4 oder ähnliches. Dort wird dann sicherlich ein > schneller 32bitter eingebaut, um alle Kunden zu bekommen und nicht nur > die, denen ein 8051 reichen würde. Guck dir mal den ellenlangen Thread an, wo es um die WinCE-Settop-Box von Pollin ging. Das ist ein typisches Beispiel. Bei der besagten Pollin-Box steckt ein älterer Media-Prozessor drin. Konkret sind rund 80% der Chipfläche durch zwei fette 64 Bit Trimedia-DSP's belegt. Der Rest ist Display-Ansteuerung, Huffman-Hardware, sonstige Peripherie, und ganz in der Ecke ein 32 Bit MIPS, der für's householding da ist. Auf dem lief dann auch das WinCE - und all die Linuxer, denen es ja so unendlich wichtig war, dort ein Linux draufzubekommen, haben die eigentliche Hauptattraktion, nämlich die zwei fetten DSP überhaupt nicht zur Kenntnis genommen. Ähnlich sieht es bei den üblichen DVD-Playern aus. Allerdings haben die jahrelang verwendet gewesenen Chips von ESS ne MIPS + nen schmaler aufgestellten 64 Bit DSP als eigentliche Arbeitspferde drin und für's householding nen 8051. Axel S. schrieb: > aber im Prinzip finde ich einen µC auf MIPS Basis sehr > sexy. Ähemm, hüstel... sexy? Nun ja, wir haben alle unsere persönlichen Präferenzen, gelle? Sachlich gesehen sind die PIC32 durchaus gute Prozessoren, aber an der Peripherie fehlt es deutlich. Wenn ich bedenke, daß einige Varianten ne MMU eingebaut haben, ohne wenigstens einen Anschluß für ein externes SDRAM zu haben, und ohne einen dedizierten richtigen TFT-Controller zu enthalten, kommt mir das Kopfschütteln. Hätte MicroChip ihren PIC32 nen richtigen externen 32 bit breiten Busanschluß gegönnt, der heutzutage mit LPDDRAM klarkommen sollte, dazu einen richtigen TFT-Controller, der auf den externen DDRAM echt paketweise zugreift und damit den Bus nicht gar zu sehr zum Flaschenhals werden läßt, dann wären sie damit den Cortexen davongezogen. Ist aber nicht. Die Bastellösung von MicroChip ist und bleibt lausig und uneffektiv. Man muß dazu sagen, daß NXP ne glückliche Hand gehabt hat, als sie die Blue-Streak's von Sharp aufgekauft hatten. Damit war das Knowhow für TFT-Controller im ARM-Umfeld bei NXP vorhanden. ST hat das erst viele Jahre danach kapiert und ne Menge von NXP kopiert. Aber bei MicroChip ist bis heute der Groschen nicht gefallen. W.S.
W.S. schrieb: > Pollin-Box steckt ein älterer Media-Prozessor drin. Konkret sind rund > 80% der Chipfläche durch zwei fette 64 Bit Trimedia-DSP's belegt. Das ist beim Raspberry Pi nicht viel anders, besonders beim ersten. Der besteht in der Hauptsache aus einem Mediaprozessor mit eigenen Programm, dem zwecks Linux-Betriebssystem ein ARM angeflanscht ist. Gebootet wird erst der Mediaprozessor, der wiederum dem ARM startet. Wenn man den RPi nicht an TV/Monitor betreibt, ist der Medieprozessor völlig für den A...
Gerhard O. schrieb: > Bis jetzt habe ich noch nie auf einen anderen als den ursprünglichen uC > umsteigen müssen. Da hast du entweder großes Glück gehabt oder ein Arbeitsumfeld, das dich davor geschützt hat. Mir ist sowas öfters passiert: Mitsubishi-->gestorben. NEC-->gestorben. Fujitsu-->gestorben. Hitachi-->naja, quasi gestorben, sprich umgerührt und nen Renesas draus gebacken. Deshalb ist ein ziemlicher Teil meines persönlichen Code-Portfolios auch so ausgelegt, daß er sowohl bigendian als auch littleendian abkann. Das hab ich bislang bei feilgebotenen Bibliotheken anderer Leute noch nicht so gesehen. Allerdings sehe ich durchaus, daß sowas mit der Zeit bedeutungslos wird, weil die Szene in Richtung Cortex Monokultur geht. Nun ja, jedenfalls die hier im Blickfeld befindliche Szene. W.S.
W.S. schrieb: > für's householding nen 8051 Stimmt - und nicht nur in SoC auch in SiP kommt meist ein 8051 zum Zug - kein AVR oder PIC: https://www.elektormagazine.de/news/gas-sensoren-in-smartphones-aber-mit-einem-8051
Lothar schrieb: > TriHexagon schrieb: >> Aber gibt es heute noch 8-Bit Familien die aktiv weiterentwickelt > > EFM8 8051 sind erst 2015 rausgekommen, EFM8LB erst dieses Jahr. Wir > evaluieren grade die Umstellung von einem ARM Design, denn EFM8LB hat > 14-bit 1MSPS ADC und 4x 12-bit DAC, da gibt es aktuell keinen ARM > > http://www.silabs.com/products/mcu/8-bit/Pages/efm8.aspx > http://www.silabs.com/products/mcu/8-bit/efm8-laser-bee/Pages/efm8-laser-bee.aspx Oh die hatte ich ja noch gar nicht auf dem Schirm, sehen aber gut aus. Was hindert die Hersteller eigentlich solche Peripherie in 32-Bit µCs einzubauen? Paul R. schrieb: > Ist in Elektor Nr.541/542. Seite 34 35: > > seit Anfang 2015 AVR B-Typen > 130nm-Prozess > genauer RC-Oszillatoren > Seriennummer > mehr I/O > Capacitive Touch in HW > neue ATtinys > > nur im SMD-Gehäuse > > Eval-Bords: http://www.atmel.com/webdoc/atmega168pbxmini/index.html Danke. Tatsächlich, gerade bei Atmel hab ich nicht mehr damit gerechnet. W.S. schrieb: > Deshalb ist ein ziemlicher Teil meines persönlichen Code-Portfolios auch > so ausgelegt, daß er sowohl bigendian als auch littleendian abkann. Das > hab ich bislang bei feilgebotenen Bibliotheken anderer Leute noch nicht > so gesehen. > > Allerdings sehe ich durchaus, daß sowas mit der Zeit bedeutungslos wird, > weil die Szene in Richtung Cortex Monokultur geht. Nun ja, jedenfalls > die hier im Blickfeld befindliche Szene. Soweit ich mich richtig erinnere, können die Cortexe sowieso beides.
W.S. schrieb: > Mitsubishi-->gestorben. NEC-->gestorben. Fujitsu-->gestorben. > Hitachi-->naja, quasi gestorben, sprich umgerührt und nen Renesas draus > gebacken. Das ist ja schockierend! Da haben wir scheinbar großes Glück gehabt. Wir hatten andererseits große Probleme bei der Beschaffung von SDRAM, FLASH, und TFT-LCDs wegen Abkündigungen. Drei Mal mußten wir innerhalb 7 Jahren auf Parallel Typen von SDRAM zugreifen. Im Falle der TFT-LCD mit industriellen Eigenschaften muß man froh sein 5 Jahre+ schaffen zu können. Die uC machten uns eigentlich diesbezüglich die geringsten Schwierigkeiten. Alles was wir bis jetzt verwendet haben ist immer noch im normalen Handel lieferbar.
W.S. schrieb: > Ich frag dich mal, wozu man ne DMA tatsächlich braucht. Bei dedizierten > Peripherie-Cores wie z.B. einem TFT-Controller mit DMA-Fähigkeit sieht > man das sofort ein. Aber ein ganz gewöhnlicher DMA, dessen Fähigkeit > sich auf das Umschaufeln von A nach B erschöpft? DMA ist bei mem-to-mem eher selten sinnvoll. Gewöhnlich ist eine Seite eine Peripherie-Einheit wie UART, SPI oder auch ein Port (z.B. per Timer getriggert). Um nicht bei jedem Peripheriemodul das Rad neu zu erfinden macht man den DMA-Controller zentral und konfigurierbar und verbindet nur die Events der Module mit dem DMA-Controller. > Wozu sowas? Wenn alle paar µs ein ADC-Wort per SPI ansteht, dann sind Interrupts für jedes einzelne Wort unökonomisch bis unrealistisch. Die CPU wird solche Daten wahrscheinlich blockweise bearbeiten, oder auch nur so wie sie reinkamen per Ethernet wieder rausfeuern.
A. K. schrieb: > W.S. schrieb: >> Pollin-Box steckt ein älterer Media-Prozessor drin. Konkret sind rund >> 80% der Chipfläche durch zwei fette 64 Bit Trimedia-DSP's belegt. > > Das ist beim Raspberry Pi nicht viel anders, besonders beim ersten. Der > besteht in der Hauptsache aus einem Mediaprozessor mit eigenen Programm, > dem zwecks Linux-Betriebssystem ein ARM angeflanscht ist. Gebootet wird > erst der Mediaprozessor, der wiederum dem ARM startet. Wenn man den RPi > nicht an TV/Monitor betreibt, ist der Medieprozessor völlig für den A... Da wir gerade über Abkündigungen reden. Die Tatsache, das der RPi SOc eine Multimediprozessor mit angeflanschtem ARM ist, macht der Foundation noch große Probleme. Den der Multimediaprozesor ist für RAM, GPIOs und Schnittstellen zuständig, wird aber von Broadcom nicht mehr weiterentwickelt, das zuständige Team ist aufgelöst. Deswegen wird es weder USB 3 noch mehr als 1GB RAM für den RPI geben.Es sei den sie geben die Abwärtskompatibilität auf und steigen auf einen neuen Grafikern um - mit all den Closed -Source Problemen.
W.S. schrieb: > wozu man ne DMA tatsächlich braucht Bei den aktuellen 8051 z.B. um ADC Daten ohne CPU Last im RAM abzulegen. Das Programm kann dann warten, bis ausreichend Daten vorhanden sind und dann Filter o.ä. machen z.B. EFM8LB Bei den ARM geht der Trend allerdings weg von DMA hin zu asymmetrischen Cores z.B. ein M0 beschäftigt sich mit dem ADC und holt Daten ab und ein M4 macht den Filter z.B. LPC4300
Moby A. schrieb im Beitrag #4651674: > Auf dem Xmega z.B. zum Eventsystem-gesteuerten Einlesen und Ausgeben von > Puffern von/auf UART. Letzteres ist nach wie vor eine ganz feine > Schnittstelle... Lothar schrieb: > Bei den aktuellen 8051 z.B. um ADC Daten ohne CPU Last im RAM abzulegen. > Das Programm kann dann warten, bis ausreichend Daten vorhanden sind und > dann Filter o.ä. machen Kopfschüttel... Also mal ganz generell: Wenn Input-Daten anliegen, die in irgend einer Weise verarbeitet werden sollen, ist in jedem Falle Rechenzeit der CPU vonnöten, um eben diese Verarbeitung vorzunehmen. Da nützt es garnichts, wenn zuvor ein DMA die Daten von irgend einer Schnittstelle in irgend einen RAM befördert. Also könnte die CPU die Daten auch gleich aus der Schnittstelle lesen und verarbeiten. Das Einzige, was man bei irgendwelcher blockweiser Verarbeitung einsparen könnte, wäre der Overhead, der für einen Interrupt erforderlich ist. Der wird allerdings aufgefressen durch die Notwendigkeit, den DMA zu konfigurieren bzw. im Fluge umzukonfigurieren, ohne dabei ein oder mehrere Daten zu verlieren. Ein wenig anders ist die Ausgabe zu einer Schnittstelle: Da kommen Daten asynchron herein und sie kommen nachdem der DMA bereits programmiert wurde. Ein DMA kann einen ganzen Block von Daten in geordneter Weise irgend wohin schaufeln. Aber er kann nicht auf Daten reagieren, die nach seiner Konfigurierung hereinkommen. Also geht alles nur blockweise und genau das ist das Gegenteil dessen, was man bei einer asynchronen Schnittstelle wie einem UART in Wirklichkeit haben will. Nein, dazu ist ein Treiber vonnöten und dieser muß puffern und mit völlig asynchron hereinkommenden und herauszugebenden Daten klarkommen. Ein DMA kann das prinzipiell nicht. W.S.
Stefan schrieb: > Das hat > Microchip ja auch selbst inzwischen erkannt und gerade noch rechtzeitig > Atmel gekauft. Sonst hätten sie eher früher als später einräumen müssen > dass der PIC32 gegenüber dem Cortex-M nie eine Chance hatte. Jetzt mal ganz unabhängig von der Frage wie gut (oder schlecht) die PIC 32 tatsächlich sind... Wie kann man bloß ernsthaft auf den Gedanken kommen das die ARM eine wesentliche Rolle bei der Entscheidung zur Übernahme von ATMEL gespielt haben könnten? Da muss man doch schon iemlich fanatisher ARM Fan sein, oder? OK, sicher ist es ein netter Nebeneffekt das Microchip durch den Kauf neben den eigenen 8 & 16 Bit Pic architekturen, MIPS, sowie diversen 8051 nun auch die ARM noch im Bestand hat (und natürlich die AVR) Aber jetzt mal ehrlich: Da ist jemand durchaus eher einer der Großen der Branche. So richtig mit eigenen FABs usw. Jemand dessen Geschäft die letzten Jahre gut gelaufen ist und der schon einige kleinere und mittlere Firmen zur Sortimentsergänzung in der letzten Zeit zugekauft hat. Versetzen wir uns mal in die Lage dessen Vorstandsvorsitzenden, also von jemanden der bestimmt wo es langgeht und dessen Gehalt zum großen Teil vom Gewinn bestimmt wird: Mal angenommen die Behauptung das dieser Erkannt hat das ihm in einem Bereich ein wichtiges Produkt fehlt - Ein Produkt auf Basis eines geprüften, bereits entwickelten und damit jederzeit Lizensierbaren IP Cores, dann überprüft man natürlich die Möglichkeiten. Soweit ist es ja noch Nachvollziehbar. Aber wenn ich an diesem Punkt bin und es zeigen sich dann drei Möglichkeiten zeigen: 1. Ich mache es so wie andere große und vor allem unzählige kleine Halbleiterhersteller vor mir. Ich erwerbe eine Lizenz für den IP Core, verheirate den mit meiner eigenen Peripherie sofern nicht bereits ausreichend Perpherie als IP erworben werden kann und bringe das Teil unter meinem Namen in dem Markt. Im Gegensatz zu den vielen kleinen und mittleren Fabless Herstellern die bereits diesen Weg gegangen sind habe ich Experten für wirklich ALLE stationen der µC Entwicklung und Herstellung im Haus und verfüge auch noch über eigene Fabriken so das sich da keine wirklichen Hindernisse auftun. Kosten sind gut kalkulierbar. Die Worst Case Zeitschiene lässt sich Anhand derer (Kleinfirmen) die dieses Produkt ohne jede große Vorerfahrung vor mir in den Markt gebracht haben auch gut abschätzen. Zudem habe ich in den letzten Jahren noch eine reihe kleinerer Firmen zugekauft, so das ich das Produkt auch unter deren Namen in den MArkt bringen könnte wenn ich nicht meinen Namen draufschreiben will. 2. Ich mache es wie in den Jahren vorher schon öfter Erfolgreich Praktiziert: Wenn mir eine Technologie im Portfolio fehlt kaufe ich einen kleinen Hersteller der diese Technologie bereits im Programm hat auf und gliedere den ein. Die Produkte kann ich dann über meine eigenen Fabs herstellen lassen oder wenn die Kapazität nicht reicht Fremdvergeben. Da es ein Überschaubarer Betrag ist geht das ganze ohen große Wehen und Risiko für mich über die Bühne. Erregt kein großes Aufsehen und wenn es schief geht unschön, aber nicht existentiell. 3. Ich suche mir ein anderes, so gerade mit Kraftanstrengung noch schluckbares Schwergewicht aus, ds durch einen Schrumpfungsprozess aber eigendlich nur noch aus Lizenzrechten, Kunden und Namen besteht aus (Kein Fabs, keine besonderen Herstellungstechnologien usw. also nichts was für meine Bestandsprodukte sinnvoll ist) der neben vielen anderen Sachen halt auch das gewünschte Produkt im Portfolio hat. Diesen Kaufe ich in einem Bieterwettstreit mit einem anderen Mitbieter für einen Betrag der mein eigenes Unternehmen im Falle eines Misserfolges in existentielle Probleme bringen könnte. Eine Übernahme die Wellen schlägt und mir auch einigen Gegenwind von teilen meiner Aktionäre einbringen wird. Jetzt mal ehrlich: Wer glaubt tatsächlich das bei dieser Auswahl auch nur der HAUCH einer Chance bestehen würde das die Entscheidung auf Möglichkeit drei fällt? nee, für den Atmel Kauf waren ganz andere Dinge als "ARM" ausschlaggebend. Das war höchstens ein netter Beifang. Aber keinesfalls mehr! > > PS: Ich brauche aktuell einen PIC (gerne 8Bit) der >= 5 Touch-Buttons > abfragen kann und mit einer CR2032 versorgt mind. 1 Jahr lang läuft. Eine der ALLERWICHTIGSTEN Randbedingungen für solche Anfragen hast du hier vergessen. Wie sieht es mit dem Verhältnis der StandbyPahsen zu den Betriebsphasen aus? Und überhaupt, was ist als Standby möglich? DeepSleep - Das mit Watchdog oder ohne? Oder muss der durchgehend im Idle Modus laufen? Das sind die entscheidenden Parameter bei der Auswahl... Aber um mal einen Typ ins Blaue zu werfen: PIC16F18313 könnte was für dich sein... Gruß Carsten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.