Ich versuche bisher vergeblich HM-MOD-RPI-PCB auf einem BananaPi zu verwenden.
Ich habe zwei HM-MOD-RPI-PCB Module, bei beiden das selbe Verhalten.
Sie lassen sich ohne Probleme mittels flash-hmmoduart flashen, daher gehe ich davon aus, das sie prinzipiell funktionsfähig und korrekt angeschlossen sind.
Der BPi hat auch mehrere serielle Schnittstellen, ich habe die Module an zweien (ttyS1 normale RPi kompatible Pfostenleiste, ttyS2 8-polige Postenleiste mittels Adapter) probiert, geht an beiden nicht:
Internals:
CFGFN
CNT 0
DEF /dev/ttyS1
DevState 0
DevType UART
DeviceName /dev/ttyS1@115200
FD 45
LastOpen 1503336298.14268
NAME RM_HmUART_ttyS1
NR 454
PARTIAL
STATE opened
TYPE HMUARTLGW
XmitOpen 0
model HM-MOD-UART
Helper:
Log:
Resolve 1
IDs:
READINGS:
2017-08-21 19:12:02 D-type HM-MOD-UART
2017-08-21 19:12:02 cond disconnected
2017-08-21 19:12:02 loadLvl suspended
2017-08-21 19:24:58 state opened
Attributes:
hmId F11034
verbose 5
Nach einem set reopen steht im log nur:
2017.08.21 19:24:58 4: HMUARTLGW RM_HmUART_ttyS1 Reopen
2017.08.21 19:24:58 3: RM_HmUART_ttyS1 device closed
2017.08.21 19:24:58 3: Setting RM_HmUART_ttyS1 serial parameters to 115200,8,N,1
2017.08.21 19:24:58 1: /dev/ttyS1 reappeared (RM_HmUART_ttyS1)
Berechtigungen für /dev/ttyS1 sind ok.
Auf einem RPi3 funktionieren die selben Module:
Internals:
AssignedPeerCnt 0
CNT 19
DEF /dev/ttyAMA0
DEVCNT 2
DevState 99
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 11
LastOpen 1503246901.78844
NAME RM_HmUART_RPI3
NR 20
PARTIAL
RAWMSG 0500003940A6104A11BAF1103406035E00
RSSI -57
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model HM-MOD-UART
msgLoadCurrent 0
msgLoadHistory 0/0/0/0/-/-/-/-/-/-/-/-
msgLoadHistoryAbs 0/0/0/0/0/-/-/-/-/-/-/-/-
owner F11034
Helper:
CreditTimer 5
FW 66561
Initialized 1
AckPending:
LastSendLen:
3
3
Log:
IDs:
RoundTrip:
Delay 0.00266504287719727
loadLvl:
lastHistory 1503248104.26845
Peers:
READINGS:
2017-08-20 18:35:04 D-HMIdAssigned F11034
2017-08-20 18:35:04 D-HMIdOriginal 584110
2017-08-20 18:35:04 D-firmware 1.4.1
2017-08-20 18:35:04 D-serialNr OEQ0307171
2017-08-20 18:35:01 D-type HM-MOD-UART
2017-08-20 18:35:04 cond ok
2017-08-20 18:35:04 load 0
2017-08-20 18:35:04 loadLvl low
2017-08-20 18:35:01 state opened
Attributes:
HMUARTLGW.pm ist aktuell.
Irgendeine Idee woran das liegen kann oder was ich noch untersuchen kann?
Gibt es eine Möglichkeit direkt (ohne fhem) das Modul anzusprechen, z. B. per Terminalprogramm?
Ergänzung:
Es wird immer merkwürdiger. Ich habe das Modul jetzt per usb2serial Adapter angeschlossen. An meinem Laptop funktioniert es.
Am BPi selbst dann nicht, wenn es ich es über einen powered USB-Hub anschließe, also kann ein Problem mit der Stromversorgung wohl auch ausgeschlossen werden.
Mglw. ein Linux/Kernel Problem, es ist
Linux bananapi 4.11.6-sunxi #6 SMP Fri Jun 23 19:56:18 CEST 2017 armv7l GNU/Linux
installiert.
Die Seriellen-Schnittstellen funktionieren aber bei 115200 Baud, das habe ich mit einem Terminalprogramm getestet.
Hi,
an serial-getty Dienst deaktivieren hast Du gedacht?
Gruß Otto
Ja, an ttyS1 lief vorher ein RPi add-on Board mit culfw ohne Probleme. Und auf ttyUSB0 läuft ja eh kein Getty.
Nach dem list vom device, hat das Modul nicht ein byte mit dem HM-MOD-RPI-PCB ausgetauscht. Ich würde ja behaupten es steckt nicht dran.
Aber ich habe keine Ahnung vom BananaPi - sorry ich bin Dir keine große Hilfe.
Gruß Otto
Danke trotzdem, ich muss mal sehen, ob ich irgendwie einen Trace von der Kommunikation erstellen kann.
Danach das Modul mal auf direkter Ebene (Terminalprogramm oder so) anzusprechen habe ich auch schon mal ohne Erfolg gefahndet.
Zwei neue Erkenntnisse: Die Kommunikation lässt sich mit ser2net als Proxy belauschen.
Auf dem BPi gibt es keine Kommunikation, das Modul stellt sich tot.
Das Problem auf dem BPi liegt mglw. an der Beschaltung des Reset-Pins des Moduls.
Auf dem RPi ist der Pegel des Pins IO-1 low.
Auf dem BPi per default high.
Nun kann ich aus der Anleitung des HM-MOD-RPI-PCB nicht zweifelsfrei entnehmen, ob der Reset Pin active low oder active high ist.
Weiß das jemand?
Hi,
man kann das Pin offen lassen, habe ich bei meinem ESP so. Ohne drüber nach zu denken.
Ich bin relativ sicher es muss Hi sein, ich habe mal das auf geschrieben:
ZitatNotizen
Eventuell braucht man mit der original Firmware (1.2.1) noch das:
echo 18 >/sys/class/gpio/export
echo out >/sys/class/gpio/gpio18/direction
echo 1 >/sys/class/gpio/gpio18/value
Damit wird das Reset Pin am Modul definiert gesetzt
Gruß Otto
Ich habe das Problem behoben, aber die Lösung ist gelinge gesagt merkwürdig.
Es liegt an einem (nicht angeschlossenen) BMP085 Sensor bzw. dem I2C_BMP180 Modul.
Auf den GPIOs steckte bisher ein Board mit u.a. einem BMP085.
Dieses Board habe ich durch ein HM-MOD-RPI-PCB ersetzt, die Definition des BMP085 Devices aber belassen.
Solange dieses Device vorhanden ist, funktioniert kein HM-MOD-RPI-PCB, sei es direkt oder per USB angeschlossen.
Ich verstehe den Zusammenhang noch nicht wirklich.
Im Log steht dazu:
2017.08.23 19:44:52 3: i2c: HWaccess blockweise von 0x77 lesen, Reg: 0xaa -> syswrite failure: No such device or address
2017.08.23 19:44:52 1: PERL WARNING: Exiting subroutine via last at ./FHEM/00_RPII2C.pm line 514.
Es liegt nicht am I2C Zugriff an sich, die Definition eines anderen per I2C angeschlossener Sensors (TSL2561) verursacht das Problem nicht.