Was ist 32 Bit und nicht ARM?

Na super.

Die Halbgötter in Weiss servieren eine Suchanfrage
wo ARM enthalten ist.

Danke.

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 :-)

Intel Galileo oder so, echte X86.

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?

Besser Arm dran, als Arm ab;-)

Infineon Tricore
ST SPC56

V850 / RH850

P8X32A aka Parallax Propeller

H. K. schrieb:
> Der TriCore ist teuer, aber genial.

In wie weit ist der Tricore "genial"?

68k aka CPU32
88k
VAX
Sparc
i860

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 ^^

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

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.

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.

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

>bemerkenswerten Bug
Was für einen?

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:
> 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.

;)

>>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

>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 ...