Hallo! Ich hoffe ihr könnt mir helfen: Ich arbeite an einem Uni-Projekt. Dabei soll ein 16Bit SPI-Befehl an die Messvorrichtung geschickt, dann ein Signal mit >12Bit abgetastet und dieses schließlich an den PC gesendet werden. Bislang wird ein At91SAM7S verwendet, welcher jedoch für eine geplante Erweiterung zu langsam ist. wir suchen also die schnellstmögliche Lösung für dieses Problem. Welcher Controller hat schnellere Schnittstellen zum PC?
> wir suchen also die schnellstmögliche Lösung für dieses Problem Völlig falsche Frage. Vorne steht immer die Überlegung "wie schnell muss es sein". Dann suchen. Der schnelleste Controller mit Anbindung an PCs ist eine PCI-Karte im PC. Sowas gibt es mit Microcontroller und/oder FPGA. > Welcher Controller hat schnellere Schnittstellen zum PC? Jeder mit Ethernet-Controller drauf.
Möglichst schnell ist nicht falsch da die Prozessgeschwindigkeit von der Messung ausgebremst wird. Also suchen wir was möglichst schnelles. wie viele Daten kann man per Ethernet effektiv an den PC senden? Oder konkreter: Wieviele Byte/s schafft z.B. ein AT91SAM7X? Bevor wieder NXP - Werbung kommt: Die Dinger haben eine viel zu langsame SPI Schnittstelle (max 1/8 MCK) und sind daher nicht geeignet.
Die Messung ist also unendlich schnell, nur ausgebremst von der Transferrate? Oder ergibt sich aus der Messung eine maximal sinnvolle Transferrate? Keine Sorge, Robert wurde (leider) schon rausgeekelt. Und neuere NXPs haben eine schnellere SPI-Schnittstelle (zusätzlich zu den alten SPIs, heisst auch anders).
ok... beim LPC2368 siehts schon viel besser mit dem SPI (SSP) aus. Wenns den früher gegeben hätte wäre er eine Überlegung wert gewesen. Die Messung ist zwar nicht unendlich schnell, aber wir können das vorhandene Messmodul mit einem 40MSPS ADC (war gerade am Institut vorhanden) auch gegen ein noch schnelleres austauschen. Ein Messzyklus besteht aus dem Senden eines 16Bit Wertes per SPI an einen DDS (maximal möglich wären 40MHz SPI Takt, der AT91SAM7 schafft 24Mhz) und das darauffolgende einlesen des Messwertes vom ADC. Dies schafft er aktuell in 2.5μS pro Messwert. Momentan werden noch 1024 Messwerte im RAM zwischengespeichert und dann übertragen, da ein direktes verschicken der Messwerte über USB zu viel gebremst hat.
USB 2.0 hat eine theoretische Übertragungsrate von 480Mbit/s od. 100Mbit/s Ethernet.
USB 2.0 wenns sein muss auf einen FPGA packen... http://www.opencores.org/projects.cgi/web/usb/overview
Ich verstehe nicht, wieso die Lösung noch nicht bekannt ist bzw. wo das Bottleneck ist. "Der AT91SAM7 schafft 24 MHz von den 40 MHz möglichen über SPI... beim LPC2368 siehts schon viel besser mit dem SPI (SSP) aus. Wenn's den früher gegeben hätte, wäre er eine Überlegung wert gewesen..." Ist das Auslösen der Messung das Bottleneck, d.h. kannst du nicht oft genug den Befehl zum Messen geben? Den AT91SAM7 musst du dann rauswerfen. Warum dann nicht den LPC2368 verwenden, wenn der ein schnelleres SPI zulässt? "Momentan werden noch 1024 Messwerte im RAM zwischengespeichert und dann übertragen, da ein direktes verschicken der Messwerte über USB zu viel gebremst hat." Ist das Übertragen der Messwerte ggf. mit Ausbremsen der SPI durch das Übertragen das Bottleneck? Schon überlegt einen zweiten µC nur dafür einzusetzen? Die Netto-Datenrate von ~800 KB/s (2Byte/2.5µs) läge im mittleren USB Full Speed Bereich. Mehr ginge noch mit USB High Speed. Sind die Übertragungsroutinen µC und PC seitig bereits optimiert?
2,5µs pro 16bit sind etwas unter 1MB/sec. USB1.1 oder 10Mbps Ethernet sind dafür zwar grad noch drin, aber zu knapp wenn man sich noch ein bischen Luft lassen will. Bleiben also USB2.0 Highspeed oder 100Mbps Ethernet. Bei USB gilt es darauf zu achten, dass zwar viele Controller ein sogenanntes "USB 2.0" beherrschen, aber nur wenige davon im Highspeed-Modus. Ethernet scheint mir da noch verbreiteter zu sein, teils intern (z.B. Atmel SAM7X), teils extern via Bus (z.B. DM9000).
Das Problem ist die daten Wegzuschaffen. Das mit den 24Mhz SPI geht eigendlich gut, 8Mhz wie es die aktuell erhältlichen NXP ARM schaffen ist aber zu wenig. Die kleinen ARM haben laut meinen Informationen eigendlich alle nur Full Speed. Eine Optimierung der Geschwindigkeit wäre zwar schön, ich weis aber leider nicht wie. Gibt es irgendwo ein Projekt welches die maximale USB Geschwindigkeit einen At91Sam7 ausnutzt?
Moin, du (also der Themenstarter) willst also eine Echtzeitmesswertauswertung aufziehen? Verstehe ich das richtig ? Oder könntest du evtl. noch mehr Daten auf dem µC puffern ? Weiterhin: Sollen die zum PC gesendeten Daten in einer Windowsapplikation verarbeitet werden? (das würde dann den Vorgang ausbremsen, vor allem falls die Messswerte grafisch dargestellt werden sollen)... Gruß Christian
Die Daten werden an Matlab gesendet und dort analysiert. bislang speichere ich 1024 messwerte im Mikrocontroller (4096 geht auch noch) und schicke sie dann über USB zum PC (per DMA). Ich möchte nun die Sendegeschwindigkeit deutlich erhöhen, habe dazu aber nichts brauchbares gefunden, wie man die maximal mögliche Bitrate des USB-Controllers im At91SAM7 erreichen kann. Momentan schaffe ich ca. 250kBit/s effektiv. Das muss doch deutlich schneller gehen...
Ich kann 100 FPS mit einem ATMEga128 (16MHz) und einem FTDI FT245BM auf ein T6963 Display mit 240x64 Pixel ausgeben. Also knapp 2kB pro Displayinhalt. 2kB * 100 = 200 kB/s. Mit einem PIC18F2550 ca 100kB/s. Nicht Kilobit/s ! Es sind Kilobyte/s. Du machst grundsätzlich etwas falsch. Mein Tip: Nicht jedes Byte einzeln abschicken. Puffern, puffern, puffern.
Ich verwende modifizierten Beispielcode für USB von http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index.html#at91examples Es wird gepuffert und am Ende der Messung per DMA im Hintergrund übertragen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.