But it has to stop sometime.
When you add a final ,0 to the end of the line, DA generates a 0x0000 word. So only if the whole word is 0 will it consider it the end of the "string".
Any other 0 characters within the "string" are ignored.
<br>
But it has to stop sometime.
When you add a final ,0 to the end of the line, DA generates a 0x0000 word. So only if the whole word is 0 will it consider it the end of the "string".
Any other 0 characters within the "string" are ignored.
<br>
DT
Got it..
Code:StringOut: ' Send the string out via Hserout Readcode Addr, TwoChars ' Get the 14 bit packed characters IF TwoChars then Char = TwoChars >> 7 ' Separate first char if Char then ' Look for Null char, Don't send if found hserout [Char] ' Send first char endif Char = TwoChars & $7F ' Separate second char if Char then ' Look for Null char, Don't send if found hserout [Char] ' Send the second char endif Addr = Addr + 1 ' Point to next two characters goto StringOut ' Continue with rest of the string ELSE Addr=Addr+1 Goto StringOut ENDIF return
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
NARGH forget the above. It depend on the previous and the next string... wich doesn't happen with my first version with DT...mmm
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Well, if we want to create and send a mix of String and Numeric Value, da is not the one to use even if it gives some codespace advantages.
O.K. for Text String only. So i'll stick to my first solution that used dt
Thanks for the tips anyway !
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Hi Guys,
Hope you don't mind me butting in...
I've been using a similar method for 18F' devices in assembler for awhile now and I wonder if you might need to account for the occasional odd length character string to make sure the address is word aligned before placing it back into TOS?
Regards, Mike
Code:; ; Example macro usage ; _Title "K8LH Az/El Controller\r\n\n" _Print "Satellite AOS:\r\n" _Print "Satellite LOS:\r\n" ;****************************************************************** ; ; print the in-line string using Stack Pointer & TBLPTR ; PutString movff TOSH,TBLPTRH ; copy SP address to TBLPTR movff TOSL,TBLPTRL ; clrf TBLPTRU ; PutNxt tblrd *+ ; get character movf TABLAT,W ; last character (00)? bz PutXit ; yes, exit rcall Put232 ; else, print character bra PutNxt ; do another PutXit btfsc TBLPTRL,0 ; odd address? tblrd *+ ; yes, make it even (fix PC) movf TBLPTRH,W ; movwf TOSH ; update the return stack movf TBLPTRL,W ; movwf TOSL ; return ; ; ;******************************************************************
Last edited by Mike, K8LH; - 29th August 2005 at 03:02.
I'm using this for my LCD display, but what if....
I want to send two lines of text to my LCD?
Normally we would send $FE, $C0 to start the second line but coding this doesn't work using your example....
@ da "First line",$FE,$C0,"Second Line",0
I see you guys are doing this when sending serial data, by adding 13,10,0 to the string.
Cheers
J
using DA it won't work. Da pack two ascii character in a 14bit packet... 2X7Bits
$FE (wich should be write h'FE') is over the 127 dec or 7F Hex.
What you can do is to use something else something like
Code:DA "first line",1,2,"Second Line",0 . . . If char = 1 then char = $FE If char = 2 then char = $C0
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
I use DEBUG to get to my serial pic LCD readout at 2400 baud. I have been trying to replace the hserout functions in the "string storage" thread with my usual debug output with no luck. I get repeating characters but not the expected string. I see now where there may be an issue because of the 14 bit word length but how to correct this is not clear.
Last edited by Homerclese; - 9th March 2007 at 06:23.
Thanks,
Homerclese
Bookmarks