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.
>Und Ihr habt dann automatisch die A-Karte.
Das wohl eher nicht, denn Unschlüssiger schrieb: "...und auch Abnehmer
in der Hand." :-)
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 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?
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
Vielleicht meldet sich Unschlüssiger mal wieder. Nicht, dass wir ihn schon ins Irrenhaus getrieben haben :-)
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
Eclipse? Äh nein, mein Rechner bleibt javafreie Zone. Aber prinzipiell stimme ich Dir zu, sofern insbesondere der Debugger gut eingebunden ist. 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
Bitte 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.