Der Titel sagt es schon. Alles, oder sehr vieles was man an 32-Bit Architektur im Mikrocontroller-Bereich hört/sieht kommt konzeptuell aus der ARM-Schmiede. Ich kenne daneben nur die ATMEL 32 Bit Prozesoren und die von Freescale (Motorola). Was gibt es noch an 32-Bit Mikrocontrollern wo nicht ARM drin ist? Bitte erweitert meinen Horizont.
Halbwisser schrieb: > Die Halbgötter in Weiss servieren eine Suchanfrage > wo ARM enthalten ist. wo ARM NICHT enthalten ist. Einfach mal weiterblättern... Vielleicht lassen die Halbgötter ja Augen regnen :-)
Jürgen H. schrieb: > Man beachte das minus ;-) (-arm) Na super. "Wer unseren xyz 32-Bit Mikrocontroller nicht kennt, ist arm dran." wird also weggefiltert?
Renesas M32R. Markus E. schrieb: > Infineon TriCore Der TriCore ist teuer, aber genial. Durfte auf der Uni im Rahmen eines Labors damit was machen.
:
Bearbeitet durch User
Dein Vorposter hatte bereits festgestellt, dass der TE das ja in seinem Eingangsposting schon erwähnt hatte, und daher die Löschung seines Kommentars beantragt. ;)
- Xtensa (z.B. als LX106 im ESP8266 oder LX6 im ESP32) - einige DSPs (z.B. C2000 von TI, Blackfin von AD)
Christopher J. schrieb: > - Xtensa (z.B. als LX106 im ESP8266 oder LX6 im ESP32) > > - einige DSPs (z.B. C2000 von TI, Blackfin von AD) Er hat nach Microcontrollern und nicht nach DSPs gefragt...
BEIN schrieb: > 68k aka CPU32 > 88k > VAX > Sparc > i860 Ich kann auch hier nicht so recht die Mikrocontroller erkennen ... Halbwisser schrieb: > Was gibt es noch an 32-Bit Mikrocontrollern wo nicht ARM drin ist?
Die ganzen Softcores in den FPGAs: Microblaze, Nios II, ZPU, LatticeMico32, LEON3... Das Drumherum (Speicher + Peripherie) das aus dem Mikroprozessor einen Mikrocontroller macht passt meist auch noch ins FPGA-fabric und dass es billig sein soll hat der TE ja nicht gesagt ^^
2⁵ schrieb: > H. K. schrieb: >> Der TriCore ist teuer, aber genial. > > In wie weit ist der Tricore "genial"? Die Errata Sheets sind dicker als ein AVR-Manual; eben "never stop thinking" ;-)
Halbwisser schrieb: > BEIN schrieb: >> 68k aka CPU32 Die hat Freescale/NXP bzw. bald Qualcomm auch noch im Angebot. Die laufen da nur unter dem Namen ColdFire. Renesas hat gleich eine ganze Reihe von 32-Bit Controllern, die nicht auf ARM basieren: SuperH (ursprünglich Hitach), RX (Renesas), V850 (ursprünglich NEC), M32R (ursprünglich Mitsubishi) FTDI hat FT32 in bspw. den FT900ern Fujitsu hat noch FR50, FR60 und FRlite im Angebot Noch unbekannter ist hier z.B. Andes http://www.andestech.com/en/index/index.htm deren Cores bspw. hier http://www.hycontek.com/e-page2-HY16F.html zu finden sind. RISC-V ist auch gut im Rennen, leider noch nicht ganz so weit lowRisc http://www.lowrisc.org/ PULP Platform http://www-micrel.deis.unibo.it/pulp-project/
STMler schrieb: > Christopher J. schrieb: >> - Xtensa (z.B. als LX106 im ESP8266 oder LX6 im ESP32) >> >> - einige DSPs (z.B. C2000 von TI, Blackfin von AD) > > Er hat nach Microcontrollern und nicht nach DSPs gefragt... C2000 geht je nach Blickwinkel auch noch als Microcontroller durch und der Blackfin hat einen neben dem eigentlichen DSP. Hatte das aber zugegebenermaßen nicht gelesen, dass er explizit nach Mikrocontrollern gefragt hatte.
Halbwisser schrieb: > Was gibt es noch an 32-Bit Mikrocontrollern wo nicht ARM drin > ist? Bitte erweitert meinen Horizont. Warum kein ARM? Das ist Stand der Technik. Was spricht dagegen? Die PIC32 haben keinen ARM-Kern, aber ich glaube, dass für Microchip Atmels Besitz der ARM-Lizenz ein gutes Kaufargument war. Gruß Daniel
Daniel V. schrieb: > Warum kein ARM? Das ist Stand der Technik. Was spricht dagegen? Viele der hier genannten Prozessorfamilien sind deutlich innovativer und modernen als ARM. Arm ist bei Marketing und Vertrieb führend. Einen eignen Core zu entwickeln und weiter zu treiben ist halt sehr viel Aufwand und man benötigt gute Partner für die Tools. Da ist ein ARM Kern einzubauen günstig und risikolos. Auch für die Anwender.
Daniel V. schrieb: > Halbwisser schrieb: >> Was gibt es noch an 32-Bit Mikrocontrollern wo nicht ARM drin >> ist? Bitte erweitert meinen Horizont. > > Warum kein ARM? Das ist Stand der Technik. Was spricht dagegen? Warum nur ARM Monokultur, was spricht dafür? ARM ist nur wegen deren Lizenzmodell so weit verbreitet. Das ist nur Marketing, andere Architekturen sind gleichwertig. Will jetzt nicht behaupten das ARM schlecht sind - ganz und gar nicht. Aber "der Stand der Techik" deren Kerne ist nicht der Grund für deren Erfolg. Wirklich stark sind die ARMs sowieso wo anders, nicht beim Kinderspielzeug (Controller), sondern bei den dicken SOCs und App-Prozessoren. Viel wichtiger sind bei Controllern in vielen Fällen andere Faktoren: Der Erfolg der STM32-Serie zum Beispiel dürfte nicht auf den Prozessorkern zurückzuführen sein. Da ziehen die Punkte seriöser Hersteller, Preis, Langzeitverfügbarkeit und passable Peripherie, lesbare Datenblätter und kurze Errata-sheets. Der STM32F031 kostet erheblich weniger als ein ATMEGA. Vergleich doch mal Features, Toolchain und Peripherie eines STM32F031 mit einem beliebigen ATMEGA. Da hast du deinen Grund "für den Erfolg von ARM".
Trumpeltier schrieb: > Der STM32F031 kostet erheblich weniger als ein ATMEGA. ... > Da hast du deinen Grund "für den Erfolg von ARM". mhm auf Kosten der Sparer und EU Steuerzahler ja so kann man sich auch alles schönrechnen, Draghi, den Franzosen und Italienern sei Dank. Nur so kann sich ein Hersteller Quartal zu Quartal Verluste. Aber das große Erwachen kommt bestimmt... meine Meinung
Stefan schrieb: > mhm auf Kosten der Sparer und EU Steuerzahler ja so kann man sich auch > alles schönrechnen, Draghi, den Franzosen und Italienern sei Dank. Nur > so kann sich ein Hersteller Quartal zu Quartal Verluste. Aber das große > Erwachen kommt bestimmt... meine Meinung Also ST ist ein europäische Hersteller, ATMEL/Microchip ein amerikanischer. Danach würde das Umstellen von ATMEL auf ST die europäische Wirtschaft stärken. Damit europäische Arbeitsplätze und den Euro. Bitte erkläre deinen Beitrag.
> Warum kein ARM? Das ist Stand der Technik. Was spricht dagegen?
Du bekommst mehr Leistung, ausgereiftere Technik, bessere Datenblaetter
und schoenere Peripherie. Ausserdem ist dein Leben abwechslungsreicher
und die FAEs dankbarer. :)
Olaf
Olaf schrieb: >> Warum kein ARM? > Du bekommst mehr Leistung, ausgereiftere Technik, bessere Datenblaetter > und schoenere Peripherie. und exotische ungetestete proprietäre Compiler und mangelhafte oder inkompatible oder fehlende Tools für teuer Geld.
Bei größeren Automotive-Projekten, vor allem rechenintensive Algos, ist der TriCore gesetzt. Das wird auch teilweise vom OEM so vorgegeben. Auch wenn der Ingenieur das nur ungern hört: Bei der Bewertung der Eignung eines Produktes (in dem Fall Mikrocontroller) spielt die Technik nur eine untergeordnete Rolle. Da gibt es genug Faktoren die höher gewichtet werden: Preis, Verfügbarkeit, Verbreitung, persönliche Vorgeschichte, Firmenpolitik, Lizenzsystem, Tool-Landschaft.... Evtl. kann man noch Werbung/Marketing/Vertriebswege dazuzählen. Das kann man scheiße finden, durchaus. Aber mittlerweile sollte keiner mehr überrascht sein dass die technisch "beste" Lösung nicht immer bevorzugt wird, das ist schon lange kein Geheimnis mehr. PS: prominentes Beispiel ist DOS in den 80ern und die immer noch anhaltende Marktdominanz von MS ;-)
:
Bearbeitet durch User
Daniel V. schrieb: > Die PIC32 haben keinen ARM-Kern, aber ich glaube, dass für Microchip > Atmels Besitz der ARM-Lizenz ein gutes Kaufargument war. Das denke ich nicht. Immerhin hat Microchip jetzt den neuen Cortex-M23/M33 selber lizensiert. Interessant waren vermutlich eher das Knowhow der Implementation der ARM-IP in ein eigenes Produkt was jetzt mit den neuen Cortex von Nutzen sein dürfte, um schneller mit einem Produkt am Markt zu sein.
>> Da hast du deinen Grund "für den Erfolg von ARM". >mhm auf Kosten der Sparer und EU Steuerzahler ja so kann man sich auch >alles schönrechnen, Draghi, den Franzosen und Italienern sei Dank. Deine Antwort hat nun gar nichts mit diesem Thread zu tun. Draghi tut übrigens genau das einzig Mögliche und Richtige. Das ist aber mit null makroökonomischen Bildungshindergrund leider nicht zu verstehen.
Daniel V. schrieb: > Warum kein ARM? Das ist Stand der Technik. Was spricht dagegen? Themaverfehlung. Es geht um die Erweiterung meines (Halbwissen-, Viertelwissen- ...) Horizontes. Eventuell auch um deinen .....
Halbwisser schrieb: > Was gibt es noch an 32-Bit Mikrocontrollern wo nicht ARM drin > ist? Bitte erweitert meinen Horizont. Schau mal in ein Fachmagazin, die haben regelmäßig Marktanalysen. Seit Jahrzehnten mischte da Hitachi (jetzt Renesas) mit der SH-Familie gut mit. DSP's finden sich im 32bit embedded Markt, bspw Drucker. Also schau mal bei Texas Instrument vorbei insbes bei der TMS320-Serie.
Trumpeltier schrieb: > Der STM32F031 kostet erheblich weniger als ein ATMEGA. Vergleich doch > mal Features, Toolchain und Peripherie eines STM32F031 mit einem > beliebigen ATMEGA. Deshalb würde mich die Intention des TO interessieren, warum er keinen ARM-Kern haben möchte? Le X. schrieb: > Bei größeren Automotive-Projekten, vor allem rechenintensive Algos, ist > der TriCore gesetzt. Das wird auch teilweise vom OEM so vorgegeben. Ist das so? Werden nicht eher die ARM-R-Familie z.B. von TexasInstruments eingesetzt? Hast Du eine Quelle? Le X. schrieb: > Bei der Bewertung der Eignung eines Produktes (in dem Fall > Mikrocontroller) spielt die Technik nur eine untergeordnete Rolle. Joar, das stimmt allerdings. In der Luftfahrt ist das nicht anders, da kommen auch noch weitere Aspekte wie Technologieknoten (<90 nm und man ist raus), Peripherie, Sprachkompatibilität etc. zusammen. STler schrieb: > Interessant waren vermutlich eher das Knowhow der Implementation der > ARM-IP in ein eigenes Produkt was jetzt mit den neuen Cortex von Nutzen > sein dürfte, um schneller mit einem Produkt am Markt zu sein. Ja, das ist ein netter Nebeneffekt gewesen. Hätte Atmel nicht die ARM-Lizenz, glaube ich nicht ob Microchip den Laden übernommen hätte. Gruß Daniel
Daniel V. schrieb: > Deshalb würde mich die Intention des TO interessieren, warum er keinen > ARM-Kern haben möchte? Davon war nicht die Rede. Oder doch? Wo steht bitte dass ich keinen mit ARM-Architektur haben möchte? Muss ich mich wohl verschrieben haben. Ich zweifle an mir selbst.
Arc N. schrieb: > Die hat Freescale/NXP bzw. bald Qualcomm auch noch im Angebot. Die > laufen da nur unter dem Namen ColdFire. ColdFire != CPU32
Daniel V. schrieb: > Ist das so? Werden nicht eher die ARM-R-Familie z.B. von > TexasInstruments eingesetzt? Hast Du eine Quelle? Nein, das ist subjektives Empfinden, beruhend auf Erfahrungen mit verschiedenen Projekten mit verschiedenen OEMs. Vor allem wenn noch irgendwelche Safety-Ziele eingehalten werden müssen. Was ich hier abteilungsübergreifend mitkriege wird fast nur der TriCore eingesetzt. Für kleinere ECUs die hauptsächlich irgendwelche Akotren ansteuern, aber hohe Stückzahlen haben werden aber nach wie vor gerne kleine 16-Bitter eingesetzt.
Markus F. schrieb: > Arc N. schrieb: >> Die hat Freescale/NXP bzw. bald Qualcomm auch noch im Angebot. Die >> laufen da nur unter dem Namen ColdFire. > > ColdFire != CPU32 Doch ColdFire ist als 68k Derivat eine 32 bit CPU. Kann man auch gern im Datenblatt ab S.61 nachlesen http://www.nxp.com/files/32bit/doc/ref_manual/MCF5272UM.pdf
Trumpeltier schrieb: > Stefan schrieb: >> mhm auf Kosten der Sparer und EU Steuerzahler ja so kann man sich auch >> alles schönrechnen, Draghi, den Franzosen und Italienern sei Dank. Nur >> so kann sich ein Hersteller Quartal zu Quartal Verluste. Aber das große >> Erwachen kommt bestimmt... meine Meinung > > Also ST ist ein europäische Hersteller, ATMEL/Microchip ein > amerikanischer. > Danach würde das Umstellen von ATMEL auf ST die europäische Wirtschaft > stärken. Damit europäische Arbeitsplätze und den Euro. > > Bitte erkläre deinen Beitrag. Zwar bin ich kein Microchip Fan, trotzdem sind mir deutsche Arbeitsplätze die Microchip in Deutschland hält lieber als diejenigen die auf Teufel komm raus vom Steuerzahler finanziert werden. Also findest Du staatsfinanzierte Unternehmen sinnvoller als Unternehmen die sich profitabel selbst erhalten können? Sorry aber staatsgelenkte Unternehmen und staatsfinanzierte Arbeitsplätze möchte ich nicht mit meinem Steuergeld unterstützen. Wenn die Firma nicht von selbst tragfähig ist soll sie eben Pleite gehen. Natürliche Marktbereinigung.
Ordner schrieb: >> ColdFire != CPU32 > > Doch ColdFire ist als 68k Derivat eine 32 bit CPU. Der Begriff CPU32 steht für eine Architekturversion aus der 68000 Reihe.
Halbwisser schrieb: > Wo steht bitte dass ich keinen mit ARM-Architektur haben möchte? > Muss ich mich wohl verschrieben haben. Ich zweifle an mir selbst. Man nennt das Problem glaube ich Kommunikationstreppe. Man versucht als Mensch immer herauszufinden, welche Gedankengänge das Gegenüber verfolgt. Man kann die Intention hinter deinem Post auf verschiedene Arten interpretieren: - Ich will keinen ARM mehr nehmen! - ARM ist das Beste, es gibt nichts anderes, das beweise ich euch! - Ich will wissen, was es neben ARM noch gibt Je nach eigenem Wissensstand / Hintergrund liegt irgendeine dieser Interprtationen jetzt besonders nahe. Und dementsprechend fällt die Antwort aus. So kommt es dann zu derartigen "Unfällen". Ich würde das nicht allzu krumm nehmen.
> Wenn die Firma nicht von selbst tragfähig ist soll sie eben Pleite gehen.
Aber bitte nicht bei der Infrastruktur (Bahn, Trinkwasser, etc).
> und exotische ungetestete proprietäre Compiler und mangelhafte oder > inkompatible oder fehlende Tools für teuer Geld. AEhem..ja fuer Cortex-M3 hab ich gerade diese Woche einen bemerkenswerten Bug im gcc (4.7.x) gefunden. Gcc fuer SuperH wuerde dagegen als sehr ausgereift ansehen. Olaf
Trumpeltier schrieb: > Man kann die Intention hinter deinem Post auf verschiedene Arten > interpretieren: Da gibt es nicht viel zu interpretieren. Halbwisser schrieb: > Bitte erweitert meinen Horizont. Andere Mütter haben (vielleicht?) auch schöne Töchter.
Bernd K. schrieb: > Olaf schrieb: > >>> Warum kein ARM? > >> Du bekommst mehr Leistung, ausgereiftere Technik, bessere Datenblaetter >> und schoenere Peripherie. > > und exotische ungetestete proprietäre Compiler und mangelhafte oder > inkompatible oder fehlende Tools für teuer Geld. Compiler RX: GCC, Renesas eigener basiert afaik auf clang, IAR SuperH: GCC, clang/LLVM, IAR, GHS V850: GCC, IAR, GHS M32R: GCC, IAR MIPS: GCC, clang/LLVM, GHS Andes: GCC, http://osdk.andestech.com/ RISC-V: GCC, clang/LLVM TriCore: GCC, clang/LLVM, Tasking, GHS Power: GCC, clang/LLVM, GHS 68k/ColdFire: GCC, clang/LLVM(?), GHS, Tasking XMOS: GCC/LLVM https://www.xmos.com/support/tools/source Debugging- und Trace-Tools gibt es für die u.a. von Lauterbach, Segger, Yokogawa Digital, iSYSTEM und anderen
Bernd K. schrieb: > und exotische ungetestete proprietäre Compiler und mangelhafte oder > inkompatible oder fehlende Tools für teuer Geld. Der Wildwuchs bei ARM-Cores hat dafür hingegen zur Folge, dass es immer mal wieder Versionen von gcc gibt, die u.U. buggy Code generieren, oder mal wieder eine Option für Hack/Bug X implementiert wird, die man dann kennen sollte. Und wieder ist man bei den Interna.. Die genannte Blackfin-Architektur (übrigens genausowenig als DSP zu betrachten wie ein ARM mit SIMD-Extensions) ist mal ein schönes Beispiel. Leider auch wie Tricore in der Nische steckengeblieben..
Interessant ist, dass noch niemand die Nummer 2 nach ARM (bzgl. der Anzahl in Umlauf gebrachter Einheiten) genannt hat: Synopsys ARC. Siehe auch: http://www.eejournal.com/archives/articles/20131106-archs/ Und es ist auch interessant, dass diese Core-Familie auch ihren Ursprung in Europa hat.
Jetzt habt ihr dem Halbwisser seine Hausaufgaben gemacht. Naja, nicht ganz. Eine der genannten Architekturen ist nur 8-Bit, nicht 32-Bit. Welche, muss er selber rausfinden. Damit geht auch kein Copy&Paste mehr in die Arbeit, und beim prüfen welche Architekturen wirklich 32-Bit sind, lernt er vielleicht noch was. ;)
Fitzebutze schrieb: > Der Wildwuchs bei ARM-Cores hat dafür hingegen zur Folge, dass es immer > mal wieder Versionen von gcc gibt Erzähl mehr!
Arc N. schrieb: >> und exotische ungetestete proprietäre Compiler und mangelhafte oder >> inkompatible oder fehlende Tools für teuer Geld. > > Compiler > RX: GCC, Renesas eigener basiert afaik auf clang, IAR > SuperH: GCC, clang/LLVM, IAR, GHS > V850: GCC, IAR, GHS > M32R: GCC, IAR > MIPS: GCC, clang/LLVM, GHS > Andes: GCC, http://osdk.andestech.com/ > RISC-V: GCC, clang/LLVM > TriCore: GCC, clang/LLVM, Tasking, GHS > Power: GCC, clang/LLVM, GHS > 68k/ColdFire: GCC, clang/LLVM(?), GHS, Tasking > XMOS: GCC/LLVM https://www.xmos.com/support/tools/source OK, ich nehme meine Bemerkung zurück.
>>bemerkenswerten Bug >Was für einen? Der Compiler erzeugt Code der sich beim Ruecksprung aus Funktionen weghaengt. typedef struct { unsigned short Manufakture; unsigned char Parity1; unsigned char Device; unsigned short Command; unsigned char Parity2; unsigned char NewFlag; unsigned char RepeatCounter; } Kaseikyo_Type; void test(void) { Kaseikyo_Type Kommando; } oder void kasei_reciever(void) { static short timingcounter; //boese short counter2; //gut weil auf stack } Grund ist vermutlich das der Cortex-M3 irgendwie mit dem Allignment das der Compiler erzeugt nicht klar kommt. Interessanterweise hatte ich mit anderen ARMs und denselben Compiler das Problem nicht. Loesung ist entweder: Kaseikyo_Type Kommando _attribute_ ((aligned (_BIGGEST_ALIGNMENT_))); oder -mstructure-size-boundary=32 Olaf
Olaf schrieb: >>>bemerkenswerten Bug >>Was für einen? > > Der Compiler erzeugt Code der sich beim Ruecksprung aus Funktionen > weghaengt. Nein, ich denke er fragte nach der Bug-ID, Bugtracker-Link. Würde mich auch interessieren.
>Der Compiler erzeugt Code der sich beim Ruecksprung aus Funktionen >weghaengt. Ah, danke. Irgendwie meine ich, vor kurzem mal von so einem Fehler gehört zu haben. Ziemlich schwer zu finden ...
Vielleicht gibt es auch irgendwann noch den bo32 als Erweiterung des bo8. https://www.mikrocontroller.net/articles/8bit-CPU:_bo8 *duck und weg** Gruß Jobst
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.