µC gesucht mit Ext.Mem.Int, USB, DMA

Soweit ich erkennen kann lassen sich per Fullspeed USB sowieso nur 64 
Byte pro Frame übertragen, isochron 1KB. Insofern dürfte die Grösse des 
USB-RAMs nicht der entscheidende Aspekt sein und es sollten genug 
Möglichkeiten bestehen, die Daten rechtzeitig ins normale RAM zu 
verlagern.

Controller mit mindestens 32KB RAM, externem Speicherinterface und USB 
gibt es jedenfalls einige. In den STM32F103/105 Reihen beispielsweise.

Jörg schrieb:

> reicht mir ein 70MHz Prozessor wenn über USB eine Datenrate von 8MBit/s
> zu erwarten ist?

Nö. Mit diesem ganzen Zirkus drum herum und vermutlich streng synchronem 
pausenfreiem Bus nicht. Da klingt das für mich eher nach FPGA. Eventuell 
geht es aber auch mit XMOS.

Hab's nicht probiert, aber 12Mb/s = 1,5MB/s = 0,4MW/s traue ich dem 
Controller schon zu, immerhin muss der Prozessor die normalerweise nicht 
Bit für Bit einzeln verarbeiten. Erst zusammen mit der Bitpflückerei 
wird das zum Thema.

Hallo Jörg,

über den Daumen könnte da die Leistung der AVR32UC3 von Atmel reichen. 
Da gibt es Typen mit USB-Hardware und externem Speicherinterface.

Gruß, DetlevT

Detlev T. schrieb:

> über den Daumen könnte da die Leistung der AVR32UC3 von Atmel reichen.
> Da gibt es Typen mit USB-Hardware und externem Speicherinterface.

Ob ein 66MHz AVR32 wirklich so viel schneller ist als ein 100MHz 
Cortex-M3 (LPC1700)? Weder USB noch Bus sind hier m.E. das zentrale 
Problem, sondern das Bitgepfriemel frisst die Leistung. Die 
USB-Interrupts und Blocktransfers kommen da nur noch oben drauf.

Was mit weiterhin zu unklar ist um es abschätzen zu können: die externen 
Buszyklen. Müssen die exakt alle 1µs ablaufen, komplett ohne erlaubtem 
Jitter? Das schafft ohne externe Synchronisation nicht einmal DMA. Wie 
hast du das in der bisherigen Lösung gemacht?

Wenn ein Jitter von ein paar Takten zulässig ist, dann ist ein 
Bustransfer über Timer-getriggertes DMA wohl auch kein Problem und 
frisst kaum Zeit.

Ist das externe nun wirklich ein Bus, oder sind das bloss 16 Leitungen 
und du hast bisher einen Bus verendet? DMA direkt auf den Port gibt's ja 
auch.

Interrupts sollten dann auch kein Problem sein, solange die Gesamtlast 
noch verdaut wird. Das darf natürlich keine Just-in-Time Produktion 
werden, sondern es müssen genug umgepfriemelte Daten für den DMA auf 
Halde liegen, um sich auch ab und zu mal um den USB Interrupt kümmern zu 
können.

Also nochmal von vorne, so wie ich den Kram verstanden habe:

(1) Alle Millisekunde kommen 9KB Daten über USB rein.

(2) Zwischen (1) und (3) sitzt jemand, der deine 9KB vom Kopf auf die 
Füsse stellt, indem er die Bits im Speicher neu sortiert.

(3) Alle Mikrosekunde werden 16 Bit parallel irgendwo ausgegeben, egal 
ob Bus oder Port. Die Daten kommen aus einem 9KB Puffer im RAM.

Deinen Interrupt alle Mikrosekunde sehe ich hier nicht. Sondern einen 
DMA-Kanal, der in für ihn gemächlichem Mikrosekundenraster 
umgepfriemelte Daten aus dem Speicher rausschaufelt.

Rechenzeit entsteht in (1) und (2). In (1) weil das USB per Interrupt 
bedient werden will um die eingelaufenen Daten abzufischen bevor das 
USB-RAM überläuft. Hauptschleife macht (2) und sorgt dafür, dass dem DMA 
die Daten nicht ausgehen.

RAM-Bedarf: 3 Puffer zu je 9KB. Einer läuft grad rein, einer wird 
verwurstet, einer läuft grad raus. Vielleicht geht auch weniger als 9KB 
pro Puffer.

Jörg schrieb:

> Den USB-Transfer werd ich Isochron machen,

Wenn du schon über die Quelle keine Kontrolle hast, dann darüber wohl 
auch nicht. Zumal du m.W. diese Datenrate mit Fullspeed nur isochron 
schaffst.

> Muss dieser Transfer immer wieder von mir persönlich losgetreten werden
> (wahrscheinlich gibt es einen DMA-Timer-Interrupt)?

Wie schon angedeutet kann jeder einzelne DMA-Transferzyklus- eines 
16-Bit Wortes automatisch per Timer-Event losgetreten werden. DMA-Quelle 
ist Speicher, inkrementierend, DMA-Ziel kann ein Port sein, kann 
externer Speicher sein, inkrementierend oder nicht. Wenn das mal 
eigerichtet ist, dann läuft das die ganzen 9KB autark durch, ohne 
Beteiligung der CPU.

> Also ein Interrupt der die DMA veranlässt die 16bit
> Daten rauszuschieben...

Begriffsproblem? Der Begriff "Interrupt" steht gemeinhin für eine 
Unterbrechung des Prozessors. Die gibt's hier nicht. Nur alle 
Mikrosekunde ein für einen Takt vom DMA blockiertes RAM.

> Dieser Transfer
> passiert ja ohne das der Prozessor etwas mitbekommt.

Ja.

> Position A+16Bits befinden?? Kann man hier bei der Init der DMA einen
> Bereich angeben der nacheinander abgefrühstückt werden soll?

Genau das ist DMA.

> Des Weiteren würd ich mal vermuten das ein DMA Transfer für den
> ankommenden USB Stream sinnvoll sein wird, um Leistung einzusparen vom
> Prozessor.

Je nach Implementierung des USB-Moduls. Ich habe mal kurz bei dem vom 
STM32 reingesehen. Da landen die Daten in einem internen 
Dual-Port-Memory aus dem der USB-Interrupt sie rausholen muss. Diesen 
Transfer kriegt die CPU schneller zustande als der DMA-Controller.

A. K. schrieb:
> Ob ein 66MHz AVR32 wirklich so viel schneller ist als ein 100MHz
> Cortex-M3 (LPC1700)? Weder USB noch Bus sind hier m.E. das zentrale
> Problem, sondern das Bitgepfriemel frisst die Leistung. Die
> USB-Interrupts und Blocktransfers kommen da nur noch oben drauf.

Sehe ich auch so. Ein 16-Bit Päckchen braucht 32 Shift-Befehle, die 
jeweils einen Takt brauchen. Bei 66MHz wäre der Controller damit also 
etwa zur Hälfte ausgelastet. Vielleicht noch 20% Rechenleistung für die 
Schleife. Bleiben 30% für die Reaktion auf den USB-Interrupt und die 
Programmierung des DMA, der die bereits behandelten Daten rausspeichert. 
Käme auf einen (Simulations-) Versuch an, ob man mit der Zeit auskommt. 
Ich halte das aber für möglich.

Jörg schrieb:

> Ist es eigentlich ratsam bei USB ein O/S einzusetzen?

Nein, das denke ich nicht.

> Oder ist es
> schneller wenn mann vom jeweiligen Chiphersteller den Source bekommt für
> die USB-Treiber Implementierung?

Ebendies. ST hat Code für den USB-Support. Inwieweit der hier direkt 
geeignet ist oder etwas umgebaut werden muss weiss ich nicht. Das wird 
bei Atmel, NXP und TI nicht anders sein.

PS: Wenn ich hier STM32 erwähne, dann weil ich die besser kenne als die 
LCP1700. Prinzipielle Unterschiede in der Vorgehensweise dürfte es dabei 
nicht geben, vielleicht arbeitet NXP beim USB etwas anders, aber das 
ändert wenig am Arbeitsprinzip insgesamt. Die 100MHz eines LPC1700 
könnten jedoch nützlich sein.

Detlev T. schrieb:

> Sehe ich auch so. Ein 16-Bit Päckchen braucht 32 Shift-Befehle, die
> jeweils einen Takt brauchen.

Bischen mehr ist es, denn die Daten kommen aus Speicher und müssen 
wieder in Speicher zurück. Wahrscheinlich lässt sich das zeitsparend mit 
dem Transfer der Daten aus dem USB-RAM verbinden, womit auch noch einer 
der 3 Puffer entfällt. Dann liegt der Hauptteil der CPU-Last im 
USB-Interrupt.

Entscheidend ist also, ob ein Controller diese Last schafft. Die 
DMA-gesteuerte Ausgabe ist für die Abschätzung dagegen kaum relevant.

Jörg schrieb:

>>(2) Irgendwo zwischen (1) und (3) sitzt jemand, der deine 9KB vom Kopf
>>auf die Füsse stellt, indem er die Bits im Speicher neu sortiert.
>
> richtig, ein Controller (welcher muss noch gefunden werden);

Ich rieche da ein mögliches Missverständnis. Mit 1-3 waren Abläufe im zu 
findenden Controller gemeint und mit dem "sitzt jemand" ein Stück 
Programm.

@Jörg: An deiner Stelle würde ich einen nehmen, die man kaufen kann.

Abgesehen von der Frage zur USB-Performance dürfte die Bitschubserei 
erst mit mindestens 17 freien Registern optimal arbeiten. Was ARMs und 
AVR32 schlechter stellt als beispielsweise MIPS oder PowerPC.

Jörg schrieb:

> welche unterschiede sind das die du bezüglich der PowerPCs ansprichst?

Vielleicht habe ich die Bitschubserei auch nicht richtig verstanden. 
Aber was bei mir rüberkam sind 16 Register als Datenquelle und eines als 
Ziel. Die 16 werden nacheinander geschoben und nach jeder solchen Aktion 
wird das rausgeschobene Bit ins Zielregister reingeschoben. Ergibt an 
Registern 16 für rein, 1 für raus, 2 für Adressen als Minimum.

Nun haben AVR32 und ARM aber nur 16 Register, davon 13 frei verwendbar. 
MIPS und PowerPC haben insgesamt 32 Register. Ich habe nur nicht parat, 
ob die den dafür nötigen rotate-with-carry/add-with-carry Befehl kennen.

Der Thumb-Mode bringt nichts.

Karl schrieb:

> Compileroptimierung. Zum Debuggen wollte ich eigentlich -O0, aber damit
> hat dann kein USB funktioniert. Schlussendlich bin ich bei -O2 gelandet.

Das ist klar, der Unterschied ist gewaltig. Dazu kommt evtl. noch die 
Platzierung, denn die SAM7 können mangels Flash-Bandbreite nativen ARM 
Code nicht ungebremst im Flash ausführen, sondern müssen auf RAM 
ausweichen.

Hier könnte zwar nicht Thumb, wohl aber Cortex mit gegenüber ARM7 oder 
ARM9 erheblich kleinerem Interrupt-Overhead punkten, jedenfalls bei IRQ 
in C und nicht FIQ in Assembler.

Wenn die einzelnen Interrupts eher kurz sind (ist das der Fall gewesen?) 
und man sowas auf ARM7/9 macht, dann könnte das ein Fall für FIQ in 
Assembler sein.

Jörg schrieb:

> was wird hier alles optimiert gegenüber dem -00?

Bei -O0 liegen beispielsweise alle Parameter und Variablen im RAM statt 
in Registern, sie werden bei jeder Verwendung erneut geladen und/oder 
gespeichert. Allein dieser Unterschied ist exorbitant.

Es gibt noch jede Menge mehr Optimierungen unterschiedlicher Bedeutung.

A. K. schrieb:

> MIPS und PowerPC haben insgesamt 32 Register. Ich habe nur nicht parat,
> ob die den dafür nötigen rotate-with-carry/add-with-carry Befehl kennen.

Hab mal nachgesehen. MIPS hat nicht, PowerPC hat.