PDA

View Full Version : HSEROUT using STR modifier - length parameter as variable not working



flotulopex
- 21st February 2021, 12:19
Hi there,

I'm using HSEROUT with the STR modifier and I can't find the way to set the number of characters "\n" in a variable instead.

While this works:

HSEROUT [STR BalBuffer\40,26,13]

...this doesn't:

BalCount VAR BYTE
BalCount = 40
HSEROUT [STR BalBuffer\BalCount,26,13]

It is to mention that it does compile without error in both cases.

I didn't try this one, but according to some other post (from Bruce in 2005), DEBUG/DEBUGIN seem to accept a variable for the charater value.

Is this a limitation for the STR modifier (= it has to be a number) in HSEROUT or is there a way to make it work with a variable?

HenrikOlsson
- 21st February 2021, 15:45
I don't know and I can't test/try if your code right now but a simple workaround would be

For i = 0 to BalCount ' (Or possibly BalCount-1)
HSEROUT [BalBuffer]
NEXT
HSEROUT [26,13]

flotulopex
- 21st February 2021, 17:14
Thanks Henrik,

I went this way already but so it is correct, the number of characters cannot be replaced by a variable.

Strange....

HenrikOlsson
- 21st February 2021, 17:28
Which device are you using?

I compiled two different version and looked at the .lst and with my limited understanding of assembly I'd say it "should work"

First, HSEROUT [STR Buffer\16]


movlw low (010h)
movwf R4 + 1
movlw low (low (HSEROUTJ))
movwf R8
clrf (R8) + 1
clrf R2 + 1
movlw low (low (_Buffer))
call SEROUT2STRN

Here it takes the literal 16 and moves it to the low byte (I think) of system variable R4.

Second, HSEROUT [STR Buffer\Length]


movf _Length, W
movwf R4 + 1
movlw low (low (HSEROUTJ))
movwf R8
clrf (R8) + 1
clrf R2 + 1
movlw low (low (_Buffer))
call SEROUT2STRN

Here it takes the Length variable, and loads THAT to the low byte (I think) of system variable R4.

In the actual serout macro it then decrements R4 to determine when it's done.

Ioannis
- 22nd February 2021, 07:35
Page 47 of the manual says "STR must be followed by a backslash and a number that specifies how many
characters (bytes) to collect."

So, as I understand it, it should be a number, not a variable.

If you want to change that on the fly, then Henrik's loop is the way to go.

Ioannis

richard
- 22nd February 2021, 08:23
it works for me

9023


;pic18f26k22 tx demo
#CONFIG
CONFIG FOSC = INTIO67
CONFIG PLLCFG = OFF
CONFIG PRICLKEN = OFF
CONFIG FCMEN = OFF
CONFIG IESO = OFF
CONFIG PWRTEN = OFF
CONFIG BOREN = SBORDIS
CONFIG BORV = 190
CONFIG WDTEN = ON
CONFIG WDTPS = 32768
CONFIG CCP2MX = PORTC1
CONFIG PBADEN = OFF
CONFIG CCP3MX = PORTB5
CONFIG HFOFST = ON
CONFIG T3CMX = PORTC0
CONFIG P2BMX = PORTB5
CONFIG MCLRE = EXTMCLR
CONFIG STVREN = ON
CONFIG LVP = OFF
CONFIG XINST = OFF
CONFIG DEBUG = OFF
CONFIG CP0 = OFF
CONFIG CP1 = OFF
CONFIG CP2 = OFF
CONFIG CP3 = OFF
CONFIG CPB = OFF
CONFIG CPD = OFF
CONFIG WRT0 = OFF
CONFIG WRT1 = OFF
CONFIG WRT2 = OFF
CONFIG WRT3 = OFF
CONFIG WRTC = OFF
CONFIG WRTB = OFF
CONFIG WRTD = OFF
CONFIG EBTR0 = OFF
CONFIG EBTR1 = OFF
CONFIG EBTR2 = OFF
CONFIG EBTR3 = OFF
CONFIG EBTRB = OFF
#ENDCONFIG








define OSC 8


DEFINE DEBUG_REG PORTB
DEFINE DEBUG_BIT 7
DEFINE DEBUG_BAUD 9600
DEFINE DEBUG_MODE 0
DEFINE HSER_TXSTA 20h
DEFINE HSER_BAUD 9600
trisb=$7f
OSCCON = $60 ; OSC 8
anselc = 0
BalBuffer VAR BYTE[60]
BalCount VAR BYTE
latb.7=1
for BalCount= 0 to 59
BalBuffer[BalCount]=BalCount+"0"
next
BalBuffer[59]=0
pause 2000
debug "ready",13,10






















BalCount = 40
HSEROUT [STR BalBuffer\BalCount,13,10]
debug STR BalBuffer\BalCount,13,10
debug "full load",13,10
debug STR BalBuffer,13,10
end

richard
- 22nd February 2021, 08:33
or even

9024



BalCount = 40HSEROUT [STR BalBuffer\BalCount,13,10]
debug STR BalBuffer\BalCount,13,10
debug "full load",13,10
debug STR BalBuffer,13,10
HSEROUT [STR BalBuffer,13,10]




for BalCount= 0 to 40
HSEROUT [STR BalBuffer\BalCount,13,10]
next
end

Ioannis
- 22nd February 2021, 08:41
Unfortunately Charles Leo is not monitoring this forum. I 'll make a post on support.melabs.com to clarify this, since the manual is not very clear on the matter.

I 'd rather be 100% sure that this is trusted all the time on all MCU's.

Ioannis

flotulopex
- 22nd February 2021, 09:54
Which device are you using?
It's the one I always use: 16F690.

flotulopex
- 22nd February 2021, 09:57
it works for me

Well, I'll give it a try with a 18F1220 when I'm back home tonight.

richard
- 22nd February 2021, 10:08
it fails of course for more than 255 chrs

9025




BalBuffer VAR BYTE[300]
BalCount VAR word
latb.7=1
clear
for BalCount= 0 to 59
BalBuffer[BalCount]=BalCount+"0"
next


for BalCount= 1 to 59
BalBuffer[BalCount+60]=BalCount+"0"
next
for BalCount= 1 to 59
BalBuffer[BalCount+120]=BalCount+"0"
next
for BalCount= 1 to 59
BalBuffer[BalCount+180]=BalCount+"0"
next
for BalCount= 1 to 59
BalBuffer[BalCount+240]=BalCount+"0"
next
BalBuffer[0]=13
BalBuffer[60]=13
BalBuffer[120]=13
BalBuffer[180]=13
BalBuffer[240]=13
pause 2000
debug "ready",13,10




BalCount = 40
HSEROUT ["40 ",STR BalBuffer\BalCount,13,10]
debug "40 ",STR BalBuffer\BalCount,13,10
debug "full load "
debug STR BalBuffer,13,10
HSEROUT ["full load ",STR BalBuffer,13,10]




BalCount = 255
HSEROUT ["255 ",STR BalBuffer\BalCount,13,10]
HSEROUT [13,10]
HSEROUT ["260"]
BalCount = 260
HSEROUT [STR BalBuffer\BalCount,13,10]
end

HenrikOlsson
- 22nd February 2021, 12:56
it fails of course for more than 255 chrs
Of course, since the macro only uses the low byte of R4 to index the array. That would also make it fail when using a constant >255.

In any case, the "example" posted in the first place had a BYTE sized variable with a value of 40 and everything we've seen this far is that it should (and ideed does, for 18F at least) work. I think I compiled for 16F628 when I looked at the .lst yesterday.

flotulopex,
You're going to have to post code that we can just compile, assemble and program into a chip that shows the problem.

flotulopex
- 23rd February 2021, 05:49
flotulopex,
You're going to have to post code that we can just compile, assemble and program into a chip that shows the problem.

Yup, I will do so asap.... Sorry, didn't have much time yesterday.

Ioannis
- 23rd February 2021, 11:54
Charles replied:

Yes, I believe it can be trusted with a variable. I've used this form to receive a variable number of characters based on a length parameter received immediately prior to the string:

[wait($80),length,STR idstring\length]

So officially it is valid syntax.

Ioannis

flotulopex
- 27th February 2021, 12:11
For now, here a my two test programs with 16F690 and 18F1220.

Surprisingly (to me), both accept the STR length as variable in the 3 ways I'm using it (HSEROUT, SEROUT2 and DEBUG).

I'll go back to my current program and try again....