mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Protokoll für RS485


Autor: thomasb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo leute,

hat jemand schon ein einfaches protokoll für RS485 bus geschrieben? ich
muß 3-4 avr's auf einen bus hängen. falls jemand schon dies
programmiert hat, brauche ich nicht das rad neu zu erfinden ... :-)

ansonsten muß ich mich wohl dahinterklemmen und dann natürlich hier
posten :-)

schöne grüße,
thomas

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Firma Kramer-Electronics hat sich mal das "Protocol 2000" für die
Steuerung ihrer AV-Kreuzschienen ausgedacht. Es besteht aus 4 Byte...
Du willst aber wohl eher eine Muli-Proz-Kommunikation aufbauen, wo man
vielleicht 9Bit benutzt...

Autor: thomasb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo rahul,

gibt's das protokoll "lizenzfrei"? meine controller plaudern nicht
wirklich permanent miteinandner ...

gruß,
thomas

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ICh weiß ja nicht, ob das wirklich ein Protokoll für dich ist.
www.kramerelectronics.com
Welche Art von und wie viele Daten musst du denn übertragen?
Ein einfaches selbst geschriebenes Protokoll ist vielleicht sinnvoller
als ein "gekauftes".

Autor: Nick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum nimmst Du nicht ganz einfach den UART mit RS232 oder noch simpler
I2C mit dem TWI?
SPI geht auch, braucht aber ein paar Leitungen mehr.

Autor: Kjion (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich hab für meinem Laufroboter ein Protokoll geschrieben.
( http://www.kreatives-chaos.com/index.php?seite=laufroboter )
Es gibt demnächst auch noch mehr Informationen dazu auf der Seite. Ich
muss ihr allerdings erstmal für den Landeswettbewerb fit machen ;)

Schreib mir einfach mal ne Email...

MfG Kjion

Autor: thomasb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi kjion,

das mit dem snap ist ein heißer tip ...
das werde ich mir genauer anschauen ...

thanx,
thomas

Autor: thomasb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@nick:

ich muß längere strecken in einem wohnmobil überbrücken, da geht sich
rs232 nicht aus. außerdem verwende ich den uart, nur mit einem rs485
converter vorn drauf ...

dieses modell hat auch den vorteil, daß ich (mit einem pegelwandler)
mit dem notebook über die rs232 schnittstelle mitsniffen kann, wie sich
die controller unterhalten.

gruß,
thomas

Autor: Frankl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RS232 mit 9800 Baud schafft man schon 50 Meter mit gutem geschirmten
Kabel.

Autor: thomasb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@frankl:

soveit ich informiert bin, ist rs232 eine punkt-zu-punkt verbindung
zwischen zwei teilnehmern, bei rs485 können wesentlich mehr teilnehmer
am selben bus hängen.

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
um genau zu sein passen an den RS485-Bus 32 Teilnehmer...
Was willst du denn überhaupt übertragen?
So wie ich das sehe, hast Du Messwerte (Talker) von irgendwelchen
Messfühlern (Wasserstand, Batterieleistung, Chemie-Klofüllstand...) und
dann wirst du auch noch ein paar Listener haben, die irgendwelche
Befehle empfangen (Licht?)
Da würde es sich empfehlen, die 9Bit-Übertragung zu realisieren, wobei
das erste Byte eine Adresse überträgt, das zweite vielleicht einen
Befehl, dann die Länge der Daten und dann entsprechend der angegeben
Länge die Daten. Und vielleicht noch eine Prüfsumme.
Als Rückmeldung kann man dann NAK für nicht kompletten Empfang oder ACK
für gültigen Empfang geben. Bei NAK wird die Übertragung wiederholt;
bei ACK ist alles i.O. Beide Befehle sind 1Byte lang und sind im ASCII
zu finden.
Es gibt eine ganze Menge Protokolle, die aber meistens für irgendwelche
speziellen Aufgaben vorgesehen sind.
Baue dir doch dein eigenes, oder willst du noch mit der Aussenwelt in
Verbindung treten? Dann würde ich CAN oder Ethernet vorschlagen.
Gruß Rahul

Autor: thomasb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@rahul:

danke für die info. es werden nur die avr's untereinander
kommunizieren. ich werde mit das protokoll selber anpassen, nur ist es
einfacher von einem bestehenden gerüst wegzuarbeiten. so, wie du das
beschrieben hast, so stelle ich mir die kommunikation auch vor ... hast
du vielleicht links zu der 9bit-übertragung bei der hand? wäre super.

danke,
thomas

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

bei Multimaster-RS485 bleibt eigentlich nur CSMA/CD wie es bei Ethernet
verwendet wird.

Zusätzlich noch etwas "erfinden" was der Packetstruktur von Ethernet
sehr ähnlich ist und man macht eigentlich nix verkehrt.

Matthias

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias:
das mit dem Ethernet-Protokoll ist dann interessant, wenn man auch
einen Controller hat, der sich um den ganzen Spaß kümmern kann.
Bei Thomas' Anwendung ist die Kommunikation nur ein Mittel zum Zweck.
Es wird sich dabei vermutlich um gelegentlichen Datenaustausch handeln,
indem ein Master (im Cockpit / Bordcomputer) irgendwelche Slaves
gelegentlich nach ihrem Status abfragt bzw. Slaves dem Master
gelegentlich ihren Status zukommen lassen.

@Thomas:
Ich habe mal im Mikrocontroller-Kochbuch von Andreas Roth etwas darüber
gelesen.
Links dazu habe ich noch nicht gefunden, aber im Datenblatt zum
ATmega162 steht eine kurze Beschreibung. Man kann die USART so
konfigurieren, dass das 9. Bit kenntlich macht, ob es sich um Daten
oder eine Adresse handelt.
Bei der Modelleisenbahn gibt es auch ein interessantes Protokoll, das
auf die Versorgungsspannung moduliert wird.
DMX bietet sich meiner Meinung nach nicht an, weil es sich dabei nur um
einen Master und viele Slaves (Listener) handelt.

Am besten drei AVR nehmen, jeweils einen DS75176 (Reichelt ~50
Cent?)und die drei auf einen Bus legen. Die beiden äusseren sollten
einen Terminierungswiderstand von 120Ohm zwischen Leitung A und B
bekommen.
Allen dreien die gleiche Applikation verpassen (LEDs ein,je nach
Taster) und allen eine andere Adresse...
Ich habe leider keine AVR rumliegen und mein lokaler Händler verlang 5
Euro für einen RS485-Transceiver, sonst würde ich das ausprobieren.

Autor: thomasb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@rahul:

danke für die hilfe. so ähnlich habe ich mir den vesuchsaufbau auch
vorgestellt. ich werde versuchen, das s.n.a.p protokoll zu
implementieren. da gibts auch einen art sniffer mit dem auch daten
gesendet/empfangen werden können, und der über die serielle
schnittstelle eines pc auf den bus gehängt werden kann. wenn es mir
gelingt (und von dem gehe ich aus :-)), das protokoll standardgemäß zu
implementieren, werde ich den source natürlich hier posten. für alle,
die das protokoll auch interresiert: http://www.hth.com/snap/

schöne grüße und besten dank an alle,
thomas

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

es muß ja nicht das Ethernet-Protokoll sein. Aber zumindest ist
CSMA/CD (Carrier Sense Multiple Access with Collision Detection) sehr
einfach mit den üblichen RS485-Chips zu implementieren. Man empfängt
einfach jedes gesendete Byte wieder selber und vergleicht es mit dem
gesendeten. Sind sie gleich -> weitersenden, ungleich -> zufällige Zeit
warten und nochmal.

Wenn man dann noch Datenpäckchen schnürt mit [Absender, Empfänger,
Länge, Daten, CRC] hat man im Prinzip das Ethernet-Protokoll schon
drin. Ethernet hört sich immer so toll an es ist aber von der
Protokollsicht sehr primitiv.

BTW:
10MBit Ethernet auf TP ist elektrisch nichts anderes als RS485.

Matthias

Autor: Suschman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf Koax Kabel wird doch bei Ethernet Manchester-Codierung benutzt.
Dachte auf TP wird das genauso gemacht, nicht RS232/485 like ??

Mfg Suschman

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

ich bezog mich auf das elektrische nicht auf die Kodierung ->
differentielle Übertragung.

Matthias

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer benutzt heute denn noch Koax-Verdrahtung? Naja, zumindest nicht mehr
für neue Anlagen...
Die Idee mit dem CSMA/CD ist doch ziemlich gut. Ich hab nur IEEE802
gesehen und dachte gleich an Manchester etc. Thomas wird den ganzen
Schnickschnack um das Protokoll brauchen. Die Kollisionsdetektion ist
ziemlich einfach und interessant.
Rahul

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Die Kollisionsdetektion ist ziemlich einfach"

Na, na.
Das ist aber wirklich nur ein Gerücht !

Die RS-485-Treiber sind sehr leistungsstark. Bei langen Leitungen
(hoher Widerstand) kann es daher passieren, daß sie gegeneinander
kämpfen und jeder gewinnt auf seiner Seite. Keiner kriegt also die
Kollision mit.

Man könnte höchstens CAN-Treiber nehmen (PCA80C251), die haben einen
dominanten Level, d.h. eine 0 setzt sich immer durch.
Und sobald einer eine 1 sendet, aber eine 0 liest, weiß er daß er
kollidiert ist.

Aber dann ist es noch lange nicht einfach, diese Kollision aufzulösen.
Wenn mehrere gleiche Baugruppen kollidieren, ist nämlich die Gefahr
groß, daß sie auch versuchen zur gleichen Zeit nochmal zu senden,
wieder kollidieren usw. usw. bis zum Sankt-Nimmerleins-Tag.


Das einfachste Protokoll ist daher immer noch der Single-Master, der
zyklisch alle Slaves fragt, ob sie was zu sagen haben.
Und dann ist für den adressierten Slave ein Zeitfenster (z.B. 10ms)
offen, in dem nur er alleine senden darf.


Peter

Autor: thomasb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi,
ich habe noch eine idee zur kollision: da jeder avr eine eigene adresse
hat (destination im paket) - könnte er ja diese adresse zur erzeugung
der pause bei einer kollision hernehmen. somit dürften eigentlich die
bereits kollidierten nach dem ablauf der zeit nicht wieder kollidieren
...
außerdem sollte der absender auf ein ack des empfänger innerhalb einer
zeit warten - kommt es nicht, sendet er sein paket nochmals ...

das ganze ist eine interessante diskussion - ich bin schon gespannt,
wie meine kommunktiaon laufen wird :-)

thomas

Autor: leo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Idee mit der (durch Adressierung) unterschiedlichen Wartezeit ist
zwar ein guter Weg um die "wiederholte" Kollision zu unterbinden,
löst aber nicht das Problem der unerkannten Kollision.
So wie peter schon schrieb sind die RS-Treiber so stromstark (vertragen
in der Regel ja auch Kurzschlüsse) daß sie auf jedem Kabelende
"richtige" Daten sehen.
Eine (wenn auch nicht sehr "schöne") Möglichkeit wäre eventuell nicht
per TX sondern über TX-Enable zu senden. Damit wird nur ein Pegel
"stromstark" auf die Leitung gelegt (den anderen müßte man halt
pull-upen bzw. -downen) und die Kollision müßte auf beiden Seiten der
Leitung dedektierbar sein.

Für Multimaster-Systeme halte ich CAN (als Transportlayer, das
Protokoll kann man ja vereinfachen) für sinnvoller. Wenn man den
CAN-Vorteil der Kollisionerkennung auf Bit-Ebene auf Byte-Fehler
ausdehnt hält sich auch der Programmieraufwand in Grenzen (dafür können
dann aber auch destruktive Kollisionen auftreten).

grüße leo

Autor: thomasb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn der absender auf eine ack meldung wartet, müsste es eigentlich auch
klappen. nehmen wir an, wir senden und es tritt eine kollision auf, die
wir nicht erkennen. dann wird der empfänger das paket auch nicht lesen
können, bzw. die prüfziffer wird falsch sein ...
kann der empfänger nun da paket nicht lesen, wird er auch keine
ack-meldung retournieren können ... somit wird der absender nach einer
gewissen zeit das paket nochmals senden (die zeit wird aus der
"station id" berechnet).

wäre das nicht eine idee?

gruß,
thomas

Autor: Mario B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@matthias

Hallo Matthias du hast oben geschrieben
"....es muß ja nicht das Ethernet-Protokoll sein. Aber zumindest
ist
CSMA/CD (Carrier Sense Multiple Access with Collision Detection) sehr
einfach mit den üblichen RS485-Chips zu implementieren. Man empfängt
einfach jedes gesendete Byte wieder selber und vergleicht es mit dem
gesendeten. Sind sie gleich -> weitersenden, ungleich -> zufällige
Zeit
warten und nochmal."

Wie soll ich das gesendete Byte wieder empfangen. Hab nur eine
Schnittstelle??

Benötige das für ein Projekt dringend.
Kannst du mir das etwas genauer erklären.

THX
Mario

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

die üblichen RS485 Treiber (MAX485) haben zwei Pins um den Empfänger
und den Sender einzuschalten. Du schaltest jetzt einfach den Empänger
immer ein und den Sender wenn du senden willst. RS485 kann ja nur
Halbduplex.

Matthias

Autor: Mario B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias

Ist das so richtig ???

Schritte im Programm:
1.der max485 wird auf empfangen eingestellt
2.Habe 1 byte zum versenden
3.der max485 wird auf empfangen und auf senden eingestellt
4.sende das byte nach Rx
5.empange das byte über Tx
6.der max485 wird wieder nur auf empfangen eingestellt

Das was über Rx gegangen ist über Tx wieder zurückgekommen.
Tx würde also ein verändertes bit empfangen falls ein anderer
Teilnehmer zur selben Zeit sendet ???

mario

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
genau!

Autor: Neubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hey,

- hat jemand von euch die sache mit S.N.A.P weiterverfolgt
- möchte vielleicht dieses ScalableNodeAddressProtocol in meinen atmega
einbinden

-> um das rad nicht neu erfinden zu müssen : hat jemand vielleicht
einen source dazu (in c wäre fein :)  ?!?!)



neubi

Autor: Dirk E. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau mal hier
Beitrag "S.N.A.P.-Protokoll in winAVR"

läuft zu mindestens bei mir.

Gruß
Dirk

Autor: rene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab mal ein Master Slave Protokoll geschrieben :
http://www.ibrtses.com/embedded/shortmsgprotocol.html
Master Slave bedeutet die kommunikation wird immer vom selben initiiert, 
sonst laeuft nichts.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es hier einen Preis zu gewinnen, wenn man die älteste Leiche 
ausbuddelt?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.