Hallo, ich will mehrere Slaves an einen Master hängen und suche nach einem geeigneten Bus-System, welches auch eine Länge von 10 bis 15 Metern mitmacht. Oberstes Prinzip: Einfach und billig. Ich habe an SPI gedacht (umgesetzt auf RS485), aber da muss ich die ganzen CS-Leitungen mitschleppen. Auch IIC ist wohl wenig geeignet, da hier die Umsetzung auf RS485 nicht funktioniert. Also bleibt nur CAN (zu teuer) oder RS232 auf RS485 umgesetzt, falls ich das dann überhaupt muss (wegen der Kabellängen). Vielleicht gibt es ja auch noch etwas anderes. Ich bin für jeden Vorschlag zu haben. Danke, Peter
Hallo Peter, warum nimmst Du nicht direkt RS232? Du könntest alle Teilnehmer parallel an den Bus hängen. Über die Payload werden die einzelnen Teilnehmer adressiert. Nötig wäre in diesem Szenario allerdings ein Master der den Clients "Rede-Rechte" zuweist. Spricht etwas dagegen? Vg Stefan
RS232 ist nur point to point fähig. Man könnte aber eine Art Token Ring bauen. Ich würde es mit RS485 machen (Bei der Treiberwahl darauf achten, dass deine 20 Teilnehmer abgedeckt sind.) Gruß Roland
>> warum nimmst Du nicht direkt RS232? >> Spricht etwas dagegen? Ja, es ist nicht als Bus-System geeignet. RS485 ist genau für sowas konzipiert.
Peter schrieb: > Also bleibt nur CAN (zu teuer) oder RS232 auf RS485 umgesetzt, falls ich > das dann überhaupt muss (wegen der Kabellängen). Wieso ist CAN zu teuer? Wenn ich bei Digikey schaue: PIC18F25K80 im SSOP: 2.42€ bei 25 Stück MCP2561 SO08: 0.73€ bei 25 Stück Summe: 3.15€ Alternativ: LPC11C24: 3.95€ bei 25 Stück Wie billig solls denn werden?
http://www.omnibusrevue.de/neuer-10-m-reisebus-von-buessing-825974.html Da gehen (mit Stehplätzen) vielleicht sogar bis zu 80 Teilnehmer rein :D
thomas schrieb: > RS485 ist genau für sowas konzipiert. Um das zu präzisieren, weil der TO schon an SPI-over-RS485 bzw. I2C-over-RS485 nachgedacht hat: Gemeint ist hier UART (nicht RS232) an RS485-Transceiver.
:
Bearbeitet durch Moderator
warum nicht onewire 1w? bei mir hängen temp<\r> temp -> zeige alle Temperaturen <\r> <\n>282e075503000057 +20,8?C, Wohnzimmer, Bus:#1, N:136, M:4, P:80 <\r> <\n>284dc793030000df +19,9?C, Schlafzimmer, Bus:#1, N:136, M:4, P:76 <\r> <\n>2893d4930300003a +20,8?C, kl. Zimmer, Bus:#1, N:136, M:4, P:80 <\r> <\n>288bd19303000012 +24,8?C, Z?hlerschrank, Bus:#1, N:136, M:4, P:96 <\r> <\n>28cde10004000042 +15,5?C, Balkon, Bus:#1, N:136, M:4, P:60 <\r> <\n>2860f29303000075 +21,5?C, Wohnzimmer warm,Bus:#1, N:136, M:4, P:84 <\r> <\n>0000000000000000<\r> <\n>Ready<\r> 6 Tempsensoren an ca. 50m Stern Bus gemischt gibt viele Teile in onewire 1w https://www.mikrocontroller.net/part/DS2405 http://www.maximintegrated.com/en/products/comms/one-wire.html https://de.wikipedia.org/wiki/1-Wire https://www.google.de/search?q=onewire&ie=utf-8&oe=utf-8&gws_rd=cr&ei=_iOBVZfbFees7AaY_IAo#q=one+wire+aktor https://www.google.de/search?q=onewire&ie=utf-8&oe=utf-8&gws_rd=cr&ei=_iOBVZfbFees7AaY_IAo#q=onewire+sensoren https://www.google.de/search?q=onewire&ie=utf-8&oe=utf-8&gws_rd=cr&ei=_iOBVZfbFees7AaY_IAo#q=onewire+schalter
Joachim B. schrieb: > warum nicht onewire 1w? Weil der TO komplett offengelassen hat, was für Slaves er an den Bus hängen will. Daraus kann man eigentlich nur folgern, dass es sich um selbst zu entwickelnde Slaves handelt. Denn wenn der TO wüsste, welche Slaves er an den Bus hängen wollte, wäre der Typ des Busses ja schon klar vorgegeben. OneWire Slaves selbst zu programmieren würde ich mir nicht antun, da das Timing ziemlich heftig ist. Oder gibt es bereits generische OneWire-Transceiver in Hardware gegossen, die man einfach an den µC anflanscht? Tja, jetzt geht das Rätselraten wieder los. Der TO hat zwar die Länge des Busses genannt, aber weder etwas zur notwendigen Datengeschwindigkeit und Datenmenge gesagt noch erzählt, was das überhaupt für Slaves sein sollen.
:
Bearbeitet durch Moderator
Single-Master ist doch prädestiniert für RS485. Und das ist eine sehr billige Option. CAN ist auch ganz gut geeignet, falls die verwendeten Controller bereits ein CAN-Modul besitzen. Welche Datenrate wird denn angestrebt? Gruß, Stefan
Frank M. schrieb: > Tja, jetzt geht das Rätselraten wieder los. Der TO hat zwar die Länge > des Busses genannt, aber weder etwas zur notwendigen > Datengeschwindigkeit und Datenmenge gesagt noch erzählt, was das > überhaupt für Slaves sein sollen. So ist es, aber die passenden Lösungen werden schon ausgelost ;-) Für Übertragungsgeschwindigkeiten bis 115 kBd wären RS485 Treiber im Halbduplexbetrieb mit Multiprozesser-Protokoll mein Vorschlag. Auch CAN-Bus Treiber würden sich anbieten, ebenfalls per UART betrieben.
Frank M. schrieb: > OneWire Slaves selbst zu programmieren würde ich mir nicht antun, ich auch nicht, soll aber fertiges geben Frank M. schrieb: > Oder gibt es bereits generische > OneWire-Transceiver in Hardware gegossen, die man einfach an den µC > anflanscht? keine Ahnung könnte sein, ich habe ja meine Timming "Problemchen" so pö a pö selber beim Master ausgeräumt da ich ja parasitär speise, zuerst ging es mit 5 Busse an 5 Ports, dann habe ich die zurückgebaut bis alle Busse nun "illegal" als Stern am einen Port hängen. läuft seit Jahren so ca. 5 Jahre mit derselben Software.
Zuverlässig, kostengünstig und einfach umzusetzen: LIN Bus https://ess.cs.tu-dortmund.de/Teaching/PGs/autolab/seminarfolien/Meier-LIN.pdf Unterstützt aber von Haus aus nur 16 Busteilnehmer.
Joachim B. schrieb: > ich habe ja meine Timming "Problemchen" so pö > a pö selber beim Master ausgeräumt [...] Beim Master ist es einfach: dieser kann ja selbst entscheiden, wann er gerade Zeit hat, seine Slaves abzuklappern. Aber ein Slave muss immer verfügbar sein, egal wie "tief" er gerade in seinen Interrupts hängt, die er nebenbei so abklappern muss. Bei UART an RS485 ist das überhaupt kein Problem. Bei OneWire kann es aber ziemlich kritisch werden.
Erstmal Danke für die vielen Antworten! Frank M. schrieb: > Tja, jetzt geht das Rätselraten wieder los. Der TO hat zwar die Länge > des Busses genannt, aber weder etwas zur notwendigen > Datengeschwindigkeit und Datenmenge gesagt noch erzählt, was das > überhaupt für Slaves sein sollen. Es sollen Mikrocontroller angeschlossen werden (ATmega oder ATtiny). Die sollen dann vom Master alle paar Sekunden ein paar Dutzend Bytes erhalten (Übetragungsrate wenige kHz), um dann einige wenige Daten wieder an den Master zurück zu senden. Stefan schrieb: > warum nimmst Du nicht direkt RS232? Bzgl. RS232/UART: Kann ich den Bus evtl. komplett als RS485 aufbauen und dann z. B. nach jedem Meter mit einer kurzen Stichleitung und Pegelumsetzer einen AVR/Attiny über UART anhängen? Alle hören mit und das erste Byte gibt an, welcher Controller adressiert ist. Frank K. schrieb: > Wieso ist CAN zu teuer? Nicht zu teuer, aber aufgrund der ATmega/ATtiny fehlt die Hardware. Joachim B. schrieb: > warum nicht onewire 1w? Ich denke, an Leitungen muss ich nicht sparen (abgesehen von den SPI CS). Mittlerweile habe ich auch mal etwas gegoogelt und folgende Chips gesehen: http://www.reichelt.de/P-82B715-TD/3/index.html?&ACTION=3&LA=446&ARTICLE=70074&artnr=P+82B715+TD&SEARCH=P82B715 Evtl. nehme ich sowas oder eben UART auf RS485. Peter
Peter schrieb: > Bzgl. RS232/UART: Kann ich den Bus evtl. komplett als RS485 aufbauen und > dann z. B. nach jedem Meter mit einer kurzen Stichleitung und > Pegelumsetzer einen AVR/Attiny über UART anhängen? Alle hören mit und > das erste Byte gibt an, welcher Controller adressiert ist. Ja, genau so wird das gemacht. Bei niedriger Übertragungsrate sind Stichleitungen auch kein Problem. Gruß Dietrich
Peter schrieb: > Suche Bus: 10m lang und 20 Teilnehmer http://www.autoscout24.de/nutzfahrzeuge/catalogcontent/trucks/de/images/129/large/kleinbus-1-1024x683.jpg SCNR
Peter schrieb: > Alle hören mit und > das erste Byte gibt an, welcher Controller adressiert ist. Wenn die Übertragungssicherheit sehr wichtig ist, sollte das 1. Zeichen im Datenstrom eindeutig sein, d.h. man sollte ein zusätzliches Startzeichen spendieren. Am einfachsten geht das, wenn man die Daten ASCII-codiert. Nebenbei kann man zum Testen dann auch einfach an der Leitung mit einem Terminal-Programm mithören. Gruß Dietrich
Peter schrieb: > Evtl. nehme ich sowas oder eben UART auf RS485. Genauso wird das gemacht. Der Klassiker (incl. failsafe): http://www.reichelt.de/MAX-485-CSA/3/index.html?&ACTION=3&LA=446&ARTICLE=39600&artnr=MAX+485+CSA&SEARCH=max485 Peter schrieb: > Alle hören mit und > das erste Byte gibt an, welcher Controller adressiert ist. Gibt's sozusagen fertig. Nennt sich "Multi-processor Communication Mode".
Für diese Eckdaten ist RS485 ideal. Nimm Deine Tiny/Atmega, baue vor den internen UART einen RS485-Treiber, z.B. für 1,20€ bei Reichelt: http://www.reichelt.de/MAX-485-CSA/3/index.html?&ACTION=3&LA=446&ARTICLE=39600&artnr=MAX+485+CSA&SEARCH=rs485 Dann hängst Du sie alle nacheinander an ein Kabel. Bei niedrigen Baudraten sind auch Stichleitungen kein Problem. Vorne und hinten einen Abschlußwiderstand. Bei niedrigen Baudraten und Stichleitungen funktioniert auch Zentralterminierung. Als Protokoll ASCII, macht das mitlesen sehr einfach. Jede Slave antwortet nur dann, wenn er dazu vom Master aufgefordert wird. Damit wird das Protokoll sehr einfach. Von IIC über lange Strecken halte ich persönlich nichts, auch wenn einige Leute das schon erfolgreich praktiziert haben. IIC ist von der Grundidee ein geräteinterner Bus. Gruß, Stefan
Ralf G. schrieb: > Peter schrieb: >> Alle hören mit und >> das erste Byte gibt an, welcher Controller adressiert ist. > > Gibt's sozusagen fertig. Nennt sich "Multi-processor Communication > Mode". Oder LIN (https://de.wikipedia.org/wiki/Local_Interconnect_Network)
Stefan schrieb: > Von IIC über lange Strecken halte ich persönlich nichts, auch wenn > einige Leute das schon erfolgreich praktiziert haben. IIC ist von der > Grundidee ein geräteinterner Bus. sehe ich auch so, nur wer hat I2C gesagt? ich sagte 1w oder onewire.
Roland Praml schrieb: > RS232 ist nur point to point fähig. Peter schrieb: > Es sollen Mikrocontroller angeschlossen werden (ATmega oder ATtiny). Die > sollen dann vom Master alle paar Sekunden ein paar Dutzend Bytes > erhalten (Übetragungsrate wenige kHz), um dann einige wenige Daten > wieder an den Master zurück zu senden. Peter schrieb: > Ich denke, an Leitungen muss ich nicht sparen (abgesehen von den SPI > CS). Netzwerk(Leitungen) ginge auch, ein Cat Kabel hat etliche Adern und geht auch seriell. (Alternative 32 oder mehrpolige Telefonkabel 10m sind ja nicht lang und 20 Teilnehmer brauchen nur 40 Adern) Entweder jeder ATmega oder Tiny bekommt seine 2(3) RS232 Strippen mit Pegelwandler V24 oder alle arbeiten auf einen Netwerkserver Sharkoon http://www.sharkoon.com/?q=de/node/1797 http://www.sharkoon.com/?q=de/node/1239 an USB RS232 Umsetzer, so kann ich den abgesetzten Webserver (Atmel) auch resetten oder umprogrammieren. Mehrfach RS232 Karten gibt es auch zu Hauf oder genügend USB RS232 Umsetzer anschliessen.
:
Bearbeitet durch User
Peter schrieb: > Frank K. schrieb: >> Wieso ist CAN zu teuer? > > Nicht zu teuer, aber aufgrund der ATmega/ATtiny fehlt die Hardware. Die musst Du ja nicht nehmen, wenn sie für dieses Projekt nicht geeignet sind. Die (leicht verfügbaren) Alternativen habe ich Dir ja aufgezeigt. fchk
Hallo Peter, deine Aufgabe schreit förmlich nach RS485. Das ist ein Halb-Duplex Master-Slave-System, das problemlos funktioniert (bis 10MBaud, bis 1,2km). Da braucht es keine "CS-Leitung". Es gibt die beiden Leitungen D+ und D-, die werden einfach zu allen Teilnemern durchgeschleift. In Ruhe ist der Master Sender, alle Slaves sind Empfänger. Der Datenaustausch geht immer vom Master aus, er adressiert den Empfänger. Wenn der Master Daten anfordert weiß er das und schaltet um auf Empfang, der adressierte Slave schaltet auf senden. CAN ist ein Multimaster-System, lauter gleichberechtigte Teilnehmer. Da darf jeder senden, wann es ihm wichtig erscheint. Es können auch zwei Nachrichten gleichzeitig auf den Bus gelangen (Kollision) und dann müssen Mechanismen her, damit umzugehen. LIN hat Vorteile im Auto, die +12V und die Rückleitung sind dort überall vorhanden. Bei deinen µC mußt du die Bedingungen erst schaffen und hast dann trotzdem ein störanfälligeres System als RS485. Aus meiner Sicht ist hier RS485 am geeignetsten. Mache dich einfach über die vorgeschlagenen Feldbusse schlau (Wikipedia) und entscheide dann selbst, nach deinen Bedingungen. Gruß. Tom
Von Intel gibt es ein Protokoll, dass sich "Multiprocessor communication" schimpft. Im Prinzip ist es ein Multimaster Serial Bus und funktioniert so: - Alle Teilnehmer stellen ihren UART auf Empfangen - Ein Master startet das Senden indem er 9(!)Bit sendet (z.B. die ID des Teilnehmers) - Das führt auf den Slaves zu einem Framing-Error-Interrupt und jeder Slave kann anhand der ID feststellen ob er angesprochen wurde. - Wenn nein, verlässt er den Interrupthandler und wartet auf das nächste 9Bit Datum. - Wenn ja sendet/empfängt er 8Bit Datenpakete Mit RS485 Treibern geht das auch über längere Strecken. Ich habe das früher mal in einer industriellen Produktionsmaschine eingesetzt. Dort hatten wir ca. 20 Teilnehmer auf ca. 5m verteilt in der Anlage sitzen. Der Bus-Kabelstrang dürfe mehr als 10m lang gewesen sein. Man braucht noch ein Protokoll, das z.B. regelt, wie lange die Datenpakete sind und das verhindert, dass zwei Master gleichzeitig senden wollen. Manche UARTs haben einen gewissen Support für dieses Protokoll und können z.B. die 9Bit-Adresse schon in HW vergleichen und nur bei Übereinstimmung überhaupt einen Interrupt auslösen. z.B. 8051 UART: The next bit, SM2, is a flag for "Multiprocessor communication." Generally, whenever a byte has been received the 8051 will set the "RI" (Receive Interrupt) flag. This lets the program know that a byte has been received and that it needs to be processed. However, when SM2 is set the "RI" flag will only be triggered if the 9th bit received was a "1". That is to say, if SM2 is set and a byte is received whose 9th bit is clear, the RI flag will never be set. This can be useful in certain advanced serial applications. For now it is safe to say that you will almost always want to clear this bit so that the flag is set upon reception of any character. Im Netz findet sich einiges darüber.
Tom Amann schrieb: > CAN ist ein Multimaster-System, lauter gleichberechtigte Teilnehmer. Da > darf jeder senden, wann es ihm wichtig erscheint. Es können auch zwei > Nachrichten gleichzeitig auf den Bus gelangen (Kollision) und dann > müssen Mechanismen her, damit umzugehen. Wie man CAN nutzt, ist ja jedem selbst überlassen. Man muß es ja nicht als Multimastersystem nutzen. Und Kollisionen sind schon im Protokoll geregelt. Das ist ja gerade das Schöne.
Angehängte Dateien:
-
pic18can.sch.png
12 KB -
pic18can.brd.png
15 KB
Und so könnte ein CAN-Knoten aussehen. fchk
RS485 schrieb: > - Ein Master startet das Senden indem er 9(!)Bit sendet (z.B. die ID des > Teilnehmers) Nein, er sendet 11 Bits und alle Anderen senden auch immer 11 Bits! Neben Start, Stopp, 8 x Datenbits wird das 9. Bit als '1' übertragen, um die gesendeten 8 Bits als Adresse auszuweisen UND bei allen angeschlossenen Empfängern einen Interrupt auszulösen. Bleibt das 9. Bit auf '0' handelt es sich um normale Daten. Auf das Multiprozessor-Protokoll hatte ich schon um Uhr 10:00 hingewiesen; es sollte allgemein bekannt sein ;-)
Peter schrieb: > Nicht zu teuer, aber aufgrund der ATmega/ATtiny fehlt die Hardware. Wie jetzt? ATMega16M1 - 32 Pin TQFP.
grundschüler schrieb: > 1 wire, wie ds1820 Hättest Du den Thread komplett gelesen, hättest Du erkannt, dass OneWire schon lange vom Tisch ist. Der TO will eigene Clients an den Bus hängen und keinen DS1820 oder irgendeine andere fertige OneWire-Hardware.
:
Bearbeitet durch Moderator
Man kann auch CAN-Transceiver (MCP2551) an die UART hängen. Das Protokoll ist dann wie bei RS-485, hat aber den Vorteil, man braucht keine Richtungsumschaltung und es gibt keine Kollisionen (hoher Stromverbrauch, wenn 2 Transceiver gegeneinander treiben).
Thread beobachten
Seitenaufteilung abschalten
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.