RS 485 Master - Slave in Bascom???

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:

1. man konfiguriere die USART auf 9 Datenbits.
2. 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.