RS485: Busauslegung und alternativ: CAN-Treiber-Chips?

Begonnen von Beta-User, 22 Februar 2018, 15:14:12

Vorheriges Thema - Nächstes Thema

KarlHeinz2000

Der RX Buffer kommt von Arduino IDE. Da hat man im Sketch keinen Einfluss (mehr).

Beta-User

Hab zu dem Thema noch das hier gefunden:
https://arduino.stackexchange.com/questions/1726/how-does-the-arduino-handle-serial-buffer-overflow
ZitatFor a software serial port in SoftwareSerial.h the receiver buffer size _SS_MAX_RX_BUFF is defined as 64 bytes. In both cases it stops attempting to insert received data into the queue when it is full, so you could get a mix to old and new data depending on how you're retrieving data from the queue. Ideally it would be best to ensure the buffer always gets emptied in a prompt manner to avoid the buffer filling. Maybe take a look at timers and implementing a simple state machine if your problem is related to other code blocking the main loop.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rob

Die Änderungen sind soweit drin. Hat ein wenig gedauert, weil ich den LM2576HV noch nachmalen musste. Rest siehe Edit. :)

Viele Grüße
rob


Beta-User

@rob:
Auch das sieht wieder gut aus, und funktiional scheint das auch soweit zu passen (war kurz unsicher wg. Verbindung RX-CRX und TX-CTX, aber zum Glück hatte ich von dem GW ein Bild gemacht und das ins Wiki gepackt...).

Allerdings finde ich die Optik des GW's etwas unglücklich. Konkret sollte m.E. die USB-Buchse in etwa an derselben Stelle sein wie beim Nano. Außerdem finde ich es leichter, wenn die Stomversorgung "verwinkelt" ist, statt die TX/RX-Linien. Falls zu wenig Platz ist, könnte man evtl die MCP-Boards insgesamt etwas weiter nach oben verschieben, aber eigentlich müsste das noch so passen.

Was die Versorgung von Node-n + Last angeht, fällt mir grade auf, das die VCC-Verbindung auf RAW geht. Das mag zwar sicherer sein, aber hinter einem gut eingestellten Step-Down müßte insgesamt eigentlich auch VCC als Eingang ok sein? Alles andere führt nur zu weiteren leichten Verlusten... Oder übersehe ich da was?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Schotty

Vorweg: Ich habe jetzt nicht den kompletten Thread noch einmal gelesen, also falls mein folgendes Geschreibsel schon diskutiert wurde und somit hinfällig ist, seht es mir bitte nach, wenn ich das hier nochmal zur Sprache bringe.. ;)

Mir persönlich 'gefallen' die in der Abbildung beschriebenen errechneten Widerstandswerte nicht so richtig, insbesondere der für R3.
Es ist für einen Anfänger m.E. viel zu verwirrend und erzeugt lediglich Unsicherheiten. Zumal in der Abbildung der Widerstandswert bei R4 dann wiederum 120Ohm beträgt (btw: afaik sollten die Terminierungswiderstände immer gleich groß sein?!) und auf den gängigen Modulen meist sowieso 120Ohm verbaut sind. 
Ich würde daher 'empfehlen', es bei besagten 120Ohm an beiden Seiten zu belassen.

Die standardmäßig angegebenen 120Ohm sind nicht in Stein gemeißelt, sie kommen daher, dass in ISO11898 die Verwendung von Kabeln mit einer Impedanz von 120Ohm 'empfohlen/vorausgesetzt' wird. Aber auch dort wird eine Spanne angegeben (s. bspw. ISO 11898-2, Kap. 7.5), der letztliche Wert ist von mehreren Faktoren abhängig.

Streng genommen müsste bereits bei den gerne genutzten CAT-Kabeln ein anderer Wert gewählt werden, nämlich meist 100Ohm, da dies i.d.R. die Impedanz dieses Kabeltyps ist, zu dem der Wert der Terminierungswiderstände passen sollte. Für uns 'Normalanwender' ist das aber m.A.n. vernachlässigbar.
Wenn man jedoch nun schon eine Berechnung der Abschlusswiderstände einbringt, dann sollte man wohl auch das Thema galvanische Trennung aufgreifen - was aber für den Anfänger mit den gängigen Modulen ebenfalls wieder etwas zu kompliziert und verwirrend sein mag und für den 'normalen' Anwendungsfall u.U. overdosed ist.

Gemäß dem KISS-Prinzip sollte es imho also bei den Standardwerten und dem typischen 'plug&play'-Szenario mit den gängigen Modulen bleiben, alles andere würde an dieser Stelle (= in der Abbildung, ansonsten können solche Themen natürlich gerne irgendwo erwähnt werden!) m.A.n. eher 'stören' bzw. verwirren..

Just my 1/2Euro ;)   
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

Beta-User

Sehr guter Einwurf!

Vielleicht noch eine etwas allgemeinere Anmerkung zum Thema Wiki-Artikel/Starter-Guide:
Ich habe den damals "on the fly" (angelehnt an das EnOcean-Muster) erstellt, nachdem ich die ersten Hürden soweit genommen hatte und dann später nur noch erweitert/ergänzt, wenn halt was neues dazukam. Der ist aber keineswegs "heilig", schon gleich nicht, was diese ganzen Schaltungsthemen angeht. Da bin ich einfach (ziemlicher) noob und habe eher experimentelles "Wissen".

Daher:
- Wer sinnvolle Ergänzungen/Querverweise hat und die notwendigen Rechte, direkt ins Wiki zu schreiben: just do it (v.a. @Ranseyer), ich fühle mich schlicht nicht in der Lage, das "unfallfrei" ins Wiki zu übersetzen, was da zu Bus, Terminierung usw. steht...
- Guideline sollte das sein, was Schotty schreibt: KISS, default-Werte verwenden, die "jeder" in der Grabbelkiste hat bzw. die mit den Modulen automatisch kommen, Optimierungen usw. dann im Text erwähnen;
- Wer keine Wiki-Rechte hat: Bei Interesse einfach an Peter (die Adresse ist über die Wiki-Hauptseite verlinkt) wenden, oder dann einfach Textvorschläge hier oder (wenn keine teechnischen Fragen zu klären sind besser!) im Wiki-Bereich einstellen; gerne mit Formatierung, notfalls aber einfach als simplen Text.

Es macht m.E. mehr Sinn, wenn die Leute das v.a. bzgl. RS485 zusammentragen, die sich aktuell damit befassen, wie wenn ich jetzt auch noch dazu wieder meine Kiste aus dem Keller hole; wollte eigentlich ein paar andere Instruktionen irgendwann mal weiter schreiben ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rob

Optische Dinge sind kein Thema und flink gemacht. Der gedrehte Micro ist dem Steckboard geschuldet und es wurde bereits festgestellt, dass Steckboards nicht gut sind. Ich wollte eh noch optisch angleichen, vom Steckboard weg und die Buck-Converter ersetzen.

Das größere Problem scheint jedoch inhaltlicher Natur (Optik alleine bringt keine Punkte). Dort steckt wohl der Teufel im Detail. Ich meinte ganz gut durchgestiegen zu sein, aber jetzt stehe ich aufm Schlauch.  :o

Die 130Ohm stammen ja aus dem Calculator (R1 u. R2 auch; http://www.alciro.org/tools/RS-485/RS485-resistor-termination-calculator.jsp). Eingegeben 12V und 120Ohm, Rest belassen (siehe unten im Bild). Weil das Ergebnis nicht passt, heißt es m.E. alles zurück auf Anfang:
Im ersten Bild mit Max485 bleiben am GW-Transceiver u. Last Node also doch wieder die Standard-Widerstände. Den Extra-Krams mit 12V, externen Widerständen usw. braucht es dann nicht mehr. Im Prinzip brauchen es das Bild nicht, weil im Original vom Wiki bereits alles drin ist und das neue Bildchen nichts Nennenswertes hinzuträgt.

Schwieriger wird es bei den CAN-Dingern. Die haben ja keinen PullUp/PullDown on Board. Die vom Calculator passen nicht. Was male ich dann da hin? Auch die Busabschlüsse sollen eh ganz anders gemacht werden.
Wahrscheinlich macht es gar keinen Sinn irgendwas bildhaft festzuhalten (zu viele Wege/ Kompromisse). War ja auch auf meinem Mist gewachsen und jetzt kostet es Euch unnötig Zeit u. Diskussion. Das war nicht meine Absicht. Meine Absicht war es Klarheit zu schaffen, was so nicht erreichbar scheint.

MySensors@RS485 ist schwieriger als ich dachte. Kabelgebunden gehts auch mit dem Ethernet-GW, ohne Widerstands- und Transceiver-Fragen. Oder halt 1-Wire. Mist, jetzt hab ich die CAN-Module umsonst geordert.  :'(

Die zwei Bilder würde ich vorerst rausnehmen, um nicht falsche Infos unnötig weiter zu verbreiten. @Beta_User: ich kann es auch ausm Wiki nehmen, dann brauchst Dich darum nicht kümmern.

Vielen Dank für Eure Rückmeldungen und beste Grüße
rob

Schotty

Hi rob,
oh man, jetzt habe ich ein schlechtes Gewissen, ich wollte dich nicht demotivieren!!

Bzgl Widerstandswerte: Mein Geschreibsel bezog sich erstmal auf CAN, weil ich die Bemerkung heute Morgen in deiner schönen(!) Grafik hier https://forum.fhem.de/index.php/topic,84814.msg1054219.html#msg1054219 gesehen hatte. Bzgl RS485 hatte ich gar nicht geguckt, sorry..
Afaik ist das mit den gleich-großen Widerständen eigtl auch bei RS485 der Fall, aber (auch) da kann ich mich irren! Ist alles nur angelesen, ich bin diesbzgl kein Experte!

Bild bzgl RS485: Deine MAX485-Module sind deutlich schicker als meine und eine Breadboard-Darstellung mag ein anderer User vielleicht/bestimmt lieber, insofern finde ich es überhaupt nicht überflüssig! Kann/sollte m.A.n. also ruhig drinbleiben. Aber auch da (jetzt gerade nachgesehen ;) ) würde ich vorschlagen, die Bemerkung hinsichtlich der abweichenden Widerstandswerte rauszunehmen.
Aus dem ganz einfachen Grund, dass a) die fertigen MAX485-Module i.d.R. bereits mit 120Ohm-SMDs bestückt sind und es b) wie bei CAN erwähnt m.A.n. eher verwirrend ist, wenn da abweichende Werte aufgeführt werden. (Jetzt mal unabhängig davon, dass ich bei meiner Grafik auch die Standard-R7 mit 120Ohm 'drin' habe.)

Ich hatte mich (weil ich eine regelrechte Odyssee hinter mir habe, was die finale Inbetriebnahme anging - Fehler lag allerdings *ganz* woanders: die Steckdose war mit dem Lichtschalter oben an der Kellertür gekoppelt  ::)  >:(  :-X ) mit dem Kram eine ganze Weile beschäftigt und viel gelesen, anfangs bzgl RS485, später dann aber mehr bzgl CAN, weil Beta-User mir freundlicherweise auch MCP2551er geschickt hatte und ich irgendwann dachte 'hmmm, vielleicht liegt der Fehler ja bei RS485 selbst'.
Ohne jetzt groß ausschweifen zu wollen: Unterm Strich scheint es so zu sein, dass das ganze in unseren Anwendungsfällen eigtl eher 'vernachlässigbar' ist. Je größer (Kabellängen, Anzahl Nodes etc), komplexer (auch hinsichtlich Verkabelung) und schneller (Übertragungsrate) die komplette (Bus-)Installation wird, desto kritischer wird es u.U. auch mit solchen Feinheiten wie den Terminierungswiderständen.
Auch bei RS485 wird ja gerne normales CAT-Kabel genutzt (mit 100Ohm Impedanz) und es läuft meist trotzdem mit den 120er Widerständen. Es gibt auch genügend User, die keinerlei Schirmung benutzen, GND nicht verbinden etc und bei denen es auch ohne Probleme läuft. Bei anderen wiederum macht dann aber durchaus auch mal ein gewisser Potentialunterschied oder die mangelnde EMV-gerechte Auslegung Probleme.   
Wer wirklich tiefer in die Materie einsteigt und eben nicht die 'normalen' Module einsetzen, sondern alles selbst zusammenbauen will, der wird/sollte sich dann sowieso mit den weiteren Feinheiten auseinandersetzen. Dazu gehören m.E. dann eben auch die unterschiedlichen Widerstandsgrößen, eine EMV-gerechte Installation, galvanische Trennung etc.pp.
Das ist aber für den Einsteiger (und darum geht es hier doch erstmal prinzipiell) alles viel zu viel.

MySensors@RS485 ist nicht schwieriger als du dachtest, lass dich bitte von meinem Beitrag open nicht abschrecken oder verunsichern! Nachdem ich dann nach einigen Wochen (naja, streng genommen Monaten  >:( ) und unendlich vielen Varianten und Fehlersuchen dann mal auf das eigentliche Problem mit dem erwähnten Lichtschalter gekommen bin, habe ich kurzerhand meine Nanos und RS485-Module wieder aus der Kiste geholt, das (mittlerweile gelegte) LAN-Kabel als Busleitung mißbraucht und voilà, innerhalb kurzer Zeit lief alles problemlos. Sollte die Installation wachsen, werde ich sicherlich auch auf CAN umsteigen, aber bisher ist bei meiner Mini-Installation mit 3 RS485-Modulen (1GW, 2Nodes), AltSoftSerial@Nano und 9600kbps alles problemlos. Stromversorgung der einzelnen Nanos via jeweiliger USB-Buchse, lediglich A+B und GND habe ich verbunden. Und so dürfte der 'normale' Einsteigerbeginn eben aussehen: Günstige Nanos und RS485-Module bestellen, Strippe ziehen, verkabeln und flashen und dann 'erst mal gucken'. Wenn dann Probleme auftauchen, fragt man entweder hier oder im MySensors nach (jaaa, schon klar - natürlich erst, wenn man nach eigener Recherche nicht weiter kommt..   ;) ).

Bzgl PullUp/Down & Busabschlüsse @CAN: Sooo viel schwieriger im Sinne von 'anders' ist es da eigtl auch nicht (jedenfalls für uns Normalos), die Systeme sind sich recht ähnlich (was die physische Seite angeht).
Auch da gilt m.A.n. aber erstmal: KISS. Der 'normale' Einsteiger wird sich erstmal ein paar fertige Module kaufen (btw: Welche hast du dir bestellt?), anschließen und fertig. Ob und welche Widerstände da drauf sind und wie die Terminierung dort realisiert ist, ist dabei erstmal zweitrangig. Wichtig ist der Hinweis, dass nur am jeweils ersten und letzten Modul die Abschlusswiderstände drauf sind. Das reicht für den Einstieg.

Als 'richtiger' Bus ist eigtl auch eine Verkabelung vorgesehen, bei denen die Teilnehmer wirklich 'hintereinander' angeschlossen sind, stubs/Stichleitungen sollten möglichst vermieden werden. Aber auch das ist relativ, es sind je nach Installation auch durchaus stubs problemlos verwendbar. Es ist eben nur wichtig zu wissen, wie es prinzipiell eigtl aussehen sollte, damit man es hinterher bei der Fehlersuche etwas leichter hat. Aber das wird man bei der dann meist eh notwendigen Recherche früher oder später auch herausfinden. Für den Einsteiger reicht m.A.n. der Hinweis "alle Nodes sind in Reihe am Bus anzuschließen, Stichleitungen sollten möglichst vermieden werden" oder sowas in der Art. Aber das wird im Wiki von Beta-User ja vermutlich schon drin stehen (hab's jetzt aktuell nicht nochmal komplett gelesen ;) ).

Wer wirklich eigene Schaltungen aufbauen und eben keine fertigen Module verwenden will, der wird früher oder später bspw. auch darauf stoßen, dass die MCP2551er eigtl nicht mehr verwendet werden sollten, sondern die Nachfolger MCP2561 und MCP2562 eingesetzt werden sollten. Unterschiede sind in den application notes und Datenblättern zu finden, kann ich aber bei Gelegenheit sonst hier auch gerne irgendwann nochmal kurz aufführen, wenn das von Interesse ist. Aber da auf den gängigen Modulen (TJA lasse ich jetzt mal außen vor) sowieso noch die alten MCP2551er verbaut sind, ist auch das für den 'Normalo' uninteressant/irrelevant.

Ganz kurz bzgl der Widerstände @CAN:
- PullUp/Down:
Bei den fertigen Modulen sind (zumindest bei einigen Modellen) teils durchaus PullUps/Downs vorzufinden (ich meine jetzt extern verbaute, nicht welche innerhalb der Transceiver selbst). Auch im KFZ-Bereich werden die von einigen Autobauern (den Namen 'VW' hatte ich diesbzgl mal irgendwo gelesen) wohl durchaus verwendet. Sinn von den Teilen ist (Achtung: rein aus dem Gedächtnis, kann also durchaus fehlerbehaftet sein! ;) ) wohl, den Störabstand zu vergrößern, weil so eine Art 'definierter' Zustand in Ruhe erzielt werden kann. Auch können so Kurzschlüsse auf dem Bus (bessser?) erkannt werden. So habe ich es mir zumindest stark vereinfacht gemerkt - bitte nicht schlagen, wenn es nicht den Kern der Sache trifft.. ;)

- Abschlusswiderstand/Terminierung an den jeweiligen Busenden: Prinzipiell auch wie bei RS485, ein (erstmal) 120Ohm-Widerstand hängt zwischen CAN-H & CAN-L. Es gibt aber (auch hier) noch die 'fancy' Varianten, bei denen (einfach ausgedrückt) anstelle eines 120ers bspw je ein 60Ohm-Widerstand pro Leitung verwendet wird (also insg. 2 Widerstände). Nennt sich 'biased split termination' (und ist iirc teilweise auch bei gängigen Modulen vorzufinden). Zusätzlich kann man da dann auch noch nen Kondensator und was-weiß-ich-nicht-noch-alles verbauen, aber auch das führt erstmal zu weit.

Ich hoffe, ich habe dich jetzt etwas 'beruhigen' und ein wenig für Klarheit sorgen können. Falls ich die Sache nur verschlimmert habe: duck-und-wech..  ;D   

Gruß
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

rob

Zitat von: Schotty am 16 Mai 2020, 20:12:47
...jetzt habe ich ein schlechtes Gewissen, ich wollte dich nicht demotivieren!!
Falls ich die Sache nur verschlimmert habe...
Hallo Schotty.

Brauchst Du ehrlich nicht zu haben. Ich bin auch nicht demotiviert. Nix verschlimmert, im Gegenteil: super klar gestellt. Alles gut  ;D
Ich denke, ich weiß jetzt wie ich weiter machen kann. Ich möchte diesen Fred jedoch weniger okkupieren, damit es mehr um Technik gehen kann. Der Grafikkrams ist ja nur ein Randthema.

Viele Grüße
rob

PS: Meine Bilderchen müsst Ihr nicht jedes Mal loben, um mich zu motivieren. Ich machs gerne und wenns gefällt freu ich mich natürlich, aber ich muss damit nicht im Mittelpunkt stehen :D

Schotty

..nur noch eine ganz kurze anmerkung bzgl des von dir verlinkten widerstandsrechners für rs485: 100m ist ja schon echt ne hausnummer. wenn ich da mal 20m eingebe, kommen ca 122ohm raus, bei 50m ca 125ohm. den unterschied bzgl 130 vs 120 finde ich jetzt auch nicht sooooo groß (bin aber auch kein elektroniker ;) ),als dass man da nun zwingend drauf hinweisen und die leute zum smd-braten animieren müsste. bei anderem awg-wert des kabels sieht das ganze dann auch schon wieder aus. cat5 wird sicherlich auch eher 'mal eben' verwendet werden, als cat7, also müsste man das dann streng genommen auch wieder berücksichtigen, etc.pp.
ich hatte jetzt bei mir auch ganz einfaches cat5 genommen,einfach weil ich das noch in entspr länge liegen hatte und erstmal testen wollte (am anfang in der ersten euphorie hatte ich auch schon ne 50m bzw 100m-rolle cat7-verlegekabel und zig bauteile für galvanische trennung etc im warenkorb,dann aber zum glück doch nicht gleich bestellt ;) ). wie gesagt, funzt bisher problemlos mit den standard rs485-modulen und 120ohm am anfang und ende..
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

Schotty

Gute arbeit muss und sollte doch auch gerne mal gelobt und anerkannt werden, das kommt heutzutage doch eh schon viel zu kurz  :D

Ich bin zwar nicht der TE,aber von okkupieren kann m.A.n. nicht die Rede sein. Es geht doch ums Thema, also ist (zumindest für mich ;) ) sowieso alles gut! Und gerade, wenn du da was fürs Wiki erstellst, dann sollten etwaige Unklarheiten doch eh besprochen und idealerweise beseitigt werden! Also halte uns gerne auf dem Laufenden - meine Meinung..

Welche CAN-Module hattest du dir denn jetzt eigtl bestellt?
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

rob

Zitat von: Schotty am 16 Mai 2020, 21:02:29
Welche CAN-Module hattest du dir denn jetzt eigtl bestellt?
die frechen Dinger hier https://www.ebay.de/itm/NEW-MCP2551-High-Speed-CAN-Communicate-Protocol-Controller-Bus-Interface-Module/401132415647 Ich meine, solche hatte Beta-User auch einmal verlinkt gehabt.

Ja, ich halte Euch gerne auf dem Laufenden.

Viele Grüße
rob

Beta-User

Yep, jedenfalls auf den ersten Blick sehen die aus wie die, die ich jetzt hier rumliegen habe. (Die meisten meiner Nodes sind aber mehrfach umgelötet und "beherbergen" MCP2551-Chips auf umgelöteten TJA1050-Platinen, die adaptiert sind auf die typischen RS485-Module...). Nur die, die ich neu aufgebaut habe, haben die "lila" Module - was bis dato immer stressfrei ging.

Kurz zusammengefaßt daher zu dem Bus-Thema meine These: Was für RS485-Module paßt, stört auch die CAN-Transceiver nicht ;) .

Und es ist auch ok, wenn hier teils Wiki-Themen usw. auftauchen. Der TE bin ich (und könnte eigentlich ein "gelöst" davor machen? Wir tappen da nämlich m.E. deutlich nicht mehr im Dunkeln bzw. mein setup funktioniert trotz meiner Mehrfachadaptionen...!)

Was die "verwende den Nachfolger"-Frage angeht: Es ist ok, wenn der Hersteller sagt, er hätte was neues (stromsparenderes, btw), und dessen Verwendung empfiehlt, aber das heißt doch noch lange nicht, dass die alten Murks waren, oder? Wie dem auch sei, ich habe jetzt auch mal ein paar "nackige" MCP2562 bestellt, damit ich ggf. mitreden kann... War eben noch finanziell verkraftbar (unter 50ct/St., mal sehen, wann ich ggf nach Eintreffen mal Muße zum Löten habe. Aber fertige Module gibt es damit eben leider (noch) nicht, und zu den Baudraten findet sich jedenfalls im Datenblatt nur eine Obergrenze, oder übersehe ich mal wieder was?).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Für die Selberlöter@CAN anbei noch ein Bild von einem umgelöteten TJA-Modul und einem "nativen" MCP2551-Modul.

Bei dem TJA-Modul war afaik mal ein 120-Ohm-R drauf gewesen (R3), jedenfalls gehen die beiden Verbindungen zu CANH/CANL. Auf dem "nativen" sind die (per default unbestückten) Lötpunkte für R2 und C2 zu erkennen, beide verbinden CANH und CANL. Der Rest ist RX/TX-LED und ein Spannungsstabilisation, also keine großen Geheimnisse und bei Bedarf mit einem "nackigen" IC mMn. recht stressfrei nachzubauen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Schotty

Zitat von: Beta-User am 17 Mai 2020, 07:39:13
Was die "verwende den Nachfolger"-Frage angeht: Es ist ok, wenn der Hersteller sagt, er hätte was neues (stromsparenderes, btw), und dessen Verwendung empfiehlt, aber das heißt doch noch lange nicht, dass die alten Murks waren, oder?
Nein, habe ich aber doch so auch nie behauptet/gesagt?!

Zitat
Wie dem auch sei, ich habe jetzt auch mal ein paar "nackige" MCP2562 bestellt, damit ich ggf. mitreden kann...
Naja, wirklich viel 'mitzureden' gibt's da wohl nicht, denn von den Unterschieden wirst du/wir im normalen Anwendungsszenario vermutlich nicht viel merken..
Zitat aus dem Migration-Sheet: "Although major improvements have been made, resulting in increased EMC performance and much lower current consumption, the differences in using the MCP2561 versus the MCP2551 are minor."
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/