Ich überlege, ob ich die CAN Kommunikation auf can-utils (das wo auch cansend, candump, ... herkommt) umprogrammieren soll. Mit udsoncan/isopt scheinen wir die Geschichte irgendwie nicht so richtig los zu werden 😕 Aber das ist ein tierischer Aufwand, auch weil die ganze Codec Geschichte im udsoncan steckt. Und es weiss niemand, ob man damit das Problem dann wirklich los ist und ob man sich nicht ein möglicherweise ein anderes einhandelt. Und mit DoIP wär es dann auch vorbei. Hallo Phil, wenn man die CAN-Kommunikation ohne udsoncan abwickeln möchte, muss man ReadByDid und WriteByDid nachbauen. Ersteres habe ich für den ioBroker-Adapter bereits umgesetzt, das sollte sich zügig in Python umsetzen lassen. WriteByDid sollte auch kein großer Aufwand sein. Die Codecs können trotzdem aus udsoncan direkt weiterverwendet werden, da reicht eine Zeile: from udsoncan.common.DidCodec import DidCodec Das verwende ich in E3onCAN. Funktioniert problemlos. Und jetzt kommt das große ABER: Ich habe erhebliche Zweifel, dass wir die Timeout-Thematik dadurch loswerden. Denn die Pseudo-Timeouts kommen aus iso-tp und eben nicht aus udsoncan. Die Timeouts aus udsoncan sind reale Fehler, d.h. die angefragte ECU antwortet nicht, trotz korrekter CAN-Kommunikation. Die iso-tp Timeouts werden durch einen Bug im Linux-Kernel verursacht. Der dürfte weiterhin zuschlagen, wenn wir udsoncan umgehen. Deshalb mein Fazit: Wäre machbar, ist aber nicht sinnvoll.
... Mehr anzeigen
