Hallo, ich möchte in meinem Zimmer verschiedene LED Lampen mit einem µC (Master) ansteuern. An jeder Lampe möchte ich einen Slave (z.B. ATmega8) habe, an dem Relais etc. hängen. Welches Bussystem ist dafür am besten? CAN oder RS485. Kann ich z.B. für den Master einen ARM und für die Slaves AVR verwenden? Gruß
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?
Wenn die Slaves (Lampen) nix spezielles machen sollen, ginge auch I²C Bus. Für An/Aus reicht dann zB. ein PCA8574 bzw. PCA8574A. Dann musst du auf der Slave Seite nix programmieren.
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
Flex schrieb: > Danke Jörg S., > aber ich habe gelesen, dass man bei I2C keine langen Kabel verwenden > sollte. I²C geht auch über längeres Kabel. Aber je Länger desto höher der Aufwand. Siehe: http://www.mikrocontroller.net/articles/I2C_als_Hausbus > 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. Die Daten bekommst du über I²C natürlich auch übertragen. Von daher könnte man z.B. mit einem einfachen PCF8574 starten und dann später auf µC Slave umsteigen.
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 ?? ;-)
Warum baust Du Dir nicht was Eigenes? Ich habe für verschiedene Projekte was LIN-ähnliches gebaut mit den MCP2101 bzw dem älteren MCP201. Den schliesst Du einfach an den USART an und er enthält eine Stromversorgung. Wilde Geschwindigkeiten wirst Du nicht brauchen, oder? Geruhsame 19,2 k sind in vielen Fällen ausreichend. Und nur ein bzw zwei Kabel mit 12V Pegeln. Ein Protokoll überlegt und auf gehts. z.B. so: Startbyte - Adressbyte - Längenbyte - Daten - ... - Prüfsummenbyte Und es hat den Vorteil, dass man nicht mit speziellen Eigenarten von Protokollen zu kämpfen hat, die man eigentlich nicht braucht... Gruss aus Berlin Elux
Natürlich kannst du dir einen eigenen Bus und ein Protokoll definieren, sinnvoller ist es meines erachtesn aber auf einen bestehenden Bus aufzusetzen und sich diesen dann an den einen oder anderen Ecken an seinen Anforderungen anzupassen statt was komplett eigenes zu machen, das hat dann auch den Vorteil das manche fertige Tolls verwendet werden könnten. Variante 1: (DMX/RDM) Du verwendest den DMX 512 , bzw desen Erweiterung RDM, hier hast du die Möglichkeit durch abändern des Präambel Bytes auch weitere Informnationen und selbst eigendefinierte Kommandos unterzubekommen. Für die Helligkeist und Winkelwerte lässt du die Präambel (oder auch Startbyte) auf 0 stehen dann hast du DMX512 und über ändern der Präambel stehen dir weitere 254 Kommandos zur Verfügung die du aus der RDM Spezikation oder auch selber definieren kannst wenn du nicht kompatibel zu anderen Geräten sein musst. Vorteil ist das du zig PC Tools zum Testen und Ansteuern verwenden kannst. Da der DMX BUs physikalisch ja auf dem RS485 Bus aufbaut ist er , wenn man die entsprechenden Treiber verwendet , ich empfehle die ESD und spannungsfesten Typen (FAULT Protection) wie z.B. MAX13443 oder 13448, dann kann selbst 24 V auf den BUs Leitungen die Treiber nicht zerschiessen. ÜBertragungsrate ist ziemlich hoch bei 250 kBaud, d.h. du kannst deine Lichtspiele sehr dynamisch ablaufen lassen und hats 512 Adressen zur Verfügung. Die DMX Leitungen sollten aber geschirmt und verdrillt verlaufen und sind vom Netz strikt getrennt zu halten. Variante 2: DALI DALI Beschaltung ist deutlich aufwendiger als DMX und auch in der Software muss deutlich mehr gemacht werden. Die Übertrgungsrate ist mit 1200 Baud sehr gering, du kannst auch nur 16 Gruppen offiziell adressieren. Allerdings ist das DALI Protokoll durch die langsame Geschwindigkeit sehr robust und kann auf ner STandard NYM Leitung parrralel mit dem Netz verlegt werden. Du musst DALi dann aber auch sicherheitstechnisch wie Netzspannung behandeln, obwohl die Pegel ja nur 16-20 V haben. Ich selbst habe sowohl DMX / RDM als auch DALI Schaltungen schom mit den AVRS ( wie Mega 640/ 88/32, sowohl Master als auch Slave seitig in Industriedesigns eingesetzt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.