RS 485 Master - Slave in Bascom???

Hallo

wie kann ich einen Master und einen Slave mit RS485 programmieren?
mit Print kann ich vom Master aus senden denke ich. Doch wie kann der Slave dies empfangen. Gibt es da irgendwo etwas nachzulesen? oder kann mir dies einer von euch erklären?

Hallo,
Du kanst Dir mal die Befehle Inkey, Input, Inputbin usw. anschauen,
damit kann man die Zeichen die über UART reinkommen abfragen.

Zum RS485 Protokoll allgemein hatte ich ja auch schon einige Fragen.

Mittlerweile habe ich wohl hingenommen dass RS485 kein definiertes Protokoll hat, sondern "nur" die Hardware bescheiben soll.

Wo kann man Beispielprotokolle für einen Multislave Bus (Master Adr. 1 bis ca 31 Geräte also 30 Slaves) bekommen?

Am liebsten wären mir Praxisbeisiele und deren Umsetzung mit Bascom.

Hallo darwin.nuernberg,

schau mal nach SNAP-Protokoll. Damit kann man sehr zuverlässig eine
Master- Slave-Anwendung schreiben. Das Protokoll ist einfach zu imple-
mentieren und ziemlich stabil.

mfg

AVRWalli

hallo,
ich sitze auch shcon seit langer Zeit an diesen Problemen. Ich bin jetzt soweit, dass ich ein einwandfrei funktionierendes Multi-Slave System aufgebaut habe.

Ich habe vor mein Projekt noch zu dokumentieren, aber im Moment bin ich leider etwas im Abistress und deswegen hab ich keine Zeit. Sobald ich hier fertig bin (3-4 wochen) werd ich mich mal dransetzen.

Ein Protokoll, welches den Datenverkehr steuert hab ich auch schon entwickelt.

Falls es euch interessiert, meldet euch mal und ich werde euch dann infos zukommen lassen. Ich habe übrigens bisher auch alles in Bascom geschrieben. Wollte schon immer mal eine Lib für RS485 entwerfen, habe leider nur zu wenig ERfahrung in ASM.

Also seit unbesorgt, wer Geduld hat kann Infos bekommen.

Gruß
Baui

scha doch mal nach Profibus,
der verwendet den RS485 hardwaremäßig.
wenn du das dann in bascom implementierst haste auch gleich profibus kompatibles system

@Baui
Geduld habe ich Viiiiieeeel.
Interresse noch Meeeeehr!

Speziell da Du scheinbar mit Protokoll und Hardware zusammen eine Komplettlösung liefern könntest?

Nicht nur die Einen, die von der Software nur die theoretische Ahnung haben, aber praktisch noch nie damit gearbeitet haben.
Oder die anderen Die nur die Hardware zusammenschrauben sich aber um die Software nicht kümmern.

@AVRWalli

Das SNAP scheint mehr an IP angebunden zu sein.
Irgendwas ohne das OSI-7 Schichten Modell (welches ich sowiso nie so richtig gerafft habe).
Alles was ich darüber (zunächst) gefunden habe scheint eine Anbindung in bestehende Netzwerke zu priorisieren.

http://www.kreatives-chaos.com/index.php?seite=snap
http://www.itwissen.info/?id=31&ano=01-003412

Sicherlich gibt es da eine entsprechende Adaption.

Eín bisschen Theorie und die dazugehörige Praxis,
verbunden mit der Hardware-Realisation wäre mir sehr lieb.

Hallo ich habs mit einem Beispielprogramm hinbekommen ein String zu übertragen. Doch wenn ich nun ein Byte senden will funktioniert das nicht. was hab ich da falsch gemacht?

Code:

$regfile = "m32def.dat" $crystal = 16000000 $baud = 19200 Config Portb = Input Config Portd = Output Rs485 Alias Portd.2 Rs485 = 1 Dim A As Byte A = 123 Cls ' Clear the LCD display Cursor Off Do Print A Wait 1 Loop End

Code:

$regfile = "m32def.dat" $crystal = 16000000 $baud = 19200 Config Lcdpin = Pin , Db4 = Portc.5 , Db5 = Portc.2 , Db6 = Portc.4 , Db7 = Portc.3 , E = Portc.7 , Rs = Portc.6 Config Lcd = 20 * 4 Config Portb = Input Config Portd = Output Rs485 Alias Portd.2 Rs485 = 0 Dim Test As Byte Cls ' Clear the LCD display Cursor Off Do Inputbin Test Locate 1 , 1 Lcd Test Loop End

wie macht man das dann überhaupt mit den Adressen wenn man mehrere Slaves hat?

inputbin?

ich habs mit waitkey gemacht, ansonsten identischer Programmablauf.

Mit den Adressen für diverse Slaves ists etwas kniffelig.
Du brauchst ein Übertragungsprotokoll.
Eine Startbedingung, dann Absender, dann Empfänger, dann Datenbytes
und die Endbedingung.
Jeder Busteilnehmer muß dann bei Datenempfang nachsehen
ob er mit der Zieladresse gemeint ist und wenn ja, die
in den Nutzdaten enthaltenen Anweisungen / Daten etc. ausführen,
dann schickt er das Ergebniss an den Absender zurück.
Da brauchts Struktur dafür.
Entweder du tüftelst Dir n eigenes Protokoll aus oder du
nimmst n gängiges Industrieprotokoll und adaptierst das.

das mit dem byte funktioniert noch nicht so richtig.
wie ist das denn mit dem Interrupt? Wann weis ein Slave dass der Master was will? muss ich da die INT auch noch miteinander verbinden? Der Profibus funktioniert ja auch ohne Interruptleitung. wie macht der das denn?

für was benötige ich denn eine Start und Stop Bedingung?
reicht das nicht, wenn ich ein byte sende mit der adresse und dann eins mit den Daten? eventuell noch ein
Kontrollbyte zurück.

Wo bekomme ich denn so ein Profibusprotokoll her. Ich habe bis jetzt noch keine Ahnung wie der Profibus arbeitet.

Hallo darwin.nuernberg,

die Leute im 2. Link meinen was anderes.
Hier mal ein kleines Beispiel, habe ich mal im Web gefunden:

Code:

' ' -----[ Title ]------------------------------------------------------ ' ' File......: SNAP-IO.BAS ' Purpose...: Turns LEDs on and off ' Author....: Christer Johansson ' Version...: 1.01 ' Started...: 980503 ' Updated...: 980918 ' Modified..: 991229 by Claus Kuehnel ' -----[ Program Description ]---------------------------------------- ' ' This program shows how to implement the S.N.A.P protocol in ' BASCOM-AVR and is an simple example to turn LEDs ON or OFF. ' This example uses 16-bit CRC-CCITT as error detection method which ' gives secure data transfer. ' ' The packet structure is defined in the received packets first two ' bytes (HDB2 and HDB1). The following packet structure is used. ' ' DD=01 - 1 Byte destination address ' SS=01 - 1 Byte source address ' PP=00 - No protocol specific flags ' AA=01 - Acknowledge is required ' D=0 - No Command Mode ' EEE=100 - 16-bit CRC-CCITT ' NNNN=0010 - 2 Byte data ' ' Overview of header definition bytes (HDB2 and HDB1) ' ' HDB2 HDB1 ' +-----------------+-----------------+ ' | D D S S P P A A | D E E E N N N N | ' +-----------------+-----------------+ ' ' $regfile = "m128def.dat" $crystal = 16000000 $baud = 19200 $hwstack = 128 $swstack = 128 $framesize = 128 ' -----[ Constants ]-------------------------------------------------- ' Const Preamble_x = &B01010101 ' Preamble byte Const Sbyte_x = &B01010100 ' Synchronisation byte Const Crcpoly = &H1021 ' CRC-CCITT Const Hdb2_x = &H52 Const Hdb1_x = &H48 Const Myaddress = 123 ' Node - Adresse ' -----[ Variables ]-------------------------------------------------- ' Dim Preamble As Byte ' Preamble byte Dim Sbyte As Byte ' Sync byte Dim Crc As Word ' CRC Word Dim Hdb1 As Byte ' Header Definition Byte 1 Dim Hdb2 As Byte ' Header Definition Byte 2 Dim Dab1 As Byte ' Für welche Node-ID ist das Paket Dim Sab1 As Byte ' Wer sendet das Paket Dim Db1 As Byte ' Paket Data Byte 1 Dim Db2 As Byte ' Paket Data Byte 2 Dim Db3 As Byte ' Paket Data Byte 3 Dim Db4 As Byte ' Paket Data Byte 4 Dim Db5 As Byte ' Paket Data Byte 5 Dim Db6 As Byte ' Paket Data Byte 6 Dim Db7 As Byte ' Paket Data Byte 7 Dim Db8 As Byte ' Paket Data Byte 8 Dim Crc2 As Byte ' Paket CRC Hi_Byte Dim Crc1 As Byte ' Paket CRC Lo_Byte Dim Temp1 As Byte ' Temporäre Variable Dim Temp2 As Byte ' Temporäre Variable Dim Tmpw1 As Word Dim Tmpw2 As Word Dim I As Integer Dim Ausgabe As String * 8 Dim Dummy As String * 1 ' -----[ Initialization ]--------------------------------------------- ' Config Portg = Output ' Portb ist output 'Portb = &HFF Preamble = Preamble_x Sbyte = Sbyte_x Ausgabe = " 123.5" '------[ Program ]---------------------------------------------------- ' Sound Portg.0 , 15000 , 15 _start: 'Temp1 = Waitkey() ' Warten auf Daten Temp1 = Inkey() ' Ist das empf. Zeichen das SYNC byte dann die nächsten 8 Byte ' vom Master lesen, sonst zurück zum Start If Temp1 <> Sbyte Then 'Portg.1 = 1 ' Irgendwas empfangen 'Printbin Temp1 Goto _start Else ' Get packet in binary mode Inputbin Hdb2 , Hdb1 , Dab1 , Sab1 , Db8 , Db7 , Db6 , Db5 , Db4 , Db3 , Db2 , Db1 , Crc2 , Crc1 Portg.2 = 1 ' Packet empfangen ' Packet header check routine ' ' Check HDB2 to see if MCU are capable to use the packet ' structure, if not goto Start If Hdb2 <> Hdb2_x Then Goto _start ' Check HDB1 to see if MCu are capable to use the packet ' structure, if not goto Start If Hdb1 <> Hdb1_x Then Goto _start ' Address check routine ' ' Check if this is the node addressed, if not goto Start If Dab1 <> Myaddress Then Goto _start ' Check CRC for all the received bytes Gosub Check_crc ' Check if there was any CRC errors, if so send NAK If Crc <> 0 Then Goto Nak ' No CRC errors in packet so check what to do. ' ' Associated Function (place it between +++ lines) '+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ' Portb = Db1 Sound Portg.0 , 10000 , 10 'BEEP If Db1 = 255 Then Portg.1 = 1 Else Portg.1 = 0 End If Dummy = Mid(ausgabe , 1 , 1) Db1 = Asc(dummy) Dummy = Mid(ausgabe , 2 , 1) Db2 = Asc(dummy) Dummy = Mid(ausgabe , 3 , 1) Db3 = Asc(dummy) Dummy = Mid(ausgabe , 4 , 1) Db4 = Asc(dummy) Dummy = Mid(ausgabe , 5 , 1) Db5 = Asc(dummy) Dummy = Mid(ausgabe , 6 , 1) Db6 = Asc(dummy) Dummy = Mid(ausgabe , 7 , 1) Db7 = Asc(dummy) Dummy = Mid(ausgabe , 8 , 1) Db8 = Asc(dummy) '+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ' Ack_: ' Send ACK (i.e tell master that packet was OK) ' Set ACKs bit in HDB2 (xxxxxx10) Hdb2 = Hdb2 Or &B00000010 Hdb2 = Hdb2 And &B11111110 Goto Send Nak: ' Send NAK (i.e tell master that packet was bad) ' Set ACK bits in HDB2 (xxxxxx11) Hdb2 = Hdb2 Or &B00000011 Goto Send Send: ' Swap SAB1 <-> DAB1 address bytes Temp2 = Sab1 Sab1 = Dab1 Dab1 = Temp2 ' Clear CRC variable Crc = 0 ' Put HDB2 in variable Tmp_Byte1 Temp1 = Hdb2 ' Calculate CRC Gosub Calc_crc ' Put HDB1 in variable Tmp_Byte1 Temp1 = Hdb1 ' Calculate CRC Gosub Calc_crc ' Put DAB1 in variable Tmp_Byte1 Temp1 = Dab1 ' Calculate CRC Gosub Calc_crc ' Put SAB1 in variable Tmp_Byte1 Temp1 = Sab1 ' Calculate CRC Gosub Calc_crc ' Put Data in variable Tmp_Byte 8 Temp1 = Db8 ' Calculate CRC Gosub Calc_crc ' Put Data in variable Tmp_Byte 7 Temp1 = Db7 ' Calculate CRC Gosub Calc_crc ' Put Data in variable Tmp_Byte 6 Temp1 = Db6 ' Calculate CRC Gosub Calc_crc ' Put Data in variable Tmp_Byte 5 Temp1 = Db5 ' Calculate CRC Gosub Calc_crc ' Put Data in variable Tmp_Byte 4 Temp1 = Db4 ' Calculate CRC Gosub Calc_crc ' Put Data in variable Tmp_Byte 3 Temp1 = Db3 ' Calculate CRC Gosub Calc_crc ' Put Data in variable Tmp_Byte 2 Temp1 = Db2 ' Calculate CRC Gosub Calc_crc ' Put Data in variable Tmp_Byte 1 Temp1 = Db1 ' Calculate CRC Gosub Calc_crc ' Move calculated Hi_CRC value to outgoing packet Crc2 = High(crc) ' Move calculated Lo_CRC value to outgoing packet Crc1 = Low(crc) ' Send packet to master, including the preamble and SYNC byte ' Print "Antwort" Printbin Preamble ; Sbyte_x ; Hdb2 ; Hdb1 ; Dab1 ; Sab1 Printbin Db8 ; Db7 ; Db6 ; Db5 ; Db4 ; Db3 ; Db2 ; Db1 Printbin Crc2 ; Crc1 ' Print "Ende" ' Give AVR time to shift out all bits before setting to Rx Waitms 50 ' Done, go back to Start and wait for a new packet Goto _start End If ' -----[ Subroutines ]------------------------------------------------ ' 'Soubroutine for checking all received bytes in packet Check_crc: Crc = 0 Temp1 = Hdb2 Gosub Calc_crc Temp1 = Hdb1 Gosub Calc_crc Temp1 = Dab1 Gosub Calc_crc Temp1 = Sab1 Gosub Calc_crc Temp1 = Db8 Gosub Calc_crc Temp1 = Db7 Gosub Calc_crc Temp1 = Db6 Gosub Calc_crc Temp1 = Db5 Gosub Calc_crc Temp1 = Db4 Gosub Calc_crc Temp1 = Db3 Gosub Calc_crc Temp1 = Db2 Gosub Calc_crc Temp1 = Db1 Gosub Calc_crc Temp1 = Crc2 Gosub Calc_crc Temp1 = Crc1 Gosub Calc_crc Return ' Subroutine for calculating CRC value in variable Tmp_Byte1 Calc_crc: Tmpw1 = Temp1 * 256 Crc = Tmpw1 Xor Crc For Temp2 = 0 To 7 If Crc.15 = 0 Then Goto Shift_only Tmpw2 = Crc * 2 Crc = Tmpw2 Xor Crcpoly Goto Nxt Shift_only: Crc = Crc * 2 Nxt: Next Return

Ich hoffe, Du kannst es gebrauchen.

mfg

AVRWalli

Das dürfte das geringste Problem sein.
Im Bus würde es einen "Master" geben,
der pollt alle Geräte an und fragt diese dabei ab.

Natürlich benötigt dann der "Master" die Kenntnis der Anzahl der Geräte im Bus und deren Adressen.

Außerdem muss der Master auch entsprechend handeln, falls ein "Slave"
mal ausfällt oder während eines TimeOut's nicht antwortet
Um das Poling zu diesem Gerät seltener bis gering auszuführen (m den speed im Bus nicht zu stark durch unnätiges warten auf Antwort auf ein minimum zu reduzieren. Und falls der Slave dann doch wieder aktiv wäre(evtl. war ja nur ein Stomausfall oder ähnliches der Fall), dann muss der Slave ja wieder mit eingebunden werden, also deher das Pollinng nicht gänzlich einstellen.

Das ganze könnte man dann noch ausbauen und einen Reserve Master zu etablieren, falls der primäre Master mal ausfällt.

So würde ich das dann machen.

Liste der Anhänge anzeigen (Anzahl: 1)

@ Warum Start und Endphrase:
Es gibt Protokolle fester Länge und variabler Länge.
Beispiel:
gegeben: Du verwendest Deinen Slave als einfachen AD-Wandler um einen
Messwert einzulesen. Der ADC des µC hat 10Bit Breite.
ist der Der Messwert kleiner als 255 würde es reichen ein Byte zu übertragen.
Bei einem größeren Messwert bräuchtest Du dann (von 255 bis 1024) zwei
Byte um das Messergebnis zu übertragen.
Eine Variante ist Du hängst an den Anfang des Übertragungsblocks eine
Mitteilung ob nur ein Byte oder zwei kommen,
oder du überträgst prinzipiell 2 Byte,
oder du schcikst ein Stopkondition, damit der Master weiß hier ist
die Nachricht zuende.

Beim Profibus sind so ziemlich alle Varianten auf einmal verwendet
je nach gewähltem Telegrammtyp.

http://www.profibus.com/imperia/md/c...002-German.pdf

Im Anhang schick ich mal die Profibus Dekodierungstabelle um zu zeigen
wie komplex eine Kommunikation so sein kann.

Aber wenn ich dies nun ohne Interruptleitung mache, dann muss der Master ständig den Bus abfragen. Und wenn dann zwei Slaves gleichzeitig senden, dann kommt am Master garnichts mehr an.

Zitat:

Zitat von Zeroeightfifteen

Aber wenn ich dies nun ohne Interruptleitung mache, dann muss der Master ständig den Bus abfragen. Und wenn dann zwei Slaves gleichzeitig senden, dann kommt am Master garnichts mehr an.

Na dann dürfen die Slaves eben erst "reden",
wenn sie gefragt werden.

Also eine Anfrage des Masters an einen bestimmten Slave,
welcher dann antwortet.

Sonst sollte "Stille" auf'm Bus sein.
Natürlich muss der Master dann ständig einen nach dem anderern abfragen und die Slaves müssen solange warten können bis diese an der Reihe sind (je nach anzahl der Slaves ein paar ms).

Zitat:

Zitat von darwin.nuernberg

Na dann dürfen die Slaves eben erst "reden",
wenn sie gefragt werden.

Hmm ... irgendwie ist sowas unpraktisch ... zumal der Master ja dann ständig pollen muss ....

Naja wie man es nimmt,
Klar ist der Master ständig beschäftigt,
ist ja auch eine von vielen anderen möglichkeiten.

Codetechnisch bestimmt ein geringerer Aufwand als andere Lösungen,
dafür muss der arme Kerl halt ein bisschen was tun :shock:.

Und ist auch eine Insellösung.

Zitat:

Zitat von darwin.nuernberg

Na dann dürfen die Slaves eben erst "reden",
wenn sie gefragt werden.

Also eine Anfrage des Masters an einen bestimmten Slave,
welcher dann antwortet.

ja aber wann weis ein Slave wann er gefragt wird. Dann muss ich im Slave ständig nachfragen ob er gefragt ist.

Jeder Slave bekommt eine eigene ID (per DIP-Schalter)
oder einmalig mittes Cable-Select beim einrichten des Busses,
oder fest im Programm implementiert.

Netzwerkkarten haben ja auch ihre MAC Identifikation
(MediaAccessControl, hat also nix mit Äpfeln zu tun)

So könnte das Kommunizieren aussehen:

Prozessorgeflüster:

Master "Hallo Du, Slave1?"
Slave1 "Ja, was ist denn?"
Master "Slave1, schalt doch mal Dein Licht ein."
Slave1 "OK, das licht ist an."

Master "Hallo Du, Slave2?"
Slave2 "Ja, was ist denn?"
Master "Slave2: willst Du mir was sagen?"
Slave2 "Nö, habe nix zu sagen"

Master "Hallo Du, Slave3?"
Slave3 "Ja, was ist denn?"
Master "Slave3: willst Du mir was sagen?"
Slave3 "Ja"
Master "Slave3: Was willst Du mir sagen?"
Slave3 "Bei Slave1 brennt das Licht."

Master "Hallo Du, Slave4?"
-keine Antwort-
Master "Hallo Du, Slave4?"
-keine Antwort-

Master "Hallo Du, Slave1?"
Slave1 "Ja, was ist denn?"
Master "Slave1, schalt doch mal Dein Licht aus."
Slave1 "OK, das licht ist aus. {wenn der mal wüsste was er will}"

...und eben solange bis der Stom ausfällt

Wenn da keine Freude bei diesem smalltalk aufkommt ;-)

...und es Sprach eine Stimme aus dem Chaos zu mir:
"Lächle und sei froh, denn es könnte schlimmer kommen."

...und ich lächelte,
...und ich war froh,
...
...
...und es kam schlimmer.

ja schon aber wann wann sagt denn der Slave "Ja was ist denn?" Der muss ja ständig den Bus abfragen damit er dies dann sagen kann oder nicht?

Ja sag mal,
red (schreib) ich in suaheli.

Logisch,
JAAAhAAA.
Rrrrrrichtig,
Corrrrrrekt

Schnellmerker.

(ein helles Köpfchen, bei Sonnenlicht)

ABER!

Auch der Slave muss ständig horchen ob der Master was von ihm will.
Da ja kein Interrupt ausgelöst wird,
kann der Slave nicht irgendwo in einer Schleife rumwuschteln,
sondern muss sich auch seiner Pflicht im klaren sein.

Das ganze ist nicht ganz zeitunkritisch.

Die Aufforderung vom Master liegt ja zum einen nicht ewig an
und sollte außerden auch noch während eines (noch zu definierenden) TimeOuts erfolgen,
sonst "Quasselt" der Slave ja einem anderen oder dem Master dazwischen.

Also nix mit ich probier mal so,
muss man sich schon alles genau überlegen,
aber wenn's so einfach wäre dann gäbe es diesen Thread auch nicht.
Der absolute könner bin ich ja auch nicht, eher auf der suche nach was funktionierenden.

Und erst wenn ich das dann auch richtig kapiert habe,
und wenn meine noch nicht fix definierten Anfordrungen erfüllt
werden können,
setzte ich mich an die Umsetztung in Silber, Zinn und Kupfer.

Außerdem haben sich bisher andere,
welche eventuell bereits erfolgreich diesem Thema gewidmet haben,
schön mit kreischendem Schweigen aus den Rampenlicht gehalten.

Kennt denn sonst keiner eine alternative,
welche einfach und zudem praktikabel ist?

Klar man könnte so einen Art Interfaceprozesor aufbauen,
welcher nix anderes macht als auf der Leitung zu sitzen,
um im Falle eines Falles dem eigentlichen Slave in die Seite haut (mit 'nem IRQ)

Frei nach dem Motto:
"Hey, der "alte" will was von Dir"

das mid dem Interfaceprozessor währe auch eine sehr gute Idee. Doch das wird dann gleich wieder teurer wenn ich hier einen Atmega benutze. Weil wenn der Slave immer horchen muss glaube ich ist das nicht so gut. Er soll ja schließlich seine Arbeit erledigen und nicht alle 5ms horchen.

wo ich gerade doch mal wieder hier bin....
hier is ja doch einigermaßen unruhe wegen des RS485.

also zum Problem des zeitkritischen abhorchen des Busses:
Ich habe es bei mir so gelöst, dass ich zusätzlich zu den beiden RS485 Leitungen eine dritte Interruptleitung mitgelegt habe. Der Busverkehr läuft ja nun logischerweise so ähnlich ab wie darwin bereits sagte. Nur das bei mir der Master wenn er einen slave ansprechen möchte, erst den interrupt setzt, sodass alle slaves "aufwachen", prüfen ob sie gefragt sind und dann der angesprochene antowrtet, die anderen schlafen weiter..nein arbeiten weiter (sollten sie zumindest) .
Da das ganze mit der Interruptleitung natürlich nicht in jedermanns sache ist, gibts auch die Möglichkeit (kann mich heute auch nicht zwischen groß- und kleinschreibung entscheiden 8-[ )das ganze über das 9. Datenbit des AVR zu machen. Der Nachteil der dadurch entsteht ist, dasss man einen Adapter(zwischengeschalteter AVR der den Verkehr zwischen RS485 Bus und PC händelt) braucht um einen Pc an den Bus zu klemmen. Deswegen habe ich mich auch für die dritte Leitung entschieden. Bei längeren Leitungen muss man diese dritte dann natürlich noch galvanisch vom Controller trennen, da sonst zu große Potenzialdifferenzen auftreten. Das ist aber bei den längen die im roboterbau auftreten absolut unproblematisch. Ansonten denke ich das es eigentlich die einfachste Lösung ist um die Slaves zu entlasten und kompatibilität zum Pc zu behalten.

Was das Protokolol angeht, habe ich ein Modul geschrieben, welches die Aufgaben des Sendens und emfpangens übernimmt (also auch das komplette Timing). Mann muss dem Modul nur die entsprechenden Daten übergebne Fertig. Meldet sich ein Slave nicht so wird noch 3 mal versucht ihn zu erreichen ansonsten wird ein fehlercode zurückgegeben, sodass man bescheid weiss, dass da wer den geist aufgegeben hat....
Adressen werden nicht per Autoselect vergeben, sondern jeder Controller bekommt eine eindeutige Adresse.

Leider habe ich im Moment wirklich wenig Zeit. Aber wenn ich es schaffe kann ichauch bis nächste Woche schonmal was fertig machen wenn ihr wirklich so scharf drauf seid =P~

so ich wünsche noch einen schönen abend

Baui

mensch mensch ... kann es denn so schwwierig sein?

also. IRQs können von verschiedenen Events ausgelöst werden,
z.B. von der UART.
Bei mir hängt der µC in seiner Funktion, z.B. Regelung oder was auch
immer ... dann kommt der Interrupt vn der UART,
aha es wurde ein Zeichen empfangen ...
vergleichen mit Startbyte für Telegrammanfang, wenn gleich, dann
gehe in Subroutine für Telegrammempfang und Verarbeitung.
Ist das dann abgeaerbeitet, dann wieder raus aus der Sub in normalen
Prozess.

So wirds gemacht

Homosapiens, homosapiens, ja so schwierig ist es.

Die Version von Baui ist zwar nicht schlecht, da einfach zu behandeln,
aber eben auch kein echter RS485 / Profibus mehr.
Wenn wir schon einen Standard verwenden dann so wie dieser definiert ist.

Beim RS485/Profibus reichen sogar nur zwei Leitungen (ohne GND) aus.

Die "denke" von Vitis hat eines nicht bedacht,
woher soll der UART wissen dass gerade das was er Empfängt für "seinen Slave" ist.
Das passiert auch bei der Variante von Baui

Um Rechenzeit zu gewinnen, und nichts anderes sollte doch die IRQ Variante bringen,
hilft es nur wenn der Bus quasi intelligent überwacht würde und seine CPU nur dann stört, wenn es "wichtig" ist.

Klar könnte ein UART einen IRQ auslösen,
dann aber bei jeden Bit das auf dem Bus herumspaziert,
ob es nun für seinen "Kunden" ist oder nicht.

Also IRQ kann auch lästig sein,
speziell wenn mehrere Teilnehmer im Bus verbunden werden und nicht nur zwei.

Bei einem Punkt zu Punkt Protokoll ist dies ja nich weiter tragisch,
z.B. nur um die Leitungslänge des RS485 zu nutzen.
(RS232 kann ja normalerwesise max. 15m lt. definition und RS485 mehrere hundert Meter (1500?) ohne weitere "Booster")

Quasi ein "aufgemoztes" RS232 aber eben kein BUS.
Dann könnte man auch ein Acknolege mit RTS/CTS und DTR/DSR aufbauen.

Wenn am Bus viel Traffic ist, kommt der Slave aus seinen IRQ's gar nicht mehr raus
bzw. fällt von einen IRQ in den nächsten

Frage:
Kriegt man dann irgendwann sowas wie einen IRQ oder Stack overflow? wenn zu viele IRQ's ausgelöst werden.

Ein IRQ unterbricht ja ein Programm um eine definierte Subroutine abzuarbeiten.
Die Interruptbehandlung wird (absichtlich) währenddessen nicht abgeschaltet (kein "Disable IRQ")

Wenn während dieser IRQ-Routine nun wieder ein IRQ ausgelöst wird,
und währen diesem wieder und wieder.
Irgendwann muss doch der Speicher für die Rücksprungadressen (Return) mal platzen.

[list=1]

[*]Muss es unbedingt Profi Bus sein?

Ich denke nicht unbedingt, es ist ja deine Sache, was du für nen Protokoll auf den Bus bringst, das ist ja das schöne dabei.

[*]Woher soll der UART wissen dass gerade das was er empfängt für "seinen Slave" ist?

Da gibt es relaziv viele und auch relativ einfache Tricks. Nen kleiner Tip von mir dazu: schau beschäfftige dich mal mit den Thema MPCM zu beschäftigen. Datenblatt Atmega 8 - Seite 151

Grober Umriss des MPCM:

man konfiguriere die USART auf 9 Datenbits.
Man setze das MPCM Bit im Register USCRA

Die USART wird nun nur noch dann denn Receive complete Interupt liefern, wenn das MSB gesetzt ist (das höchstwertige Bit), dieses könnte man daher ganz gut zur Adressierung / Zur Kennzeichnung des Adressbytes verwenden.

Im Controller wird also bei einem Interupt nur nachgeschaut, ob es seine eigene Adresse war.

Ist es die seine, wird das MPCM Bit gelöscht und der Controller kann damit die Datenbytes empfangen.

Nach den Daten sollte noch eine Stop Phrase kommen, damit der Controller weiss, okay, das wars dann und das MPCM Bit wieder setzen kann.

Generelle Grundlagen:

Adressen werden immer im Format: 1 xxxx xxxx übertragen.
Daten werden immer im Format: 0 xxxx xxxx übertragen.
[/list:o:35d4cb85ea]

Dieses ist nur eine Möglichkeit ... wenn man z.B. kein Feedback von den Slaves benötigt, könnte man auch ein DMX 512 ähnliches Protokoll nutzen.

Ich hoffe damit etwas weiter geholfen zu haben,

Grüße

da Hanni.

also irgendwann versteh ichs natürlich auch nicht mehr...

ich habe doch geschrieben, dass ich ich die Interruptleitung nur mitgelegt habe, um die Kompaitiblität zum PC zu erhalten und trotzdem einfach REchenzeit bei den Slaves zu sparen.

Das was hanni beschreibt ist genau das was ich mit dem 9. Datenbit meine.Das heisst im Datenblatt eben MPCM(MultiProcessorCommunicationMode). Also genau das wonach du suchst.
DA hast du deinen echten RS485 Bus. Nur zwei Leitungen. Nur beim Senden der Adresse springen die Slaves (und zwar alle) für ein Byte in die Empfangsroutine. Nur der, der auch angepsrochen wurde, hat dann kurz etwas mehr zu tun.
Nichts anderes machen Controller am Profibus. Entweder man hört die ganze Zeit jedes Byte am Bus ab, oder man definiert ein Zeichen bzw. Merkmal (9. DAtenbit) welches eine Adresse kennzeichnet. Dadurch spart man dann uach enorm REchenzeit bei den Slaves.

Ich verstehe jettzt nicht ganz, was daran nicht echt sein soll (außer die Interruptleitung, die ich aber auch als "nicht jedermanns Sache" beschreiben habe, und gleich im anschluss das 9. DAtenbit erwähnt habe)

Zu deiner Frage:

Zitat:

Wenn während dieser IRQ-Routine nun wieder ein IRQ ausgelöst wird,
und währen diesem wieder und wieder.
Irgendwann muss doch der Speicher für die Rücksprungadressen (Return) mal platzen.

eben gerade das muss verhindert werden. Du solltest es vermeiden, dass aus einer Interruptroutine heraus wieder ein Interrupt ausgelöst werden kann (zumindest wenn du dies nicht bewusst machst). Dass bedeutet im klartext Interrup sperren, entweder gleich global alle oder nur die entsprechenden (Datenblatt).
Andere Möglichkeit ist, deine Interruptroutine so kurz zu halten, dass diese der Auslösefrequenz hinterherkommt. Ich präferiere jedoch die erste Variante, da dort probleme von vorneherein ausgeschlossen werden.

Ansonsten, wenn ud dies nicht beachtest, läuft dir irgendwann der Stack über. DAs ist richtig. Dann gibts Chaos im Controller.

Hoffe, dass jetzt Probleme beseitigt sind.

Gruß
Baui

@Hanni:

zu 1.
Ja Profibus sollte es schon sein, aus bestimmten anderen Gründen.
Erst mal was eigenes Entwerfen um dies zu verstehen
und dann später Fremdgeräte mit bereits festgelegtem Protokol
(Welches ist mir noch nicht bekannt) damit anzusprechen.

zu 2.
Ja das ist schon mal ein Ansatz,
dieSlaves werden dann zwar auch noch immer gestört,
um festzustellen ob sie gemeint sind, aber nicht mehr so oft.

Mindestens um die Hälfte der Telegramme, welche durch den Bus laufen,
kommt auf die Größe der Datenpakete an.

Ich würde mit das dann so vorstellen:

1 AAAA xxx für einen "Call des Masters an einen Slave"
0 AAAA xxx für ein "Telegramm"
AAAA = Adresse des Empfängers 0001 für Master oder xxx0 für den entsprechenden Slave

So jetzt wird von meiner Seite aus mal wieder Ruhe einkehren,
da ich mir erst mal die vorgergstellten Protokolle um die Ohren hauen muss.

@Baui:
Das Problem Kompatibilität zu PC kann ich so jetzt nicht nachvollziehen,
Es gibt doch auch fertige Interfaces, welche auch nicht mit 'nem separaten IRQ arbeiten.

Nichts gegen Deinen Lösungsansatz,
aber wenn Ich schon mal mit 'nem Standard anfange dann richtig,
ohne Kompromisse, sonst ist man schnell in einer Sackgasse.

Da haben sich ein paar "helle" Köpfe zusammengesetzt,
um so ein System zu definieren,
welche vermutlich noch mehr auf den Kasten haben.
Und der Bus hat sich ja etabliert und das nicht erst seit gestern,
sondern schon seit vielen Jahren.

Mir geht es jetzt darum, dies zu verstehen und umzusetzten.

Immerhin bin ich mit dieser Recherche hier im Roboternetz in einem kuzen Zeitraum schon weiter gekommen als irgendwo anders in Jahren nicht.

So jetzt werd ich mich mal (irgendwann) auf die Suche nach den beschriebenen Protikollen machen und dieses Forum weiterhin beobachten, könnte ja sein dass noch mehr Info rüber kommt.

Die einzige für mich wirklich prozessorlastsparende Variante
wäre mit 2 µC zu arbeiten.
A) Einer für die Busanbindung, der nur lauscht und kommuniziert
und nur wenn der Slave wirklich gemeint ist dann am 1.
Controller nen Int auslöst oder der Hauptprozessor schiebt
kontinuierlich in Arbeitspausen seine Daten in den "Kommunikator", die
der dann auf Anfrage weiterschickt,
B)oder wie beim SPI ne Slave-Select-Leitung.
Ansonsten kommt der Slave um das Lauschen nicht herum.
Klar, das braucht etwas Rechenzeit, nur ob die bei den Geschwindigkeiten
der µC wirklich ins Gewicht fällt ?
Für zeitkritische Busslave Geschichten wäre die A-Variante sinnvoll,
für unkritische Anwendungen wäre die Interruptvariante denkbar.
Im Übrigen baut man einen Bus auf um Leitungen zu sparen
und die Daten die drüber laufen sollten auch nicht unbedingt
jede Handlungsanweisung für den Slave beinhalten sondern
nur die "Konfiguration" also Umgebungsvariablen.
Als Antwort reicht dann "ausgeführt" Oder "Ergebnis=xy". Der
Rest sollte in der Software des Slaves ablaufen, dafür benutzt man
nämlich Slaves, sonst könnt man ja gleich alles an einen µC anbinden.
Wieviel Trafic auf dem Bus ist und was da an Rechenlast verbraten wird
hängt von der "Intelligenz" der Busteilnehmer ab.

Wie lange nach dem Printbefehl kann ich mit inkey oder inputbin die Daten empfangen? Oder sendet der Printbefehl dies ohne zu achten ob jemand empfängt?

Zitat:

Oder sendet der Printbefehl dies ohne zu achten ob jemand empfängt?

Genau das tut er, wenn ihn nicht ein Hardwarehandshake daran hindert.

genau darum ist es wichtig, das der Gegenpart empfangsbereit
und der Bus frei ist.

also werde ich doch einen Mega8 als Inerfacecontroller verwenden, der immer auf empfangen ist und wenn die Adresse vom jeweiligen Slave genannt wird, soll der Master kurz warten und der Slave in eine Sub rein springen. Das müsste doch so funktionieren oder.

Es sollte auch ohne einen Interface Prozessor funktionieren ... zumal es recht wiedersinnig ist einen Mikrocontroller zu verwenden um ein Käfergrab zu vermeiden um anschließend das Käfergrab mit weiteren Mikrocontrollern neu zu eröffnen ...

ist zwar etwas überdimensioniert, aber kannste so durchaus machen ...
ob Deine Anwendung so zeitkritisch ist weißt nur Du alleine.

Naja ... eine Anmerkung hab ich allerdings noch:

Zeitkritisch und Basic schliesst sich irgendwie etwas aus .... aber das ist wohl Ansichtssache.

Ich denke mal, diese Ganze scache dürfte mit einem Mikrocontroller unter Zuhilfenahme des MPCM, Interuptroutinen sowie einer anständigen Ansteuerung der Bustreiber leicht zu realisieren sein.

Grüße,
da Hanni.

Wenn man den RS485 mit UART behandelt, kann man sich doch einen IRQ erzeugen lassen, immer wenn ein Byte über die UART rein kommt,
in der ISR kann man dann kurz abfragen was das Byte aussagt,
und wenns ein Beginn einer Übertragung ist, und danach die richtige Slaveadresse kommt, kann man sich ein Flag setzen das wiederum in der Hauptschleife abgefragt wird,
die restlichen Bytes werden dann bis zum schluss eingelesen,
ansonsten die Bytes ignorieren und im normalen Ablauf weitermachen !?

So vom Prinzip her sollte es gehen, oder gibts noch ein andres Problem was ich überlesen hab ?!

Also wenn ich das mit dem IRQ hinbekomme, dann ist das bester schon einen Controller zu verwenden. weiß von euch einer, wie ich das mit dem Interrupt mache?

Die UART hat ein Flag für Receive Complete,
kann man in Bascom mit

Code:

Enable Interrupts Enable URXC On URXC Isrlabel

abfangen.

Man kann sich in der ISR einen Buffer füllen (ByteArray?), falls die richtige Slaveadresse nach dem Start dabei war. Und ein Flag setzen, das ein Telegramm zur Bearbeitung ansteht, dieses sollte dann in der Hauptschleife gemacht werden.