Gerade eben gesehen... Neue Cortex-M0+-Familie von Atmel http://www.atmel.com/Microsite/samd20/default.aspx ...und eine Einschätzung von dritter Seite: http://www.elektroniknet.de/halbleiter/mikrocontroller/artikel/98530/ Tolle Teile! Der Atmel-Süchtige
Der Atmel-Süchtige schrieb: > ...und eine Einschätzung von dritter Seite: > http://www.elektroniknet.de/halbleiter/mikrocontroller/artikel/98530/ Das ist keine dritte Seite. Die leben von der Werbung, die Firmen in Auftrag geben. > Tolle Teile! Dafür sehe ich keine Belege > Der Atmel-Süchtige Begebe dich sofort in Behandlung. Heilung ist möglich (siehe ST). elektronik.net: "Über die Daten der MCU hinsichtlich Energiesparmodi und Leistungsaufnahme gibt es in der ersten veröffentlichten Datenblattversion leider keine Angaben." Kein Kommentar.
Warum soll ich jetzt davon begeistert sein? Mir wird das nicht ganz klar. Der ARM LPC1114FN28 von Phillips begeister mich da eher: http://avr.paslog.jp/article/2542408.html
Schade, wieder ohne CAN, da bleibt wohl doch nur NXP. Christian_RX7
was für ein Schwachsinn in dem Bericht steht, soweit ich mich zurückerinnern kann, ist der Xmega bereits vor EnergyMicro Gründung entwickelt worden und da gab es schon das bekannte Event System... ich finde das Sercom Design interessant, man kann nun wirklich eine schöne Plattform aufbauen. mir gefällt auch das BIST Modul, der Chip passt ganz gut zwischen Xmega und CM3, wenn man gute analoge Peripherie will mit gain stage kann man jetzt zwischen Xmega und CM0+ von Atmel wehln
Mike schrieb: > ... kann man jetzt zwischen Xmega und CM0+ von Atmel > wehln Sieht eher nach dem Sargnagel für die 32-bit AVRs aus :-( Mal gespannt wie lange sich die UC3s noch in der Roadmap von Amtel halten.
Heiko Jakob schrieb: > Sieht eher nach dem Sargnagel für die 32-bit AVRs aus :-( > Mal gespannt wie lange sich die UC3s noch in der Roadmap von Amtel > halten. glaub nicht dass die so schnell von der Bildfläche verschwinden, für die 32bit AVR kommt eher ein CortexM4 entgegen (DSP) und Atmel hat ja schon seit längerem die low power SAM4L Serie im Angebot, trotzdem hat sowohl Samsung als auch Microsoft den UC3L den Vorzug gegeben - hätte der 32Bit AVR keinen Markt dann wäre er also schon lange verschwunden denke ich. UC3L im Microsoft Surface: http://www.ifixit.com/Teardown/Microsoft+Surface+Teardown/11275/2 UC3L im Samsung Galaxy Tab: http://www.highbeam.com/doc/1G1-310928378.html Wenn der 32Bit AVR in einer Foundry produziert wird, dann gibt es fast gar keinen Grund den abzukündigen - man muß ja keine Technologie vorrätig halten sondern bestellt seine Wafer einfach nach wenn jemand danach fragt. Theoretisch könnte so ein Bauteil jahrelang weiterangeboten werden selbst wenn dafür in einer eigenen Fab kein Platz mehr ist. Was aber gut sein kann dass Atmel keine neuen 32Bit AVR mehr designed, aber das heißt ja nicht dass der Baustein nicht mehr vorhanden ist. Noch ein wenig dann wird es auf CM3/CM4 auch keine weiterentwicklungen mehr geben, wird aber wohl eine weile weiterproduziert, kommt sicher irgendwann ein neuer Core und dann geht das ganze von vorn lso
>Warum soll ich jetzt davon begeistert sein? Wegen SERCOM mit nur 2x-RX-Buffer braucht man es jedenfalls nicht. (PIC24 zB hat da ein 8x FIFO)()
Mit 4 INT-Prioritäten hat SAMD20 auch nicht mehr als die ATXmegas.
Atmel musste auf jeden Fall was die Richtung tun, wer will schon ATMEGA Krücken haben, wenn zum selben Preis Cortexe zu haben sind. Mich wundert es sowieso, wie manche bei Neuentwicklungen die Technik auf dem Stand vor >10 Jahren einsetzt, nur weil man es schon immer gemacht hat? Aber jetzt zum Atmel Cortex Chip selbst. Ich habe mir die Teile angesehen und sehe keinen Grund die neuen Chips von Atmel den bereits länger vorhandenen von ST, NXP etc. vorzuziehen.
♪Geist schrieb: > wer will schon ATMEGA Krücken haben, wenn zum selben Preis Cortexe zu > haben sind. Beispielsweise Leute, die Betrieb bei 5 V brauchen (soll wohl in der Fahrzeugtechnik noch sehr verbreitet sein). Es gibt meines Wissens bislang keinen einzigen ARM, der das kann. Wenn du nur 'ne Fensterscheibe runterleiern willst, ist dir das als Anwender völlig wurscht, ob der Controller nun 8 Bit oder 32 auf einmal verarbeitet. Schneller wird das Fenster davon sowieso nicht. :-)
Christian Kreuzer schrieb: > Schade, wieder ohne CAN, da bleibt wohl doch nur NXP. > > Christian_RX7 Oder ST Jörg Wunsch schrieb: > Beispielsweise Leute, die Betrieb bei 5 V brauchen (soll wohl in > der Fahrzeugtechnik noch sehr verbreitet sein). Es gibt meines > Wissens bislang keinen einzigen ARM, der das kann. > > Wenn du nur 'ne Fensterscheibe runterleiern willst, ist dir das als > Anwender völlig wurscht, ob der Controller nun 8 Bit oder 32 auf > einmal verarbeitet. Schneller wird das Fenster davon sowieso nicht. :-) In der Fahrzeugindustrie setzt man sowieso (wie in Luftfahrt + Raumfahrt) auf alte, wenn nicht veraltete Mikrocontroller. Meist Freescale oder Motorola HCxxxxx. Hat den einfachen Sinn, dass die sehr bekannt sind und vor allem robust. Die Teile sind schon so lange auf dem Markt, dass man jeden einzelnen Fehler auswendig kennt und die etablierten Teile sind zuverlässig wie keine anderen. Aber das mag dem Hobbybastler so und so egal sein, kaum einer weiß ja von den Errata geschweige denn liest sie. Außerdem interessiert es niemanden wenn mal die blinkenden LEDs beim Hobbyprojekt ausgehen oder der µC sich verhaspelt. Wenn jedes halbe Jahr ein neuer Mikrocontroller raus kommt dann wird der einzelne nie so gut "erforscht" werden wie es besagte Klassiker sind.
Jörg Wunsch schrieb: > Beispielsweise Leute, die Betrieb bei 5 V brauchen (soll wohl in > der Fahrzeugtechnik noch sehr verbreitet sein). Es gibt meines > Wissens bislang keinen einzigen ARM, der das kann. Fujitsu und Toshiba müssten da etwas haben.
STM hat an einuigen pins 5V toleranz LPC111x auch Nuvoton auch TI auch ... gibt also einige die 5V abkönnen zumindest an den GPIOs 5V treiben war noch nie die stärke eines µC und meist nur eine krückenlösung
hhhhh schrieb: > STM hat an einuigen pins 5V toleranz > LPC111x auch > Nuvoton auch > TI auch ... Ist aber was anderes als Betrieb mit 5 V. > 5V treiben war noch nie die stärke eines µC und meist nur eine > krückenlösung So'n Quatsch. Nur, weil da mal krückige 8051-Lösungen rumliefen, die nur einen Pullup-Widerstand nach 5 V benutzt haben, heißt das nicht, dass dies die einzige mögliche Lösung wäre. Sämtliche einfachen PICs sowie ATtiny/ATmega haben damit überhaupt kein Problem, und seit mittlerweile fast einem Jahrzehnt haben sie dafür sogar symmetrisch belastbare Ausgangsstufen (d. h. die p-Transistoren haben vergleichbare Stromergiebigkeit wie die n-Transistoren).
Jörg Wunsch schrieb: >> 5V treiben war noch nie die stärke eines µC und meist nur eine >> krückenlösung > > So'n Quatsch. Nur, weil da mal krückige 8051-Lösungen rumliefen, > die nur einen Pullup-Widerstand nach 5 V benutzt haben, heißt das > nicht, dass dies die einzige mögliche Lösung wäre. Sämtliche > einfachen PICs sowie ATtiny/ATmega haben damit überhaupt kein > Problem, und seit mittlerweile fast einem Jahrzehnt haben sie > dafür sogar symmetrisch belastbare Ausgangsstufen (d. h. die > p-Transistoren haben vergleichbare Stromergiebigkeit wie die > n-Transistoren). Aber 5 Volt Betriebspannung für den Kern bedeutet meist grössere Strukturen. Daneben hat man auch häufig einen Mischbetrieb 3.3 und 5 Volt. Um 3.3 Volt Logik sicher am 5 Volt AVR zu betreiben, braucht man Pegelumsetzter. Und betreibt man den AVR mit 3.3 Volt, verliert man Geschwindigkeit und hat keine 5-Volt Toleranz mehr. Atmel scheint mir überhaupt mit der 5 Volt Toleranz auf Kriegsfuss zu stehen, siehe Arduino Due.
Uwe Bonnes schrieb: > Aber 5 Volt Betriebspannung für den Kern bedeutet meist grössere > Strukturen. Sagt ja keiner, dass man den Kern damit betreiben muss. Der kann ja auch über einen Spannungsregler angebunden werden, und in den Padzellen macht man dann die Pegelwandlung. Aber es ging ja nur um die Frage, warum denn überhaupt noch jemand klassische AVRs (oder vergleichbare Controller) einsetzt, wenn doch der Preisunterschied zu den 32-Bittern minimal ist. Einen typischen Fall sehe ich beispielsweise darin, dass man einen Controller direkt von einer LiPo-Zelle betreiben will: das geht mit einem nur 3,3-V-fähigen Controller eben nicht. Wenn man dann einen externen Spannungsregler hat, macht man wieder Klimmzüge beim Einschalten, damit man den Regler während der Schlafphasen im standby halten kann (sodass die Zelle nicht nennenswert entladen wird) und trotzdem beim Eintreffen eines äußeren Ereignisses aufwachen. Hat man einen Controller für 5 V, dann klemmt man das Teil direkt an die Zelle: der gesamte gültige Spannungsbereich einer solchen Zelle (3 … 4,2 V) ist für den Controller eine zulässige Spannung. Der Controller kann beim standby ggf. noch externe Peripherie herunterfahren und legt sich dann selbst schlafen, wobei er < 1 µA braucht und damit im Bereich der Selbstentladung liegt. Geschwindigkeit oder Wortbreiten sind für derartige Anwendungen völlig nachrangig. Oft genug laufen die zufriedenstellend schon mit einem Takt von 1 MHz. Nicht jede Applikation muss erst ein Windows booten, bevor sie arbeiten kann. :-))
> Beispielsweise Leute, die Betrieb bei 5 V brauchen (soll wohl in > der Fahrzeugtechnik noch sehr verbreitet sein). Es gibt meines > Wissens bislang keinen einzigen ARM, der das kann. XMC1100 von Infineon wäre so ein Teil. CM0 mit 5V
>> Beispielsweise Leute, die Betrieb bei 5 V brauchen (soll wohl in >> der Fahrzeugtechnik noch sehr verbreitet sein). Es gibt meines >> Wissens bislang keinen einzigen ARM, der das kann. >Fujitsu und Toshiba müssten da etwas haben. und Nuvoton
Marc N. schrieb: > > In der Fahrzeugindustrie setzt man sowieso (wie in Luftfahrt + > Raumfahrt) auf alte, wenn nicht veraltete Mikrocontroller. Meist > Freescale oder Motorola HCxxxxx. Für die Luft+Raumfahrt ist die Aussage richtig, aber die Begründung unvollständig. Neben Zuverlässigkeit geht es hauptsächlich um Analysierbarkeit und Vorhersagbarkeit.
Marc N. schrieb: > In der Fahrzeugindustrie setzt man sowieso (wie in Luftfahrt + > Raumfahrt) auf alte, wenn nicht veraltete Mikrocontroller. Meist > Freescale oder Motorola HCxxxxx. Das ist so pauschal schlicht Unfug. Einen HCirgendwas hatte ich noch nie in den Fingern (außer aus historischem Interesse), dafür reichlich Tricores. Renesas fertigt inzwischen Automotive-µCs in 40nm, die anderen sind bei 60nm unterwegs. Richtig ist, dass die Halbleiter-Prozesse der automotive-tauglichen ICs immer ein bis zwei Strukturbreiten hinter denen der Consumerware hinterherhinken. Die Produktlebenszyklen sind aber auch etwas länger als bei einem Tablet oder Handy. In Luft- und Raumfahrt mag es anders aussehen, da kenne ich mich nicht aus. Max
Jörg Wunsch schrieb: > Beispielsweise Leute, die Betrieb bei 5 V brauchen (soll wohl in > der Fahrzeugtechnik noch sehr verbreitet sein). Es gibt meines > Wissens bislang keinen einzigen ARM, der das kann. Die NuMicro CM0 von Nuvotron können 5V. So arg schwer ist es eigentlich nicht. Der Core von ARM Controllern arbeitet sowieso oft <2V, runtergeregelt, mit Spannungstrennung zwischen Core und IO.
A. K. schrieb: > Die NuMicro CM0 von Nuvotron können 5V. Wurde ja inzwischen schon genannt. > So arg schwer ist es eigentlich nicht. Der Core von ARM Controllern > arbeitet sowieso oft <2V, runtergeregelt, mit Spannungstrennung zwischen > Core und IO. Ist schon klar, man muss es „nur“ machen …
Zwei Dinge sind in den letzten Jahren doch ganz klar geworden: - 8-Bitter sterben aus. Sie werden vom Cortex M0 verdrängt. - Die Cortex-M-Serie ist im Moment bei kleinen Controllern das Maß der Dinge. Inzwischen baut fast jeder uC-Hersteller ARM-Kerne in ihre neuen Bausteine ein. Dem konnte sich auch Atmel nicht entziehen. Die Hersteller müssen sich jetzt eben umstellen. Früher war der Prozessorkern und die Toolchain noch Teil ihres Hauptgeschäftes. Jetzt müssen sie sich anhand der Peripherie und Support differenzieren.
>- 8-Bitter sterben aus
wetten dass nicht?
Frag mal Microship, die werden alles dran setzen auch weiterhin ihre
(vom Grunde her seit Anf. der 70er Jahre(!!!) bestehende 8-Biter zu
vermarkten.
MCUA schrieb: > Frag mal Microship, die werden alles dran setzen auch weiterhin ihre > (vom Grunde her seit Anf. der 70er Jahre(!!!) bestehende 8-Biter zu > vermarkten. Nicht wirklich. Wenn Microchip das tut, werden sie vom Markt verschwinden. Es gibt keinen vernünftigen Grund mehr, weiterhin auf 8-Bitter zu setzen.
8-Bit schrieb: > - 8-Bitter sterben aus. Sie werden vom Cortex M0 verdrängt. Kaum. Es wird beide nebenher geben. Möglicherweise werden aber einige eher exotische Serien eingestampft. Das 51er bald aussterben kann man wohl ausschliessen. > Die Hersteller müssen sich jetzt eben umstellen. Früher war der > Prozessorkern und die Toolchain noch Teil ihres Hauptgeschäftes. Jetzt > müssen sie sich anhand der Peripherie und Support differenzieren. Je leistungsfähiger Cores werden, desto grösser ist das Risiko für den Hersteller. Denn ernsthafte Bugs können dann existenzbedrohend sein, und deren Wahrscheinlichkeit wächst mit der Komplexität. Als zuverlässig bekannte Cores einzukaufen ist weniger riskant. Weil zudem Toolchains und ihr Support auch nicht kostenlos vom Himmel fallen, ist stets die Frage, ob Ausgaben für eine eigene Architektur teurer oder billiger als Lizenzkosten sind. Software ist nicht unbedingt das Kerngeschäft eines Halbleiterherstellers.
8-Bit schrieb: > Es gibt keinen vernünftigen Grund mehr, weiterhin auf > 8-Bitter zu setzen. Ich bin anderer Meinung. Als ich vor Jahren mein Aha-Erlebnis bit dem ARM hatte, sagte ich mir: "Nie wieder 8-Bitter!" Tatsache ist aber, dass ich bei Neuentwicklungen ganz gerne mal wieder einen 8-Bitter einsetze. Nicht jetzt unbedingt wegen dem Preis; aber sie sind schlicht einfacher in der Handhabung (Software).
A. K. schrieb: > Kaum. Es wird beide nebenher geben. Möglicherweise werden aber einige > eher exotische Serien eingestampft. Das 51er bald aussterben kann man > wohl ausschliessen. Ganz aussterben natürlich nicht, aber sie werden nur noch für exotische Anwendungen überhaupt interessant. A. K. schrieb: > Je leistungsfähiger Cores werden, desto grösser ist das Risiko für den > Hersteller. Denn ernsthafte Bugs können dann existenzbedrohend sein, und > deren Wahrscheinlichkeit wächst mit der Komplexität. Als zuverlässig > bekannte Cores einzukaufen ist weniger riskant. > > Weil zudem Toolchains und ihr Support auch nicht kostenlos vom Himmel > fallen, ist stets die Frage, ob Ausgaben für eine eigene Architektur > teurer oder billiger als Lizenzkosten sind. Software ist nicht unbedingt > das Kerngeschäft eines Halbleiterherstellers. Genau das sind die Gründe, wieso man auf Standard-Cores setzt und eigene Architekturen immer mehr aussterben werden.
Mehmet Kendi schrieb: > Tatsache ist aber, dass ich bei Neuentwicklungen ganz gerne mal wieder > einen 8-Bitter einsetze. Nicht jetzt unbedingt wegen dem Preis; aber sie > sind schlicht einfacher in der Handhabung (Software). Preislich liegen Cortex M0 schon lange gleich auf. Und auf der Toolchain-Seite wird sich noch einiges tun. Wobei ein Crossworks jetzt schon mindestens genauso komfortabel ist wie ein AVR-Studio.
gibt es die M0 von Atmel denn schon? wollte mir aus Neugier mal anschauen was die können. Aber die Datenblätter sind ein wenig merkwürdig. Es gibt nicht mal einen Abschnitt wo die maximal zulässigen Ströme drin stehen. Oder wie man den Quarz anzuschießen hat. Oder suche ich nur falsch? http://www.atmel.com/devices/SAM_D20E14.aspx?tab=documents Auch vermisse ich die Infos welche Hilfsmittel man zum "brennen" braucht.
Peter II schrieb: > Auch vermisse ich die Infos welche Hilfsmittel man zum "brennen" > braucht. Ich tipp mal auf JTAG und SWD wie bei allen andern auch.
Zumal das ja üblicherweise Core-Komponenten von ARM sind. Bloss die etwaigen Bootloader sind wirklich herstellerspezifisch,
>Ganz aussterben natürlich nicht, aber sie werden nur noch für exotische >Anwendungen überhaupt interessant. Nö. exotische Anwendungen bedeuten sehr geringe Stückzahlen. Bei den (verfügbaren) 8-Bitern ist das Gegenteil der Fall. Zudem sind 8-Biter in einigen Fällen leistungsfähiger und besser als 32Biter. (Es ist auch fraglich, ab man eine CPU als "32Biter"bezeichnen soll, bloss weil da ein paar 32-Bit-Register drin sind.) >Genau das sind die Gründe, wieso man auf Standard-Cores setzt und eigene >Architekturen immer mehr aussterben werden. Würde ja heissen, dass es in Zukunft nur noch Cores eines -Einzigen- Herstellers gibt. Na dann gute Nacht.
MCUA schrieb: > Würde ja heissen, dass es in Zukunft nur noch Cores eines -Einzigen- > Herstellers gibt. Na dann gute Nacht. Wenn du die Leistungstreppe bis zum Ende erklimmst, dann landest du in der Masse bei einer einzigen ISA mit knapp über 2 Herstellern (mit langfristiger Option auf exakt einen). Wobei es in solchen Fällen eben mehr als einen Core-Designer geben kann. So gibts die oberen ARMs nicht nur von ARM. Qualcomms Krait hat zwar die ARM ISA, ist aber eine eigenständige Implementierung davon. Aber irgendwie glaub ich nicht, dass dich das beruhigt. ;-)
>Wenn du die Leistungstreppe bis zum Ende erklimmst, dann landest du in >der Masse bei einer einzigen ISA mit knapp über 2 Herstellern, mit >langfristiger Option auf exakt einen. wäre X86(?) , Alpha(?), PPC(?), Grossrechner mit 1 Mio Kernen (?). Also dann muss 'jetzt' Microship den X86 nehmen und den in 8Piner einbauen??? Es ist doch nicht das absolute Ende der Leistungstreppe massgebend (das zudem extrem schwer zu definieren ist), sondern schlichtweg das, was man für einen bestimmten Preis bekommt.
Ich wollte damit ausdrücken, dass bei vergleichbarer Funktion eine Reduktion von Vielfalt eine völlig natürliche Folge einer langfristigen Technikentwicklung ist. Einerseits unübersehbar bei PC/Server-Prozessoren, da ist das schon weit gediehen. Andererseits zeigt sich das aber eben auch bei Controllern.
Jörg Wunsch schrieb: > ♪Geist schrieb: >> wer will schon ATMEGA Krücken haben, wenn zum selben Preis Cortexe zu >> haben sind. > > Beispielsweise Leute, die Betrieb bei 5 V brauchen (soll wohl in > der Fahrzeugtechnik noch sehr verbreitet sein). Es gibt meines > Wissens bislang keinen einzigen ARM, der das kann. > Cypress PSoC5
Jörg Wunsch schrieb: > Beispielsweise Leute, die Betrieb bei 5 V brauchen Wenn hier schon Werbung für Atmel und Co gemacht wird, kann ich ja mal Toshiba empfehlen. Cortex-M3 basierende, echte 5V-Devices mit integriertem Spannungsregler für die interne Logik, die auf 1.5V läuft. Also draußen echte 5V-I/Os, intern stromsparende 1.5V für den Core. Typen: M380 und M370 (für Motorcontrol). http://www.toshiba-components.com/microcontroller/M37Sigma.html Industrieanwendungen setzten zum Teil immernoch auf 5V. Damit ist auch die Anbindung an die Leistungselektronik ohne Level-Shifter leichter. Für Automotive: M350 http://www.toshiba-components.com/automotive/autocortexm3.html
> gibt es die M0 von Atmel denn schon? samples ja, production ende 2013 >wollte mir aus Neugier mal anschauen was die können. Aber die Datenblätter >sind ein wenig merkwürdig. Es gibt nicht mal einen Abschnitt wo die maximal >zulässigen Ströme drin stehen. Oder wie man den Quarz anzuschießen hat. > >Oder suche ich nur falsch? nein, das datenblatt ist aj auch noch Preliminary. >Auch vermisse ich die Infos welche Hilfsmittel man zum "brennen" >braucht. SAM D20 Xplained Pro Evaluation Kit hat debugger integriert (j-link) Atmel Studio 6.1 hat Unterstützung eingebaut. gruss gerhard
MCUA schrieb: > Nö. exotische Anwendungen bedeuten sehr geringe Stückzahlen. > Bei den (verfügbaren) 8-Bitern ist das Gegenteil der Fall. > Zudem sind 8-Biter in einigen Fällen leistungsfähiger und besser als > 32Biter. Mit exotisch meinte ich Dinge wie RF, wo man aufgrund des großen analogen Anteils andere Strukturbreiten fährt und deshalb die Siliziumfläche des Cores wieder eine ganz andere Rolle spielt. Riesige Stückzahlen gibt es dort aber auch. Für Standardanwendungen sind Cortex M0 im Moment fast unschlagbar, und das sowohl bei Einzelstücken als auch Millionenstückzahlen. 8-Bit-uC können wenn überhaupt noch mit größerer oder speziellerer Peripherie punkten, aber das liegt einfach daran, dass die M0 noch sehr neu sind. Man sieht ja auch schon, dass sich da sehr viel tut. MCUA schrieb: > Würde ja heissen, dass es in Zukunft nur noch Cores eines -Einzigen- > Herstellers gibt. Na dann gute Nacht. Wie schon erwähnt wurde ist das genau die Situation, die man auf dem PC- und Servermarkt hat. Dort sind vor ca. 5-8 Jahren die letzten nicht-x86-Massenprodukte ausgestorben - heute gibt es nur noch Exoten. Und selbst die Konsolenwelt wird gerade aufgeräumt und wird bald von x86 dominiert. Auch wenn sich eine Architektur durchsetzt, heißt das noch lange nicht, dass es auch nur einen Hersteller gibt. Das sieht man ja auch in der PC-Welt. Und im Embedded-Markt ist es ja so, dass es mehrere Hersteller gibt. Lediglich der Kern wird von einer Firma bereit gestellt, und es gibt ja auch Ansätze von anderen Firmen, kompatible Cores zu entwickeln (Qualcomm wurde ja schon genannt).
8-Bit schrieb: > deshalb die Siliziumfläche des Cores wieder eine ganz andere Rolle > spielt. Ich glaube, die Siliziumfläche des Cores spielt auch bei normalen Controllern nicht die große Rolle. Es überwiegt der Flächenverbrauch der Peripherie und des Speichers (Flash + SRAM) deutlich das bisschen Core. Damit ist es aber nun auch egal, ob der Core ein AVR oder ein CM0 ist.
Besserwisser schrieb: > Wenn hier schon Werbung für Atmel und Co gemacht wird, kann ich ja mal > Toshiba empfehlen. Cortex-M3 basierende, echte 5V-Devices mit > integriertem Spannungsregler für die interne Logik, die auf 1.5V läuft. Gibt es die im DIP-Gehäuse und kannst Du mir die Bestellnummer von R* nennen? Oder soll ich mit RX210 kommen? Ich habe mir erst einmal wieder ein paar hundert ATmega88 bestellt. Deren Möglichkeiten entsprechen meinen Fähigkeiten :-)
Jörg Wunsch schrieb: > Ich glaube, die Siliziumfläche des Cores spielt auch bei normalen > Controllern nicht die große Rolle. Es überwiegt der Flächenverbrauch > der Peripherie und des Speichers (Flash + SRAM) deutlich das > bisschen Core. Damit ist es aber nun auch egal, ob der Core ein > AVR oder ein CM0 ist. Genau das meinte ich. Bei RF-Prozessen sieht das aber vielleicht etwas anders aus, weil man gröbere Strukturen hat. Die Chips haben eben viel weniger Flash und RAM und dafür mehr analoge Schaltung drauf.
Vitamin-B schrieb: > Die Chips haben eben viel weniger Flash und RAM und dafür mehr analoge > Schaltung drauf. Naja, der ATmega256RFR2 hat mit den größten RAM, den AVRs überhaupt so haben (und den zweitgrößten Flash). ;-) (Beides übrigens genauso viel wie der größte SAMD20.)
Ja, es wird wohl auf die tatsächlich verwendete Technologie ankommen. Andere Hersteller setzen bei solchen Anwendungen immer noch stark auf den 8051, aber auch das ändert sich natürlich. Wenn das so funktioniert gibt es jedenfalls noch einen Grund weniger für 8-Bit-uC.
8-Bit schrieb: > Andere Hersteller setzen bei solchen Anwendungen immer noch stark auf > den 8051, aber auch das ändert sich natürlich. Wenn das so funktioniert > gibt es jedenfalls noch einen Grund weniger für 8-Bit-uC. Nur teilweise. Für einen neuen Core/Chip müsste der Hersteller in vielen Bereichen auch qualifizierte Tools bereitstellen. Welche, von den hier diskutierten Teilen, haben den Entwicklungstools mit Qualifizierung für FDA,FAA,MIL etc ? (Gerne auch Drittanbieter) Grüße Andreas P.S: Man glaubt ja kaum wo überall C51/52 cores drin sind. Teilweise ahnt man garnicht, dass da überhaupt irgendwas digitales auch dem Chip ist. A.
Andreas H. schrieb: > Welche, von den hier > diskutierten Teilen, haben den Entwicklungstools mit Qualifizierung für > FDA,FAA,MIL etc ? (Gerne auch Drittanbieter) Gutes Beispiel für eine exotische Anwendung (auch wenn da womöglich auch Millionenstückzahlen dahinterstecken können...)
Auf dem SAM D20 Explained board befinden sich erstaunlich wenige Bauteile? Ist der Debugger auf der Rückseite oder in der MCU selbst integriert? http://store.atmel.com/PartDetail.aspx?q=p:10500351#tc:relatedtools
Besserwisser schrieb: > Also draußen echte 5V-I/Os, intern stromsparende 1.5V für den Core. > Typen: M380 und M370 (für Motorcontrol). Aber die Eingänge sind im Gegenzug auch nicht 3.3V kompatibel wie bei AVR... Beim M374 war ich mal auf nem Workshop bei GLYN. Die Anwendung um einen Motor zu steuern war so am Poller (RAM mäßig) das byteweise am Stack der FreeRTOS Tasks gedreht werden musste damit es überhaupt lief.
>Auch wenn sich eine Architektur durchsetzt, heißt das noch lange nicht, >dass es auch nur einen Hersteller gibt. Doch, der eigentliche CPU-Hersteller ist dann nur Einer, nicht Mehrere. Und nur Einer am Markt (egal welcher) ist immer schlecht! >Das sieht man ja auch in der PC-Welt. Ist total was anderes wie Embedd.Bereich, weil das an PC-Software (X86) festgemacht. Im Embedd.Bereich ist das ja nirgentwo vorgeschrieben. Und mit Sicherheit wird es auch in 20 Jahren noch einige verschiedene CPU-Archit f. Embedd geben.
Jörg Wunsch schrieb: > Geschwindigkeit oder Wortbreiten sind für derartige Anwendungen > völlig nachrangig. Oft genug laufen die zufriedenstellend schon mit > einem Takt von 1 MHz. Nicht jede Applikation muss erst ein Windows > booten, bevor sie arbeiten kann. :-)) Aha, es kommt bei solchen Anwendungen aber auf die Summe von Suspend und Run an. Da kann die CPU noch so wenig im Suspend verbrauchen und dann im Run alles wieder verbraten ;-).
MCUA schrieb: > Doch, der eigentliche CPU-Hersteller ist dann nur Einer, nicht Mehrere. > Und nur Einer am Markt (egal welcher) ist immer schlecht! Nein! Siehe Krait, siehe OpenCores. Es gibt Möglichkeiten, alternative Implementationen einer Architektur zu entwickeln. MCUA schrieb: > Im Embedd.Bereich ist das ja nirgentwo vorgeschrieben. > Und mit Sicherheit wird es auch in 20 Jahren noch einige verschiedene > CPU-Archit f. Embedd geben. Es gibt auch im PC- und Serverbereich noch verschiedene Architekturen. Die spielen keine Rolle mehr. Auch im Embedded-Bereich kommt das Thema Standardsoftware immer stärker. Es fängt bei der Toolchain an und hört bei Echtzeitbetriebssystemen und Standardbibliotheken auf.
>Auf dem SAM D20 Explained board befinden sich erstaunlich wenige >Bauteile? Ist der Debugger auf der Rückseite oder in der MCU selbst >integriert? auf dem board ist der sog, Atmel Embedded Debugger bestückt, welcher eine SWD Schnittselle zum debuggen zur verfügugn stellt. diese kann auch für externe boards verwendet werden. am besten mal das user guide runterladen: http://www.atmel.com/Images/Atmel-42102-SAMD20-Xplained-Pro_User-Guide.pdf gruss gerhard
Karlo schrieb: > Aha, es kommt bei solchen Anwendungen aber auf die Summe von Suspend und > Run an. Da kann die CPU noch so wenig im Suspend verbrauchen und dann im > Run alles wieder verbraten ;-). Da der Stromverbrauch im aktiven Betrieb (solange man weit genug außerhalb des Bereichs der Leckströme bleibt) relativ linear mit der Taktfrequenz skaliert, ist es im Allgemeinen ziemlich egal, ob man 100 µs lang mit 20 MHz oder 2 ms lang mit 1 MHz arbeitet. Kritischer ist in dieser Hinsicht der Einfluss irgendwelcher „Totzeiten“, bspw. falls erst ein Quarz anschwingen muss, bevor die CPU richtig losarbeiten kann. In dieser Zeit fließt ein Strom fast wie im aktiven Betrieb, ohne dass die CPU irgendwas sinnvolles tun würde.
Nö, das stimmt so nicht. Nehmen wir den EFM32TG (oder "Tiny Gecko"): Der verbraucht 210µA/MHz bei 1MHz und 150µA/Mhz bei 32MHz mit einem Cortex M3, der 1,25DMIPS/MHz hat. Das heißt der Energieverbrauch bei gleicher Spannung ist 1.4 höher bei 1MHz verglichen zu 32MHz. Der SD20 soll auch 150µA/MHz können - für welche Frequenzen dies gilt, habe ich noch nicht finden können. Allerdings mit einem Cortex M0+, d.h. mit 0.93 DMIPS/MHz. Damit folgt dass diese MCU ca. 1.34x mehr Energie verbraucht als die mit Cortex M3. D.h. für Anwendugen mit möglichst niedriegem Energieverbrauch lohnt sich der genaue Blick auf die Effizient der CPU und auch die µA/MHz-Werte über die jeweiligen Taktfrequenzen. Dazu kommen natürlich die genannten Unterschiede bzgl. Wake-up-Zeiten (bei EFM32TG 2µs, beim SAM D20 habe ich noch keine Werte gefunden, und vor allem wieviel Strom im Standby verbraucht wird. Beim Tiny Gecko kann ich Funktionen mit 1-2µA erledigen (Display ansteuern, UART, Captouch, etc.). Gruß Cpt Haddock
Cpt Haddock schrieb: > Der verbraucht 210µA/MHz bei 1MHz und 150µA/Mhz bei 32MHz Das ist das, was ich mit „relativ linear“ meinte; es ist eben nicht exakt linear. (Offenbar auch bei den ARMs mit ihren kleinen Strukturen stärker nichtlinear als bei den AVRs mit ihren etwas größeren Strukturbreiten.) Natürlich hängt es immer von der Applikation ab, aber für Applikationen, die viel schlafen, ist der Punkt, an dem der Energieverbrauch während der aktiven Phase nicht mehr dominiert, ganz schnell erreicht. Dann muss man alles Augenmerk auf die Schlafphasen setzen, und zwar auf alles, was da verbaut ist, nicht nur den Prozessor. Es wäre nicht das erste Mal, dass da ein paar Mikroampere durch den Flussmitteldreck abfließen …
Jörg Wunsch schrieb: > Das ist das, was ich mit „relativ linear“ meinte; es ist eben nicht > exakt linear. (Offenbar auch bei den ARMs mit ihren kleinen > Strukturen stärker nichtlinear als bei den AVRs mit ihren etwas > größeren Strukturbreiten.) Logisch, bei kleinen Strukturen nimmt die statische Stromaufnahme extrem zu. Ein großer FPGA im 28nm-Prozess kann schon einmal auf ein halbes Watt rein statische Leistungsaufnahme kommen.
>Es gibt Möglichkeiten, alternative >Implementationen einer Architektur zu entwickeln. Das ists aber keine andere Architektur, sondern fast das Gleiche in Grün. >Es gibt auch im PC- und Serverbereich noch verschiedene Architekturen. PC ist was andere als Server. Bei PC gibts fakt nur X86. >..und hört bei Echtzeitbetriebssystemen und Standardbibliotheken auf. Das benötigt gerade keine bestimmte CPU. Aber alles was Standard-OSs oder -Bibl. sind, hat auch Einschränkungen (ua zu aufgeblähter Code, zu langsam, wegen Std auch eingeschränkt (da man auf spez uC-Features nicht eingehen kann)) gegenüber auf den konkr. Chip optimierte Software. Und genau aus dem Grund wird noch lange nicht jede Appl mit Std-Softw gemacht. (Obwohl manche dass schon seit 20 Jahren proklamieren)
>>..und hört bei Echtzeitbetriebssystemen und Standardbibliotheken auf. Das benötigt gerade keine bestimmte CPU. Also wenn es nicht gerade um Hochsprachenfeindliche Krüppel-ISAs wie 8051 und PIC geht, ist die ISA eines MCUs eigentlich auch ziemlich belanglos. Die Probleme bei der Portierung zwischen den Architekturen entstehen durch die Peripherie. Gerade wenn hier mehr Flexibilität erreicht werden soll, helfen allerdings etwas mehr Rechenpower und 32Bit. Daher ist ein Schritt von 8 auf 32Bit absehbar. Es muss aber keine ARM Monokultur werden. Von den Japanern gibt es noch einige interessante Alternativen. Auch MIPS ist noch nicht tot, wird aber wohl nicht im Low-End MCU bereich zu finden sein. Nur schade, dass Atmel Ihre Produktlinien so breitwillig der Erosion überlassen...
>ist die ISA eines MCUs eigentlich auch ziemlich belanglos.
VonWegen. Die entscheidet über die Leistung (der CPU).
>>ist die ISA eines MCUs eigentlich auch ziemlich belanglos. >VonWegen. Die entscheidet über die Leistung (der CPU). Zur Info: ISA=Instruction Set Architecture. Wie stark unterscheidet sich denn die Performance zwischen AVR und ARM bei Berechnung von 8 Bit Aufgaben? Oder ARM vs. MIPS? Der Unterschied, den die ISA ausmacht ist ab einem gewissen Level relativ marginal. (Wie gesagt, Antikes mal außen vor gelassen)
MCUA schrieb: > Das ists aber keine andere Architektur, sondern fast das Gleiche in > Grün. Wie eben im PC-Markt und x86. Es steht natürlich jedem frei, eigene Architekturen auf den Markt zu bringen und damit erfolgreich zu sein. Nur im Moment sieht es eben so aus, als würde sich ARM durchsetzen. Die 8-Bit-Architekturen werden jedenfalls nicht in der heutigen Breite überleben und eine wirkliche Konkurrenz für die Cortex M gibt es auch noch nicht. MCUA schrieb: > Aber alles was Standard-OSs oder -Bibl. sind, hat auch Einschränkungen > (ua zu aufgeblähter Code, zu langsam, wegen Std auch eingeschränkt (da > man auf spez uC-Features nicht eingehen kann)) gegenüber auf den konkr. > Chip optimierte Software. Vorurteile, die heutzutage oftmals gar nicht mehr zutreffen. Heutzutage setzt mal lieber auf einen stärkeren Core (eben z.B. einem Cortex M) und verwendet Standardbibliotheken. Time-To-Market wird heutzutage vielmals höher bewertet als Kostenoptimierung auf den letzten Cent. Wobei die Cortex-M ja sogar Kostenvorteile bieten. MCUA schrieb: > Und genau aus dem Grund wird noch lange nicht jede Appl mit Std-Softw > gemacht. (Obwohl manche dass schon seit 20 Jahren proklamieren) Meine Erfahrung ist eher, dass das mehr am Ego der Programmierer liegt als an "harten" Gründen.
8-Bit schrieb: > Vorurteile, die heutzutage oftmals gar nicht mehr zutreffen. Heutzutage > setzt mal lieber auf einen stärkeren Core (eben z.B. einem Cortex M) und > verwendet Standardbibliotheken. Time-To-Market wird heutzutage vielmals > höher bewertet als Kostenoptimierung auf den letzten Cent. Wobei die > Cortex-M ja sogar Kostenvorteile bieten. Was soll "man" jetzt mit dieser Aussage anfangen? Wer ist überhaupt "man"? Persönlich nehme ich immer noch die Teile, die für die betreffende Anwendung sinnvoll sind. Wenn ich mich nach "man" richten müßte, müßte ich jeden Sonntag mit dem Geländewagen zum Bäcker fahren. Ich laufe lieber!
Noch ein Nachtrag zum Thema Energiefreundlichkeit (s.a. oben): Jörg Wunsch schrieb: > Das ist das, was ich mit „relativ linear“ meinte; es ist eben nicht > exakt linear. (Offenbar auch bei den ARMs mit ihren kleinen > Strukturen stärker nichtlinear als bei den AVRs mit ihren etwas > größeren Strukturbreiten Der AVR-8 hat 0.328DMIPS/MHz (http://www.ecrostech.com/Other/Resources/Dhrystone.htm) Ein ATTiny hat ca. 375µA/MHz (1.5mA@3V@4MHz). D.h. er verbraucht bezogen auf DMIPS ~9x mehr als ein Tiny Gecko mit ARM Cortex M3. Das ist nun natürlich bezogen auf einen rechenintensiven Benchmark. D.h. bei sehr einfachen Applikation ohne viel Anforderungen an die CPU (ud vielleicht noch in Assembler programmiert?!) wird der ATTiny seinen Dienst mit wenig Energie tun. Die Zeiten der Autocodegeneratoren, Libraries, C/C++,... + mehr benötigte lokale Rechenperformance treiben die Rechenleistung nach oben. Wie bei jedem Thema: Gute Analyse der eigenen Anforderungen und Benchmark mit eigenen Code auf den Eval-Boards der möglichen MCU-Kandidate. Bei mir hat der Tiny Gecko (EFM32TG) gewonnen :-)
M. N. schrieb: > Was soll "man" jetzt mit dieser Aussage anfangen? Wer ist überhaupt > "man"? > Persönlich nehme ich immer noch die Teile, die für die betreffende > Anwendung sinnvoll sind. Natürlich kannst du für dich machen, was du willst. Ich beschreibe nur die Situation, wenn es in der Industrie um Stückzahlen, Kosten, Qualität und Wartbarkeit geht.
Cpt Haddock schrieb: > Das ist nun natürlich bezogen auf einen rechenintensiven Benchmark. Richtig. Ein „Controller“ jedoch heißt ja vor allem deshalb so, weil er etwas steuert. Solche Aufgaben sind oft genug IO-intensiv, und die reine Rechenleistung rückt massiv in den Hintergrund. Wenn du nur 2 Taster und 3 LEDs zu bearbeiten hast, dann bringt es dir keinen Systemvorteil mehr, dass deine CPU 32 Bits auf einmal durchsetzt. Dieser Systemvorteil ist aber bei Rechen-Benchmarks wie Dhrystone natürlich immer implizit dabei. Aber s. o., batteriebetriebene Geräte verbrauchen oft nach meinen Erfahrungen einen nicht zu unterschätzenden Teil ihrer Energie in der Schlafphase. Die paar Dhrystones interessieren dort überhaupt nicht :), und man muss die Hardware insgesamt optimieren. Mit ihren kleinen Strukturgrößen haben die ARMs hier einen systembedingten Nachteil aufgrund ihrer viel größeren Leckströme, den sie nun durch technische Tricks erst allmählich wettmachen können. (Energymicro dürften die ersten gewesen sein, die in dieser Richtung was hatten.)
8-Bit schrieb: > Natürlich kannst du für dich machen, was du willst. Ich beschreibe nur > die Situation, wenn es in der Industrie um Stückzahlen, Kosten, Qualität > und Wartbarkeit geht. Das ist eine gewagte Aussage. Hast Du Zahlen, dies zu belegen? Wer ist denn die "Industrie"? Ein homogener Haufen, der irgendwelchen Maktprognosen-Gurus hinterherläuft? Das glaube ich nicht! Ich sehe auch einen Unterschied, ob jemand in Stückzahlen Autos, Telefone, Fernseher oder Staubsauger herstellt. Gerade bei consumer-Elektronik ist es doch mit Qualität und Wartbarkeit eh nicht weit her. Hoffentlich bleibt eine Vielzahl diverser Architekturen noch lange erhalten. Je nach Anwendung sind die Anforderungen immer unterschiedlich und somit bleibt auch Platz für persönliche Vorlieben und Abneigungen, denen sich keiner entziehen kann. Wer einen 8051 in der Muttermilch hatte, dem wird er weiterhin gut schmecken :-) Wenn hier an einer Stelle um nA gefeilscht wird, ist das für Manche substantiell und für andere völlig belanglos. Für Anwendungen, wo viel gerechnet werden muß, sind 32Bit Register eine Wohltat. Die braucht man aber überhaupt nicht, um ein paar IO-Pins wackeln zu lassen. Ganz zu schweigen von einem 4GB IO-Adressraum, wie er an anderer Stelle vor ein paar Tagen erwähnt wurde. Um auf den Titel zurückzukommen: Atmel hat jetzt einen Cortex-M0+ im Angebot. Das ist ja schön, läßt mich aber völlig kalt. Und aus Erfahrung gefragt: Können sie überhaupt liefern? Wenn nicht, wann denn? Und kontinuierlich oder mal für eine halbes Jahr kein einziges Stück? Der Punkt fehlt in der obigen Auflistung: Verfügbarkeit :-)
M. N. schrieb: > Das ist eine gewagte Aussage. Hast Du Zahlen, dies zu belegen? > Wer ist denn die "Industrie"? Ein homogener Haufen, der irgendwelchen > Maktprognosen-Gurus hinterherläuft? Das glaube ich nicht! Natürlich gibt es unendlich viele Anwendungen und Nischen, in denen andere Lösungen sinnvoll sind. Ich spreche hauptsächlich von Automotive, Consumer und Industrieanwendungen. In den meisten Anwendungen haben dort 32-Bit-uC die Nase vorne. Für Neuentwicklung versteht sich, es wird natürlich auch noch in vielen Jahren Altsysteme mit 8-Bit-uC geben (das ist wohl der Hauptgrund, wieso es noch recht viele 8051er gibt). Marktprognosen interessiert keinen profesionellen Ingenieur. Es geht rein um die technische Weiterentwicklung. Die Cortex M sind eben heute in vielerlei Hinsicht das Maß der Dinge. M. N. schrieb: > Ich sehe auch einen Unterschied, ob jemand in Stückzahlen Autos, > Telefone, Fernseher oder Staubsauger herstellt. Gerade bei > consumer-Elektronik ist es doch mit Qualität und Wartbarkeit eh nicht > weit her. Wenn es um den Preis geht, sind die ARM-uC weit vorne. Heute bekommt man einen Cortex M4 für einen Preis, für den man vor vier Jahren gerade mal einen größeren Atmega oder MSP430 bekommen hat. Und wirklich billiger geworden sind die auch nicht. M. N. schrieb: > Wer einen 8051 in der Muttermilch > hatte, dem wird er weiterhin gut schmecken :-) Professionelle Ingenieure müssen anders denken. Da geht es um harte Fakten, nicht um Vorlieben und Gefühle. M. N. schrieb: > Und aus Erfahrung gefragt: Können sie überhaupt liefern? Wenn nicht, > wann denn? Und kontinuierlich oder mal für eine halbes Jahr kein > einziges Stück? Atmel hat sich in dieser Hinsicht in den letzten Jahren massiv verbessert.
8-Bit schrieb: > M. N. schrieb: >> Und aus Erfahrung gefragt: Können sie überhaupt liefern? Wenn nicht, >> wann denn? Und kontinuierlich oder mal für eine halbes Jahr kein >> einziges Stück? > > Atmel hat sich in dieser Hinsicht in den letzten Jahren massiv > verbessert. Du reihst Behauptung an Behauptung. Kannst du wenigstens diese belegen.
Lohnt es sich denn überhaupt noch sich mit zb.8Bit AVR zubeschäftigen, Denn wenn ich mir ansehe was ein Atmega128 kostet kriegt ich fast zum gleichen Preis ein STM32F103ZET6
>Wenn es um den Preis geht, sind die ARM-uC weit vorne. Das sind nicht die Einzigsten, die günstig sind. >Ich spreche hauptsächlich von Automotive, >Consumer und Industrieanwendungen. AchNe. Also gehen alle 8Biter zu den Hobbyisten? >In den meisten Anwendungen haben dort >32-Bit-uC die Nase vorne. Keineswegs. >Professionelle Ingenieure müssen anders denken. Da geht es um harte >Fakten, nicht um Vorlieben und Gefühle. Jo. Und das Beste wird genommen. Und das ist noch lange nicht immer ARM. >Hoffentlich bleibt eine Vielzahl diverser Architekturen noch lange >erhalten. Mit Sicherheit. Denn es gibt viel zu viele Anwendungen, als dass da nur eine Archit. Platz finden sollte.
Davis schrieb: > Du reihst Behauptung an Behauptung. Kannst du wenigstens diese belegen. Tut mir leid, geht nicht - NDA sei Dank. MCUA schrieb: > Das sind nicht die Einzigsten, die günstig sind. Ja, andere 32-Bit-uC, zum Beispiel von TI, sind teilweise auch sehr günstig. MCUA schrieb: > AchNe. Also gehen alle 8Biter zu den Hobbyisten? Wie gesagt - Altsysteme. Vor zwei/drei Jahren war die Situation noch ganz anders. MCUA schrieb: > Jo. Und das Beste wird genommen. > Und das ist noch lange nicht immer ARM. Aber immer öfter.
dennis schrieb: > Denn wenn ich mir ansehe was ein Atmega128 kostet Der kostet Museumsgebühren. Aber in diesem Thread ging's um ein anderes Thema, nämlich die SAMD20. Wenn du etwas völlig anderes anfangen willst, dannn bitte in einem eigenen Thread.
8-Bit schrieb: > M. N. schrieb: >> Wer einen 8051 in der Muttermilch >> hatte, dem wird er weiterhin gut schmecken :-) > > Professionelle Ingenieure müssen anders denken. Da geht es um harte > Fakten, nicht um Vorlieben und Gefühle. Ach, wenn das so wäre, gäbe es keine Promo-Boards zum 'Anfüttern'. Würde ein STM32F407-Discovery-Board € 395,-- netto kosten, wäre es hier nie erwähnt worden und nicht bei mir auf dem Tisch gelandet. Allein die Lektüre des Datenblattes würde mir zum Schnuppern nicht reichen, auch wenn die dortigen Zahlen gut aussehen (und die Errata ganz woanders stehen). Aber gut, ich bin ja kein professioneller Ingenieur, ich verdiene nur mein Geld mit dem Kram, von dem ich erwarte, dass er mir auch noch Spaß macht. 8-Bit schrieb: > Davis schrieb: >> Du reihst Behauptung an Behauptung. Kannst du wenigstens diese belegen. > > Tut mir leid, geht nicht - NDA sei Dank. Wessen NDA? Oder NSA? Mir kommt das Alles etwas vor, wie das Hochjubeln von Aktien. Wenn sie am nächsten Tag ins Bodenlose gefallen sind, kommt der nächste Experte, der das schon immer vorausgesagt hat.
M. N. schrieb: > Ach, wenn das so wäre, gäbe es keine Promo-Boards zum 'Anfüttern'. Würde > ein STM32F407-Discovery-Board € 395,-- netto kosten, wäre es hier nie > erwähnt worden und nicht bei mir auf dem Tisch gelandet. Die Verfügbarkeit von Entwicklungstools spielt natürlich eine gewisse Rolle. Und gerade bei Konzernen ist es einfacher, wenn man sich vom FAE ein paar Low-Cost-Eval-Kits kostenlos zuschicken lassen kann. Und natürlich spielt es bei gleichwertigen Produkten eine Rolle, ob man vielleicht als Student oder privat schon einmal mit dem ein oder anderen Baustein gearbeitet hat. M. N. schrieb: > Wessen NDA? Wenn du deine Brötchen mit Entwicklung verdienst, solltest du eigentlich wissen, dass du Firmengeheimnisse nicht ausplaudern darfst. Aber du bist ja nur Bastler, wie du ja selbst sagst, da kannst du so etwas natürlich nicht wissen.
>> Du reihst Behauptung an Behauptung. Kannst du wenigstens diese belegen. > Tut mir leid, geht nicht - NDA sei Dank. Totaler Humbug. Etwaige NDA-Kenntnisse haben nichts mit Markt-Kenntnissen zu tun. Und wenn man eine F-i-r-m-a kennt, kennt man den M-a-r-k-t noch lange nicht!
MCUA schrieb: > Totaler Humbug. > Etwaige NDA-Kenntnisse haben nichts mit Markt-Kenntnissen zu tun. > Und wenn man eine F-i-r-m-a kennt, kennt man den M-a-r-k-t noch lange > nicht! Also nochmal langsam. Es ging darum, dass jemand nach Belegen für das Lieferverhalten einer Firma fragt. Diese Belege kann ich nicht herausrücken, ohne Firmengeheimnisse zu verraten. Dazu gehören nämlich nicht nur technische Infos, sondern auch konkrete Angaben über Lieferzeiten, Stückzahlen, Preise, Abkündigungen (diese werden den großen Kunden nämlich schon viel früher mitgeteilt) usw. Ich kann nur sagen, dass sich Atmel in dieser Hinsicht in den letzten zehn Jahren massiv gebessert hat, weil sie bei einigen großen Kunden Probleme bekommen haben.
8-Bit schrieb: > Also nochmal langsam. Es ging darum, dass jemand nach Belegen für das > Lieferverhalten einer Firma fragt. Da hat sich etwas missverständlich entwickelt. Als Bastler ist mir Atmel im Grunde doch Schnuppe. Mir ging es um diese (Markt) Aussagen: 8-Bit schrieb: > Es steht natürlich jedem frei, eigene Architekturen auf den Markt zu > bringen und damit erfolgreich zu sein. Nur im Moment sieht es eben so > aus, als würde sich ARM durchsetzen. Die 8-Bit-Architekturen werden > jedenfalls nicht in der heutigen Breite überleben und eine wirkliche > Konkurrenz für die Cortex M gibt es auch noch nicht. > ... > Heutzutage > setzt mal lieber auf einen stärkeren Core (eben z.B. einem Cortex M) und > verwendet Standardbibliotheken. Time-To-Market wird heutzutage vielmals > höher bewertet als Kostenoptimierung auf den letzten Cent. Wobei die > Cortex-M ja sogar Kostenvorteile bieten. Das ist doch weichgespültes Marktgeschreie - konkrete Angaben bleiben aus! Und wenn Jemand Zahlen dazu liefert, möchte ich auch gerne wissen, von wem er bezahlt wird und welche Aktien er im Depot hat. Du scheinst nur Cortex-M zu kennen, die auch ihre Schwächen haben. Diskussionen darüber gab es schon vor längerer Zeit. Ich muß aber noch einmal hierauf zurückkommen: 8-Bit schrieb: > Professionelle Ingenieure müssen anders denken. Da geht es um harte > Fakten, nicht um Vorlieben und Gefühle. Dabei fällt mir unweigerlich BER ein. Knallharte Profis basteln Milliarden in den Brandenburger Sand.
Jörg Wunsch schrieb: > Aber s. o., batteriebetriebene Geräte verbrauchen oft nach meinen > Erfahrungen einen nicht zu unterschätzenden Teil ihrer Energie in > der Schlafphase. Die paar Dhrystones interessieren dort überhaupt > nicht :), und man muss die Hardware insgesamt optimieren. Mit ihren > kleinen Strukturgrößen haben die ARMs hier einen systembedingten > Nachteil aufgrund ihrer viel größeren Leckströme, den sie nun durch > technische Tricks erst allmählich wettmachen können. (Energymicro > dürften die ersten gewesen sein, die in dieser Richtung was hatten.) Hi Jörg, kann ich nur bestätigen! In diesem Feld hat sich der Tiny Gecko als sehr sparsam erwiesen. Ich kann viele Funktionen mit nur 1-2µA durchführen und dank eines Event Systems (bei Energy Micro heißt es PRS) Ablaufsteuerungen in den Deep Sleep Mode verlagern. Aber dennoch: Ich kann sehr schön die Libs verwenden und in C programmieren ohne mir die Finger krumm zu programmieren und bekomme mehr Leistung zu weniger Energie. Das möchte ich nicht mehr vermissen. So, nun reicht's für diesen Thread, der eher esoterisch wird. Es scheinen sich hier eher die Marketing-Heinis der Hersteller auszuweinen. Ich dachte das Forum ist für Bastler und Tüftler. Mit diesen Worten eines knallharten Bastlers ... :-) Schönes Wochenende!
M. N. schrieb: > Das ist doch weichgespültes Marktgeschreie - konkrete Angaben bleiben > aus! Und wenn Jemand Zahlen dazu liefert, möchte ich auch gerne wissen, > von wem er bezahlt wird und welche Aktien er im Depot hat. Ich hatte mal Aktien von Atmel, Infineon und TI. ARM hatte ich noch nicht, darüber ärgere ich mich jetzt. Ansonsten sitze ich auf Kundenseite und setze dabei unter anderen Atmel, Microchip, TI und Renesas ein. Wie du dir denken kannst, waren da nicht nur ARM-Prozessoren dabei. Ich kann dir nur sagen, dass wir für Neuprojekte Angebote von verschiedensten Prozessoren verglichen haben und die neueren 32-Bit-uC hatten preislich immer die Nase vorne. Im Low-Cost-Bereich (ab 30-50 Cent) ist der Cortex M0 fast unschlagbar. Der M4 hat noch mehr Konkurrenz, zum Beispiel durch den C2000. Dabei ging es um 5-6stellige Stückzahlen. Für einen Bastler ist das logischerweise weniger relevant, dem ist im Endeffekt egal, ob der Chip jetzt 1 oder 5 Euro kostet. Und ich kann dir sagen, wie wir bei solchen Stückzahlen in der Entwicklung vorgehen. Wir haben zum Beispiel eine Anwendung, ganz einfaches Datenhandling, ein paar ADC-Kanäle auslesen, kleine Umrechnung und über die serielle Schnittstelle verteilen. So etwas kann jeder 8-Bit-AVR problemlos. Wir setzen dort trotzdem einen 32-Bit-uC ein, weil wir damit auf die gleiche Softwareplattform einsetzen können, die wir auch für unsere größeren Anwendungen verwenden. Dadurch entfällt nicht nur Entwicklungs-, sondern vor allem Doku- und Testaufwand. Insgesamt etwa 2 Mannmonate. Und dabei ist der Prozessor sogar noch günstiger als die üblichen 8-Bit-AVR, dir wir sonst teilweise im Einsatz hatten. Das war jetzt mal ein Beispiel, aber wir sind ja ständig mit den FAE der Hersteller in Kontakt und die plaudern auch mal aus dem Nähkästchen. Und da hört man auch etwas heraus, wie andere Firmen unterwegs sind. Und es sieht wohl so aus, als wären wir nicht die einzigen, die so arbeiten. Vermutlich ist das jetzt auch für dich wieder nur "weichgespültes Marketinggeschrei", weil es nicht so ganz in dein Weltbild hineinpasst. Aber da kann ich dir jetzt auch nicht mehr helfen.
8-Bit schrieb: > Und ich kann dir sagen, wie wir bei solchen Stückzahlen in der > Entwicklung vorgehen. Wir haben zum Beispiel eine Anwendung, ganz > einfaches Datenhandling, ein paar ADC-Kanäle auslesen, kleine Umrechnung > und über die serielle Schnittstelle verteilen. So etwas kann jeder > 8-Bit-AVR problemlos. Wir setzen dort trotzdem einen 32-Bit-uC ein, weil > wir damit auf die gleiche Softwareplattform einsetzen können, die wir > auch für unsere größeren Anwendungen verwenden. Dadurch entfällt nicht > nur Entwicklungs-, sondern vor allem Doku- und Testaufwand. Insgesamt > etwa 2 Mannmonate. Und dabei ist der Prozessor sogar noch günstiger als > die üblichen 8-Bit-AVR, dir wir sonst teilweise im Einsatz hatten. Das ist für mich der Hauptgrund gewesen, jetzt für Neuentwicklungen komplett auf 32 Bit (und da die STM32) zu gehen: man hat nur noch eine Plattform, die leistungsmäßig eben einen deutlich größeren Bereich abdeckt als bspw. die AVR-Serie. Das heisst für uns: Bibliotheken nur noch für eine Architektur, kein Umdenken/Einarbeiten mehr, nur eine Werkzeugkette etc. Dazu gibt es die ARMs ja mittlerweile in einer gigantischen Fülle an Typen. Da ist für unsere Aufgaben immer ein passender dabei. Der Preis ist bei uns nicht wichtig - die Entwicklungskosten übersteigen bei unseren geringen Stückzahlen die Bauteilkosten bei weitem.
Im Automotive-Bereich gibt es noch andere Andorderungen z.B. an die Robustheit. Da spielt der Temperaturbreich, EMV-Festigkeit und Flash-Lebensdauer ein Rolle. Also kurz: wie zuverlässig ist der Controller über Lebendauer. Da können Argumente wie größere Rechenleistung zu gleichem Preis schnell in den Hintergrund geraten.
8-Bit schrieb: > Vermutlich ist das jetzt auch für dich wieder nur "weichgespültes > Marketinggeschrei", weil es nicht so ganz in dein Weltbild hineinpasst. Im Gegenteil, ich freue mich über Deine konkreten, konstruktiven Aussagen. Ich mag es nur nicht, wenn Leute vorgeben wollen, wohin der Hase läuft und alle hinterherlaufen sollen. Meine Stückzahlen liegen nur im dreistelligen Bereich, daher ist der Einzelpreis nicht so entscheidend. Vielleicht kennst Du ja die RX6x und die STM32F4xx. Letzterer ist schön schnell, aber Ersterer zehnmal 'schöner' zu programmieren. Mal sehen, wie ich mich entscheiden werde. 8-Bit schrieb: > Im Low-Cost-Bereich (ab 30-50 > Cent) ist der Cortex M0 fast unschlagbar. Dieses Teil, zu dem Preis, in einem TQFP32/48, dass man auch alle Interna nutzen kann: da bin ich dabei :-)
Chris D. schrieb: > Das ist für mich der Hauptgrund gewesen, jetzt für Neuentwicklungen > komplett auf 32 Bit (und da die STM32) zu gehen: man hat nur noch eine > Plattform, die leistungsmäßig eben einen deutlich größeren Bereich > abdeckt als bspw. die AVR-Serie. Genau das meinte ich damit. chris schrieb: > Im Automotive-Bereich gibt es noch andere Andorderungen z.B. an die > Robustheit. > Da spielt der Temperaturbreich, EMV-Festigkeit und Flash-Lebensdauer ein > Rolle. Also kurz: wie zuverlässig ist der Controller über Lebendauer. Da > können Argumente wie größere Rechenleistung zu gleichem Preis schnell in > den Hintergrund geraten. Richtig. Mit ARM ist man an sich da nicht falsch unterwegs, schließlich sind bei den Cortex M doch sehr viele Erfahrungen aus dem sehr bewährten ARM7 eingeflossen. Es hängt dann eher von der Implementation und der Umgebung ab. Gerade die von dir erwähnten Punkte hängen eher an der Technologie, nicht an der Architektur des Rechenkerns. M. N. schrieb: > Im Gegenteil, ich freue mich über Deine konkreten, konstruktiven > Aussagen. Ich mag es nur nicht, wenn Leute vorgeben wollen, wohin der > Hase läuft und alle hinterherlaufen sollen. Ich habe mit keinem Wort geschrieben, dass sich jemand nach meinen Aussagen richten muss. Ich habe lediglich eine Beobachtung beschrieben. Mag sein, dass das falsch ankam, aber das liegt auch an der Interpretation des Lesers. M. N. schrieb: > Dieses Teil, zu dem Preis, in einem TQFP32/48, dass man auch alle > Interna nutzen kann: da bin ich dabei :-) Gibt es, aber eben erst bei entsprechenden Stückzahlen.
M. N. schrieb: > Dieses Teil, zu dem Preis, in einem TQFP32/48, dass man auch alle > Interna nutzen kann: da bin ich dabei :-) Freescale MKL05Z8VLC4 liegt bei 250 Stück bei ~ 0,74 € (Digi Key)
Mal ein Beispiel: Beim Übergang von MEGA auf den XMEGA ist es pi mal daumen beim gleichen Kern, aber leider komplett neue Onchip-Peripherie. Das war so als ob man einen komplett neuen Controller vor sich hatte (trotz IDE). IHMO ist beim Wechsel oft die OnChip-Peripherie das Problem. Sogar innerhalb der "Familie" bzw. des Kerns. Natürlich würde auch die MCU-Linie nehmen, die meine Anwendungen am besten abdecken. Für den einen sind es ARM, für den anderen MSP, der nächste nimmt 8051...
Alle schreien ARM, aber clevere Entwickler gehen Hybrid und nutzen ARM UND AVR ;-) http://www.kickstarter.com/projects/secretlabs/agent-the-worlds-smartest-watch Wenn ich mich nicht täusche ist es ein tiny1634. So jetzt mal meine Fragen: - Warum nicht diese olle TinyGecko Familie? - Warum überhaupt Hybrid und nicht EnergyMicro die ja so energieeffizient sein sollen? - Warum wurde kein CortexM0(+) genommen, dann hätte man ja eine Toolchain nutzen können Ich stell mal meine Behauptungen und Fragen auf: - EM sei gar nicht so stromsparend wie der Name suggeriren soll - Der Preis ob ein Cortex günstiger als ein AVR ist sei reine Verhandlungssache und vom Geschick des Einkäufers abhängig - Wenn man einen AVR zum Mercedes-Preis verkaufen kann, warum soll man dann den Preis halbieren und zum CortexM0 Preis verkaufen? Offensichtlich ist einigen vielen Leuten der Preis wert - Den End-Preis bestimmen die Distributoren, wenn sie ein Produkt teurer verkaufen können dann ist es ok. Offensichtlich lässt sich der Cortex lediglich über den Preis den Kunden schmackhaft machen, wäre der Preis dem AVR gleich, würden wohl mehrere beim AVR bleiben. Offensichtlich gibt es doch nicht genug Vorteile um den Cortex gut verkaufen zu können. - Warum verkauft ein Produzent A z.b. einen AVR für 2.5Euro, wobei man bei einigen Konkurrenten (laut Marketing) mehr Leistung, 32Bit zum halben Preis bekommt? Warum hat man den Cortex, der ja 4x soviele Bits hat wie ein AVR (ich sag jetzt auch mal wie ein PIC oder ähnliche, damit es hier nicht so einschlägig wird ;-)), viel mehr MHz aufweist, nicht z.b. 4x teurer verkauft? Oder zumindest den Preis dem AVR gleichgestellt? Warum muß man den Preis den so niedrig ansetzen um überhaupt was verkaufen zu können? Taugt der Cortex doch nicht so wie ARM marketing es allen andrehen will? Schon interessant oder? Warum verlieren die anderen Produzenten (ok Atmel hat jetzt auch einen Cortex der die 8Bitter ersetzen soll) freiwillig Geld? Wenn ich ein Produkt hätte, z.b. ein VW Golf der 7Liter verbraucht, und dieser 30000Euro kostet, und nun bringt ein Konkurrent eine Alternative zum Golf raus der nur noch 3.5Liter verbraucht, viel schneller fährt und mehr Zylinder hat (Bits), ja warum muß dieser Produzent dann noch den Preis auf 15000Euro setzen um dieses Fahrzeug verkaufen zu können? Und warum kaufen dann Leute immer noch den Golf? fragen über fragen, aber ich hab grad ne Flasche Wein auf ;-)
Matthias schrieb: > gibt es doch nicht genug Vorteile um den Cortex gut verkaufen zu können. > - Warum verkauft ein Produzent A z.b. einen AVR für 2.5Euro, wobei man > bei einigen Konkurrenten (laut Marketing) mehr Leistung, 32Bit zum > halben Preis bekommt? Ganz einfach: Er wird ihn bald nicht mehr verkaufen - zumindest nicht für Neuprojekte. Es gibt aber genug Altprodukte, die logischerweise nicht mehr auf eine neue Architektur umgestellt werden können. Aber mit diesen Altprojekten wird auch die alte, teure Architektur (bzw. Technologie) aussterben. Matthias schrieb: > Warum muß man den Preis den so niedrig ansetzen um > überhaupt was verkaufen zu können? Taugt der Cortex doch nicht so wie > ARM marketing es allen andrehen will? Den ARM kann man aufgrund der neueren Fertigungsprozesse viel billiger produzieren. Der Rest ist reines Gesetz des Marktes: Es gibt viel Konkurrenz und ein wichtiges Kriterium ist der Preis, besonders wenn man sich nicht mehr technisch hervorheben kann. Bei Low-Cost-uC ist das eben der Fall. Das ist im übrigen eine fast lehrbuchreife Penetrationsstrategie. Matthias schrieb: > ja warum muß dieser > Produzent dann noch den Preis auf 15000Euro setzen um dieses Fahrzeug > verkaufen zu können? Weil es nicht nur einen Konkurrenten gibt, sondern viele. Sie konkurrieren schon lange nicht mehr mit dem Golf mit 7 Liter Verbrauch, sondern untereinander. Matthias schrieb: > Und warum kaufen dann Leute immer noch den Golf? Hier hinkt der Vergleich. Wie erwähnt handelt es sich dabei meistens noch um Altprojekte, die entweder schon weit im Produktlebenszyklus stehen oder noch auf einer alten Softwareplattform basieren, die nicht mehr portiert werden soll. Das ist ein Prozess, der sich über Jahrzehnte zieht. Er hat aber erst vor etwa ein bis zwei Jahren begonnen. Wir stehen also noch ganz am Anfang, und deshalb kaufen natürlich noch viele die alten Prozessoren für einen teuren Preis.
8-Bit schrieb: >> FDA,FAA,MIL etc ? (Gerne auch Drittanbieter) > > Gutes Beispiel für eine exotische Anwendung (auch wenn da womöglich auch > Millionenstückzahlen dahinterstecken können...) Exotische Anwendung ? FDA ist die Foot & Drugs Administration, deren (abgeleitete) MPG Vorschriften in D, die Grundlage aller Zulassungen für Medizingeräte sind. FAA ist die Federal Aviation Administration, mit der man sich rumschlägt, wenn irgendwas im Bereich Luft- & Raumfahrttechnik zugelassen werden soll. Da greift dann auch schon oft der MIL-Standard. Exotische Anwendungen ! Alles klar^^ Grüße Andreas
Preisfrage: Wann verlangen diese Vorschriften tatsächlich eine zertifizierte Toolchain? Also wirklich zwingend verlangen, nicht nur empfehlen. Letzeres wird in quasi jeder Norm gemacht, man kann es aber auch quasi immer durch andere Methoden umgehen.
8-Bit schrieb: > Preisfrage: Wann verlangen diese Vorschriften tatsächlich eine > zertifizierte Toolchain? Also wirklich zwingend verlangen, nicht nur > empfehlen. Die Frage stellt sich doch meist so gar nicht. Wenn Du aber z.B. bei einem Medizingerät in den USA einen Case hast, dann musst DU nachweisen, dass Du nach dem aktuellen Stand der Technik gearbeitet hast. Und das schliesst z.B. auch ein, dass Du Dich bestmöglichst von der Brauchbarkeit Deiner Werkzeuge überzeugt hast. Und wie machst Du das ? Z.B. Indem Du Compiler benutzt, die von einer "fachkundigen Stelle" zertifiziert sind. Oft wird das auch direkt vom Kunden verlangt, der genau in dieser Situation NICHT feststellen will, dass sein Zulieferer (also DU) durch ungenügende Entwicklungsprozesse (incl. Tools) das Ganze versiebt hat. Das wird dann nämlich richtig teuer. Grüße Andreas
Chris D. schrieb: > Das ist für mich der Hauptgrund gewesen, jetzt für Neuentwicklungen > komplett auf 32 Bit (und da die STM32) zu gehen: man hat nur noch eine > Plattform, die leistungsmäßig eben einen deutlich größeren Bereich > abdeckt als bspw. die AVR-Serie. Mich würde interessieren, mit welchen µCs Du zuvor gearbeitet hast, und ob diese mit ihrer Leistung nicht sowieso schon am Anschlag waren. Nur AVR? Setzt Du auch die 'kleineren Brüder' STM32F051 ein? Arc Net schrieb: > Freescale MKL05Z8VLC4 liegt bei 250 Stück bei ~ 0,74 € (Digi Key) Die gefallen mir nicht so recht. Auch wird wieder deutlich, das ARM nur der Kern ist, die Peripherie hängt wieder ganz von den Vorlieben (und der µC-Entwicklungsgeschichte) des jeweiligen Herstellers ab. Wenn man auf der einen Seite mit STM32 arbeitet und dann beispielsweise mit obigen Freescale-Typen, ist es mit gemeinsamen, erprobten Bibliotheken wieder Essig. Um noch einmal auf die oben angesprochene 5V-Fähigkeit zu kommen: sobald im System MOSFETs, Motortreiber (L6203), o.ä. direkt angesteuert werden sollen/müssen, kann man dies mit 5V-µCs (AVR) sehr einfach erledigen. Auch aus diesem Grund sind für mich die Cortex-M0 noch nicht so zündend, obwohl die Interrupt-Prioritäten schon ihren Reiz haben ...
M. N. schrieb: > Chris D. schrieb: >> Das ist für mich der Hauptgrund gewesen, jetzt für Neuentwicklungen >> komplett auf 32 Bit (und da die STM32) zu gehen: man hat nur noch eine >> Plattform, die leistungsmäßig eben einen deutlich größeren Bereich >> abdeckt als bspw. die AVR-Serie. > > Mich würde interessieren, mit welchen µCs Du zuvor gearbeitet hast, und > ob diese mit ihrer Leistung nicht sowieso schon am Anschlag waren. Nur > AVR? Wir hier haben davor nur die AVRs eingesetzt (attiny, atmega). Ja, die waren irgendwann am Anschlag - spätestens mit Ansteuerung eines TFTs etc. wird es eben eng. > Setzt Du auch die 'kleineren Brüder' STM32F051 ein? Ja, für einfache Sachen durchaus. Wie gesagt: das breite Leistungsspektrum der STM32 hat mich überzeugt. Ich habe jetzt für jede Anwendung hier den passenden Controller - aus einer Familie. Und manchmal wachsen mit der Entwicklung auch die Anforderungen (kennst Du vermutlich selbst ;-). Da ist es gut, wenn man ohne Probleme den nächstgrößeren Typen wählen kann und nach oben viel Luft hat. Wie gesagt: der Preis ist für mich eher Nebensache, da die Bauteilkosten bei den geringen Stückzahlen (hauptsächlich für chem. Industrie) hier praktisch keine Rolle spielen. Mir geht es darum, nur noch eine Plattform pflegen zu müssen. Und wenn man die Bibliotheken von Anfang an modular aufbaut (so wie wir jetzt hier) und/oder ein passendes OS nimmt (hier NuttX), dann ist auch der (eventuelle) Wechsel zu Herstellern anderer ARM-Familien nicht mehr so wild. Wenn ST die Grätsche macht, wäre das jetzt nicht mehr dramatisch für uns - im Gegensatz zu einer Atmel-Pleite damals. Das ist für uns ein dicker Pluspunkt für ARM. Und natürlich sind bei unseren Anwendungen mit entsprechenden Integer-Werten 32-Bit einfach deutlich schneller - vom Takt mal ganz abgesehen. Hat man das einmal, möchte man darauf nicht mehr verzichten :-)
Andreas H. schrieb: > Wenn Du aber z.B. bei einem Medizingerät in den USA einen Case hast, > dann musst DU nachweisen, dass Du nach dem aktuellen Stand der Technik > gearbeitet hast. Und das schliesst z.B. auch ein, dass Du Dich > bestmöglichst von der Brauchbarkeit Deiner Werkzeuge überzeugt hast. > Und wie machst Du das ? Z.B. Indem Du Compiler benutzt, die von einer > "fachkundigen Stelle" zertifiziert sind. Das ist eine Möglichkeit, aber nicht die einzige und auch nicht in allen Fällen die beste. In den Normen EN61508 und DO178B sind jedenfalls alternative Wege vorgesehen, gerade weil auch den Gremien bekannt ist, dass man einen Compiler nicht so einfach mal zertifiziert. Mal davon abgesehen, dass es durchaus Toolchains für Cortex M und Cortex R gibt, die für EN61508 oder DO178B vorgesehen sind.
8-Bit schrieb: > In den Normen EN61508 und DO178B sind jedenfalls > alternative Wege vorgesehen, gerade weil auch den Gremien bekannt ist, > dass man einen Compiler nicht so einfach mal zertifiziert. Oh, das ist interessant. Hast Du da zufällig ein Beispiel parat ? Vielleicht wäre sowas bei uns ja auch anwendbar. Grüße Andreas P.S.: Du meinst aber DO178C, oder (die B ist outdated afaik) ? A.
Ich kann dir mal meine Erfahrungen mit der EN61508 (bis SIL3) mitteilen. Bei anderen Normen sieht es wohl ähnlich aus. Zumindest hat das eine kurze Recherche ergeben. Wie gesagt, es gibt keine harte Forderung: "Du darfst nur einen zertifizierten Compiler nutzen." Solche harten Forderungen gibt es im Übrigen nur ganz selten; es gibt eigentlich immer einen gewissen Interpretationsspielraum. Und die Verwendung eines zertifizierten Compiler macht den Zertifizierungsprozess auch nicht wesentlich einfacher. Da spielen einfach zu viele andere Faktoren eine Rolle. Zunächst einmal wird das Gesamtprodukt und der Entwicklungsprozess bewertet. Dabei ist der Einsatz der Tools nur eine kleine Facette. Viel wichtiger sind die Nachvollziehbarkeit der angewendeten Entwicklungsprozesse, eine saubere Dokumentation und vernünftig gewählte Testverfahren. Die Einhaltung von Coderichtlinien (Stichwort MISRA-C) sind auch wichtig. Da gibt es dann noch die Bewährtheit. Es ist sehr vorteilhaft, wenn man mit einem Tool seit Jahren arbeitet. Man verwendet besser etwas bewährtes als auf einen unbekanntes Tool umzusteigen, nur weil es zertifiziert ist. Tests habe ich schon erwähnt - man kann davon ausgehen, dass bei einer ausreichenden Testabdeckung einen Großteil der durch Compilerfehler entstehenden Probleme aufdecken kann. Außerdem ist auch den Zertifizierungsgesellschaften klar, dass auch ein zertifiziertes Tool niemals komplett fehlerfrei sein kann. Und es gibt selbstverständlich auch systemaische Fehler, die nicht auf das Tool zurückzuführen sind. Außerdem gibt es ja auch zufällige Fehler (Soft-Error sagt dir sicherlich etwas). Deshalb muss man von Anfang an ein fehlertolerantes System entwickeln. Und man geht davon aus, dass ein solches System auch gegenüber Compilerfehler in einem ausreichenden Maße geschützt ist.
Jörg Wunsch schrieb: > Beispielsweise Leute, die Betrieb bei 5 V brauchen (soll wohl in > der Fahrzeugtechnik noch sehr verbreitet sein). Es gibt meines > Wissens bislang keinen einzigen ARM, der das kann. FM3 von Fujitsu beispielsweise. Wir warten gerade auf das Starterkit, allerdings weniger wegen den 5V sondern wegen den zwei Ethernet-Schnittstellen. Edit: Ok, wurden schon genannt...
hallo, damit dieser thread nich noch weiter von eigentlichen Thema abdriftet ein paar themenspezifische infos: es gibt eine neue revision des datenblatts: -) neues kapitel SAM D20 Schematic Checklist (beinhaltet auch die anschaltung der oszillatoren -) div fehlerbehebungen/ergänzungen allerdings fehlen immer noch die ac/dc characteristics. gruss gerhard
Andreas H. schrieb: > 8-Bit schrieb: >> In den Normen EN61508 und DO178B sind jedenfalls >> alternative Wege vorgesehen, gerade weil auch den Gremien bekannt ist, >> dass man einen Compiler nicht so einfach mal zertifiziert. > > Oh, das ist interessant. Hast Du da zufällig ein Beispiel parat ? > Vielleicht wäre sowas bei uns ja auch anwendbar. > > Grüße > Andreas > > P.S.: Du meinst aber DO178C, oder (die B ist outdated afaik) ? > A. Kurz dazu: - Im Zusammenhang mit der DO-178B existiert der Begriff Tool-Zertifizierung nicht. Man spricht dort von Tool-Qualification. - Ex existieren keine Compiler, die im Sinne der DO-178B/Development-Tool- qualifizierbar wären. Es ist nicht möglich, ein komplexes Tool wie einen Compiler zu qualifizieren. Die Korrektheit des Compiler muss per Verifikation der erzeugten Artefakte nachgewiesen werden. - Es gibt bereits eine DO-178C. Damit wird aber nicht automatisch die DO-178B ungültig/veraltet. Welche Version anzuwenden ist, bestimmt jeweils der übergeordnete System-Entwicklungsprozess (vereinfacht gesagt). - Das Thema Tool-Qualification wurde in der DO-178C ausgelagert und in der DO-330 beschrieben
8-Bit schrieb: > Die Einhaltung von Coderichtlinien (Stichwort MISRA-C) > sind auch wichtig. Das ist Lustig. Mir erzählen unsere SW-Verantwotlichen, dass sie ihren Compiler nur deswegen haben, weil er wohl nach MISRA-C zertifiziert ist. Deiner (absolut plausiblen) Darstellung nach, wäre das aber gar nicht nötig, da MISRA-C eher den gesamten SW Entwicklungsprozess "vorschreibt". Sehe ich das richtig ? Grüße Andreas
EFA schrieb: > Ex existieren keine Compiler, die im Sinne der > DO-178B/Development-Tool- qualifizierbar wären. Es ist nicht möglich, > ein komplexes Tool wie einen Compiler zu qualifizieren. Sehe ich eigentlich genau so. Von unseren SW-Devs wurde mir das dann aber anders erklärt. Da werde ich mal nachhaken. Danke für die Infos :-) Grüße Andreas
MISRA-C ist lediglich ein Codestandard. Ein Codestandard ist nur ein ganz kleiner Teil, der beispielsweise für DO178B (und bei anderen Normen, usw..) relevant ist. Eine Zertifizierung nach "MISRA-C" gibt es nicht. Alleine die Aussage, ein Compiler sei nach MISRA-C zertifiziert, ergibt keinen Sinn. Ein Compiler kann den Entwickler maximal bei der Einhaltung des MISRA-C unterstützen. Für den Gesamtentwicklungsprozess ist damit nur ein kleiner (und der einfachste) Teil abgedeckt.
Andreas H. schrieb: > EFA schrieb: >> Ex existieren keine Compiler, die im Sinne der >> DO-178B/Development-Tool- qualifizierbar wären. Es ist nicht möglich, >> ein komplexes Tool wie einen Compiler zu qualifizieren. > > Sehe ich eigentlich genau so. Von unseren SW-Devs wurde mir das dann > aber anders erklärt. Da werde ich mal nachhaken. > > Danke für die Infos :-) > > Grüße > Andreas Schick mir mal die Anschrift, dann gibts ein Q-Audit nach EN9100/AQAP2210 :)
EFA schrieb: > - Ex existieren keine Compiler, die im Sinne der > DO-178B/Development-Tool- qualifizierbar wären. Es ist nicht möglich, > ein komplexes Tool wie einen Compiler zu qualifizieren. Die Korrektheit > des Compiler muss per Verifikation der erzeugten Artefakte nachgewiesen > werden. Etwas weiter ist das Gebiet schon. http://compcert.inria.fr/ (formal verifizierte Compiler) und der bislang einzige formal verifizierte Kernel seL4 http://www.ok-labs.com/whitepapers/sample/sel4-formal-verification-of-an-os-kernel
Arc Net schrieb: > EFA schrieb: >> - Ex existieren keine Compiler, die im Sinne der >> DO-178B/Development-Tool- qualifizierbar wären. Es ist nicht möglich, >> ein komplexes Tool wie einen Compiler zu qualifizieren. Die Korrektheit >> des Compiler muss per Verifikation der erzeugten Artefakte nachgewiesen >> werden. > > Etwas weiter ist das Gebiet schon. > http://compcert.inria.fr/ (formal verifizierte Compiler) > und der bislang einzige formal verifizierte Kernel seL4 > http://www.ok-labs.com/whitepapers/sample/sel4-formal-verification-of-an-os-kernel Formale verifikation ist nur eine Möglichkeit der Verifikation. Bei dem zweiten Link handelt es sich um einem Microkernel. Das ist nichts neues, zertifizierte OS/Kernel gibt es reichlich. Welche Verifikationsmethoden zur Anwendung kommen ist der Behörde egal (vereinfacht gesagt). Bei dem Compiler (erster Link) handelt es sich um einen Compiler, bei dem gewisse Verifikationsaktivitäten durch formale Verifikation durchgeführt wurden. Von einer Zertifizierung oder Qualifizierung nach DO-178B ist das noch weit entfernt.
EFA schrieb: > Bei dem > zweiten Link handelt es sich um einem Microkernel. Das ist nichts neues, > zertifizierte OS/Kernel gibt es reichlich. seL4 ist der einzige formal verifizierte Kernel, d.h. div. Eigenschaften sind mathematisch bewiesen, das ist ein gewaltiger Unterschied zu einer wie auch immer gearteten Zertifizierung. Ähnliches gilt für den CompCert.
Arc Net schrieb: > EFA schrieb: >> Bei dem >> zweiten Link handelt es sich um einem Microkernel. Das ist nichts neues, >> zertifizierte OS/Kernel gibt es reichlich. > > seL4 ist der einzige formal verifizierte Kernel, d.h. div. Eigenschaften > sind mathematisch bewiesen, das ist ein gewaltiger Unterschied zu einer > wie auch immer gearteten Zertifizierung. > Ähnliches gilt für den CompCert. Das interessiert eine Certification Authority aber reichlich wenig. Auf den Seiten steht nichtmal, wie die Certification Baseline definiert ist. Das reicht schon als Aussage, dass es sich bei den Themen eher um akademische Projekte ohne praktische Relevanz handelt. Für eine Zertifizierung, beispielsweise in der Luftfahrt, reich es nicht zu sagen "formal verifiziert" oder "mathematisch bewiesen". Dort schreibt die Certification Authority den Standard vor, nach dem zu zertifizieren ist. Die Aussage "foraml zertifiziert" is zulassungstechnisch ohne Kontext erstmal belanglos. Was nicht heissen soll dass es nicht etwas über die Qualität der Software aussagt.
EFA schrieb: > Eine Zertifizierung nach "MISRA-C" gibt es nicht. Alleine die Aussage, > ein Compiler sei nach MISRA-C zertifiziert, ergibt keinen Sinn. Es kann ja durchaus sein das bei der Entwicklung des Compilers selbst mit MISRA-C gearbeitet wurde. Es ist also zumindest theoretisch nicht unmöglich.
8-Bit schrieb: > - 8-Bitter sterben aus. Sie werden vom Cortex M0 verdrängt. Diesen Trend kann ich absolut nicht erkennen. Mal ganz davon abgesehen, daß es in einer riesengroßen Zahl von Anwendungen rein um Bitmanipulationen geht und somit die Verarbeitungsbreite sowieso völlig Wurscht ist. Viele Bits Verarbeitungsbreite blähen im Minimum zuverlässig den Code auf, erfordern deshalb mehr Speicher dafür. Soll der Code dadurch nicht schweinelangsam abgearbeitet werden, sind auch breitere Busse nötig. Das erhöht die Zahl der Pins, die Zahl der Layer, senkt die Ausbeute in der Fertigung auf allen Ebenen. Sprich: Höhere Verarbeitungsbreiten sind nur dort sinnvoll, wo sie neben diesen ganzen Nachteilen auch irgendeinen Vorteil bescheren...
Wenn es denn bei reiner Bitmanipulation bleiben würde, wäre das vielleicht sogar richtig. Meistens spielt aber zumindest mal ein ADC mit oder es ist eine kleine Umrechnung notwendig. Oder man nutzt Timer mit 16 oder 32 Bit. In all diesen Anwendung ist ein 32Bit-CPU schon vorteilhaft. Dass die Codegröße bei 32-Bit ansteigt ist ein Mythos. In den meisten Fällen ist sie sogar geringer. Thumb-Code ist schon sehr effizient. Die neuen 32-Bit-uC werden in einer viel moderneren Technologie gefertigt. Somit sind breitere Busse überhaupt kein Thema. Wieso sollte die Anzahl der Pins oder Layer steigen? Es gibt Cortex M0+ mit 8 Pin, und die kriegt man auch auf einer 1-Lagen-Karte zum laufen. Oder meinst du die Lagen auf dem Silizium? Das wird durch die neuere Prozesstechnologie kostentechnisch mehr als ausgeglichen.
8-Bit schrieb: > Wenn es denn bei reiner Bitmanipulation bleiben würde, wäre das > vielleicht sogar richtig. Meistens spielt aber zumindest mal ein ADC mit > oder es ist eine kleine Umrechnung notwendig. Oder man nutzt Timer mit > 16 oder 32 Bit. In all diesen Anwendung ist ein 32Bit-CPU schon > vorteilhaft. Nicht notwendigerweise. Wenn der 8Bitter eine 32Bit-Addition in vier Schritten erledigen muß, und der 32Bitter das in einer Operation erledigen kann, ist er trotzdem erst dann im Vorteil, wenn dieser eine Schritt bei gleichem Takt schneller erledigt ist als der 8Bitter seine vier. Und das ist längst nicht immer der Fall... > Dass die Codegröße bei 32-Bit ansteigt ist ein Mythos. Nein, das liegt in der Natur der Sache. Wenn man die Möglichkeiten der größeren Verarbeitungsbreite wirklich nutzen will, braucht man mehr Operationen und die Operationen müssen zumindest zum Teil breitere Operatoren verarbeiten können. Beides führt unweigerlich dazu, daß sich die Zahl der Instruktionen pro Byte Codegröße verringern muß. Das ist so logisch, daß man darüber eigentlich überhaupt nicht diskutieren müßte. Im Vergleich zum 8Bitter eingespart werden kann hingegen nur etwas, wenn dessen beschränkte Verarbeitungbreite für eine Aufgabe mehr Instruktionen erfordert als sie bei 32Bit Verarbeitungsbreite nötig sind. Nur ist das eben bei den meisten µC-Anwendungen eher selten der Fall. Für Bitmanipulationen wird's überhaupt nicht gebraucht. Für das Rechnen mit geringen Genauigkeiten und kleinen Zahlen ebenfalls nicht. Für Stringverarbeitung allenfalls bezüglich der Zeigerarithmetik, aber selbst die ist meist nur 16Bit breit, nicht 32. Im Übrigen gibt es 32Bit-µC seit mindestens 20 Jahren. Sie konnten bis heute nicht die 8Bitter obsolet machen. Wahrscheinlich deshalb, weil andere Leute ebenfalls erkannt haben, daß eine höhere Verarbeitungsbreite nur dann einen Vorteil bringt, wenn man sie auch tatsächlich benötigt.
c-hater schrieb: > Im Übrigen gibt es 32Bit-µC seit mindestens 20 Jahren. Ich hab hier nen 64-Bitter Baujahr 1992, zugegeben es ist kein µC sondern eine "normale" MIPS R4k4, aber damals(TM) gab's keinen Unterschied zwischen µC und normaler CPU. Die Peripherie war früher meistens extern und an CPUs wurde verbaut was gerade opportun war. Irgendwo hab ich noch ne VME-Bus Karte mit 'nem MC88k aus einer Maschinensteuerung BJ.'90 rumliegen. Der hatte auch schon 32-Bit.
c-hater schrieb: > Im Vergleich zum 8Bitter eingespart werden kann hingegen nur etwas, wenn > dessen beschränkte Verarbeitungbreite für eine Aufgabe mehr > Instruktionen erfordert als sie bei 32Bit Verarbeitungsbreite nötig > sind. Nur ist das eben bei den meisten µC-Anwendungen eher selten der > Fall. Für Bitmanipulationen wird's überhaupt nicht gebraucht. Für das > Rechnen mit geringen Genauigkeiten und kleinen Zahlen ebenfalls nicht. Ja, für Zahlen von 0 bis 255. Alles darüber hinaus benötigt schon ein wildes Umladen von Registern. Und bei Funktionsaufrufen Stackoperationen muss der ganze Wust vorher auch noch gesichert werden. > Für Stringverarbeitung allenfalls bezüglich der Zeigerarithmetik, aber > selbst die ist meist nur 16Bit breit, nicht 32. Und schon das benötigt ein zweites Register und halbiert die Geschwindigkeit. > Im Übrigen gibt es 32Bit-µC seit mindestens 20 Jahren. Sie konnten bis > heute nicht die 8Bitter obsolet machen. Wahrscheinlich deshalb, weil > andere Leute ebenfalls erkannt haben, daß eine höhere > Verarbeitungsbreite nur dann einen Vorteil bringt, wenn man sie auch > tatsächlich benötigt. Dass die 32-Bitter sich jetzt erst durchsetzen, liegt nur ein einer einzigen Sache: dem Preis. Jetzt erst sind sie preislich auf einer Ebene mit den 8 Bittern. Wenn ich für praktisch dasselbe Geld die Wahl zwischen 32 und 8 Bit habe, denn fällt die Wahl nicht schwer. Es wird Nischen für 8 Bit geben, aber die Masse wird wechseln. Es gibt Schlimmeres :-)
c-hater schrieb: > Nicht notwendigerweise. Wenn der 8Bitter eine 32Bit-Addition in vier > Schritten erledigen muß, und der 32Bitter das in einer Operation > erledigen kann, ist er trotzdem erst dann im Vorteil, wenn dieser eine > Schritt bei gleichem Takt schneller erledigt ist als der 8Bitter seine > vier. > > Und das ist längst nicht immer der Fall... Doch, bei Cortex Mx im Vergleich zu allen 8-Bittern ist das sehr wohl der Fall! c-hater schrieb: > Nein, das liegt in der Natur der Sache. Wenn man die Möglichkeiten der > größeren Verarbeitungsbreite wirklich nutzen will, braucht man mehr > Operationen und die Operationen müssen zumindest zum Teil breitere > Operatoren verarbeiten können. ARM Cortex arbeitet mit Thumb-Code, also 16-Bit Befehlsbreite. Viele 8-Bit-Kerne arbeiten ebenfalls mit 16-Bit-Befehlsbreite, haben also absolut keinen Vorteil. c-hater schrieb: > Im Vergleich zum 8Bitter eingespart werden kann hingegen nur etwas, wenn > dessen beschränkte Verarbeitungbreite für eine Aufgabe mehr > Instruktionen erfordert als sie bei 32Bit Verarbeitungsbreite nötig > sind. Und das ist fast immer der Fall. Sobald du einen ADC hast (mindestens 10 Bit Auflösung sind absolut üblich), arbeitest du mit 16-Bit-Werten. Mit 8-Bit-Timern arbeitet auch kein Mensch mehr, selbst bei einfachen PWM möchte man schon mindestens 10-12-Bit Auflösung haben. Die Anwendungen, in denen du ausschließlich mit 8 Bit auskommst, kannst du an einer Hand abzählen. c-hater schrieb: > Für das > Rechnen mit geringen Genauigkeiten und kleinen Zahlen ebenfalls nicht. Mir ist ehrlich gesagt noch keine einzige Anwendung untergekommen, bei der ich mit 8-Bit-Zahlen ausgekommen bin. Und selbst wenn: Eine einzige simple Multiplikation, und dein 8-Bit-Kern verliert meilenweit gegen einen modernen Cortex M-Kern. c-hater schrieb: > Für Stringverarbeitung allenfalls bezüglich der Zeigerarithmetik, aber > selbst die ist meist nur 16Bit breit, nicht 32. Das ist ein gutes Beispiel, bei dem ein 8-Bitter schon überfordert ist. Selbst ein 16-Bit-Adressraum ist schon problematisch, aber wer gibt sich heute schon mit einem Adressraum von 64 KBbyte zufrieden? Bei einem 8-Bit-uC muss man sich schon viele umständliche Tricks einfallen lassen, um überhaupt einen größeren Adressraum zu ermöglichen. Und dabei geht es noch nicht mal um Stringoperationen; jeder Sprungbefehl wird zum "Pain in the ass". c-hater schrieb: > Im Übrigen gibt es 32Bit-µC seit mindestens 20 Jahren. Sie konnten bis > heute nicht die 8Bitter obsolet machen. Wahrscheinlich deshalb, weil > andere Leute ebenfalls erkannt haben, daß eine höhere > Verarbeitungsbreite nur dann einen Vorteil bringt, wenn man sie auch > tatsächlich benötigt. Nein, weil bisher einfach der Kern auf dem Silizium eine große Rolle gespielt hat und die 32-Bit-Prozessoren einfach noch zu teuer waren. Inzwischen ist aber die Prozesstechnologie fortgeschritten. Die Strukturbreiten sind so klein geworden, dass der Kern auf dem Silizium keinen wesentlichen Platz mehr ein nimmt. Entscheidend ist eigentlich nur noch die Peripherie (die IO-Ports kann man nicht kleiner machen, solange die IO-Spannung so hoch beibt, Analog-Peripherie kann man auch nicht beliebig verkleinern) und der Speicher. Letzterer wird aber durch die 32-Bit-uC für die meisten Anwendungen sogar besser genutzt. Außerdem gab es noch nicht so hoch optimierte Kerne wie der M0.
8-Bit schrieb: > ARM Cortex arbeitet mit Thumb-Code, also 16-Bit Befehlsbreite. Viele > 8-Bit-Kerne arbeiten ebenfalls mit 16-Bit-Befehlsbreite, haben also > absolut keinen Vorteil. Thumb ist ein 16-/32-Bit Mischmasch. BL, DMB, DSB, ISB, MRS, MSR sind z.B. 32 Bit instructions
Machmal ist die Geschwindigkeit und Effizienz nicht entscheidend, sondern wer ist insgesamt am guenstigsten....
8-Bit schrieb: > Mit > 8-Bit-Timern arbeitet auch kein Mensch mehr, 8-Bit schrieb: > Mir ist ehrlich gesagt noch keine einzige Anwendung untergekommen, bei > der ich mit 8-Bit-Zahlen ausgekommen bin. 8-Bit schrieb: > Selbst ein 16-Bit-Adressraum ist schon problematisch, aber wer gibt sich > heute schon mit einem Adressraum von 64 KBbyte zufrieden? Geht's noch oder willst Du wieder nur provozieren?
Bezüglich der Geschwindigkeit kann ich einen Datenpunkt beisteuern. Ein interessanter Herausforderer der 8Bit MCUs am unteren Ende ist m.E. die LPC81X Serie. Über Anwendungen mit >64kb Programmcode muss man nicht diskutieren, hier sind 8Bit MCUs generell nur bedingt geeignet. Der kleinste Vertreter ist hier der LPC810 im 8Pin DIP Gehäuse. Vergleichbar sind ATtiny85 und PIC12F1822. Rein nach Anzahl der ausführbaren Befehle pro Sekunde ergibt sich bei Nutzung des Internen RC-Oszillators folgendes Bild:
1 | CPU Clock-Configuration MIPS |
2 | LPC810 30 Mhz, 0 WS ~30 |
3 | Attiny85 16 MHz (PLL) ~16 |
4 | PIC12F1822 32 MHz ~8 |
Alle drei lassen Portzugriffe in einem Befehlstakt zu, so dass die Geschwindkeit von Logikanwendungen direkt proportional zu den MIPS skaliert. Bei Rechenintensiven Anwendungen profitiert man zusätzlich von den mächtigeren 32 Bit befehlen, was das Feld noch weiter auseinander treibt.
c-hater schrieb: > Nein, das liegt in der Natur der Sache. Wenn man die Möglichkeiten der > größeren Verarbeitungsbreite wirklich nutzen will, braucht man mehr > Operationen und die Operationen müssen zumindest zum Teil breitere > Operatoren verarbeiten können. Beides führt unweigerlich dazu, daß sich > die Zahl der Instruktionen pro Byte Codegröße verringern muß. Das ist so > logisch, daß man darüber eigentlich überhaupt nicht diskutieren müßte. Wäre schön, wenn Du diese Behauptungen auch mit Beispielen begründen könntest. Die thumb ISA unterstützt bei vielen Befehlen Konstanten, so dass bei reinem 8 Bit Code häufig die Codedichte identisch ist. Dass die Befehlslänge von AVR und Thumb identisch ist, wurde im Thread ja schon häufiger erwähnt.
M. N. schrieb: > Geht's noch oder willst Du wieder nur provozieren? Du darfst gerne Gegenbeispiele nennen.
Davis schrieb im Beitrag #3231502: > Mach dich nicht noch lächerlicher, als du ohnehin schon bist. Zu deinem > hohlen Geschwafel - ohne Inhalt - auch noch Gegenbeispiele zu fordern - > ist dreist & dämlich. Untermaure erst einmal deine Behauptungen mit > Beispielen, dann sehen wir weiter. Was hast du denn schon beigetragen, außer dumme Kommentare? Beispiele, gerne: LED dimmen: mit 8 Bit nicht sinnvoll, zumindest nicht für Beleuchtungsanwendungen. Motorsteuerungen: Mit 8-Bit-PWM undenkbar. Auch bei einer einfachen Frequenzmessung ist man mit 8 Bit entweder in der Auflösung oder in der minimal messbaren Frequenz sehr beschränkt. Einfache Systemtimer kann man mit 8-Bit-Timer natürlich realisieren. Wenn man aber beispielsweise auf einem mit 16 MHz getakteten Timer einen 100ms-Tick realisieren will, braucht man einen Prescaler von 1/1.6*10^6 Welche Timerperipherie bietet so etwas? Zu Berechnungen habe ich ja schon ADC genannt. Jede Anwendung, die mit ADC-Daten rechnet, braucht mehr als 8 Bit. Ansonsten kann ich mir beim besten Willen keine Berechnung vorstellen, die mit einer 8-Bit-Zahl bequem durchzuführen ist. Zum Thema Adressraum: 8 Bit Adressraum - nur 255 adressierbare Adressen sind ja wohl absoluter Blödsinn, darüber brauchen wir wohl nicht diskutieren. Und selbst 16 Bit werden heutzutage schnell knapp. Da gehen schon eine Menge für die Peripherieregister drauf. Mehr als 32kByte Flash geht nicht. Natürlich reicht das für viele einfache Anwendungen aus, aber dann ist die Architektur absolut nicht skalierbar. Und das ist heutzutage eben wichtig. Vor allem wenn man diese Skalierbarkeit geschenkt bekommt, wie es beim M0 eben der Fall ist.
@8-Bit Nur weil der Kern 8-Bit ist, heisst es nicht, dass da nur 8-Bit Peripherals verbaut; siehe AVR.
8-Bit schrieb: > ARM Cortex arbeitet mit Thumb-Code, also 16-Bit Befehlsbreite. Viele > 8-Bit-Kerne arbeiten ebenfalls mit 16-Bit-Befehlsbreite, haben also > absolut keinen Vorteil. Ein deutlicher Unterschied kann in der Darstellung von Speicheradressen im Code liegen. Ein Thumb-Prozessor benötigt 6 Bytes nur um eine Adresse ins Register zu bekommen und 2 weitere Bytes um sie zu verwenden. 8-Bitter benötigen für solche load/store oder kombinierte Operationen meist nur 3-4 Bytes insgesamt, für eingeschränkten Adressraum oft nur 2 Bytes. Inwieweit sich dieser Unterschied auswirkt hängt sowohl von der Optimierung des Compiler ab, als auch vom Programmierstil. Bei Programmierung auf 8-Bittern ist es ziemlich verbreitet, in hohem Masse skalare globale Variablen zu verwenden, ohne sie irgendwie zusammen zu fassen. Solche Variablen werden von 32-Bitter unabhängig voneinander betrachtet und sorgen dann für ziemlich viele solche teuren Adressoperationen. 32-Bitter wiederum bevorzugen Speicheradressierung relativ zu einem Register. Eine Methode, die umgekehrt manchen 8-Bittern Klimmzüge abverlangt (8051, PIC). Diese Adressierungsmethode kommt Programmiertechniken entgegen, in denen zusammengehörige Variablen beispielsweise in C++-Klassen (oder structs) zusammengefasst sind. Je grösser die Programme werden und weiter weg sich der grösste Teil des Codes von Bit- und Bytepriemelei hin zu sauber in Abstraktionsebenen strukturierter Programmierweise entwickelt, desto besser schneiden die 32-Bitter ab. > Außerdem gab es noch nicht so hoch optimierte Kerne wie der M0. Optimiert waren sie schon. Aber nicht mit minimalem Chipaufwand als Designziel, sondern hoher Performance. Einzige Ausnahme: ARM. Die ersten ARMs sollten nicht wie beispielsweise MIPS die Performance bei damals mögliche Chiptechnik maximieren, sondern bei signifikant begrenztem Aufwand (grob vgl. 8086) nur eine adäquate Performance liefern. Ebendies prädestinierte ARMs schon früh für anspruchsvolle embedded Systems, obwohl das nicht das ursprüngliche Designziel war. Negativ an den klassischen ARMs war der noch eher hohe Code-Aufwand. Die Konurrenz (z.B. Hitachi) bot irgendwann 32-Bit Alternativen mit deutlich kompakterer Codierung. Worauf ARM mit dem langsameren aber wesentlich kompakter codierten Thumb-Befehlssatz reagierte.
8-Bit schrieb: > LED dimmen: mit 8 Bit nicht sinnvoll, zumindest nicht für > Beleuchtungsanwendungen. Arbeitest Du bei Infineon? :) Viele gängige LED-Controller arbeiten mit 8 Bit (z.B. WS2801X). Gut ist das allerdings nicht, das muss ich zugeben.
Coder schrieb: > @8-Bit > > Nur weil der Kern 8-Bit ist, heisst es nicht, dass da nur 8-Bit > Peripherals verbaut; siehe AVR. Natürlich, aber sobald du was mit den Ergebnissen anfangen willst, musst du auch mit entsprechenden Bitbreiten rechnen. Und dann ist der 8-Bit-Kern nur noch eine Krücke.
A. K. schrieb: > Ein deutlicher Unterschied kann in der Darstellung von Speicheradressen > im Code liegen. Ein Thumb-Prozessor benötigt 6 Bytes nur um eine Adresse > ins Register zu bekommen und 2 weitere Bytes um sie zu verwenden. > 8-Bitter benötigen für solche load/store oder kombinierte Operationen > meist nur 3-4 Bytes insgesamt, für eingeschränkten Adressraum oft nur 2 > Bytes. ... > Inwieweit sich dieser Unterschied auswirkt hängt sowohl von der > Optimierung des Compiler ab, als auch vom Programmierstil. Eben. In den meisten Fällen ist der zusätzliche Speicherbedarf marginal. Der Nachteil wird schnell ausgeglichen, wenn der 8 Bitter doch einmal mit 16 Bit arbeiten muss. Übrigens entsteht der Vorteil der 8 Bitter nur, weil die meisten Architekturen 16 Bit Arithmetik unterstützen, um z.B. Postinkrement und Indizierte Addressierung zu ermöglichen. Sauber, "Orthogonal", ist das nicht...
8-Bit schrieb: > Zum Thema Adressraum: 8 Bit Adressraum - nur 255 adressierbare Adressen > sind ja wohl absoluter Blödsinn, darüber brauchen wir wohl nicht > diskutieren. Ich beziehe das mal auf den Datenadressraum, da der Codeadressraum mit der Breite der Datenverarbeitung in keiner Beziehung steht. Als die 8051er frisch waren war das für den vorgesehen Einsatzzweck völlig ausreichend. Verglichen mit den Adressierungskrücken in den Vorgängern 8048 und F8 war das direkt angenehm. > Mehr als 32kByte Flash geht nicht. Wenn man sich für getrennte Adressräume entscheidet, dann ist auch eine 8-Bit Architektur vorstellbar, die 4GB Code adressieren kann. AVRs schaffen im Rahmen des Befehssatzes der normalen Megas immerhin schon einige MB. Die Crux ist eher, dass eine Adressraumtrennung die Programmierung deutlich komplizierter gestaltet. Weil man bei jedem Pointer berücksichtigen muss, in welchen Adressraum er zeigen soll. Oder gar Klimmzüge wie managed pointer verwenden muss, bei denen Laufzeitcode sie differenziert. Bei sehr kleinen Programmen, evtl sogar in Assembler, spielt das kaum eine Rolle. Aber bei grösseren Programmen sind getrennte Adressräume recht unangenehm. Renesas 16-Bitter M16C(&Co) variieren das, indem sie einen gut adressierbaren 64K Datenadressraum in einen für Daten weit schlechter adressierbaren 1MB Gesamtadressraum einbetten. Das erspart managed pointer, aber nicht den erhöhten Aufwand für den Programmierer.
Wenn jemand die Geschwindigkeit nicht benötigt, ist die Bit-Breite eigentlich egal. Wichtig ist, dass der Controller das kann, was er soll. Das heißt insbesondere, er hat die Peripherie, die ich benötige. Die Argumente klingen ein wenig wie die Angst-Optimierungen bei der C-Programmierung. Es könnte zu langsam sein...
A. K. schrieb: > Ich beziehe das mal auf den Datenadressraum, da der Codeadressraum mit > der Breite der Datenverarbeitung in keiner Beziehung steht. Ach nein? Schonmal einen Sprungbefehl ausgeführt? Ja, ich weiß, es gibt auch relative Sprünge, aber das ist ja auch nur eine Krücke. A. K. schrieb: > Als die 8051er frisch waren war das für den vorgesehen Einsatzzweck > völlig ausreichend. Verglichen mit den Adressierungskrücken in den > Vorgängern 8048 und F8 war das direkt angenehm. Seit der Einführung des 8051 sind schon ein paar Jährchen vergangen, die Anforderungen und Einsatzwecke haben sich ein ganz wenig weiterentwickelt. Ewig Gestrige gibt es natürlich immer. A. K. schrieb: > Wenn man sich für getrennte Adressräume entscheidet, dann ist auch eine > 8-Bit Architektur vorstellbar, die 4GB Code adressieren kann. AVRs > schaffen im Rahmen des Befehssatzes der normalen Megas immerhin schon > einige MB. Denkbar ist vieles. Aber inwiefern hat man dann noch einen Vorteil in Bezug auf Ausführungsgeschwindigkeit und Codegröße? A. K. schrieb: > Die Crux ist eher, dass eine Adressraumtrennung die Programmierung > deutlich komplizierter gestaltet. Weil man bei jedem Pointer > berücksichtigen muss, in welchen Adressraum er zeigen soll. Genau darum geht es mir doch.
Coder schrieb: > Wenn jemand die Geschwindigkeit nicht benötigt, ist die Bit-Breite > eigentlich egal. Wichtig ist, dass der Controller das kann, was er soll. > Das heißt insbesondere, er hat die Peripherie, die ich benötige. Und er muss ein Kostenziel erreichen. In dieser Hinsicht sind Cortex M0 ganz vorne dabei.
Tim . schrieb: > Sauber, "Orthogonal", ist das nicht... Allerdings sind das Kriterien, die einen C-Compiler nicht wirklich interessieren. Der hat nur gewisse Minimalansprüche für effiziente Umsetzung von Code. Wie es beispielsweise die erwähnte Adressierung relativ zu einem Register darstellt, ohne die sich ein Daten-Stack schlecht implementieren lässt. Auch vorzeichenbehaftete Vergleiche sind ganz nützlich (fehlen in PIC, 8051). Fehlende Orthogonalität stört eher den Assembler-Programmierer, der jedesmal überlegen muss, ob ADD nun anders adressieren kann als EOR. Den Compiler-Autor interessiert das nur ein einziges Mal.
@8-Bit Bedauerlicherweise ist die Welt nicht so einfach. Schau nicht nur auf den Silizium-Preis: I.d.R. reden wir von wenigen Cent!?! Eine bestehende Infrastruktur portiert man nicht mal so eben. Und das kann richtig ins Geld gehen, insbesondere bei Software nach EN61508. Nicht jeder arbeitet in einer Firma, die Millionen von MCU verbaut.
Coder schrieb: > Bedauerlicherweise ist die Welt nicht so einfach. Schau nicht nur auf > den Silizium-Preis: I.d.R. reden wir von wenigen Cent!?! Eine bestehende > Infrastruktur portiert man nicht mal so eben. Und das kann richtig ins > Geld gehen, insbesondere bei Software nach EN61508. Deshalb wird es auch noch lange 8-Bit-uC geben. Das habe ich aber weiter oben schon geschrieben. Ich rede ganz explizit von einem Trend bei Neuentwicklungen.
8-Bit schrieb: > Ach nein? Schonmal einen Sprungbefehl ausgeführt? Ja, ich weiß, es gibt > auch relative Sprünge, aber das ist ja auch nur eine Krücke. Die in Befehlen codierte Adressbreite für Code ist von der Adressbreite eines getrennten Datenadressraums völlig unabhängig. Wie schon gesagt, die ganz normalen AVRs können von der Codierung her 8MB Code adressieren. Einzig bei indirekten Sprüngen spielt das eine Rolle. > Denkbar ist vieles. Aber inwiefern hat man dann noch einen Vorteil in > Bezug auf Ausführungsgeschwindigkeit und Codegröße? Keine. Im Gegenteil. Der einzige Vorteil dieser Skalierbarkeit besteht darin, im gleichen Entwicklungssystem mit der bestehenden Erfahrung bleiben zu können. Und das gilt in beiden Richtungen. 8-Bitter mit 512KB Code sind oft ebenso ausserhalb ihren optimalen Einsatzspektrums wie 32-Bitter mit 4KB Flash und 8 Pins. Die existieren deshalb, damit man ein grosses Spektrum abdecken kann, ohne Werkzeuge und Erfahrung auswechseln zu müssen.
A. K. schrieb: > Und das gilt in beiden Richtungen. 8-Bitter mit 512KB Code sind oft > ebenso ausserhalb ihren optimalen Einsatzspektrums wie 32-Bitter mit 4KB > Flash und 8 Pins. Die existieren deshalb, damit man ein grosses Spektrum > abdecken kann, ohne Werkzeuge und Erfahrung auswechseln zu müssen. Ey - also ich finde den LPC810 toll. Nur Schade, dass die von NXP mitgegebene CMSIS Implementierung erst einmal den halben Flash-Speicher vollmüllt.
A. K. schrieb: > Die in Befehlen codierte Adressbreite für Code ist von der Adressbreite > eines getrennten Datenadressraums völlig unabhängig. Wie schon gesagt, > die ganz normalen AVRs können von der Codierung her 8MB Code > adressieren. Was sich aber immer noch auf die Codedichte auswirkt. A. K. schrieb: > Und das gilt in beiden Richtungen. 8-Bitter mit 512KB Code sind oft > ebenso ausserhalb ihren optimalen Einsatzspektrums wie 32-Bitter mit 4KB > Flash und 8 Pins. Die existieren deshalb, damit man ein grosses Spektrum > abdecken kann, ohne Werkzeuge und Erfahrung auswechseln zu müssen. Mit dem Cortex M0 wurde das sinnvolle Einsatzspektrum so verschoben, dass sich eben letztere auch kostentechnisch besser als vergleichbare 8-Bitter darstellen und deshalb für Neuentwicklungen quasi keine Nachteile mehr bieten.
8-Bit schrieb: > Mit dem Cortex M0 wurde das sinnvolle Einsatzspektrum so verschoben, > dass sich eben letztere auch kostentechnisch besser als vergleichbare > 8-Bitter darstellen und deshalb für Neuentwicklungen quasi keine > Nachteile mehr bieten. Rein technisch gesehen ist das richtig. Wenn allerdings diese Neuentwicklung eines Produktes von jemandem durchgeführt werden muss, der seine 8-Bitter in- und auswendig kennt, aber ausser seinem eigenen noch nie einen Cortex dressiert hat, dann wird die Entscheidung u.U. nicht auf technischer Grundlage getroffen, sondern unter Berücksichtigung der zu investierenden Zeit. Klar, irgendwann ist es Zeit, mal neue Wege zu gehen. Als strategische Entscheidung. Nur ist eben die effiziente Abdeckung der 32-Bitter nach ganz unten noch ziemlich frisch.
8-Bit schrieb: > Coder schrieb: >> Bedauerlicherweise ist die Welt nicht so einfach. Schau nicht nur auf >> den Silizium-Preis: I.d.R. reden wir von wenigen Cent!?! Eine bestehende >> Infrastruktur portiert man nicht mal so eben. Und das kann richtig ins >> Geld gehen, insbesondere bei Software nach EN61508. > > Deshalb wird es auch noch lange 8-Bit-uC geben. Das habe ich aber weiter > oben schon geschrieben. Ich rede ganz explizit von einem Trend bei > Neuentwicklungen. ? meine Erfahrung im Berufsleben sagt. Werde schnell und kostengünstig fertig. Das gilt auch bei Neuentwicklung. "Alt" bewährtes und vorraussichtlich viele tausende Zeilen "fehlerfreierer" :-) Code sind unschlagbar günstig. Man probiert im kleinem Rahmen natürlich immer mal etwas neues aus. By the way wechselt man von NXP Cortex M0+ zu einem Kinetis M0+ ist es ein fast neuer Controller; der Kern identisch, die Peripherie anders....
A. K. schrieb: > Nur ist eben die effiziente Abdeckung der 32-Bitter nach > ganz unten noch ziemlich frisch. PS: Erste Ansätze in Form der SO-20 (SO-24?) CM3 Controller von Luminary Micro waren nicht wirklich der Stein der Weisen. Deren Vorteil lag wirklich nur in der Rechenbreite, ansonsten waren die in so ziemlich jeder Hinsicht schlechter als beispielsweise ein Mega8.
Coder schrieb: > Man probiert im kleinem Rahmen natürlich immer mal etwas neues aus. By > the way wechselt man von NXP Cortex M0+ zu einem Kinetis M0+ ist es ein > fast neuer Controller; der Kern identisch, die Peripherie anders.... Aber das Entwicklungssystem bleibt.
8-Bit schrieb: > Was sich aber immer noch auf die Codedichte auswirkt. Bei AVRs liegt die Grenze bei 8KB Code. Alles darüber unterscheidet sich in der Codedichte nicht, aufgrund der Entscheidung für eine Befehlscodierung in 16 Bits. Auch die PIC18 codieren 20 Bits Zieladresse, ausreichend für 2MB Code.
A. K. schrieb: > Coder schrieb: >> Man probiert im kleinem Rahmen natürlich immer mal etwas neues aus. By >> the way wechselt man von NXP Cortex M0+ zu einem Kinetis M0+ ist es ein >> fast neuer Controller; der Kern identisch, die Peripherie anders.... > > Aber das Entwicklungssystem bleibt. Ja richtig. Sag das mal deinem Firmware-Entwickler: Du darfst alle Treiber neu schreiben, alle Tests neumachen machen usw. aber das Entwicklungssystem bleibt ;-)
A. K. schrieb: > Coder schrieb: >> Man probiert im kleinem Rahmen natürlich immer mal etwas neues aus. By >> the way wechselt man von NXP Cortex M0+ zu einem Kinetis M0+ ist es ein >> fast neuer Controller; der Kern identisch, die Peripherie anders.... > > Aber das Entwicklungssystem bleibt. Eigentlich ist es doch egal, ob GCC AVR- oder ARM-Code erzeugt? Ein Problem ist aber, dass sich nicht nur die Peripherie von Controller zu Controller deutlich ändert, sondern man bei den Cortex-Controllern zusätzlich auch noch auf deutlich mehr Peripherie angewiesen ist. Durch die hohen Core-Clockraten werden Zusatzmaßnehmen wir Wait-States und Caches notwendig. Diese mach die Ausführungszeiten häufig undeterministisch. Begegnet wird diesem Probleme mit neuen, sehr komplexen, Timern und Features wie DMA. Bei den kleineren Cortex-Controllern ist es fast schon Glückssache, ob die Peripherie zur Anwendung passt.
Tim . schrieb: > Eigentlich ist es doch egal, ob GCC AVR- oder ARM-Code erzeugt? Nein. Allein schon weil du dich beim AVR mit den erwähnten Fisematentechen rund um die Adressräume rumärgern darfst. Ausserdem ist der ganze Komplex des Debuggings nicht von der Hardware zu trennen. Zudem beziehe ich mich nicht unmittelbar auf GCC. Schon mal einen GCC für 8-Bit PICs gesehen? ;-) > Bei den kleineren > Cortex-Controllern ist es fast schon Glückssache, ob die Peripherie zur > Anwendung passt. Das gilt für alle solchen Auswahlentscheidungen. Egal welcher Core drin steckt. Wer bestimmte Periphierieeigenschaften benötigt, der kann beim Wechsel zu egal welchem Chip eines anderen Herstellers Probleme kriegen.
A. K. schrieb: > Und das gilt in beiden Richtungen. 8-Bitter mit 512KB Code sind oft > ebenso ausserhalb ihren optimalen Einsatzspektrums wie 32-Bitter mit 4KB > Flash und 8 Pins. Meine volle Zustimmung dazu! 8-Bit schrieb: > Du darfst gerne Gegenbeispiele nennen. 8-Bit PWM reicht mir zur Helligkeitssteuerung von 7-Segm.-Anzeigen, für die Hintergrundbeleuchtung von TFTs und auch für die Steuerung von DC-Motoren. 10-Bit ADC-Werte kann man bequem und schnell genug mit 2 x 8-Bit verarbeiten. Die Bremse dabei ist meist der ADC selbst. Vielfach lasse ich auch linksbündig wandeln und nehme nur das obere Byte. Zum Einlesen von Potis reicht das in der Regel aus. Wenn dann 'hochpräzise' 24-Bit ADCs verwendet werden, sind diese so lahm, dass auch hier die 8-bittige Weiterverarbeitung nicht als Bremse wirkt. Mehr darf ich nicht sagen. NDA - Du weißt :-) @8-Bit An Deiner Stelle würde ich z.B. vielmehr auf die möglichen Interruptprioritäten der Cortex-Mx verweisen. Hier ist ein 8-Bit AVR klar unterlegen, was aber nicht an seiner internen Busbreite liegt.
A. K. schrieb: > Rein technisch gesehen ist das richtig. Wenn allerdings diese > Neuentwicklung eines Produktes von jemandem durchgeführt werden muss, > der seine 8-Bitter in- und auswendig kennt, aber ausser seinem eigenen > noch nie einen Cortex dressiert hat, dann wird die Entscheidung u.U. > nicht auf technischer Grundlage getroffen, sondern unter > Berücksichtigung der zu investierenden Zeit. Niemand behauptet, dass dieser Trend von heute auf morgen umgesetzt wird. Das ist natürlich ein jahrzehntelanger Prozess. Der neue Cortex M0 von Atmel ist ja erst einer der ersten Hinweise auf diese Entwicklung. Außerdem: Häufig ist alter Code eben nicht so fehlerfrei und arbeitsarm, wie du es gerade beschreibst, sondern eine schlecht wartbare Altlast. Häufig noch in Assembler geschrieben, weil man ja aufgrund der ineffizienten Architektur jedes Byte und jeden Prozessorzyklus ausquetschen musste. Da spart es enorm viel Zeit, wenn man auf eine moderne, hoch skalierbare Architektur umsteigen kann. A. K. schrieb: > Bei AVRs liegt die Grenze bei 8KB Code. Alles darüber unterscheidet sich > in der Codedichte nicht, aufgrund der Entscheidung für eine > Befehlscodierung in 16 Bits. Auch die PIC18 codieren 20 Bits > Zieladresse, ausreichend für 2MB Code. Ja, alles schön und gut. Ich erinnere dich mal an den Anstoß der Diskussion: Dort wurde behauptet, dass 8-Bitter viel effizienter sind und viel kleineren Code produzieren. Im Moment lieferst du nur Argumente dafür, mit welchen Krücken 8-Bit-Architekturen leben müssen, um noch halbwegs effizienten Code ausspucken zu können. M. N. schrieb: > 10-Bit ADC-Werte kann man bequem und schnell genug mit 2 x 8-Bit > verarbeiten. Die Bremse dabei ist meist der ADC selbst. > Vielfach lasse ich auch linksbündig wandeln und nehme nur das obere > Byte. Zum Einlesen von Potis reicht das in der Regel aus. > Wenn dann 'hochpräzise' 24-Bit ADCs verwendet werden, sind diese so > lahm, dass auch hier die 8-bittige Weiterverarbeitung nicht als Bremse > wirkt. Und welchen enormen Vorteil hat man da noch bei einem 8-Bitter,w enn man ständig mit solchen Krücken herumwerkeln muss?
8-Bit schrieb: > Außerdem: Häufig ist alter Code eben nicht so fehlerfrei und arbeitsarm, > wie du es gerade beschreibst, sondern eine schlecht wartbare Altlast. Entschuldigung, das war nicht auf dich, sondern auf folgenden Beitrag bezogen: Coder schrieb: > ? meine Erfahrung im Berufsleben sagt. Werde schnell und kostengünstig > fertig. Das gilt auch bei Neuentwicklung. "Alt" bewährtes und > vorraussichtlich viele tausende Zeilen "fehlerfreierer" :-) Code sind > unschlagbar günstig.
M. N. schrieb: > 8-Bit PWM reicht mir zur Helligkeitssteuerung von 7-Segm.-Anzeigen, für > die Hintergrundbeleuchtung von TFTs und auch für die Steuerung von > DC-Motoren. Hintergrundbeleuchtung: Ja gut, wenn man keine Kennlinie braucht. Ansonsten sieht man schon ganz alt aus. Und DC-Motoren sind ja fast schon genauso out wie 8-Bit-Prozessoren.
8-Bit schrieb: > Da spart es enorm viel Zeit, wenn man auf eine > moderne, hoch skalierbare Architektur umsteigen kann. Wie oft hast du schon erlebt, dass ein gut eingeführtes Produkt von Grund auf neu gebaut wurde, statt es inkrementell weiter zu entwickeln? Also in kommerziellem Rahmen natürlich. Nichtkommerziell ist das recht verbreitet. Natürlich gibt es das. Nur muss man damit rechnen, dass die Kunden erst einmal die 2. oder 3. Revision davon abwarten, um nicht Betatester spielen zu müssen. Sollen das doch die anderen machen. Oft läuft es darauf hinaus, auf einige Jahre beide Produkte parallel pflegen zu müssen. Bis das neue so weit ist, das alte wirklich problemarm ersetzen zu können.
A. K. schrieb: > Wie oft hast du schon erlebt, dass ein gut eingeführtes Produkt von > Grund auf neu gebaut wurde, statt es inkrementell weiter zu entwickeln? > Also in kommerziellem Rahmen natürlich. Nichtkommerziell ist das recht > verbreitet. Schon ein paar Mal, besonders natürlich wenn der Funktionsumfang gering ist und der alte Code schlecht wartbar war. Aber auch bei größeren Projekten habe ich das schon gesehen. Dazu muss man sagen, dass eine von Anfang an vernünftig gestaltete Plattform leicht auf eine günstigere oder leistungsfähigere Architektur portiert werden kann und es dann gar nicht mehr notwendig ist, etwas von Grund auf neu zu entwickeln.
Wenn die 8-bit so langsam und ineffizient sind, frage ich mich, wie man denn jahrezehnte lang mit diesen controllertypen erfolgreich arbeiten konnte? Mein Arbeitgeber muss mich für die letzten 8 Jahre ja abmahnen :-) Jede Entwicklungsabteilung macht seine eigene Rechnung auf. Und da kann man nicht pauschal sagen, die 32-Bitter kommen günstiger; es zählen noch eine Menge andere Faktoren.
Coder schrieb: > Wenn die 8-bit so langsam und ineffizient sind, frage ich mich, wie man > denn jahrezehnte lang mit diesen controllertypen erfolgreich arbeiten > konnte? Mein Arbeitgeber muss mich für die letzten 8 Jahre ja abmahnen > :-) Ganz einfach: Weil sie bis vor 1-3 Jahren noch die günstigest Alternative waren und tatsächlich für die meisten Anwendungen - wenn auch oft mit Kompromissen im Design ausgereicht haben. Coder schrieb: > Jede Entwicklungsabteilung macht seine eigene Rechnung auf. Und da kann > man nicht pauschal sagen, die 32-Bitter kommen günstiger; es zählen noch > eine Menge andere Faktoren. Richtig, und deshalb geht der Trend in Richtung 32 Bit. In Bezug auf Bauteilkosten sind sie inzwischen ganz vorne dabei. Sie ermöglichen außerdem besser skalierbaren und wartbaren Code. Das alles spricht sehr stark dafür, dass sich 32-Bit-uC durchsetzen werden und die 8-Bitter in immer mehr Anwendungen ersetzen werden. Es wird ohne Zweifel in den nächsten Jahren immer noch viele Anwendungen für 8-Bit-Architekturen geben.
8-Bit schrieb: >> 10-Bit ADC-Werte kann man bequem und schnell genug mit 2 x 8-Bit >> verarbeiten. Die Bremse dabei ist meist der ADC selbst. >> Vielfach lasse ich auch linksbündig wandeln und nehme nur das obere >> Byte. Zum Einlesen von Potis reicht das in der Regel aus. >> Wenn dann 'hochpräzise' 24-Bit ADCs verwendet werden, sind diese so >> lahm, dass auch hier die 8-bittige Weiterverarbeitung nicht als Bremse >> wirkt. > > Und welchen enormen Vorteil hat man da noch bei einem 8-Bitter,w enn man > ständig mit solchen Krücken herumwerkeln muss? Seit Anfang des Jahres nehme ich einen C-Compiler, der das für mich erledigt. 8-Bit schrieb: >> 8-Bit PWM reicht mir zur Helligkeitssteuerung von 7-Segm.-Anzeigen, für >> die Hintergrundbeleuchtung von TFTs und auch für die Steuerung von >> DC-Motoren. > > Hintergrundbeleuchtung: Ja gut, wenn man keine Kennlinie braucht. > Ansonsten sieht man schon ganz alt aus. Du kaufst immer nur TFTs mit Kennlinie der Hintergrundbeleuchtung? Alles klar! > Und DC-Motoren sind ja fast schon genauso out wie 8-Bit-Prozessoren. Nomen est omen - bei Deinem Auto ist der Scheibenwischermotor ein Scheibenläufer und die Seitenscheiben werden mit BLDC-Motoren bewegt? Alles klar!
Nur mal so am Rande: Wenn Du an 10000 Controller 600€ sparst, weil dein M0 ein bissl günstiger aber für 100K€ Software neu entwickelst (Zulassungen usw.!!) ist deine rechnung nicht gut. So viel zu den anderen Faktoren, die du mir im Munde umdrehst. Sorry. Nicht jede Firma hat Multimillionen Stückzahlen! Als hobbyst ist das andere sache..
Ich verstehe die Diskussion gerade nicht. Atmel vs. Atmel? Natürlich ist Microchip besser!
Tim . schrieb: > Ich verstehe die Diskussion gerade nicht. Atmel vs. Atmel? Natürlich ist > Microchip besser! Zumindest muss man sich bei denen keine Gedanken machen, ob man nun auf ARM umsteigt. :-))
Jörg Wunsch schrieb: > Zumindest muss man sich bei denen keine Gedanken machen, ob man nun > auf ARM umsteigt. :-)) Was die Argumentation in diesem Thread angeht ist MIPS doch auch nur ein anders lackierter ARM. Also wenn schon dann sollten es MCUAs Lieblinge sein. Aber aus Atmel vs Renesas wird leider kein so schöner Zank wie bei Mircochip. ;-)
M. N. schrieb: > Seit Anfang des Jahres nehme ich einen C-Compiler, der das für mich > erledigt. Natürlich, aber der Ausgangspunkt der ganzen Diskussion war doch die Behauptung, dass 8-bitter soooo viel effizienteren Code produzieren. Also noch einmal konkret die Frage: Welchen erheblichen technischen Vorteil haben jetzt die 8-bitter wirklich gegenüber einem Cortex-M0? Coder schrieb: > Wenn Du an 10000 Controller 600€ sparst, weil dein M0 ein bissl > günstiger aber für 100K€ Software neu entwickelst (Zulassungen usw.!!) > ist deine rechnung nicht gut. So viel zu den anderen Faktoren, die du > mir im Munde umdrehst. Sorry. Richtig, deshalb legt man ja besonderen Wert auf Wartbarkeit und Skalierbarkeit. Und das geht mit den moderneren 32-Bit-Architekturen einfach besser, und spart deshalb - vernünftig eingesetzt - richtig viel Geld. Gerade bei kleineren und mittleren Stückzahlen. Natürlich ist es nicht sinnvoll, auf Teufel komm raus umzusteigen, wenn man schon eine fertige Codebasis für eine andere Architektur hat. Aber das habe ich auch nie behauptet. Und noch einmal, weil es hier wohl keiner kapiert: Ich behaupte nicht, dass jetzt sofort jeder auf ARM umsteigen muss und dass es in jedem Fall sinnvoll ist. Es geht um einen allgemeinen Trend und einen Prozess, der sich über Jahrzehnte hin ziehen wird.
8-Bit schrieb: > Ich behaupte nicht, > dass jetzt sofort jeder auf ARM umsteigen muss und dass es in jedem Fall > sinnvoll ist. Es geht um einen allgemeinen Trend und einen Prozess, der > sich über Jahrzehnte hin ziehen wird. Da sind wir uns ja endlich einig und kein Grund mehr, sich mit Händen und Füßen dagegen zu wehren: die 8-Bitter werden uns überleben.
M. N. schrieb: > Da sind wir uns ja endlich einig und kein Grund mehr, sich mit Händen > und Füßen dagegen zu wehren: die 8-Bitter werden uns überleben. Natürlich werden ein paar Exoten überleben, aber auf breiter Linie werden sie durch die 32-bitter ersetzt.
>Die neuen 32-Bit-uC werden in einer viel moderneren Technologie >gefertigt. Somit sind breitere Busse überhaupt kein Thema. Wenn die Busse schon "so breit" sind, warum kann ein ARM dann nicht statt seinem Flaschenhals cont. (in 4 oder 8 Bit incr.) von 8..128 Bits OPCode einlesen? >Ich hab hier nen 64-Bitter Baujahr 1992, zugegeben es ist kein µC >sondern eine "normale" MIPS R4k4, aber damals(TM) gab's keinen >Unterschied zwischen µC und normaler CPU. Is ja interessant. Die Leute in '92 kannten also keinen Unterschied zwischen einem HC11- / 8051-uC (mit interner Periferie) und verschiedenen Derivaten davon, zu einer PC-CPU (ohne spez Periferie)? (Und auch von MIPS gab es damals schon Controller) >aber wer gibt sich >heute schon mit einem Adressraum von 64 KBbyte zufrieden? Jede Menge Leute. Die weit überwiegende Anzahl an Controllern hat deutlich < 64 kB RAM / ROM (bzw Flash). > LED dimmen: mit 8 Bit nicht sinnvoll, zumindest nicht für > Beleuchtungsanwendungen. Für das kleine Zeugs würde wohl (oft) ein 4 Biter reichen >Alle drei lassen Portzugriffe in einem Befehlstakt zu, in einem Befehlstakt ???????? ARM hat nichtmal ein Befehl, um ein Bit (oder mehr) zu setzen (*), geschweige denn, das mit einem Takt zu machen! ((*) nat. angewandt auf MEM oder IO) Selbst ein PIC (aus den 70ern !) kann das besser. >Ey - also ich finde den LPC810 toll. dito >Dass die Befehlslänge von AVR und Thumb identisch ist... heisst aber noch lange nicht, dass deshalb auch Befehle identisch sind. >Die Crux ist eher, dass eine Adressraumtrennung die Programmierung >deutlich komplizierter gestaltet. Weil man bei jedem Pointer >berücksichtigen muss, in welchen Adressraum er zeigen soll. Nö. Adressraumtrennung hat man fakt. immer, denn Daten sind was anderes als Code (selbst wenn log. gesehen diese Bereiche sich überlappen könnten), also muss man auch immer die Richtigkeit des Pointers (sofern man den überhaupt braucht) berücksichtigen. Wenn Busse (Code/Daten) sich logisch gesehen überlappen können, heisst das noch lange nicht, dass sie sich physikalsich gesehen überlappen. Somit gibt es die typische (uralt) Trennung von Neumann / Harvard nicht mehr. >Renesas 16-Bitter M16C(&Co) variieren das, indem sie einen gut >adressierbaren 64K Datenadressraum in einen für Daten weit schlechter >adressierbaren 1MB Gesamtadressraum einbetten. Nö. M16C(&Co) haben grösseren Datenadressraum. (Die grösseren der Reihe haben auch mehrere 32 Bit Reg. Insbes. sind deren Adressierungs-Möglichkeiten zigmal besser als bei ARM. (was aber nicht heissen soll, das die für jegliche Anwendung am besten geeignet sind, denn oft sind schlichtweg die Kosten entscheidend))
MCUA schrieb: >>Ich hab hier nen 64-Bitter Baujahr 1992, zugegeben es ist kein µC >>sondern eine "normale" MIPS R4k4, aber damals(TM) gab's keinen >>Unterschied zwischen µC und normaler CPU. > Is ja interessant. > Die Leute in '92 kannten also keinen Unterschied zwischen einem HC11- / > 8051-uC (mit interner Periferie) und verschiedenen Derivaten davon, zu > einer PC-CPU (ohne spez Periferie)? > (Und auch von MIPS gab es damals schon Controller) Die definition von µC war damals eine andere als heute. Jede CPU die in einem Chip geliefert wurde war µ und wenn sie in irgendeiner Steuerung verbaut wurde war sie Controller. That's it.
>Es gibt nicht mal einen Abschnitt wo die maximal zulässigen >Ströme drin stehen. Current out of a GND pin 50mA , nix 400mA. >Die definition von µC war damals eine andere als heute. Nö.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.