Probleme mit RS 485 Bus

[habunus]

Hallo,

hätte mal eine Frage zum dem RS 485 Bus. Habe folgenden Code mit einem Master und einem Slave der auch Funktioniert:

Master:


'------------------------------------------------------------------------------
'name : .bas
'copyright : (c) 1995-2005, MCS Electronics
'purpose : demonstrates
'micro : Mega48
'suited for demo : yes
'commercial addon needed : no
'------------------------------------------------------------------------------
$regfile = "m16def.dat"
$crystal = 8000000
$baud = 19200

Config Portd.2 = Output
Portd.2 = 0
Dim Slave(2) As String * 8

'Slaveadressen
Slave(1) = "Modul 1"
Slave(2) = "Modul 2"
' - - - - - - -

Send:

Do

Waitms 100

Portd.2 = 1
Waitms 100
Print Slave(1)
Waitms 100
Portd.2 = 0

Loop
Goto Send



Slave:


'------------------------------------------------------------------------------
'name : .bas
'copyright : (c) 1995-2005, MCS Electronics
'purpose : demonstrates
'micro : Mega48
'suited for demo : yes
'commercial addon needed : no
'------------------------------------------------------------------------------
$regfile = "m16def.dat"
$crystal = 8000000
$baud = 19200

Config Portd = Output
Portd.2 = 0
Portd.7 = 0

Dim Rs485input As Byte
Dim A As Byte
Dim Temp As String * 8

' - - - Lcd - - -
Config Lcd = 16 * 2
Config Lcdpin = Pin , Db4 = Porta.0 , Db5 = Porta.1 , Db6 = Porta.2 , Db7 = Porta.3 , E = Porta.5 , Rs = Porta.4
Config Lcdbus = 4
Config Lcdmode = Port


On Urxc Onrxd
Enable Urxc
Enable Interrupts

Do
nop
Loop

Onrxd:
Inputbin Temp


Cls
Lcd Temp

Return


An dem Slave habe ich eine LCD Angeschlossen und wenn der Slave z.B. Modul 1 empfängt sind immer kryptische Zeichen dabei.

Was könnte das sein. Habe mir schon etliche Dinge durchgelesen aber finde den Fehler nicht.
Bin noch ein Neuling mit Bascom ;-)


Bedanke mich im Voraus für eine Antwort

[Vitis]

ts ts ... input und lcd-darstellung im interrupt ... das macht man nicht

dann noch hier:

Print Slave(1)

bei dieser Anweisung wir CR und LF mitgesendet, das ist auch
gut so, da du sonst nicht aus dem input beim slaver heraus kommst
sprich, am ende deines empfangenen strings sind noch 2 zeichen
im ascii-code zeichen 10 und 13. die werden vemutlich auf dem lcd
als irgendwas dargestellt. du kannst das vermeiden, indem du per
"left" deine zeichenkette um 2 Stellen kürzt.

[BlaueLed]

Hi,

der Fehler liegt darin, das er den String Temp mit 8 Stellen definiert aber nur 7 sendet.

mfg Kay

[habunus]

Hallo Vitis,

was meinst du damit:

ts ts ... input und lcd-darstellung im interrupt ... das macht man nicht

Was meinst du damit ????

Mfg Tobias

[Vitis]

interrupts, bzw. deren interruptroutinen programmiert man
möglichst kurz und knackig.
Das hat damit zu tun, dass der AVR wenn ein interrupt ausgeführt
wird in der entsprechenden routine bleibt, bis diese abgearbeitet
ist. kommen andere interrupts dazwischen werden die schlicht ignoriert.
wenn du also timer, uart, softclock, twi interuptbasierend programmierst
kommst du mit der Art der Programmierung u.U. sehr in die bredulie.

es spielt keine Rolle ob der String länger definiert ist als genutzt, es ist
sogar besser so als andersrum. Der compiler merkt das schon selbst.

[BlaueLed]

der Fehler mit dem kryptischen Zeichen ist aber nicht mehr da, seit dem er String * 7 gemacht hat. Also kann es so falsch nicht gewesen sein, was ich geschrieben habe :-)

[Vitis]

ja klar, so kann man das machen, aber ... es gibt immer ein aber ...
die zeichen 10 und 13 werden empfangen, auf alle fälle und das braucht er auch
für den input. sie werden auch wahrscheinlich dem string angehängt, nur
sind sie nun ausserhalb des definitionsbereichs.
das könnte dazu führen, dass wenn er nach dem string eine weitere
variable dimensioniert, die dann im ram hinter dem string liegt,
diese durch die empfangenen zeichen überschrieben wird.
so entstehen u.U. prima zu debuggende programmfehler weil
man sich dann den wolf sucht warum nun diese oder jene variable
seltsame unreproduzierbare werte enthält.
am schönsten werden die geschichten, wenn stack oder frame vom
überschreiben betroffen sind.
klar, bei dem miniprogramm ist das nicht der fall, aber aus dem miniprogramm
soll wohl am ende was größeres werden, daher plädiere ich dafür
von anfang an richtig zu machen als dann später fehler die man
vor x monaten gemacht hat zu debuggen :)