mikrocontroller.net

Forum: Haus & Smart Home RS485 Bus aufbauen


Autor: Michael Wulz (mwulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael Wulz (mwulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael Wulz (mwulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Wulz (mwulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael Wulz (mwulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was für ein PIC Controller soll denn zum Einsatz kommen?

Autor: c. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael Wulz (mwulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias wrote:
> Was für ein PIC Controller soll denn zum Einsatz kommen?

PIC16F877

gruss
M

Autor: Michael Wulz (mwulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Wulz (mwulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael Wulz (mwulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Al (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Michael Wulz (mwulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!!

Autor: c. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benutze einfach sowas, http://www.hth.com/snap/
würde nicht meine erste wahl sein, aber ok.

Autor: Al (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ;-)

Autor: Michael Wulz (mwulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus Xy (markus1748)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich würde einen PIC24xxxx nehmen. Deren UART hat ne 
Hardwaresteuerung für RS485. Die funktioniert sogar ;)

Autor: Michael Wulz (mwulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: ... ... (docean) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: lrlr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael Appelt (micha54)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: picbastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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)

Autor: aha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Michael Wulz (mwulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: aha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: picbastler (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Chris S. (schris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> gibt es auch eine Soft-Can implementation für AVR
Das ist aber interessant.
Zufällig einen Link parat? ;-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://caraca.sourceforge.net/
Ist aber offenbar 2002 eingeschlafen.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Chris S. (schris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: DD4DA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Route_66 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Maik Geßner (maik81ftl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Daniel Hauck (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

schau dir mal das fhem-projekt und meinen Beitrag an

Beitrag "homematic-wired-I/O-Module im Eigenbau"

Gruß

Daniel Hauck

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.