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.

AVR32 hat doch keine FPU?

@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

Netsilicon NS9750

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

Das Board gibt es jetzt für € 139,95 im Shop:
http://shop.mikrocontroller.net/csc_article_detail...

@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

Hi!

What about TMS320F28335

http://focus.ti.com/docs/prod/folders/print/tms320...

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.