RS232 lesen im bitbanging, Nummernschalter abfragen

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
Rediensch
User
Beiträge: 6
Registriert: Dienstag 21. Februar 2017, 16:04

Hallo miteinander,
ich suche eine Betriebssystemunabhängige Programmiersprache, um einen Nummernschalter (Telefonwählscheibe) über die RS232 als Eingabegerät benutzen zu können. Dazu muß ich zwei Leitungen der RS232 im bitbanging abfragen können. Die RS232 Module der python Bibliotheken können nur standard- RS232 Kommunikation (serielles Wort mit definierter Wortlänge und Boudrate). Wer weiß, ob überhaupt und wenn wie das RS232 bitbanging in Python funktionieren könnte?

--

Mit freundlichen Grüßen, best regards,
Dipl.-Ing. Ulf Schneider
Sat- Service Schneider
Funk- und Fernmeldetechnik
Landsberger Str. 62a
04736 Waldheim
Germany
Tel.: +49(0)34327/92809
Fax : +49(0)34327/90394
www.sat-schneider.de
BlackJack

@Rediensch: Ist die erste Frage nicht ob man überhaupt an die Leitungen von der seriellen Schnittstelle heran kommt und wenn ja *wie*? Mir scheint Du suchst eher so etwas wie GPIOs die man wirklich unabhängig und frei Ansteuern kann, wo kein UART-Chip ”im Weg” ist.

Man braucht also zur Software noch eine Hardware. Es gibt wohl von FTDI USB<->Serial-Konverter die einen ”bit banging”-Modus haben. Oder man bastelt sich etwas mit einem Microcontroller (Arduino & Co), oder einem Raspi (Zero).
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

Zuerstmal muss dein RS232 Pegel zu einem TTL-Pegel gewandelt werden - da gibt's den MAX232, in seinen verschiedenen Varianten. Und dessen TTL-Ausgang musst du dann auf einen GPIO deines Rechners legen, wie BlackJack schon angedeutet hat.
Rediensch
User
Beiträge: 6
Registriert: Dienstag 21. Februar 2017, 16:04

Erst einmal vielen Dank für die Antworten.
Ich hätte aber aus verschiedenen Gründen gern die vorhandene RS232 benutzt.
Es muß irgendwie über die RS232 gehen.
In Visual Basic geht es auch, siehe hier: http://archiv.bwir.de/schaltungen/winampwaehlscheibe
Nur ist mir Visual Basic zu umständlich (zu groß, riesige Bibliotheken, *.dll, Versionsprobleme, keine Betriebssystemübergreifende Funktion).
Eine Spannungsquelle und auch ein Pegelkonverter wäre nicht nötig, wenn man einfach die andauernd High geschaltete RTS- Leitung als Spannungsquelle nutzt. Der nsa Kontakt schaltet dann von diesem Plus die DSR- Leitung und der nsi/nsr Kontakt die CTS Leitung.
Damit kann der Nummernschalter einfach nur über 3 Drähte ohne weitere Hardware mit der RS232 kommunizieren.
Also muß die RTS Leitung statisch High gesetzt werden und DSR und CTS abgefragt werden können. Die DSR Leitung muß ständig abgefragt werden, sie kündigt mit L>H eine bevorstehende Impulsfolge an und mit H>L das Ende des Impulstelegramms. Auf der CTS Leitung müssen dann die Impulse entprellt und gezählt werden, während DSR High ist. Programmtheoretisch alles ganz einfach. Wie aber kann man direkt auf die 3 Leitungen zugreifen, ohne das serielle RS232 Kommunikationsprotokoll benutzen zu müssen?
Rediensch
User
Beiträge: 6
Registriert: Dienstag 21. Februar 2017, 16:04

Es hat sogar ein EXEL MAkro für diese Aufgabe gegeben, es benutzt eine RSAPI.dll zur Schnittstellenkommunikation.
Der Link ist geplatzt, die RSAPI.dll findet man hier: http://www.b-kainka.de/rsapidll.zip

Ich bin zwar Hardwaremensch mit nur rudimentären Programmierkenntnissen, aber wenn es unter Visual BAsic geht und sogar unter EXEL, muß es auch mit Python sicher irgendwie gehen. Oder liege ich da falsch?
BlackJack

@Rediensch: Was spricht gegen PySerial? Sofern die Hardware und der Treiber das mitmachen, sollte das damit gehen.
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

Hast du denn mal die bestehenden Calls ausprobiert? Dabei sollte ja unerheblich sein, dass die COM-Schnittstelle nebenbei offen ist.

https://github.com/pyserial/pyserial/bl ... 32.py#L397
Idefix_1024
User
Beiträge: 19
Registriert: Montag 11. Januar 2010, 14:36

wenn diese besagten Lösungen schon bekannt sind, warum nicht "einfach" die dll der alten Lösung nehmen und unter Python mit ctypes ansprechen?

Dann kann man das VBA Skript in Python nachbauen und die Funktionen in der dll aufrufen... das macht dann praktisch das Gleiche wie das VBA Skript und man braucht nur die eine dll-Dateil mit der einen Python Datei und zB winPython auf einen USB Stick legen und hat alles in der Hosentasche was man braucht...
wäre das evtl eine Lösung?
PySerial hat wahrscheinlich das Problem, dass man nicht nahe genug an den einzelnen Bits ist... das vereinfacht die Arbeit im Normalfall aber hier ist es eher hinderlich
Rediensch
User
Beiträge: 6
Registriert: Dienstag 21. Februar 2017, 16:04

Na ja, die fehlende Shnittstellennähe ist ja mein Problem. Ein Jungstudent suggerierte mir, das gänge alles wieder mit Pyton so einfach wie früher.
Er zeigte mir auch nur wenige Zeilen PYthon Programmcode, mit der er serielle Schnittstellenkommunikationaufbauen konnte.
Angeblich ohne *.dll und ohne Compilieren, so wie ich das von früher mit FORTH oder BASIC Interpreter kenne. Das hat mich bewogen, mich mit Python beschäftigen zu wollen.
Ich bin 60 Lenze und habe mein letztes Programm, ein Steuerprogramm für einen Motorprüfstand ca. 1984 auf einem U880 (Z80) Heimcomputer geschrieben.
Da war alles noch einfach und hardwarenah. OUT LPT1 (bitwort) und 8 Harwareleitingen waren ohne Firlefanz gesetzt oder mit IN LPT1 gelesen.
Timer brauchte man nicht, PAUSE 20 waren immer 20 Taktzyklen Pause. Zeit messen konnte man anhand der Taktzyklenzahl in Schleifenabfrage, bis eine Leitung sich geändert hat. Die erforderlichen 12Bit A/D Wandler habe ich als R2R netzwerk mit Komparator noch selbst zusammengelötet.
Nein, ich will nicht zurück zu 256K Arbeitsspeicher, wie ihn mein erster selbst zusammengelöteter Computer AC1 hatte. Owohl man damit noch richtige Erfolgserlebnisse hatte! Da es für Privat noch keine Drucker gab, hatte ich eine Fernschreibmaschine dazu zweckentfremdet, die von nur einer RS232 Leitung über einen Schalttransistor an 60V getrieben wurde. Der ganze Aufstand mit Compilieren und *.dll Treibern hat mich von weiteren Programmieraktivitäten unter Windows oder LINUX abgeschreckt.
Bei Pyton soll das wieder einfacher sein.
Na ja, schaun wir mal. Jedenfalls ist das Schnittstellen- Modul (CALL) mit 400 Zeilen nicht das, was ich mir vorstelle.
BlackJack

@Rediensch: So einfach wie früher geht das natürlich nicht. Python kann nicht auf magische Weise das Betriebssystem umgehen um näher an der Hardware dran zu sein. Python ist eine „high level language“, das heisst abstrahiert deutlich mehr von der Maschine als beispielsweise Forth, C, oder Pascal. Das will man ja aber eigentlich auch, denn dadurch wird die Sprache einfacher zu benutzen. Man muss sich weder um die Speicherverwaltung kümmern, noch um Stapeleffekte wie bei Forth. Es geht also eher in Richtung BASIC. Man kann sich bei den Problemlösungen mehr um die Lösung des Problems kümmern, ohne ständig auf der Ebene der Maschine die darunter liegt, denken zu müssen. Was in dem Fall wo direkte Kommunikation mit Hardware das Ziel ist, natürlich nicht mehr geht. Aber auch da ist Python IMHO mit dem `ctypes`-Modul ganz gut aufgestellt, weil man damit externe Bibliotheken die in anderen Sprachen geschrieben sind, und Betriebssystemschnittstellen ansprechen kann. Man kann damit problemlos BASICs `PEEK()` und `POKE` in reinem Python implementieren. Nur dass einem das unter den meisten Betriebssystemen nicht viel nützt, da man damit erst einmal nur auf den eigenen Adressraum zugreifen kann, der vom System, anderen Prozessen, und der Hardware isoliert ist.

``IN LPT1`` und ``OUT LPT1`` klingt nach Parallelport. *Den* kann man auch am PC auf diese Weise nutzen, nur dass heutzutage kaum ein PC noch so einen Anschluss besitzt. Über diese Schnittstelle lief früher eine ganze Menge selbstgebastelter Hardware am PC. Ich hatte beispielsweise einen D/A-Wandler für Tonausgabe und die ersten Schaltungen um Laufwerke und Drucker vom C64 an den PC anzuschliessen. Aktuelle Lösungen setzen dafür auf Microcontroller zur Ansteuerung der alten Hardware und USB-Verbindung zum PC.

Wenn man ein ”Erlebnis” haben möchte, welches in die Richtung der 8-Bitter aus den 80ern und 90ern geht, dann nimmt man heutzutage einen Microcontroller oder einen Einplatinenrechner wie den Raspberry Pi oder eines der Produkte die auf diesen Trend aufgesprungen sind.

Am nähsten zu ”früher” kommt der Microcontroller, der in der Regel in C programmiert wird und wo man wirklich die totale Kontrolle hat, weil es kein Betriebssystem gibt und das eigene Programm das einzige ist was läuft.

Die Einplatinenrechner haben normalerweise ein Linux als Betriebssystem. Es ist also ein wenig ”unübersichtlicher” und ”ungenauer” weil man ein ganzes Betriebssystem laufen hat. Das macht die Programmierung auf der anderen Seite aber auch bequemer, eben weil man ein ganzes, erstaunlich normales Betriebssystem laufen hat. Damit dann auch alle möglichen Programmiersprachen, unter anderem auch Python. Und für die Hardwarebasteleien mindestens digitale „general purpose I/O“-Pins (GPIOs). Mit der entsprechenden Bibliothek sieht dann die Programmierung mit Python recht einfach aus.

Wobei man sich an der Stelle aber auch nicht täuschen sollte. IMHO ist Python keine leichte Programmiersprache, also mindestens mal deutlich komplexer als 8-Bitter BASIC-Dialekte. Man kann damit Programme schreiben die leicht(er) zu lesen und zu verstehen sind, als in einigen anderen Sprachen. Dazu muss man die Sprache und die Paradigmen der strukturierten, der funktionalen, und der objektorientierten Programmierung lernen. Nichts davon hatte man bei den BASIC-Dialekten der 8-Bit-Ära. Dazu kommt dann noch nebenläufige Programmierung wenn man nicht ständig „busy waiting“ mit den I/O-Pins betreiben möchte und ereignisbasierte Programmierung wenn es in Richtung GUI geht, oder auch wenn man sich eine eigene Ereignisschleife für die GPIO-Behandlung schreiben möchte. Wobei man die letzten beiden Punkte von ”früher” ein bisschen kennt wenn man dort mit Maschinensprache und Interrupts zu tun hatte.
Benutzeravatar
Sr4l
User
Beiträge: 1091
Registriert: Donnerstag 28. Dezember 2006, 20:02
Wohnort: Kassel
Kontaktdaten:

Also ich würde nen Mikrokontroller nehmen aber bitbanging müsste doch mit pySerial übe: setRTS() setDTR() getCTS() getDSR() getRI() getCD() gehen.
(vgl. https://github.com/pyserial/pyserial/bl ... il.py#L577 ). Alle Funktionen sind jedoch "backwards compatibility / deprecated functions".

Auch befürchte ich das RS232 bitbanging über USB Adapter (je nach Geschwindigkeit) nicht unbedingt das zuverlässigste ist. Je nach PC, USB Adapter und Betriebsystem Kombination meine ich.
BlackJack

@Sr4l: Die sind „deprecated“ weil es dafür mittlerweile Properties auf dem `Serial`-Objekt gibt, die sich dann auch an die Namenskonventionen halten. Also statt ``port.setDTR(True)`` oder ``bit = port.getDSR()`` sollte man in neuem Code ``port.dtr = True`` und ``bit = port.dsr`` schreiben. Man sieht das ja an der Implementierung der Methoden die Du verlinkt hast, die machen genau das. :-)
Rediensch
User
Beiträge: 6
Registriert: Dienstag 21. Februar 2017, 16:04

Aha, jetzt verstehe ich. Das Modul "serial" ist eine Art Treiber. Also den erstmal runterladen.
Muß ich serial in das Verzeichnis vom Interpreter kopieren, oder wohin sonst ?
Dann pip install serial und schon könnte ich mal versuchen statisch mit den 3 Leitungen über die Kommandos pot.get und port.set spielen?
Wie muß ich die Schnittstelle COM 1 vorher initialisieren oder mounten?
BlackJack

@Rediensch: Das `serial`-Modul würde ich jetzt nicht als Treiber bezeichnen. Das bietet eine plattformunabhängige API für die serielle Schnittstelle. Das heisst hinter den Kulissen wird die jeweilige API des Systems angesprochen. Von dem Windows-Teil hast Du ja schon ein wenig Code gesehen.

Zum Installieren bitte nichts manuell irgendwo hin kopieren sondern die normalen Wege verwenden, also beispielsweise ``pip``. Ein ``python -m pip install pyserial`` lädt das Package herunter und installiert es für den Python-Interpreter den man für diesen Aufruf verwendet hat. Anstelle von ``python`` kann/muss man das eingeben was man eingibt um den Interpreter zu starten. Also beispielsweise ``python3`` wenn es ein 3er Python ist, oder auch den kompletten Pfad zum Programm wenn das nicht im Suchpfad für Programme liegt.

Ob Du in Deinem System vorher noch irgend etwas machen musst um die serielle Schnittstelle verwenden zu können, also beispielsweise irgendwo aktivieren, einhängen, Treiber installieren, Kernelmodule laden, oder sonstwas, hängt vom System ab. Wenn COM 1 eine normale serielle Schnittstelle ist, die im Rechner verbaut ist, dann war es IIRC früher bei Windows zumindest so, dass die einfach da war.

Ich habe das Modul eben gerade auf meinem OSMC-Raspi installiert:

Code: Alles auswählen

$ sudo -H python -m pip install pyserial                             
Collecting pyserial
  Downloading pyserial-3.2.1-py2.py3-none-any.whl (189kB)
    100% |████████████████████████████████| 194kB 196kB/s 
Installing collected packages: pyserial
Successfully installed pyserial-3.2.1
$ python -m serial.tools.list_ports
/dev/ttyAMA0        
1 ports found
Wie man sieht ist dort das Kernelmodul für die serielle Schnittstelle bereits geladen, ohne das ich da irgend etwas spezielles für tun musste. Bei Raspbian sollte das auch der Fall sein. AFAIK ist die dort allerdings auch schon in Verwendung weil da IIRC die Bootkonsole drauf läuft danach auf eine Benutzeranmeldung wartet. Kann sein das OSMC das übernommen hat.

Die Getter- und Settermethoden sollte man nicht mehr verwenden, die sind „deprecated“, also veraltet. Das ist normalerweise der erste Schritt so etwas aus Bibliotheken in Folgeversionen zu entfernen. Die entsprechenden Leitungen gibt es als „properties” auf `Serial`-Exemplaren, also berechnete Attribute. Wenn man die abfragt oder denen etwas zuweist, dann wird Code ausgeführt.
Rediensch
User
Beiträge: 6
Registriert: Dienstag 21. Februar 2017, 16:04

Na gut, dann werde ich den Interpreter auch gleich unter Knoppix installieren und dort weitermachen, nicht unter Windows.
Ich habe auf allen meinen Linux Rechnern Knoppix fest installiert, weil das die Ditribution war, die mit zwei Graphikkarten (eine onboard und eine gesteckte) klarkam. Ubuntu hat da das Handtuch geworfen und schon beim Installieren nur Farbchaos auf dem Monitor gezeigt. Außerdem hat Knoppix (verglichen mit Ubuntu) die meißte gut ausgesuchte Usersoftware gleich beim Installieren mit an Bord. Ich kann auch ohne Probleme den Fileserver in meinem Windows- Netzwerk connecten und mounten, auch freigegebene Platten auf allen Windows Rechnern im Netzwerk kann ich mounten. Ist schon eine feine Sache das Knoppix, arbeite viel lieber damit als mit Windows.
Ich wußte gar nicht, daß der Raspberry Pi eine RS232 hat, ich dachte immer, der hat nur I/O Ports.
BlackJack

@Rediensch: Der Raspi hat keine RS232-Schnittstelle aber eben die GPIOs und auch einen UART der mit bestimmten Pins verbunden ist, so dass man sich damit eine RS232-Schnittstelle basteln kann. Also die bereits angesprochene Pegelwandlung mit einem MAX3232 und eine Sub-D-Buchse zusammenlöten. Erster Suchtreffer für „raspberry pi rs232“: Add a 9-pin Serial Port to your Raspberry Pi in 10 Minutes. Oder man verwendet ein passendes USB-to-Serial-Kabel.
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

Wobei man beim PI sich den ganzen UART-Kram natuerlich auch sparen kann, und nur die Pegel wandeln, um ueber die GPIOs die Nummernschalter abzufragen. das habe ich sogar fuer einen Freund schon mal implementiert - das entprellen war extrem wichtig :)
Antworten