Hallo, für ein größeres Projekt suche ich einen Mikrocontroller mit einer Floating-Point Unit. Je mehr Dampf, desto besser. Außerdem sollte das Teil noch handlötbar sein, also BGA, richtig fiese Pitchabstände oder Pins >> 200 sollten es nach Möglichkeit nicht sein, kommt aber dann auch auf den Einzelfall drauf an. Achso, um die Aufgabe noch ein wenig schwieriger zu machen, sollte es dafür einen (günstigen) C-Compiler und eine günstige Möglichkeit geben, das Teil zu programmieren. Eine gute Option dürfte ein µC mit ARM9 sein, weil es dafür eine kostenlose Entwicklungsumgebung gibt, und der Kern auch eine Anbindung für einen Coprozessor anbietet. Aber einen konkreten Chip, der alle oben genannten Anforderungen unter einen Hut bringt, habe ich bislang noch nicht gefunden. Wahrscheinlich kennt einer von den Cracks hier den Markt besser und kann mir behilflich sein... Schönes Wochenende! Stefan P.S.: Um eine echte FPU kommen wir nicht drumrum, eine Softwarelösung scheidet schon mal aus....
1. Vie viele FLOPS brauchs du ?
1.2 Geht mit soft ?
2. Samsung hat gute uC ARM basiert.
3. Hilft vielleicht ein DSP ?
Gruß
Gibt bei Freescale tolles uC ColdFire mit TQFP gehäuse bis etwa 100 MHz, nicht schlecht.
EP9302 (http://olimex.com/dev/cs-e930x.html). Hat 200 Pins. Aber du solltest schon ungefähr wissen, WIE schnell du rechnen musst.
>P.S.: Um eine echte FPU kommen wir nicht drumrum, eine Softwarelösung >scheidet schon mal aus.... Ich finde es immer wieder interessant, wie überzeugt Leute sind nicht um so etwas herumzukommen. Meist sind es die selben Leute, die dann später über die Maschinengenauigkeit stolpern. Zu deiner CPU Suche Deine Anforderungen lassen sich nicht leicht erfüllen. Warum nimmst du nicht ein Board mit BGA CPU und evt. Speicher. und steckst das auf dein restliches Board. Sowas gibt es sehr klein. Dann hast du keine Probleme mit Routing und löten und kannst trotzdem das verwenden, was du brauchst. BTW: geht es hier um 1 Exemplar oder eine ernsthafte Anzahl
Wie Andreas schon sagte haben die Cirrus ARM9s ne FPU. Das ist allerdings NCIHT die FPU von ARM. AVR32 würde mir auch noch einfallen. Und vermutlich gibts bei Renesas auch irgendwas in der Richtung.
@Andreas Schwarz Frage: wird es das genannte Board mit dem EP9302 auch im Shop geben? Wenn ja, wann und zu welchem Preis? Gruß Dieter
Wenn Interesse besteht, gerne. Preis wäre so ca. 160 Euro inkl. MwSt.
Sehe ich das richtig, das der Cirrus EP9302 auf jeden Fall noch externen Speicher und Flash braucht? @Wolfram: Ja, vielleicht kann man Floating Point irgendwie umgehen. Aber besser ist es, mal 10€ mehr in einen Chip zu investieren, als nachher tagelang zu versuchen, den Code zu optimieren weil das Teil dann doch zu schwachbrüstig ist. Das Teil muss ziemlich fiese Matrixmultiplikationen ausführen. Es geht prinzipiell erst einmal nur um einen Mikrocontroller, oder um eine sehr begrenzte Anzahl.
Der EP9302 benötigt auf jeden Fall externen Speicher, da er weder über internes RAM noch Flash verfügt. Dass du diese Frage stellst lässt aber wieder die Vermutung aufkommen, dass ein uC diesen Kalibers für deine Aufgabe vollkommen überdimensioniert ist. Internes RAM von ARM7TDMI etc. bewegt sich typisch in Grössenordnungen zwischen 16 und 256kb - wenn deine Daten dort hinein passen würden, ist es gut möglich, dass auch die Rechenleistung (ohne FPU) für deine Aufgabe ausreichend wäre. Beim EP9302 könntest du unter Umständen über Errata's des Maverick Crunch Co-Prozessors (== FPU) stolpern. Mir wurde gesagt, dass selbst aktuelle GCC Versionen nicht sämtliche Erratas (bzw. Workarounds dafür) implementieren. Cirrus ist nicht bereit, mit der FOSS Community zusammenzuarbeiten, trägt also nicht dazu bei, dass Probleme Upstream gefixed werden, sondern pflegt lieber eigene Kernel + Toolchain Releases, deren Qualität zumindest fragwürdig ist. Eine Alternative wäre eventuell der NXP LPC3180 - der verfügt über ARM's VFP (== FPU), die von aktuellen GCC Versionen problemlos unterstüzt wird. Dieser Chip ist zwar nur als BGA erhältlich, von Phytec z.B. gibt es jedoch ein CPU Board, das alle BGA Teile enthält, und über zwei Molex Connectors auf einem Basisboard Anschluss findet. Generell solltest du dir aber auf jeden Fall genauer über deine Anforderungen klar werden. Gruss, Dominic
@Andreas Schwarz Wieviele Interessenten bzw. Bestellungen brauchst Du um das Board im Shop anzubieten? Ein Board könnte ich kurzfristig bestellen. Mehr leider nicht. Gruß Dieter
@Stefan, wie groß soll denn die Rechenleistung tatsächlich sein. Nicht jede FPU ist unbedingt der Knaller bzgl. GEschwindigkeit. Manchmal geht es ja auch um Genauigkeit. Diese beiden Eckdaten sollten schon bekannt sein. Willst du vor allem Filter rechnen oder was soll gerechnet werden. Ein bischen Info würde auch zu etwas mehr Antworten führen. Thomas
Ich habe mal ein paar von den EP9302-Boards bestellt, sollten in ca. 2 Wochen da sein. Gibt es jemanden der schon Erfahrung mit dem EP9302 bzgl. Toolchain, Linux, Nutzung der FPU hat?
Moin... vom NXP3180 kann man nur abraten! Aussage NXP Entwicklung..... Das Ding ist wohl nur ein Testballon der für einen ganz kleinen Bereich von Anwendungen ausgelegt ist. Q4/07 soll es (frühestens) einen 3188 geben, der dann auch irgendwie einsetzbar ist. Das Phytec-Board habe ich hier übrigens liegen, garnicht mal so schlecht, wenn man denn den µC bebrauchen kann. -- SJ
Eventuell solltest Du auch einmal einen Prozessor aus der SuperH-Serie von Renesas in Betracht ziehen, z.B. SH7201 bzw. SH7203. Habe gerade einen Prospekt von Glyn in der Hand. Die haben eine FPU integriert und sind im QFP Gehäuse erhältlich (die grösseren leider nur mit mehr als 200 Pins). Das Verhältnis Rechenleistung zu Leistungsaufnahme dürfte ziemlich unschlagbar sein: Bei 200 Mhz Takt nur 288mW bei bis zu 480 Mips. Die Entwicklungsumgebung gibts dazu auch weitgehend umsonst. Gruss Mike
> Gibt es jemanden der schon Erfahrung mit dem EP9302 bzgl. Toolchain, > Linux, Nutzung der FPU hat? Ich hatte von Olimex vor einigen Monaten bereits ein EP9301 Board bekommen, um den OpenOCD damit zu testen. Der EP9302 ist praktisch identisch mit dem 9301, allerdings nur für bis zu 66 MHz Bustakt spezifiziert. Auch wenn der 9301 über keine FPU verfügen soll funktioniert sie bisher einwandfrei ;) Ein grundsätzliches Ärgernis mit Cirrus ist deren Unfähigkeit mit den Kernel Maintainern (Upstream) zusammenzuarbeiten. Cirrus bringt in unregelmäßigen Abständen einen eigenen Release heraus, der aus einer etwas älteren Kernelversion und nicht näher benannten Patches besteht. Bis vor Kurzem war von Cirrus nur Version 2.6.8 erhältlich, die bereits vor einigen Jahren released wurde. Lennert Buytenhek und Andere hatten den EP93xx Support daraufhin von Grund auf neu geschrieben, und Unterstützung für die wichtigsten Peripherals (UART, USB, Ethernet, AC97 Audio) in den Upstream Kernel gebracht. Cirrus weigerte sich allerdings, an dem Port mitzuarbeiten, und wollte Lennert auch nicht für das Schreiben weiterer Treiber bezahlen (alles andere hatte er pro-bono geschrieben, und lediglich ein Board zum Testen erhalten). Lennert ist der offizielle ep93xx Maintainer, und würde jederzeit Patches von Cirrus integrieren, allerdings besteht daran von Seiten Cirrus' kein Interesse, und der Cirrus Code erfüllt auf keinen Fall Linux Code Standards (weder formell noch qualitativ). Vor etwa zwei Wochen wurde von Cirrus eine neue Version released, die größtenteils auf der Arbeit Lennert's basiert, allerdings wurden z.B. saemtliche HW-Register umbenannt, und etwa das Tick Subsystem komplett ruiniert, so dass das System glaubte mit etwa der 2-fachen Geschwindigkeit zu laufen. Ähnlich sieht es mit der Toolchain aus - GCC 4.x enthält Support für Maverick Crunch, allerdings sollen wohl nicht alle Erratas implementiert sein. Von Cirrus gibt es mittlerweile eine neue Toolchain, die angeblich Crunch Support enthält, allerdings ist die nur binary only verfügbar, auf meine Anfrage nach dem Quelltext hat Cirrus geantwortet, dass das noch ein paar Tage dauern kann. Es ist aber z.B. möglich eine ganz normale softfloat Toolchain zu verwenden, und nur den eigenen, floating-point lastigen Code mit Maverick Unterstützung zu übersetzen (dazu ist die Verwendung der neuen EABI anstelle der alten OABI nötig). Sinnvollerweise sollte man dazu dann auch eine eigene libm verwenden, die ebenfalls mit Crunch übersetzt wurde. Upstream GLIBC lässt sich (noch) nicht vollständig für Crunch übersetzen. Mit dem Redboot, der von Olimex standardmäßig auf dem Board installiert ist, wurde ich nicht glücklich, darum habe ich existierende U-Boot Patches an das Olimex Board angepasst: http://mmd.ath.cx/cs-e9301/ Für den CS-E9302 müsste das Timing an die 200 MHz angepasst werden, alles andere sollte passen wie es ist. Ich habe eine machine-id für das E9301 registriert, ein Patch der diese Machine ID verwendet findet sich ebenfalls auf meiner Seite. Lennert hat mich letzte Woche nochmals nach dem Patch gefragt, und wird ihn in nächster Zeit in seinen Tree aufnehmen, womit er dann auch irgendwann auf kernel.org auftauchen sollte. Der Linux Patch und die Machine ID sollten as-is mit dem EP9302 verwendbar sein. Sparkfun hat ein Wiki zur Verfügung gestellt, in dem Doku zu Olimex Produkten geschrieben werden könnte, allerdings ist der Kunde, der dieses Dokumentationsprojekt in's Laufen bringen wollte von dem Board und Olimex ziemlich enttäuscht, darum wird das Wiki wohl noch länger leer bleiben. Gruß, Dominic
Achso, jetzt noch zum praktischen Teil. Die besten Erfahrungen hatte ich mit dem Upstream Kernel (z.B. 2.6.21.1) + Patch. Als Toolchain verwende ich eine arm-v4t-linux-gnueabi OSELAS.Toolchain mit GCC 4.1.2 von Pengutronix, für das Userland PTXdist, ebenfalls Pengutronix. GCC 4.2 wurde letzte Woche released, daher sollte es in naher Zukunft auch eine stabile OSELAS.Toolchain mit 4.2 geben. Dieser Kernel wird nicht mit Olimex' Redboot funktionieren, da der eine falsche machine ID übergibt (bei meinem Board war es die des EDB9302). Die Arbeit mit Embedded Linux sollte unbedingt unter einem Linux durchgeführt werden (bei mir aktuell (K)ubuntu Feisty Fawn - Cygwin würde prinzipiell auch funktionieren, allerdings ist da Ärger vorprogrammiert. Gruß, Dominic
Stefan Heindel wrote:
> Je mehr Dampf, desto besser.
Das ist ja mal ne super genaue Angabe, mit der jeder was anfangen kann.
Wie wärs einfach mal mit konkreten Zahlen ?
Was steht denn dazu im Pflichtenheft ?
Man muß bei jedem Projekt eine Abschätzung machen, wieviel Leistung man
wirklich braucht.
Wenn man aber aus reiner Bequemlichkeit nur sagt "viel", weiß man noch
lange nicht, obs reicht.
"viel" und "ausreichend" sind 2 völlig verschiedene Dinge.
Peter
Danke für die Infos. Dominic R. wrote: > Die Arbeit mit Embedded Linux sollte unbedingt unter einem Linux > durchgeführt werden (bei mir aktuell (K)ubuntu Feisty Fawn - Cygwin > würde prinzipiell auch funktionieren, allerdings ist da Ärger > vorprogrammiert. Muss es Linux sein, oder tut es auch ein anderes Unix (OS X)?
Erstaunlich, bisher wissen wir immer noch nicht wieviel Dampf der Poster braucht. Meines Erachtens gibt es zwei Wege. Der Weg der teueren Hardware, der teuren Software und der guenstige Weg. Zum teuren Weg gehoeren die Texas Floatingpoint DSPs, die Entwicklungsumgebung kostet von 4kEuro aufwaerts, plus die Hardware. Dann gibt's noch den 486 aufwaerts. Fuer ein Einzelstueck wuerde man einen PC nehmen. Software ist guenstig. Als Zwischending gibt's noch die PowerPC. Als Customloesung koennte man sich auch in grosses FPGA vorstellen, ein paar millionen Gatter, und dort einige FPUs drin. Dann sind fuer Eingearbeitete ein paar Monate weg, fuer Laien etwas mehr. Dort waeren die chips dann in 768 pin BGA aufwaerts. Also nicht brauchbar fuer den Poster.
Ich habe mal bei #ptxdist in freenode nachgefragt, und dort als Antwort bekommen, dass es einen Versuch wert sei, und dass es nicht unmöglich ist. Erfahrung mit OS X haben sie allerdings auch nicht. Prinzipiell sollte die Entwicklung mit allen Unix-ähnlichen Umgebungen möglich sein, und zumindest das Übersetzen von U-boot und Kernel lässt sich definitiv auch unter Cygwin oder OS-X bewerkstelligen, allerdings könntest du beim Übersetzen des Userlands über Probleme stolpern. Sofern nicht onehin installiert wirst du auf jeden Fall einen Teil der GNU Tools benötigen, mindestens GCC. Ptxdist übersetzt wohl einige Host-Tools während des Build Prozesses, und benötigt dazu einen native-GCC. Gruß, Dominic
Nachtrag aus #ptxdist: OS X könnte problematisch sein, weil es semi-casesensitiv ist, d.h. dass du zwar "test" und "Test" haben kannst, aber nicht beide gleichzeitig. Für die meisten Pakete, die darüber stolpern, sollte es aber Patches geben. Gruß, Dominic
OS X unterstützt auch voll case-sensitive Dateisysteme (UFS, demnächst ZFS), das sollte also kein Problem sein. Mir ging es nur darum ob vielleicht irgend welche Linux-Spezialitäten verwendet werden.
Hallo, der Grund, warum ich keine konkreten Zahlen genannt habe, war, dass ich eben keine konkreten Zahlen hatte, und auch keine Vorstellung davon hatte, wie rechenlastig die Anwendung wird. Inzwischen ist aber bekannt, dass man mindestens 10 MFLOPS braucht. Dies ist nur eine grobe Schätzung, wenn man mehr Rechenleistung zur Verfügung hätte, wäre natürlich besser, weil man dann auf der sicheren Seite wäre. Und wenn man in eine Prozessorfamilie investiert (Programmer, Toolchain, etc.) wäre es echt schlecht, wenn die Leistung dann doch nicht ausreicht und man in mühseliger Kleinarbeit den Code an allen Ecken und Enden zeitaufwendigst optimieren muss. Außerdem ist neben allen oben genannten Anforderungen noch die Forderung nach einer Code-Protection dazu gekommen. Also hätten wir: - Relativ preiswerte Entwicklungsumgebung - Rechenleistung >= 10 MFLOPS - Code-Protection (damit scheidet extern angebundener Flash schon aus!?) - Lötbar (wobei dies inzwischen fast das schwächste Kriterium von allen ist) Okay, bei einer Recherche habe ich folgende interesssante Prozessoren gefunden: SHARC (große Rechenleistung, aber kein Flash) TRICORE-Reihe von Infineon (TC1766 => Hat dazu jemand nähere Infos? Preise für den Compiler usw. habe ich nicht gefunden. Auch die eigentliche Rechenleistung war nicht explizit angegeben. Trotz allem ein vielversprechender Kandidat.) CIRRUS EP9302 (Problem mit ext. anzubindenden Flash und den damit verbundenen Code-Protection-Schwierigkeiten) TI TMS320xxxx (Gibt die entweder mit Flash ODER mit FPU :-( ) NXP LPC3180 (Der lt. Aussage des Freds nix kann :-( ) RENESAS SH7201 & 7203 (Kein Datenblatt gefunden. Hat jemand Infos über evtl. vorhandenes Flash oder generelle Informationen?) Ich bedanke mich erst einmal für die vielen Beiträge, und hoffe dass ihr auch noch weitere interessante Infos beisteuern könnt :o) Stefan
Meinst Du, daß mit einem 200Mhz-Prozessor 10 MFLOP/s erreichbar sein können? Das bedeutet, daß gerade mal 20 Takte für eine FLOP zur Verfügung stehen ... Und vermutlich soll der gute Prozessor auch noch irgendwas anderes machen. Könnte es sein, daß das Projekt ein bisschen "Wahnsinn" ist?
Die 10MFlops sind kein Problem, auch nicht bei 200MHz. Zum Problem wird die Schlussfolgerung, dass aus Sicherheitsgründen nur internes Flash verwendet werden soll. Denn Geräte dieser Leistungsklasse sind eher Prozessoren mit externem Speicher, selten vollintegrierte Controller. Oder sie sind DSPs.
Ich kann leider nicht beurteilen, ob das ganze realisieren ist oder nicht. Ich wurde beauftragt, geeignete Prozessoren zu finden, die die genannten Anforderungen erfüllen. Die Forderung nach dem internen Flash wurde so nicht direkt gestellt, sondern es wurde nur gesagt dass der Code halbwegs sicher gegen auslesen geschützt sein sollte. Daraus habe ich die Schlussfolgerung gezogen, dass ein externer (SPI) Speicherbaustein für den Code schlecht geeignet wäre, weil man dann ohne Probleme an den Code drankommen könnte.
Angehängte Dateien:
-
CS-EP9301.jpg
170 KB
Das Board gibt es jetzt für € 139,95 im Shop: http://shop.mikrocontroller.net/csc_article_details.php?saArticle[ID]=88
@Andreas: Ich hätte an dem Board Interesse, allerdings hätte ich gerne eine Angabe wieviel Gramm es auf die Wage bringt!
Was ist alles genau auf der CD-Drauf? Sind bei den Sourcen auch die entsprechenden Linkerscripte und makefiles dabei? Falls auf der CD nicht alles drauf ist um das Linux selber correct zu compilieren wirds für "Anfänger" gaanz schön schwer.... PS: könntest du die 2.6 Sourcen irgendwo uploaden, bzw. die dateien schicken die für die SD-Karte zuständig sind?
>Autor: Sven Johannes (svenj) >Datum: 21.05.2007 10:55 >vom NXP3180 kann man nur abraten! Aussage NXP Entwicklung..... >Das Ding ist wohl nur ein Testballon der für einen ganz kleinen Bereich >von Anwendungen ausgelegt ist. Q4/07 soll es (frühestens) einen 3188 >geben, der dann auch irgendwie einsetzbar ist. >Das Phytec-Board habe ich hier übrigens liegen, garnicht mal so >schlecht, wenn man denn den µC bebrauchen kann. Irgendwie widerspricht sich das. Kannst Du das mal konkretisieren? @ Stefan Heindel: TRICORE-Reihe von Infineon (TC1766 => Hat dazu jemand nähere Infos? Ja ;-) Abgekündigt, ebenso wie der TC1775. Bleibt zB das phycore TC1130 Board aus der Tricore Familie übrig. C Compiler zu bekommen ist schwer; gcc hat einen Port von HiTeX, die den Source nicht rausgeben wollen und so Geld verdienen möchten. Ansonsten Tasking und Greenhill Compiler -> Geld. Bleibt also nur assembler übrig, über den ich nichts sagen kann. Über die rechenperformance kann ich leider noch nichts aussagen. Grüße Olaf
Wie siehts mit RENESAS SH2A mit FPU aus. z.B. SH7201 QFP176 oder SH7203 QFP240 (480MIPS). Compiler gibt es von GNU oder Renesas (Bis 256k Code frei) Starterkits gibt es auch: www.renesas.com/rsk Evtl. ginge auch R32C die haben FPU und sind richtige MCUs mit embedded Flash!
Ich würde auf jeden Fall den SH7201 verwenden. Das Evauationboard kostet bei Glyn incl. E8-Emulator (der kostet normalerweise einzeln schon alleine 125 €) und Softwaretools lumpige 150€. Der µC leistet 288 MIPS bei 120MHz. Flashspeicher extern = 32 MBit, RAM = 128 MBit. Der µC ist bestückt mit jeder Menge Peripherie (CAN, ADC, DAC, ...). Ausserdem gibt es einen frei verfügbaren GNU-Compiler. Jeder Pin des µCs ist auf eine Pfostenleiste herausgeführt. Ich denke mal für deine Anwendung reicht das locker und du hast dann auch noch ein bisschen Reserve.
es kann auch mit dem SH2A 7211 funktionieren 320 MIPS aus dem internen Flash oder mann nimmt MPC55XX familie mit bis zu 3MB flas 132 MHz und FPU.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.