Hallo zusammen, ich habe für die Erweiterung meiner Hausautomatisierung einen Kommunikationsbus entwickelt, der mit nur einer Datenleitung, beliebigen auch ungeschirmten Leitungen und Topologien funktioniert. Als Vorbild diente mir der CAN-Bus, von dem ich die für mich wichtigsten Ideen und Features übernommen habe: - Prioritätssteuerung der Nachrichten nach ID - Multi-Master-System: alle können gleichzeitig senden - Fehlerkontrolle per Parity Bits Die Datenleitung wird über einen Pullup gegen Hi gezogen. Dies ist der rezessive Zustand. Jeder Busteilnehmer verfügt über einen Transitor, der den Bus gegen Low ziehen kann (dominant). Die Information selbst wird anders als bei CAN über die Länge des Pulses dargestellt. Eine logische "1" ist ein kurzer Puls, eine logische "0" ein langer. Die maximale Datenrate ergibt sich durch die Länge der Pulse (default 4ms und 8ms) und die Pausenzeit dazwischen (default 2ms). Siehe angehängte PDF-Datei. Es wird für einen Arduino insgesamt also eine 3-adrige Leitung benötigt (5V, Gnd, Signal). Im System ist nur ein Pullup vonnöten, mehr gehen natürlich auch. Optional kann man LEDs mit dranhängen, notwendig ist pro Teilnehmer allerdings nur ein einziger Transistor (für Open-Collector). Die Nachrichten haben eine Länge von 30 Bit und folgendes Format: Message Structure ID Value Parity 10 16 4 Bits = 30 Bits 3FF FFFF Maximalwert Damit können nur etwas 5 Nachrichten pro Sekunde verschickt werden. Das reicht mir für meine Anwendung vollkommen aus, da ich Signale wie Wasserstände und Bodenfeuchtigkeiten übertrage. Bei Bedarf können die Zeiten natürlich verkürzt werden. In meinem System habe ich in Sterntopolgie 3 Strom-Erdkabel zweckentfremdet (je ca. 20m) und mehrere Telefonleitungen. Mit dem 10k Pullup könnte ich noch etwa 2-3 mal schneller. Wer's noch schneller braucht kann den Pullup reduzieren und geschirmte Leitungen verwenden. Damit sollte die 10-100 fache Geschwindigkeit drin sein. Die Nachrichten werden mit 4 Parity Bits gegen Bitkipper gesichert. In der angehängten Zip-Datei finden sich 3 Arduino-Dateien: - MyCAN - ID_EEPROM - Test_MyCAN_V1 MyCAN ist die Bibliothek für den modifizierten CAN-Bus. Stehen etliche Kommentare drin. Die wichtigsten Funktionen sind: MC_setup() Initialisierung der Pins und Interrupts (für Empfang) MC_sendMessage() Nachricht senden MC_getMessageFromRXqueue() Nachricht aus der Queue holen MC_printStats() Statistik zu Sendung und Empfang über RS232 ausgeben Für jede Nachricht wird eine unsigned long variable verwendet. Der Empfang läuft per Interrupt im Hintergrund. Die selbst gesendet Nachrichten werden quasi ebenfalls empfangen. Zum Abholen der Nachrichten ruft man MC_getMessageFromRXqueue auf. Alle noch nicht abgeholten Nachrichten stehen in einem Array mit Platz für 32 Nachrichten. Der Ganze Rest wie kodieren, dekodieren, Parity berechnen und prüfen läuft alles im Hintergrund. Um eine eindeutige ID für jeden Teilnehmer zu generieren und speichern habe ich noch die Bibliothek ID_EEPROM angehängt. Diese generiert durch Auslesen von 8 Analogpins eine "zufällige" Zahl, berechnet daraus eine ID zwischen 0 und 63 und speichert sie zusammen mit einem Code im EEPROM. Beim ersten Aufruf von ID_getID() geschieht dies. Bei jedem weiteren Aufruf von ID_getID() wird die gespeicherte ID ausgegeben, auch bei Verlust der Versorgungsspannung. Damit kann man ganz prima Sensoren mit IDs versehen. Zuletzt ist als Beispiel die Arduino Datei Test_MyCAN_V1 angehängt. Diese initialisiert die Kommunikation und verschickt Nachrichten mit einer kleinen Rechenübung. Nach Empfang wird die Rechnung nachvollzogen und geprüft. So läßt sich testen ob Parity gereicht hat. Mit dem Programm kann man mit 3-4 Teilnehmern eine Art Stresstest aufbauen. Ein exemplarisches Ergebnis hänge ich noch mit an. Ich hoffe, der eine oder andere kann das Ganze gebrauchen und stehe gerne für Fragen zur Verfügung! Viele Grüße, André.
Angehängte Dateien:
:
Bearbeitet durch User
Hallo zusammen, keine Fragen und Kommentare? Hatte mir ein wenig mehr Resonanz erhofft ;-)
Warum keine Standard CAN Transceiver verwenden? Differentielle, störunanfällige Übertragung + Absicherung gegen Überspannung und Transienten... Interessanter "proof of concept" aber IMHO in der Praxis so nicht einsetzbar
Andre B. schrieb: > - Prioritätssteuerung der Nachrichten nach ID > - Multi-Master-System: alle können gleichzeitig senden > - Fehlerkontrolle per Parity Bits Dazu fällt mir als Frage ein wie das ohne dedizierte Unit funktionieren können soll ohne den Controller zu 100% auszulasten. Aber sonst ja, gibt doch schon CAN.
Andre B. schrieb: > Hallo zusammen, > > keine Fragen und Kommentare? Hatte mir ein wenig mehr Resonanz erhofft > ;-) Was soll man dazu sagen? Wenn es für Dich funktioniert, fein und es ist Anerkennenswert, daß Du eine neue Lösung für ein schon seit sehr langem gelöstes Problem erdacht hast. Jeder Huster im Haus oder ums Haus wird Deine Kommunikation durcheinander bringen, das ganze ist massiv von den Kabelkapazitäten (Leitungslänge) abhängig, wenn der Pullup als Gegenmaßnahme zu niederohmig wird dann klingelt es an allen Ecken und Enden mehr als den angeschlossenen Halbleitern lieb ist, der Aufwand das in den Griff zu bekommen ist auch nicht gerade gering, Störfestigkeit läßt sich Konzeptbedingt nur durch geringere Baudrate erreichen... OpenCollectordinge sind vor gefühlten 70 Jahren erfunden worden und es hat einen Grund, warum für lange Leitungen (und Hausbusse haben solche) normalerweise differentielle Signale oder "hf" verwendet wird Bei mir reichen 3pol Kabel auch für die CAN-Verbindung, die in vielen Bereichen (SW, HW, Konzept) robuster ist. MiWi
Ich schließe mich den Kritiken an. Seit ich CAN verwende will ich nichts anderes mehr haben. Vor allem auch weil man sich um das Hardwareprotokoll nicht kümmern muss. Die erste Hardwarekrücke hast du ja schon in MyCan eingebaut. Wenn der linke Controller im Reset ist wird der Bus Low und nichts geht mehr. Sowas will keiner haben. Und wenn jetzt noch ein paar Bauteile mehr dazu kommen ist auch der Platz für den Treiber größer als ein CAN-Transceiver. Was soll das also für einen Nutzen bringen? Bei einem Hausbus sollte man auch nicht glauben die Baudrate spielt keine Rolle. Klar für einen Temperatursensor allein nicht, aber wenn da noch etwas Photovoltaik, Heizung, Wärmepumpe u.s.w. dazukommen sind das schnell mal ein paar 100 Byte pro Sekunde. Am Ende wird es dann doch wieder auf verdrillte Leitungen hinauslaufen und die haben im minimum 2 Paare von denen man 2 für die Versorgung von kleinen Knoten nehmen kann. EIB-Kabel sind da nicht die schlechteste Lösung. Wenn deine Lösung bei einer bestimmten Baudrate in beliebiger Topologie und mit beliebigen Leitungen funktioniert funktioniert sie mit einem ordenlichen CAN-Transceiver erst recht. Ich benutze 100k weil meine LPC11C24 das als Bootloaderbaudrate haben. Um die Topologie habe ich mir keine Gedanken gemacht und auch 1984 verlegte unverdrillte Telefonleitungen mit verwendet. Bisher ohne irgendwelche Probleme.
Warum nicht LIN mit eigenem Protokoll?
Andre B. schrieb: > Es wird für einen Arduino insgesamt also eine 3-adrige Leitung benötigt > (5V, Gnd, Signal). Warum keinen 1-Draht-CAN? Transceiver für 1-Draht-CAN http://www.nxp.com/docs/en/data-sheet/MC33897.pdf Dann hat man Arbitrierung, Kollisionsvermeidung und Fehlerüberwachung gleich in Hardware im Controller.
:
Bearbeitet durch User
temp schrieb: > Seit ich CAN verwende will ich nichts > anderes mehr haben. Vor allem auch weil man sich um das > Hardwareprotokoll nicht kümmern muss. Ich kann mich da nur anschließen. CAN ist sowas von problemlos, einfach und zuverlässig. Der einzige Nachteil von CAN ist, daß Atmel nur wenige MCs mit CAN im Programm hatte (AT89C51CC03, AT90CAN128). Und die ATmega64C1 waren lange Zeit schwer zu beschaffen.
Peter D. schrieb: > Der einzige Nachteil von CAN ist, daß Atmel nur wenige MCs mit CAN im > Programm hatte (AT89C51CC03, AT90CAN128). Und die ATmega64C1 waren lange > Zeit schwer zu beschaffen. Dafür haben Renesas und Freescale umso mehr.
Andre B. schrieb: > Um eine eindeutige ID für jeden Teilnehmer zu generieren und speichern > habe ich noch die Bibliothek ID_EEPROM angehängt. Diese generiert durch > Auslesen von 8 Analogpins eine "zufällige" Zahl, berechnet daraus eine > ID zwischen 0 und 63 und speichert sie zusammen mit einem Code im > EEPROM Wie vorhersagbar ist das denn? Und wie groß ist die Chance, dass von 10 Geräten 2 die gleiche ID haben? Da wäre mir die Adressierung wie bei I2C lieber (ein paar Bits für den Typen und ein paar Bits per Dipschalter)
Andre B. schrieb: > keine Fragen und Kommentare? Hatte mir ein wenig mehr Resonanz erhofft Man kann ein CAN-Protokoll auch ohne CAN-Transceiver als Eindrahtbus fahren. Allerdings vergibt man damit die Störsicherheit, die der differenzielle Bus bringt. Und man vergibt sich die Möglichkeit, einen simplen CAN-Sniffer anzuschließen und mal am Bus mitzuhören. Achim.S schrieb: > Und wie groß ist die Chance, dass von 10 Geräten 2 die gleiche ID haben? Mit etwa 52%. Das gilt als "fast sicher"... ;-) Siehe https://de.wikipedia.org/wiki/Geburtstagsparadoxon
:
Bearbeitet durch Moderator
Oha, viel Kritik, kann ich aber mit umgehen ;-) Ein paar Kommentare: - CAN scheidet für mich komplett aus, weil ich unter anderem völlig ungeschirmte und unverdrillte Strom-Erdkabel zur Kommunikation mißbrauche. - Statt CAN-Controller brauche ich einen Transistor pro Slave - weniger geht nicht - Hier bringt kein Huster nix aus dem Tritt ;-) - Die zufällig generierten IDs sind nur Hilfsmittel ums einfacher zu machen. Wer zu viele Teilnehmer hat kann die auch manuell vergeben - Reset eines Teilnehmers unterbricht die Kommunikation tatsächlich für ein paar ms. In meiner Hausautomatisierung kein allzu großes Problem Dachte hier wären ein paar mehr Leute die Spaß am Basteln und Selbermachen haben, aber da bin ich wohl alleine... Viele Grüße, André.
Andre B. schrieb: > keine Fragen und Kommentare? Hatte mir ein wenig mehr Resonanz erhofft Andre B. schrieb: > Oha, viel Kritik, kann ich aber mit umgehen ;-) Andre B. schrieb: > Dachte hier wären ein paar mehr Leute die Spaß am Basteln und > Selbermachen haben, aber da bin ich wohl alleine... Irgendwie bist du hier falsch. Georg
Hi >Dachte hier wären ein paar mehr Leute die Spaß am Basteln und >Selbermachen haben, aber da bin ich wohl alleine... Vielleicht hättest du das ohne Arduino machen sollen. Nicht jede mag das Zeugs. MfG Spess
Andre B. schrieb: > - CAN scheidet für mich komplett aus, weil ich unter anderem völlig > ungeschirmte und unverdrillte Strom-Erdkabel zur Kommunikation > mißbrauche. Bist du ernsthaft der Meinung deine Transistortreiber gehen und CAN auf der gleichen Leitung mit der selben Baudrate geht nicht? Ich denke dann bist du komplett auf dem Holzweg. Ob das konform mit den Spezifikationen ist interessiert hier recht wenig. Dein Bus hat auch keine Spezifikation. > - Statt CAN-Controller brauche ich einen Transistor pro Slave - weniger > geht nicht Aber nur wenn die Slaves ausschließlich senden sollen. Wenn auch Empfang angedacht ist, sollten wohl noch ein paar Bauteile vor den Eingangspins kommen. Oder soll der völlig ungeschützt am Bus lauschen? > - Hier bringt kein Huster nix aus dem Tritt ;-) ne, aber in die ewigen Jagdgründe! Bei der Preisbetrachtung kommt noch der Zeitaufwand für das Protokoll dazu. Da spielen die paar Euro für die CAN-Hardware am Ende keine Rolle mehr. Andre B. schrieb: > Dachte hier wären ein paar mehr Leute die Spaß am Basteln und > Selbermachen haben, aber da bin ich wohl alleine... Wir gehören nicht zu den Millionen Fliegen die Scheiße gut finden...
Can auf Erdkabel geht garantiert besser als deine Lösung auf Erdkabel. ;-)
Wie genau werden die Leitungen denn an den µC angebunden? - Deine Zeichnung gibt kein Hinweis auf die getroffenen ESD - Maßnahmen (gegen Burst & Surge).
> den Bus gegen Low ziehen kann (dominant). Die Information selbst wird > anders als bei CAN über die Länge des Pulses dargestellt. Eine logische > "1" ist ein kurzer Puls, eine logische "0" ein langer. Das ist genau so ein Mist wie 1-Wire. Wenn du ein Protokoll nutzt wo sich der Lowlevel nicht mit gaengigen USARTs abbilden laesst dann muessen deine Controller die Kacke immer am Dampfen halten und sie nicht im Sleepmode. Olaf
Ohh ja, 1-Wire :) Wo man so zwischen 480us und 8us (oder so) Pulsezeiten einhalten muss. Mit NOP-s ist 480us zu lange. Mit Timers+Interrupt ist der 8us zu kurz.
Andre B. schrieb: > Die Datenleitung wird über einen Pullup gegen Hi gezogen. Dies ist der > rezessive Zustand. Jeder Busteilnehmer verfügt über einen Transitor, der > den Bus gegen Low ziehen kann (dominant). Die Information selbst wird > anders als bei CAN über die Länge des Pulses dargestellt. Eine logische > "1" ist ein kurzer Puls, eine logische "0" ein langer. Welche Vorteile hat das gegenüber einer etablierten seriellen Kommunikation wie z.B. RS232 und einer darauf aufbauenden Busversion wie z.B. LIN? Da gibt es fertige Treiber, Testgeräte wie Protokollanalyser auch im Soho Bereich, Programmbeispiele und und und ... es funktioniert. Ein eigenes System muss da schon etwas bieten worauf keiner der Gurus gekommen ist. Nachteile sind aber einige da. Z.B. dass sich mit deinem Protokoll die Flankenwechsel verdoppeln (und die Bitrate sich halbiert) ohne etwas zu gewinnen. Leitungen sind ja auch immer Antennen, das ist nicht gerade störstrahlfreundlich.
Deine Initiative ehrt dich ja. Und es macht ja auch Spaß was eigenes zu entwickeln und sich Gedanken darüber zu machen. Geht mir ja genauso :) Vieles wurde ja auch schon geschrieben. Einen Punkt wollte ich aber noch zu bedenken geben, der bei meiner Hausautomatisierung eine wichtige Rolle gespielt hat. Da die Knoten ja meist "versteckt" sind war es für mich wichtig einen Bootloader zu haben mit dem ich die Firmware über den Bus updaten kann. Andre B. schrieb: > Message Structure > ID Value Parity > 10 16 4 Bits = 30 Bits > 3FF FFFF Maximalwert > > Damit können nur etwas 5 Nachrichten pro Sekunde verschickt werden. Das wären dann grade mal 10Byte Payload/s. Da würde ein Update ewig dauern. Für einfache Sachen wie Licht ein/aus reicht das sicher. Aber schon wenn man an Funktionen denkt wie "Zentralaus" wo beim betätigen eines Tasters mehrere Aktionen ausgeführt werde und mehrere Telegramme zu versenden sind bekommst Du da schon ein ziemliches Delay. Olaf schrieb: > Wenn du ein Protokoll nutzt wo > sich der Lowlevel nicht mit gaengigen USARTs abbilden laesst dann > muessen deine Controller die Kacke immer am Dampfen halten und sie nicht > im Sleepmode. Da sehe ich kein Problem. Bei Pulsdauer 4/8ms hast Du genug Zeit den Controller per Interrupt beim Flankenwechsel zu wecken. Das ist eher ein Problem bei CAN. Wenn man hier den Transceiver deaktiviert (der oft der größte Verbraucher in der Schaltung ist) ist die Nachtricht futsch bis alles aktiviert ist.
:
Bearbeitet durch User
Hi Bad U. schrieb: > Bei Pulsdauer 4/8ms hast Du genug Zeit den > Controller per Interrupt beim Flankenwechsel zu wecken. Das 1-wire-Protokoll läuft in µs, nicht ms - hatte mich auch etwas ausgebremst, daß Das so flott sein muß. Unterm Strich wurden per Schleifen Takte totgeschlagen - da man taktgenau berechnen kann, wie lange eine Schleife dauert, kommt man so ganz gut parat. In der Zeit macht der Rechenknecht halt Nichts Anderes - zum Auslesen von DS18B20 aber 'ausreichende Technik'. Müsste nachlesen, aber Das hier: kyrk schrieb: > 8us dürfte den realen Werten recht nahe kommen. MfG
> Aber nur wenn die Slaves ausschließlich senden sollen. Wenn auch Empfang > angedacht ist, sollten wohl noch ein paar Bauteile vor den Eingangspins > kommen. Oder soll der völlig ungeschützt am Bus lauschen? Ich verwende einen modernen Mikrocontroller, der hat ESD-Schutz an jedem Pin ;-) > ne, aber in die ewigen Jagdgründe! Warum noch mal? > Wir gehören nicht zu den Millionen Fliegen die Scheiße gut finden... Sehr robuste Töne von Dir. Sehr subtil ;-) Aber jeder muss selbst wissen, wie er sich auszudrücken wählt. Insgesamt kann ich nur feststellen, dass es für mich die einfachste Lösung war. 1 Transitor plus pro TN bisken SW die meinen uC kaum belastet, absolut robuste Übertragung die seit Monaten fehlerlos läuft und klar - schnarchlangsam, aber wie gesagt für meine Anwendung absolut ausreichend. An meine uCs komme ich fürn update per USB dran, und über 50m Netzleitungs-Erdkabel gehen ohnehin keine großen Datenraten. Ich hatte meinen Spaß damit und wer ein wenig basteln und lernen möchte wie eine einfache aber robuste Kommunikation funktioniert findet vielleicht auch gefallen dran.
spess53 schrieb: > Vielleicht hättest du das ohne Arduino machen sollen. Nicht jede mag das > Zeugs. Wer AVR verwendet aber kein Arduino mag, ist meiner Meinung nach dämlich! Ein Ardunino ist nichts anderes als ein AVR mit nem Bootloader auf einem Breakoutboard gelötet. Man muss ja nicht die IDE nehmen! Und bei den Preisen nehmen wir sogar Arduino-Boards und verkabeln sie passend mit den Sensoren um zu schaun ob das ganze so läuft. Danach wird eine PCB designt. Wir sparen damit ungeheure Zeit. Und was Zeit im Business bedeutet muss man hoffentlich nicht erläutern! Aber lasst die Arduino-Nichtmöger ruhig weiter erstmal PCBs ätzen um dann festzustellen das sie einen Pinfehler drinn haben ;-)
Patrick J. schrieb: > Das 1-wire-Protokoll läuft in µs, nicht ms Ich hatte das ja auf dem Bus vom TO bezogen, nicht auf 1-Wire. Andre B. schrieb: > Insgesamt kann ich nur feststellen, dass es für mich die einfachste > Lösung war. Dann passts doch :) Klar wenn Du nur ein NYY mit drei Adern hast geht die Kommunikation halt nur mit zwei Adern. Gibts, wie geschrieben bei CAN aber auch. Und ob das auch sicher mit Andre B. schrieb: > beliebigen > auch ungeschirmten Leitungen und Topologien funktioniert. kann sein, aber was bringt Dich zu der Annahme? Wenn man nur auf Vorhandenes zurückgreifen kann ist die Lösung ja OK. Du schreibst aber auch, dass Deine Idee eine Erweiterung Deiner Hausautomatisierung ist. Die wäre vielleicht für das Forum wesentlich interessanter.
:
Bearbeitet durch User
Hi >Wer AVR verwendet aber kein Arduino mag, ist meiner Meinung nach >dämlich! Deine Meinung. >Und was Zeit im Business bedeutet muss man hoffentlich nicht erläutern! Doch müsstest du. Bei uns in der Firma geht es jedenfalls recht entspannt zu. >Aber lasst die Arduino-Nichtmöger ruhig weiter erstmal PCBs ätzen um >dann festzustellen das sie einen Pinfehler drinn haben ;-) Wir machen keine Leiterplatte mehr. Ein paar Musterleiterplatten sind halt billiger als eine komplette Galvanik und den ganzen Zirkus den man für mehrlagige Leiterplatten drumherum braucht. Außerdem ist ein richtige Leiterplatte selbst mit ein paar kleineren Fehler immer noch sicherer als so ein zusammengeschusterter Lego/Duplo-Aufbau aus irgendwelchen Breakout-Boards. Ich mache beruflich seit 20 Jahren Leiterplattenlayouts und auch die passende Software dazu. Mit Elektronik und Programmierung habe ich schon einige Zeit früher angefangen. Also ich bin glücklich dieses Arduino-Gedödel nicht zu brauchen. War ja ursprünlich auch mal für Künstler und ähnlich nicht eleketronikaffine Leute gedacht. Dämlich sind die, die Arduino benutzen, weil sie nichts anderes können. MfG Spess
spess53 schrieb: > Dämlich sind die, die Arduino benutzen, weil sie nichts anderes können. Wir sind zwar auf ARM umgestiegen, benutzen aber immer noch Arduino Pro-Mini und Nano Clones als Slaves für STM32 und sind sehr zufrieden damit. Haben noch eine ganze Menge davon, zusammen mit passenden Modul-Boards dafür. Die kleinen Dinger sind zuverlässig und im Gegensatz zu manch anderen Arduino-Boards ist Layout auch gut. Für verschiedene Low-Level Aufgaben, noch dazu im Assembler programmiert, gibt es einfach nichts besseres. > Außerdem ist ein richtige Leiterplatte selbst mit ein paar kleineren > Fehler immer noch sicherer als so ein zusammengeschusterter > Lego/Duplo-Aufbau aus irgendwelchen Breakout-Boards. Nein, nicht immer. Auch wenn ich mich wiederhole: Beim PC mit 3-4GHz wird auch vieles gesteckt bzw. mit Kabeln verbunden, es funktioniert und es stört sich keiner dran - warum sollten Arduino-Boards mit lächerlichen 16MHz nicht steckbar sein ?
:
Bearbeitet durch User
Hi >Beim PC mit 3-4GHz wird auch vieles gesteckt bzw. mit Kabeln > verbunden, es funktioniert und es stört sich keiner dran - warum > sollten Arduino-Boards mit lächerlichen 16MHz nicht steckbar sein ? Bis auf Stromversorgung sind das standarisierte erprobte Schnittstellen. Wo sollten da Probleme herkommen >Die kleinen Dinger sind zuverlässig und im > Gegensatz zu manch anderen Arduino-Boards ist Layout auch gut. Also ist Arduino Board nicht gleich Arduinoboard. Oder sehe ich das falsch. Abgesehen davon wurden hier mehr irgend welche Sensor-Breakout-Boards favorisiert. MfG Spess
spess53 schrieb: > Also ist Arduino Board nicht gleich Arduinoboard. Oder sehe ich das > falsch. Also, R3 Boards würde ich wegen Raster und fehlerhafter Stromversorgung bzw. Abblockung niemals verwenden. > Abgesehen davon wurden hier mehr irgend welche > Sensor-Breakout-Boards favorisiert. Tja, schlecht und billig - aber solange es für Eigengebrauch ist... Es gibt ein russisches Sprichwort, in etwa heisst es: Käse umsonst gibt es nur in der Mausefalle. Irgendwie trifft das auch auf diese Breakout Boards aus China zu...
Andre B. schrieb: > Ich verwende einen modernen Mikrocontroller, der hat ESD-Schutz an jedem > Pin ;-) Du beliebst zu Träumen. Der eingebaute ESD Schutz genügt maximal um statische Aufladungen beim Anfassen zu händeln. Mag sein dass das bei dir bisher gut ging aber verallgemeinern kann man das auf keinen Fall. > >> ne, aber in die ewigen Jagdgründe! > > Warum noch mal? Weil dein Pin weitgehend ungeschützt an der langen Leitung hängt. Kannst ja damit mal in das nächste EMV Labor zum fröhlichen Pin braten gehen. Das allerwenigste ist ein Serienwiderstand um die Ströme in den Ableitdioden zu begrenzen. Und selbst das ist kein Schutz mehr wenn die beim EMV-Test üblichen 8kV an 150pF auf deinen Eingang geschaltet werden. Aber 1000 mal besser als den Pin direkt auf die Leitung zu legen.
Moins, hier hacken viele auf Andre rum, vermutlich ohne eigene Erfahrungen gemacht zu haben. Darum teile ich mal meine: Seit vier Jahren habe ich einen ähnlichen Bus laufen: drei Leitungen (+5V,GND,Signal), wobei das Signal an einer Stelle (derzeit alles andere als zentral) über einen Stromspiegel auf 5V gezogen wird -- anfangs hatte ich einen Pullup, das ging auch. Derzeit ca. 75m Leitung, fast alles 4x2-adriges Telefonkabel, das bereits in der Wand lag. Ich fahre mit 3,3kBaud (also keine unterschiedlichen Bitzeiten), nutze ein paar CAN-Prinzipien. Die bisher vorhandenen vierzehn Geräte übertragen üblicherweise weniger als 400 Bit pro Sekunde (über fünf Sekunden ermittelt), da habe ich also noch viel Luft. Probleme gab es bisher keine. Die Prozessoren (ATMega) langweilen sich, denn mit einem Capture-Eingang und einem Compare-Ausgang kann man das Protokoll ohne viel Rechenleistung umsetzen und auch noch das tun, was das Gerät eigentlich machen soll. Natürlich gibt es jeden Monat ein paar Datenpakete, die nicht fehlerfrei überall ankommen, aber damit muss jeder Bus umgehen können, dafür gibt es CRC etc. Die Hardware ist wirklich einfach, man braucht an jedem Busknoten weder Spezialbauteile noch lokale Spannungsregler, sondern nur sehr wenig diskretes Zeug außer dem Controller. Gruß!
Nachtrag zu meinem vorigen Beitrag: natürlich ist ein solcher Bus keine Lösung für jedes Kommunikationsproblem und hat seine besonderen Vor- und Nachteile -- aber das gilt auch für jeden anderen.
Na ja, es ging von André so ein bisschen in die Richtung, dass CAN ja ausscheidet, weil das auf dem Kabel ja nicht funktionieren würde. DARAUF sind einige Leute (zu Recht) eingestiegen. Vielleicht war es die Fehlannahme, dass CAN-Leitung geschirmt und verdrillt sein müsste. "MiWi" und "temp" haben das am 05.07. um 09:14 und 09:51 ganz gut zusammengefasst und ich kann mich dem nur anschließen: Es kann ja für ihn in seinem Umfeld funktionieren, eine brilliante Lösung ist es dadurch nicht. Der vermeintlich einfache Anschaltungsaufwand würde sich im nächsten Anwendungsszenario bei einem anderen Anwender rächen, z.B. wenn Störquellen vorhanden sind. Der Basteltrieb in Ehren und André hat bestimmt auch etwas dabei gelernt. In vielen Beiträgen hier im Forum zeigen sich die verschiedenen Ausprägungen der Autoren. Die einen möchten "basteln" um jeden Preis, mit Breadboards, Pollin-Bauteilen, Arduino, uralten Controllerfamilien usw. Andere Poster möchten wiederum professionelle Elektronik verstehen und/oder entwerfen, die möglichst im höchsten Maße standardkonformen, zuverlässig und robust funktioniert - einfach nur so, auch ohne direkte Notwendigkeit. Da gibt es zwischen diesen Lagern keinen Konsens, niemals leider.
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.