Serin2 and STR Modifier

[_Ian]

Hi all,

I have a question about the STR modifier for serin2 (or DEBUGIN, I'm assuming that they act the same way?). Simply put, does STR do any ascii conversion of the input bytes when it writes them to the array? In other words, if I do:

DEBUGIN [STR array\1]

and the incoming byte is $44, then

array[0] == $44

and not $52, or something else?

Sample Code:

This ends with the array full of garbage:
================
payload var byte[15]
reply var byte
msg var byte
timeout con byte
reply = 5
...
DEBUGIN timeout, error, [WAIT(msg), STR payload\reply]
==========================================

While this one works fine:
===================
payload var byte[15]
reply var byte
msg var byte
timeout con byte
reply = 5
...
DEBUGIN timeout, error, [WAIT(msg), payload[0],_
payload[1],_
...
payload[5] ]
============================================

Other than this, the serial comm works fine, but I can't seem to get STR to do what (I think) it should. I am new to PBP, though...

Thanks much,

Ian

[Melanie]

Try it with a constant for the array size rather than a variable...

DEBUGIN timeout, error, [WAIT(msg), STR payload\5]

[_Ian]

Hi Melanie,

Actually, it doesn't seem to make a difference whether the value for STR is variable or constant.

Also, SKIP seems to be generating the same issues...If I:

debugin timeout, error, [wait(msg),_
tmp,tmp,tmp,_
tmp,tmp,tmp,_
tmp,tmp,tmp,_
tmp,tmp,tmp,_
tmp,_
payload[0],_ 'real data starts here
payload[1],_
payload[2],_
payload[3]]

Then I get the expected bytes in payload. But if I do this:

debugin timeout, error, [wait(msg), skip 13,_
payload[0],_
payload[1],_
payload[2],_
payload[3]]

Then I get four completely different bytes in payload. Moveover, they are not bytes that I can identify in the datastream, either before or after my four "target" bytes. But then, they are not random, either.

One thing that I did not mention before, I am running at a heck of a baud rate: 115200. My setup code looks like:

'=====DEFINES===================================== =======
DEFINE OSC 20

'======Outputs==================================== =======
DEFINE DEBUG_PACING 70
DEFINE DEBUG_REG PORTB
DEFINE DEBUG_BIT 6
DEFINE DEBUG_BAUD 115200
define DEBUG_MODE 1 'inverted

'======Inputs===================================== =======
DEFINE DEBUGIN_PACING 70 '(8 / BAUD) * 10^6 us
DEFINE DEBUGIN_REG PORTB
DEFINE DEBUGIN_BIT 7
define DEBUGIN_MODE 1 'inverted

Am I doing something really wrong, or can the Pic just not handle that high of a data rate? I think that it must be me, since I don't notice any other problems (dropped or corrupted data, etc), unless I try to use the STR or SKIP commands (WAIT works fine!).

**shrugs.
**grins.

Any suggestions?

Thanks again,

Ian

[Melanie]

I have used the example I gave you at low baud rates (eg 2400) without problems. It could be you're asking too much of your PIC. Try with a slower baud rate and move up in stages. Whenever I get problems I always revert to a known datum point where everything should work, and move forward from there.

[Bruce]

This works fine on a 16F876A @20MHz with PBP v2.46. I changed the port
pins, and used true mode through a max232, but it works as expected. With
or without the character pacing.


'=====DEFINES=====================================
DEFINE OSC 20

'======Outputs====================================
DEFINE DEBUG_PACING 70
DEFINE DEBUG_REG PORTC
DEFINE DEBUG_BIT 6
DEFINE DEBUG_BAUD 115200
DEFINE DEBUG_MODE 0 ' 1 = inverted, 0 = true

'======Inputs=====================================
DEFINE DEBUGIN_PACING 70
DEFINE DEBUGIN_REG PORTC
DEFINE DEBUGIN_BIT 7
DEFINE DEBUGIN_MODE 0 '1=inverted, 0=true

payload var byte[15]
reply var byte
msg con "~"
timeout con 5000 ' Note change from (timeout con byte)
reply = 5 ' receive 5 characters in payload string

Main: ' Display "Waiting..." every 5 seconds if timeout period expires
DEBUGIN timeout, error, [WAIT(msg), Skip 13, STR payload\reply]
Debug "Received: ", STR payload\reply,13,10
Goto Main

Error:
Debug "Waiting...",13,10
goto Main

End

Sending ~ABCDEFGHIJKLMNOPQR from MCS terminal to the PIC it displays;

Waiting...
Received: NOPQR ' ABCDEFGHIJKLM are skipped, NOPQR are received
Waiting...