HSerGetString

[Jim giordano]

I'm having trouble with HSerGetString trashing one of my string variables.

Here is the program

#option Explicit

#chip 16f1765,32
#startup InitPPS, 85
#define PPSToolPart 16LF1765
Sub InitPPS
 Dir PORTC.3 Out
 RC3PPS = 0x0016    // TX > RC3
 RXPPS = 0x0004    // RA4 > RX
End Sub

#define USART_BAUD_RATE 115200
#DEFINE USART_TX_BLOCKING
#DEFINE USART_DELAY OFF

wait 100 ms
dim mystr as string
dim t1,t2 as String
mystr="123.456"

HserPrintCRLF
hserprint "mystr before HSerGetString <"
HSerPrint mystr
hserprint "> len="
hserprint len(mystr)
HserPrintCRLF
hserprint "hit enter for next step"
HSerGetString t2
hserprint "mystr after HSerGetString <"
HSerPrint mystr
hserprint "> len="
hserprint len(mystr)
HserPrintCRLF

When I run this, I get-

mystr before HSerGetString <123.456> len=7
hit enter for next step
mystr after HSerGetString <yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy> len=121</yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy>

I have attached the code, asm, and lst files.

[Jim giordano]

don't know why the previous post is showing

mystr after HSerGetString <yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy> len=121</yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy>

at the end. I've edited it twice, but can't get rid of whatever is causing the post to show extra stuff after len=121, it shouldn't be there.

[mmotte]

i think what you need is
<#define USART_BLOCKING/>

Also the the string is can only be up to 40 bytes unless dim ed other.

[Jim giordano]

Thank you.

Yes, using USART_BLOCKING works, but I still don't understand why it trashed a completely unrelated variable.

In the help for HSerGetString, it says to use the USART_TX_BLOCKING, but down in the example, it used USART_BLOCKING, so a little confusing. (Same for HSerGetNum.)

I'm not sure what you meant by
"Also the the string is can only be up to 40 bytes unless dim ed other."

I certainly didn't want the program to set the length of mystr to 121. It seems the length wasn't actually 121, that was just trash the HSerGetString wrote into byte zero of mystr. (121 is another of those y's).

I can't think up any scenarios where HSerGetString would get a bunch of y's, there was nothing being transmited. The default for not using USART_BLOCKING would be a 255 character according to the help. Or you could set it to something else if you wanted.

If HSerReceive had return the default 255 to HSerGetString, then all would have been good because HSerGetString would have discarded the 255's and continued waiting for a 13. So where did the 121's come from?

So, yes, USART_BLOCKING makes the problem go away, but something in GCBasic needs a little work somewhere to stop this memory trashing from happening.

And thanks again for you help, it is appreciated.

[Jim giordano]

Yesterday I ran this many times with the same result, bunches of 121 characters.

Today, with everything exactly the same, no more 121 characters. ??

The only thing I can figure is that it was some problem with the driver on my computer that cleared up with a reboot this morning.

Please disregard this whole mess.
Sorry for wasting all your time.