www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Daten an den PC schicken


Autor: Peter I. (Gast)
Datum:

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

Autor: A.K. (Gast)
Datum:

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

Autor: Peter I. (Gast)
Datum:

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

Autor: A.K. (Gast)
Datum:

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

Autor: Peter I. (Gast)
Datum:

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

Autor: Peter I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat niemand eine Möglichkeit schnell Daten an den PC zu senden?

Autor: JÜrgen Grieshofer (psicommand)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
USB 2.0 hat eine theoretische Übertragungsrate von 480Mbit/s od. 
100Mbit/s Ethernet.

Autor: JÜrgen Grieshofer (psicommand)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
USB 2.0 wenns sein muss auf einen FPGA packen...

http://www.opencores.org/projects.cgi/web/usb/overview

Autor: Stefan (Gast)
Datum:

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

Autor: A.K. (Gast)
Datum:

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

Autor: Peter I. (Gast)
Datum:

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

Autor: Christian (Gast)
Datum:

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

Autor: Peter I. (Gast)
Datum:

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

Autor: holger (Gast)
Datum:

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

Autor: Peter I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich verwende modifizierten Beispielcode für USB von 
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm...
Es wird gepuffert und am Ende der Messung per DMA im Hintergrund 
übertragen.

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.