Hallo zusammen,
wer kann mir bei der Auswahl eines µC oder DSP behilflich sein?
Meine Anforderungen sind eigentlich ganz überschaubar. Mindestens zwei
SPI-Schnittstellen, wenn möglich (aber nicht zwingend notwendig) zwei
CAN-Schnittstellen und das Ganze auf jeden Fall deutlich jenseits 100
MIPS, vermutlich eher > 200 MIPS.
Eigentlich nicht viel, leider lande ich hiermit gleich bei Controllern
und DSPs im 400-Pin BGA-Gehäuse (TC11xx, Blackfin, i.MX25x, ...), mit
massig anderer Peripherie und in der Größenordnung von 30-50 Euro.
Gibt es hier wirklich nichts schickes Kleines, z.B. in QFP oder QFN, für
moderates Geld und vielleicht sogar ohne 3000 Seiten
Bedienungsanleitung?
Sollte ich irgendwas übersehen haben, wäre ich über entsprechende
Hinweise dankbar.
Beste Grüße,
ControllerSuchender
Danke für den Tip. Die Propeller hatte ich mir schon angeschaut,
allerdings schreckt mich die Tatsache zurück, dass sie sich anscheinend
nicht in C programmieren lassen.
"Rechnen" im eigentlichen Sinne möchte ich gar nicht. Ich muss größere
Datenmengen von a nach b schaufeln und dabei auswerten, d.h. ich
benötige DMA für die Bedienung der SPI-Schnittstellen sowie viele
Vergleiche und relative Speicherzugriffe. Mathematische Operationen im
eigentlichen Sinne gibt es, von ein paar Additionen abgesehen, nicht.
Die besseren Propeller: XMOS.
Ist nicht direkt C, worin nach den Vorstellungen des Herstellers
programmiert werden soll, aber ähnlich. C/C++ gibt's jedoch auch.
Also wenn nicht gerechnet wird, bringt ein DSP nicht besonders viel.
Und wenn der Kram nicht parallelisierbar ist, bringen parallele
architekturen nichts. Wie kommst du denn auf 200MIPS ?
@ ControllerSuchender (Gast)
>"Rechnen" im eigentlichen Sinne möchte ich gar nicht. Ich muss größere>Datenmengen von a nach b schaufeln und dabei auswerten, d.h. ich>benötige DMA für die Bedienung der SPI-Schnittstellen sowie viele>Vergleiche und relative Speicherzugriffe. Mathematische Operationen im>eigentlichen Sinne gibt es, von ein paar Additionen abgesehen, nicht.
Klingt eher nach einem größeren CPLD oder kleinen FPGA. Das lächelt über
so ein paar MBits/s ;-)
MFG
Falk
Die Parallelität der Propeller und XMOS hat eher mit deren I/O-Struktur
zu tun. Diese Dinger habe wenig bis keine I/O-Module und arbeiten mit
Events statt Interrupts, statt dessen wird das per Software realisiert.
Eine SPI-Schnittstelle mit DMA belegt folglich einen Core für sich.
> ..allerdings schreckt mich die Tatsache zurück, dass sie sich anscheinend
nicht in C programmieren lassen.
KEIN Controller wird in C programmiert. Immer übersetzt ein C-Compiler
den Code in den Binärcode des Controllers.
A. K. schrieb:> Die Parallelität der Propeller und XMOS hat eher mit deren I/O-Struktur> zu tun.
Ist mir klar, aber die angabe von 160 MIPS beim Propeller bezieht sich
ja auf die volle Auslastung aller Kerne gleichzeitig.
Wenn der TE jetzt aber 200 MIPS +SPI und CAN will, dann geht das auf dem
Propeller nicht, wenn das Verarbeiten der Daten nicht parallelisierbar
ist.
Also SPI mit 200MHz getaktet hab ich noch nicht gesehen.
Und CAN geht nur bis 1MBit, das sind max 500kBit wirkliche Daten.
Sag einfach mal, womit sich die 200MIPS langweilen sollen.
Peter
@A.K.
Kannte ich noch nicht, schaue ich mir aber auf jeden Fall an. Danke für
den Tip.
@Hans Meyer
Die Aufgaben sind bedingt parallelisierbar, da es viele gleichartige
Operationen auf unterschiedliche Daten gibt.
Bislang haben wir ein paar Versuche auf einem 150MHz Tricore gemacht,
aber hier ist die Ausführungszeit bereit grenzwertig. Zudem handelt es
sich um einen BGA416 und die Verfügbarkeit bei gängigen Distris ist auch
nicht berauschend.
@Falk:
Du sagst es. Leider kommen noch Aufgaben hinzu, die ich nicht in Logik
abbilden müssen möchte. Insofern wäre das Optimum wahrscheinlich ein
FPGA mit einer Mischung aus SoftCore und Logikteil. Leider fehlt uns
hier das KnowHow und zudem auch die Zeit.
@bensch:
Bitte entschuldige meine vereinfachte Formulierung. Aber ich denke es
hat trotzdem jeder verstanden, was gemeint war.
@Peter:
Die zu verarbeitende Nettodatenrate liegt bei 6-8MBit, verteilt auf zwei
SPI-Kanäle. Das sollte also darstellbar sein. ;-)
Über CAN wird dann natürlich nur ein Konzentrat übertragen.
Hans Mayer schrieb:> Wenn der TE jetzt aber 200 MIPS +SPI und CAN will, dann geht das auf dem> Propeller nicht, wenn das Verarbeiten der Daten nicht parallelisierbar> ist.
Wobei sich die Frage stellt, worauf sich die MIPS-Angabe bezieht. Ein
klassischer Controller hat meist einen Rattenschwanz an Interrupts zu
bewältigen, was bei diesen Architekturen entfällt.
Aber hier dürfte XMOS interessanter sein, und da sind schon beim kleinen
Modell die 400 MIPS aufgeteilt auf 4-8 Threads möglicherweise fix genug.
ControllerSuchender schrieb:> Die zu verarbeitende Nettodatenrate liegt bei 6-8MBit, verteilt auf zwei> SPI-Kanäle. Das sollte also darstellbar sein. ;-)
Das sind dann also alle 4µs ein neues Dword.
Ein 32-Bitter mit 50MHz hat dann 200 Zyklen Zeit, klingt machbar.
Vielleicht muß man sich den Assembleroutput angucken, wo der Compiler
umständliche Sachen macht.
Ich würds mit nem Cortex M3 versuchen (ST, TI).
Peter
@ ControllerSuchender (Gast)
>Du sagst es. Leider kommen noch Aufgaben hinzu, die ich nicht in Logik>abbilden müssen möchte. Insofern wäre das Optimum wahrscheinlich ein>FPGA mit einer Mischung aus SoftCore und Logikteil.
Könnte sein.
>Leider fehlt uns hier das KnowHow und zudem auch die Zeit.
Dann werdet ihr das wohl mit ziemlich viel Overkill bezüglich
Prozessiorleistung und Software kompensieren müssen. Hmmm.
>Die zu verarbeitende Nettodatenrate liegt bei 6-8MBit, verteilt auf zwei>SPI-Kanäle. Das sollte also darstellbar sein. ;-)
Und dafür baucht man 200 MIPS? 8 Mbit/s sind 1MByte/s. Mit
Zwischenspeichern, DMA & Co ergibt sich vielleicht 3-5MBytes/s. OK, da
schnauft ein kleiner 32 Bit Prozesor schon ein wenig, aber das sollte
mit einem 50-100 MHz ARM, so er denn gescheite Perepherie hat, machbar
sein.
MfG
Falk
> Dann werdet ihr das wohl mit ziemlich viel Overkill bezüglich> Prozessiorleistung und Software kompensieren müssen. Hmmm.
Sieht leider so aus.
Es handelt sich aber nur um einen ersten Entwicklungsschritt, später ist
ohnehin ein Logik-basierte Lösung angedacht.
> Und dafür baucht man 200 MIPS?
200MIPS sind nicht unbedingt notwendig, es wäre aber schön, etwas
Reserve zu haben. Sollte der Controller nicht von Vorneherein ein
Flaschenhals sein besteht zudem die Möglichkeit, die Datenrate nochmal
deutlich zu Steigern.
Momentan kommen wir mit dem Tricore schon hin, allerdings wäre ein
Controller mit anderem Package und besserer Verfügbarkeit wünschenswert.
@ ControllerSuchender (Gast)
>Es handelt sich aber nur um einen ersten Entwicklungsschritt, später ist>ohnehin ein Logik-basierte Lösung angedacht.
Hä? Und was soll das? Da jetzt tierisch Energie reinzustecken um es
hinterher richtig zum machen ist reichlich sinnlos.
>Momentan kommen wir mit dem Tricore schon hin, allerdings wäre ein>Controller mit anderem Package und besserer Verfügbarkeit wünschenswert.
Dann bleibt beim Tricore oder macht es gleich richtig. Alles andere ist
Murks.
MFG
Falk
>> MitZwischenspeichern, DMA & Co ergibt sich vielleicht 3-5MBytes/s. OK, da>> schnauft ein kleiner 32 Bit Prozesor schon ein wenig, aber das sollte>> mit einem 50-100 MHz ARM, so er denn gescheite Perepherie hat, machbar>> sein.
Korrekt! Mein kleiner At32UCA1512 schafft das ohne den Core merklich zu
belasten, solange es ab und zu mal eine Pause gibt, um die Daten
woanders hinzuschieben. Wenn wirklich kontnuierlich 3-5MB/sec ankommen,
ist ein FPGA die bessere Wahl, weil man eben nicht auf den
Speicherbereich zugreifen sollte, den der DMA gerade bearbeitet.
Vieleicht klappt es, wenn man mit zwei Puffern arbeitet, habe ich nicht
probiert.
Renesas SH7203 hat 2xCAN; SH7286 nur 1x und SH7211 keine.
Aber alle Typen haben einen externen Bus, an den man beliebige
CAN-Controller anschließen kann. Das kann dann ganz zweckmäßig sein,
wenn man dafür schon die C-Quelle hat.
Eventuell wäre ja auch ein S12XE interessant. Mehrfach CAN und SPI sind
vorhanden, der XGATE Coprozessor schafft maximal 100 MIPS die S12XCPU 50
MIPS. Sowohl der S12XCPU Kern als auch der XGATE lassen sich in C
programmieren, allerdings ist der Codewarrior nicht ganz billig aber
vllt. reicht ja auch die Light-Version.
Jörg
ein ARM9 wäre sicher auch interressat für dich AT91SAM9263. Hat alles
was du brauchst und den SPI kannst du auch mit bis zu 100 MHz betreiben
lassen. Ebenso besitzt er DMA. Brauchst nur externen Speicher noch
anklemmen, da der intere sicher nicht ausreicht.
