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
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?
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.
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.
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.
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:> 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
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
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/1797http://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.
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.
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 ;-)
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.
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).
