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
Hallo, Schau dir mal den an: http://en.wikipedia.org/wiki/Parallax_Propeller Und erklär mal genauer, was du rechnen möchtest. Grüße
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.
Also ich denke auch hier ist ein PIC32 ein passendes Gefährt. 80MIPS, handliches Package (TQFP), CAN an board :)
Ich werf da einfach mal meinen derzeitigen Liebling dem STM32 in die Runde, zumal der Einstieg durch gute Firmware-Lib sehr erleichtert wird. http://www.mikrocontroller.net/articles/STM32 Gruß Tom
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.