www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ARM - Schneller µC mit Floating Point gesucht


Autor: Stefan Heindel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Ale (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. Vie viele FLOPS brauchs du ?
    1.2 Geht mit soft ?

2. Samsung hat gute uC ARM basiert.

3. Hilft vielleicht ein DSP ?

Gruß

Autor: Ale (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt bei Freescale tolles uC ColdFire mit TQFP gehäuse bis etwa 100 MHz, 
nicht schlecht.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
EP9302 (http://olimex.com/dev/cs-e930x.html). Hat 200 Pins.

Aber du solltest schon ungefähr wissen, WIE schnell du rechnen musst.

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVR32 hat doch keine FPU?

Autor: DiScha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas Schwarz
Frage: wird es das genannte Board mit dem EP9302 auch im Shop geben?
Wenn ja, wann und zu welchem Preis?

Gruß Dieter

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Interesse besteht, gerne. Preis wäre so ca. 160 Euro inkl. MwSt.

Autor: Stefan Heindel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: DiScha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Thomas S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Sven Johannes (svenj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Berti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Netsilicon NS9750

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)?

Autor: Null (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Heindel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Heindel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:
Angehängte Dateien:

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

Autor: Ulrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas:
Ich hätte an dem Board Interesse, allerdings hätte ich gerne eine Angabe 
wieviel Gramm es auf die Wage bringt!

Autor: Ulrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Slawc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Besucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Tron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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