8 Sensoren mit PC verbinden?

[Marte Schwarz]

Hallo Johannes,

Zeitwerte liegen im Hundertstelsekundenbereich und sollten doch mind. 2
geltende Ziffern haben.

Dann vergiss alles, was Du im LowCost Bereich an USB bekommst. Nur was auf
dem USB-Zielsystem eine eigene Uhr mitführt kann Deine Anforderungen
erfüllen. Unter Windoof und weitgehend unter Linux eigentlich auch fast
alles. Diese Systeme haben keine Echtzeitfähigkeit, selbst wenn die Hardware
schnell genug abgefragt werden könnte (mit USB is nich) - wenn das System
gerade mit was anderem beschäftigt ist, wirst Du das Event nicht
mitbekommen, oder erst dann, wenn der Systemtask wieder nach Deinem Ereignis
fragt.
Um 0.1 ms aufzulösen brauchst Du einen eigenen Prozessor mit eigener Uhr,
die das Ereichnis dann mit einem Zeitstempel versehen an den PC
weiterreicht. Das sollte mit einem ľC nicht wirklich aufwändig sein, will
aber eben gemacht sein.

Marte

 

[Johannes Permoser]

Bjoern Schrader wrote:

Meld dich mal hier, wenn du Ergebnisse hast. Das würde mich wirklich
interessieren, wie die erreichbaren Werte aussehen.

Hab heute mal ein bisschen mit VC++ und meinem Gamepad rumprobiert udn
festgestellt, dass es doch zeimlich ungeeignet ist

Die kleinsten auf - zu - auf Zyklen die ich messen konnte dauerten 16,
31 und 47 Hundertstel => für mich ungeeignet, für andere Sachen sicher
lustig, da zum Abfragen nichts an der Hardware verändert werden muss,
und das Abfragen in 3 Zeilen getan ist.

MfG, Martin Lacher

 

[Johannes Permoser]

Marte Schwarz wrote:

Dann vergiss alles, was Du im LowCost Bereich an USB bekommst. Nur was auf
dem USB-Zielsystem eine eigene Uhr mitführt kann Deine Anforderungen
erfüllen. Unter Windoof und weitgehend unter Linux eigentlich auch fast
alles. Diese Systeme haben keine Echtzeitfähigkeit

Hab ich auch grad festgestellt:

Hab heute mal ein bisschen mit VC++ und meinem Gamepad rumprobiert udn
festgestellt, dass es doch zeimlich ungeeignet ist

Die kleinsten auf - zu - auf Zyklen die ich messen konnte dauerten 16,
31 und 47 Hundertstel => für mich ungeeignet, für andere Sachen sicher
lustig.

Um 0.1 ms aufzulösen brauchst Du einen eigenen Prozessor mit eigener Uhr,
die das Ereichnis dann mit einem Zeitstempel versehen an den PC
weiterreicht.

Das wäre dann die Lösung mit dem ATMEL-AVR und dem MAX232, oder?

 

[Michael Kutscher]

Hi,

Um 0.1 ms aufzulösen brauchst Du einen eigenen Prozessor mit eigener
Uhr, die das Ereichnis dann mit einem Zeitstempel versehen an den PC
weiterreicht.


Das wäre dann die Lösung mit dem ATMEL-AVR und dem MAX232, oder?

Genau (wobei es auch ein halbes Dutzend andere Controller tun dürften,
aber wenn Du mit keinem davon Erfahrung hast, ist der AVR sicher kein
schlechter Weg um das zu ändern). Falls in der Schulbibliothek der
"Elektor" steht, einfach die Zugabe aus dem Dezemberheft requirieren.
Damit gehts auch. (Kaufen kann man das Heft aber nicht mehr. Wenns nicht
irgendwo ungenutzt rumsteht, kauft sich der AVR billiger...)

Diese Käfer lassen sich übrigens auch alle in C programmieren, ist aber
etwas umständlicher im Handling als das V-Studio.

Viel Erfolg!
Michael Kutscher
--
www.kutschersoft.de

 

On Tue, 17 Jan 2006 15:49:55 +0100, Axel Schwenke
<axel.schwenke@gmx.de> wrote:

IIRC hat TurboPascal seine Zeitschleife kalibriert. Etwa so:

t1=lies_uhrzeit()
for (i=1000; i; i--)
t2=lies_uhrzeit()
speed=komische_konstante/(t2-t1)

Der K6 war so schnell, daß die letzte Zeile ein "Division by 0" gab.

Oder war vielleicht der TP-Compiler doch so intelligent, die nutzlose
Schleife einfach wegzurationalisieren? Und vor allem: Welche Auflösung
hat die lies_uhrzeit() ? Sekunden? 8->

Heinz

 

[Axel Schwenke]

Heinz Liebhart wrote:

On Tue, 17 Jan 2006 15:49:55 +0100, Axel Schwenke
axel.schwenke@gmx.de> wrote:

IIRC hat TurboPascal seine Zeitschleife kalibriert. Etwa so:

t1=lies_uhrzeit()
for (i=1000; i; i--)
t2=lies_uhrzeit()
speed=komische_konstante/(t2-t1)

Der K6 war so schnell, daß die letzte Zeile ein "Division by 0" gab.

Oder war vielleicht der TP-Compiler doch so intelligent, die nutzlose

Die Worte "TP-Compiler" und "intelligent" würde ich nicht in einem Satz
unterbringen wollen. Außer vielleicht mit einer zusätzlichen Verneinung.

Ich hab mal vor *langer* Zeit ein bisschen Fraktale mit TP programmiert.
Weils so langsam war, habe ich dann mal in den generierten Assembler-
code geschaut und konnte auch tatsächlich die innere Schleife um Faktor
100 oder so beschleunigen. Ein echtes Kleinod war z.B. folgendes:

PASCAL:
INTEGER x=0,y=0,z=0;

generierter Code:
MOV AX,0
MOV [x],AX
MOV AX,0
MOV [y],AX
MOV AX,0
MOV [z],AX

Da hätte der simpelste Peephole-Optimizer zweimal MOV AX,0 weggespart
und einmal XOR AX,AX draus gemacht. Der Rest war ähnlich schlecht, wenn
auch nicht immer ganz so offensichtlich.

Danach habe ich mich dann nicht mehr darüber gewundert, daß Turbo-Pascal
beim *compilieren* am schnellsten war.

Schleife einfach wegzurationalisieren? Und vor allem: Welche Auflösung
hat die lies_uhrzeit() ? Sekunden? 8-

Tante Gugel findet <http://www.webplain.de/turbopascal/error200.php>
es war also wirklich nur so ähnlich


XL

 

[Rudolf Wiesendanger]

Würde mich interessieren wann das war, da ich mich auch mal mit einem
Mandelbrotprogramm beschäftigt habe.
Welche Version Turbo Pascal war das ?
Habe mich danach dem Programm "Fractint" zugewendet.

Denke Du hast sicher recht, dass man mit Assemblerprogrammierung einiges
herausholen kann. Bei einem Programm für die Mandelbrotmenge ist es aber
wahrscheinlich mindestens so wichtig, das man für das Zeichnen der Pixel
möglichst wenig Zeit verbraucht. Und dies ist natürlich mit Turbo Pascal
über einen BGI Treiber relativ langsam. Dies gilt natürlich auch beim
Weg über das BIOS. So bleibt der direkte Maschinennahe Zugriff mit
Assembler.
Aber auch der gewählte Algorithmus ist wichtig.Da ist das Programm
Fractint ungeschlagen.

Axel Schwenke wrote:

Ich hab mal vor *langer* Zeit ein bisschen Fraktale mit TP programmiert.
Weils so langsam war, habe ich dann mal in den generierten Assembler-
code geschaut und konnte auch tatsächlich die innere Schleife um Faktor
100 oder so beschleunigen. Ein echtes Kleinod war z.B. folgendes:

 

[Axel Schwenke]

Rudolf Wiesendanger <Ruediw@hispeed.ch> wrote:

[snip]

Bitte nicht unaufgefordert mailen und posten.
Antwort kommt per Mail weil hier OT.

XL

 

[Johannes Permoser]

So, nun mal mein aktueller Lösungsansatz:

Ich werde den Tutorial-Aufbau von www.mikrocontroller. net mit einem
Atmega8 und dem MAX232 nachbauen. Für die USB schnittstelle wird ein
RS232 -> USB Adapter für 4.99 von Ebay ausgeschlachtet werden.

MfG, Johannes Permoser

 

[Jürgen Appel]

Hallo!

Rainer Zocholl schrieb:

Jetzt ist mir noch was eingefallen:
Gibt es solche Messmodule auf mit USB-Anschluss in einem vertretbaren
Preissegment?

USB ist immer noch sehr teuer und zu kompliziert um bei "Null"
anzufangen.

Wenn man schon ein wenig Ahnung von Micorprozessoren hat und ansonsten eh
eine serielle Schnittstelle bemühen möchte, scheint mir der neue
FTDI-232-chip ganz nett zu sein (die neue RL-Version auf der FTDI-Website
sieht noch ein wenig bastlerfreundlicher aus). Treiber gibt's auch fertig
dazu (bzw. sind bei Linux schon dabei), das Einlöten dürfte für einen
Anfänger dabei das schwierigste sein.

Wenn man sich dann schon diesen Chip bestellen will, dürfte auch
http://www.tuxgraphics.org/electronics/200510/article05101.shtml
ganz interessant sein
(oder auch
http://shop.tuxgraphics.org/electronic/microcontroller.html?id=479595#avrusb500).

Da hat man dann auch gleich eine Beispielanwendung und spart sich den Kauf
des Mikroprozessorprogrammers dazu.

Alternativ würde ich dem OP dazu raten, einfach ein Echtzeit-Linux
aufzuspielen und den vorhandenen Druckerport zu benutzen. Dann kommt man
völlig ohne Hardwarebasteleien aus und hat dennoch all den Comfort und die
Treiberunterstützung eines modernen Betriebssystems.

Unter RTLinux war es schon zu Zeiten von 400 MHz-Rechnern kein Problem,
einzelne Pins so schnell an- und auszuschalten daß ein angehängter
Piezolautsprecher einen reinen >10kHz Ton von sich gab (auch wenn Netscape
geladen wurde). Bei Windows oder einem normalem Linux gab es trotz
höchster Prozeßpriorität der Treiber dann nur Gestottere...

Gruß
Jürgen
--
GPG key:
http://pgp.mit.edu:11371/pks/lookup?search=J%FCrgen+Appel&op=get