Hallo zusammen, ich möchte mir eine modulare Gefahrenmeldeanlage bauen. Prinzipieller Aufbau: Eine große Prozessoreinheit mit einem ATmega 644 oder ähnlichem. Dieser stellt eine Anbindung ans Ethernet dar. Weiter sollen Rauchmelder, Einbruchsensoren, Glasbruchmelder usw. über weitere Module angeschlossen werden können. Hierzu habe ich einen kleinen ATmega Vorgesehen.Größenordnung ATmega 8 und bei sehr kleinen Modulen nur ein Attiny. Jetzt soll die ganze Geschichte in ein kleines Rack mit Rückwandbus. Stecker sind im Rack bereits verbaut. Meine Idee war es nun, die Module mit der Prozessoreinheit über I2C zu verbinden. Natürlich dann als Rückwandbus. Nun habe ich gesehen dass, der übliche I2C Bus bei µC 100kbit/s hat. Ist das ausreichend um 6-8 Module mit dem Hauptprozessor zu verbinden. Wie ist eure Meinung dazu? Gruß Tobias
Du wirst kaum ganze Romane übertragen sondern kodierte Informationen. Daher ist die Geschwindigkeit des Busses eher sekundär. Allerdings ist I2C eher für die Kommunikation für die Bauelemente auf einer Platine (=in einem Modul) gedacht, weniger für die Kommunikation mit externen Komponenten oder Baugruppen. Dafür verwendet man eher robustere Busse, wie CAN oder RS485.
danke für die schnelle Antwort. Was wäre da leichter zu implementieren? CAN oder RS485? CAN ist doch eher schon für längere Stecken oder?
Bei den von dir genannten Controllern ist RS485 wohl leichter umzusetzen als CAN. Sowohl Hard- als auch Softwareseitig. Ich will dich auch nicht von I2C abhalten, aber du kannst halt unter Umständen Probleme bekommen.
Genau deswegen habe ich ja gefragt, ob es sinnvoll ist, I2C zu nutzen für meine Zwecke.
Tobias Schu schrieb: > Genau deswegen habe ich ja gefragt, ob es sinnvoll ist, I2C zu nutzen > für meine Zwecke. Für 2 Handvoll Sensoren, deren reihum abfragen nicht zeitkritisch ist? Da kannst du so ziemlich alles nehmen, hauptsache du kannst es programmieren.
Hallo! Bei Deinem Problem würde ich persönlich mir erst mal Gedanken um die zuverlässige Übertragung machen. Gefahrenmeldung, Brandmeldung, Einbruch - alles sicherheitskritische Sachen. Sowohl Fehlalarme als auch Versagen der Alarmierung sollte NIE vorkommen. Mein Tipp wären midestens zwei unterschiedliche Busse. Auch die Controller würde ich nicht auf einsamer Flur arbeiten lassen. Zweikanalig ist das Zauberwort. Diversitär wäre zu überlegen. Hängt davon ab, ob Menschenleben in Gefahr sind. Rauchmelder könnten ja auch nur für den Holzschuppen sein. I²C halte ich nicht für besonders zuverlässig, insbesondere wenn man den selbst programmiert.
Sicherheit kommt ja auch ein klein wenig auf die Implementierung an. Mit I2C und nur "ein paar bits pro Sekunde" kommt man schon ziemlich weit, jedenfalls viel weiter als ein Rückwandbus reicht. Normale I2C - Slaves haben kein Problem damit, wenn die Busgeschwindigkeit gedrosselt wird. Ist dein Master so programmiert, daß sich alle Slaves melden müssen, sehe ich da auch keinen Unsicherheitsfaktor. Als zweite Sicherheit ist dann noch eine gemeinsame Alarmleitung denkbar. Die könnte dann von jedem Slave ausgelöst werden, auch in Fällen wo z.B. der Master tot ist oder mit einem Slave nit redet. Anders sieht das für verteilte Sensoren im Feld aus. Da ist die Störempfindlichkeit das ausschlaggebende Kriterium und ein Feldbus wie RS485-basierte haben eindeutige Vorteile.
Tobias Schu schrieb: > danke für die schnelle Antwort. > > Was wäre da leichter zu implementieren? CAN oder RS485? > CAN ist doch eher schon für längere Stecken oder? nicht unbedingt. Der Vorteil von CAN ist, dass die Controller viel mehr selber in Hardware machen, was Du bei 485 selber programmieren musst. Dafür bist Du aber an die Paketstruktur des CAN (zB max 8 Datenbytes pro Paket) gebunden, weil das eben in Hardware gegossen ist. Für CAN ist AVR eine unglückliche Wahl, weil nur wenige AVRs einen CAN-Controller eingebaut haben, und das sind dann große Bausteine mit 64 Pins. Viele Bastler verwenden den per SPI extern angebundenen Controller MCP2515 von Microchip zB in Verbindung mit einem Mega8. Ein Microchip PIC18F26K80 auf der anderen Seite hat CAN bereits eingebaut, und der eingebaute CAN-Controller ist eine stark verbesserte Version des MCP2515 mit mehr Pufferspeicher, und der PIC kann direkt auf die CAN-Register zugreifen, ohne SPI dazwischen. Zudem kostet der PIC deutlich weniger als der AVR plus MCP2515, und einen Quarz spart man auch noch. Schön blöd, wer da mit AVR rumhühnert! Was die Auswahl an Peripherie und die Qualität der Peripherie angeht, ist PIC eindeutig besser. Es gibt zB auch PICs mit eingebautem Ethernet. Da musst Du nur noch Deine RJ45 Buchse mit eingebautem Übertrager anklemmen, ein paar Widerstände und Kondensatoren, und der Rest ist auf dem Chip drauf. Wenn Du I2C nehmen möchtest, gibt es von NXP oder TI Busswitches dafür, zB den PCA9547. Damit kannst Du dann den Bus vom Prozessor auf eine von 8 Karten schalten und diese ansprechen. Die einzelnen Karten dürfen mit unterschiedlichen Versorgungsspannungen arbeiten - der PCA9547 ist gleichzeitig Level Shifter. Plus: Du kannst auf jeder Karte die gleichen I2C Adressen verwenden. Damit kannst Du jede Karte einfach so in einen beliebigen Slot stecken, und der Zentralprozessor weiß anhand eines EEPROMs auf der Karte, was für eine Karte mit welchen Peripheriebausteinen in dem jeweiligen Slot steckt. Wenn Du mehr als 8 Slots brauchst, nimmst Du halt zwei von den PCA9547. Der PCA9547 dient außerdem dazu, die einzelnen Segmente voneinander zu entkoppeln, um die ganze Geschichte zuverlässiger und fehlertoleranter zu machen. Eine defekte Karte stoppt so nicht die ganze Maschine. Und wenn mal der Bus hängt (was bei I2C immer mal wieder vorkommt), kannst Du ihn über den Reset-Pin des I2C Multiplexers immer wieder zurücksetzen. Ich würde auf die Karten keine Mikrocontroller setzen, sondern einfache I2C Peripheriechips in der Richtung MCP23008 oder PCA9554, wenn es geht. Das vereinfacht die Entwicklung, weil Du nur einen Controller programmieren musst. fchk
Frank K. schrieb: > Für CAN ist AVR eine unglückliche Wahl, weil nur wenige AVRs einen > CAN-Controller eingebaut haben, und das sind dann große Bausteine mit 64 > Pins. Es gibt auch sowas wie den Mega16M1, M32C1 und so, der hat nur 32 Pins. Und immer diese PIC Vergleiche, als ob ein 16F84 das gleiche wäre wie ein dsPIC32. Welcher von den PIC32 hat denn einen Ethernet-Phy eingebaut? Die AT32UC3C haben auch 2 CANs, Ethernet und USB, die gibt es mit 64/100/144 Pins in 0,5mm Pitch - also mit 64 Pins so gross wie ein Mega644. Nur, ein AVR32 ist eben kein AVR...
Rudolph schrieb: > Frank K. schrieb: >> Für CAN ist AVR eine unglückliche Wahl, weil nur wenige AVRs einen >> CAN-Controller eingebaut haben, und das sind dann große Bausteine mit 64 >> Pins. > > Es gibt auch sowas wie den Mega16M1, M32C1 und so, der hat nur 32 Pins. Wenn nicht einmal RS und Farnell den listen, dann denke ich mir meinen Teil. > Und immer diese PIC Vergleiche, als ob ein 16F84 das gleiche wäre wie > ein dsPIC32. Einen dsPIC32 gibts nicht. Du meinst dsPIC33. Außerdem vergleiche ich nicht Äpfel mit Birnen, sondern 8-Bitter mit 8-Bittern. > Welcher von den PIC32 hat denn einen Ethernet-Phy eingebaut? von denen keiner. Auch hier habe ich 8 Bitter mit 8 Bittern verglichen. Ich hatte die PIC18F97J60 Familie im Sinn. Die hat quasi den ENC28J60 gleich mit eingebaut, natürlich abzüglich des bremsenden SPI dazwischen. Und abzüglich des extra Quarzes für den ENC, der auch noch Platz braucht und Kosten verursacht. Es gibt keine billigere Möglichkeit, einen Ethernet-Knoten zu realisieren. > Die AT32UC3C haben auch 2 CANs, Ethernet und USB, die gibt es mit > 64/100/144 Pins in 0,5mm Pitch - also mit 64 Pins so gross wie ein > Mega644. Bestreite ich auch nicht. Nur hat der Mega 644 nur 40/44 Pins. > Nur, ein AVR32 ist eben kein AVR... Auch das bestreite ich nicht. Nur, AVR ist nicht das Maß aller Dinge. Manchen Bastlern muss man ab und an zeigen, was es noch so alles in der Welt gibt. fchk
Hallo zusammen, ich danke erst einmal allen für die Antwort. Auch wenn ich keinen Streitschlichter spielen möchte, aber sollte es hier nicht viel mehr um das gemeinsame Interesse an Elektronik gehen, als um die Diskussion ob AVR oder PIC? Ich habe mich mit den Atmels momentan angefreundet. Das wird auch erst einmal so bleiben. Trotzdem danke für den Einblick in die PICs ;) So nun aber wieder zum Thema: Also zur Sicherheit. Da ich in vielen Bereichen analoge Melder nutze mit einfacher Live-Zero Technik, brauche ich mir über Redundanz im privaten Bereich glaube ich keinerlei Sorgen machen. Natürlich sollte das System ohne Fehlalarme laufen, aber es ist eben ein Bastelprojekt. Vom Prinzip finde ich CAN halt toll, da es sehr einfach ist zu implementieren. CAN ist meines Wissens sehr zuverlässig. RS485 ist da glaub ich schon weit aus aufwendiger oder? Mein Problem mit dem MCP CAN-IC ist nur, dass ich noch keinerlei Erfahrung habe mit mehreren Slaves am SPI Bus. Der Master hat bereits einen ENC28J60 am SPI. Wäre es ohne große Probleme möglich, beide IC's mit dem Mega644 anzusteuern? Gruß Tobias
:
Bearbeitet durch User
Tobias Schu schrieb: > Wäre es ohne große Probleme möglich, beide IC's > mit dem Mega644 anzusteuern? Flowchart für mehrere Slaves bei SPI: Haben alle ICs ein /CS oder/OE? -> Ja: Funktioniert.
Tobias Schu schrieb: > Ich habe mich mit den Atmels momentan angefreundet. Das wird auch erst > einmal so bleiben. Trotzdem danke für den Einblick in die PICs ;) Einen Glaubenskrieg ist hier ohnehin fehl am Platz, denn Glauben gehört in die Kirche - hier gehts um nachprüfbare Fakten. In diesem Fall ist aber wohl nicht die Technik das Problem, sondern Dein begrenztes Wissen. > Vom Prinzip finde ich CAN halt toll, da es sehr einfach ist zu > implementieren. CAN ist meines Wissens sehr zuverlässig. RS485 ist da > glaub ich schon weit aus aufwendiger oder? Eigentlich nicht. Die Echtzeitfähigkeit wirst Du wohl nicht brauchen, andere Dinge wie CRCs kannst Du problemlos nachimplementieren. > Mein Problem mit dem MCP CAN-IC ist nur, dass ich noch keinerlei > Erfahrung habe mit mehreren Slaves am SPI Bus. Der Master hat bereits > einen ENC28J60 am SPI. Wäre es ohne große Probleme möglich, beide IC's > mit dem Mega644 anzusteuern? Ja, es ist möglich. Allerdings ist der SPI bei Dir ohnehin ein Flaschenhals. Den ENC28J60 kann man ja auch an einen PIC18F67J60 mit internem Ethernet anschließen und vergleichen. Mit dem internen Ethernet ist die Ethernet-Geschwindigkeit fast doppelt so hoch wie mit dem extern per SPI (10 MHz SPI Clock) angebundenen Chip. Da Prozessor, Software und die ganze Systemumgebung jeweils identisch sind und der Ethernetteil des PIC18F67J60 recht ähnlich zum ENC28J60 ist, bleibt nur noch die Anbindung als Verursacher für den Faktor 2 in der Geschwindigkeit übrig. Da Du ja ein armer AVR-User bist, dem der Zugriff auf Prozessoren mit internem Ethernet verwehrt bleibt, will ich Dir den Flaschenhals nicht noch enger machen, als er ohnehin schon ist. Daher habe ich einen anderen Vorschlag: Wenn Du keinen Mega644, sondern einen 644*P* nimmst, hast Du einen zusätzlichen seriellen Port. Zum einen könntest Du den im SPI-Modus betreiben, zum anderen kannst Du auch schlicht einen CAN-Transceiver an den UART anschließen. Das, was dort dann rauskommt, ist natürlich kein CAN mehr, aber das ist für Deine Zwecke egal. Es ist eine serielle Busverbindung zwischen den einzelnen Knoten. Natürlich muss der Bus an beiden Enden terminiert werden, und ebenso natürlich sind keine(!) Stichleitungen erlaubt, aber das ist bei 485 auch nicht anders. Es entfällt die bei 485-Transceivern erforderliche Umschaltung der Senderichtung. Alles, was Du sendest, empfängst Du auch wieder, und damit kannst Du feststellen, ob Dein Paket korrekt gesendet worden ist, oder ob jemand anderes versucht hat, gleichzeitig zu senden. Die CAN-Hardware macht das selber, Du musst das in Software implementieren, aber das ist eine leicht lösbare Aufgabe, genau wie das Erzeugen und Prüfen einer CRC. Dieser Vorschlag reduziert den Hardwareaufwand sowohl beim Hauptprozessor als auch bei den Slaves. fchk
CAN über SPI angebunden ist grausam. Da kannst Du auch gleich RS485 nehmen, dann hast Du wahrscheinlich sogar noch weniger Protokoll zu implementieren. Wobei, okay, Ethernet über SPI ist dann noch schlimmer. :-) Dann überlege lieber ob Du statt dem Mega644 nicht einen 90CAN32/90CAN64/90CAN128 benutzen kannst. Oder halt wirklich mal einen AVR32 UC3C, ist zwar was ganz anderes, aber wenigstens bleibt die Entwicklungs-Umgebung komplett gleich. :-) Die Mega16M1 gibt es im Moment bei DigiKey, hab vorhin erst welche auf der Arbeit für ein zukünftiges Projekt bestellt bei dem wir Euro-Karten in einem 19" Einschub benutzen möchten... Ende Juni hat Mouser die auch wieder. Und ich hoffe der Farnell Vertreter der mir schmackhaft machen wollten was für ein guter Atmel-Distri die sind hat meinen Hinweis auf den fehlenden Mega16M1 mal weitergeleitet...
Helge A. schrieb: > Ist dein Master so programmiert, daß sich alle Slaves melden müssen, > sehe ich da auch keinen Unsicherheitsfaktor. Das ist im I2C Standard sowieso schon drin. Wenn während der Addressierung der Slave nicht mit dem ACK bit antwortet, gilt das als Kommunikationsfehler. Wenn I2C sauber über mit GND getrennte Leitungen geführt wird mit kräftigen Pullups, sollten 1-2m drin sein, vorausgesetzt, man fährt den Bus langsam. 400kHz wird also knapp, scheint hier aber auch nicht nötig zu sein.
:
Bearbeitet durch User
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.