Digital-Signal mit PC einlesen

=20

USB ist gar nicht so schwer, wenn man nicht das Rad komplett neu erfindet: Es gibt einige g=FCnstige uC mit integriertem USB Interface. Die meisten k=F6nnen isochrone Transfers was bei einer solchen Datenrate g=FCnstig ist. Softwareseitig ist es unter Windows nicht ganz so einfach wie f=FCr Linux oder FreeBSD. Unter den *nix Systemen steht mit der libusb eine (relativ) einfach zu verwendende Zwischenschicht zur Verf=FCgung, dank der man auf USB zugreifen kann, ohne einen Treiber schreiben zu m=FCssen.

Wolfgang Draxinger

--=20

Das klingt doch schon ganz gut, dann werd ich mich in die Richtung auf die Suche begeben.

BSD'ler sind überall :) Wollte das ganze auch auf einem FBSD-System zum laufen bringen.

Ich glaube, dass ich irgendwo einen libusb-Port für Win gesehen habe.

Vielen Dank dafür & Gruß, Peter

Wenns noch einfacher sein darf nimmt man einen FT245BM und einen zusätzlichen µC der ein bischen zwischenpuffert. Dann muß man sich weder auf Host- noch auf Clientseite um den USB kümmern sondern öffnet eine serielle Schnittstelle und empfängt die Daten am PC. Auf Clientseite muß man nur mit ein paar Ports wackeln. Datendurchsatz unter Windows liegt bei etwa 800kByte/s.

Hallo Peter,

| Meine Signalbreite beträgt 160 KBit/Sekunde. Die serielle Schnittstelle | des PC wird mir aber nur mit max. 128 KBit/s angegeben. | | Die parallele (IEEE 1284) habe ich als max. 150 KBit/s identifiziert,

ich weiss ja nicht, wo Du das her hast, zu DOS Zeiten mit nem 486DX33 hab ich ganz ohne EPP und Co einfach so mit Bits über Port setzten und abholen problemlos im µs Bereich gearbeitet. IMHO sitzen die am ISA-Bus ziemlich direkt dran, deswegen will man die ja auch nicht mehr mit dazubauen, und wenn, dann teilweise schon am USB, womit dann die ganze Bitbangerei nicht mehr so schnell geht :-( | Dann gibt es da noch USB. Suche ich allerdings nach Informationen zu | USB, finde ich oft hinweise, dass die Programmierung dafür ziemlich | schrecklich sein soll...

USB ist toll, wenn das Signal gleichmäßig eintrudelt. Wenn Du aber ein Ereignis feststellen willst, dann nur mit ca 1 ms Genauigkeit, schneller is nich :-(

Martin

Martin Schönegg schrieb:

Das Schlagwort ist dabei DOS. Sobald ein OS verwendet wird das nicht Echtzeitfähig ist kann man dieses Unterfangen vergessen.

Es geht. Es muß eben nur etwas Intelligenz am anderen Ende sitzen und die eintrudelnden Daten in ein Protokoll verpackt.

"Peter Willer" schrieb im Newsbeitrag news:d777qj$1mhr$ snipped-for-privacy@ulysses.news.tiscali.de...

Hallo Peter,

daß da noch irgendwie etwas "Anderes" zwischen deinem Datenstrom und z.B. der USB-Schnittstelle stecken muß haben die anderen jetzt ausführlich diskutiert.

Ich hätte da noch zwei wichtige Fragen.

Was sind 160kBit/s Signalbandbreite? Meintest du Bitrate?

Wie hast du die ausgerechnet? Darin steckt auch die Frage wer sendet die Daten, z.B. ADC? oder Signal auf einem digitalen Bus). Wenn die Bits asynchron einlaufen, dann muß eventuell mit wesentlich höherer Datenrate abgetastet werden.

Gruß Helmut

Jou, das klingt noch besser. Nur - entschuldige meine Unwissenheit - der FT245BM arbeitet mit max. 1 MByte/s bzw. 300 KByte/s und ich frage mich, wofür ich dann einen Puffer brauche? Evtl. damit die Bits so ankommen, wie es der FT... benötigt? Was kann man denn da empfehlen?

Kurz nocheinmal zur Info: Ich bin ein ganz "böser" Neuling auf dem Gebiet.

Vielen Dank & Gruß, Peter

Peter Willer schrieb:

Kommt drauf an wie die Daten eintrudeln. Sind sie schon richtig schön aufbereitet mit synchronem Übernahmesignal kann man da auch was ohne Puffer basteln.

Ich würde aber generell einen µC zwischen FT245BM und Datenquelle schalten dann kann man die Daten auch noch ein bischen umformatieren oder passend verpacken.

Wie sowas aussehen kann, kannst du dir ja mal auf meine HP -> USBisp anschauen. Das ist im Prinzip nichts anderes als ein FT245BM mit µC der eine Protokollumsetzung macht.

Am Fri, 27 May 2005 15:39:03 +0200 schrieb Peter Willer :

Entweder max. 115,2kbit/s oder heute oft max. 230,4kbit/s

Habe ich am 486er schon mit >300kHz abgefragt. Unter DOS in einer kurzen Pascal Schleife, aber ohne definiertes Timing, also Interrupts haben verzögerung gebracht. Heute kannst du da meist mit 1MByte/s einlesen - EPP/ECP Modi.

Zur Not ein Schieberegister an der Parallelen, dann hast du lächerliche