Welcher Bus für Lichtsteuerung

Flex schrieb:
> Welches Bussystem ist dafür am besten? CAN oder RS485.

Kommt auf die maximale Anzahl der Teilnehmer, maximal benötigte 
Datenmenge, ... an. Meine Glaskugel tendiert zu CAN, da da das Protokoll 
"schon dabei ist".

> Kann ich z.B. für den Master einen ARM und für die Slaves AVR verwenden?

Wieso nicht?

Der ATmega8 unterstützt doch kein CAN. Gibt es da spezielle Bausteine, 
die ich dann über I2C oder SPI anschließen kann. Also ich möchte 
ca.10-15 Teilnehmer (Slaves) verwenden.


mfg

Jepp. Ich verweise einfach mal auf den Artikel 
http://www.mikrocontroller.net/articles/CAN

Am Beliebtesten sind MCP2515 und (betagter) SJA1000.

Wie gesagt, ist Deine Entscheidung, ob Du - wenn Du einen µC ohne 
integrierten CAN-Controller nehmen willst - lieber einen externen 
CAN-Controller einsetzt oder den Protokollstack in Software machst - 
dann kann es aber unter diesem Gesichtspunkt auch RS485 sein.

Also ich hatte geplant mit dem mbed von http://mbed.org/ den Maser zu 
machen, der hat ja schon CAN Hardwareseitig und ATmega8 als Slave.
Kann ich dann an jeden Slave einen 4DIP Schalter zur Codierung machen?

>Kann ich dann an jeden Slave einen 4DIP Schalter zur Codierung machen?

Also wenn Dich diese Frage schon überfordert, das wird der Rest auch 
nix.
Oder willst Du jetzt wegen jedem Widerstand fragen ob er passt?

Sieh Dir mal das an: 
http://www.kreatives-chaos.com/artikel/can-testboard

Diese Seite habe ich auch schon gefudnen.
Kann ich den MCP2551 auch direkt an RX und TX des ATmega hängen ohne den 
MCP2515 der am SPI hängt?

klar.

Aber vergiss die zwei 10Watt-Widerstände nicht, die Du dann dafür 
einsetzen musst.

Ich hab zwar nich nach den 10Watt!!! Widerständen gefragt, aber auch 
egal...

Wieso kommen die notwendigen Informationen eigentlich immer 
tröpfchenweise?

Im Eröffnungsposting hatte es noch den Anschein, dass der TO "nur" nicht 
weiß, welches Bussystem und welche Mikrocontroller er will.
Auf Nachfrage erfahren wir dann zumindest die Anzahl der geplanten 
Knoten. Weitere Informationen, wie z. B. die maximale Buslänge und die 
geplante Struktur, wissen wir immer noch nicht (hat keiner gefragt, 
steht aber in jedem Artikel zum Thema "Bus" recht weit oben), können 
aber implizit annehmen, dass sich zumindest die Länge in Grenzen hält 
(TO spricht von einem einzigen Zimmer).
Jetzt kommt so nach und nach heraus, dass er sich schon spezielle 
Mikrocontroller ausgeguckt hat, von denen der als Slave Gedachte das 
eine Busprotokoll, nach dem er speziell fragte, nicht von Haus aus 
unterstützt, und dass er für den Master auch schon ein spezielles Board 
im Auge hat.

Warum ist es den Leuten eigentlich nicht möglich, solche Informationen 
zusammengefasst im ersten Posting zu präsentieren? Nur so als Hinweis: 
Mit dieser Art der Informationsherausgabe nur auf Nachfrage vergrault 
man selbst noch die hilfsbereitesten Forensiker.

On topic: Der MCP2515 handled das CAN-Protokoll, während der MCP2551 ein 
Bustreiber ist, welcher die TTL-Pegel in etwas "Buskonformes" umwandelt.
Der MCP2515 kann natürlich entfallen, wenn das CAN-Protokoll in Software 
nachgebaut wird (das ist ja gerade der Witz an diesem Baustein, dass der 
das macht).
Auch für z. B. RS485 wird ein Bustreiber gebraucht (z. B. der 
antiquierte SN75176 oder z. B. ein MAX485); unabhängig vom eingesetzten 
Mikrocontroller (kenne zumindest keinen µC, der Bustreiber integriert).
µC's wie z. B. AT90CAN128 integrieren auch lediglich den CAN-Controller, 
nicht jedoch den Bustreiber.

Danke Jörg S.,
aber ich habe gelesen, dass man bei I2C keine langen Kabel verwenden 
sollte. Zuwerst möchte ich nur an/aus schalten, aber später auch 
Temperaturdaten und RFID Daten übertragen. Ich denke, wenn ich von 
Anfang an mich auf ein System spezielisiere, habe ich es später 
leichter.

mfg

Danke Patrik.
Jetzt habe ich das mit den zwei Bausteinen verstanden.

Jetzt noch einmal mein geplantes Vorhaben:

1 Master (ATmega32,128 oder Mbed)
5-15 Slave (Atmega8)
10-30m Kabellänge (vorerst)

Zu übertragende Daten:
-Lampe an/aus
-Temperaturdaten
-RFID Daten
-Sensordaten (bedämpft, nicht bedämpft)

Das sollte es vorerst sein.

mfg

Patrick schrieb:
> Mit dieser Art der Informationsherausgabe nur auf Nachfrage vergrault
> man selbst noch die hilfsbereitesten Forensiker.

Weil es in den Medien so vorgelebt wird.
Da allerdings ist die Zielrichtung, dass so wenig wie moeglich 
herauskommt, also genau das Gegenteil.

citb

Warum nicht DMX512 als etablierten Lichtbus verwenden. Vorteil wäre die 
Verwendbarkeit von standardisierten Komponenten aus der Bucht.

zum selberlöten und AVR --> 
http://www.hoelscher-hi.de/hendrik/light/profile.htm

An DMX habe ich auch schon gedacht, da es auch viele Effektstrahler mit 
DMX gibt. Aber dann kann ich keine Sensordaten übertragen, oder geht das 
doch?

machbar ist sicher vieles, aber der DMX-Bus wäre mir zu schade dafür. 
Ich habe mir die DMX-Komponenten nachgebaut und bin voll zufrieden.
Für Sensordaten (was ja schon fast in Richtung Hausbus geht) würde ich 
was getrenntes machen.
DMX habe ich seinerzeit genommen, weil das Zeug auf der Webseite alles 
schon fertig zum Nachbau war und bei ebay die PAR-Scheinwerfer mit 
RGB-LED inkl. DMX-Adapter so schön billig waren. (Und die gehen heute 
noch, hätte ich bei dem Preis nicht erwartet)

Uwe

Ich würde mir einen uC mit integriertem CAN-Controller suchen. Dann 
brauchst Du nur noch einen externen Treiber alla MCP2551 o.ä.

Spontan fallen mir da Microchip, ST, NXP oder TI ein.

Meist gibt es dann für die integrierte Perepherie bereits fertige 
Softwaremodule zur Initialisierung, Senden, Empfangen von Nachrichten.

Damit sollte es relativ einfach gehen.

Von ATMEL gibt es da meines erachtens relativ wenig.
Ich hatte mal für meine Abschlussarbeit den AT90CAN128.
Ist aber schweine teuer im Vergleich zu den oben genannten, bei deutlich 
weniger Performance/Perepherie.

Anonsten gibt es bei Kreatives Chaos für den MCP2515 bzw. den AT90CAN 
eine schöne Bib.

Grüße

@Patrick:

doch es gibt inzwischen von NXP (BASIS ARM Cortex M0) die LPC11C14 u. 
LPC11C24 die bereits einen CAN-Bustreiber integriert haben. Feine Teile, 
leider etwas wenig Flash. Aber CAN ist schon drin...

Canni

ganz klar: DALI!

ist mit den at90pwm von atmel leicht implementiert.

und mit DALI kann man natürlich temperatur und RFID daten übertragen ?? 
;-)