Virtueller COM-Port vs. RS232

Florian Schaeffer schrieb:

könnte an der Latenzzeit vom USB liegen. Wie kann ich das vermeiden ohne zu wissen, was für ein

gar nicht?

Es hat einen Grund warum viele klagen, das bei nicht "realen" seriellen, verschiede Geräte nicht funzen, bei denen es auf Timing ankommt.

Wenn du das so brauchst wie oben beschrieben , nimm nur echte serielle. Bei Laptops ohne COM1 bleibt dann nur noch eine PCMCIA Karte.

Andreas

Hallo,

was hast Du denn da eigentlich vor das der Unterschied von 200 zu 206 ms für Dich relevant ist? Du hast unter Windows mit Delphi ohne spezielle Treiber oder Hardware eh schlechte Karten wenn Du ein auf Millisekunden genaues Timing über eine Standardschnittstelle nach aussen bringen willst. Du kannst Dich bei der asynchronen seriellen Schnittstelle nur darauf verlassen das das Timing für ein einzelnes serielles Zeichen soweit stimmt das es von der Gegenseite richtig empfangen werden kann, aber dazu kann die Gesamtdauer des Zeichens durchaus um +- 5 % falsch sein ohne das dies zu Problemen führt.

Bye

Uwe Hercksen schrieb am 22.02.2007 10:02:

s=20

h=20

ne=20

Es ist relevant. Wie gesagt: Per RS232 klappt's. Also kann es nicht so schlimm sein, das=20 mit Delphi zu wollen. Wer sagt, da=DF ich ganze Zeichen =FCbertragen will?

--=20 PM: f.schaeffer

Andreas Ruetten schrieb am 22.02.2007 08:05:

Ja, aber dann m=FC=DFte sowohl das Einschalten, als auch das Ausschalten =

verz=F6gert werden, nicht aber nur eins davon. Das Signal m=FC=DFte gleic= h=20 lang bleiben, nur sp=E4ter kommen. Oder?

Das ist alles keine Alternative.

--=20 PM: f.schaeffer

Florian Schaeffer schrieb:

Niemand. Aber /deren/ Timing ist das einzige, das bei der RS-232 spezifiziert ist. Alles andere ist eher Zufall, wenn es trotzdem paßt.

Tilmann

--
http://www.autometer.de - Elektronik nach Maß.

Florian Schaeffer schrieb:

Nein, die Verzögerung ist zufällig und kann für jeden Vorgang eine andere sein.

Tilmann

--
http://www.autometer.de - Elektronik nach Maß.

Hallo,

wenn Du die serielle Schnittstelle mißbrauchen willst darfst Du Dich nicht wundern wenn es nicht immer klappt. Es kann Dir auch sehr leicht passieren das es per RS232 nicht immer klappt, z.B. auf einem anderen Rechner, wenn noch andere Programme im Hintergrund laufen, wenn sich Windows mal länger mit sich selbst beschäftigt.....

Bye

Florian Schaeffer schrieb:

Da dein OS ja nichtmal echtzeitfähig ist (nehm ich jetzt mal einfach so an. Windows?) kannst du das Vorhaben eh vergessen wenn es zuverlässig bei jeder Prozessorauslastung funktionieren soll.

--
Matthias Weißer
matthias@matwei.de
http://www.matwei.de

Wenn es nicht darum geht genau 200mS zu produzieren sondern moeglichst um Reproduzierbarkeit zwischen Systemen, kommst Du bei einer RS232 (und Deinem OS ohne weitere Tools) um Die Daten nicht herum (ich nehme auch an Delphi unterstuetzt keine Interrupts ueber die GPIO von UARTS?). Soweit ich mich entsinne muss ein Break ja nur mindestens laenger als ein jeweiliger Frame sein. Aber die realen Toleranzen bei der Datenbits sind wahrscheinlich enger. Heuzutage sind alle geil auf hohe Baudraten dadurch sind die (nicht veraendebaren) Vorteiler in den (ASIC-)UARTs wesentlich groesser angesetzt und die Baudraten werden genauer als frueher produziert. Daher erwarte ich hier zw. verschiedenen Rechnern und Methoden eigentlich keine grossen Abweichungen.

Es wuerde mich interessieren wie gross nun die tatsaechlichen Unterschiede sind bei N81 mit 50 bps und einem Datenbyte 0x00 bei beiden Methoden (virtuell und normal). Hier sollte es dann eigentlich wesentlich geringere Unterschiede geben, auch wenn die theoretische Toleranz bei _der_ Baudrate in mS wieder groesser ist. Aber ich kann mich natuerlich auch irren.

Ich habe mal so (1987 also in grauer Vorzeit als es noch keine so billigen uC gab aber mit einem echten PC-USART) gemeinsam mit den Datenbytes und der Programmierung der Bauratenregister (Teiler) unter Laufzeit (DOS/Turbo-C) damals variable Pulse generiert die eigentlich sehr zuverlaessig waren. War ein ziemlicher SW-Aufwand eben zur Laufzeit immer die exateste Methode der Kombination von Bits und Baud abhaengig vom verwendeten USART-Quarz zu finden fuer die jeweils gewuenschte Impulsdauer. Ich kann mich leider an die Abweichungen zw. den damaligen gelieferten Rechnertypen leider nicht mehr erinnern ist heute aber sicher auch nicht mehr gueltig.

mfg Charlie

Daran, daß Windows kein Echtzeit-OS ist.

Mit einer normalen Userspace-Applikation: Garnicht.

Selbst ein Treiber könnte ein "exaktes" Timing allenfalls bei einer realen Hardware gewährleisten, nicht aber bei einem virtuellen COM-Port. Denn dieser ist auch bloß ein Treiber und wenn man ihn nicht selbst geschrieben hat, hat man nach Übergabe der Kontrolle an diesen Treiber (und die Kontrolle muß man übergeben, um seine Funktionalität nutzen zu können) keinen Einfluß mehr darauf, was er weiter anstellt.

Sprich: wenn du "exaktes" Timingverhalten brauchst, mußt du ein RTOS benutzen. Aber du solltest dir vorher bei Wikipedia ansehen, was RTOS bedeutet. Nämlich auch nicht etwa, daß jede Aktion instantan erfolgt, sondern nur, daß sie in einem _definierten_ Zeitrahmen erfolgt. Das bedeutet zum Beispiel bei der Erzeugung eines Pulses mit einer Wunschbreite X und einer garantierten Anwortzeit des Systems Y, daß die tatsächlich erzeugte Pulsbreite irgendwo zwischen X-Y und X+Y betragen wird. Das ist im Prinzip genau wie bei Windows, der Unterschied ist, daß bei Windows das Y keine garantierte Maximalgröße hat und deshalb im Extremfall sogar unendlich werden kann. Es ist also alles möglich zwischen: Es wird garkein Puls erzeugt und: Er dauert unendlich lange.

Nur, daß die heute auch schon PCMCIA weglassen, dafür dann das express-Gedöns kommt. Mal sehen, ob es dafür auch ordentliche COM-Karten geben wird...

Hallo Karl,

Ich hab auch schon an der Seriellen mit Bitbanging rumgemacht, IMHO ist es das, was der OP auch gemacht hat. Dass er die 200 ms so genau sieht, leigt ha daran, dass er am Scope die wenigen ausreisser, nicht sieht, weil die gleich 100 ms oder noch mehr überziehen und eben unregelmäßig reinhauen. Ohne Speicherscope, das alle Kurven übereinanderschreiben kann wird das nix mit dem Beobachten.

Das schenit mir auch der einzig sinnvolle Weg zu sein, diesen 200 ms Puls zu generieren. Allerdings ist dann der Zeitpunkt des Starts auch nicht mehr so sicher, war er aber ohnehin nie gewesen ;-)

Ja DOS war und ist für solche Spielereien nach wie vor ungeschlagen.

Das dürfte mit einem PC die einzig saubere Variante sein, die unter Windoof klappen könnte. Zugriff auf die Baudrate hat man via API, dann wird das folgende Timing nicht mehr von Windows aus behindert, sondern vom Baudratengenerator.

Marte

Hallo, das mit dem FTDI kannste vergessen. Der Treiber sendet nicht jeden Wackler einer Leitung sofort an den Chip. Das wird erstmal gepuffer....

Schreib doch einfach mal warum Du die Schnittstelle ansteuern willst bzw. was Du vorhast. Vielleicht gibt es noch eine andere lösung.

Gruss Jochen

Jochen Rapp schrieb am 23.02.2007 21:26:

--=20 PM: f.schaeffer

Florian Schaeffer schrieb:

Ach, K-Line! Wenn du noch ein bisschen wartest, ist das eh' Geschichte.

2006 war IIRC in den USA das letzte Neuwagenjahr, bei dem noch K-Line für OBD erlaubt war, ab 2007 soll da nur noch OBD via CAN verbaut werden. EU wird vermutlich bald folgen.

Jan

Jan Kandziora schrieb:

Da lob ich mir die Diagnoseschnittstelle beim Käfer, und das Disgnosegerät war fest eingebaut.

Gruß Dieter

Jan Kandziora schrieb am 26.02.2007 00:29:

=FCr

1. Sehr hilfreich
2. Betrifft das OBD II
3. 2008
4. Verschrotten nicht alle sofort ihr Auto.

--=20 PM: f.schaeffer

Dieter Wiedmann schrieb:

Tankuhr?

Andreas

Tilmann Reh schrieb:

Dieses Vergewaltigen irgendwelcher IO-Bausteine für nicht spezifizierte Kommunikation ist der einzige Grund, warum unterschiedliche Hardware nicht immer zuverlässig funktioniert und manchmal gar nicht.

Bernd