RS 485 Master - Slave in Bascom???

[Zeroeightfifteen]

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?

[linux_80]

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

[darwin.nuernberg]

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.

[avrwalli]

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

[Baui]

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

[Vitis]

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

[darwin.nuernberg]

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

[Zeroeightfifteen]

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?

$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


$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?

[Vitis]

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.

[Zeroeightfifteen]

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.

[avrwalli]

Hallo darwin.nuernberg,

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



'
' -----[ 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

[darwin.nuernberg]

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.

[Vitis]

@ 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/content/pisc/technicaldescription/4001_vOktober2002-German.pdf

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

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

[darwin.nuernberg]

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

[Hanni]

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

[darwin.nuernberg]

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.

[Zeroeightfifteen]

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.

[darwin.nuernberg]

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.

[Zeroeightfifteen]

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?

[darwin.nuernberg]

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

Logisch,
JAAAhAAA.
Rrrrrrichtig,
Corrrrrrekt

Schnellmerker.

(ein helles Köpfchen, bei Sonnenlicht)

[darwin.nuernberg]

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"

[Zeroeightfifteen]

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.

[Baui]

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

[Vitis]

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

[darwin.nuernberg]

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.

[Hanni]

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 (http://atmel.com/dyn/resources/prod_documents/doc2486.pdf)

Grober Umriss des MPCM:
[list=1:35d4cb85ea] 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.

[Baui]

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:


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

[darwin.nuernberg]

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

[Vitis]

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.

[Zeroeightfifteen]

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?

[PicNick]

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

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

[Vitis]

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

[Zeroeightfifteen]

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.

[Hanni]

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

[Vitis]

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

[Hanni]

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.

[linux_80]

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 ?!

[Zeroeightfifteen]

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?

[linux_80]

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

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.

[darwin.nuernberg]

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

Nein ist nicht Ansichtssache.

Wenn man Basic als Interpreter-Sprache versteht,
z.B. wie vor Urzeiten der VC20/C64 und Kollegen, dann ja.

Beispiel: Teil (Zeile) des Codes übersetzten, ausführen und wieder von vorne.

Bascom wird jedoch nicht interpretiert sondern Compliliert.
Sprich es wird der gesamte Code zunächst komplett übersetzt bevor er ausgeführt wird.

Ob jetzt Bascom oder C einen besseren Code liefern kann ich nicht sagen (Tendiere aber für einen leichten Vorsprung von C).

Wenn es wirklich knallhart zeitkritisch wird,
dann hilft eh nur noch pures Assembler.

Außerdem ist der Begriff Zeitkritisch an sich eine Gummiband Auslegung.

Echtzeit wäre hier wohl der passendere Ausdruck.
Da tut sich aber jeder Chip schon schwer was soll man da von der verwedneten Hochsprache schon sagen.

Dann kann man auch gleich in binärcode arbeiten.




Widersprüche?

[Vitis]

ein gutes Schlussplädoyer für den thread hier würd ich sagen ;)

[darwin.nuernberg]

ein gutes Schlussplädoyer für den thread hier würd ich sagen ;)

Nee, blos nicht.

Es könnte doch noch einer eine ander geniale Idee haben
(die dann doch wieder ihre Macken hat)

[Zeroeightfifteen]

genau wenn einer noch eine Idee hat dann soll er sie doch bitte noch dazu schreiben. Ich werde mich dann mal an die arbeit machen das mit dem IRQ aus zu probieren.

[elkokiller]

Hallo zusammen,

die beiträge sind ja schon etwas älter.
Kann mir hier jemand ein Beispielcode für die Slave geben?
ich kome einfach nicht weite

Tobias

[Vitis]

on urxc uartinterrupt
enable urxc
enabe interrupts

ddrc = &B00000100
portc.2 alias rw_rs485
rw_485=1 ' empfangesrichtung
dim Zeiger as byte
dim Message(20) as byte
zeiger=0

do
' Hauptschleife
loop

uartinterrupt:
incr zeiger
message(zeiger)=UDR
return
end


so in etwa, aber in nem anderen thread hab ich mal ne ausführliche Sache gesehen, find sie aber nicht ... ich schau mal zuhaus nach heut abend

[lwl]

Guten Morgen,

Ich weiß, dieses Thema ist schon bischen älter, aber ich hoffe, ich bekomme Trotzdem vielleicht eine Antwort. Ich habe mir paar Infoblätter durchgelesen und dort ergaben sich noch so die ein oder andere Frage. Folgende wären das:

Als Slave spricht dort was gegen den ATTiny2313? In meinem Fall sollen die Slaves nur auf Anfrage Daten aus einem Sensor holen, Verarbeiten und auf Kommando an den Master Schicken.

Als Master würde ich den ATmega644p nehmen, der hat 2 Uarts den er soll mit Bus UND dem PC Kommunizieren und mit dem PC per RS232 (Kabellänge von 50m +- etwas machbar?)

Als System dachte ich an die 4-Draht Lösung, weil dort reagieren, wenn ichs richtig verstanden habe, die Slaves nur auf Master-Anfragen und nicht auf die Slave Sendungen.

Was für ein Treiber müsste ich den für das 4-Draht System nehmen?

Beim 2 Draht System wollte ich den "sn75176" nehmen, ich weiß nicht der Sparsamste aber bei insgesamt max 15 Units denk ich ist er okay.

Für die Adressierung werde ich mich vermutlich für Dip Schalter entscheiden, aber das ist ja Geschmackssache oder?


Vom Protokoll her wollte ich es wie folgt machen:

1. Master sendet im vorgegeben Zyklus an 00 (ist ja Adresse für Alle, wenn ich das richtig verstanden habe) den Befehl, Daten aus dem Sensor holen.
2. Master Spricht nun alle Slaves seperat an und holt die Daten
3. Slaves Antworten
4. Master bereitet Daten für Ausgabe auf und los gehts.

Michael



PS: Ich hoffe man hört was von Euch und bitte berichtigt mich, wenn ich irgendwo Falsch liege.

[WL]

Als Slave spricht dort was gegen den ATTiny2313? In meinem Fall sollen die Slaves nur auf Anfrage Daten aus einem Sensor holen, Verarbeiten und auf Kommando an den Master Schicken.

Wenn Dein Programm da reinpasst, spricht da nichts dagegen.



Als Master würde ich den ATmega644p nehmen, der hat 2 Uarts den er soll mit Bus UND dem PC Kommunizieren und mit dem PC per RS232 (Kabellänge von 50m +- etwas machbar?)

50m ??? Eher nicht (ohne weiteres). Warum nicht auch RS485 ? Oder Master näher am PC plazieren.



Als System dachte ich an die 4-Draht Lösung, weil dort reagieren, wenn ichs richtig verstanden habe, die Slaves nur auf Master-Anfragen und nicht auf die Slave Sendungen.

Da bringst Du was durcheinander. 4-Draht Lösung bedeutet Full-Duplex, also gleichzeitiges Senden und Empfangen.
Bei 2-Draht RS485 (Half-Duplex) wird der Reihe nach Gesendet und danach Empfangen.



Was für ein Treiber müsste ich den für das 4-Draht System nehmen?


Da gibt es sehr viele...............
z.B. MAX485/MAX488/MAX491/u.s.w.


Beim 2 Draht System wollte ich den "sn75176" nehmen, ich weiß nicht der Sparsamste aber bei insgesamt max 15 Units denk ich ist er okay.

Geht auch mit 4-Draht Bus.




Für die Adressierung werde ich mich vermutlich für Dip Schalter entscheiden, aber das ist ja Geschmackssache oder?


Richtig.
Ich nehme allerdings feste Adressen im Programm. Warum sollte ich die Adressen ändern ?


Vom Protokoll her wollte ich es wie folgt machen:

1. Master sendet im vorgegeben Zyklus an 00 (ist ja Adresse für Alle, wenn ich das richtig verstanden habe) den Befehl, Daten aus dem Sensor holen.
2. Master Spricht nun alle Slaves seperat an und holt die Daten
3. Slaves Antworten
4. Master bereitet Daten für Ausgabe auf und los gehts.


Wozu Schritt 1 ?


Mein Protokoll habe ich mit MPCM (9Bit Übertragung) aufgebaut (im Datenblatt nachschauen).
Die Slaves (der Master auch) schauen in der ISR auf gesetztes 9.Bit (Adresse wird übertragen) und machen dort nur weiter wenn sie adressiert sind (darauf folgendes Frame) > Telegramm holen und entsprechend reagieren / wenn nein > weiter in der Hauptschleife.
Man muß nur das MPCM-Bit sinnvoll auf "1" und "0" schalten..............

(der µC wird nur bei gesetztem 9.Bit in die ISR geschickt wenn der MPCM-Modus aktiv ist)

Slaves :
Die Hauptschleife bearbeitet den Sensor und der µC wird ab und zu in die ISR geschickt.

Master:
Die Slaves der Reihe nach adressieren, Daten abholen (auch in der ISR) und weiterverarbeiten..........

[lwl]

Kann den Bascom das überhaupt? Also mit dem 9.Bit? Habe irgendwo gelesen, dass Bascom dafür nicht optimal ist. Von daher müsste ich mir was überlegen.

Und vom Bus her denke ich, ich bleib beim 2-Wire-Bus. Habe so noch ein wenig Reservem im Cat.5 Kabel.

Und an sich sollen die Slaves ja nur Daten ermitteln und weiterleiten. Und gut, dann müsste ich mir was für die Kommunikation mit dem PC überlegen. Der PC soll aber nur mit dem Master Kommunizieren. Von daher dachte ich an RS232. Und man kann doch auch die Signale Verstärken mit passenden Treibern oder? Vorallem soll der PC nicht ständig drin hängen, sondern nur bei Bedarf. Er soll die Uhr Stellen und die Daten auch erhalten können bei Abruf.

Was ich vll noch nicht sagte ist, der Master bekommt ein RTC Chip.

Mit den Slaves hat er nix zu tun.

Und für die Dip Schalter Lösung entschied ich mich, weil ich so alle Slaves gleich bauen kann und die gleiche Software drauf spielen kann. Also so an sich Identisch. Jede Unit bekommt auch Abschlußwiderstände, die Per Jumper Aktiviert bzw. Deaktiviert werden können. Hat den Grund, so kann ich den Bus verlängern ohne großen Aufwand. Einfach Jumper bei letzten Unit raus, neue Unit hinter packen, Jumper dort rein, richtig Adressieren und fertig.

Gut ich muss dem Master sagen, dass eine weitere Unit zu gekommen ist, aber dafür kann man sich ja noch was überlegen, also ein art "Automatisches Setup". Bei diesem läuft er einfach alle Adressen durch, die möglich sind und wenn keine Antwort kommt weiß er, er ist durch.

Alternativ kann man auch sagen er läuft die Gesamten Adressen durch und Speichert alle die eine Antwort geben in einem Array ab, der nach abschluß des Setups im EEprom gepackt wird. Also Variante B wäre für den fall, dass man "unsauber" adressiert.


Michael

[WL]

Kann den Bascom das überhaupt? Also mit dem 9.Bit? Habe irgendwo gelesen, dass Bascom dafür nicht optimal ist.

........... Bascom kann ! Auch Bits schreiben und lesen !


Und man kann doch auch die Signale Verstärken mit passenden Treibern oder?

Kann man.
RS485 Treiber hast Du aber in Händen.



Und für die Dip Schalter Lösung entschied ich mich, weil ich so alle Slaves gleich bauen kann und die gleiche Software drauf spielen kann. Also so an sich Identisch. Jede Unit bekommt auch Abschlußwiderstände, die Per Jumper Aktiviert bzw. Deaktiviert werden können. Hat den Grund, so kann ich den Bus verlängern ohne großen Aufwand. Einfach Jumper bei letzten Unit raus, neue Unit hinter packen, Jumper dort rein, richtig Adressieren und fertig.

Gut ich muss dem Master sagen, dass eine weitere Unit zu gekommen ist, aber dafür kann man sich ja noch was überlegen, also ein art "Automatisches Setup". Bei diesem läuft er einfach alle Adressen durch, die möglich sind und wenn keine Antwort kommt weiß er, er ist durch.

Alternativ kann man auch sagen er läuft die Gesamten Adressen durch und Speichert alle die eine Antwort geben in einem Array ab, der nach abschluß des Setups im EEprom gepackt wird. Also Variante B wäre für den fall, dass man "unsauber" adressiert.


Warum nicht. Dann man los........
Viel Erfolg !

[lwl]

ja gut, dann würd ich aber ein zweiten Bus aufbauen. wie gesagt pc und Master sollen nur kommunizieren. wie bekomm ich den dann am besten den PC in den bus? Weil bei RS232 ist das ganz einfach. Vorallem am PC müsste ich dann noch eine passende Anwendung haben. Weil ich kam endlich dahinter, wie ich mit RS232 kommunizieren kann also vom PC her. Von daher würd ich gern bei RS232 bleiben.

Ach was ich vergessen habe, ich weiß nicht ob das den Unterschied bringt, aber zwischen dem Uart vom µC und der Seriellen Schnittstelle ist noch ein Max232 eingesetzt.

Und wegen der Kommunikation wollte ich eh ein "Paket" schnüren, welches übermittelt wird. Dann also bestehend aus Empfänger Adresse, Sender Adresse und Daten. Also so war es geplant. Muss beim Slave dann ja nur das "Paket" zerlegen und er reagiert dann.

Michael

[WL]

ja gut, dann würd ich aber ein zweiten Bus aufbauen. wie gesagt pc und Master sollen nur kommunizieren. wie bekomm ich den dann am besten den PC in den bus? Weil bei RS232 ist das ganz einfach. Vorallem am PC müsste ich dann noch eine passende Anwendung haben. Weil ich kam endlich dahinter, wie ich mit RS232 kommunizieren kann also vom PC her. Von daher würd ich gern bei RS232 bleiben.

Ist die Verbindung vom Master zum PC(RS232) KEIN zweiter Bus ???
nochmal............

...mein Vorschlag:
PC -> (USB-RS485-Adapter)..............................50m......... ...........................RS485 (z.B.MAX485) -> MASTER-µC
Zu überlegen wäre, ob Halb- oder VollDuplex (2/4-Draht).

...deine Variante:
PC RS232 /(USB-RS232)-> RS232-Repeater....................................50m... ....................................RS232-Repeater ->RS232 ->MASTER-µC

Softwaretechnisch ist es egal ob RS232 oder RS485 (oder....) solange kein (Hardware-)Handshake gefordert ist.


Ach was ich vergessen habe, ich weiß nicht ob das den Unterschied bringt, aber zwischen dem Uart vom µC und der Seriellen Schnittstelle ist noch ein Max232 eingesetzt.

Sicher !
Dann raus damit !



Und wegen der Kommunikation wollte ich eh ein "Paket" schnüren, welches übermittelt wird. Dann also bestehend aus Empfänger Adresse, Sender Adresse und Daten. Also so war es geplant. Muss beim Slave dann ja nur das "Paket" zerlegen und er reagiert dann.

Das kannst Du machen wie Du willst.
Deine SLAVEs haben sowieso nichts zu tun...................

[lwl]

Ja gut,

kennst den ein vernünftigen RS232 Repeater? Weil ich möchte beim Seriellen Anschluß bleiben nicht den USB Anschluß verwenden. Also ist reine geschmackssache von mir.

Und zur Kommunikation kam mir eine doch gute Idee, da testen ich dann aber erstmal, ob es klappt. Aber wenns Interessiert, was ich vor habe:

1. Master sendet die Adresse des Slaves
2. Slaves hören per Inkey ab und reagieren nur, wenn ihre Adresse genannt wurde, arbeiten sonst weiter.
3. Master sendet Befehl und Prüfsumme und da die anderen Arbeiten ja weiter also bekommts nur der gewünschte Slave. Gut die bekommen was in den Inkey Bus, aber die sollen den einfach wieder löschen, wenn es nicht eine Adresse ist.
4. Slave sendet an Master die gewünschten Daten.

Ich denke, so könnte es zumindest fürn Anfang gut machbar sein. Gut ich machs doch anders als geplant wegen dem Paket, aber naja.


Michael

[WL]

O.K.
ich geb's auf..........................

Mach wie Du denkst !

[lwl]

Ich kann es ja Hardware und Softwaremäig noch anpassen. Für die Slaves sollen lediglich Streifenrasterplatinen verwendet werden. Und die werde ich nicht aufs minimale verkleinern. Also von daher ist noch alles machbar.

Nur spricht was dagegen Wenn ich mich im Nachgang doch für die Kommunikation zwischen PC und Master für ein Seperaten RS485 Bus entscheide, diesen an die Serielle Schnittstelle (9 Pol. Anschluß) zu packen?

Und naja Softwaremäßig ist schließlich auch alles möglich. Ein Programmiergerät habe ich und somit brauch ich nur einen ISP Anschluß pro Junit rein packen und das ist überhaupt kein Problem.


Michael