Kommunikation über 485-Bus mit Bascom und PicBasic

[wurm]

Hallo,

ich bin im Moment ein bißchen am Verzweifeln. Irgendwie bekomme ich das mit der Buskommunikation auf dem 485-Bus nicht richtig hin.
Und da dieses ein super Forum ist, stelle ich hier mal meine Frage:

Ich habe eine Master-Steuerung, die 2 Slave´s ansprechen soll, die dann eine Antwort geben.
Das ganze ist über einen 485 Bus verbunden. Hierbei muss ich zwischen senden und empfangen umschalten.

Der Master (Atmege12 wird mit Bascom programmiert und so sieht der Code aus:

' Kommunikation

'Software UART 2
Open "comd.2:19200,8,n,1" For Input As #2
Open "comd.3:19200,8,n,1" For Output As #3

Tastendruck:

Set Busrxtx ' 485 Bus auf senden
'Print #3 , chr(100)  ' Slave1 ansprechen
'Reset Busrxtx '485 Bus auf empfangen
'Slave1_in = Inkey(#2) ' Slave1 antwort holen
'Set Busrxtx ' 485 Bus auf senden
'Print #3 , Chr(101) ' Slave2 ansprechen
'Reset Busrxtx  '485 Bus auf empfangen
Slave2_in = Inkey(#2) ' Slave2 antwort holen

'Abfragen
if Slave1_in = 001 then gosub Vorwärts
.....

goto Tastendruck

Bei den Slave´s ist ein Pic16F873a im Einsatz. Diesen habe ich mit PicBasic programmiert. Der Code sieht dabei folgendermaßen aus.

' Definitionen
define osc 4
include "modedefs.bas"

DEFINE HSER_RCSTA 90h
DEFINE HSER_TXSTA 24h
DEFINE HSER_BAUD 19200 ' 19200 Bauds
DEFINE HSER_CLOERR 1

Bus_out var byte
Bus_out_alt var byte
zaehler var word
Bus_in var Byte
busrw var portc.5
output portc.5

Schleife:
low busrw 'Slave auf empfang
HSERIN [Bus_in]
if Bus_in = 101 then 'Slave soll Antworten //100 für Slave1 //101 für Slave2
high busrw 'Slave auf senden
HSEROUT [Bus_out] 'Variable Bus_out ausgeben (Anweisungen von Sensoren)
low busrw 'Slave auf empfangen
endif

goto Schleife

Irgendwie erkennt der Pic nicht, dass er angesprochen wird.
Hat jemand eine Idee, was ich an dem Code ändern sollte, damit es funktionieren kann?

Mfg,
Thorsten

[Stromi]

Sicher, dass der Pic was bekommt, beim Bascomcode?
Der ist ohne Def, Dim usw
Ist ziemlich viel "geremt"....
Poste möglichst keine Auszüge von deinem Code. So geheim kann er nicht sein .

[wurm]

sorry, die Rems sollten da eigentlich nicht hin.
Der Code passt hier leider nicht rin, deshalb habe ich ihn zum Download bereitgestellt.

www.bl-design.net/Desktop.rar

[darwin.nuernberg]

In der Bascom-Hilfe steht was zum RS485 (Suchman nach 485)

• Use PRINT or PRINT0 for the first serial port. Use PRINT1 for the second serial port.
  
  When you use RS-485 half duplex communication you need a pin for the direction of the data. The CONFIG PRINT automates the manual setting/resetting. It will either SET or RESET the logic level of the specified pin before data is printed with the Bascom print routines. After the data is sent, it will inverse the pin so it goes into receive mode.
  
  
  You need to set the direction of the used pin to outputmode yourself.
  
  

  .......
  Config Print0 = Portb.0 , Mode = Set 
  Config Pinb.0 = Output                                      'set the direction yourself 
  .....

Schau doch mal selbst nach.

Ansonsten bin ich auch sehr an deinem Protokoll interresiert,
da ich demnächst (innerhalb den nächsten Decade) auch damit arbeiten möchte/werde.

[wurm]

Das Problem ist, das der Pic (Slave) die Daten nicht empfängt.
Ich hab das mit einem Display getest. Der Master sendet seine Signale korrekt.
Der Pic ist nur irgendwie nicht in der Lage, die Daten von der UART richtig zu holen. Ich hab mal eine Abfrage gemacht, es kommen immer nur Nullen an.

Ich hab nur leider noch keine Ahnung, woran das liegt.

[Stromi]

Das PIC-Program ist mit PIC-Bas geschrieben. Gibt es davon eine Demo?

[wurm]

glaube nicht, dass es davon eine Demo-Version gibt.
Hab bei dem Hersteller mal nichts gefunden.
www.melabs.com

[wurm]

ich habe das problem jetzt weiter eingegrenzt.
wenn ich mit dem Atmega ein chr(101) sende, dann empfängt der Pic ein chr(210).
Ich weiß nicht, ob das Signal invertiert ist oder ob da etwas mit den Kommunikationsparametern nicht stimmt.

[darwin.nuernberg]

Soweit ich das mit dem RS485 überrissen habe,
gibt es kein definiertes Protokoll, sprich jeder kann sein eigens Ding machen.

RS485 definiert, rein die Hardware (2-Wire für halb und 4-Wire für Vollduplex Modi).

Schau mal nach ob du wirklich nur ein Byte bekommst oder
möglicherweise gar zwei (oder mehr) und
ob Du nur das letzte betrachtest.

Ich stell mir das z.B. so vor ein Byte zwird in zwei Bytes zerlegt, wobei das obere Nibble (4-Bit) nach rechts (uunten) geschoben wird (oder das untere nach oben) die restlichen 4-Bit sind dann erst mal "0000" und könnten mit der Zieladresse maskiert werden (somit sind dann 1-15 Slaves und ein Master also 16 Adressen codierbar).

Wenn nun nicht beide Seiten das gleiche Protokoll verwenden krachts schon.

Ist nur so eine Idee, aber vielleicht trifft ja das eine oder andere zu.

[hitrax]

ich habe das problem jetzt weiter eingegrenzt.
wenn ich mit dem Atmega ein chr(101) sende, dann empfängt der Pic ein chr(210).
Ich weiß nicht, ob das Signal invertiert ist oder ob da etwas mit den Kommunikationsparametern nicht stimmt.

Hallo "Wurm"

Habe ein ähnliches Problem gehabt.
Bei mir lags an der nicht ganz korrekten Syntax des Print befehls.
Wenn Du nur Print chr(101) angibst sendet der Controller ein CR mit.
Das führt schon mal zur Verwirrung auf der Empfangsseite.

Wenn Du den Printbefehl mit einem ";" Semikolon abschliesst

zB. Print chr(101);

wird dieses CR unterdrückt und nur der Zeichencode gesandt.
Das war jedenfalls bei mir der Fehler. Vielleicht hilft dir das ja weiter.

MfG Helge