Losing data when extracting bytes from words - 16F18855

[Demon]

This is when I run it up to 1990, and repeat the 90 series at the bottom; always the same numbers are messed up.

Missing HSEROUT v4.pdf

[Demon]

I just noticed something. It didn't wait for the 90 series to complete.

Something is not always working with my OK reply.




EDIT: Confirmed, I checked the longest saved SALEAE session. All the series that are chopped are missing numbers that relate with how early the TX started on the RX PIC. It didn't wait for the HSERIN to complete, and took off running.

I can't explain why it's always the same series.


Something tells me the DEFINES are different for this PIC, and I blindly copied over existing code.

[richard]

You will notice you never receive the data from 93 onwards

since your terminator is "]" <==> ascii 93

[Demon]

You will notice you never receive the data from 93 onwards

since your terminator is "]" <==> ascii 93

Ok, but what about these guys?

[0340 0341 0342 0343 0344 0345 0346 0347 0348 0256]
[0860 0768 0000 0000 0000 0000 0000 0000 0000 0000]
[1110 1111 1112 1113 1114 1115 1116 1024 0000 0000]
[1620 1621 1622 1623 1624 1625 1626 1627 1628 1536]
[1880 1881 1882 1883 1884 1792 0000 0000 0000 0000]        <---- this one does have a 93

EDIT: What would you suggest as a good delimiter? I have no idea what would avoid this stuff.

[richard]

349 dec = 0x15d 0x5d = dec 93 <==> ascii "]"

[Demon]

Right.

In mainframe programming, we used high-values.

Is x'FF' is viable option in PBP?


EDIT: This doesn't work, even if tilde is at 126. Some still get triggered.

hserin [ wait("~"), STR MsgData\21\"~" ]

EDIT SOME MORE: it works fine if I don't use delimiters. I'll be sending text and numbers so I don't see a way out, I have to leave the ends "free".

[richard]

the start and finish characters cannot be allowed in the data body of your message using your simplistic scheme ;

there are much simpler and more reliable methods