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!
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.
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.
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? ;-)
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.
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 ;-)
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).
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.
>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.
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 ;-)
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.
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.
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
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
Unschlüssiger schrieb:> Jetzt suchen wir noch einige der Passenden BauteileUnschlüssiger schrieb:> diesen Punkt versuchen wir schon seit knapp 2 Monaten zu lösenUnschlü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?
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/16LXfamily.pdf 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
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
>> 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.
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
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 ;-)
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
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
>...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.
@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?
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-Microcontroller-Family-offers-44-models-587067
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.
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.
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
> 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
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
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!
> 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
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
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
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.
> 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
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
Μα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.
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
