Forum: Mikrocontroller und Digitale Elektronik Umsetzung "kleines" Bussystem für AVR im Haus


von Hugo P. (portisch)


Lesenswert?

Hallo,

bevor ich mich draufstürze eine Fehler zu machen möchte ich mich erst 
wegen Erfahrungen erkundigen.

Im Aufbau ist Fix eine SPS die eine RS232 Schnittstelle hat.
Nun würde ich einen AVR platzieren der die Daten von 1-Wire 
Temperatursensoren (MAXIM) über RS232 an die SPS übergibt. Die SPS hat 
dann einen Webserver, der die Werte anzeigen kann.

Die Temperaturmessung ist somit abgedeckt.

Nun hatte ich die Idee, da IRMP so gut funktioniert im Haus 
(Wohnbereich) Empfänger zu platzieren um z.B. Licht mit der 
Fernbedienung steuern zu können.

Nun stellt sich mir die Frage wie ich die 2 (oder mehr) AVRs am besten 
miteinander verbinde!?

Wegen den Temp-Sensoren kommt ja schon das 1-Wire zum Einsatz.

Also der AVR der 1-Wire auf RS232 umsetzt ist sozusagen der Master. 
Diesen kann ich auch noch V-USB verpassen, damit ich mit einem Laptop 
dann den AVR und die Slave AVRs konfigurieren kann.

Um einen Slave AVR zu konfigurieren sollte es reichen, dass Command und 
der zugehörige IRMP Code zum Slave zu senden. Also ca. 8 Bytes pro 
Befehl die vom Master zum Slave gesendet werden müssen.
Die Maximale Anzahl ergibt sich dann an der Größe des AVR Speichers.
a
Der Slave legt die Codes im EEPROM ab und vergleicht damit die 
dekodierten Fernbedienungsbefehle von IRMP. Wird ein passender Code 
empfangen soll der Slave AVR einfach das Command an den Master senden. 
Also die "normale" Komunikation beschrängt sich auf 1-2 Bytes die vom 
Slave zum Master gesendet werden müssen. Dies sollte aber am besten vom 
Slave getriggert werden damit nicht die ganze Zeit der Master die Slaves 
abfragen muss. Es sollte ja schon so funktionieren, dass ich die Taste 
auf der Fernbedienung drücke und die SPS diesen Befehl dann maximal 
500ms später erhält.

Geht das überhaupt mit 1-Wire?

Die Leitungslängen werden sich so um ca 10-50m herum abspielen.
I2C fällt da ja voll aus, oder? SPI auch und RS232 ist schon in 
Verwendung.
Als Kabel wird eine Klingelleitung 4x2x0,6 z.B. zum Einsatz kommen, da 
alle Schalter als Taster ausgeführt werden und diese mit 24V an der SP 
hängen.

von avrGerd (Gast)


Lesenswert?

Recht einfach ist z.Bsp. RS485.

sie hier: http://www.mikrocontroller.net/articles/RS-485

avrGerd

von Hugo P. (portisch)


Lesenswert?

avrGerd schrieb:
> Recht einfach ist z.Bsp. RS485.
>
> sie hier: http://www.mikrocontroller.net/articles/RS-485
>
> avrGerd

Muss der nicht an der RS232 vom AVR hängen?
Auch habe ich dann ja den 1-Wire ja schon drinnen. Ich müsste sozusagen 
den Slave nur zusätzlich "draufhängen".

Ich glaube aber, dass der Slave nichts direkt an den Master schicken 
kann, sondern das der Master den Slave Abfragen muss. Bei 16KBits/s sind 
das 2048 Bytes/s. Ich glaube da ist auch Polling der Slaves völlig im 
grünen Bereich. Mal sehen...

von Peter D. (peda)


Lesenswert?

avrGerd schrieb:
> Recht einfach ist z.Bsp. RS485.

Stimmt, das ist nämlich nur die Pegelspezifikation.
Will man aber RS485 praktisch nutzen, muß man erstmal ein riesen 
Protokollgedöns dafür programmieren.

Ich würde daher für neue Projekte den CAN-Bus nehmen. Da ist die 
Hardware billig und die Software ganz easy, macht alles schon der 
CAN-Chip.

Schade ist nur, daß bei den AVRs die CAN-Auswahl recht dünn ist.


Peter

von Thomas B. (nichtessbar)


Lesenswert?

Ich arbeite bzw. Finalsiere gerade eine Bibliothek, die zwischen uC / 
PC-Komponenten via Master-Slave Prinzip und fertigem Protokoll (inkl. 
Fehlerbehandlung, repeative sending, ...) Daten sicher überträgt. Denke 
das ist so ziemlich genau das was du suchst, habe ich auch schon in 
mehreren Gebäudebeleuchtungsprojekten über RS485 eingesetzt, Testphase 
läuft jetzt seit ca. 1.5 Jahre ;)

Max. 1 Master (derzeit, Protokoll unterstützt bis zu 3 simultane) und 
max. 254 Slaves.

RW-Output auf uC (AVR) für Umschalten von RS485-Bausteinen zwischen 
Lesen und Schreiben ist fertig implementiert.

Codegröße ~3.0kB in kleinster Version (daran arbeite ich gerade), 
Implementierte Übertragungsarten: Daten- und Befehlstransfer, jeweils 
Unicast, Multicast und Broadcast.

Filetransfer ist auch schon implementiert aber noch nicht in der 
Bibliothek enthalten.


Bei Interesse melde dich mal

von Hugo P. (portisch)


Lesenswert?

Danke euch!

Mit AVR und CAN habe ich noch gar nicht gearbeitet. Kenne es aber von 
unserer Firma.

Aber wie gesagt, dass 1-Wire ist wegen den Sensoren Pflicht und somit 
schon vorhanden.

>> Bei Interesse melde dich mal

Werde ich vielleicht! Aber danke dafür!
Ich werde mich jetzt erst einmal (zum ersten mal) mit 1-wire und den 
Temp-Chips spielen. Das habe ich ja auch noch nie gemacht und habe somit 
noch keine praktischen Erfahrungen damit.

Wenn ich das stabil zum Laufen bekomme werde ich es einmal mit Polling 
von AVRs über 1-Wire probieren.

Beim I2C z.B. habe ich schon einige praktische Erfahrungen gemacht und 
würde es mir daher nicht im Haus installieren... ;)

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Funk wäre auch ne Lösung, vor allem, wenn keine Kabel liegen oder 
verlegt werden sollen. Für die berüchtigten RFM module gibts da auch 
schon komplette 'Sensornetzwerk' Lösungen. Am besten im 868 Mhz Bereich 
, da ist nicht so viel los.
Jeder Node kriegt ein RFM12 Modul und wartet auf die Aufforderung des 
Masters.
http://www.mikrocontroller.net/articles/RFM12

von holger (Gast)


Lesenswert?

>Wenn ich das stabil zum Laufen bekomme werde ich es einmal mit Polling
>von AVRs über 1-Wire probieren.
>
>Beim I2C z.B. habe ich schon einige praktische Erfahrungen gemacht und
>würde es mir daher nicht im Haus installieren... ;)

Dan wirst du 1-Wire auch nicht mögen.

von Hugo P. (portisch)


Lesenswert?

Ich habe heute meine DS18B20 Sensoren bekommen und diese mit diesem 
Source angebunden:
http://gandalf.arubi.uni-kl.de/avr_projects/tempsensor/index.html

Das funktioniert schon einmal ohne Probleme mit 2 Sensoren.

Nun habe ich auch einmal einen Kabelbund von ~80m als Datenleitung 
drangehängt. Ging ohne Probleme.

Die Slave implementierung gestalltet sich aber schwerer:
http://github.com/smurfix/owslave

Auch bin ich mir nicht sicher ob IRMP und ein Zeitlich kritisches 
Protokoll zusammen auf einem AVR funktionieren.

Das mit CAN und z.B. RS485 gefällt mir deswegen nicht da ich kein 
Sternnetz machen kann. Der Master AVR sitzt zentral im Keller und ich 
will die Busleitung nicht von einer Seite im Haus zur anderen 
durchziehen müssen sondern direkt vom Keller hinfahren.

von Thomas B. (nichtessbar)


Angehängte Dateien:

Lesenswert?

Hab 1 Wire in der Praxis noch nie verwendet (werde das aber bald machen, 
weil ich sehen will ob über angehängte Schaltung meine 
Bibliotheksfunktionen auch laufen..) aber was spricht gegen eine 
Schaltung aus ein paar Logikgatter, die abhängig von der 
Datentransferrichtung die richtigen Leitungen auf den Bus durchschaltet 
(Multiplexer) und auf der anderen Seite wieder demultiplexed?

EDIT: Hab grad erst gemerkt, dass Logikgatter ja kein Tristate haben 
sondern auf Masse ziehen ^^ Nehmt die selten her, aktualiserte Schaltung 
kommt gleich

(Bitte zu beachten dass die Schaltung im Anhang NICHT getestet oder 
validiert ist..)

von Thomas B. (nichtessbar)


Angehängte Dateien:

Lesenswert?

Hm, war zu langsam, aktualisierte Schaltung im Anhang.

Änderung gegenüber der ersten: Ist jetz wirklich ein Multiplexer, da die 
jeweils nicht aktive Leitung (gesteuert durch R!W) high-impedance ist. 
Während des Umschaltvorgangs (der theor. gleichzeitig geschieht) sorgt 
der Pullup für ein stabiles Signal.

ADG411 ist vl. nicht der optimale Baustein für diese Anwendung, es 
sollte halt irgendein Analogschalter / Multiplexer sein, der bei nicht 
durchgeschaltetem Eingang entsprechend hochohmig ist.

Inwieweit das ganze dann auf einen Stern noch funktioniert bzw. der Bus 
generell stabil ist (bei langen Leitungen sollte man wenn möglich im 
Mittel jeden Gleichanteil vermeiden da dieser oftmals stark bedämpft und 
somit nicht mitübertragen wird, siehe Leitungstheorie) sei mal 
dahingestellt ;)


Ich hoffe jetzt hab ich keinen Blödsinn mehr verbreitet, bin heute nicht 
mehr besonders denkfähig...

von Hugo P. (portisch)


Lesenswert?

Ich habe jetzt noch den Eigenbaubus von Clemens Helfmeier:
Beitrag "1-Drahtbidirektionalbus über große Distanz mit AVR"
gefunden.

Dieser scheint recht einfach aufgebaut und ausreichend zu sein. Auch das 
bidirektionale senden von Daten ist super um Polling zu vermeiden.
Es kann ja sein, dass für mehrere Tage keine Datenübertragung notwenig 
ist.
Mann müsste halt noch ein ID-Handling mit einbauen, damit die AVRs 
wissen wenn die Daten gehören.

Zwischen Master und Slave mit IRMP werden nur wenige Daten übertragen.
Am besten ist es die IR-Codes mit einer ID zum Slave zu übertragen. Mit 
einer 8Bit Ir-Code-ID kann man dann 256 Funktionen am Slave 
einprogrammieren. Wird der passende IR-Code von IRMP dekodiert sendet 
dieser einfach nur die ID zum Master.

256 IDs werden es nicht ganz sein, denn ein IRMP IR-Code braucht 
mindestens 5 Bytes * 256 = 1280 Bytes. Der Atmega168 z.B. hat "nur" 512 
Bytes EEPROM = 85 IDs.
Es müsste halt immer dann der EEPROM Inhalt ins SRAM geladen werden 
damit nicht dauernd auf das EEPROM zugegriffen werden muss.

Nun habe ich leider wenig Erfahrung mit den Timern!

Slave:
IRMP verwendet ja schon den Timer1 (16Bit) um die IR Signale zu 
dekodieren.
Das Bussystem von Clemens benutzt auch den Timer1. Dieser müsste dann 
für Timer0 (8Bit) umgebaut werden, oder? Kann das überhaupt dann noch 
funktionieren?

Master:
UART, ist ja eh in der Hardware des AVR drinnen.
One-Wire für die Temp.Sensoren. Die Implementierung von Martin Thomas 
benutzt soweit ich gesehen habe keine Timer.
D.h. Timer1 ist für das extra Bussystem verfügbar.
Timer0 könnte dann noch benützt werden um die Temperatur Sensoren 
zyklisch abzufragen.

Ist diese Umsetzung mit z.B. 2 Atmega168 möglich?

von Thomas B. (nichtessbar)


Lesenswert?

Hugo Portisch schrieb:
> Ist diese Umsetzung mit z.B. 2 Atmega168 möglich?

Grundsätzlich ja, mit den Timern musst halt sehen wie du klarkommst, 
Kannst ja einfach einen 8-Bit Timer nehmen, den immer bis zum Overflow 
laufen lassen und eine Variable erhöhen (quasi das higher Byte 
Softwaremäßig) und dann halt abfragen, wann dieses Byte überlauft, dann 
hattest grob 256*256 Zyklen, gleich wie beim 16 Bit timer, nur langsamer 
weil dazwischen Rechenaufwand anfällt, musst halt sehen wie sich das 
ausgeht...

von wolfram (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Hugo,
ich habs schon an einigen Stellen hier gepostet. Auch ich habe eine 
Hausautomatisierung gebaut und dabei recht viel Erfahrung gesammelt.
Von der Verwendung von 1wire kann ich Dir dringend abraten. Das 
funktioniert auf kurzen Strecken, aber wenns nicht geht hast Du 
praktisch keine Chance raus zu finden warum. Was war noch gleich das 
letzte was ich angeschlossen habe.
Ich habe heute noch Reste der 1-Wire Lösung im Haus zum Auslesen von 
DS18S20 Temperatursensoren, das geht meistens, ist aber nicht 
lebenswichtig wenn es eben mal nicht geht.

Die 1-Wire zu Digital-out-Chips habe ich auch schon mal probiert, aber 
es gilt obiges. Zudem ist das 1-Wire Protokoll für alle Devicetypen 
alles andere als einfach zu implementieren.

Ich verwende übrigens im ganzen Haus CAN-Bus, und das nach ausprobieren 
bzw. untersuchen vieler verschiedener Verfahren (RS485, ZigBee, 1-Wire, 
EIB). Im nachfolgenden Thread hab ich mal davon geschrieben wie das so 
funktioniert.
Beitrag "Hausautomatisierung im neuen Haus"

Über ein CAN/USB Gateway ist der Bus an einer kleinen Linux Büchse 
angeschlossen, die dann über Webseite von Smartphone bedient werden 
kann. Hier überlege ich demnächst einen Linux Router zu verwenden der 
eben auch USB Anschluss hat, dann braucht das ganze nur 10W.
Gerne kann ich Dir mehr zu meinen 1-Wire Erfahrungen erzählen.

von Axel (Gast)


Lesenswert?

Ich habe das biher auch mit 1-Wire gemacht, ingesamt 10 AVR-Slaves, 
überwiegend HR20 Heizungsthermostate, Markisen/Fenstersteuerung im 
Wintergarten, und ein paar Temperatursensoren.

Im Prinzip funktioniert das schon, durch die CRC ist das auch relativ 
gut abgesichtert.

Aber nur im Prinzip. Wenn ein Controller ausfällt, kann der den ganzen 
Bus auf Masse ziehen und nichts geht mehr. Die Zuverlässigkeit ist auf 
so einer langen Leitung begrenzt. Und wenn Du nicht strickt eine 
Linientopologie einhältst, solltest du Dir die Qualität der Signale am 
besten nicht ansehen. Ich habe mitlerweile einen ziemlichen Wildwuchs an 
Leitungen, die Signalqualität ist unter aller Sau und die 
Übertragungsqualität auch. Noch funktioniert es, aber mehr geht auch 
nicht.

Ich gehe daher dazu über, Ethernet-> 1-wire Interfaces zu machen. 
Ethernet liegt sowieso überall im Haus, von da aus gehen dann 1-Wire 
Leitungen zu den Aktoren/Sensoren, wo nicht sowieso schon die Steuerung 
Ethernet hat.

Gruss
Axel

von wolfram (Gast)


Lesenswert?

Axel schrieb:
> Aber nur im Prinzip. Wenn ein Controller ausfällt, kann der den ganzen
> Bus auf Masse ziehen und nichts geht mehr. Die Zuverlässigkeit ist auf
> so einer langen Leitung begrenzt. Und wenn Du nicht strickt eine
> Linientopologie einhältst, solltest du Dir die Qualität der Signale am
> besten nicht ansehen. Ich habe mitlerweile einen ziemlichen Wildwuchs an
> Leitungen, die Signalqualität ist unter aller Sau und die
> Übertragungsqualität auch. Noch funktioniert es, aber mehr geht auch
> nicht.
Das hätte ich nicht besser schreiben können ;-)..
Das schlimme ist man weiß nicht was noch geht..

Ethernet liegt zwar bei mir auch im ganzen Haus, aber ich wollte nicht 
für jede Rollade Ethernet verschwenden..

Du kannst übrigens alte Routerhardware mit Linux verwenden, dafür gibts 
1-Wire Treiber..
Gruß Wolfram

von Axel (Gast)


Lesenswert?

>Ethernet liegt zwar bei mir auch im ganzen Haus, aber ich wollte nicht
>für jede Rollade Ethernet verschwenden..

Muss man ja nicht. Ich groupiere das, ein Ethernet Board ist z. B. für 
das Wohnzimmer/Wintergarten zuständig (Rolladen, Markise, Heizung). Die 
Verteilung in diese Räume hinein geht dann per 1-wire.

Ebenso für die Kinderzimmer. Manche Geräte bekommen einen eigenen 
Anschluss (Wärmepumpe, Solaranlage, Heizung). Und es gibt ein Board 
(ähnlich dem Pollin Board) für die Zentralsteuerung.

So kann ich auf alle Ethernetknoten direkt vom PC etc. zugreifen, 
Software updaten etc. Die können auch jeweils autonom agieren, wenn ein 
Fehler auftritt, so dass nicht das ganze Haus stillsteht.

HMI will ich jetzt übrigens mit einem Touchlet von Pollin machen. Kostet 
59€, dafür hat man dann ein Webinterface, welches auf alle Gruppen 
zugreifen kann und per WLAN irgendwo positioniert werden kann.

Gruss
Axel

von Hugo P. (portisch)


Angehängte Dateien:

Lesenswert?

Erst einmal Danke für die Hilfreichen Tipps und Ideen!

Ich habe mich die letzte Woche mit dem Bus:
Beitrag "1-Drahtbidirektionalbus über große Distanz mit AVR"

beschäftigt.

Ob es wirklich dabei bleibt...mal sehen!

Derzeit habe ich umgesetzt:
Master:
Atmega168
RS232 Anbindung
OneWire Bus an PD7 um Temp Sensoren verwenden zu können.
Eigenbau OneWire Bus an PB0 (Timer1 ICP) um die AVRs miteinander zu 
verbinden.

Slave:
Atmega168
IRMP
Eigenbau OneWire Bus an PB0 (Timer1 ICP) um die AVRs miteinander zu 
verbinden.

Ablauf:
Der Master fragt jede Minute die Tempsensoren ab und gibt den Wert+SN an 
der RS232 aus.
Über die RS232 kann man über den Master die Slaves IRMP Codes 
programmieren.
Der Slave vergleicht die IR Codes und schickt das eingestellte Command 
Byte zum Master falls der Code passt. Damit wird der Bus entlastet, da 
nicht jeder IR-Code über den Bus muss.

Im Testaufbau funktioniert es schon ganz gut.
Es fehlt halt noch einiges:
Richtiges Errorhandling/Retry.
Tests mit mehr als einem Slave.
Und überhaupt ob der Bus auf die Länge noch geht...


Auch muss ich mir noch Gedanken dazu machen, wie ich z.B. ein LED AVR 
RGB Steuerung als Slave einbinde. Oder ich nehme einfach Warmweiße für 
indirekte Beleuchtung die ich einfach ein/ausschalte!?

Beispiel der RS232 mit 2 Temp Sensoren:
000 085 011 048 040 033 057 187 003 000 000 009 236 000 000 085 011 048 
040 168 056 187 003 000 000 184 236 000

000 sync byte 1
085 sync byte 2
011 data len
048 command byte
040 id
033 id
057 id
187 id
003 id
000 id
000 id
009 id
236 temp int16
000 temp int16 = 23,6°C

000 sync byte 1
085 sync byte 2
011 data len
048 command byte
040 id
168 id
056 id
187 id
003 id
000 id
000 id
184 id
236 temp int16
000 temp int16 = 23,6°C

Um z.B. den IRMP Code zu programmieren:
Protokoll: 0x02
Address: 0xBF40
Command: 0x0021
Flags: 0x00


Hex: 00 55 08 00 11 02 40 BF 21 00 00

00 sync byte 1
55 sync byte 2
08 data len
00 command byte
11 IRMP command byte
02 Protokoll
40 Address
BF Address
21 Command
00 Command
00 Flags

Wenn nun dieser Code empfangen wird bekommt man das IRMP Command byte:
0x00 0x55 0x02 0x10 0x11

0x00 sync byte 1
0x55 sync byte 2
0x02 data len
0x10 command
0x11 IRMP Command

>> Muss man ja nicht. Ich groupiere das, ein Ethernet Board ist z. B. für
>> das Wohnzimmer/Wintergarten zuständig (Rolladen, Markise, Heizung). Die
>> Verteilung in diese Räume hinein geht dann per 1-wire.

Ist das ein selberbau Ethernet Board? So hört sich das gar nicht so blöd 
an. Geht dann von jedem Board ein LAN Kabel an den Switch/Router oder 
sind die in einem Ring/Strang miteinander verbunden?

von Hugo P. (portisch)


Lesenswert?

Also wegen der Verbindung der AVRs untereinander nochmal:

Ich schwanke nun immer mehr auf CAN (mit MCP2515 per SPI).
(Muster vom MCP2515 und MCP2551 habe cih mir aber trotzdem schon einmal 
angeschafft.)

Jedoch was ich davon noch nicht (zu 100%) weiß:

1. Wie "langsam" kann man den BUS fahren? Der Datentransfer ist ja sehr 
gering und es würden eigentlich 9,6kpbs schon ausreichen.
Je langsamer man unterwegs desto weniger anfällig ist das System wegen 
fehlender Terminierung und Stichleitungen.

2. Kann ich auch ~256 Bytes an einem Slave schicken? Das CAN Paket hat 
ja 8 Bytes Nutzdaten. Oder kann man hier einfach 32 Pakete verschicken?

3. Wie "gut" arbeitet der MCP2515?
In unserer Firma haben wir schon schlechte Erfahrungen mit dem MCDP2510 
gemacht. Wenn länger nichts auf dem Bus los war hat der Chip den Bus mit 
Fehlern überschwemmt. Dieser wurde dann durch den MCP2515 ersetzt, wobei 
dieser anscheinend auch seine Eigenheiten hat:
http://ww1.microchip.com/downloads/en/Devicedoc/80179g.pdf

So wie Axel gefällt mir das sehr gut. Ich werde z.B. einen AVR bei der 
SPS (Daten -> RS232 Brücke) und andere AVRs mit 1-Wire und/oder IRMP im 
Haus verteilen. Die Verbindung der AVRs werde ich über LAN Kabel 
herstellen. da sind genug Adern drinnen für CAN-H/L und +5V/GND und 
geschirmt ist es auch gleich.

von wolfram (Gast)


Angehängte Dateien:

Lesenswert?

Hugo Portisch schrieb:
> 1. Wie "langsam" kann man den BUS fahren? Der Datentransfer ist ja sehr
> gering und es würden eigentlich 9,6kpbs schon ausreichen.

Hallo Hugo,
alsi ich verwende den CAN Bus weils einfach sicher funktioniert. Siehe 
auch meine anderen Posts zum Thema.
Ich verwende den Bus über gesamtlängen von ca. 75m, wobei ich sowohl 
Ring- als auch Sterntopologie gemischt habe, teilweise mit 10m 
Stichleitungen.
Ging aus bautechnischen Gründen halt nicht anders.
Ich verwende eine CAN Bus Speed von 125kBit/s. Langsamer als 20kBit ist 
meiner Meinung nicht notwendig.
Zum Thema Qualität MCP2515: Der funktioniert wunderbar, und es gibt auch 
genug Infomationen im Netz dazu wie man den programmiert etc.
und DAS war für MICH der Grund den zu verwenden.
Ich verwende den MCP 2515 zusammen mit einem ATMEGA 644 als lokalen 
Controller. Siehe Bild. Der MCP sitzt oben auf der Platine, der 
ATMEGA644 unten.
>Je langsamer man unterwegs desto weniger anfällig ist das System wegen
>fehlender Terminierung und Stichleitungen.
Ja, aber bei 10kBit kein Problem.

>Die Verbindung der AVRs werde ich über LAN Kabel herstellen.
ich verwende stattdessen EIB Bus Kabel. Das sind grüne 4-adrige 
geschirmte Kabel.
Warum ? Nun, ich habe lokale AVR/CAN Controller die direkt 230V 
schalten, und das zumeist in derselben UP-Dose. Und das EIB-Kabel ist 
für solche Zwecke entwickelt UND zugelassen.
Auch vermischt man dann nicht aus Versehen LAN- und Hausbuskabel.

Man kann natürlich mehr als 8 Bytes versenden, muss aber dann (aber auch 
bei 8 Bytes) ein Protokoll implementieren.
Bei mir funktioniert alles recht gut mit 8 Byte Telegrammen, was willst 
Du mit 256 Byte ?

von Hugo P. (portisch)


Lesenswert?

wolfram schrieb:
> Man kann natürlich mehr als 8 Bytes versenden, muss aber dann (aber auch
> bei 8 Bytes) ein Protokoll implementieren.
> Bei mir funktioniert alles recht gut mit 8 Byte Telegrammen, was willst
> Du mit 256 Byte ?

Naja, ich will die Slaves über das Netzwerk konfigurieren. Dazu brauche 
ich mehr als 8 Bytes.

Das mit den EIB Kabel ist ein guter Tipp. Das CAT5e Kabel gibt es halt 
günstiger. Aber wie du schreibst ist Verwechselungsgefahr. Aber dazu 
nehmen wir bei uns in der Firma Kabel mit unterschiedlichen Farben.
CAN: Gelb, LAN: Weiß, Syncnet: Rot,....

EIB 2x2x0.8 ~0,30/m
CAT5e ~0,15/m - 0,20/m

von Wolfram (Gast)


Lesenswert?

Hugo Portisch schrieb:
> Naja, ich will die Slaves über das Netzwerk konfigurieren. Dazu brauche
> ich mehr als 8 Bytes.

Warum brauchts Du mehr?
Ich konfigurier die Söaves per 2 bzw. 3 Byte Befehl und übertrage dann 
die Parameter einzeln. Quasi wie Modbus, setze ich die Registerparameter 
einzeln. Man muss ja in de Regel auch nur einzelne Parameter ändern.
Rolladenlaufzeit, Helligkeitssensor Limit etc.
Und jeder Slave bekommt dann nur die Parameter die er auch "braucht"

EIB Kabel kriegt man über Ebay recht günstig ;-)

von Hugo P. (portisch)


Lesenswert?

Eigentlich habe ich vorgesehen, dem Slave eine Liste von IRMP Codes zu 
schicken. Dies sind dann 7 Bytes * Anzahl der Codes (~10-20).
Vorteil hier ist, dass schon der Slave die empfangenen IR Codes mit der 
Liste vergleicht und nur dann ein Command an den Master schickt wenn 
dieser auch zutrifft -> wenig (bis fast keine) Buslast.

Ansonsten würden dauernd alle IRMP Codes zum Master geschickt, auch wenn 
der Code von einer anderen Fernbedienung stammt und mit der Steuerung 
überhaupt nichts zu tun hat. -> hohe Buslast.

Und Danke für den Tipp mit 123...

Aber ich habe schon den CAN Bootloader für den MCP2515 gefunden und da 
werden auch mehr Bytes übertragen.
Das muss ich mir noch ansehen wie es am besten zum Lösen ist!

von B. J. (bjue)


Lesenswert?

Frage an wolfram:
Womit hast Du die Ipod Menüs erstellt?
Gibt es eigentlich noch weitere Infos zu Deinem Hausbussystem?
Du bist leider nur als Gast angemeldet, sonst hätte ich Dich direkt 
kontaktiert...

von Wolfram L. (amazon)


Lesenswert?

B. Jue schrieb:
> Ipod Menüs erstellt?

Die Ipod-Menüs sind mit iWebkit (Google) erstellt.

von Hugo P. (portisch)


Lesenswert?

Hallo nochmal!

Ich hahbe nun den MCP2515 mit der CAN-Lib in Betrieb genommen.
Senden von einzelnen Messages hin und her funktioniert auch schon ohne 
Probleme. Nun frage ich mich aber wie ich es am besten/einfachsten mache 
wenn ich z.B. 12 Bytes an Daten verschicken will.

Ich habe schon etwas herumprobiert, komme aber zu keiner "guten" Lösung.

Deswegen will ich hier einmal fragen ob das schon mal jemand mit der 
CAN-Lib umgesetzt hat!?

Also ein einfaches Beispiel:

Sender Node 0x01 zerlegt die 12 Bytes in mindestens 2 CAN Messages 
(Kommt darauf an wieviele Datenbytes pro Message aufgenommen werden).

Empfänger Node 0x02 empfängt die zwei Nachrichten und baut damit die 12 
Bytes wieder zusammen.

Hat da jemand vielleicht ein kleines Beispiel-Programm.

Danke!

von SNR (Gast)


Lesenswert?

Du kannst ja z.B. im ersten Datenbyte immer angeben wie lange die 
Nachricht an den angesprochenen Node ist. Also in der Nachricht einen 
Protokoll-Header einbauen.

Schau Dir mal CANopen oder ähnliches an, die machen das da so (und 
vieles mehr).

Grüße

von Hugo P. (portisch)


Lesenswert?

Ok, ich habe mir jetzt ein bisschen den AVR CAN Bootloader angesehen.
Da ich diesen sowieso einsetzen werde habe ich mich daran gehalten.

Also 4 Byte Header, 4 Byte Daten pro Message.

Das geht auch schon recht gut.
Nun habe ich aber ein Eigenschaft des MCP2515 festgestellt:
Wenn im Transmitbuffer Nachrichten mit der gleichen Priorität drinnen 
liegen wird zuerst die letzte Nachricht versendet.

D.H. Wenn ich nacheinander 3 Messages schicken will kommt diese 
Reihenfolge beim Empfänger an:

M0
M2
M1

Senden will ich aber:
M0
M1
M2

Wenn die Nachrichten verdreht werden stimmt ja der Counter usw. beim 
Empfänger nicht mehr.

Derzeit hätte ich es so gelöst, dass ich nach jedem can_send_message 
z.B. 50ms warte. Das gefällt mir aber nicht so gut...
Gibt es da noch einen anderen Trick?

von (prx) A. K. (prx)


Lesenswert?

Ich übertrage den kompletten Inhalt eines 4Mbit Protokollspeichers via 
CAN. Aufgeteilt auf mittelgrosse Blöcke mit Adressen, jeweils bestehend 
aus einer gewissen Anzahl von 8-Byte Datenhappen. Kontrolliert wird die 
Übertragung eines solchen Blockes durch Sequenzinformation in der ID.

Wenn man sowas am Stück sendet, dann sollte man sich sicher sein, dass 
der Empfänger dabei nicht absäuft. Was leicht vorkommen kann, wenn der 
Absender mehr CAN-Puffer hat als der Empfänger. Insofern wärs klüger, 
wenn man die Frames nicht in den Puffern der CAN-Tx Hardware stapelt, 
sondern im Gänsemarsch auf die Reise schickt, also den nächsten solchen 
Frame erst wenn der vorherige durch ist, ggf. mit etwas Pause 
dazwischen. Dann erledigt sich auch das oben skizzierte Problem der 
Reihenfolge.

Der Gänsemarsch erledigte sich bei mir aber ohnehin von selber, denn der 
verwendete Controller hatte einen Bug, der effektiv nur einen der 3 
Tx-Buffer nutzbar machte.

von Hugo P. (portisch)


Lesenswert?

>> Gänsemarsch

Danke für den Tipp!!

Ich habe "einfach" in der CAN-Lib die Verwendung der anderen Buffer 
auskommentiert. Nun habe ich auch einen schönen "Gänsemarsch"! ;)
1
  if (_bit_is_clear(status, 2)) {
2
    address = 0x00;
3
  //}
4
  //else if (_bit_is_clear(status, 4)) {
5
  //  address = 0x02;
6
  //} 
7
  //else if (_bit_is_clear(status, 6)) {
8
  //  address = 0x04;
9
  }
10
  else {
11
    // Alle Puffer sind belegt,
12
    // Nachricht kann nicht verschickt werden
13
    return 0;
14
  }

von Hugo P. (portisch)


Lesenswert?

Ich hänge beim CAN Bus nun wieder ein bisschen :(

Ich halte mich an das Protokoll vom CAN Bootloader:
http://www.kreatives-chaos.com/artikel/can-bootloader

Ich kann auch schon schön Daten in die Messages aufteilen und diese 
nacheinander verschicken.

Mein Problem ist nun, wenn ich ein WRONG_NUMBER_REPSONSE auftreten 
würde!

Ich müsste also nach jedem Senden einer Nachricht prüfen ob ein 
WRONG_NUMBER_REPSONSE oder ein Error zurückkommt.
Das ist mit nur einem Slave ja kein Problem.

Also ca. so:

while not data transfer finished
{
send_can_message

check_if_response
}

Wenn nun aber ein zweiter Slave oder mehrere Slaves dran hängen die in 
der gleichen Zeit eine Nachricht an den Master schicken gehen diese 
(oder zumindest Teile davon) verloren. Im "check_if response" wird ja 
eine Nachricht abgefragt und nur auf einen Error für den laufenden 
Transfer abgefragt.

Hat die empfangene Nachricht mit dem Transfer gar nichts zu tun ist sie 
verloren.

Ich weis nicht wie das besser Umgesetzt werden kann.
Die einzige Idee was ich jetzt hätte ist dass ich die Nachricht die 
nichts mit dem aktuellen Transfer zu tun hat einfach buffere.
Wenn der aktuelle Transfer fertig ist kann dieser Buffer dann 
abgearbeitet werden.

Kennt vielleicht jemand ein ähnliches "Protokoll" das sich mit diesem 
Thema beschäftigt? Muss ja nicht CAN sein.

von Daniel E. (everyday_fun69)


Lesenswert?

Hallo zusammen,

So eine ähnliche Idee hat ich auch mal. Zum Glück hat mich jemand 
belehrt, solche Basteleien in Hinblick auf Sicherheit, Verfügbarkeit und 
Zukunft genau zu überdenken. Auch an den Verkauf sollte man denken, wer 
kauft gern gebasteltes ? Ich habe mich dann zum Glück für EIB 
entschieden. Geht mal  was kaputt Kauf ich einen neuen Aktor oder 
Sensor, Tausch das Element im Programm aus und fertig. Mit dem koppler 
fürs Internet könnte man den Spaß noch erweitern. Nur für die 
Spielmatzen die das unbedingt brauchen.

Nur meine Meinung und Hinweis.

von Stefan K. (stefan64)


Lesenswert?

Sehr hilfreich nach 4 Jahren ...

Bitte 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
Noch kein Account? Hier anmelden.