Ich würde gerne einen eigenen proprietären Bus mit RS485 Spezifikation mit PIC Microcontrollern und CCS C++ Compiler aufbauen. Ich kenne RS485 von DMX her eingentlich soweit. Mir ist auch die Topologie bekannt. Ich weiss nur nicht wie dies Programmtechnisch realisierbar ist, dass mehrere Nodes am Bus schreiben können. Also Multi-Master Betrieb! Soweit ich weiss müssen da immer alle nodes warten bis der Bus frei ist, und anschließend senden. Oder gibt es da andere Regeln die man beachten muss? Sollte so aussehen: ---------- ---------- ---------- | Node 1 | | Node 2 | | Node 3 | ---------- ---------- ---------- | | | | | | -----+----------------+----------------+---------- | | | RS485 --------+----------------+----------------+------- Ich hab jetzt auf jedem RS485-Transciever (zum Beispiel: http://focus.ti.com/lit/ds/symlink/sn65hvd485e.pdf). Dieser Transciever hat einen Pin für Schreiben, Schreiben-Enable und für Lesen, Lesen-Enable. Somit müsste ich ja immer im Lesen-Betrieb sein, damit bekomme ich am Lesen Pin die kompletten Daten. Sobald der Bus frei ist, kann Schreiben aktiviert werden um die Daten aus einem buffer auf den Bus zu schreiben. Ich weiss die PIC - Microcontroller haben einen Hardware UART Stack eingebaut, welcher das Senden und Lesen von Seriellen Daten ermöglicht. Wie kann ich diesem UART Modul jetzt sagen, dass es bevor Daten geschrieben werden den Enable-Pin setzt, bzw. wenn nix geschrieben wird für Lesen den Lesen-Enable-Pin setzt? Ich weiss, es gibt hier die ewige Diskussion ob RS485 oder CAN, ich hab mich für RS485 aus Einfachheit entschieden. Koalissionen möchte ich über Software ausschließen. Der Node soll ggf. solange warten bis der Bus frei ist, auch wenns ewig dauert ;-) Das ganze soll für eine Hausautomation sein, ich möchte meine Gas-Therme über einen PIC mit meiner selbstprogrammierten Stellmotorregelung und in weiterer Folge mit der Fussbodenheizung kombinieren. Da laufen also nicht viel Daten über den Bus, eine Baud-Rate von 4800 Baud sollte hier glaub ich auch aussreichend sein, Verkabelung ist verdrilltes Telefonkabel (4 adrig, (2xBus,+15V,GND). danke im Vorraus für eure Hilfe! michael
Michael Wulz wrote: > Der Node soll ggf. solange warten bis der Bus > frei ist, auch wenns ewig dauert ;-) Und wenn 2 Nodes auf die gleiche Idee kommen, was passiert dann?
mhm......gute Frage. Klar wenn ein Node Sendet, warten alle zugleich auf freigabe. Ich würde vorschlagen eine Random-Wartezeit einbauen. Sodass wenn zwei Busnoten warten würden, diese nie zugleich dann senden. Einer ist dann immer der Kürzere. @A. K. (prx): Was haltest du von der Idee??
@ Michael Wulz (mwulz) >mehrere Nodes am Bus schreiben können. Also Multi-Master Betrieb! Braucht du das WIRKLICH? Nicht mal USB hat das. >Soweit ich weiss müssen da immer alle nodes warten bis der Bus frei ist, >und anschließend senden. Oder gibt es da andere Regeln die man beachten >muss? Im Falle einer Datenkollision muss eine variable Zeit gewartet werden, bis wieder gesendet wird. So macht es Ethernet. >Ich weiss die PIC - Microcontroller haben einen Hardware UART Stack >eingebaut, UART ja, Stack nein. >Wie kann ich diesem UART Modul jetzt sagen, dass es bevor Daten >geschrieben werden den Enable-Pin setzt, bzw. wenn nix geschrieben wird >für Lesen den Lesen-Enable-Pin setzt? Das muss die CPU allein tun. Ist ja nicht das Problem. >Ich weiss, es gibt hier die ewige Diskussion ob RS485 oder CAN, ich hab >mich für RS485 aus Einfachheit entschieden. Und erfindest damit das Rad neu ;-) >Das ganze soll für eine Hausautomation sein, ich möchte meine Gas-Therme >über einen PIC mit meiner selbstprogrammierten Stellmotorregelung und in >weiterer Folge mit der Fussbodenheizung kombinieren. Da laufen also >nicht viel Daten über den Bus, eine Baud-Rate von 4800 Baud sollte hier >glaub ich auch aussreichend sein, Verkabelung ist verdrilltes >Telefonkabel (4 adrig, (2xBus,+15V,GND). Tu dir selber einen Gefallen. Vergiss Multimaster. Single Master ist um WELTEN einfacher und ist determinisitsch. Für deinen Krümelkram dreimal ausreichend. Wenn dann mal stabil läuft und alles spielt kannst du über (Un)sinn von Multimaster nachdenken. MFG Falk
Michael Wulz wrote: > mhm......gute Frage. > Klar wenn ein Node Sendet, warten alle zugleich auf freigabe. > Ich würde vorschlagen eine Random-Wartezeit einbauen. > > Sodass wenn zwei Busnoten warten würden, diese nie zugleich dann senden. > Einer ist dann immer der Kürzere. > > @A. K. (prx): Was haltest du von der Idee?? Nichts. Nimm an der Bus wird grad frei, und 2 Nodes warten sehnsüchig drauf, selber mal zu Wort zu kommen. Geht ohne Kollision nur mit deterministischer Wartezeit, für jede Node eine andere. Nimm an der Bus ist schon ein Weilchen frei, und 2 Nodes kommen gleichzeitig auf die gleiche Idee. Da gibt's nun garkeine Vermeidungsstrategie mehr. So wird das nix. Entweder Koordination (z.B. token passing) oder mit Kollisionen leben. Für Letzteres sind RS485-Transceiver eher wenig geeignet. Nur: RS485 Multimaster ist seit Verfügbarkeit billiger CAN Controller wie dem MCP2515 wenig sinnvoll geworden. Seither gilt als Daumenregel: CAN für Multimaster, RS485 für Single.
Falk Brunner wrote: > >>mehrere Nodes am Bus schreiben können. Also Multi-Master Betrieb! > > Braucht du das WIRKLICH? Nicht mal USB hat das. Okay, ich hab anscheinend was falsch verstanden. Mulstimaster ist wenn Mehrere Nodes gleichzeitig schreiben können oder? Ist klar bei mir muss immer nur ein Node senden und nie 2 gleichzeitig. Somit ist das Single-Master Betrieb, nur das der Master jeder Node sein kann. >>Soweit ich weiss müssen da immer alle nodes warten bis der Bus frei ist, >>und anschließend senden. Oder gibt es da andere Regeln die man beachten >>muss? > > Im Falle einer Datenkollision muss eine variable Zeit gewartet werden, > bis wieder gesendet wird. So macht es Ethernet. Jop, dass hab ich auch oben geschrieben, eine Zufallszeit die gewartet wird. >>Ich weiss die PIC - Microcontroller haben einen Hardware UART Stack >>eingebaut, > > UART ja, Stack nein. Sorry, meinte das richtige, schrieb aber Stack ;-) >>Wie kann ich diesem UART Modul jetzt sagen, dass es bevor Daten >>geschrieben werden den Enable-Pin setzt, bzw. wenn nix geschrieben wird >>für Lesen den Lesen-Enable-Pin setzt? > > Das muss die CPU allein tun. Ist ja nicht das Problem. Aber eine Auslagerung dieses in eine ext. Hardware ist wieder aufwendig und kompliziert. >>Ich weiss, es gibt hier die ewige Diskussion ob RS485 oder CAN, ich hab >>mich für RS485 aus Einfachheit entschieden. > > Und erfindest damit das Rad neu ;-) Machen, dies nicht viele ;-)! >>Das ganze soll für eine Hausautomation sein, ich möchte meine Gas-Therme >>über einen PIC mit meiner selbstprogrammierten Stellmotorregelung und in >>weiterer Folge mit der Fussbodenheizung kombinieren. Da laufen also >>nicht viel Daten über den Bus, eine Baud-Rate von 4800 Baud sollte hier >>glaub ich auch aussreichend sein, Verkabelung ist verdrilltes >>Telefonkabel (4 adrig, (2xBus,+15V,GND). > > Tu dir selber einen Gefallen. Vergiss Multimaster. Single Master ist um > WELTEN einfacher und ist determinisitsch. Für deinen Krümelkram dreimal > ausreichend. Wenn dann mal stabil läuft und alles spielt kannst du über > (Un)sinn von Multimaster nachdenken. Ich denke eben, dass ich das falsch verstanden habe. Michael
A. K. wrote: >> mhm......gute Frage. >> Klar wenn ein Node Sendet, warten alle zugleich auf freigabe. >> Ich würde vorschlagen eine Random-Wartezeit einbauen. >> >> Sodass wenn zwei Busnoten warten würden, diese nie zugleich dann senden. >> Einer ist dann immer der Kürzere. >> >> @A. K. (prx): Was haltest du von der Idee?? > > Nichts. Gut Danke! > Nimm an der Bus wird grad frei, und 2 Nodes warten sehnsüchig drauf, > selber mal zu Wort zu kommen. Geht ohne Kollision nur mit > deterministischer Wartezeit, für jede Node eine andere. Die ist ja immer anders, da sie Zufallsmäßig bestimmt wird. > Nimm an der Bus ist schon ein Weilchen frei, und 2 Nodes kommen > gleichzeitig auf die gleiche Idee. Da gibt's nun garkeine > Vermeidungsstrategie mehr. Okay, da ist der Ball wieder bei dir, du hast recht, dass könnte passieren. > So wird das nix. Entweder Koordination (z.B. token passing) oder mit > Kollisionen leben. Für Letzteres sind RS485-Transceiver eher wenig > geeignet. Nur wie kann ich ein Token-Passing realisieren? > Nur: RS485 Multimaster ist seit Verfügbarkeit billiger CAN Controller > wie dem MCP2515 wenig sinnvoll geworden. Seither gilt als Daumenregel: > CAN für Multimaster, RS485 für Single. thx
Michael Wulz wrote: > Somit ist das Single-Master Betrieb, nur das der Master jeder Node sein > kann. Es muss eine eindeutige Festlegung geben, welche Node den Hut auf hat. Per Programm oder per Jumper oder wassweissich. Und diese Node fragt die anderen Nodes nacheinander ab. Von den übrigens Nodes darf nie eine ungefragt ihren Senf dazu geben.
A. K. wrote: > >> Somit ist das Single-Master Betrieb, nur das der Master jeder Node sein >> kann. > > Es muss eine eindeutige Festlegung geben, welche Node den Hut auf hat. > Per Programm oder per Jumper oder wassweissich. Und diese Node fragt die > anderen Nodes nacheinander ab. Von den übrigens Nodes darf nie eine > ungefragt ihren Senf dazu geben. Gut, ich muss somit über ein Register im Speicher des Controllers den Status "Senden-Erlauben" festlegen. Somit hat immer ein Node den "Token". Und am Ende des Senden-Erlauben wenn der Bus-Frei ist. Was muss ich dann machen? Es muss ja immer einer diesen "Token" haben. Es darf keinen Zustand geben, wo keiner den Token hat. Klar, aber was passiert wenn ein Node einen Token hat und dann ausfällt? danke M
Du bist glaube ich immer noch beim Multimaster. Diesmal beim Token Passing. Der dafür erforderliche Verwaltungs- und Testaufwand wird dir etliche schlaflose Nächte bereiten. Versprochen. Single Master heisst: Es gibt eine einzige rot angestriche Node, die Kommandos an eine beliebige der anderen blau angestrichenen Nodes sendet und deren Status/Daten abfragt. Ist die rote Node abgeschaltet, ist der Bus solange tot bis du den Pinsel schwingst. Unaufgefordert sendet nur die rote Node. Die sendet ein Kommndo an eine blaue Node und wartet endlich lange auf die Antwort. Eine blaue Node darf nur auf eine solche an sie gerichtete Anfrage antworten, sonst nicht.
Bei Pic´s , 9bit Übertragungen, bit 9 gesetzt = Node-Addresse, ansonten nur 8bit verwenden, aber 9bit Senden. So vermeidet man Probleme mit Syncronisation oder sonstigen Errors.
c. wrote: > Bei Pic´s , 9bit Übertragungen, bit 9 gesetzt = Node-Addresse, > ansonten nur 8bit verwenden, aber 9bit Senden. > So vermeidet man Probleme mit Syncronisation oder sonstigen Errors. Okay, wie kann ich das über die integrierte UART realisieren? Soweit ich weiss kann ich darüber nur 8-Bit Daten senden, oder? danke Michael
A. K. wrote: > Du bist glaube ich immer noch beim Multimaster. Diesmal beim Token > Passing. Der dafür erforderliche Verwaltungs- und Testaufwand wird dir > etliche schlaflose Nächte bereiten. Versprochen. Gut, ich brauch dann Koffeeintabletten! > Single Master heisst: Es gibt eine einzige rot angestriche Node, die > Kommandos an eine beliebige der anderen blau angestrichenen Nodes sendet > und deren Status/Daten abfragt. Ist die rote Node abgeschaltet, ist der > Bus solange tot bis du den Pinsel schwingst. Klar, deine Aquarellmalerei ist von mir verstanden aufgenommen worden. Kann ich dir mit "ACK" bestätigen! > Unaufgefordert sendet nur die rote Node. Die sendet ein Kommndo an eine > blaue Node und wartet endlich lange auf die Antwort. Eine blaue Node > darf nur auf eine solche an sie gerichtete Anfrage antworten, sonst > nicht. Okay, ich hatte es doch richtig verstanden ;-( Ich brauche Multi-Master aus dem ganz einfachen Grunde, dass ich diesen Bus gerne weiter als Hausbus ausbauen möche. Somit bauch ich zu jedem Geber oder Aktor nur die Busleitung hinlegen. In der Firmware des jeweiligen Aktors ist dann abgelegt was passiert wenn einer auf die Taste drückt, oder im Raum die Temperatur zu niedrig wird. Nämlich ein Befehl an den jeweiligen Node, Gib das Relais xy auf ON. Wenn ich einen Single-Master habe, sowas kann ich mit single-master nicht realisieren. Dadurch ich eben nicht x-viele Buskabel verlegen kann (Platztechnisch nicht realisierbar) wird diese Variante zum Einsatz kommen. danke Michael
Na dann - viel Vergnügen mit Multimaster-RS485. Kleiner Tip noch: Selbst Token Passing ist nicht unbedingt vollständig kollisionsfrei. Irgenwie muss man nämlich mit einem verschütt gegangenen Token klar kommen.
A. K. wrote: > Na dann - viel Vergnügen mit Multimaster-RS485. > > Kleiner Tip noch: Selbst Token Passing ist nicht unbedingt vollständig > kollisionsfrei. Irgenwie muss man nämlich mit einem verschütt gegangenen > Token klar kommen. Jop, wenn nämlich ein master einen Token hat und dann stirbt. Ich werd mir mal gedanken machen ;-) bzw. eventuell das Token-Ring mal anschaun (Computernetzwerk) vielleicht kann ich dort was abzweigen ! danke jedenfalls Michael
> Na dann - viel Vergnügen mit Multimaster-RS485.
Ist eigentlich nicht soo schwierig, wenn man sich ein paar Gedanken
macht und etwas 'sinnlose' Buslast in Kauf nimmt:
- Bus aufbauen mit x Nodes, jeder mit einer eindeutigen Adresse
- alle lauschen am Bus, geben aber nur Antwort, wenn sie gefragt sind
- alle haben einen Timer der abläuft (0,1 ... 1,0 ... 5,0 ... 10s ...
was
auch immer). Wird ein Node während dieser Zeit nicht angepollt, wartet
er eine Zufallszeit ab und fängt dann selbst an, alle verfügbaren
Addressen abzupollen -> ein neuer Master ist geboren
- Eine Übrgabe der Masterfünktion nach einer Zeit X sollte implementiert
sein, ebenso dass ein Node den Masterstatus anfordern kann, wenn er
ihn
braucht (z.B. PC)
Natürlich ist dass einiger Aufwand und man muss noch die Nutzdaten
händeln, aber das Konzept funktioniert im professionelllen Bereich ganz
gut (Maschinensteuerung physikalisch RS485 Protokoll modifiziertes
MODBUS RTU) auch ohne dezidierten Master. Man will damit maximale
Ausfallsicherheit erreichen.
Al wrote: >> Na dann - viel Vergnügen mit Multimaster-RS485. > > Ist eigentlich nicht soo schwierig, wenn man sich ein paar Gedanken > macht und etwas 'sinnlose' Buslast in Kauf nimmt: > > - Bus aufbauen mit x Nodes, jeder mit einer eindeutigen Adresse > - alle lauschen am Bus, geben aber nur Antwort, wenn sie gefragt sind > - alle haben einen Timer der abläuft (0,1 ... 1,0 ... 5,0 ... 10s ... > was > auch immer). Wird ein Node während dieser Zeit nicht angepollt, wartet > er eine Zufallszeit ab und fängt dann selbst an, alle verfügbaren > Addressen abzupollen -> ein neuer Master ist geboren > - Eine Übrgabe der Masterfünktion nach einer Zeit X sollte implementiert > sein, ebenso dass ein Node den Masterstatus anfordern kann, wenn er > ihn > braucht (z.B. PC) Sowas hatte ich mir auch ausgedacht. Nur mit der Weitergabe des Masters noch nicht gerechnet. > Natürlich ist dass einiger Aufwand und man muss noch die Nutzdaten > händeln, aber das Konzept funktioniert im professionelllen Bereich ganz > gut (Maschinensteuerung physikalisch RS485 Protokoll modifiziertes > MODBUS RTU) auch ohne dezidierten Master. Man will damit maximale > Ausfallsicherheit erreichen. Okay, aber ich denke, dass in dem Fall hier nicht so viele NutzDaten anfallen. Dies sollte also bei der geringen Bus-Geschwindigkeit kein Problem sein. Ich werd mir mal zwei PIC's schnappen und das MPLAB starten ;) danke jedenfalls für die Hilfe!!
> Nur mit der Weitergabe des Masters noch nicht gerechnet. Regelmässige Übergabe muss ja nicht sein, ist halt von der gleichmässigen Ausnutzung her interessant. Bei der angesprochene Maschinensteuerung ist der Master die Führungsmaschine, die bei Bedarf weitere Module zu- oder abschaltet. Gleichmäßige Ab- und Ausnutzung ist da ein Muss. Allerdings ist ohne Masterübergabe auf Anforderung kein Eingriff von aussen möglich - der Master lässt sich dann nichts sagen. Es sollte auch klar sein, dass bei einem Eingriff von auseen (PC) das Pollen mit übernommen werden muss, sonst Timeout & neuer Master ..... > Okay, aber ich denke, dass in dem Fall hier nicht so viele NutzDaten > anfallen. Dies sollte also bei der geringen Bus-Geschwindigkeit kein > Problem sein. Unsere Maschinen arbeiten mit 9600 Baud auf dem Bus, also auch nicht wirklich schnell ..... Modbus ist halt robust und hat alles was man braucht: Adressierung, Status, Nutzdaten, CRC-Prüfsumme und es ist recht gut dokumentiert. Ausserdem sind einige Hilfsprogramme verfügbar. > danke jedenfalls für die Hilfe!! Nix zu danken ;-)
Al wrote: ... > Unsere Maschinen arbeiten mit 9600 Baud auf dem Bus, also auch nicht > wirklich schnell ..... Modbus ist halt robust und hat alles was man > braucht: Adressierung, Status, Nutzdaten, CRC-Prüfsumme und es ist recht > gut dokumentiert. Ausserdem sind einige Hilfsprogramme verfügbar. Welche Maschinen sind das? Ich kenne den "ModBus", ein Kunde betreibt das Leitsystem von Papiermaschinen damit! gruss Michael
Hallo Michael, für Multi-Master ohne absolut sichere Abfragen, ob der Bus wirklich frei ist, empfiehlt sich - auch bei niedrigen Nutzdatenraten eine hohe Übertragungsfrequenz, dann ist der Bus nur kurze Zeit belegt. Ich habe derzeit bei 115,2kBit/s 13 RS485 Knoten im Multimaster Betrieb am Laufen - ohne größere Probleme ... Kollisionen gibt es bei mir hauptsächlich, wenn die Knoten im Debug-Betrieb unnötige Messages ausgeben ... Grüße Markus1748
Also ich würde einen PIC24xxxx nehmen. Deren UART hat ne Hardwaresteuerung für RS485. Die funktioniert sogar ;)
Matthias wrote: > Also ich würde einen PIC24xxxx nehmen. Deren UART hat ne > Hardwaresteuerung für RS485. Die funktioniert sogar ;) Danke für eure Tipps! Ich kenne zwar keinen aus der PIC24xxxx Serie, werd mir diese aber mal ansehen. Hab eh den ICD2, der sollte diese Serie auch debuggen und programmieren können. danke Michael
Naja, das debugging finde ich allgem. bei den Teilen nicht prickelnd. Aber funktionieren tun die. Ich empfehle den C30 (gibt es kostenlos - Studentenversion). Die PIC24 haben ein paar nette Features. Aber auch ein paar unangenehme Bugs (siehe Errata Sheet). Auch das IRQ-Handling ist gewöhnungsbedürftig... Aber irgendwie funktionieren die. ICh hab hier grad ein Projekt mit PIC24Hxx,PIC24Fxx und DSPIC33xxx am Laufen. Also alles machbar ;)
Michael Wulz wrote: > Ich brauche Multi-Master aus dem ganz einfachen Grunde, dass ich diesen > Bus gerne weiter als Hausbus ausbauen möche. Somit bauch ich zu jedem > Geber oder Aktor nur die Busleitung hinlegen. In der Firmware des > jeweiligen Aktors ist dann abgelegt was passiert wenn einer auf die > Taste drückt, oder im Raum die Temperatur zu niedrig wird. Nämlich ein > Befehl an den jeweiligen Node, Gib das Relais xy auf ON. Wenn ich einen > Single-Master habe, sowas kann ich mit single-master nicht realisieren. Klar geht das das mit Single-Master.... macht jedes SPS so... 1. Also alle Nodes sind strohdoof, und antworten nur auf Anfragen mit ihren Daten... 2. Ein Master (z.b. PC) fragt alle Nodes die Eingänge haben ab.... 3. Dann rechnet der Master aus was anhand der Eingänge passieren muss.. 4. Der Master schreibt alle Daten an die Nodes (die die Ausgänge haben) runter 5. wieder bei 2. beginnen JEDE SPS arbeitet so und damit über 90% der Maschinen heutzutage...warum sollte man das nicht genauso machen?
wie macht PHC (peha) das ?? da können alle module (eingänge/ausgänge) usw. (bei Ereignissen) senden.. (da wird IMHO auch "wiederholt" wenn was kollidiert..)
Ich verstehe bloss nicht, warum man sich für einfache Steuerungsaufgaben im Heim/Kleinstserienbereich RS485-Multimaster überhaupt noch antut. Kommt hier doch alle paar Wochen mal jemand mit der Idee vorbei. Klar, bei 20000 verkauften Geräten im Jahr mag es sich vielleicht lohnen mit RS485 günstigere Hardware und komplexere/teurere Software einzusetzen. Aber hier? Gibt's irgendwelche Horrorvorstellungen vor CAN, weil man den Fehler gemacht hat, mal bei CANopen reinzusehen?
Möchte mich kurz in die Diskussion mit einklinken, da ich auch gerade vor einer (wichtigen) Entscheidung stehe - RS485 Single Master oder CAN? CAN ist zwar alles schön und gut - jedoch ist der Preis um eine Spur höher, was die Hardware angeht. Was mir im Moment an CAN überhaupt nicht gefällt ist die riesige Hardware (28-Pin CAN-Controller, dazu 8-Pin CAN-Treiber); natürlich jeder wieder mit seinem eigenen Hühnerfutter rundherum. Bei 485 reicht im Prinzip ein MAX485 ev. noch nen Pullup + Terminierung und das wars. Was ich schon angedacht hatte: Anstatt einem Hausbus das ganze in mehrere Subnetze zerlegen (jede für sich voll funktionsfähig); die jeweiligen Master sind dann wiederum miteinander vernetzt. Der Einfachheit halber mit RS485. Welche signifikanten Vorteile bietet mir das CAN? Außer der vielleicht minimal schnelleren Telegrammbearbeitung, da Multimaster?
Hallo, ich habe im Moment ebenso die Entscheidung, wie ich diverse Komponenten mit einem zentralen Master miteinander verbinde. Für I2C sind die Leitungen etwas lang.... Mit RS485 in der RS422er-Konfiguration habe ich vor vielen Jahren einige Erfahrungen gemacht: 1 twisted pair vom Master-Transmitter an die Slave-Receiver und 1 weiteres Twisted-Pair für alle Slave-Transmitter zurück an den Master-Receiver. Leitung: 4-adrige Telefonleitung, Leitungslängen über 1000m und 64kBaud. Protokoll: 2 byte + Daten = Adr+Ctrl(1..32) + N(0...255) + N-Bytes Sollte im Haus bei den kürzeren Leitungslängen noch deutlich schneller gehen, ausserdem sind Repeater für mehr als 32 Knoten kein Problem. Edit: ...und Optokoppler sind kein Problem, da alles unidirektional arbeitet. Gruß, Michael
Nun muss ich aber doch mal eine Lanze für CAN brechen. Ich habe auch vor etlichen Monaten angefangen, so eine Art Hausbus aufzuziehen, und hatte mich eigentlich schon für RS485 entschieden. Mitten in die komplizierten Protokoll-Überlegungen (ich wollte auch so eine Art Multi-Master) hinein platzte die Neugier, wie es denn mit CAN wäre. Und auf einmal wurde alles ganz einfach! Man nehme beispielsweise den PIC18F4580, da ist das CAN-Modul schon drin. Außen noch ein Transceiver dran (8 pin) und fertig ist die Hardware. Und die Software macht dann richtig Spaß: Man übergibt auf einem Knoten ein Telegramm an das CAN-Modul, und schon wird es auf allen anderen Knoten empfangen und kann nach Belieben verarbeitet oder verworfen werden. Wer ist der Master, wann darf ich senden und wie vermeide ich Kollisionen? Alles kein Thema mehr, geht praktisch von alleine. Kein Vergleich zu dem Gefummel mit einzelnen Bytes über UART. Ich habe immer ein komplettes Telegramm vorliegen, bestehend aus 29 Bit ID plus 8 Byte Nutzdaten, damit lässt sich eigentlich alles erschlagen, was im Einfamilienhaus jemals vorkommt. Gerade wenn es ein Hobby-Projekt ist und ich wenig Zeit investieren kann, konzentriere ich mich doch lieber auf die Dinge, die Spaß machen. In meinem sehr persönlichen Fall ist es so, dass ich mehr Freude daran habe, mir eine Software-Architektur zu überlegen und die CAN-Telegramme mit Sinn zu füllen, als mich selbst um die Übertragung der einzelnen Bytes zu kümmern. Das lasse ich lieber das CAN-Modul übernehmen, dort haben andere schlaue Leute schon viel Arbeit reingesteckt.
gast wrote: > gefällt ist die riesige Hardware (28-Pin CAN-Controller, dazu 8-Pin > CAN-Treiber); Ein 18pin CAN-Controller tut es auch. Oder ggf. ein 28pin Microcontroller mit CAN drin, wenn du dich mit Microchip PIC18 oder PIC30 anfreunden kannst (allerdings ist AVR+MCP2515 billiger als PIC18F258). Der Unterschied liegt in der Software. Die paar Cents die du mit RS485 einsparst, die investierst du bei Multimaster-Betrieb in eine sehr viel komplexere Software. > Was ich schon angedacht hatte: Anstatt einem Hausbus das ganze in > mehrere Subnetze zerlegen Was die Kompexität der Software noch weiter erhöht. Wenn es dir eher um Beschäftigung geht als um Lösungen, dann ist das der richtige Weg. > Welche signifikanten Vorteile bietet mir das CAN? Es ist nicht das Tempo. Der Unterschied: Multimaster mit CAN funktioniert, sobald CAN überhaupt funktioniert. Um sicher zu sein, dass Multimaster-RS485 in allen Lebenslagen funktioniert musst du entweder bestehende Lösungen übernehmen oder erhebliche Zeit in Tests investieren, denn Tests auf Aspekte von Gleichzeitigkeit und Reaktion auf Störungen und Ausfälle sind ausgesprochen schwierig und Probleme so gut wie nicht reproduzierbar. Bei CAN haben das bereits andere für dich erledigt. Und das alles wegen 2€ Preisdifferenz pro Node? Wohlgemerkt: ich beziehe mich hier auf Multimaster-Betrieb. Wenn das nicht erforderlich ist, spricht nichts gegen RS485.
@ A. K. (prx) Danke für die Antwort! Ich bin eben noch am Überlegen, ob es überhaupt Multi-Master sein muss. Damit ich nicht unzählige Werte pollen muss, hätte ich das eben auf kleine Subnetze aufgeteilt. zB ein Subnetz nur für die Heizung - dann funktioniert die Heizung komplett unabhänig vom Licht (dezentral halt) Also die 2€ unterschied sind mir egal, das ist richtig. Da ich mit AVRs arbeiten möchte, fällt der PIC leider weg - und der AT90CAN128 ist für die meisten Anwendungen eindeutig zu groß. Folglich bleibt nur noch kleiner AVR + CAN-Controller + CAN-Treiber. RS485 würd ich wahrscheinlich eh nur im Single-Master fahren. Da frag ich mich eben ob ich Multi-Master brauche für eine Haussteuerung (dann wirds ein CAN); oder ob RS485 Single-Master ausreicht (zur Not eben unterteilt in Subnetze, damit die Polling-Zeit schön kurz bleibt)
Ich muss hier leider mal auf CAN eindreschen. Die Nutzdaten sind auf 6 Byte beschraenkt. Das mag gut sein, um einem Blinker zu blinken, ein Licht zu schalten, oder ein Rad zu bremsen. Aber etwas laengeres, ein gesampeltes Array, ein Filetransfer ist eher muehsam.
aha wrote: > Aber etwas laengeres, ein gesampeltes Array, > ein Filetransfer ist eher muehsam. Klar, CAN ist kein Ersatz für Ethernet, sondern ein Steuerbus. Wobei sich allerdings durchaus auch alle 8 Bytes für Bulk-Datentransfer nutzen lassen, denn man kann das Framing in den 29-Bit Adressen unterbringen. Ich übertrage so beispielsweise den Inhalt eines 4MBit Dataflash via CAN, wenn erforderlich. Das ist allerdings nicht die primäre Aufgabe des betreffenden Busses. Im gleichen Bus verwende ich auch eine LCD-Anzeige, deren Positionierung via Adressbits erfolgt, so dass auch hier 8 Bytes Nettoinhalt transportiert werden.
Mir ist gerade ein anderer Gedanke gekommen: zusätzlich zum RS485 könnte man eine Ader als Signalisierung für Sendewunsch/freigabe benutzen. Vorgestellt hätte ich mir das so, dass diese eine Leitung eine Ringleitung ist, die zB Idle=High möchte nun ein Teiln. etwas senden, so setzt er seinen Ausgang auf low und wartet, bis dieses Low wieder auf seinem Eingang angekommen ist. (Das Signal muss durch alle anderen Teilnehmer hindurch) Dann wissen die anderen, dass der Bus jetzt belegt ist und Kollisionen werden verhindert. Was haltet ihr von diesem Vorschlag? Was die Verkabelung betrifft natürlich ungünstig, da ja meist ein 2x2x0.8 verwendet wird (wenn man nicht gerade den Schirm als Masseleitung benutzt)
picbastler wrote: ..... > Man nehme beispielsweise den PIC18F4580, da ist das CAN-Modul schon > drin. Außen noch ein Transceiver dran (8 pin) und fertig ist die > Hardware. Und die Software macht dann richtig Spaß: Man übergibt auf > einem Knoten ein Telegramm an das CAN-Modul, und schon wird es auf allen > anderen Knoten empfangen und kann nach Belieben verarbeitet oder > verworfen werden. Deine Idee ist garnicht so schlecht ;-) Der PIC ist ein 8bit µC und einfach zu handhaben! Ich hab mit dem PIC18F4550 schon gearbeitet, da ist der 4580 nicht mehr weit weg ;-) Werd mir morgen gleich mal zwei bei Farnell bestellen und als Transciever einen LT1796 dazu. Oder habt Ihr eine bessere Wahl? > Wer ist der Master, wann darf ich senden und wie vermeide ich > Kollisionen? Alles kein Thema mehr, geht praktisch von alleine. Kein > Vergleich zu dem Gefummel mit einzelnen Bytes über UART. Ich habe immer > ein komplettes Telegramm vorliegen, bestehend aus 29 Bit ID plus 8 Byte > Nutzdaten, damit lässt sich eigentlich alles erschlagen, was im > Einfamilienhaus jemals vorkommt. > > Gerade wenn es ein Hobby-Projekt ist und ich wenig Zeit investieren > kann, konzentriere ich mich doch lieber auf die Dinge, die Spaß machen. > In meinem sehr persönlichen Fall ist es so, dass ich mehr Freude daran > habe, mir eine Software-Architektur zu überlegen und die CAN-Telegramme > mit Sinn zu füllen, als mich selbst um die Übertragung der einzelnen > Bytes zu kümmern. Das lasse ich lieber das CAN-Modul übernehmen, dort > haben andere schlaue Leute schon viel Arbeit reingesteckt. Mit welchem Compiler hast du das im MPLAB programmiert, ich mach alles in CCS C Compiler. Das wird vermutlich auch ein Spass hier einen Treiber programmieren oder finden ;-) danke Michael
Michael Wulz wrote: > Werd mir morgen gleich mal zwei bei Farnell bestellen und als > Transciever einen LT1796 dazu. Oder habt Ihr eine bessere Wahl? Aber pass auf dass du die Rev B0 kriegst. In die A1 hat Microchip extra was eingebaut damit einem nicht langweilig wird (die Punkte 5,6,8 gefallen mir ganz besonders).
Falls man genuegend Draehte hat, weil man zB mit einem flachband arbeitet, so kann man auch RS422 nehmen. Das is im Wesentlichen Dasselbe wie RS458,, aber fullduplex, ohne Richtung umschalten. Damit lassen sich sehr gut Master Slave Busse einrichten. In einer Richtung kann der Master immer senden, in der anderen Richtung antwortet nur der jeweils angesprochene Slave.
Transceiver? MCP2551, mit 100k an RS gegen GND, damit die Flanken nicht unnötig steil werden. Steht im Datenblatt. Mein Bus fährt mit 50 kbit/s (da ich keine gesampelten Arrays übertragen muss, reicht das völlig ;-), braucht keine speziellen Kabel und verträgt sogar lange Stichleitungen. Treiber? Ich habe mich am Datenblatt entlanggelesen und die Register entsprechend gesetzt. Mehr war nicht nötig. Als Anregung könntest du in den Anhang schauen (suche CanInit, CanSend, CanRecv). Compiler ist BoostC.
Es würde mich interessieren, was nun der Kostenunterschied zwischen CAN sowei RS485 besteht, sprich sind es Kostenunterschiede im 3 oder 4stelligen Bereich, wenn man alles durchrechnet ?
Pro Node: CAN: MCP2515 + PCA82C250: ca. 3,50€, betrieben via SPI. RS485: SN75176: 0,30€, betrieben via UART. Geht natürlich auch teurer, das sind die jeweilig billigsten Teile. So sind ATmega88+MCP2515 deutlich billiger als ein PIC18F258(0) mit integriertem CAN. Aufwand für Abschluss, Verkabelung, Schutzbeschaltung usw. ist praktisch gleich.
lrlr wrote: > wie macht PHC (peha) das ?? > > da können alle module (eingänge/ausgänge) usw. (bei Ereignissen) > senden.. (da wird IMHO auch "wiederholt" wenn was kollidiert..) Das könnt ihr euch in meinem Projekt "OpenHC" abgucken: http://openhc.wiki.sourceforge.net/ Der Code ist portabel, läuft auch auf einem nicht-Atmel. PHC arbeitet mit CRC-Prüfsummen, Kollisionserkennung, Bestätigung der Pakete durch den Empfänger, sowie ggf. Wiederholung. Damit kriegt man es in den Griff. Man könnte das angesprochene Projekt damit realisieren, muß das Rad nicht neu erfinden, außer man will unbedingt... ;-) Jörg
CAN vs RS485 ist ja ein Dauerbrenner. Wie schon ganz am Anfang jemand geschrieben hat: Heutzutage Multimaster => CAN, sonst RS485. Man wird sonst irre. Es wird immer wilder, man glaubt, man hat es, dann kommt aber Fall 318 und ... Argh! Es hat natürlich jeder seinen eigenen Ehrgeiz, von Anforderungen mal ganz abgesehen. Ich habe meinen "Seelenfrieden" in der Planung vorerst so gefunden: - Brauche ich wirklich Multi-Master? => Nein - Welche Übertragungsrate brauche ich? => Einige kbit/s reichen wirklich aus (und da ist noch viel Luft nach oben, wenn's hart kommt, wird eben etwas gepuffert, keine echtzeitanforderungen). - Billig wär sowieso gut. - Einfaches Protokoll, daß auch ich nach 3 Monaten noch verstehe und erweitern kann (ohne wieder das CAN-Protokoll lernen zu müssen). Ich verdrahte sowieso mit CAT 5e, also 8 Adern. Neben der Spannungsversorgung habe ich also noch locker eine Ader als Signalleitung frei. Wenn irgendein Node außerhalb der Reihe (zyklische Temperaturabfragen z.B.) meint, etwas mitteilen zu müssen, zieht er die Signalleitung einfach runter. Das löst bei allen (inkl. Master) einen Interrupt aus und sie erwachen alle aus dem sleepmode und können gleich angesprochen werden. Nun fragt der Master reihum, wer es denn war und fragt diesen dann ab. Keine wilden Szenarios mehr "und was, wenn dann ...". Himmlisch.
@ Lutz (Gast) >Ich verdrahte sowieso mit CAT 5e, also 8 Adern. Neben der Nobel geht die Welt zu Grunde. 0815 Klingeldraht tuts hier locker. >Spannungsversorgung habe ich also noch locker eine Ader als >Signalleitung frei. Wenn irgendein Node außerhalb der Reihe (zyklische >Temperaturabfragen z.B.) meint, etwas mitteilen zu müssen, Dann wäre es ja KEINE zyklische Abfrage, sondern eine _A_zyklische. Wobei man einfach die Frage stellen darf, wie schnell sich die Temperaturen oder Messwerte allgemein ändern. >fragt diesen dann ab. Keine wilden Szenarios mehr "und was, wenn dann Naja, deine Interruptleitung ist schon wieder wild. Lass die Sensoren doch einfach nach ein paar Sekunden einpennen (Sleep Mode). Wenn Ruhe auf dem Bus ist bleibt das so. Wenn irgend jemand Daten versendet, wachen sie wieder auf (Pin Change Interrupt) und lauschen den Dingen, die da kommen mögen. Wenn sie nicht angesprochen werden pennen sie wieder ein. Das kann man auch einfach als Interruptfuntion auf dem Bus "missbrauchen". Ein Sensor mit "ganz wichiger Meldung" pfeffert einfach ein paar Bytes auf den Bus. Der Master kriegt das mit, denkt sich "Hallo, wasn da los" und klappert die Pappenheimer ab. Poors Man Multimaster ;-) MFG Falk
>Ich verdrahte sowieso mit CAT 5e, also 8 Adern. Neben der >>Nobel geht die Welt zu Grunde. 0815 Klingeldraht tuts hier locker. Na ja, 100 m für 12,99 € bei Äbäh ist selbst für mich nicht nobel. Außerdem kann/könnte ich das einmal verlegte Kabel auch etwas universeller/anders nutzen. >>Dann wäre es ja KEINE zyklische Abfrage, sondern eine _A_zyklische. >>Wobei man einfach die Frage stellen darf, wie schnell sich die >>Temperaturen oder Messwerte allgemein ändern. Wie sagt der Jurust so schön: Es kommt darauf an. Es hat natürlich jeder "seinen" Hausbus vor Augen mit unterschiedlichen features. Zyklisch soll bei mir das Geplante sein, z.B. Temperaturabfragen alle 5 Minuten und auf SD-Karte loggen (bitte nicht fragen, wofür das gut ist), check, ob noch alle nodes dabei sind etc.. Es soll aber auch ereignisgesteuerte und unplanmäßige Aktivität geben wie z.B. Bewegungsmelder hat ausgelöst, Rauchmelder etc. >>Naja, deine Interruptleitung ist schon wieder wild. Lass die Sensoren >>doch einfach nach ein paar Sekunden einpennen (Sleep Mode). Wenn >>Ruhe auf dem Bus ist bleibt das so. Wenn irgend jemand Daten versendet, >>wachen sie wieder auf (Pin Change Interrupt) und lauschen den Dingen, >>die da kommen mögen. Wenn sie nicht angesprochen werden pennen sie >>wieder ein. Das kann man auch einfach als Interruptfuntion auf dem Bus >>"missbrauchen". >>Poors Man Multimaster ;-) Den Gedanken werde ich mal weiterverfolgen ... Ganz besonders, wenn die Adern knapp werden sollten.
Ich hätte da einen Voirschlag, nur bin ich nicht so fit in der Materie, vielleicht hilft Falk ja mit. Mein Vorschlag, Pic cpu´s mit integriertem Vreg (max 15V), also 12V System, sowie 2x integriertem comparator als rs485 Empfänger/Sender. Würde so 1.5 Euro kosten, kein rs485 transceiver, keine psu. Max 49mA, das geht. Nun kommt der schwierigere Teil. Wie die 12V sowie die rs485 Ein/Ausgänge vor Überspannung schützen.
Wird das jetzt ein Wettberwerb darum, wer noch den letzten sinnvoll investierten Cent durch Software ersetzen kann? Immerhin kostet ein RS485-Transceiver grad mal 30¢ und erspart manche Schutzschaltung (weil erstens recht robust und zweitens wenn in Fassung leicht ausgewechselt).
@A. K. (prx) >Wird das jetzt ein Wettberwerb darum, wer noch den letzten sinnvoll >investierten Cent durch Software ersetzen kann? Hehe, eigentlich nicht. Ich wäre da jedenfalls nicht dabei. > Immerhin kostet ein RS485-Transceiver grad mal 30¢ Naja, vielleicht die Uralt-Gurke von SN75176. Den würde ich heute nicht mehr nehmen (wollen). Was halbwegs gescheites in CMOS von Ratiopharm, ähhh Maxim & Co ist schon sinnvoll. > und erspart manche Schutzschaltung (weil >erstens recht robust und zweitens wenn in Fassung leicht ausgewechselt). Eben. Wer den "einspart" ist selber Schuld. Erst Recht in einer Massenanwendung.
Zum Thema "Einfach"... ich habe letzte Woche eine CAN Kommunikation zwischen zwei Pic18F4585 aufgebaut. Das Ganze war inkl. Installation des Compilers und der Entwicklungsumgebung in 4h erledigt. Und wenn man nicht so einen doofen Fehler beim setzen der Register macht wäre es auch in 2h gegangen. Und nun kann ich munter Knoten an den Bus hängen und es funktioniert einfach. Die Prio wird durch die CAN-ID festgelegt. Eigentlich ist CAN die einfachste Multimaster Kommunikation die ich kenne, fast schon Plug & Play :-) Ich unterstreiche somit aus eigener Erfahrung: SingleMaster -> RS485 MultiMaster -> CAN Und die paar Cent mehr im Vergleich zu deutlich weniger Stress ist mir das allemal Wert. Grüße T.
Das Problem, das ich mit CAN habe ist folgendes: stell dir vor, du brauchst irgendwo ganz abgesetzt einen digitalen Eingang (oder was auch immer), der aus irgendeinem Grund direkt am Bus angebunden sein muss; dann brauchst du bei RS485+simples Protokoll nen Max485 + 4kB AVR bei CAN hingegen entweder - CAN-Treiber + µC mit integr. CAN-Contr. oder - CAN-Treiber + CAN-Contr. + µC Rechnet euch da mal die Anzahl der Pins auf dem Layout aus bzw. überhaupt die Abmessungen der Platine. Bin jetzt fast gänzlich bei einem Ansatz, der in der untersten Ebene (also I/O) auf RS485 Singlemaster aufsetzt. All diese Master sind dann zB AT90CAN128 und übernehmen für sich schon abgekapselte Funktionen. Alle Master sind dann aber übergeordnet via CAN vernetzt. So hab ich einen Heizungs-Master, einen Licht-Master, ... die aber alle untereinander kommunizieren können. Ist denke ich ein guter Kompromiss zwischen kosten-/platzsparend und Funktionalität. mfg gast
Microchip hat ganz nette CAN-IO expander, auch eine Alternative. Weiters gibt es auch eine Soft-Can implementation für AVR, habe ich auch schon benutzt, da ich ein Gerät gemacht haben, wo 24V Signale waren, und laut Spezifikationen ein Can-Bus mit Bausteinen für 24V am sinnvollsten war, gleichzeitig jedoch bei geringsmöglichsten Kosten.
> gibt es auch eine Soft-Can implementation für AVR
Das ist aber interessant.
Zufällig einen Link parat? ;-)
Hab mir Caraca kurz angeschaut, habe aber leider keine Quellcodes zum Download gefunden. Von der Topologie her, ist es im Prinzip eh so ähnlich, wie ich es oben schon angesprochen habe. Ganz unten die I/Os, dann, darüberstehend, die Master, die wiederum untereinander vernetzt sind. Aber ist es nicht Sinn eines CAN, dass (fast) alle Teilnehmer auf derselben Ebene sind? Wenn ich das richtig verstanden habe, dann ist Caraca angelehnt an CAN (nutzt dieselben Treiberbausteine), aber nur bedingt kompatibel zum richtigen CAN, oder? Danke und mfg, gast
Caraca benutzt Can 2.0B passive, und kann keine overload-frame. Anstatt das Protokoll besser zu definieren, haben sich die Entwickler dazu entschlossen, die 11bit addresse als eine 6bit Addresse zu verwenden, und die restlichen 5bits als Funktionscode zu benutzen. Für miche eine unverständliche Limitierung. Wenn man nun den Caracas code, iso level 3 nicht benutz, dann hat man eine funktionierende Can 2.0B passive, welche durch ev. Erweitern des layer2 auch die 2.0B aktive beherrschen könnte, habe ich aber nicht gebraucht. Abgesehen vom overload-frame ist sie Standard, aber halt nur bei kleineren Geschwindigkeiten, 100khz ist nicht drinn. Wem aber 10-20k reicht, für den geht sie. Was ich gemacht habe: Funktionen mit AVR-AS compiliert, dann decompiliert sowie das Resultat als inline-C code im GCC als ein .h sowie .c file eingebunden.
Hallo, > Das Problem, das ich mit CAN habe ist folgendes: > stell dir vor, du brauchst irgendwo ganz abgesetzt einen digitalen > Eingang (oder was auch immer), der aus irgendeinem Grund direkt am Bus > angebunden sein muss; dann > brauchst du bei RS485+simples Protokoll nen Max485 + 4kB AVR > bei CAN hingegen entweder > - CAN-Treiber + µC mit integr. CAN-Contr. > oder > - CAN-Treiber + CAN-Contr. + µC > Rechnet euch da mal die Anzahl der Pins auf dem Layout aus bzw. > überhaupt die Abmessungen der Platine. Naja, das liegt an Deiner Festlegung auf den AVR. Ich liebe AVRs, aber für den Hausbus werde ich auf PICs setzen. Genau aus dem von Dir erwähnten Grund. Atmel hat eben keine kleinen µCs mit CAN. Microchip hingegen schon. Und die ersten Erfahrungen mit der 18F Familie und einem DevBoard und C-Compiler von mikroE sinde absolut positiv. Mit einem kleinen 28pin SMD PIC (PIC18F2480) mit CAN und einem Transiver ist die Packungsdichte IMO ok. Aber das ist meine pers. Sicht, ob das für Dich gilt oder Du mit der gemischten RS485/CAN glücklich wirst must Du entscheiden. Mir wäre allerdings die Verwendung zweier Technologien zu stressig. Grüße T.
RS485 ist ein ALOHA-Netz auf einem Feldbus. Die Hardware kann Kollisionen nicht verhindern oder darauf selbständig reagieren. Dafür gibt es Protokolle a-la CSMA/CD. Die funktionieren nach gleichem Muster. Zuerst auf den Bus hören, dann ein Timer mit Zufallszahl laden und erst nach Ablauf wird gehört und bei freiem Bus gesendet. Bei einigen Systemen werden logarithmische, andere lineare Timer.Damit lässt sich gut mit Kollisionssituation umgehen.
@mwulz Ich habe genau aus dem gleichen Grunde vor einiger Zeit (Als Controller mit integrietem CAN noch nicht üblich oder sauteuer waren) die Variante UART + RS485-Treiber (75176) gewählt. Bin dabei auch auf das Kollisionsproblem bei Multi-Master gestossen. Dazu musste ich eine Busbelegungsvariante programmieren, die Kollisionen erkennt und Datenverfälschungen vermeidet. Es sollten aber auch Prioritäten möglich sein, um wichtige Meldungen (Alarm) vorrangig zu behandeln. Ich benutzte dafür die normalen UART Leitungen TxD und RxD sowie einen PIN zur Hochohmigschaltung des RS485-Treibers. Der Empfängerteil des 75176 war immer aktiv. Die Variante mit dem 9-ten Datenbit der Controller für Adressen verringerte die zeitliche Belastung der angeschlossenen Teilnehmer erheblich. Trotzdem ist das Senden an alle, an eine Gruppe oder genau an einen Teilnehmer möglich. Trotzdem sind ganz paar Knoten nur mit einem AT98C2051 ausgerüstet und machen dabei neben dem Datenprotokoll noch ihre eigenen Aufgaben. Ich rede immer von der Vergangenheit, weil es inzwischen nicht mehr ganz so wie oben beschrieben ist: Ich verwende statt RS485-Pegel CAN-Pegel (!!! Also doch). Deshalb sind jetzt ausschliesslich PCA82C250 und kompatible am Zweidrahtbus zu finden. Am Protokoll habe ich nichts geändert. Weshalb also der Umbau? 1. Einsparung des zusätzlichen PIN für die Hochohmigkeit 2. Gemischter Betrieb meines alten Protokolles mit dem CAN Protokoll an der gleichen Leitung, da jetzt entsprechende Controller erschwinglich sind.
Selbe Frage nur andere Hardware-Vorgaben, Moin @ll Habe sogesehen selbige Frage wie Themenstarter, nur habe ich 2 unterschiedliche RS485 Systeme. Sender via PLM 7xx von Sabo 2-Wire und Empfänger via 4-Wire-RS485. Kann ich die tx- und rx- leitungen einfach weglassen oder muß ich da noch einen Konverter zwischen jagen?
Hallo, schau dir mal das fhem-projekt und meinen Beitrag an Beitrag "homematic-wired-I/O-Module im Eigenbau" Gruß Daniel Hauck
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.