Hallo ,
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
//SoftwareSerial Serial1(RX_PIN, TX_PIN);
void setup()
{
// Serielle Schnittstellen initialisieren
Serial.begin(115200);
Serial1.begin(115200);
// DTR-Signal simulieren
pinMode(RX_PIN, OUTPUT);
pinMode(TX_PIN, OUTPUT);
digitalWrite(RX_PIN, LOW);
digitalWrite(TX_PIN, LOW);
delay(15);
digitalWrite(RX_PIN, HIGH);
digitalWrite(TX_PIN, HIGH);
delay(15);
digitalWrite(RX_PIN, LOW);
digitalWrite(TX_PIN, LOW);
delay(11);
pinMode(RX_PIN, INPUT);
pinMode(TX_PIN, INPUT);
}
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
}
}
</code>
Karsten S. schrieb: > Jetzt habe ich mir einen Arduino NANO genommen, und sende über dessen > Software Serial Zeichen, nichts passiert, da nie das DTR Signal gekommen > ist Dafür brauchst Du einen separaten Pin, den Du schaltest. Also sofern es überhaupt geschaltet werden muss und nicht ein fester High-Pegel reicht. Karsten S. schrieb: > 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. Völliger Blödsinn.
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
Karsten S. schrieb: > 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.
Karsten S. schrieb: > Beleidige nicht, es gibt keine zusätzliche Leitung, das DTR wird > bewiesener Maßen von der Sensorhardware über HTerm empfangen Wen beleidige ich, Deinen "KI"-Brabbelbot? Da, etwas Lektüre: https://de.wikipedia.org/wiki/RS-232 Und Du behauptest, dass es unter Windows (wohl mit USB-RS232-Konverter, der einen DTR-Pin haben sollte) klappt und mit dem Arduino ohne DTR nicht. Das Thema Pegelwandlung hast Du ggf. auf dem Schirm? Viele Angaben zum Aufbau machst Du ja leider nicht. Karsten S. schrieb: > Also wenn Du es nicht weißt schreib nicht blödsinn Im Gegensatz zu Dir weiss ich, was DTR ist und wie eine RS-232 funktioniert.
pinMode(TX_PIN, INPUT); ? muß der TX_PIN nicht auf OUTPUT gesetzt werden? Gruß Ulrich
Es gibt keine weitere Leitung außer TX und RX 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 ?
Die genaue Bezeichnung des Sensors ist geheim? Sonst könnte man ja im Datenblatt nachschauen was das Teil genau erwartet...
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.
Es ist ein OPTRIS IR CS- Sensor Alles läuft ssoweit bis zu der aktiviersequenz. Die scheinbar standard sein muss für VirtualPorts. Siehe auch Serial.begin(19200, SERIAL_7E1); Leider nicht für Softserial bezüglich mode SERIAL_7E1
Wieder einmal so ein TO, der null Ahnung hat aber alles besser weiss. Und dann die Helfer noch beleidigt! Gruss Chregu
DTR ist eine Steuerleitung vom PC zum Reset Eingang des Mikrocontrollers. Beim Wechsel von HIGH nach LOW startet der Mikrocontroller neu. Man kann diese Leitung nicht anders herum vom Mikrocontroller aus ansteuern.
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. (40 Jahre in der Softwareentwicklung)
Karsten S. schrieb: > Es gibt eine Flanken Schaltung die das DTR ersetzt , wie oben > beschrieben. Na dann ist ja alles gut, oder nicht? Wenn wir dir diese Sonderlocke erklären sollen, musst du uns wenigstens den Schaltplan davon zeigen.
Karsten S. schrieb: > Es ist ein OPTRIS IR CS- Sensor Aha, irgendein ungenannter, ohne Datenblatt. Und den Schaltplan von dem, was Du da aufgebaut hast, verschweigst Du uns ebenfalls beharrlich. Karsten S. schrieb: > Siehe auch Serial.begin(19200, SERIAL_7E1); > > 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. Karsten S. schrieb: > Es gibt eine Flanken Schaltung die das DTR ersetzt , wie oben > beschrieben. Wenn ChatGPT sowas behauptet, muss es ja stimmen. Gut, dass ChatGPT Dir nicht zur Problemlösung geraten hat, Altöl zu trinken. Karsten S. schrieb: > 40 Jahre in der Softwareentwicklung Es wäre weniger peinlich gewesen, wenn Du das nicht erwähnt hättest.
Vielleicht mal mit einem BREAK versuchen? Wenn das nicht hilft mit einem Logicanalyzer mitschneiden was genau bei funktionierender Kommunikation mit HTerm passiert.
Karsten S. schrieb: > 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.
Karsten S. schrieb: > (40 Jahre in der Softwareentwicklung) Da kannste mal sehen was da mit einem passiert...
Karsten S. schrieb: > Kennt jemand eine Sequenz die für Virtual-ports also ohne Physische DTR > Leitung gültig wist bz. funktioniert ? Du kannst ein Gerät, dass nur für Hardware-Handshake ausgelegt ist, nicht per Software-Handshake steuern. DTR ist ein Beispiel dafür.
Ich mache genau das. Ich habe es oben haarklein erklärt.
https://www.uweelectronic.de/images/ue-products/temperaturmanagement/UETF-IR/UETF-IR-CSL15/Bedienungsanleitung%20CS%20LT15.pdf 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.
Karsten S. schrieb: > Ich mache genau das. > Ich habe es oben haarklein erklärt. Was machst du haarklein? Karsten S. schrieb: > 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 5. 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.
Karsten S. schrieb: > 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.
:
Bearbeitet durch User
Peter S. schrieb: > https://www.uweelectronic.de/images/ue-products/temperaturmanagement/UETF-IR/UETF-IR-CSL15/Bedienungsanleitung%20CS%20LT15.pdf 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...
Echt lustig, da kann ich nur mit dem Kopf schütteln. Mal wieder so ein Fall von, Apfel + Birne = Obstsalat. Und somit wären wir wieder bei: RTFM! Nun ja, wenn der TO jetzt noch auf Peter S. und Boris hört, sollte das Problem ja gelöst sein ;-)
Der Arduino hat keinen USB Host, also auch keinen Virtuellen USB Port.
Rüdiger B. schrieb: > Der Arduino hat keinen USB Host, also auch keinen Virtuellen USB Port. Schließt man einen typischen Arduino an einem PC an, geschieht das sehr wohl über einen virtuellen USB-Port. Auf dem PC. So undeutlich und verquast, wie sich der Threadstarter ausdrückt, muss man auch solche Binsen hier klar und deutlich wiederholen.
Hallo, 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.
Rüdiger B. schrieb: > Der Arduino hat keinen USB Host, also auch keinen Virtuellen USB Port. Was soll ein virtueller USB Port für ein Ding sein? Hier scheint einiges durcheinander geraten zu sein.
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)
Adam P. schrieb: > 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.
Ich vermute, seine Behauptung hat eine ganz absurde Ursache: Karsten S. schrieb: > 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: Beitrag "Re: Ein Draht TX DebugTransmitter" Aber "40 Jahre in der Softwareentwicklung" - hoffentlich nur als Hobby oder zumindest nichts, wovon Menschenleben abhängen.
Hmmm schrieb: > Aber "40 Jahre in der Softwareentwicklung" - hoffentlich nur als Hobby Hey irgendjemand muss ja Windows ME damals programmiert haben.
Karsten S. schrieb: > 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.
:
Bearbeitet durch User
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.
Rüdiger B. schrieb: > 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.
Rüdiger B. schrieb: > 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....
Karsten S. schrieb: > ich habe einen Thermal IR Sensor , der wird am Serial-Port scharf > geschalten wenn das DTR vom Terminal gesendet wird. DTR wird nicht gesendet, sondern das ist eine Leitung, die gesteuert wird, genauso wie ein GPIO von einem µC.
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.
:
Bearbeitet durch User
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.
Karsten S. schrieb: > 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.
char usbDescriptorString0[] = //language descriptor
{
4, //sizeof(usbDescriptorString0): length of descriptor in
bytes
3, //descriptor type
0x09, 0x04, //language index (0x0409 = US-English)
};
int usbDescriptorStringSerialNumber[] =
{
3,0
};
//--------------------------- Device Descriptors
---------------------------
char usbHidReportDescriptor[] = { // USB report descriptor
0x06, 0x00, 0xFF, // USAGE_PAGE (Generic Desktop)
0x09, 0x01, // USAGE (Vendor Usage 1)
0xA1, 0x01, // COLLECTION (Application)
0x09, 0x02, // USAGE (Vendor Usage 0x02)
0x15, 0x00, // LOGICAL_MINIMUM (0)
0x26, 0xFF, 0x00, // LOGICAL_MAXIMUM (255)
0x75, 0x08, // REPORT_SIZE (8)
0x95, 0x08, // REPORT_COUNT (8)
0x81, 0x02, // INPUT (Data,Var,Abs)
0x09, 0x03, // USAGE (Vendor Usage 0x03)
0x75, 0x08, // REPORT_SIZE (8)
0x95, 0x08, // REPORT_COUNT (8)
0x91, 0x02, // OUTPUT (Data,Var,Abs)
0x09, 0x04, // USAGE (Vendor Usage 0x04)
0x75, 0x08, // REPORT_SIZE (8)
0x95, 0x08, // REPORT_COUNT (8)
0xB1, 0x02, // FEATURE (Data,Var,Abs)
0xC0 // END_COLLECTION
};
usw..
Karsten S. schrieb: > 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
Thomas Z. schrieb: > 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.
Karsten S. schrieb: > 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. Für dies Lösung fehlt dir jetzt nur noch das passende Problem. Mit deinem Arduino Nano und SoftwareSerial hat das überhaupt gar nichts zu tun?
Karsten S. schrieb: > ein USB - (Yellow Book) Deskriptor gesendet werden du bist ein Troll und glaubst alles was ChatGP dir so halluziniert. CDC ist das "Centers of Desease Control" die amerikanische Gesundheitsbehörde. https://wwwnc.cdc.gov/travel/page/yellowbook-home Yellow Book ist in der Edv die Beschreibung des CD Formats. CDC steht bei USB für Communication Device Class https://en.wikipedia.org/wiki/USB_communications_device_class wie hast du denn 40 Jahre Software Entwicklung ohne ChatGP gemacht?
:
Bearbeitet durch User
Karsten S. schrieb: > Jeder Request wird mit einem HID (HumanInterfaceDevice) gesendet Nö, die üblichen USB-UARTs von FTDI, SiLabs, WCH und auch Prolific haben weder mit HID noch mit CDC etwas am Hut.
Thomas Z. schrieb: > wie hast du denn 40 Jahre Software Entwicklung ohne ChatGP gemacht? Vielleicht hatte er damals noch nicht so viel Red Bull konsumiert.
Karsten S. schrieb: > DTR vom PC ist ein USB -Deskriptor Paket > (Yellow Book) Karsten S. schrieb: > Jeder Request wird mit einem HID (HumanInterfaceDevice) gesendet Jetzt dreht er ganz durch.
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. ciao gustav
Karl B. schrieb: > Geht doch. 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.
Harald K. schrieb: > Was hat das eigentlich mit dem Thema des Threads zu tun? Gar nichts. Doch: DTR wird oben erwähnt als Datentransfer. Zumindest als Initialisierung. Karsten S. schrieb: > 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! ciao gustav
Karl B. schrieb: > DTR wird oben erwähnt als Datentransfer. Zumindest als Initialisierung. Nein, das hat sich der völlig ahnungslose TO zusammengereimt. Vielleicht solltest Du den Thread einfach mal komplett lesen, bevor Du ihn kommentierst.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.