Master Slave Verbindung mit AVR2313 und 485-Bustreibern ?

[Juergen151]

Hallo Richard,

Deine Frage versteh ich jetzt nicht ganz die Schaltung hab ich doch als jpg angehängt, ich sende Zeichen über den RS 485. (bzw. weiter oben meine Website zu dem Thema)

Mfg Jürgen

[Vitis]

tjaha ... Du hast dann zwei Busmaster dran wenn ich das richtig verstanden habe ... da wirds schon deutlich komplexer. Du müsstest dann nämlich Deinen Mastern beibringen wann der jeweilige senden darf.
Damit hat Du ziemlich exakt die Schwachstelle bei der 485-kommunikation erwischt.
Mit nem einfachen Protokoll ... ich sende-du machst wird das dann nämlich nix.
Zum Einen müsstest du beim Aktor erfassen wenn ne Kollision stattfindet, sprich beide Master senden ... das geht noch recht einfach über das FE-Flag (framing error), Dann noch ne Checksumme verarbeiten für Dein Protokoll und natürlich n Acknowledge vom Slave verwerten beim Master, sprich der Slave müsste noch antworten (ja, ich hab den Befehl verstanden bzw. Ich hab den Befehl nicht verstanden) und dieses ACK auch beim Master verarbeiten um ggf. nochmals den Befehl zu senden ...
Im Idealfall müsstest Du den Mastern noch n Token geben, wann wer jetzt den Bus belegen darf ...

Alles in allem keine einfache geschichte an der sich schon viele die Zähne ausgebissen haben.

[Richard]

Hallo Richard,

Deine Frage versteh ich jetzt nicht ganz die Schaltung hab ich doch als jpg angehängt, ich sende Zeichen über den RS 485. (bzw. weiter oben meine Website zu dem Thema)

Mfg Jürgen

Ich meinte nicht die Schaltung, eher die Software. Du brauchst ja ein
Protokoll um den Bustreiber im richtigen Moment von Lesen auf
Schreiben umzuschalten. Siehe auch die Post von Vitis.

Gruß Richard

[Juergen151]

Hallo Vitis & Richard,

ja das mit dem Umschalten von Senden auf Empfangen hatte ich ganz vergessen, so ist es halt wenn man sich nur alle 6 Monate mit damit beschäftigt.

Ein Protokoll wollte ich unbedingt vermeiden um das Ganze nicht unnötig kompliziert zu machen, mit einem Sender + einem Empfänger hats ja bisher auch wunderbar funktioniert.

Ich hab mir den Code des Senders jetzt schon mal angesehen und abgeändert für Umschaltung Senden/Empfangen, bin aber noch nicht dazu gekommen das ganze zu probieren.

Ich meine aber es sollte funktionieren, wenn man davon ausgeht das verschiedene Taster nicht gleichzeitig gedrückt werden, obwohl wenn man bedenkt wie kurz diese Zeiten sind wird man das wohl kaum schaffen genau gleichzeitig zu drücken.

Wie seht Ihr das ist das so lauffähig ?

Mfg Jürgen

'Sensor
$regfile = "attiny2313.dat"
$crystal = 3579545
$baud = 4800
Portb = &B11111111
Portd.2 = 0

$hwstack = 32
$swstack = 10
$framesize = 40

Config Print = Portd.2 , Mode = Set
Config Pind.2 = Output

Config Debounce = 30

Waitms 300


Do
Debounce Pinb.0 , 0 , Schalter1 , Sub
Debounce Pinb.1 , 0 , Schalter2 , Sub
Debounce Pinb.2 , 0 , Schalter3 , Sub
Debounce Pinb.3 , 0 , Schalter4 , Sub
Debounce Pinb.4 , 0 , Schalter5 , Sub
Debounce Pinb.5 , 0 , Schalter6 , Sub
Debounce Pinb.6 , 0 , Schalter7 , Sub
Debounce Pinb.7 , 0 , Schalter8 , Sub
Loop


Schalter1:
Portd.2 = 1
Waitms 50
Print "!10";
Waitms 50
Portd.2 = 0
Waitms 50
Return

Schalter2:
Portd.2 = 1
Waitms 50
Print "!11";
Waitms 50
Portd.2 = 0
Waitms 50
Return

Schalter3:
Portd.2 = 1
Waitms 50
Print "!12";
Waitms 50
Portd.2 = 0
Waitms 50
Return

Schalter4:
Portd.2 = 1
Waitms 50
Print "!13";
Waitms 50
Portd.2 = 0
Waitms 50
Return

Schalter5:
Portd.2 = 1
Waitms 50
Print "!14";
Waitms 50
Portd.2 = 0
Waitms 50
Return

Schalter6:
Portd.2 = 1
Waitms 50
Print "!15";
Waitms 50
Portd.2 = 0
Waitms 50
Return

Schalter7:
Portd.2 = 1
Waitms 50
Print "!16";
Waitms 50
Portd.2 = 0
Waitms 50
Return

Schalter8:
Portd.2 = 1
Waitms 50
Print "!17";
Waitms 50
Portd.2 = 0
Waitms 50
Return


End

[Juergen151]

Hallo Vitis, Richard,

ich habs nun ausführlich getestet, vergesst meinen Code vom letzten Posting, es ist wohl tatsächlich so wenn ein Dritter Bus-Teilnehmer dran ist gehts nicht ohne Software-Protokoll, ich war bisher immer der Meinung das der RS485 Chip dies bereits hardwaremäßig tut.

Wie schwierig ist es wohl das Protokoll in meinen biherigen Code einzufügen ? Geht das überhaupt mit Bascom ? Vitis vielleicht kannst Du das mal probieren, wäre nett ! Oder gerne auch ein anderer Bascom-Experte !

Mfg Jürgen

[Richard]

moin min

Grht relativ einfach. Alle Teilnehmer empfangen per IRQ, damit
nebenbei auch aqndere Aufgaben möglich sind.Dann sendet der
Master eine Auffrderung z.B. in der Art..
: Start.
#ID = Adresse des Slaves
> = für Sendeauforderung
< = für Leseaufforderung
xyz = Anzahl der folgenden Daten oder Befehls Bytes
CRC Checksumme
$00 = nack senden wenn CRC OK
.................................................. ...
CRC nicht Ok nach ? Zeit goto start
Else
xyz Daten vom Slave empfangen und verarbeiten.

Für den IRQ Empfang und auch CRC bilden/auswerten
gibt es in Bascom Befehle musst mal die Beispiele
unter samples durchsuchen und oder in der Hilfe
nach on interrupt und CRC suchen. Alle Empfangen alles,
inorieren aber alles wenn #ID nicht passt bis ein $00
kommt. Dann geht es von vorne los.

Also auch die Slaves müssen beim Antworten immer erst
ein #ID senden damit die Daten an der richtigen Stelle
ausgewertet werden, die Routine ist quasie bei allen gleich.

Die jeweilige ID sollte im EE.Prom liegen (achtung, die erste
EE-prom Speicherstelle kann beim Rest oder Einschalten
verloren gehen) also besser eine höhere wählen.

Viel Spass, Richard

[Vitis]

Wenn DU ne Hardwarelösung willst solltest Du Dir mal die CAN-Bus Bausteine anschauen, die machen sowas, bei 485 muss man sich um sowas selber kümmern. RS485 beschreibt nur die elektrische Seite der Übertragung, sonst nix.

Die Umwandlung Deines Codes ist sogar noch verhältnismäßig überschaubar.
Zum Einen solltest Du Dir mal das UCSRA Register anschauen, bzw. das TXC-Flag, damit kann man recht elegant die Umschaltung von Senden auf Empfangen lösen ohne Wait Befehle.
Dann noch CRC (gibts auch als Bascom Befehl) und n Array als Overlay über Deinen Sende- / Empfangsstring.
Dann noch das FE-Flag für den Empfang und n Ack vom Slave als Antwort bei verstandenem Befehl, bzw. Nack. Dann noch n Timeout beim Master für Befehle die ins Leere gegangen sind und gut ist.

[Richard]

Wenn DU ne Hardwarelösung willst solltest Du Dir mal die CAN-Bus Bausteine anschauen, die machen sowas,

G***** davon wollte ich jetzt nicht auch noch anfangen, CAN ist zuwar
etwas super feines aber nicht umsonst kaum im Hobby Bereich zu
finden....recht kompliziert. Weshalb Amtel auch AVR`s mit Hardware
CAN zur Verfügung stellt. Was die jetzt kosten? Aber wenn jemand seine
Wohnung komplett inklusive Musikübertragung Verkabeln will.....
Der sollte sich überlegen ob sich das nicht doch rechnet.

Da CAN aus dem Automobielbereich stammt und z.B. auch Sicherheits-
Bereiche wie ABS u.s.w. abdeckt. Sind Preislich kaum Grenzen gesetzt.

Gruß Richard

[Vitis]

nee, da hast Du mich falsch verstanden, da gibts
entsprechende Bausteine dafür, z.B.

MCP2515
http://www.datasheetcatalog.org/data...7dqexxwhcy.pdf

[Richard]

nee, da hast Du mich falsch verstanden, da gibts
entsprechende Bausteine dafür, z.B.

MCP2515
http://www.datasheetcatalog.org/data...7dqexxwhcy.pdf

Hmm, wenn ich mir so Threads (auch in anderen Foren) darüber anschaue
hatte ich den Eindruck das auch mit den IC`s etliche Probleme aufgetreten
sind?

Ich hatte einmal weil mir die Adressierung und Prioritäten verwaltung
so gut gefallen hat etwas ähnlichen aufgebaut. Einfach die TXD/RXD
noch auf 2 zusäzliche Pin`s gelegt und damit überprüft ob das gerade
gesendete Byte von einen Anderen Teilnehmer über schrieben worden ist.

Dazu muss die Datenleitung natürlich über einen Pullup an + Liegen
und mittels OC geschaltet werden. Sonst brennt etwas weg....

Allerdings ward das damals ein PIC und in Assembler realisiert.

Gruß Richard