SOLVED - Breaking HSERIN into separate parts

[Demon]

SOLVED in post #6:

https://www.picbasic.co.uk/forum/sho...164#post156164

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

USART

Is it "safe" to send HSEROUT header, data,

then receive:

- HSERIN header
(depending on header, use proper data format)
- HSERIN data

Or should I send Header and Data on 2 separate transmissions?

Objective:

I'm looking for a safe and simple way to transfer data of varying lengths.

Header is a prefix that identifies the data layout.

[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

[Ioannis]

The stop character in the Hserin command is needed if you do not know the length of the string.

Since you define the length at the beginning of the transmission, and then use it in the STR modifier, what is the point of "]" in that modifier? It will never engage!

Ioannis

[Demon]

... what is the point of "]" in that modifier? It will never engage!

Ioannis

That was one area that had me overthinking USART. STR ArrayVar\n{\c}, receives a maximum of n bytes, unless it receives character c.

If I misinterpreted the manual, I'd definitely appreciate being corrected before I code my entire project.


Initially I was copying what Pedja was doing, but I've since dropped the Length parameter and use only the StartOfData and EndOfData delimiters. I have a LOT of different Data Layouts, and calculating Length was becoming tiresome, and a possible source of human error. It's also cumbersome when you modify the Data Layout.

I am using variables in HSEROUT, an array (equal to the longest data layout) in HSERIN, which is then moved into variables depending on Header values; it's much more simple (for me).

[Ioannis]

OK, if you drop length then makes sense.

Using length variable in the STR modifier on the other hand, is very clever.

Ioannis

[Demon]

OK, if you drop length then makes sense. ...

Yeah, I updated my post with a comment to clear that.

Using length variable in the STR modifier on the other hand, is very clever. ...

I didn't field particularly clever after racking my brains trying to find the most efficient way to move data around.