Protokoll für RS485

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...

hallo rahul,

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

gruß,
thomas

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".

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.

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

hi kjion,

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

thanx,
thomas

@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

RS232 mit 9800 Baud schafft man schon 50 Meter mit gutem geschirmten
Kabel.

@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.

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

@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

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

@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.

@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

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

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

Mfg Suschman

Hi

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

Matthias

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

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

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

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

@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

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

@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

genau!

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

Schau mal hier
Beitrag "S.N.A.P.-Protokoll in winAVR"

läuft zu mindestens bei mir.

Gruß
Dirk

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.

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