Hallo Zusammen, ich bin gerade am überlegen ob es möglich ist, ein relativ einfaches Bus-System zu konstruieren: Zunächst gibt es nur 1 Datenleitung, an welche verschiedene Controller angeschlossen werden. Es soll auch möglich ein einen PC über RS232 anzuschließen (vielleicht auch später vía USB und FTDI Chip). Ich habe mal ein klein wenig mit einem solchen Bus gearbeitet, aber im Grunde keine Ahnung wie die Hardware dort aussah. Es handelt sich um das ccTalk "Bus-System". Dort wurde der Datenverkehr auch über eine Datenleitung durchgeführt . Die Daten werden über die Datenleitung im Prinzip wie über die serielle Schnittstelle geschickt. Erst ein Start-Bit, Datenbits, evnt. Parity Bit. Das Protokoll kann man sich ja einigermaßen zurecht basteln. z.B. 4Bit Empfänger 4Bit Absender 8Bit ~Irgendein Steuerkram (ack/error/?) n*8Bit Daten 8Bit Checksumme Das müsste ja eigentlich funktionieren, denke ich. Jeder Controller benötigt dann eine 4-Bit Adresse (vielleicht für 15 Geräte + Broadcast?). Allerdings ist meine Frage nicht die Software, sondern die Hardware-Seite. Da kenn ich mich leider nicht so aus. Mein, wahrscheinlich viel zu einfacher Gedanke wäre, einfach die RxD und TxD Leitungen zusammenlegen. Allerdings habe ich Angst dass dann etwas durch einen Kurzschluss passiert :/ Ich habe mal eine kleine Skizze angehängt. Ist sowas realisierbar? Wie müsste die Hardware in etwa aussehen, falls meine einfache Variante nichts taugt? Eine weitere Frage habe ich dennoch: Gibt es eigentlich ein USB<->RS232 Wandler, mit welchem man relativ ungefährlich basteln kann? Hießt, falls ich mal mist bau, geht mir höchstens der Wandler kaputt, aber sonst nichts am Laptop/PC. Oder sind die im Grunde alle relativ sicher gegen sowas? Viele Grüße, Thomas
So geht's sicher nicht, da muss man schon passende Treiber nehmen. Dann könnte man das Ganze z.B. LIN-Bus nennen.
Wenn das ein Schaltplan sein soll, nein, so kann man so etwas nicht machen. Einerseits schließt Du Sende- und Empfangsdatenleitung des µC miteinander kurz, andererseits ist RS232 nicht für Bus-Verbindungen geeignet. Sehr verbreitet ist für derartige Bussysteme RS485, dafür benötigst Du genau zwei Leitungen, und Du musst die entsprechenden Bustreiber sinnvoll ansteuern (Sende-/Empfangsumschaltung nur dann auf Senden schalten, wenn auch gesendet werden soll), und ein geeignetes Protokoll entwickeln (Busteilnehmer senden nur auf Anforderung durch den Master). In ernstgemeinten Automationssystemen wird der RS485-Treiber von der restlichen Schaltung galvanisch getrennt, d.h. die Signale, die mit dem µC verbunden sind, werden durch Optokoppler isoliert und die Stromversorgung des RS485-Treibers erfolgt durch einen isolierten DC/DC-Wandler.
Eindrahtbusse (plus GND, das brauchst Du natürlich auch): * 1-Wire (Dallas/Maxim) * LIN-Bus (Automobilindustrie) * Signe-Wire-CAN (Automobilindustrie) * eBus (Modellbahnanlagen) Wenn es um Störsicherheit geht, ist schon zweidraht besser. * CAN * RS485
Die einzige vernünftige Lösung heisst CAN-Bus = Controllers Area Network Es ist extra ein Bus-System, entwickelt für Verbindung mehrerer CPUs im Verbund. Zudem muss man sich um Dinge wie "Bus ist frei und ich darf Senden" oder CRC usw. keine gedanken machen, denn das macht die HW bereits von alleine. Man kann auch RS485 verwenden, ist aber mit mehr Programmieraufwand verbunden. Zum PC hin baust Du einfach noch einen RS232/CAN Wandler. Ausserdem ist V24 (RS485) nicht besonders Sicher. z.B. ein Gerät wird aus gesteckt, oder noch schlimmer, es wird sporadisch während einem Datenverkehr ein gesteckt, dann empfängt es irgend ein Rest und versucht damit klar zu kommen. CAN ist da wesentlich leichter, denn darum kümmert sich die Hardware. Also, wenn Du ein Anfänger in Sachen Bussystem bist, nimm lieber CAN.
Hey, schonmal vielen Dank für die Hinweise. RS485 hört sich eigentlich ganz interessant an. Jedoch weiß ich noch nicht, ob ich da auch den PC als Master verwenden kann - aufgrund der Steuerleitungen (Read Enable; Data Enable). Zur kommunikation mit der seriellen Schnittstelle verwende ich beim Programmieren einfache Windows-API Funktionen, mit welchen ich lediglich Bytes senden/empfangen kann. Da noch die Steuerleitungen zu bedienen stell ich mir zur Zeit schwierig vor (hab jetzt aber auch erst nur kurz nachgedacht :)). Das mit dem LIN Bus hört sich gut an. Mal sehen ob ich noch ein paar vernünftige Dokumente finde - Google liefert auf den ersten Blick nur eine Menge "Auto-Kram" g Die anderen, erwähnten 1-Draht Busse werd ich mir jetzt mal genauer ansehen, vielleicht finde ich da ein paar leicht verständliche Info´s. Den CAN Bus habe ich nur sehr kurz kennen gelernt, und ich denke das ist etwas zu "groß" für mich. Des Weiteren muss ich sagen, ich arbeite zwar an meinem "Hausbus" um Kommunikation zu ermöglichen - allerdings find ich es sehr interessant das Protokoll selbst zu implementieren und Dinge wie Kollisionen selbst in die Hand zu nehmen. Ich glaube nicht, dass ich große Strecken überbrücken möchte, bei welchen die Übertragung kritisch wird. Eigentlich hatte ich gehofft, das ganze durch relativ einfache Schaltungen zu realisieren - also ganz ohne Treiberbausteine. Schließlich muss man auch erstmal an solche ICs kommen g Auch hab ich gesehen, kostet der MAX485 schon 1,60 € - was ich nicht unbedingt wenig finde. Da habe ich jetzt aber auch noch nicht nach alternativen geguckt. Okay, also eine optische "Trennung" der Leiterbahnen verhindert Chaos in den Endgeräten - die normalen seriell<>USB Adapter, welche man kaufen kann, geben leider nicht viele Informationen über ihr Innenleben her. Viele Grüße, Thomas
Christian H. schrieb: > Eindrahtbusse (plus GND, das brauchst Du natürlich auch): > > * 1-Wire (Dallas/Maxim) > * LIN-Bus (Automobilindustrie) > * Signe-Wire-CAN (Automobilindustrie) > * eBus (Modellbahnanlagen) VBus von RESOL (Solarregler) hast du vergessen. ;-)
T. K. schrieb: > Jedoch weiß ich noch nicht, ob ich da auch den PC als > Master verwenden kann - aufgrund der Steuerleitungen (Read Enable; Data > Enable). Zur kommunikation mit der seriellen Schnittstelle verwende ich > beim Programmieren einfache Windows-API Funktionen, mit welchen ich > lediglich Bytes senden/empfangen kann. Da noch die Steuerleitungen zu > bedienen stell ich mir zur Zeit schwierig vor (hab jetzt aber auch erst > nur kurz nachgedacht :)). Das ist, wenn man die normale Onboard-Schnittstelle verwendet, auch wirklich ein Problem. Zwar kann man eine Handshakeleitung für die Umschaltung verwenden, deren Ansteuerung mit Win32-API-Funktionen auch recht einfach möglich ist, aber den zeitlichen Zusammenhang zwischen "letztes Byte übertragen" und der danach erforderlichen Abschaltung des Senders bekommt man so nicht sehr genau hin. Etwaige Hardware-FIFOs der Schnittstelle sollte man dafür deaktivieren, und man muss nach dem Senden eine gewisse Zeit lang warten. Das ist nicht sehr effizient, und gerade bei Protokollen, bei denen abwechselnd wenige Bytes empfangen und gesendet werden, wird das ganze sehr langsam. Das aber stellt gar kein besonderes Problem dar. Wie Du schon angedeutet hast, bist Du am Einsatz eines USB-RS232-Wandlers interessiert. Wenn Du einen geeigneten Baustein wie FT232 oder CP2103 verwendest, dann bietet der die Sende/Empfangs-Ansteuerung in Hardware. Du musst nur die Steuerleitung des RS485-Treibers mit dem dafür vorgesehenen Ausgang des Bausteines verbinden und das war's dann auch schon. Softwareseitig musst Du Dich in diesem Falle gar nicht um die Ansteuerung kümmern, das macht die Sache einfach und übersichtlich. Dir wird aufgefallen sein, daß ich immer nur von einer Steuerleitung rede, obwohl der RS485-Treiber doch zwei hat - eine für den Empfänger, eine für den Sender. Die kannst Du beide mit dem selben Signal ansteuern, da sie umgekehrte Polarität haben. Der Nebeneffekt davon ist, daß Du ein automatisches "Hardware-Echo" hast; was Dein PC sendet, empfängt er auch gleich wieder. Das ist durchaus sinnvoll, denn damit kannst Du Störungen auf dem RS485-Bus erkennen. Wenn nämlich zeitgleich ein anderes an den Bus angeschlossenes Gerät sendet, empfängt Dein PC die "Mischung" aus seinen und den "fremden" Daten, womit die Störung leicht erkennbar ist.
"Dir wird aufgefallen sein, daß ich immer nur von einer Steuerleitung rede, obwohl der RS485-Treiber doch zwei hat - eine für den Empfänger, eine für den Sender. Die kannst Du beide mit dem selben Signal ansteuern, da sie umgekehrte Polarität haben." ...hm, was denn nu? Wenn du die zusammenlegst, ist entweder Sender oder Empfänger aktiv. Also kein Echo, wenn der Sender eingeschaltet ist. Für diese Betriebsart muss der Empfänger immer aktiv sein, der Sender nur bei Bedarf. Preis: der "Klassiker" SN75176 kostet nur wenige Cent. MAX485 muss es nicht sein....
Und zum Ursprungsthema zurück: nimm CAN. Prinzipiell würde ich auch zu einem 2Draht (Differenzsignal) raten. Und dann hast du die Wahl zwischen CAN und RS485. RS485 ist billiger, keine Frage. Aber die Software hat das Potenzial, dich zum Verzweifeln zu bringen. Für eine typische SingleMaster/Multislave-Kommunikation kann man das hervorragend nutzen. Einfach zu implementieren, störsicher, billig. Bei einem Hausbus ist ein Multimasterbetrieb sehr sinnvoll. Du brauchst dir mit CAN keine Gedanken über die Busberechtigung zu machen, wenn einer was zu sagen hat, tut er es einfach. Und es kommt an :-). Es haben schon viele versucht, einen Multimasterbetrieb mit RS485 zu basteln. Tu es dir nicht an :-)
Hey, puh also nochmal vielen Dank für die Antworten. So ganz so einfach scheint das wohl nicht zu sein, da werd ich mir nochmal ordentlich Gedanken drüber machen müssen. RS485 find ich persönlich schon ziemlich nett, weil ich es immerhin ~einigermaßen~ verstehe :) Aber das kann sich mit dem CAN Bus ja auch noch ändern. Vielen Dank, Thomas
Multimaster auf 485 ist eklig aber machbar, man hat halt die volle Freiheit im Protokoll ... Profibus, Modbus, SNAP oder halt selbstgestrickt ... btw. 4 Bit sind für Adressierung etwas knapp, oder?
CAN hat: - 29 Bit Adresse - 0-8 Byte Nutzdaten Das einfach in die Register des Prozessors kopieren, dann das Sende jetzt Bit setzen, fertig. Ankommen tut dann in allen am Bus hängenden CPUs in RX Registern - 29 Bit Adresse - 0-8 Byte Nutzdaten - Garantiert - Fehlerfrei - egal wie viele gleichzeitig senden - die CAN-HW wiederholt automatisch das Telegramm wenn das Senden fehl schlägt - hört sich doch einfach an, oder? Nimm eine CPU die bereits CAN drin hat und einen Chip PCA82C251 (CAN Transceiver, also der Leitungstreiber), kostet bei Reichelt 0,97 EUR. Ist also auch günstiger als RS485.
Naja, CAN-Controller MCP2515 bekommt man für kleines Geld. Ist schon ne echte Alternative zu MC mit integriertem CAN. Mega8+MCP2515+PCA82C250 ist man mit 4€ dabei.
Wirklich langfristig ist nur RS485 bzw. RS232. Ein Haus steht durchaus 100 Jahre!
>>der "Klassiker" SN75176 kostet nur wenige Cent. MAX485 muss es nicht sein.... Der Klassiker zieht aber im Ruhezustand schon deutlich mehr Strom als der MAX485. Und bißchen störsicherer (ESD) müsste der Max auch sein.
Abdul K. schrieb: > Wirklich langfristig ist nur RS485 bzw. RS232. Ein Haus steht durchaus > 100 Jahre! Wiso sollte CAN nicht genauso lanfristig funktionieren???
Na sicher ist der MAX485 besser (sonst wäre er unverkäuflich) - funktionieren wird das aber mit dem alten Hündchen. Zukunftssicherheit: in 100 Jahren wird es weder das eine noch das andere geben. Als die ersten Telefonkabel verlegt wurden, hat auch keiner dran gedacht, dass man da DSL drüberjagen kann. Falls man soweit denken will - eine Doppelader als Medium hat sich schon seit langer Zeit bewährt. Und irgendwann ist auch eh eine komplette Sanierung aller technischer Installationen erforderlich (Leitungen/Rohre aller Art). Ansonsten glaub ich, dass es CAN länger geben wird als RS485.
CAN hängt direkt mit dem wabernden Automobilmarkt zusammen. Die Produktzyklen sind dort mittelfristig. Häuser werden ca. alle 30 Jahre teilsaniert, zumindest das Dach hält nicht länger als ca. 50 Jahre. Ein Mensch lebt heutzutage 90 Jahre, wenn er schon etwas älter war. Davon ist er vielleicht 30 Jahre produktiv und nicht mehr als 50-60 Jahre ansprechbar und wissend genug, sein Werk zu warten. The Beauty of CAN ist einfach die Sache, das es der ideale Bus für Bitschubser ist. Leute die nicht wissen, was man macht, wenn zwei Treiber gleichzeitig senden könnten. Schaut euch an wie lange ASCII und RS232 schon leben! Und RS485 ist nunmal der Update für RS232: schneller, störfester, galvanische Trennung durch transformatorische Kopplung easy, multi-master Im Notfall sind Ersatzchips leicht selbst zu bauen, was man bei CAN vergessen kann. Denn Transistoren wirds seeeehr lange geben. Daher meine Prognose.
@Abdul CAN gibtg es nicht nur in Autos. In der Industrieautomatisierung wird ebenfalls sehr oft und gerne CAN verwendet. Es gibt heute sooo viele Mikrocontroller mit integriertem CAN, die werden garantiert nicht plötzlich alle verschwinden. CAN gehört heutztage ebenfalls zu einem Standard wie ein UART. Wenn RS485 tatsächlich besser und günstiger wäre als CAN, dann würde heute in den Autos garantiert kein CAN sondern RS485 drin sein! Ausserdem kann man einen CAN Transceiver auch mit ein paar Transis selbst zur Not basteln, denn in dem Chip sind auch nur Transis drin. CAN Haus Projekte gibt es genügend im www: http://www.canathome.de/ http://caraca.sourceforge.net/ http://www.iuse.org/ http://home-automation-project.netmb.net/ CAN hat sich bereits ebenfalls seit mindestens einem Jahrzehnt bewährt und bewiesen dass es sicher ist. So sicher dass damit auch ein Airbag gesteuert werden darf! Was ist, wenn es keinen UART mehr in den Mikrocontrollern gibt?? Was ist wenn es einen jahrelangen Stromausfall gibt? Meiner Meinung nach ist es warscheinlicher, dass ein Meteorit in Dein Haus einschlägt oder das Haus vom Erdbeben platt gemacht wird (warte noch 3 Jahre), als dass es kein CAN mehr zu kaufen gibt. Natürlich gibt es technische neuerungen. Ich warte schon lange auf eine CPU die anstatt mit elektronen mit photonen Biogenetisch arbeitet. Dann wäre der Rechner so schnell wie die Lichtgeschwindigkeit. Und die Datenübertragung erfolgt dann mit neutrinos im Raum-Zeit Äther. Somit kannst Du deine Transistoren vergessen. Also so lange es Chips in Silizium gibt, wird es auch CAN geben. Ich kenne beide Bussysteme seit garantiert über 10 Jahren in und auswendig. In einer Haussteuerung, in der nur einzelne Bits/Adressen anfallen ist das nunmal das effizientere als sich um RS485 und das ganze Handshake zu kümmern. Man darf natürlich gerne das 5 Fache an Zeit verbraten um dieses Handshake über RS485 aus zu baldovern und zu 100% in den Griff bekommen. Wenn ich RS485 verwende, dann schicke ich die Daten nur noch UU-Codiert weil damit das Datenpaket garantiert als ein Block zusammenhängt. Ich selbst mache mein Hausbus auch mit CAN. Hier die Heizungssteuerung: Beitrag "Re: Heizungssteurung im Eigenbau"
Markus Müller schrieb: > - Garantiert > > - Fehlerfrei > > - egal wie viele gleichzeitig senden > > - die CAN-HW wiederholt automatisch das Telegramm wenn das Senden fehl > > schlägt > > - hört sich doch einfach an, oder? > > > > Nimm eine CPU die bereits CAN drin hat und einen Chip PCA82C251 (CAN > > Transceiver, also der Leitungstreiber), Schau mal bei IPSymcon rein. http://www.ip-symcon.de/forum/f48/stammtisch-hamburg-norddeutschland-9250/index10.html#post79595
Markus Müller schrieb: > @Abdul > CAN gibtg es nicht nur in Autos. In der Industrieautomatisierung wird > ebenfalls sehr oft und gerne CAN verwendet. Es gibt heute sooo viele > Mikrocontroller mit integriertem CAN, die werden garantiert nicht > plötzlich alle verschwinden. CAN gehört heutztage ebenfalls zu einem > Standard wie ein UART. Stimmt. Das wußte ich alles nicht. > > Wenn RS485 tatsächlich besser und günstiger wäre als CAN, dann würde > heute in den Autos garantiert kein CAN sondern RS485 drin sein! Eigentlich hast du dir auf alle deine Aussagen auch selbst Antworten gegeben! Aber die kriegste noch: Dann wäre Ethernet drin! > > Ausserdem kann man einen CAN Transceiver auch mit ein paar Transis > selbst zur Not basteln, denn in dem Chip sind auch nur Transis drin. Kann man alles, klar. Mach dann schonmal das Gehäuse entsprechend groß, falls du in 15 Jahren den Schalter updaten mußt. > > CAN Haus Projekte gibt es genügend im www: > http://www.canathome.de/ > http://caraca.sourceforge.net/ > http://www.iuse.org/ > http://home-automation-project.netmb.net/ > > CAN hat sich bereits ebenfalls seit mindestens einem Jahrzehnt bewährt > und bewiesen dass es sicher ist. So sicher dass damit auch ein Airbag > gesteuert werden darf! Nee. Heißt du MaWin? In keinster Weise habe ich zu Sicherheit groß was gesagt. Ich bezog mich vor allem auf Kompatibilität und Übersicht. > > Was ist, wenn es keinen UART mehr in den Mikrocontrollern gibt?? > Was ist wenn es einen jahrelangen Stromausfall gibt? Meiner Meinung nach > ist es warscheinlicher, dass ein Meteorit in Dein Haus einschlägt oder > das Haus vom Erdbeben platt gemacht wird (warte noch 3 Jahre), als dass > es kein CAN mehr zu kaufen gibt. Man, benutz es doch! Keiner hindert dich! Wenn du mit CAN aufgewachsen bist, nimm es! Kennste Ethernet: Nimm es! Wenn du Framing auf RS485 fertig haben willst für Doofies: nimm phyNET. > > Natürlich gibt es technische neuerungen. Ich warte schon lange auf eine > CPU die anstatt mit elektronen mit photonen Biogenetisch arbeitet. Dann > wäre der Rechner so schnell wie die Lichtgeschwindigkeit. Und die > Datenübertragung erfolgt dann mit neutrinos im Raum-Zeit Äther. Somit > kannst Du deine Transistoren vergessen. > > Also so lange es Chips in Silizium gibt, wird es auch CAN geben. Nein! Wir sprechen uns in 20 Jahren wieder. CAN war notwendig, weil die Autoindustrie was brauchte. Das sahen sie erstaunlicherweise selbst ein. Ethernet kam nicht in Betracht. Da hätte man was zugeben müssen. Also ein neuer propietärer Bus. Er wurde technisch gesehen, durchaus gut. Und weil die anderen Doofies in der Industrie zu blöde sind selbst einen Bus zu bauen, haben sie dann CAN übernommen. So ist das. > > Ich kenne beide Bussysteme seit garantiert über 10 Jahren in und > auswendig. In einer Haussteuerung, in der nur einzelne Bits/Adressen > anfallen ist das nunmal das effizientere als sich um RS485 und das ganze > Handshake zu kümmern. Man darf natürlich gerne das 5 Fache an Zeit > verbraten um dieses Handshake über RS485 aus zu baldovern und zu 100% in > den Griff bekommen. Wenn ich RS485 verwende, dann schicke ich die Daten > nur noch UU-Codiert weil damit das Datenpaket garantiert als ein Block > zusammenhängt. Du kriegst noch nichmal eine gesicherte Verbindungsschicht hin? Arm. > > Ich selbst mache mein Hausbus auch mit CAN. Hier die Heizungssteuerung: > Beitrag "Re: Heizungssteurung im Eigenbau" Na endlich die Wahrheit.
>Du kriegst noch nichmal eine gesicherte Verbindungsschicht hin? Arm. Wieso soll ich selbst eine proggen wenn ich die bereits gratis via CAN bekommen? >Nein! Wir sprechen uns in 20 Jahren wieder. gerne.
Markus Müller schrieb: >>Du kriegst noch nichmal eine gesicherte Verbindungsschicht hin? Arm. > Wieso soll ich selbst eine proggen wenn ich die bereits gratis via CAN > bekommen? Nöö, mußte nicht. Bei Ethernet hättest du aber sogar den IP-Stack vom PC kostenlos... > >>Nein! Wir sprechen uns in 20 Jahren wieder. > gerne. ;-) Schau dir an, was die Profis im Anlagenbau machen. Chemiefarmen halt. HART, 20mA
Abdul K. schrieb: > Schau dir an, was die Profis im Anlagenbau machen. Chemiefarmen halt. > HART, 20mA Steinalt, genau wie Profibus (ist übrigens RS485). ;-)
Bitte 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.