SOLVED - Breaking HSERIN into separate parts

[pedja089]

I used something like this
On transmis side
HSEROUT "DataStart:",Len, str data\Len, chksum
on receive side
HSERIN wait("DataStart:"), Len, str data\Len, chksum

[Demon]

I used something like this
On transmis side
HSEROUT "DataStart:",Len, str data\Len, chksum
on receive side
HSERIN wait("DataStart:"), Len, str data\Len, chksum

Interesting. Do you have a sample code of how you process the string array at reception?

I had been looking at HSEROUT in the manual, but I should have been looking at HSERIN; that has more options.

[pedja089]

I do not have it right now.
String is just array. You can fill each byte separatly.

[Demon]

My dilemma is having multiple record layouts, and having the receiving PIC figure out which format to use.

Using an array long enough to fit the largest transmission seems like a waste to me. My messages will range from sending a single value, to the entire set (possibly 30 values).

One alternative is to blindly use the longest possible array on reception, even if I only send one value. I have no clue if that opens up a can of worms.

I see that you can add a LENGTH parameter, maybe that can be used (got some testing to do).

[Demon]

I think I figured out what's written in plain English right in my face:

STR ArrayVar\n{\c}
Receive string of n characters optionally ended in character c

It looks like I can:

- define the array at the longest possible length,
- stop reception on character c,

This way I can embed a Data Layout Number at the start of the message, and use that to branch to code to treat the array properly.

I understand quickly, you just have to be patient and explain it to me a whole bunch of times.

[Demon]

EDIT: Length parameter has been removed, I only use StartOfData and EndOfData characters now.

-------------------------------------------

Yeah, i was waaaay overthinking this.

Transmitting (16F18877):

XmitStr                 CON "["
XmitCode1               var BYTE
XmitCode2               var BYTE
XmitNumber              var BYTE
XmitLen                 var byte
XmitChecksum            var WORD
XmitEOF                 CON "]"


    TX1STA.5 = 1

    XmitCode1  = "A"
    XmitCode2  = "A"
    XmitNumber = 8
    XmitLen    = 8

    XmitChecksum =  XmitStr + _
                    XmitCode1 + XmitCode2 + XmitNumber + XmitLen + _
                    NAV2_MHz_Standby + _
                    NAV2_KHz_Standby
                
    BlinkLED1 = 1
    hserout [   XmitStr, _
                XmitLen, _
                XmitCode1, _
                XmitCode2, _
                XmitNumber, _
                NAV2_MHz_Standby, _
                NAV2_KHz_Standby, _
                XmitChecksum.BYTE1, _
                XmitChecksum.BYTE0, _
                XmitEOF]                            
    BlinkLED1 = 0

    while TX1STA.1 = 0              ' Check TRMT bit
    wend
 
    TX1STA.5 = 0

Receiving (18F26K22):

RecvStr                 con "["
RecvLen                 var BYTE
RecvCode1               var BYTE
RecvCode2               var BYTE
RecvNumber              var BYTE
RecvChecksum            var WORD
RecvEOF                 var BYTE

    hserin [ wait(RecvStr), STR RecvData\11\"]" ] 

    RecvLen             = RecvData[0]
    RecvCode1           = RecvData[1]
    RecvCode2           = RecvData[2]
    RecvNumber          = RecvData[3]
 
'           check Code1/Code2/Number, execute proper code for that record layout.

    NAV2_MHz_Standby    = RecvData[4]
    NAV2_KHz_Standby    = RecvData[5]
    RecvChecksum.byte1  = RecvData[6]
    RecvChecksum.byte0  = RecvData[7]

It helps to send data 1 byte at a time, or else you get garbage.

[Demon]

16F18877

Transmitter Enabled/Disabled to have more than 1 PIC transmitting (using a Busy Line to determine which PIC can talk).

'          Enable Transmitter
    TX1STA.5 = 1 

... transmit ...

'          Make sure all data is sent
    while TX1STA.1 = 0              ' Check TRMT bit
    wend

'          Disable Transmitter
    TX1STA.5 = 0