ich habe einen Thermal IR Sensor , der wird am Serial-Port scharf geschalten wenn das DTR vom Terminal gesendet wird. als USB RS232 !
Die Leitungen außer tx und rx existieren nirgends!
Also am Windows PC mit dem Programm HTerm nach dem Connect einfach
den DTR Button einschalten und der Sensor legt los.
Jetzt habe ich mir einen Arduino NANO genommen, und sende über dessen
Software Serial Zeichen, nichts passiert, da nie das DTR Signal gekommen ist,
denn man kann es nicht sonderlich einschalten, ChatGP meint das die Pins für tx und rx mal kurz auf high und low wechseln sollen am Anfang, dies würde eine DTR Sequenz auslösen die der Sensor versteht.
Dem ist leider nicht so.
Kennt jemand eine Sequenz die für Virtual-ports also ohne Physische DTR Leitung gültig wist bz. funktioniert ?
Hier das Listing auf dem Arduino Nano
<code>
#include <SoftwareSerial.h>
#define RX_PIN 10 // RX-Pin von SoftwareSerial
#define TX_PIN 11 // TX-Pin von SoftwareSerial
void loop()
{
// Lese Bytes vom Sensor und gebe sie über die serielle Schnittstelle aus
if (Serial1.available()) {
uint8_t receivedByte = Serial1.read(); // Lese ein Byte vom Sensor
Serial.write(receivedByte); // Schreibe das Byte an den seriellen Monitor
}
// Lese Bytes von der seriellen Schnittstelle und sende sie an den Sensor
if (Serial.available()) {
uint8_t sentByte = Serial.read(); // Lese ein Byte vom seriellen Monitor
Serial1.write(sentByte); // Sende das Byte an den Sensor
}
}
ChatGP meint das die Pins
für tx und rx mal kurz auf high und low wechseln sollen am Anfang, dies
würde eine DTR Sequenz auslösen die der Sensor versteht.
Beleidige nicht, es gibt keine zusätzliche Leitung, das DTR wird bewiesener Maßen von der Sensorhardware über HTerm empfangen, es handelt sich um ein Virtual DTR das von HTerm sehr wohl gesendet wird. Bewiesener weise.
Also wenn Du es nicht weißt schreib nicht blödsinn, sonnst ist der ganze thread unbrauchbar. Danke Dir
Also wenn Du es nicht weißt schreib nicht blödsinn, sonnst ist der ganze
thread unbrauchbar. Danke Dir
Das ist Blödsinn. Ein Virtual DTR kannst du an einen Virtual Serial Port schicken - aber nicht an eine RX/TX UART. Dafür benötigst du einen separaten Pin. Er hat schon recht.
Dennoch kann HTerm über DTR den sensor aktivieren !
Mit dem Arduino über Softserial müsse also eine Sequenz abgesetzt werden die das DTR emuliert, sonnst würde ja der Thermo-Sensor nicht bei HTerm das DTR akzeptieren das niemals eine Leitung hat.
Warum also deformieren anstatt es zu diskutieren ??
WARUM ?
Das DTR wirkt schon vor dem wieder herunter schalten stimmt müsste eigentlich TX basierend auf Output stehen, aber schon am Ende der Sequenz müsste das DTR wirken, Danke für den Hinweis.
DTR wird getriggert wenn man in Windows die "COM" Schnittstelle öffnet.
Jeder, der schon mal mit Hterm auf einen Arduino im laufen Betrieb zugreifen wollte weis das danach.
Ja das ist für einen Hardware SERIALPORT klar, ich habe aber einen USB-Virtual RS232 da gibt es nur zwei Leitungen, sonnst würden ja alle serial Geräte über USB nicht funktionieren !
Es gibt eine Flanken Schaltung die das DTR ersetzt , wie oben beschrieben.
Leider nicht für Softserial bezüglich mode SERIAL_7E1
Was auch immer Du mit diesem Satz ausdrücken willst: Falls die Softserial kein 7E1 spricht, ist das zwar kein Beinbruch, aber Du musst Dich um das Parity-Bit kümmern, wenn der Sensor mit Dir reden soll.
Vielleicht mal mit einem BREAK versuchen? Wenn das nicht hilft mit einem Logicanalyzer mitschneiden was genau bei funktionierender Kommunikation mit HTerm passiert.
ich habe aber einen USB-Virtual RS232 da gibt es nur zwei Leitungen
Und keine Masseleitung? Erstaunlich.
Falls es doch drei Leitungen sind, mit Speicheroszi tx und rx gegen Masse aufzeichnen und nachsehen, was da am Anfang und beim drücken von DTR passiert.
Auf den Seiten 33 und 34 ist ein optionales USB-Kit beschrieben. Dabei handelt es sich vermutlich nicht um einen einfachen USB-UART-Konverter, sondern um etwas Spezielles, das bei gesetztem DTR die Betriebsspannung an den Sensor gibt.
Beleidige nicht, es gibt keine zusätzliche Leitung, das DTR wird
bewiesener Maßen von der Sensorhardware über HTerm empfangen, es handelt
sich um ein Virtual DTR das von HTerm sehr wohl gesendet wird.
Die DTR-Leitung kommt vom USB-Seriell Wandler. Guck dir bspw. den CP2102 an.
Danke für deine Antwort, es gibt durchaus einige Flankenwechsel die
zum erkennen einer DTR Kommunikation verwendet werden
Timing und Softwareverzögerungen
Die Zeitschlitze für die Steuerung des DTR-Signals in HTerm können auch von der Softwareverzögerung und der Verarbeitungszeit abhängen, die das Betriebssystem und der Treiber benötigen, um das Signal tatsächlich zu setzen oder zu löschen. Diese Verzögerungen sind normalerweise sehr gering, könnten aber im Bereich von Mikrosekunden bis Millisekunden liegen.
Zusammenfassung der Zeitschlitze:
Aktivierung (DTR gesetzt): Sofort beim Öffnen der Verbindung, im Bereich von Millisekunden.
Deaktivierung (DTR gelöscht): Sofort beim Schließen der Verbindung, im Bereich von Millisekunden.
Im Betrieb: DTR bleibt aktiv, es gibt keine regelmäßigen Schaltzyklen.
Handshaking (DTR/RTS/CTS): Kurze Pulsdauer in Millisekunden, wenn Handshaking erforderlich ist.
In HTerm sind die Zeitschlitze für das DTR-Signal sehr kurz und effizient. Das DTR-Signal wird in der Regel nur beim Öffnen und Schließen der Verbindung ein- und ausgeschaltet. Der Betriebsablauf wird durch diese schnellen Steuerungsvorgänge nicht signifikant beeinflusst, außer bei speziellen Handshake-Mechanismen.
HTerm Schaft es das DTR virtuell zu aktivieren, dies schaltet den Sensor dann "scharf" und der postet im burstmodus dann laufend daten, man muss also eine Mikro Sekunden genau flanke senden, ich werde es weiter analysieren, danke für die Dok Untersuchung. Genau diesen Pegelwandler verwende ich.
Dann würde ich einfach mal die Spannung am Anschluss "Power (+)" messen. Vermutlich ist im USB-Kit der DTR-Pin des intern verbauten USB-UART-Wandlerchips mit einen High-Side-Switch verbunden und die 5V Betriebsspannung kommen nur wenn DTR gesetzt ist.
Die Doku des optris CS Infrarot-Thermometer ist eigentlich bezüglich DTR recht eindeutig. Es gibt einen "USB-Kit" (USB-Programmieradapter inkl. Klemmblock und Software-CD). Und bei Protokoll steht: "Um den Sensor mit Spannung zu versorgen, muss das Steuersignal „DTR“ gesetzt werden."
Also sollte bei diesem Sensor die Kommunikation per UART funktionieren wenn der Sensor separat mit Spannung versorgt wird.
Wenn das wirklich das DB zum Sensor ist, dann steht auf Seite 43:
Um den Sensor mit Spannung zu versorgen, muss das Steuersignal „DTR“ gesetzt werden. Darüber steht dann noch was zur seriellen Schnittstelle: 9,6kBaud (oder auch 115,2 kBaud) mit 8N1 ohne Flusskontrolle.
Seite 50/51 Beschreibt dann wie man den Sensor mit dem MAX3381E an den PC anschließt ... und auf Seite 31 steht: Der CS Sensor darf entweder nur über USB oder extern mit Spannung versorgt werden, aber nicht gleichzeitig!
Wenn Du den USB auf RS232 Adapter vom Hersteller des Sensor verwendest, dann nutzt dieser den DTR Ausgang um den Sensor mit Betriebsspannung zu versorgen. Wenn Du DTR am PC einschaltest, bekommt der Sensor Spannung.
Wenn Du den Sensor an einen Arduino NANO anschließen möchtest, dann über RS232 mit GND, TX und RX ... dazu benötigt der Sensor dann noch eine Betriebsspannung (5-30 VDC / 100mA). Den USB Adapter kannst Du nicht an den NANO anschließen, der kann nämlich kein USB OTG...
ich befürchte ja, Ursache der ganzen Diskussion ist ein Missverständniss von virtuellen RS232 Ports über USB.
Die Wandler ICs (FT232, PL2303, CH340,...) bringen alle die komplette RS232 Schnittsetlle inklusive aller Steuerleitungen mit. In den meisten Anwendungen werden die dann aber weggelasssen.
Ich vermute der TO hat gedacht bei USB-RS232 Wandlern gäbe es die ganzen Steuerleitungen nicht, sondern nur TX und RX.
Ein Bild vom Aufbau wäre hilfreich gewesen, aber nunja.
Ich glaub er hat gedacht, man könnte das DTR Signal über die TX/RX Leitung irgendwie senden.
Aber es ist ja nun mal so, dass DTR & RTS eigene Leitungen sind.
Warum das dann nun über sein HTerm funktioniert hat, bleibt ein Rätsel.
(wenn er sagt es sei nur TX und RX verwendet worden)
Warum das dann nun über sein HTerm funktioniert hat, bleibt ein Rätsel.
(wenn er sagt es sei nur TX und RX verwendet worden)
Das ist kein Rätsel.
Der virtuelle COM-Port, den der USB-Seriell Adapter im PC zur Verfügung stellt, beherrscht HW-Handshake und wird von HTerm passend gesteuert. Nur mit RX und TX geht das nicht. Damit ließe sich nur SW-Handshake realisieren und da gibt es eben kein DTR Signal.
Ja das ist für einen Hardware SERIALPORT klar, ich habe aber einen
USB-Virtual RS232 da gibt es nur zwei Leitungen, sonnst würden ja alle
serial Geräte über USB nicht funktionieren !
Der TO scheint zu glauben, dass der USB-RS232-Konverter die beiden USB-Datenleitungen 1:1 für RXD und TXD verwendet.
Grundlagen scheinen generell nicht so sein Ding zu sein:
HTerm Schaft es das DTR virtuell zu aktivieren,
dies schaltet den Sensor dann "scharf"
Was stellst du dir unter einer virtuellen DTR Leitung vor?
Dein Sensor hat einen physischen DTR Eingang, denn kann man weder mit Luft und Liebe noch mit virtuellen Hirngespinsten ansteuern. Da muss ein Kabel und Strom dran.
Mit HTERM und USB und irgendwas virtuellem hat das gar nichts zu tun. Damit führst du uns alle nur in die Irre!
Ein Schaltplan wäre hilfreich gewesen, das viel schneller zu erkennen. Nach 40 Jahren Entwicklungserfahrung (egal welcher Art) ist mir diese planlose Vorgehensweise unbegreiflich.
Sensor mit Arduino, Arduino USB reagiert nicht auf DTR.
Das ist nicht richtig. Wie ich bereits schrieb mach der Mikrocontroller auf dem Arduino Board einen Reset, wenn die DTR Leitung vom USB-UART auf HIGH geht.
Aber daran ist der Sensor offenbar gar nicht angeschlossen. Wie gesagt: Ein Schaltplan hätte für Klarheit gesorgt.
Vielleicht so:
Sensor mit USb Interface des Herstellers, Power on mit DTR.
Sensor mit Arduino, Arduino USB reagiert nicht auf DTR.
Also muss der Arduino den Sensor mit Strom versorgen, dauernd oder
geschaltet.
RTFM ... der Hersteller verwendet bei dem kaufbaren Zubehörteil "USB auf RS232 Kabel" das DTR Signal um die Betriebsspannung für den Sensor einzuschalten / bereit zu stellen.
Wenn er das Ding an den Arduino anschließen will, dann kann der Sensor nur direkt über die RS232 Schnittstelle betrieben werden, dazu braucht der Sensor dann noch eine Versorgungsspannung.
Der Arduino besitzt zur Wandlung auf USB einen Wandlerchip (CH340) und verhält sich damit am PC wie ein virtueller COM Port, genauso wie der USB-Wandler des Sensors...
Den Sensor über USB mit einem Mikrocontroller zu verbinden geht nur, wenn der Controller das auch Unterstützt (USB OTG oder einen Host-Controller besitzt). Zwei Geräte mit USB-RS232 Wandler kann man nicht direkt verbinden....
Wenn ich mir die Schaltung auf Seite 34 der Anleitung anschaue, dann glaube ich nicht, dass DTR an den Sensor weitergegeben wird.
Vermutlich wird durch setzen von DTR lediglich die Betriebsspannung (Power white) an dem speziellen USB Adapter durchgeschaltet, denn in der Beschaltung zur direkten RS232 Schnittstelle wird DTR auch nicht benutzt.
Bei Ansteuerung mit Arduino müssten damit TX und RX ausreichen.
Falls das nicht funktioniert würde ich mir mal bei einer Ansteuerung durch den PC die Signale zum Sensor ansehen.
DTR vom PC ist ein USB -Deskriptor Paket, der FTDI Chip unterstützt das
und der hat dann eine DTR Leitung Physisch, um sie zu aktivieren muss vom PC
ein USB - (Yellow Book) Deskriptor gesendet werden. Das ist Teil der USB-RS232 Protokollebene und erfolgt auf Treiber ebene.
Den ganzen FTDI Chip abgeknipst und mit selber nen Pegel Wandler gesetzt fertig.
Danke für die Hinweise, viel Bösnmut auch immer im Spiel, schade eigentlich.
DTR vom PC ist ein USB -Deskriptor Paket, der FTDI Chip unterstützt das
ganz so ist das nicht. Beim FTDI wird der Status der Leitungen im letzen Byte des Bulk TransFers übermittelt. Auf dem Bulk Out die Ausgänge auf dem Bulk IN die Eingänge. CDC macht das anders die machen einen CLASS Request auf das Control Interface. Mit Usb Deskriptoren hat das alles nichts zu tun.
Jeder Request wird mit einem HID (HumanInterfaceDevice) gesendet
Sieht intern in der Definition so aus:
Der Descriptor enthält die spezifischen Kommandos die dann
gesendet werden.
das ist mit Verlaub gesagt einfach Unsinn. Deskriptoren werden nach einem GetDeskriptor (Setup Packet) zurück geliefert. HID sendet die Daten üblicherweise über einen Interrupt EP zurück.
Ich empfehle die USB Spec da steht das alles (und noch mehr) drin
das ist mit Verlaub gesagt einfach Unsinn. Deskriptoren werden nach
einem GetDeskriptor (Setup Packet) zurück geliefert. HID sendet die
Daten üblicherweise über einen Interrupt EP zurück.
Ich empfehle die USB Spec da steht das alles (und noch mehr) drin
Abgesehen davon dass die ganze Low Level USB Spec für das Thema gar nicht relevant ist. Es kommt darauf an ob man für den verwendeten USB->RS232 Umsetzer den passenden Treiber hat und der Rest wird im virtuellen COM Port abgehandelt.
WIE genau der Treiber die DTR Leitung aktiviert ist doch egal, sofern es passiert.
Und noch einen draufsetzen:
8 kanaliges 10 Bit-Datenerfassungssystem:
"...Der Datentransfer spielt sich zwar über sie serielle Schnittstelle (COM1) ab, läuft aber nicht wie üblich über die normalen Datenleitungen Rx und Tx, sondern über die Statusleitungen DTR, RTS, CTS.
Baustein: LTC 1090 vonLinear Technology.
Geht doch.
Und GWBASIC:
...
110 OUT&H3FC,(&HFE AND INP (&H3FC))
...
Muss nur noch umschreiben auf gängigen Code...
Vielleicht kann KI das auch.
Ist Bit-Banging. Das ging unter DOS, aber unter ernstgemeinten Betriebsystemen kannst Du das klar vergessen, das wird dann nämlich extrem langsam.
Da ist es ratsam, das eigentliche Protokoll mit einem Arduino o.ä. abwickeln zu lassen, und die aufbereiteten Daten auf sinnvolle Weise (d.h. UART, so wie sie gedacht ist) zu übertragen.
Was hat das eigentlich mit dem Thema des Threads zu tun? Gar nichts.
