RS232 Interface /ttyAMA0 mit phyton abfragen

Python auf Einplatinencomputer wie Raspberry Pi, Banana Pi / Python für Micro-Controller
SolarGuido
User
Beiträge: 21
Registriert: Donnerstag 17. August 2017, 07:10

Guten Tag,

ich habe mich bisher Null mit Phyton beschäftigt und komme mehr aus der php/html/js/sql Welt. Nun habe ich aber einen Pi2 und einen Pi3 zu Hause die ich als Interface nutzen möchte um daten von meinen Invertern zu visualisieren (Web Seite).
Ich habe dazu bisher ein Programm genutzt welches dies auf dem Pi hervoragend tut jedoch nur für einen Inverter. Der andere wird nicht erkannt das die Schnittstelle dort anders angesprochen wird.

Nun zum Problem
Da ich mit phyton noch nie etwas zu tun habe kommen sicherlich einige dumme Fragen , bitte dies zu entschuldigen.

Ziel ist es über /ttyAMA0
das Communication format wie folgt einzustellen:
Baud rate Start bit Data bit Parity bit Stop bit
2400 1 8 N 1

Code: Alles auswählen

   ser = serial.Serial(
        port='/dev/ttyAMA0',
        baudrate=2400,
        parity=serial.PARITY_NONE,
        stopbits=serial.STOPBITS_ONE,
        bytesize=serial.EIGHTBITS
    )
wie mache ich das start bit=1?

dann muss über rs232 flgendes an den Inverter gesendet werden in HEX Code :
QPIGS <CRC><cr>
HEX Code-> 5150494753BEAC0D
wobei <CR> wohl xBEAC
Also denke ich muss ich folgendes an die RS schicken:

Code: Alles auswählen

    print(ser.isOpen())
    data = "\x51\x50\x49\x47\x53\xBEAC\x0D\"
    ser.write(data)
    print(ser.write(data))
->Ich bin nicht sicher ob xBEAC so funktioniert...
Ist der <CR>


dann schickt der Inverter folgendes zurück in HEX:
(BBB.B CC.CC DD.DD EE.EE FF.FF GGGG ±HHH II.II ±JJJ KKKK
b7b6b5b4b3b2b1b0 <CRC><cr>

also 73 zeichen bis b0

Code: Alles auswählen

    ser.read()
    print(map(hex,map(ord,ser.read(73)))) 
    ser.close()

Wie gesagt ich habe noch nie was mit Phyton gemacht, und google mir gerade so was zusammen.

Wenn beim Aufruf des von mir gebastelten scripts(aus anderen Codes abgekupfert) etwas von der rs232 zurück bekommen würde und es sehen könnte, wäre ich happy. Dann würde ich mich mit den nächsten Schritten beschäftigen.

BITTE GUCKT DOCH DEN CODE MAL DURCH UND GEBT MIR FEEDBACK.

Ich würde mich um etwas Unterstützung dabei sehr freuen. Bin sicher das für die Profis hier so etwas kein Problem ist.

übrigens so etwas in der Art kommt da derzeit bei raus ist der erste Inverter:
https://emoncms.org/dashboard/view?id=43195
und
http://solar.fahremit.de/test2.php
Zuletzt geändert von Anonymous am Donnerstag 17. August 2017, 09:00, insgesamt 1-mal geändert.
Grund: Quelltext in Python-Codebox-Tags gesetzt.
BlackJack

@SolarGuido: Erst einmal gaaaanz wichtig: Die Programmiesprache heisst Python und nicht Phyton. :-)

`parity`, `stopbits`, und `bytesize` sind die Default-Werte, die muss man dann also nicht unbedingt angeben.

Das Ausgeben von `ser.isOpen()` sollte überflüssig sein, denn wenn man dem `Serial`-Exemplar beim erstellen einen Port übergeben hat, dann *ist* die Verbindung danach offen, oder man bekommt eine Ausnahme.

Was genau erwartet die Gegenseite? Zweistellige Hexadezimalwerte als ASCII-Zeichen pro Byte, oder einfach nur Bytes? Denn 'QPIGS' *kann* man auch als '\x51\x50\x49\x47\x53' schreiben, aber wirklich *sinnvoll* ist das *nicht*, weil das ein Mensch dann schlechter lesen kann.

Code: Alles auswählen

In [6]: 'QPIGS' == '\x51\x50\x49\x47\x53'
Out[6]: True
Die Prüfsumme zur Hälfte als Byte und zur Hälfte als zwei Buchstaben zu senden ist sicher falsch. Bei Zahlwerten mit mehr als einem Byte stellt sich auch die Frage in welcher Reihenfolge die Gegenseite diesen Wert erwartet.

Wahrscheinlich musst Du das hier senden: 'QPIGS\xbe\xac\r', oder das hier: 'QPIGS\xac\xbe\r'.

Und zwar nur einmal und nicht zweimal wie in Deinem Beispielcode!?

Warum lässt Du im Text bei <CR> immer das C weg? Das ist verwirrend weil Du in dem Protokoll eine Prüfsumme hast <CRC> („cyclic redundancy check“) und das ASCII-Zeichen für einen Wagenrücklauf <cr> („carriage return“).

Was als Antwort kommt habe ich nicht wirklich verstanden. Und Du solltest auch da präzise sein mit Zeichen und Bytes und was Du unter „HEX“ verstehst. Ich vermute ja einfach mal das da Bytes zurück kommen.

Ich denke Du solltest Dich da nicht an einer Byteanzahl orientieren, denn die Nachrichten sind ja offenbar in beide Richtungen durch Wagenrückläufe abgeschlossen. Man sollte also einfach Zeilen lesen können.
SolarGuido
User
Beiträge: 21
Registriert: Donnerstag 17. August 2017, 07:10

BlackJack hat geschrieben:@SolarGuido: Erst einmal gaaaanz wichtig: Die Programmiesprache heisst Python und nicht Phyton. :-)
Danke :-) vieleicht läuft deswegen das ganze nicht so wie ich mir erhoffte
`parity`, `stopbits`, und `bytesize` sind die Default-Werte, die muss man dann also nicht unbedingt angeben.
Ok Danke!

Was genau erwartet die Gegenseite? Zweistellige Hexadezimalwerte als ASCII-Zeichen pro Byte, oder einfach nur Bytes? Denn 'QPIGS' *kann* man auch als '\x51\x50\x49\x47\x53' schreiben, aber wirklich *sinnvoll* ist das *nicht*, weil das ein Mensch dann schlechter lesen kann.
Also in der Doku von der Schnittstelle steht:
QPI CRC value is: 0xBEAC

QPI: 0x51 0x50 0x49

Return: 0x0D

The QPI command (HEX value) sent to unit is: 515049BEAC0D


Also es wird wohl erwartet das Comando im HEX Werten zu senden deshalb war dies mein Ansatz. Eventuell geht das aber auch einfacher
Ich muss diesen Code senden:
QPIGS <CRC><cr>
und das in einem HEX code deshalb . Lesen muss das auch kein Mensch denn es soll ja nur gesendet werden damit das Gerät mir die Werte zurück schickt auch in HEX code wie schon beschrieben.
Hier ist die Doco dazu:
https://drive.google.com/file/d/0B86Jix ... sp=sharing
Die Prüfsumme zur Hälfte als Byte und zur Hälfte als zwei Buchstaben zu senden ist sicher falsch. Bei Zahlwerten mit mehr als einem Byte stellt sich auch die Frage in welcher Reihenfolge die Gegenseite diesen Wert erwartet.

Wahrscheinlich musst Du das hier senden: 'QPIGS\xbe\xac\r', oder das hier: 'QPIGS\xac\xbe\r'.
ich verstehe es nicht ganz nur das ich das schicken soll in Hex Werten:
QPIGS <CRC><cr>
Und zwar nur einmal und nicht zweimal wie in Deinem Beispielcode!?
so jede sekunde immer diesen befehl und dann kommen die Werte zurück
Warum lässt Du im Text bei <CR> immer das C weg? Das ist verwirrend weil Du in dem Protokoll eine Prüfsumme hast <CRC> („cyclic redundancy check“) und das ASCII-Zeichen für einen Wagenrücklauf <cr> („carriage return“).

Was als Antwort kommt habe ich nicht wirklich verstanden. Und Du solltest auch da präzise sein mit Zeichen und Bytes und was Du unter „HEX“ verstehst. Ich vermute ja einfach mal das da Bytes zurück kommen.

Ich denke Du solltest Dich da nicht an einer Byteanzahl orientieren, denn die Nachrichten sind ja offenbar in beide Richtungen durch Wagenrückläufe abgeschlossen. Man sollte also einfach Zeilen lesen können.
Ich hoffe es ist jetzt etwas klarer geworden, Danke für deine Unterstützung
BlackJack

@SolarGuido: Der CRC-Wert für 'QPI' ist der gleiche wie für 'QPIGS'? Das ist sehr unwahrscheinlich.

Lesen muss das natürlich ein Mensch: Du und jeder den den Quelltext liest.

Und da das alles sehr nach ASCII aussieht kann ich mir auch kaum vorstellen das man da tatsächlich pro Byte zwei ASCII-Zeichen verwenden soll die den Bytewert als Hexadezimalzeichen kodieren. Davon steht auch nichts in der von Dir verlinkten Dokumentation. Insbesondere finde ich da auch das Zitat nicht drin‽

Du sendest das in Deinem Code zweimal hinterheinander, einmal ohne irgendwas und einmal mit einem `print()` — ohne dazwischen mal Werte zu empfangen. Das sieht mir falsch aus. Und auch beim Empfangen hast Du zweimal hintereinander `read()` stehen.

Ich bezweifle das mit dem schicken in Hexadezimaldarstellung der Bytewerte wirklich sehr stark. Dann wird das Lesen auch umständlicher. Man muss dann nämlich in einer Schleife byteweise, beziehungsweise immer zwei Bytes lesen, solange bis man '0D' gelesen hat. ``response = next(ser)`` aufrufen wäre da deutlich einfacher.

Allerdings habe ich gerade ein kleines Problem mit der Prüfsumme: Wenn die tatsächlich als 16-Bit-Wert im High/Low-Format gesendet werden soll, wird da irgendwo garantiert das keines der beiden Bytes den Wert 13 (Hex: 0D) hat? Denn ansonsten ist das Endkennzeichen einer Nachricht nicht mehr eindeutig und das Gerät muss die Nachrichten(länge) sowieso schon am Inhalt erkennen, was ein 0D am Ende überflüssig machen würde. Und das ist unabhängig davon ob Bytewerte oder die Hexadezimaldarstellung von Bytewerten gesendet werden. Und man selbst muss auch die Längen der Nachrichten kennen die man erwartet. Macht das lesen natürlich wieder etwas einfacher, aber ein schönes Protokoll sieht anders aus.
SolarGuido
User
Beiträge: 21
Registriert: Donnerstag 17. August 2017, 07:10

BlackJack hat geschrieben:@SolarGuido: Der CRC-Wert für 'QPI' ist der gleiche wie für 'QPIGS'? Das ist sehr unwahrscheinlich.

Lesen muss das natürlich ein Mensch: Du und jeder den den Quelltext liest.
Ja ich habe nur dieses Zitat hat mir die Firma geschickt die das Teil verkauft mit dem Hinweis das Sie eigentlich dafür keinen Support leisten und ein C-Programm was ich nicht verstehe da ich wie schon geschrieben keine Ahnung habe :-(.

Der Rückgabe Wert ist auch nicht so entscheidend denn ich weiß welche Werte da kommen und würde Sie entsprechend nachbearbeiten. Wichtig ist nur erst mal das was kommt...

Der Hinweis mit CRC WERT für QPI hat mir geholfen glaube ich, ich wußte mit <CRC> nix anzufangen und habe angenommen das es immer das selbe ist...

hier das CProgramm, was mir die Firma mit geschickt hat verstehe ich aber nicht hat was mit dem CRC zu tun denke ich :

Code: Alles auswählen

INT16U cal_crc_half(INT8U far *pin, INT8U len)
{

	INT16U crc;

	INT8U da;
	INT8U far *ptr;
	INT8U bCRCHign;
    INT8U bCRCLow;

	INT16U crc_ta[16]=
	{ 
		0x0000,0x1021,0x2042,0x3063,0x4084,0x50a5,0x60c6,0x70e7,

		0x8108,0x9129,0xa14a,0xb16b,0xc18c,0xd1ad,0xe1ce,0xf1ef
	};
	ptr=pin;
	crc=0;
	
	while(len--!=0) 
	{
		da=((INT8U)(crc>>8))>>4; 

		crc<<=4;

		crc^=crc_ta[da^(*ptr>>4)]; 

		da=((INT8U)(crc>>8))>>4; 

		crc<<=4;

		crc^=crc_ta[da^(*ptr&0x0f)]; 

		ptr++;
	}
	bCRCLow = crc;

    bCRCHign= (INT8U)(crc>>8);

	if(bCRCLow==0x28||bCRCLow==0x0d||bCRCLow==0x0a)

    {
    	bCRCLow++;
    }
    if(bCRCHign==0x28||bCRCHign==0x0d||bCRCHign==0x0a)

    {
		bCRCHign++;
    }
    crc = ((INT16U)bCRCHign)<<8;
    crc += bCRCLow;
	return(crc);
}
ich hab jetzt noch mal nach dem CRC gegoogelt und etwas gefunden:
http://forums.aeva.asn.au/viewtopic.php?t=4332&start=25

Anscheinend ist das ein Code mit dem der CRC berechnet wird :-(

Ich habs mir einfacher vorgestellt... schade...
Zuletzt geändert von Anonymous am Donnerstag 17. August 2017, 13:54, insgesamt 1-mal geändert.
Grund: Quelltext in Codebox-Tags gesetzt.
BlackJack

@SolarGuido: Der Rückgabwert ist in sofern entscheidend, das man den komplett lesen muss wenn das ein Halbduplex-Protokoll ist, sonst kann es passieren das der Sender blockiert wenn man ihm seine Daten nicht abnimmt.

Das C-Programm beziehungsweise die Funktion ist die Funktion nach der der CRC-Wert berechnet wird. Das müsste man also nach Python portieren. Und wie man am Ende der Funktion sieht, stellt die tatsächlich sicher, dass keine Zeilenendenzeichen, Wagenrückläufe, und öffnende runde Klammern in dem Bytewerten vorkommen können, also ist IMHO ziemlich sicher das die Nachrichten mit einem Wagenrücklauf abgeschlossen werden und als Bytewerte übertragen werden und nicht als Hexadezimalrepresentation als ASCII-Zeichen.
SolarGuido
User
Beiträge: 21
Registriert: Donnerstag 17. August 2017, 07:10

Bild

in einem Italienischen Forum hat jemand ein Tool genutzt und danach sieht es so aus das es doch ein normaler Code ist ?

Ich werde mal ein Port Sniffer installieren und rum testen, die Hinweise haben mir aber schon eine neue Richtung gegeben Danke dir.

und gerade habe ich folgendes herausgefunden:

CRC-CCITT (XModem) 0xBEAC für 515049
Also ist -> 0xB7A9 der CRC für QPIGS :D :D :D

ich denke damit kann ich jetzt mal weiter machen 1000% Dank du hast mir richtig weiter geholfen :)
SolarGuido
User
Beiträge: 21
Registriert: Donnerstag 17. August 2017, 07:10

Hallo ich möchte den Erfolg gerne teilen es hat geklappt und das viel einfacher als ich es mir erdacht habe .

Wichtig für alle die das selbe Problem haben

der <CRC> Code ist CRC-CCITT (XModem) vom Code davor kann man z.B. hier ausrechnen:
https://www.lammertbies.nl/comm/info/cr ... ation.html

Hier nun die Rückgabe vom Wert QPIGS (funktioniert auch mit allen anderen codes super) in der Entwicklungsumgebung Python2:

Code: Alles auswählen

Python 2.7.9 (default, Sep 17 2016, 20:26:04) 
[GCC 4.9.2] on linux2
Type "copyright", "credits" or "license()" for more information.
>>> import serial
>>> ser = serial.Serial(port='/dev/ttyAMA0',baudrate=2400)
>>> data = "\x51\x50\x49\x47\x53\xB7\xA9\x0D"
>>> ser.write(data)
8
>>> ser.read(68)
'(024.7 25.23 00.00 00.00 00.00 0000 +030 25.16 -030 0000 00000000\xfd\x14\r'
>>> 
genau das was ich wollte , nochmals danke.

Der nächste Schritt wäre jetzt die Rückgabe in eine form zu bringen und eine html seite aufzurufen:

ungefähr so: http://localhost/?wert1=024.7&wert2=25.23 usw...

in PHP wüßte ich jetzt wie ich das mache oder kann ich den Rückgabe Wert ggf direkt mit phyton in eine locale sql tabelle schreiben oder notfalls auch in ein file schreiben ?

Wenn Ihr mir hier noch einen Tipp geben könntet :mrgreen:
Also Rückgabe warscheinlic in einen data string schreiben und den dann zerpflücken? ->die Positionen sind Statisch.
dann neuen String bauen (die URL)
Dann diese aufrufen (wenn Python das kann) ?

Das wäre es schon danach verarbeite ich das in PHP /SQL und HTML mit js weiter :D

Für diverse Hilfestellungen wäre ich sehr dankbar
SolarGuido
User
Beiträge: 21
Registriert: Donnerstag 17. August 2017, 07:10

ok auch das ist nicht so schwer habs super schnell hinbekommen :-)

ich schreibe die antwort aus dem Read in ein string
danach mit teilstring [x:y] bildung bilde ich die URL string
dann die url lib einbinden
die url aufrufen
fertig funktioniert daten sind in der sql angekommen :-)

Code: Alles auswählen

import urllib
'(024.7 25.23 00.00 00.00 00.00 0000 +030 25.16 -030 0000 00000000\xfd\x14\r'
result = ser.read(68)
url="192.168.178.2/input.php?wert1="
url+=result[2:6]
url+="&wert2="
url+=result[8:12]
//usw...
content = urllib.urlopen(url).read()
das war es schon so gehts :D
Zuletzt geändert von Anonymous am Donnerstag 17. August 2017, 22:41, insgesamt 1-mal geändert.
Grund: Quelltext in Python-Codebox-Tags gesetzt.
BlackJack

@SolarGuido: Das wird nicht ”vanilla” CRC-CCITT sein, wegen dem nachträglichen Anpassen, um die ”besonderen” Zeichen zu vermeiden.

Natürlich kann man mit Python auch Daten in eine SQL-Datenbank oder in eine Datei schreiben.

Du operierst für meinen Geschmack zu viel mit ”magischen” Zahlen. Zum Beispiel die Anzahl der zu lesenden Bytes oder auch die Slices. Lesen kann man einfach Zeilen und statt einzelne Teile per Slice-Syntax aus der Zeichenkette zu holen, böte sich das Aufteilen an Leerzeichen an. Und die Prüfsumme würde ich auch testen, dafür sind die ja da.

Zeichenkette mit ``+=`` zu erstellen ist etwas ineffizient und auch nicht wirklich gut lesbar im Vergleich zur `format()`-Methode.

Aus Deinen Beirägen wird nicht so ganz klar welche Python-Version Du verwendest. Bei Python 2 wären (ohne entsprechenden `__future__`-Import) die Klammern bei ``print`` falsch, aber bei Python 3 müsste es Probleme geben Zeichenketten per `Serial` zu schreiben‽ Also tippe ich auf Python 2. Da ist `urllib.urlopen()` durch `urllib2.urlopen()` ersetzt. Viele schlagen sich aber auch gar nicht erst mit den Modulen aus der Standardbibliothek herum und verwenden das `requests`-Package für solche Sachen. Da braucht man dann auch nicht die Parameter selbst in die URL rein basteln, sondern kann sie einfach als Wörterbuch übergeben.

Wobei diese Anfrage keine GET-Anfrage sein sollte, sondern eine POST-Anfrage, denn GET-Anfragen sind normalerweise keine Anfragen bei denen auf dem Server Daten verändert werden. Sowohl Webbrowser als auch Webserver können Antworten beispielsweise cachen. Beim POST könnte man die Daten dann auch als JSON senden. Ist ja gerade ”in”. :-)
SolarGuido
User
Beiträge: 21
Registriert: Donnerstag 17. August 2017, 07:10

hmm

1. habe ich schon geschrieben das ich pyhton2 nutze gucke nochmal meinen Post durch :D
2. es läuft seit mehr als 24h ohne Störung, also so gaz falsch kann ich doch dann nicht liegen :-)
Ach Ja das was ich poste ist Json das ist die API definition von emoncms.org die ich da nachbilde , nur hier symbolisch dargestellt habe ...

hier das Ergebnis:
https://emoncms.org/dashboard/view?id=43195

Danke nochmal für die Unterstützung ich bin so zufrieden wie es jetzt läuft :) das einzige was noch schön wäre wenn USB dann auch gehen würde, leider bekomme ich dann nur diesen Fehler wenn ich versuche USB zu öffnen.

Ich finde dafür das ich vor etwas mehr als 24h noch nie Python gesehen habe , ging es besser als ich dachte 8)

Code: Alles auswählen

>>> ser = serial.Serial(port='/dev/ttyUSB0',baudrate=2400)

Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    ser = serial.Serial(port='/dev/ttyUSB0',baudrate=2400)
  File "/usr/lib/python2.7/dist-packages/serial/serialutil.py", line 261, in __init__
    self.open()
  File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 278, in open
    raise SerialException("could not open port %s: %s" % (self._port, msg))
SerialException: could not open port /dev/ttyUSB0: [Errno 2] No such file or directory: '/dev/ttyUSB0'
>>>
BlackJack

@SolarGuido: Man kann aus einem Hochhaus springen und bei jedem Stockwerk sagen „bis jetzt gings gut“. CRCs werden in Protokolle ja aus einem Grund eingebaut. Wenn da irgendwann einmal Bits kippen merkst Du das gar nicht das eventuell falsche Werte in der Datenbank landen, und wenn gar Bytes verloren gehen, dann verschiebt sich der Datensstrom und Du verarbeitest ab da konsequent die falschen Stellen in den Nachrichten. So ganz richtig liegst Du damit halt auch nicht. ;-)

Wie kommst Du auf ``/dev/ttyUSB0``? Was kommt bei der Ausgabe von ``dmesg`` dazu wenn Du das Gerät per USB einsteckst? Was sagt ``lsusb`` (muss gegebenfalls installiert werden)?
SolarGuido
User
Beiträge: 21
Registriert: Donnerstag 17. August 2017, 07:10

BlackJack hat geschrieben:@SolarGuido: Man kann aus einem Hochhaus springen und bei jedem Stockwerk sagen „bis jetzt gings gut“. CRCs werden in Protokolle ja aus einem Grund eingebaut. Wenn da irgendwann einmal Bits kippen merkst Du das gar nicht das eventuell falsche Werte in der Datenbank landen, und wenn gar Bytes verloren gehen, dann verschiebt sich der Datensstrom und Du verarbeitest ab da konsequent die falschen Stellen in den Nachrichten. So ganz richtig liegst Du damit halt auch nicht. ;-)
Das weiß ich nicht da ich mich damit nicht auskenne. ich kann nur sagen das wenn ich diesen CRC nutze es mit allen Befehlen geht wenn ich den CRC davon mitschicke, nehem ich einen anderen CRC algorithmus geht es nicht da kommt dann not accn. als antwort.
Da der Befehl statisch ist umnd immer 68 Zeichen zurückgibt passt das in meinem Fall auch. Sicher ist das in dynamischen Fällen außerst uncool. Da musste man dann den <cr> suchen damit man mitbekommt wann die Rückgabe zuende ist. Brauch ich in meinem Fall aber nicht tun. Weil IMMER 68 Zeichen kommen wenn kein Wert dann 0. Wie gesagt das läuft super jetzt und da hab ich auch keinen Bedarf an anpassung mehr :D
Dein Hinweis war aber der entscheidende der mich überhaubt in die Lage versetzt hat das hin zu bekommen. 1000 Dank dafür nochmals!
Wie kommst Du auf ``/dev/ttyUSB0``? Was kommt bei der Ausgabe von ``dmesg`` dazu wenn Du das Gerät per USB einsteckst? Was sagt ``lsusb`` (muss gegebenfalls installiert werden)?
ich habe ja noch einen 2. Inverter der eine USB Schnittstelle hat und den ich nun versche ebenfalls auszulesen. Ich habe gelesen das man dann nur AMA0 in USB0 umbenennen muss , jedoch geht das nicht bei mir ...

Wenn ich auf dem PI dmesg ausführe nachdem ich das Gerät eingesteckt habe neu (nach reoot) :

Code: Alles auswählen

 62.251215] uart-pl011 3f201000.serial: no DMA platform data
[   81.879232] usb 1-1.4: new low-speed USB device number 7 using dwc_otg
[   82.058260] usb 1-1.4: New USB device found, idVendor=0665, idProduct=5161
[   82.058277] usb 1-1.4: New USB device strings: Mfr=3, Product=1, SerialNumber=0
[   82.073725] hid-generic 0003:0665:5161.0004: hiddev0,hidraw2: USB HID v1.11 Device [HID 0665:5161] on usb-3f980000.usb-1.4/input0
lusb:

Code: Alles auswählen

Bus 001 Device 007: ID 0665:5161 Cypress Semiconductor USB to Serial
Bus 001 Device 005: ID 413c:2003 Dell Computer Corp. Keyboard
Bus 001 Device 004: ID 17ef:600e Lenovo 
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device 7 ist mein Inverter

Wäre schön wenn du mir sagen könntest wie ich den in Pyhton ansprechen kann?

derzeit passsiert das:

Code: Alles auswählen

>>> ser = serial.Serial(port='/dev/ttyUSB0',baudrate=2400)

Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    ser = serial.Serial(port='/dev/ttyUSB0',baudrate=2400)
  File "/usr/lib/python2.7/dist-packages/serial/serialutil.py", line 261, in __init__
    self.open()
  File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 278, in open
    raise SerialException("could not open port %s: %s" % (self._port, msg))
SerialException: could not open port /dev/ttyUSB0: [Errno 2] No such file or directory: '/dev/ttyUSB0'
__deets__
User
Beiträge: 14480
Registriert: Mittwoch 14. Oktober 2015, 14:29

Na schau doch mal ob unter /dev/tty noch andere Geräte auftauchen wenn du dein Gerät einsteckst.
SolarGuido
User
Beiträge: 21
Registriert: Donnerstag 17. August 2017, 07:10

__deets__ hat geschrieben:Na schau doch mal ob unter /dev/tty noch andere Geräte auftauchen wenn du dein Gerät einsteckst.
Sorry ich weiß jetzt nicht wie ich das prüfen kann.

Es ist noch unter /dev/tty der serielle Port angeschlossen unter /dev/tty/AMA0 meinst du das?

Ansonsten habe ich nur das im Moment :

Code: Alles auswählen

[{'device': '/dev/bus/usb/001/007', 'tag': 'Cypress Semiconductor USB to Serial', 'id': '0665:5161'}, 
{'device': '/dev/bus/usb/001/005', 'tag': 'Dell Computer Corp. Keyboard', 'id': '413c:2003'}, 
{'device': '/dev/bus/usb/001/004', 'tag': 'Lenovo ', 'id': '17ef:600e'}, 
{'device': '/dev/bus/usb/001/003', 'tag': 'Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter', 'id': '0424:ec00'}, 
{'device': '/dev/bus/usb/001/002', 'tag': 'Standard Microsystems Corp. ', 'id': '0424:9514'}, 
{'device': '/dev/bus/usb/001/001', 'tag': 'Linux Foundation 2.0 root hub', 'id': '1d6b:0002'}]
Unter dem Ordner DEV gibt es nur BUS/USB und USB aber kein TTY

Meinst du das?

Sorry kein Linux Profi reiner Anfänger...
SolarGuido
User
Beiträge: 21
Registriert: Donnerstag 17. August 2017, 07:10

ich hab irgend was gelsen das es eine
HID device
geesen, könnte es sein das dies nicht über serial sondern über eine andere Methode angesprochen werden muss?
There is no HID driver for the inverter, so I just used a generic device file: /dev/hidraw0.
wie macht man so was?
__deets__
User
Beiträge: 14480
Registriert: Mittwoch 14. Oktober 2015, 14:29

Aber da steht doch serial device.

Und /dev/tty ist nur der prefix. Das eingebaute device heißt ja auch /dev/ttyAMA0. Vielleicht taucht dein Ding unter /dev/ttyFOOBARBAZ auf.
SolarGuido
User
Beiträge: 21
Registriert: Donnerstag 17. August 2017, 07:10

__deets__ hat geschrieben:Aber da steht doch serial device.

Und /dev/tty ist nur der prefix. Das eingebaute device heißt ja auch /dev/ttyAMA0. Vielleicht taucht dein Ding unter /dev/ttyFOOBARBAZ auf.
gibt es einen Befehl der auflistet welche tty es gibt?

tty/AMA0 ist über GIPO und einen 3.3V adapter mit dem Laderegler verbunden das geht und der ist eingesteckt und läuft unter ttyAMA0

das USB Gerät ist in unter :
device': '/dev/bus/usb/001/007', 'tag': 'Cypress Semiconductor USB to Serial', 'id': '0665:5161'
zu finden. Ja da steht USB to Serial aber es funktioniert nix außer ttyAMA0

Wenn ich :ttyFOOBARBAZ nutze passiert das selbe.

Code: Alles auswählen

>>> ser = serial.Serial(port='/dev/ttyFOOBARBAZ',baudrate=2400)

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    ser = serial.Serial(port='/dev/ttyFOOBARBAZ',baudrate=2400)
  File "/usr/lib/python2.7/dist-packages/serial/serialutil.py", line 261, in __init__
    self.open()
  File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 278, in open
    raise SerialException("could not open port %s: %s" % (self._port, msg))
SerialException: could not open port /dev/ttyFOOBARBAZ: [Errno 2] No such file or directory: '/dev/ttyFOOBARBAZ'
>>> 
:?: :?: :?: :?: :?:
BlackJack

@SolarGuido: FOOBARBAZ besteht aus den Namen FOO, BAR, und BAZ die häufig für Beispiele verwendet werden. Da hat jetzt niemand wirklich erwartet das es einen solchen Namen gibt, sondern halt *irgendeinen* der mit `/dev/tty` beginnt. Neben `/dev/ttyAMA0`.

Befehl zum Auflisten von Dateinamen ist ``ls`` und man kann auch unter Linux ”Wildcard”-Zeichen verwenden, also ``ls /dev/tty*``:

Code: Alles auswählen

$ ls /dev/tty*
/dev/tty    /dev/tty19  /dev/tty3   /dev/tty40  /dev/tty51  /dev/tty62
/dev/tty0   /dev/tty2   /dev/tty30  /dev/tty41  /dev/tty52  /dev/tty63
/dev/tty1   /dev/tty20  /dev/tty31  /dev/tty42  /dev/tty53  /dev/tty7
/dev/tty10  /dev/tty21  /dev/tty32  /dev/tty43  /dev/tty54  /dev/tty8
/dev/tty11  /dev/tty22  /dev/tty33  /dev/tty44  /dev/tty55  /dev/tty9
/dev/tty12  /dev/tty23  /dev/tty34  /dev/tty45  /dev/tty56  /dev/ttyAMA0
/dev/tty13  /dev/tty24  /dev/tty35  /dev/tty46  /dev/tty57  /dev/ttyprintk
/dev/tty14  /dev/tty25  /dev/tty36  /dev/tty47  /dev/tty58
/dev/tty15  /dev/tty26  /dev/tty37  /dev/tty48  /dev/tty59
/dev/tty16  /dev/tty27  /dev/tty38  /dev/tty49  /dev/tty6
/dev/tty17  /dev/tty28  /dev/tty39  /dev/tty5   /dev/tty60
/dev/tty18  /dev/tty29  /dev/tty4   /dev/tty50  /dev/tty61
Wenn ich bei meinem Raspi ein USB/Serial-Adapter anstecke, bekomme ich bei ``dmesg`` übrigens das hier:

Code: Alles auswählen

[1527951.682448] usb 1-1.2.4: new full-speed USB device number 13 using dwc_otg
[1527951.841145] usb 1-1.2.4: New USB device found, idVendor=0403, idProduct=6015
[1527951.841161] usb 1-1.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1527951.841170] usb 1-1.2.4: Product: FT231X USB UART
[1527951.841179] usb 1-1.2.4: Manufacturer: FTDI
[1527951.841187] usb 1-1.2.4: SerialNumber: DQ00886E
[1527951.981549] usbcore: registered new interface driver usbserial
[1527951.982260] usbcore: registered new interface driver usbserial_generic
[1527951.983772] usbserial: USB Serial support registered for generic
[1527951.995248] usbcore: registered new interface driver ftdi_sio
[1527951.995470] usbserial: USB Serial support registered for FTDI USB Serial Device 
[1527951.995622] ftdi_sio 1-1.2.4:1.0: FTDI USB Serial Device converter detected
[1527951.995861] usb 1-1.2.4: Detected FT-X
[1527951.996786] usb 1-1.2.4: FTDI USB Serial Device converter now attached to ttyUSB0
Und auch einen Eintrag unter `/dev/`:

[codebox=text file=Unbenannt.txt]$ ls /dev/ttyU*
/dev/ttyUSB0[/code]

Eventuell fehlt Dir ein Treiber für Dein Gerät oder man muss den aktivieren oder so‽
__deets__
User
Beiträge: 14480
Registriert: Mittwoch 14. Oktober 2015, 14:29

Man kann sein Produkt uebrigens auch mal googeln, und dann findet man zB

https://community.cypress.com/thread/22164

welches suggeriert das der Treiber (so vorhanden/geladen/einkompiliert, wovon ich aber ausgehen wuerde) eine Datei mit dem Muster dev/ttyACM* anlegt.
Antworten