mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Suche schnellen und einfachen µC oder DSP


Autor: ControllerSuchender (Gast)
Datum:

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

Autor: Hans Mayer (hansilein)
Datum:

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

Autor: ControllerSuchender (Gast)
Datum:

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

Autor: A. K. (prx)
Datum:

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

Autor: Hans Mayer (hansilein)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: A. K. (prx)
Datum:

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

Autor: bensch (Gast)
Datum:

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

Autor: Hans Mayer (hansilein)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: ControllerSuchender (Gast)
Datum:

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

Autor: A. K. (prx)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: stephan_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dsPIC30... dsPIC33... PIC32...

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein AVR32UC3 waere moeglicherweise auch passend.

Autor: ControllerSuchender (Gast)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: Track (Gast)
Datum:

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

Autor: Tropenhitze (Gast)
Datum:

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

Autor: Joerg Wolfram (joergwolfram)
Datum:

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

Autor: Stefan Kunz (Gast)
Datum:

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

Autor: Michael H. (morph1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich denke auch hier ist ein PIC32 ein passendes Gefährt. 80MIPS, 
handliches Package (TQFP), CAN an board :)

Autor: ichnicht (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau dir doch doch mal die C2000 Serie von TI an
stichwort TMS320F28335 oder sowas in der Art

Autor: Escamoteur (Gast)
Datum:

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

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.