Weiß jemand, wie man die Signalpegel an der RS232 im Visual Studio 13 setzen und auslesen kann? Danke
Ein bisschen mehr Kontext solltest du schon liefern.
Weiß jemand, wie man die Signalpegel an der RS232 im Visual Studio 13 setzen und auslesen kann?
Geht gar nicht.
Man kann höchstens in einer der vielen von Micosoft Studio unterstützen Programmiersprachen ein Programm schreiben, welches über die RS232 kommuniziert. Aber auch damit kann man die Signalpegel an der Schnittstelle nicht setzen und auslesen.
Oliver
Wieso denn nicht Oliver??
Private Sub CheckBox3_CheckedChanged(sender As Object, e As EventArgs) Handles CheckBox3.CheckedChanged If CheckBox3.Checked = True Then SerialPort1.DtrEnable = True Else SerialPort1.DtrEnable = False End If End Sub
Das habe ich gefunden. Aber noch nicht RxT, TxT oder CTR. HTerm macht das!
Ich möchte mir z.B. ein Schieberegister an der RS232 bauen.
Aber noch nicht RxT, TxT oder CTR.
Keines dieser Signale existiert bei RS232.
RXD ist ein Eingang, da kannst du nichts umschalten.
Wieso denn nicht Oliver?? … Aber noch nicht RxT, TxT oder CTR.
Je nun, da hast du direkt die Antwort zur Frage…
Oliver
im Visual Studio 13 setzen
Das ist eine IDE. Deinem Beispielcode nach meinst Du wohl, wie Du das mit .NET-Zeug erledigen kannst.
Das habe ich gefunden. Aber noch nicht RxT, TxT oder CTR.
TXD und RXD kannst Du nur für UART-Kommunikation nutzen. Was die Handshake-Leitungen angeht:
https://learn.microsoft.com/en-us/dotnet/api/system.io.ports.serialport?view=net-9.0-pp
HTerm macht das!
Es zeigt an, wenn Daten gesendet oder empfangen werden, das ist keine Echtzeit-Darstellung der Datenleitungen.
Sorry! War im falschen Forum und ziehe hiermit meine Anfrage zurück. Habe ein kleines Programm gefunden. Läuft sogar vom Stik und ist im Anhang! Mit dem kann man die Leitungen setzen!
War im falschen Forum
Du wolltest eigentlich in einem Forum posten, wo man dank Glaskugel Deine unvollständige Frage entziffern kann?
Mit dem kann man die Leitungen setzen!
Aber ganz sicher nicht "RxT, TxT oder CTR".
Für TXD kann man unter Windows tricksen (Break hat keinen Timeout), wie es dieser Code tut, aber ob das mit allen USB-RS232-Adaptern funktioniert, sei dahingestellt.
Hmmmmmmmm, was war so unverständlich an meiner Anfrage?
Und Du irrst! Mit dem Programm kann Mann die Pegel auf TXD, RTS und DTR setzen und rücksetzen. CTR gibt es gar nicht! Probiere es doch aus bevor Du es mit Glaskugeln versuchst. Vielleicht sollte Deine mal zur Reparatur.
Hmmmmmmmm, was war so unverständlich an meiner Anfrage?
Dass Visual Studio 13 keine Programmiersprache, sondern eine IDE für diverse Programmiersprachen ist.
Man brauchte also eine Glaskugel, um zu erfahren, ob Du aus der IDE oder aus eigenem Code etwas schalten willst, und falls letzteres, in welcher Sprache das passieren soll.
Und Du irrst! Mit dem Programm kann Mann die Pegel auf TXD, RTS und DTR setzen und rücksetzen.
Ich irre überhaupt nicht. Du hast bloss nicht begriffen, was ich geschrieben habe: Dass es mit den Handshakeleitungen regulär geht (siehe mein Link weiter oben) und mit TXD nur mit Trickserei, die a) so nur unter Windows funktioniert, b) evtl. nicht mit allen USB-RS232-Adaptern funktioniert und c) von Deinem ach so tollen Tool genutzt wird.
CTR gibt es gar nicht!
Tja, "RxT, TxT oder CTR" war ein Zitat von Dir, und alle drei gibt es nicht. Beginnende Demenz?
Ich möchte mir z.B. ein Schieberegister an der RS232 bauen.
Das ist der /schlechtestmögliche/ aller Ansätze. So etwas macht man nicht per "Bit-Banging", und schon gar nicht an einer seriellen Schnittstelle.
Gast
#7843606
Ich möchte mir z.B. ein Schieberegister an der RS232 bauen.
Das wird extrem langsam laufen, vor allem wenn noch USB dazwischen ist. Unter DOS bis Windows Me ging das mit direkten Hardwarezugriffen noch einigermaßen gut. Inzwischen aber nicht mehr.
TXD und RXD kannst Du nur für UART-Kommunikation nutzen. Was die
Ähem, nein. Man kann die auch also einfachen Ausgang (TXD) oder einfachen Eingang (RXD) verwenden. Wenn auch nicht ganz so schnell, wie das mit den üblichen "Klingelpins" geht.
Man verwendet dazu einfach den BRK-Mechanismus. Der .net-Serialport unterstützt das über das Property BreakState und über das Event PinChanged.
Insgesamt hat man also am Serialport drei Ausgänge und fünf Eingänge zur Verfügung, mit denen man in GPIO-Manier rumfummeln kann. Das genügt z.B., um 15 Tasten als Matrix abzufragen.
Ähem, nein. Man kann die auch also einfachen Ausgang (TXD)
Habe ich schon weiter oben geschrieben.
Zum einen ist das OS-abhängig. Unter Windows kannst Du den Break-Zustand beliebig ein- und ausschalten. POSIX-Systeme tun das, wofür es eigentlich gedacht ist, und schicken für einen gewissen Zeitraum ein Break, siehe tcsendbreak().
Zum anderen geht das je nach USB-UART-IC sogar komplett schief. Ich glaube, CP2102 und PL2303 sind (ggf. je nach Version) solche Kandidaten.
einfachen Eingang (RXD)
Wie soll das gehen? Du bekommst zwar mit Verzögerung ein empfangenes Break signalisiert (je nach Treiber wohl einfach aus einem Framing Error generiert), aber der Rückweg zur Ruhelage scheint nicht signalisiert zu werden.
Ich irre überhaupt nicht. Du hast bloss nicht begriffen, was ich geschrieben habe: Dass es mit den Handshakeleitungen regulär geht (siehe mein Link weiter oben) und mit TXD nur mit Trickserei
Das ist keine Trickserei, sonder ein Mechanismus, den es gibt, so lange es RS232 gibt.
, die a) so nur
unter Windows funktioniert
Das ist nun wirklich Unsinn. Linux wäre nicht Linux, wenn es etwas nicht unterstützen würde, was fest zum abzubildenden Standard gehört.
Bezüglich des .net-Serialport kann man sich mit Mono sogar völlig problemlos davon überzeugen, dass das natürlich auch unter Linux funktioniert. Ohne jede Änderung im Code!
Wenn man's allerdings von Hand machen muss, ist es unter Linux doch eine ziemliche Quälerei. Dagegen ist das Win32-API wirklich pures Gold. Zumindest in diesem Punkt. Gehen tut es aber natürlich auch unter Linux.
, b) evtl. nicht mit allen USB-RS232-Adaptern
funktioniert
Dann sind es keine RS232-Adapter. BRK gehört ganz unbezweifelbar zum RS232-Standard. Tat das von Anbeginn an.
Mir ist auch noch keiner untergekommen, der das nicht korrekt abgebildet hätte. Andererseits würde es mich allerdings auch nicht allzu sehr wundern, wenn es so etwas tatsächlich geben sollte. Es gibt so viel Müll auf dem Markt der USB-Devices, warum nicht auch sowas.
Wenn man sich mit einem rostigen und abgebrochenen Bohrer ein Loch in die Kniescheibe machen* will, dann kann man das so machen.
*) Als "Bohren" würde ich die Aktivität nicht bezeichnen wollen. Schnitzen ist es aber auch nicht.
, die a) so nur unter Windows funktioniert
Das ist nun wirklich Unsinn.
Meine Güte, "c-hater", lies es halt nach:
https://pubs.opengroup.org/onlinepubs/009696699/functions/tcsendbreak.html
Du kannst natürlich versuchen, vor Ablauf des Timeouts das Break "aufzufrischen", aber spätestens dann wird es endgültig ein ekliger Hack.
Mir ist auch noch keiner untergekommen, der das nicht korrekt abgebildet hätte.
CP2102N vor Rev. A02 (2019):
https://pubs.opengroup.org/onlinepubs/009696699/functions/tcsendbreak.html
Wen interessiert, was die schreiben?
Fakt ist: es geht. Beweis aus der Praxis: Mono tut es. Und jeder kann selber nachlesen, wie es das tut. Mono ist schliesslich OS.
CP2102N vor Rev. A02 (2019):
Gut zu wissen. Aber wie ich schon schrieb: Es würde mich bei dem allgemein oft miserablen Niveau von USB-Devices überhaupt nicht überraschen, wenn es sowas gäbe.
Aber: Allein die Tatsache, dass das ein Erratum ist, zeigt jedem logisch denkenden Menschen, dass wohl das Gegenteil (also funktionierendes BRK) wohl eher doch der Normalfall sein muss. Meinst du nicht auch?
Fakt ist: es geht. Beweis aus der Praxis: Mono tut es.
Was genau tut es? Break nach Lust und Laune ein- und ausschalten, oder wird aus dem Einschalten einfach ein handelsübliches Break mit 250-500ms?
Allein die Tatsache, dass das ein Erratum ist
Richtig lesen, das gehört nicht zu den Errata, sondern ist ein neues Feature:
CP2102N revision A02 includes the following new features:
- Send break and stop break command signalling
Und deshalb wird diese Funktionalität auch erst im neuen Datenblatt überhaupt beschrieben:
Version 1.3 of the CP2102N datasheet includes the following changes:
- Added section describing A02 functionality for sending break signaling
Fakt ist: es geht. Beweis aus der Praxis: Mono tut es. Und jeder kann selber nachlesen, wie es das tut. Mono ist schliesslich OS.
Fakt ist: Es geht nicht. Gerade im Mono-Source nachgelesen.
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
Und breakprop() sieht dann so aus:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
D.h. wenn Du unter Mono Break einschaltest, wird ein Standard-Break (250-500ms) gesendet, und das Abschalten hat überhaupt keinen Effekt.
Also keine Nutzung als beliebig ein- und ausschaltbarer Output, und Bit Banging macht damit sehr wenig Spass.
tcsendbreak() transmits a continuous stream of zero-valued bits for a specific duration, if the terminal is using asynchronous serial data transmission. If duration is zero, it transmits zero-valued bits for at least 0.25 seconds, and not more that 0.5 seconds. If duration is not zero, it sends zero-valued bits for some implementation-defined length of time.
--
Unabhängig davon kommt einem noch die Idee, einen verrosteten Konservendosendeckel zu benutzen, um sich zu verstümmeln. Vielleicht als so eine Art Piercing? Wenn man den so halb unter die Haut schiebt, dann gibt das nach einiger Zeit sicherlich interessante Effekte.
Richtig lesen, das gehört nicht zu den Errata, sondern ist ein neues Feature:
Na gut, so kann man natürlich auch verharmlosen, dass man einen Teil des Versprochenen erstmal nicht geliefert hat.
Und immerhin scheint es wichtig genug gewesen zu sein, doch noch nachgerüstet zu werden...
Ich möchte mir z.B. ein Schieberegister an der RS232 bauen.
Erzähle mal mehr was das werden soll.
Guten Morgen Obelix,
vor ca. 30 Jahren hatte ich für meine Kinder eine Baumscheibe mit einem Kreis (dort fährt eine kleine Z-Lok mit zwei Wagen), einem Andreaskreuz und 4 Häusern gebaut. Jetzt sind die Enkel da!
Das Projekt wurde damals mittels RS232 (2 Leitungen) über einen Klinkenstecker verbunden. Programmiert über Turbo Pascal und einem PC mit Dos 6.22!
Jetzt werden wahrscheinlich gleich wieder einige Leute Einspruch erheben, dass man dafür 3 Leitungen + Masse braucht. Nö! Heute würde ich dafür auf der anderen Seite einen AVR bemühen.
Jetzt werden wahrscheinlich gleich wieder einige Leute Einspruch erheben, dass man dafür 3 Leitungen + Masse braucht. Nö!
Kommt drauf an, was man machen will. Deine Beschreibung ist mehr als dürftig, nämlich komplett nichtssagend. Auch das, was Du damals mit Turbopascal und Deinem Klinkenstecker "gezaubert" hast, ist zu vage beschrieben, als daß man das beurteilen könnte.
Heute würde ich dafür auf der anderen Seite einen AVR bemühen.
Und was soll dann der Mist mit dem "Bit-banging"?
Was damals "gezaubert" wurde ist ja hier nicht das Thema. Und nichtssagend würde ich auch nicht behaupten. Wenn Du nicht nur lesen, dumme Kommentare abgeben und mal nachdenken würdest wäre es hilfreicher. Andere können das. Weist Du überhaupt was ein Schieberegister ist?
Weiß jemand, wie man die Signalpegel an der RS232 im Visual Studio 13 setzen und auslesen kann? Danke
Denkst du du hast einen Grünen Daumen? Schau mal, viel frische Luft, kein Kopfaua und Chancen auf ein Erfolgserlebnis. Gärtnern kann dir viel geben. Programmieren nicht.
Heute würde ich dafür auf der anderen Seite einen AVR bemühen.
Ja also, dann spar dir das mit dem Versuch irgendwelche Pins der RS232 setzen zu wollen und nutz einfach einenen USB-UART Adapter. Über diesen schickst du Befehle zum AVR und der kann dir dann dein Schieberegister oder sonstiges bespaßen.
TXD, RTS und DTR setzen und rücksetzen.
Erst war es "RxT" (gibts nicht), wurde aber als RXD interpretiert. Jetzt ist es RTS (gibt es und ist sogar ein Ausgang).
Deine Terminologie ist auch furchtbar.
Ja, ist schon seltsam hier!
Da stellt Mann eine Frage und keiner (außer vielleicht Ob S) bietet eine Lösung an. Sogar als sich Oliver S geirrt hat bekommt er dafür positiven Zuspruch. Es liegt wahrscheinlich daran, dass man ohne positive Wertungen keine negativen vergeben kann. Dann habe ich in einem anderen Forum fast die Lösung dafür gefunden aber ..... Wahrscheinlich können hier einige mit ihrem Halbwissen damit nicht umgehen.
Aber Cyb-Dings setzt dem Ganzen die Krone auf! Jetzt hab ich Kopfaua!
Schaut mal im Tread "Temperatursensor gesucht" nach.
H. H. schrieb
Cybarschloch einfach nicht beachten.
Erwin R. schrieb
Cybarschloch einfach nicht beachten.
Bester Kommentar ever 👍
Da kann ich mich anschließen und sind mir die vielen positiven Bewertungen verständlich!!
Wo bleibt die Ignorierfunktion?? (Idee von H.H.) Seht euch doch mal den Umgang miteinander in anderen Foren an!
Jetzt hab ich Kopfaua!
Sag ich doch. Diese ganzen Begriffe, die sind zu viel für dich. Du hast es nicht einmal geschafft, grundlegende Signale der seriellen Schnittstelle korrekt zu benennen. Deshalb mach was anderes. Jeder kann etwas.
Da stellt Mann eine Frage
Eine idiotische Frage. Bit-Banging auf seriellen Schnittstellen ist idiotisch. Früher, "da hatten wir ja nichts", war das auch schon idiotisch, aber für den Notfall hinnehmbar.
Was hat das eigentlich mit Deinem Geschlecht zu tun?
Wie willst du denn dann die Leitungen RTS/CTS als Handshake mit einbeziehen um eine sichere Datenübertragung zu realisieren?
Da stellt Mann eine Frage und keiner (außer vielleicht Ob S) bietet eine Lösung an.
Doch, Du ignorierst sie bloss (oder begreifst sie nicht).
https://learn.microsoft.com/en-us/dotnet/api/system.io.ports.serialport?view=net-9.0-pp
Da steht alles drin. Von RtsEnable bis CtsHolding, sogar BreakState für den tollen TXD-Hack.
Wie willst du denn dann die Leitungen RTS/CTS als Handshake mit einbeziehen
Das hat mit Bit-Banging nichts zu tun. Nur fossile Uarts aus der vorderen Altsteinzeit, also so etwas wie 8250 oder 16450, das Zeug, das vor 30 Jahren in PCs verbaut wurde, hat keine Hardwareunterstützung für Handshake, da muss man das per Software erledigen. Das machte man damals in einer entsprechenen ISR (oder das ganze wurde sehr, sehr behäbig).
Heutige UARTs, gerade die in Form von USB-Seriell-Bridges üblichen, können sich aber selbst um Hardwarehandshake kümmern, und die Devicetreiber, die mit ihnen kommunizieren, können das auch entsprechend konfigurieren.
Weiß jemand, wie man die Signalpegel an der RS232 im Visual Studio 13 setzen und auslesen kann?
Zuerst brauchst du einen Treiber für RS232 und das passende Windows. In der FH in Hamburg gibt es auch Hardwareprogrammierungen, da könnte man auch mal nachfragen, ob die was passendes haben.
Zuerst brauchst du einen Treiber für RS232 und das passende Windows. In der FH in Hamburg gibt es auch Hardwareprogrammierungen, da könnte man auch mal nachfragen, ob die was passendes haben.
Natürlich und dann noch eine Audienz beim Papst.
ODER man die vorhandene SerialPort Klasse und hat bereits alles was man braucht. Ach ne, Skill braucht man auch noch. Stimmt.
Natürlich und dann noch eine Audienz beim Papst.
Ist ja auch gleich um die Ecke, da bekommt man auch sehr gutes Olivenöl, schöne Pizzas, billige Reifenangebote..
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.