Mikrocontroller.net - Benutzerbeiträge [de]

CAN als Hausbus

2005-01-03T10:26:49Z

84.130.13.65:

[http://www.mikrocontroller.net/forum/read-1-66019.html#136169 Forum ]
[[Category:Projekte]]
[[Category:avr]]
[[Category:CAN]]
Das solle eine Übersichtseite werden die Projekte mit [[CAN-Bus]] als grundlage für einen Hausbus vorstellt. Es sollen auch Informationen die Can insbesondere als Hausbus betreffen gesammelt werden.

=Infos=
==Verkablung==
===Strang===
Laut offiziellen Definition ist nur ein Strang und insbesamt Stichleitungen von 2m länge erlaubt.
===Sternverkablung===
Von Bernhard:
Ich habe es in meinem Haus so
gemacht. An jedem Ende ( 20 Knoten ) habe ich den Bus mit 12K
abgeschlossen.
Die ersten 12 Knoten ( Erdgeschoss ) laufen seit 13 Monaten ohne
Probleme. Bei der heute abgeschlossenen Erweiterung um 8 Knoten in
einem weiteren Geschoss hatte ich erst Probleme.

=Projekte=
==[http://www.canathome.de/ canathome]==

Als Basis dienen AVR und Fujitsu MB90F497. Setzte Änderung: 2003-04-12

==[http://caraca.sourceforge.net/ caraca]==

CAN

2005-01-03T10:18:57Z

84.130.13.65:

[[Category:CAN-Bus]]

=Hardware=
==Mikrokontroller mit CAN==
=== AT90CAN128===
==CAN Controller==
===MCP2515 ===
SPI fähiger Can-Controller von microchip.
*2?

===SJA1000===
*Parallele schnittstelle ca 12 leitungen
==Bustreiber==
===MCP2551===
==SLIO-CAN==
Preisgünstigsten Bausteine sind die Serial Linked I/O Bausteine ( SLIO ). Diese Bausteine ermöglichen den ufbau von Ein- und Ausgabeknoten ohne lokalen Prozessor. Auf der Basis dieser Bausteine läßt sich eine dezentrale Signal-Ein-Ausgabe mit minimalem Kostenaufwand realisieren.

*P82C150
* Single-Chip-I/O-Einheit mit integriertem CAN-Controller
* mögliche Busdatenrate 20kBd bis 125kBd
* interner RC-Oszillator wird durch den Bitstrom auf den Bus synchronisiert
* Kalibrierungsnachricht alle 8000 Bitzeiten erforderlich
o 4-Bit des Identifiers über Port-Pins einstellbar
* maximal 16 P82C150 in einem CAN-Segment
o 16 Port-Pins mit unterschiedlichen Konfigurationsmöglichkeiten
+ 16 mal als digitale Eingänge
+ 16 mal als digitale Ausgänge
+ 2 mal als analoger Ausgang ( 10-Bit, DPM )
+ 6 mal als analoger Eingang ( 10-Bit, multiplex )
+ 2 mal als Komperator
[http://www.htw-dresden.de/fe/labor/mikror/projects/slio_can/]

*DS 36001M

==Allgemein==
* [http://can-wiki.info CAN-WIKI] - spezielle Wiki Site für CAN bus (Englisch)
==Dongles==
*[http://private.addcom.de/horo/can200/ Can200 Selbstbauprojekt]
*[http://www.mhs-elektronik.de/cgi-bin/mhs.pl?id1=1&id2=1 mhs-elektronik]
*[http://www.cantronik.com/ cantronik]
==Sonstiges==
[[CAN als Hausbus]]

CAN als Hausbus

2005-01-03T10:18:14Z

84.130.13.65:

CAN

2005-01-03T10:14:07Z

84.130.13.65: /* Dongles */

=Hardware=
==Mikrokontroller mit CAN==
=== AT90CAN128===
==CAN Controller==
===MCP2515 ===
SPI fähiger Can-Controller von microchip.
*2?

===SJA1000===
*Parallele schnittstelle ca 12 leitungen
==Bustreiber==
===MCP2551===
==SLIO-CAN==
Preisgünstigsten Bausteine sind die Serial Linked I/O Bausteine ( SLIO ). Diese Bausteine ermöglichen den ufbau von Ein- und Ausgabeknoten ohne lokalen Prozessor. Auf der Basis dieser Bausteine läßt sich eine dezentrale Signal-Ein-Ausgabe mit minimalem Kostenaufwand realisieren.

*P82C150
* Single-Chip-I/O-Einheit mit integriertem CAN-Controller
* mögliche Busdatenrate 20kBd bis 125kBd
* interner RC-Oszillator wird durch den Bitstrom auf den Bus synchronisiert
* Kalibrierungsnachricht alle 8000 Bitzeiten erforderlich
o 4-Bit des Identifiers über Port-Pins einstellbar
* maximal 16 P82C150 in einem CAN-Segment
o 16 Port-Pins mit unterschiedlichen Konfigurationsmöglichkeiten
+ 16 mal als digitale Eingänge
+ 16 mal als digitale Ausgänge
+ 2 mal als analoger Ausgang ( 10-Bit, DPM )
+ 6 mal als analoger Eingang ( 10-Bit, multiplex )
+ 2 mal als Komperator
[http://www.htw-dresden.de/fe/labor/mikror/projects/slio_can/]

*DS 36001M

==Allgemein==
* [http://can-wiki.info CAN-WIKI] - spezielle Wiki Site für CAN bus (Englisch)
==Dongles==
*[http://private.addcom.de/horo/can200/ Can200 Selbstbauprojekt]
*[http://www.mhs-elektronik.de/cgi-bin/mhs.pl?id1=1&id2=1 mhs-elektronik]
*[http://www.cantronik.com/ cantronik]
==Sonstiges==
[[CAN als Hausbus]]

CAN als Hausbus

2005-01-03T10:13:03Z

84.130.13.65:

[http://www.mikrocontroller.net/forum/read-1-66019.html#136169 Forum ]
[[Category:Projekte]]
[[Category:avr]]

Das solle eine Übersichtseite werden die Projekte mit [[CAN-Bus]] als grundlage für einen Hausbus vorstellt. Es sollen auch Informationen die Can insbesondere als Hausbus betreffen gesammelt werden.

=Projekte=
==[http://www.canathome.de/ canathome]==

Als Basis dienen AVR und Fujitsu MB90F497. Setzte Änderung: 2003-04-12

==[http://caraca.sourceforge.net/ caraca]==

CAN als Hausbus

2005-01-03T10:11:43Z

84.130.13.65: /* [http://www.canathome.de/ canathome] */

[http://www.mikrocontroller.net/forum/read-1-66019.html#136169 Forum ]
[[Category:Projekte]]
[[Category:avr]]

Das solle eine Übersichtseite werden die Projekte mit [[CAN]] als grundlage für einen Hausbus vorstellt. Es sollen auch Informationen die Can insbesondere als Hausbus betreffen gesammelt werden.

=Projekte=
==[http://www.canathome.de/ canathome]==

Als Basis dienen AVR und Fujitsu MB90F497. Setzte Änderung: 2003-04-12

==[http://caraca.sourceforge.net/ caraca]==

CAN als Hausbus

2005-01-03T10:09:54Z

84.130.13.65:

[http://www.mikrocontroller.net/forum/read-1-66019.html#136169 Forum ]
[[Category:Projekte]]
[[Category:avr]]

Das solle eine Übersichtseite werden die Projekte mit [[CAN]] als grundlage für einen Hausbus vorstellt. Es sollen auch Informationen die Can insbesondere als Hausbus betreffen gesammelt werden.

=Projekte=
==[http://www.canathome.de/ canathome]==
==[http://caraca.sourceforge.net/ caraca]==

Hausbus

2005-01-03T10:08:43Z

84.130.13.65:

[http://www.mikrocontroller.net/forum/read-1-66019.html#136169 Forum ]

=Anforderungen=
==Zentral/Dezentral==
Grundsätzlich kann so eine Steuerung zentral oder dezentral arbeiten (wobei natürlich auch Mischformen denkbar sind).
===Zentral===
Beim zentralen Ansatz gibt es einen Master, der zyklisch alle Sensoren (Thermometer, Lichtschalter, usw.) abfrägt und dann die entsprechenden Aktionen auslöst.
+ wenig Intelligenz bei den Sensoren/Aktoren nötig
+ bei Konfigurationsänderungen keine Änderungen bei den Sensoren/Aktoren nötig.
+ keine Multimasterfähigkeit nötig
- je mehr Sensoren vorhanden sind, desto länger dauert ein Abfragezyklus.
Da so ein selbst gebauter Hausbus ja auch Raum für Erweiterungen bieten soll,
sollte man schon mit 100-200 Sensoren rechnen (Lichtschalter, Thermometer,
Glasbruchsensoren, Rauchmelder usw. usf)
- Wenn die Zentrale ausfällt, dann fällt die gesamte Steuerung auf einmal aus
===Dezentral===
Beim dezentralen Ansatz senden die Sensoren (z.B. Lichtschalter) Botschaften an die Aktoren (z.B. die Glühlampe).
+ Die Buslast hängt von der Anzahl Ereignisse ab und nicht von der Anzahl Sensoren.
Ein Glasbruchsensor der nie aktiv wird verursacht auch keine Buslast.
+ Keine Schaltzentrale nötig (also kein Single Point of Failure)
- Multimasterfähigkeit bei allen Sendern (also allen Sensoren) nötig.
- Konfigurationsänderungen müssen immer an den entsprechenden Aktoren/Sensoren gemacht
werden. Dazu muß man sie entweder fernkonfigurieren können oder mit dem Konfigurationsgerät
direkt an die jeweiligen Geräte.

==Geschwindigkeit==
Solange man nur ein einzelnes Wohnhaus (und nicht etwa eine Schule oder eine Fabrik) ausrüsten will und nur die üblichen Sensoren/Aktoren hat, ist praktisch jeder Bus schnell genug. Andererseits erlauben RS485 und der CAN-Bus bei den in einem Haus vorkommenden Kabellängen auch durchaus Geschwindigkeiten von 1 MBit/s, wodurch man auch andere Anwendungen damit realisieren könnte.

=Vergleich von Hausbussystemen=

EIB
+ nur 2 Leitungen für Daten, Power und GND
+ kein Abschluss-R nötig, alle Bustopologien
+ multimasterfähig
- Chips nur schwer erhältlich und teuer

CAN
+ Protokoll bereits im Chip
+ multimasterfähig
+ übertragunssicher (d.h. bei Übertragungsfehler werden Daten automatisch wiederholt)
O Preis ist ausgewogen
- es werden 2 Leitungen Daten + Power + GND benötigt
- Abzweigungen vom Bus sind problematisch (max. 1m?)
- Abschluss-R notwendig

RS485
+ sehr günstig
+ Schnittstellenbausteine können direkt an den USART eines MCs angeschlossen werden
- von Haus aus nicht multimasterfähig, muß per Software realisiert werden

I2C
+ billig
+ multimasterfähig
- keine differentielle Übertragung, dadurch deutlich störanfälliger
- ohne "größeren" Aufwand nur Kabellängen <10m möglich

Ethernet
+ teuer
+ multimasterfähig
+ sehr schnell
- beim heute üblichen TP-Kabel nur Sternstruktur möglich
- aufwendig anzusteuern

=Links=
==CAN==
[[CAN als Hausbus]]

==Ethernet==
[http://www.ifas.htwk-leipzig.de/easytoweb/php/download/Verwendung%20eines%208-bit%20Microcontrollers%20zur%20Ethernet%20Vernetzung%20in%20der%20Hausautomation.pdf Diplomarbeit]

Hausbus

2005-01-03T10:08:08Z

84.130.13.65: /* CAN */

[http://www.mikrocontroller.net/forum/read-1-66019.html#136169 Forum ]
[[Category:Projekte]]
[[Category:avr]]

=Anforderungen=
==Zentral/Dezentral==
Grundsätzlich kann so eine Steuerung zentral oder dezentral arbeiten (wobei natürlich auch Mischformen denkbar sind).
===Zentral===
Beim zentralen Ansatz gibt es einen Master, der zyklisch alle Sensoren (Thermometer, Lichtschalter, usw.) abfrägt und dann die entsprechenden Aktionen auslöst.
+ wenig Intelligenz bei den Sensoren/Aktoren nötig
+ bei Konfigurationsänderungen keine Änderungen bei den Sensoren/Aktoren nötig.
+ keine Multimasterfähigkeit nötig
- je mehr Sensoren vorhanden sind, desto länger dauert ein Abfragezyklus.
Da so ein selbst gebauter Hausbus ja auch Raum für Erweiterungen bieten soll,
sollte man schon mit 100-200 Sensoren rechnen (Lichtschalter, Thermometer,
Glasbruchsensoren, Rauchmelder usw. usf)
- Wenn die Zentrale ausfällt, dann fällt die gesamte Steuerung auf einmal aus
===Dezentral===
Beim dezentralen Ansatz senden die Sensoren (z.B. Lichtschalter) Botschaften an die Aktoren (z.B. die Glühlampe).
+ Die Buslast hängt von der Anzahl Ereignisse ab und nicht von der Anzahl Sensoren.
Ein Glasbruchsensor der nie aktiv wird verursacht auch keine Buslast.
+ Keine Schaltzentrale nötig (also kein Single Point of Failure)
- Multimasterfähigkeit bei allen Sendern (also allen Sensoren) nötig.
- Konfigurationsänderungen müssen immer an den entsprechenden Aktoren/Sensoren gemacht
werden. Dazu muß man sie entweder fernkonfigurieren können oder mit dem Konfigurationsgerät
direkt an die jeweiligen Geräte.

==Geschwindigkeit==
Solange man nur ein einzelnes Wohnhaus (und nicht etwa eine Schule oder eine Fabrik) ausrüsten will und nur die üblichen Sensoren/Aktoren hat, ist praktisch jeder Bus schnell genug. Andererseits erlauben RS485 und der CAN-Bus bei den in einem Haus vorkommenden Kabellängen auch durchaus Geschwindigkeiten von 1 MBit/s, wodurch man auch andere Anwendungen damit realisieren könnte.

=Vergleich von Hausbussystemen=

EIB
+ nur 2 Leitungen für Daten, Power und GND
+ kein Abschluss-R nötig, alle Bustopologien
+ multimasterfähig
- Chips nur schwer erhältlich und teuer

CAN
+ Protokoll bereits im Chip
+ multimasterfähig
+ übertragunssicher (d.h. bei Übertragungsfehler werden Daten automatisch wiederholt)
O Preis ist ausgewogen
- es werden 2 Leitungen Daten + Power + GND benötigt
- Abzweigungen vom Bus sind problematisch (max. 1m?)
- Abschluss-R notwendig

RS485
+ sehr günstig
+ Schnittstellenbausteine können direkt an den USART eines MCs angeschlossen werden
- von Haus aus nicht multimasterfähig, muß per Software realisiert werden

I2C
+ billig
+ multimasterfähig
- keine differentielle Übertragung, dadurch deutlich störanfälliger
- ohne "größeren" Aufwand nur Kabellängen <10m möglich

Ethernet
+ teuer
+ multimasterfähig
+ sehr schnell
- beim heute üblichen TP-Kabel nur Sternstruktur möglich
- aufwendig anzusteuern

=Links=
==CAN==
[[CAN als Hausbus]]

==Ethernet==
[http://www.ifas.htwk-leipzig.de/easytoweb/php/download/Verwendung%20eines%208-bit%20Microcontrollers%20zur%20Ethernet%20Vernetzung%20in%20der%20Hausautomation.pdf Diplomarbeit]

Hausbus

2005-01-03T10:07:47Z

84.130.13.65: /* Vergleich von Hausbussystemen */

[http://www.mikrocontroller.net/forum/read-1-66019.html#136169 Forum ]
[[Category:Projekte]]
[[Category:avr]]

=Anforderungen=
==Zentral/Dezentral==
Grundsätzlich kann so eine Steuerung zentral oder dezentral arbeiten (wobei natürlich auch Mischformen denkbar sind).
===Zentral===
Beim zentralen Ansatz gibt es einen Master, der zyklisch alle Sensoren (Thermometer, Lichtschalter, usw.) abfrägt und dann die entsprechenden Aktionen auslöst.
+ wenig Intelligenz bei den Sensoren/Aktoren nötig
+ bei Konfigurationsänderungen keine Änderungen bei den Sensoren/Aktoren nötig.
+ keine Multimasterfähigkeit nötig
- je mehr Sensoren vorhanden sind, desto länger dauert ein Abfragezyklus.
Da so ein selbst gebauter Hausbus ja auch Raum für Erweiterungen bieten soll,
sollte man schon mit 100-200 Sensoren rechnen (Lichtschalter, Thermometer,
Glasbruchsensoren, Rauchmelder usw. usf)
- Wenn die Zentrale ausfällt, dann fällt die gesamte Steuerung auf einmal aus
===Dezentral===
Beim dezentralen Ansatz senden die Sensoren (z.B. Lichtschalter) Botschaften an die Aktoren (z.B. die Glühlampe).
+ Die Buslast hängt von der Anzahl Ereignisse ab und nicht von der Anzahl Sensoren.
Ein Glasbruchsensor der nie aktiv wird verursacht auch keine Buslast.
+ Keine Schaltzentrale nötig (also kein Single Point of Failure)
- Multimasterfähigkeit bei allen Sendern (also allen Sensoren) nötig.
- Konfigurationsänderungen müssen immer an den entsprechenden Aktoren/Sensoren gemacht
werden. Dazu muß man sie entweder fernkonfigurieren können oder mit dem Konfigurationsgerät
direkt an die jeweiligen Geräte.

==Geschwindigkeit==
Solange man nur ein einzelnes Wohnhaus (und nicht etwa eine Schule oder eine Fabrik) ausrüsten will und nur die üblichen Sensoren/Aktoren hat, ist praktisch jeder Bus schnell genug. Andererseits erlauben RS485 und der CAN-Bus bei den in einem Haus vorkommenden Kabellängen auch durchaus Geschwindigkeiten von 1 MBit/s, wodurch man auch andere Anwendungen damit realisieren könnte.

=Vergleich von Hausbussystemen=

EIB
+ nur 2 Leitungen für Daten, Power und GND
+ kein Abschluss-R nötig, alle Bustopologien
+ multimasterfähig
- Chips nur schwer erhältlich und teuer

CAN
+ Protokoll bereits im Chip
+ multimasterfähig
+ übertragunssicher (d.h. bei Übertragungsfehler werden Daten automatisch wiederholt)
O Preis ist ausgewogen
- es werden 2 Leitungen Daten + Power + GND benötigt
- Abzweigungen vom Bus sind problematisch (max. 1m?)
- Abschluss-R notwendig

RS485
+ sehr günstig
+ Schnittstellenbausteine können direkt an den USART eines MCs angeschlossen werden
- von Haus aus nicht multimasterfähig, muß per Software realisiert werden

I2C
+ billig
+ multimasterfähig
- keine differentielle Übertragung, dadurch deutlich störanfälliger
- ohne "größeren" Aufwand nur Kabellängen <10m möglich

Ethernet
+ teuer
+ multimasterfähig
+ sehr schnell
- beim heute üblichen TP-Kabel nur Sternstruktur möglich
- aufwendig anzusteuern

=Links=
==CAN==
CAN als Hausbus
==Ethernet==
[http://www.ifas.htwk-leipzig.de/easytoweb/php/download/Verwendung%20eines%208-bit%20Microcontrollers%20zur%20Ethernet%20Vernetzung%20in%20der%20Hausautomation.pdf Diplomarbeit]

CAN als Hausbus

2005-01-03T10:05:23Z

84.130.13.65:

[http://www.mikrocontroller.net/forum/read-1-66019.html#136169 Forum ]
[[Category:Projekte]]
[[Category:avr]]

Das solle eine Übersichtseite werden die Projekte mit Can als grundlage für einen Hausbus vorstellt. Es sollen auch Informationen die Can insbesondere als Hausbus betreffen gesammelt werden.

=Projekte=
==[http://www.canathome.de/ canathome]==
==[http://caraca.sourceforge.net/ caraca]==