mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Fujitsu MCU vs Cortex M3


Autor: Unschlüssiger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gemeinde,

wir, ein "Drei-Köpfiges" Team wollen ein kleines 
"Nebenbeschäftigungs-Startup" eröffnen und haben schon feste Projekte 
(aus Industrie und Automotive) und auch Abnehmer in der Hand.

Jetzt suchen wir noch einige der Passenden Bauteile. Das Abwägen fällt 
uns jedoch extrem schwer, da die entsprechenden Bauteile alle 
gleichartig von ihren Features sind.

Der Cortex M3 hat viel mehr Features (bei diversen Herstellern) das er 
für uns in Frage kommen könnte. Jedoch sehen wir die doch so oft 
angepriesene "Second Source" nicht, da jeder Hersteller andere Features, 
Pinnings, Footprints,... rausgebracht hat. Wir haben noch bei keinem ein 
Dropin-Replacement gefunden.

Die F²MC16 von Fujitsu sehen auch extrem brauchbar aus und sind auch in 
Automotiv Versionen gut bezahlbar. Wir würden den als Neuauflage für die 
guten alten C167 ansehen - nur eben mehr Up to Date und preislich 
attraktiver. Auch er erfüllt all unsere Ansprüche!

Wir hatten mehrere Besuche verschiedener Distributoren und FAEs, 
stellten den so ziemlich die selben Fragen und die Antwort waren meist 
die selben: "Das müssen Sie entscheiden - die sind alle ungefähr 
Featuregleich!"

Unsere Frage wäre jetzt: hat jemand im Automotiv oder Industriesektor 
mit Cortem M3 und Fujitsu M²MC16 gearbeitet und kann "besser als der 
andere" Punkte nennen?

Vielen Dank!

(PS diesen Punkt versuchen wir schon seit knapp 2 Monaten zu lösen - 
also keine "aus dem Bauch" Laune!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unschlüssiger schrieb:

> Wir haben noch bei keinem ein Dropin-Replacement gefunden.

Sowas gibts eigentlich nur bei musealen 8051ern in 
Original-Intel-Ausstattung.

Die Periphieremodule von Controllern sind weitgehend 
herstellerspezifisch - ab und zu mag ein eingekauftes ARM-Modul dabei 
sein. Damit muss man leben. Der Vorteil der Cortexe ist eher, dass die 
Entwicklungswerkzeuge herstellerneutral funktionieren. Wenn man sich die 
Preise von Keil oder IAR vor Augen führt, dann kann das für kleinere 
Vorhaben schon ein Argument sein.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habt Ihr schonmal eine Tabelle erstellt in der Ihr jedes einzelne 
Feature der Prozessoren übersichtlich gegenüberstellt, incl. 
Entwicklungsumgebungen und Demo-Code beispiele und Liefer-Verfügbarkeit?
Habt Ihr schon einen bestimmten Cortex Chiphersteller (z.B. ST, NXP 
usw.) mit einem bestimmten Chip ausgesucht?

Irgendwie scheint mir so, als ob man 2 Monate nur oberflächlich die 
Sache engekratzt hat. In der Zeit hätte man sich ein paar Demo-Boards 
kommen lassen können um den einen oder anderen Versuch zu machen.

Autor: Meise (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wichtiger Tipp: seht euch auch die Errata Sheets der Prozessoren an!

Bei einigen aktuellen Cortex-M3 Serien von TI ist z.B. der komplette 
Hibernation Controller nicht nutzbar! Und das obwohl TI teilweise 
Werbung mit dieser Peripherie macht.

Wenn man nicht aufpasst kann man sein blaues Wunder erleben was in einem 
Mikrocontroller nicht funktioniert. Wenn man dann um solche Hardwarebugs 
herum programmieren muss ist das sehr frustrierend.

Beispiel Errata TI: http://www.ti.com/litv/pdf/spmz082i

Bei Fujitsu hab ich auf die schnelle keine Erratas gefunden. Machen die 
keine Fehler? ;-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meise schrieb:

> Bei Fujitsu hab ich auf die schnelle keine Erratas gefunden. Machen die
> keine Fehler? ;-)

Ein Controller dieser Grössenordnung, dessen Erratas weder im Datasheet 
drinstehen noch öffentlich verfügbar sind, der käme für mich nicht in 
Frage. Denn eines ist klar: Die gibts nicht ohne Bugs.

Autor: Unschlüssiger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei den Cortex M3 haben wir STM32 getestet und für gut befunden.
Bei den Fujitsu MCUs haben wir auch etwas geordert, aber die Lieferung 
steht leider noch aus.

Bei der Software haben wir uns eher weniger Sorgen gemacht! Klar das wir 
bei den Cortex Keil benutzen...

Allgemein haben wir für Compiler und Debugger mit 10 - 15k€ denke ich 
recht großzügig gerechnet.

Was bei den Fujitsus unserer Meinung nach zum vorteil haben ist, dass 
die extrem oft eben nur für u.A. KFZs und dergleichen verwendet werden.
Samples an Software bekommt man für beide Architekturen on mass ;-)


Was uns auch noch recht wichtig erscheint ist die Störanfälligkeit bzw 
der Sicherheit! Fujitsu verspricht dort doch schon so manches, was man 
u.A. bei Motorsteuergeräten oder Wechselrichterapplikationen schon 
braucht!

Aus persönlicher Erfahrung habe ich auch schon so manche Schlüsse 
gezogen. Z.B. haben MCUs älterer Herstellungsvarianten (vermutlich 
aufgrund ihrer Stukturgrößen) weniger Probleme mit ESD und EMV. Auch die 
DIE Größe spielte da in der Vergangenheit eine große Rolle.

Wir hatten das Problem einen großen el. Antrieb zu überwachen. Ein 
relativ gebräuchlicher Kontroller (8Bit von Atmel) hatte dort trotz 
Störunterdrückungsmaßnahmen aller höchster Kunst massivste Probleme 
durch Störeinstrahlungen. Nach reichlichen Redesigns unter zurhilfe 
Maßnahme von FAEs und Messlaboren sind wir dann dazu über gegangen, 
mehrere kleine Kontroller (des selben Herstellers) zu benutzen. Und 
siehe da, die Probleme lösten sich auf ;-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unschlüssiger schrieb:

> relativ gebräuchlicher Kontroller (8Bit von Atmel) hatte dort trotz
> Störunterdrückungsmaßnahmen aller höchster Kunst massivste Probleme
> durch Störeinstrahlungen.

Darf man fragen welche? Von der alten AT90 Reihe ist dieses Phänomen 
bereits länger bekannt. Auch manche zu alten Typen kompatible Megas 
besitzen damit ein von Haus aus EMV-empfindlicheres Pinout (vom Die weit 
entfernte Taktanschlüsse bei DIL-Version, weit auseinander liegende 
Vcc/GND Pins auch bei SMD).

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine persönlichen Favoriten sind bei solchen Sachen keine ARMs sondern 
Renesas R8C, M16C, SH und Microchip PIC24FJ/HJ und PIC33FJ.
Dazu hin und wieder mal ein 8051er von SiLabs.
Zudem sind mir, außer einigen ARM7 von TI und Freescale, keine Cortex-M3 
bekannt die AEC-Q100 Grade 1 (-40 °C - 125 °C) oder Grade 0 (-40 °C - 
150  °C) erreichen/qualifiziert sind.

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Auch er erfüllt all unsere Ansprüche! (Fujitsu)

Dann würde ich den nehmen. Wenn zusätzliche Eigenschaften nicht 
gebraucht werden, gibt es keinen Sinn, einen 'dickeren' µC zu nehmen. 
Cortex M3 ist noch (zu) neu.
Wenn die eingesetzten µCs recht günstig sind, kann man sie auch besser 
bevorraten.

Zu Second Source, die gibt es doch sowieso nicht mehr.

Autor: Unschlüssiger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Darf man fragen welche?

Ja, AT90CAN128, ersetzt haben wir den um 3 ATmega48 und 2ATtiny plus 
einen CAN Controller



Entwickler schrieb:
> Zu Second Source, die gibt es doch sowieso nicht mehr.

Zumindest bei den Controllern nicht


Wir tendieren auch eher zu den MCUs von Fujitsu - hätten aber noch gerne 
einige "Benutzer" von denen über die Benutzung befragt. Die 
Distributoren haben uns, verständlicher weise, keine Firmen genannt, 
sagten jedoch das es in den letzten 3 Jahren jedoch eine steil steigende 
Anzahl in Deutschland geben soll. Hoffentlich war das nicht nur 
Distributer-Smalltalk ;-)

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du Dich hier im Forum umsiehst, findest Du Nutzer von AVR, PIC, 
8051, MSP430, ARM7 und auch M3 (absteigende Reihenfolge und 
unvollständig :-)
Fujitsu Anwender eigentlich garnicht. Daher wirst Du hier nicht viel in 
Erfahrung bringen können.
Auch zu meinen Renesas-Lieblingen gibt es hier keine großen Meinungen.

Was Du von den Distributoren zu hören bekommst, wird allererst 
Wunschdenken sein, damit die Vertriebsvorgaben erfüllt werden. 
Substanzielle Informationen, die über das hinaus gingen, was ich nicht 
schon selber wußte, habe ich dort nie erhalten. Woher soll ein junger 
Vertriebs-Ing. denn auch seine jahrzehntelangen Erfahrungen haben?

Daher mußt Du Deine Entscheidung treffen und durchziehen und dabei immer 
über den Tellerrand sehen, was sonst noch in der Welt passiert.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich ist die Antwort klar.

Wenn Ihr jetzt einen Cortex-M3 nehmen würdet und es gäbe nur das 
kleinste EMV Problem, dann würden alle mit dem Finger auf euch zeigen, 
warum habt Ihr nicht einen Fujitsu genommen so wie alle Auto-Bauer?
Und Ihr habt dann automatisch die A-Karte.

Alternativ könnt Ihr einfach irgend ein Demo-Board mit dem STM32 nehmen 
und dieses (wohl nicht optimale Design der Platine) mal EMV mäßig 
testen. Die Ergebnisse würden mich auch interessieren.

Ich selbst bin begeisterter STM32 User, aber das steht hier ja nicht zur 
Debatte.

Ich habe eine Heizungssteuerung gebaut, natürlich mit einem STM32, die 
CPU ist seit Betrieb nicht ein einziges mal hängen geblieben. Die 
Platine hat natürlich die üblichen EMV-Schutzsachen drauf.

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Und Ihr habt dann automatisch die A-Karte.


Das wohl eher nicht, denn Unschlüssiger schrieb: "...und auch Abnehmer 
in der Hand." :-)

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

wir verwenden die Dinger (LX und FX) in der 4ma. Ich bin sehr zufrieden 
mit den Teilen. Schnell, gut dokumentiert, 1a Support von Glyn und 
Fujitsu, langzeitverfügbar. Errata gibts natürlich, heißt "Customer 
Information" und ist sehr detailliert. Compiler ist einwandfrei (wenn 
man mal von den etwas merkwürdigen Warningstufen absieht) die IDE 
(Softune) allerdings nicht. Ich ruf den Compiler mittels makefile auf 
und filtere die Warnings mit einem Perlscript so das ich im VS direkt 
draufklicken kann. Alles in allem sind die Dinger wirklich eine 
Empfehlung wert.

Matthias

Autor: Mar Vol (marvol)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.

Es ist schon mindestens ein Jahr her, da haben wir die F²MC16 auf dem 
Evalutionboard ausprobiert. Die Aufgabenstellung war die RS485 
Kommunikation mit der Adresserkennung über das 9 Bit. Nach langem hin 
und her konnte der Interrupt nicht sauber erkannt werden, und irgendwann 
bekamen wir auch die Rückmeldung vom Support, dass dies noch nicht 
implementiert wäre. Die Beispiele sind sehr gut und auch sehr 
vielseitig, aber bei den größeren Teilen war die Extrahierung der 
gewünschten Funktion sehr aufwendig. Des weiteren haben wir den Online 
Debugger nie richtig zum Laufen bringen können. Irgendwann haben wir es 
dann aufgegeben.

Ich weiß nicht, wie der aktuelle Stand ist. Ein großer Vorteil ist 
sicherlich der Einsatz im Automotivbereich -- aber mal ganz ehrlich, wer 
hat denn schon als Kleinunternehmen die finanzielle Grundlage in diesem 
Bereich Fuß zu fassen. Man muss sich mal überlegen, wie lange ein 
Produkt braucht bis es überhaupt in die Serie kommt. Wie viele Tests 
gefahren werden müssen und wie viele Modifikationen dafür notwendig ist 
-- da gehen schnell mal ein bis zwei Jahre ins Land und die müssen auch 
finanziert werden, der Kunde bezahlt diese meist nicht.

Gruß
Marvol

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unschlüssiger schrieb:
> Jetzt suchen wir noch einige der Passenden Bauteile

Unschlüssiger schrieb:
> diesen Punkt versuchen wir schon seit knapp 2 Monaten zu lösen

Unschlüssiger schrieb:
> haben schon feste Projekte
> (aus Industrie und Automotive) und auch Abnehmer in der Hand.

Das hört sich für mich nicht ansatzweise so an, als wenn das in der 
realen Welt unter einen Hut paßt. Welcher Kunde kann sich denn sowas 
leisten?

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unschlüssiger schrieb:
> Hallo Gemeinde,
--snip--
> Die F²MC16 von Fujitsu sehen auch extrem brauchbar aus und sind auch in
> Automotiv Versionen gut bezahlbar. Wir würden den als Neuauflage für die
> guten alten C167 ansehen - nur eben mehr Up to Date und preislich
> attraktiver. Auch er erfüllt all unsere Ansprüche!
> -- snip --

So ganz verstehe ich Euren Ansatz nicht. Hab gerade mal zum Spass eine 
MC16 Broschuere angeschaut 
http://www.fujitsu.com/downloads/MICRO/fma/pdf/16L... und das 
sind doch eher sehr langsame Teile. Vielleicht gibt es ja auch VIEL 
schnellere Brueder und Schwestern.
Jedenfalls sehe ich noch nicht mal einen Grund vom C167 wegzugehen, 
schon gar nicht wenn ich die XC167 oder den XC2000 mit dem MC16 
vergeleiche. Mit den Preisen kenne ich mich in kleinenren Srueckzahlen 
nicht aus, in grossen Mengen zahlt man ori Chipflaeche und die ist 
wiederum stark vom Speicher, SRAM / Flash abhaengig. Was ich damit sagen 
moechte, gleicher Speicher bei Futjistu kostet aehnlich wie gleicher 
Speicher bei Inifineon.

Falls ihr natuerlich USB und LCD im Automotive benoetigt bietet der 
Fujitsu diese Schnittstellen....
Performance maessig kann der XC loecker bei den Cortex-M gleicher 
Frequenz mithalten, der MC16 laeuft halt viel langsamer.

Nur so als Gedanke, nochmals mit Infineon oder deren Disti verhandeln 
und existierende Software weitgehend weiterbenuetzen sollte eine 
Alternative sein im Vergleich zu einem Schritt in ein Performanceloch.

Gruss, Robert

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

woraus schließt du das die 16LX "sehr langsam" im Vergleich zu einem 
XC167 sind? Würde mich einfach mal so interessieren wie man das Anhand 
einer simplen Broschüre abschätzen kann. Ich hab keine Erfahrung mit dem 
XC167 denke aber das der mit seinen 40MHz auch keine Wunder vollbringen 
kann.

Dazu kommt natürlich das die Architektur 16LX (MB90Fxxx) dann doch schon 
sehr lange am Markt ist. Aktuell würde ich die nicht mehr in einem neuen 
Design einsetzen. Bei 16FX (MB96Fxxx) sieht es da schon anders aus. Bei 
gleicher Taktfrequenz sind die erheblich schneller (und sparsamer) und 
erreichen mit 56MHz auch einen deutlich höheren Takt.

Matthias

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Performance maessig kann der XC loecker bei den Cortex-M gleicher
>> Frequenz mithalten, der MC16 laeuft halt viel langsamer.

Das möchte ich doch mit Zahlem belegt haben. Insbesondere, dass der XC 
"locker" mithalten kann.

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin schrieb:
>>> Performance maessig kann der XC loecker bei den Cortex-M gleicher
>>> Frequenz mithalten, der MC16 laeuft halt viel langsamer.
>
> Das möchte ich doch mit Zahlem belegt haben. Insbesondere, dass der XC
> "locker" mithalten kann.

Sagen wir mal so, ich hab mit beiden gearbeitet, intensiv sogar als 
Applikations Ingenieur und als Verantwortlicher bei 2 Firmen fuer 
Benchmarks. Nicht vergessen, dass ich geschrieben hab bei gleicher 
Frequenz. Eine Moeglichkeit waere es z.B. die CPI, clocks per 
Instruction herauszufinden und da duerfte der XC besser abschneiden. 
Interrupt Performance hat der Cortex endlich Anschluss gefunden an die 
urspruengliche Interrupt Struktur des 80C166 aus dem Jahr 1989!
Es gibt natuerlich eindeutige Vorteile des Cortex-M3 und die liegen in 
der Aushwahl verfuegbarer Bausteine aber eben nicht fuer Automotive. 
Ausserdem laeuft der schnellste M3 ca. doppelt so schnell wie der 
schnellste XC2000.
Ich bin ein sehr starker Cortex-M Anhaenger aber weiss eben aus meiner 
persoenlichen Erfahrung in der Vergangenheit, dass der single clock 167, 
also der XC167 und der XC2267 weniger Taktzyklen fuer einen Befehl 
brauchen als der M3. Wenn allerdings viele 32-bit Daten verarbeitet 
werden kann die Recnung wieder zu Gunsten des Cortex ausfallen.
Wollte nur dem OP die Alternative aufzeigen bei der urspruenglichen 
Architektur zu bleiben. Die XC2267 gibt es immerhin bis 80 MHz und damit 
duerfte mindestens jeder MC16 den ich gefunden hab ausgestochen werden. 
Was denkt ihr denn warum Fujitsu gerade Cortex-M3 Teile angekuendigt 
hat?

Gruss, Robert

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß nicht, ob die Rechengeschwindigkeit an dieser Stelle für den 
"Unschlüssigen" der entscheidende Punkt ist.
Er schrieb eingangs zum Fujitsu: "Auch er erfüllt all unsere Ansprüche!"

Dagegen kann man schlecht argumentieren; optimal reicht, und das kann 
man nicht steigern. (Obwohl ich gerade mein Demoboard mit RX610 bekommen 
habe ;-)

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Entwickler schrieb:
> Ich weiß nicht, ob die Rechengeschwindigkeit an dieser Stelle für den
> "Unschlüssigen" der entscheidende Punkt ist.
> Er schrieb eingangs zum Fujitsu: "Auch er erfüllt all unsere Ansprüche!"
>
> Dagegen kann man schlecht argumentieren; optimal reicht, und das kann
> man nicht steigern. (Obwohl ich gerade mein Demoboard mit RX610 bekommen
> habe ;-)

Hab ich vielleicht missverstanden. Mein Eindruck war, es existiert 
Software fuer den C167 und es soll ein Umstieg erfolgen. Dann waere der 
designierte Nachfolger XC167 oder dessen Upgrade XC2267 eine echte, 
zeitsparende Alternative. Preislich bin ich mit dem Segment Automotive 
nur in sehr grossen Stueckzahlen etwas vertraut.

Robert

Autor: wolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo du Unschlüssiger,

du solltest besser nicht einen Cortex mit den 16 Bit Controllern von 
Fujitsu vergleichen. Da wären schon eher die 32 Bit Controller vo 
Fujitsu (die FR-Reihe) angesagt. Ich habe schon mit beiden Typen (FR und 
Cortex) gearbeitet und meine dazu folgendes:

1. was für die Fujitsu-FR's spricht:
- Die haben von Hause aus einen 16 Bit breiten Maschinencode, den ich 
für deutlich besser halte als den THUMB und THUMB2 von ARM.
- Die Versionen mit externem Busanschluß haben einen Befehls-Cache und 
ziehen deshalb locker an den meisten ARM's vorbei. Das liegt einfach 
daran, daß es bis heute keinen Flashrom mit Zugriffszeiten unter ca. 
40..50 ns gibt und deswegen so ein ARM beim Laden von jedem Befehl ein 
paar Waits einlegen muß.
- Von den Fujitsus sind viele in Nicht-Consumer-Produkten drin, weswegen 
es zwar keine riesige Typenvielfalt, dafür aber langfristige 
Verfügbarkeit gibt - und die Chips sind mittlerweile gut ausgereift und 
nicht buggy. Wen ich dran denke, was es mit dem 2478 von NXP für ein 
Theater gab...
- Die Entwicklungsumgebung "Softune" incl. aller Compiler usw. gab es 
jahrelang kostenlos auf der Embedded. Wie es nächstes Jahr aussieht, 
weiß ich natürlich nicht.
-  Die Doku ist im Vergleich zu den Epen aus den Häusern NXP und ST 
richtig gut lesbar und verständlich geschrieben.
- Die Chips sind nicht teuer.

2. was für die Cortexe spricht:
- Sie sind derzeit in aller Munde und deshalb gibt es auch ne Menge 
Leute, von denen man was lernen kann. Ebenso gibt es für Linuxer die 
GNU-Tools zum Entwickeln.
- Es gibt eine große Typenvielfalt und vielleicht sind demnächst auch 
Chips mit dabei, die einen benutzbaren TFT-Controller drin haben. Sowas 
gibt's bei den Fujitsu-Controllern nämlich NICHT, denn Fujitsu hat eine 
eigene Sparte von Grafik-Controllern.
- Sie haben Peripherie (USB, SD-Karten, Ethernet), die im Gegensatz zu 
Fujitsu eher auf Consumergeräte ausgerichtet ist.
- Sie sind für den normalen Bastler viel leichter beschaffbar als Chips 
von Fujitsu.

Ach, schau dir beide Sorten einfach mal selber an.

LiGrü wolf

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>...daß es bis heute keinen Flashrom mit Zugriffszeiten unter ca.
>40..50 ns gibt ...

Such mal nach MONOS-Flash. Renesas hat diese 10ns FlashROMs schon seit 
einigen Jahren in Produktion.
Viele Leute vermuten dabei Trickserei - is aber nich!
Das mußte ich noch loswerden.

Autor: xyz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Wolf
Dir Cotex M3 gibts tatsächlich zum grossen teil ohne Cach.

nur (aus dem datenblat zum lpc17xx)

Up to 512 kB on-chip flash programming memory. Enhanced flash memory 
accelerator enables high-speed 120 MHz operation with zero wait states.

dei gnu toolchain gibts nicht nur für linux. windows und osX user können 
diese auch benutzen.


aus dem Datenblatt vom XC226x’s
High Performance 16-bit CPU with 5-Stage Pipeline
– 15 ns Instruction Cycle Time at 66MHz CPU Clock (Single-Cycle 
Execution)
wie jetzt pipline oder single cycle?

wie sieht das beim c167 mit dem debugen aus? braucht man da immer noch 
nen emulator oder haben die mitlerweile auch JTAG oder was ähnliches?

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
xyz schrieb:
> @Wolf
> Dir Cotex M3 gibts tatsächlich zum grossen teil ohne Cach.
>
> nur (aus dem datenblat zum lpc17xx)
>
> Up to 512 kB on-chip flash programming memory. Enhanced flash memory
> accelerator enables high-speed 120 MHz operation with zero wait states.

Ist so was aehnliches wie ein mini-Cache tut aber nur vom internen 
Speicher, extern ist das mit den Wait-States schon richtig.
>
>
> aus dem Datenblatt vom XC226x’s
> High Performance 16-bit CPU with 5-Stage Pipeline
> – 15 ns Instruction Cycle Time at 66MHz CPU Clock (Single-Cycle
> Execution)
> wie jetzt pipline oder single cycle?
Es gibt keine mir bekannten, modernen Architekturen die ohne Pipeline 
arbeiten. Es wird ueber mehrere Befehle hinweg gesehen nahezu ein Befahl 
pro Zylus fertig. Das nennt sich single Cycle und hat eine Pipeline.

>
> wie sieht das beim c167 mit dem debugen aus? braucht man da immer noch
> nen emulator oder haben die mitlerweile auch JTAG oder was ähnliches?

Der C167 braucht noch einen Emulator, der XC22xx hat eine sogenannte 
OCDS (on-Chip-Debug-Support) Schnittstelle. Die kann zwischen etwas mehr 
bis viel mehr als Standard JTAG. Allerdings koennen SWD zusammen mit SWV 
auch einiges mehr als Standard JTAG.

Robert

Nochmals zur Wiederholung, warum denkt Ihr denn, dass Fujitsu gerade 44 
Produkte in der FM3 Familie angekuendigt hat? Weil die alten Teile noch 
richtig wettbewerbsfaehig sind oder weil die Felle davonschwimmen?
http://news.thomasnet.com/fullstory/RISC-Microcont...
Sind zwar nicht gerade die schnellsten M3s auf dem Markt aber immerhin 
koennen sie 2,7V - 5,5V und haben augenscheinlich 3 12-bit ADCs.

Autor: Star Keeper (starkeeper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was man bei der Wahl des Mikrocontrollers auch nicht vernachlässigen 
sollte sind die Software-Tools.
Für die Fujitsu gibt es nach meinem Wissensstand keine freie 
Entwicklungsumgebung und keine freien Kompiler. Wenn ich das richtig in 
Erinnerung habe, bekommt man in Europa eine mit Lizenzauflagen gespickte 
kostenlose version zur Verfügung gestellt. Was aber ja nicht zwingend 
für jeden ein Nachteil sein muss.
Die Qualität der Tools ist aber eher mies und ist z.B. für einen 
Entwickler mit keinem Visual Studio oder einem Eclipse vergleichbar. Die 
Ergonomie ist quasi vorsintflutlich und hält beim Arbeiten wirklich auf, 
was sich in der Entwicklungszeit bemerkbar machen kann.

Hinzu kommt, dass man sich, um die 32Bit Fujitsu debuggen zu können, 
einen Emulator anschaffen muss. Gerade bei einem Startup kann der schon 
mal den Gewinn des Ersten Projektes schlucken. Der Emulator ist dann 
wiederum nicht zwingend für alle 32Bitter von denen nutzbar, sodass man 
eventuell beim nächsten Projekt einen neuen braucht.

Quasi alle von mit vermuteten Nachteile des Fujitsu sind dann auch schon 
wieder Vorteile der Cortex, ARM-Strategie. Es gibt eine Fülle an 
Entwicklungsumgebungen, viele mehr oder minder gute Kompiler und alle 
können über JTAG debuggt werden. In der regel braucht man keinen 
Emulator für die Entwicklung. Die Cortex der verschiedenen Hersteller 
sind zwar nicht Pin-Kompatibel aber die Software ist es trotzdem zu 
großen Teilen. So, dass man von Projekt zu Projekt nicht an einen 
Hersteller gebunden ist, in der Regel kann man immer Software-Teile 
vorhergehender Projekte wieder verwenden.

Das ist meine persönliche Meinung dazu. (Vllt. kann man ja raushören 
welcher Hersteller meiner meinung nach in der Vergangenheit den Zug 
verpasst hat. Ganz abgesehen von der Leistung.)

Was mich noch etas wundert ist die Anforderung Industrial + Automotive 
Tauglich, nicht aber in einem Projekt oder?
Zumal ein Automotive tauglicher Mikrocontroller noch lange nicht das 
Projekt automotive tauglich macht.

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Star Keeper schrieb:
> Was man bei der Wahl des Mikrocontrollers auch nicht vernachlässigen
> sollte sind die Software-Tools.
Da gebe ich Dir zu 100% recht. Zitat OP, "Klar das wir
bei den Cortex Keil benutzen..."
Also ist Professionalitaet und  time to market wichtiger als bei den 
Tools auf kostenlose Angebote zu setzen.

> Für die Fujitsu gibt es nach meinem Wissensstand keine freie
> Entwicklungsumgebung und keine freien Kompiler. Wenn ich das richtig in
> Erinnerung habe, bekommt man in Europa eine mit Lizenzauflagen gespickte
> kostenlose version zur Verfügung gestellt. Was aber ja nicht zwingend
> für jeden ein Nachteil sein muss.
> Die Qualität der Tools ist aber eher mies...
--snip--
Da liegt der Hund begraben. Bei professionellen Anwendern ist die 
Qualitaet der Tools wichtig, viel wichtiger als der Anschaffungspreis.

Just my 2 cents

Robert

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Was man bei der Wahl des Mikrocontrollers auch nicht vernachlässigen
> sollte sind die Software-Tools.

Ich wuerde sogar sagen das dies eines der Hauptkriterien ist nachdem
ich einen Controller auswaehlen wuerde. Und es ist wohl der Grund warum 
ich die Controller von Renesas verwende.

[Fujitsu Oberflaeche]
> Die Qualität der Tools ist aber eher mies und ist z.B. für einen
> Entwickler mit keinem Visual Studio oder einem Eclipse vergleichbar.

Ich habe mir vor 2-3Jahren mal Fujitsu angeschaut und die Oberflaeche 
war fuer mich ein Grund ganz schnell Abstand zu nehmen. Falls sich da 
nicht viel verbessert hat kann ich auch nur dringend abraten.

> Hinzu kommt, dass man sich, um die 32Bit Fujitsu debuggen zu können,
> einen Emulator anschaffen muss.

Bei Renesas kostet der E8 IMHO so um die 100Kroeten. Also ein Witz fuer 
eine Firma. Dafuer kann man wirklich viele Tolle Dinge machen die einem 
eine Menge Entwicklungszeit sparen.

> und alle
> können über JTAG debuggt werden. In der regel braucht man keinen
> Emulator für die Entwicklung.

Aber man braucht doch irgendein jTAG Inteface. Wo siehst du da den 
Unterschied zu einem Emulator? Oder meinst du man braucht so ein 
klassisches Teil das die CPU komplett ersetzt?

Ich wuerde jedenfalls auch mal empfehlen einen Blick auf die R32 oder RX 
zutun. Und zwar gerade wegen der Entwicklungsoberflaeche.

Olaf

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht meldet sich Unschlüssiger mal wieder. Nicht, dass wir ihn 
schon ins Irrenhaus getrieben haben :-)

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unschlüssiger schrieb:

> Bei der Software haben wir uns eher weniger Sorgen gemacht! Klar das wir
> bei den Cortex Keil benutzen...

So klar würde ich das nicht sehen. Im Automotive-Bereich wird IAR gerne 
genommen, wegen MISRA-C Support. Und rein persönlich finde ich die 
Keil-IDE etwas lahmarschig (auf einem 2.8 GHZ Core2Quad mit 4GB RAM), 
IAR sagt mir mehr zu. Probiert am Besten beide aus.

Ist Safety für Euch ein Thema? -> Cortex R4
AEC Q100 ist für Euch ein Thema! Was sagen die Lieferenten dazu?

fchk

Autor: Star Keeper (starkeeper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:

> Aber man braucht doch irgendein jTAG Inteface. Wo siehst du da den
> Unterschied zu einem Emulator? Oder meinst du man braucht so ein
> klassisches Teil das die CPU komplett ersetzt?
>
Also ein Emulator ist ein Gerät, dass den Chip komplett ersetzt. In der 
Regel muss dazu ein Sockel auf die Platine gelötet und dann über Adapter 
der Emulator angeschlossen werden. An das JTAG kommt ein Debugger dran, 
die eigentlich Debug-Hardware bringt aber der Chip mit, das Gerät zum 
anstöpseln ist nur für die Kommunikation mit dem PC zuständig. Deshalb 
können viele Debugger auch für verschiedene Mikrocontrollertypen 
eingesetzt werden.

So ein Emulator bietet sehr viel mehr Möglichkeiten als ein normaler 
Debugger. Meine Erfahrung ist aber, dass es nur selten nötig ist einen 
Emulator zu benutzen, wenn der Chip einen JTAG hat. Viele Emulatoren 
haben z.B. eine umfassende Trace möglichkeit wo auch interrupts usw. 
über längeren Zeitraum aufgezeichnet werden.

Um noch mal auf die Errata-Sheets zu kommen. Die gibt es für jeden chip 
auch bei Fujitsu. Bei dem STM32 habe ich mal eine böse Überaschung 
erlebt, da gibt es eine ganze Reihe bei denen geht der DMA nicht 
korrekt. Der Fehler ist auch jetzt 2 Jahre später noch nicht gefixt!

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Also ein Emulator ist ein Gerät, dass den Chip komplett ersetzt.

Das wusste ich. Ich dachte aber nicht das man heute noch sowas
verwendet weil der Einsatz bei Controllern mit vielen kleinen
Beinchen ja hoellisch aufwendig ist und man viele Signale mit
sehr hohen Frequenzen ueber den Bus bekommen muss. Stell ich
mir z.B interessant vor bei Controllern mit externem DDRam.
Ich haette angenommen sowas sei nahezu ausgestorben seitdem die 
Controller
kein DIL40 Gehaeuse mehr haben.

BTW: Renesas scheint da auch ein neues Konzept zu haben. Neben
der normalen Schnittstelle mit den ueblichen Debuggern (z.B E8) hat
der R32 einen Pin der heisst NSD. Da kann man einen Debugger/Emulator 
E30,
anschliessen der alles ueber eine Leitung macht.

Mir reicht aber ein E8 wo ich beliebig auf Sourcelevel debuggen kann, 
alle Variablen sehen kann, Variablen aendern kann, Register und Speicher 
sehen kann.

Olaf

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> Unschlüssiger schrieb:
>
>> Bei der Software haben wir uns eher weniger Sorgen gemacht! Klar das wir
>> bei den Cortex Keil benutzen...
>
> So klar würde ich das nicht sehen. Im Automotive-Bereich wird IAR gerne
> genommen, wegen MISRA-C Support. Und rein persönlich finde ich die
> Keil-IDE etwas lahmarschig (auf einem 2.8 GHZ Core2Quad mit 4GB RAM),
> IAR sagt mir mehr zu. Probiert am Besten beide aus.

Etwas OT: Mich stört bei den ganzen (Compiler-)Herstellern egal ob Keil, 
IAR, Renesas oder sonst wem, dass sie meinen auch noch "gute" IDEs 
mitliefern zu müssen. Selbst Microchip setzt mittlerweile beim MPLAB X 
auf NetBeans.
Beschränkt euch auf vernünftige Compiler/Debugger/etc und nutzt Eclipse, 
NetBeans oder Visual Studio als IDE!


> fchk

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eclipse? Äh nein, mein Rechner bleibt javafreie Zone. Aber prinzipiell 
stimme ich Dir zu, sofern insbesondere der Debugger gut eingebunden ist.

fchk

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jede IDE die ich bisher von einem Compiler hersteller gesehen habe ist 
aus der Steinzeit. und somit nicht zu gebrauchen. egal ob IAR oder keil 
oder Mentor. jeder macht da seinen properitären ...

Wer mal in der java welt mit eclipse zu tun hatte oder mit .Net oder c++ 
eines der neueren Visual studios, der würde diese IDEs am liebsten 
gleich wieder löschen. Viele Featers die hilfreich sind existieren ganz 
einfach nicht.

Mit keil hab ich nur mal kurz auf nem seminar arbeiten dürfen. War 
wieder was neues und daher ungewöhnt. Was mich aber bei keil stört ist 
denen ihre properitären JTag adapter. Funktionieren nur mit keil und 
sonst mit nix. somit hab ich jetzt nen adapter den man auf den müll 
schmeisen könnte, da wir keil nicht verwenden.

IAR hat sich etas gebessert, das asugabe format ist jetzt zumindest 
nicht mehr ganz so properitär wie früher. Der IDE fehlen aber viele Code 
editing featers von der CDT. Codecompleation, Refectoring, ...

Mentor nun ja setzt angeblich auf der CDT auf. nur wurden die bei der 
entwicklung ihrer IDE von der CDT mit sicher 2 MagerRevisions überholt. 
Somit setzen die auf nem veralteten kern auf, den man dank mentor auch 
nicht durch was neues austauschen kann.

Eclips (CDT) als editor / Projektverwaltung bisher das brachbarste für 
mich. Aufsetzen des Projektes ist etwas aufwendiger, Make file 
schreiben, Tools zusammensuchen, ... wenn das aber mal läuft. eine 
Brauchbare lösung.

Debuggen steht auf einem anderen blatt. die GDB integration hat so ihre 
maken.

Aber wo wir beim Debugger sind. OS support ist meist auch noch ein Thema 
für die IDE auswahl. was brigt ein Debugger, der keine kernelawarnes für 
das eingesetzte OS besitzt. Man kann zwar debuggen. nur OS Probleme 
(Deadlocks  Stack overflows  ...) finden sich nicht ganz so einfach.

gruss

Autor: ert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
123 schrieb:
> ... CDT mit sicher 2 MagerRevisions überholt...
                       ^            ^
YMMD

Autor: Matthias K. (matthiask)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
123 schrieb:
> Was mich aber bei keil stört ist
> denen ihre properitären JTag adapter. Funktionieren nur mit keil und
> sonst mit nix.

Stimmt nicht ganz, es gehen auch andere.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Beschränkt euch auf vernünftige Compiler/Debugger/etc und nutzt Eclipse,
> NetBeans oder Visual Studio als IDE!

Mein Rechner ist und bleibt javamuellfreie Zone. Wenn schon dann wuerde 
ich Emacs benutzen. Aber ich habe an HEW nichts auszusetzen ausser das 
sich der Editor nicht auf Emacs-Kommandos umstellen laesst.

Olaf

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
>> Die Qualität der Tools ist aber eher mies und ist z.B. für einen
>> Entwickler mit keinem Visual Studio oder einem Eclipse vergleichbar.
>
> Ich habe mir vor 2-3Jahren mal Fujitsu angeschaut und die Oberflaeche
> war fuer mich ein Grund ganz schnell Abstand zu nehmen. Falls sich da
> nicht viel verbessert hat kann ich auch nur dringend abraten.

Die Oberfläche ist, sehr sehr vorsichtig ausgedrückt, ein bisschen 
rückständig ;-) Aber der Compiler dahinter macht einen guten Job. Wir 
verwenden ein Make + Perl um den Compiler im VS einzubinden. 
Funktioniert hervorragend.

Matthias

Autor: Star Keeper (starkeeper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Μαtthias W. schrieb:
> Olaf schrieb:
>>> Die Qualität der Tools ist aber eher mies und ist z.B. für einen
>>> Entwickler mit keinem Visual Studio oder einem Eclipse vergleichbar.
>>
>> Ich habe mir vor 2-3Jahren mal Fujitsu angeschaut und die Oberflaeche
>> war fuer mich ein Grund ganz schnell Abstand zu nehmen. Falls sich da
>> nicht viel verbessert hat kann ich auch nur dringend abraten.
>
> Die Oberfläche ist, sehr sehr vorsichtig ausgedrückt, ein bisschen
> rückständig ;-) Aber der Compiler dahinter macht einen guten Job. Wir
> verwenden ein Make + Perl um den Compiler im VS einzubinden.
> Funktioniert hervorragend.
>
> Matthias

Debuggen geht dann aber immernoch nur mit dem Fujitsu-Tool.

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Star Keeper schrieb:

> Debuggen geht dann aber immernoch nur mit dem Fujitsu-Tool.

<ChuckNorris>
Echte Programmierer debuggen nicht. Echte Programmierer erledigen Fehler 
mit einem Roundhouse Kick.
</ChuckNorris>

Debuggen geht aber eigentlich ganz gut mit Softune. Meistens tuns aber 
ein paar eingestreute printfs. Vorteil: Zeitverhalten wird (fast) nicht 
beeinflusst. So ein Breakpoint ist für Kommunikationsprotokolle mit 
Timeouts eher suboptimal. Für komplexere Sachen als ein bisschen CAN + 
IO Behandlung  (wenn z.B. externes (DDR)(SD)RAM/Flash ins Spiel kommt) 
bevorzuge ich dann aber auch etwas >= ARM926. Als Einzelchipcontroller 
sind die 16FX aber wirklich gut, preiswert und mit reichlich interner 
Peripherie ausgestattet.

Matthias

Autor: Peterle Anonym (Firma: keine) (wanderameise)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wie ist denn der stand der Dinge? habt ihr euch entschieden?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.