copy-string 'function'

[skimask]

Whadaya think? Is it going to work?
I based this off of Mr_E's simple print-string routine originally written for an LCD, adapted for my GLCD, now adapted to copy a string within the source over to a string array...basically so I can send it out with a serout or lcdout command.

string var byte[255] : stringpos var byte

ASM
copystr  macro  str
	local  thestring , overstr
	goto  overstr
thestring
	data  str , 0
overstr
	MOVE?CW  thestring , _addr
	L?CALL  _copystring
	endm
ENDASM

copystring:  stringpos  =  0
copystringloop:
                READCODE  addr ,  char
                if char = 0 then copystringdone
		string[ stringpos ] = char
                stringpos = stringpos + 1
                if stringpos < 255 then copystring1
copystringdone:
                stringpos = stringpos + 1
                string [ stringpos ] = 0
                if stringpos < 255 then copystringdone
                return

Now the statement:

@ copystr "TEST STRING"

should end up with the variable string with "TEST STRING" with the remainder of the array zero'd.
(and look...only one colon )

[Darrel Taylor]

Nope.

You are incrementing the stringpos variable, but using addr in the readcode. It'll be reading the same byte over and over.

There is no copystring1 label.

It shouldn't be necessary to zero out the rest of the array. A single 0 at the end of the string should be sufficient to mark the end.

And it's only good for 18F's.
Probably just what you're using, but what about the other guy's?

You put it in the Code Example's forum.
Typically, this is for Tested, known to be working code.

[skimask]

DOH...DOH...DOH...DOH...and...uh...DOH! That's what I get for coding at 2am.
Slide it over to the Off-Topic if you get a chance.
I was looking over the posts from a couple years ago concerning the embedded HSEROUT/string routines at the time, probably why it ended up in 'Code Examples'.

[Darrel Taylor]

skimask,

I see that you have linked to this thread a few times as a possible solution to people's problems. But you never did finish it.

It certainly won't work like it is.
<br>

[skimask]

Good point!!!

Take 2.2 .....................

I based this off of Mr_E's simple print-string routine originally written for an LCD, adapted for my GLCD, now adapted to copy a string within the source over to a string array...basically so I can send it out with a serout or lcdout command.

Set up for use with PIC18Fxxxx series PICs using PBP 2.50 and above (PBPL).

string var byte[255] : stringpos var byte : addr var long : char var byte
'if using PIC with less than 64K flash, don't need to use PBPL, can change
'addr from LONG to WORD

ASM     'macro must be placed in program before its first use
copystr  macro  stringcopy
	local  thestringcopy , overthestring
	bra overthestring
thestringcopy
	data  stringcopy , 0
overthestring
	MOVE?CW  thestringcopy , _addr
;It is necessary to use CN in place of CW to cover the case when the
;copystring statement is located above 64K (i.e. PIC18F4685, '8722, etc.etc.)
	L?CALL  _copystring
	endm
ENDASM

copystring:          stringpos  =  0
copystringloop:     READCODE  addr ,  char : if char = 0 then copystringdone
                         string[ stringpos ] = char : addr = addr + 1
                         stringpos = stringpos + 1
                         if stringpos < 255 then copystringloop
copystringdone:   string[ stringpos ] = 0 : stringpos = stringpos + 1
                         if stringpos < 254 then copystringdone
                         return

Now the statement:

@ copystr "TEST STRING"

Should result in the variable array STRING with "TEST STRING" with the remainder of the array zero'd.[/QUOTE]

[Darrel Taylor]

Take 2......................

string var byte[255] : stringpos var byte

ASM
copystr  macro  stringcopy
	local  thestringcopy , overthestring
	goto  overthestring
thestringcopy
	data  stringcopy , 0
overthestring
	MOVE?CW  thestringcopy , _addr
;It is necessary to use CN in place of CW to cover the case when the
;copystring statement is located above 64K (i.e. PIC18F4685, '8722, etc.etc.)
	L?CALL  _copystring
	endm
ENDASM

copystring:          stringpos  =  0
copystringloop:     READCODE  addr ,  char : if char = 0 then copystringdone
                         string[ stringpos ] = char : addr = addr + 1
                         stringpos = stringpos + 1
                         if stringpos < 255 then copystringloop
copystringdone:   string[ stringpos ] = 0 : stringpos = stringpos + 1
                         if stringpos < 254 then copystringdone
                         return

I think you'll need a "Take 3".
Still has the same problems mentioned in post#2
<br>

[Darrel Taylor]

I based this off of Mr_E's simple print-string routine originally written for an LCD, adapted for my GLCD, now adapted to copy a string within the source over to a string array...basically so I can send it out with a serout or lcdout command.

You didn't get it from mister-e

While we're on the subject of optimization...
http://www.picbasic.co.uk/forum/showthread.php?p=30533

But really, this things got some serious shortcomings.

What if the person doesn't want a 255 byte string? Maybe they only need 32. Your routine will wipe out other variables well beyond the array.
What if they have more than 1 array? It only copies to an array called string.
What if they're using a 16F?
Why do they have to manually change MOVE?CW to MOVE?CN. Why not detect when PBPL is used, or have a separate macro for 32-bit addresses. Or better yet, do the tblrd's or EECON rd's manually, instead of relying on ReadCode. Then it's easy to handle over 64k or 16F's. Even without 2.50

Make it a true "PBP Extension".
<br>

[skimask]

You didn't get it from mister-e

Well, then edit my 1st post to properly credit the original author. (You, Bruce, I don't remember where I first saw it, but I don't think it was in the optimization thread. I think it goes farther back than that to a thread about sending arrays out using SEROUT or something along those lines)

What if the person doesn't want a 255 byte string? Maybe they only need 32. Your routine will wipe out other variables well beyond the array.

It shouldn't wipe out anything the array is declared at 255 bytes (except that the stringpos would probably need to be defined as a word rather than a byte). If they only want 32, and they're advanced enough to be messing around with macro's, then I would think that a thinking person, which is becoming a rarity these days, would be able to figure out how to shorten the string to X number bytes.

What if they have more than 1 array? It only copies to an array called string.

Again, a thinking person should be able to figure out how to copy 'string' to another array the old fashioned way.

What if they're using a 16F?

Maybe they should think about moving over (not necessarily UP) to an 18F.

Why do they have to manually change MOVE?CW to MOVE?CN.

The macro only has to be changed once depending on the PIC's total memory. CW works up to 64K, CN works below 64K. Why not just leave it as CN all the time? CN takes more space.

Why not detect when PBPL is used,

The person compiling the program should be able to figure out quick enough if they use a LONG (i.e. the addr variable) that they need to use PBPL (they'll get an error otherwise). Says right in the manual that LONGs need PBPL. A person can type, a person must be able to RTFM.

or have a separate macro for 32-bit addresses.

Sure...let's complicate things just a bit more, make it a bit harder to remember which macro to use.

Or better yet, do the tblrd's or EECON rd's manually, instead of relying on ReadCode. Then it's easy to handle over 64k or 16F's.

The code works great for me. I don't remember stating that it was an 'All Inclusive' fix it for everybody. And ReadCode seems to work well above 64K with PBPL.

Make it a true "PBP Extension".

For me, it is an Extension...

Move the thread over to 'Off Topic' or 'Bluetooth' or something.

[Darrel Taylor]

I don't remember where I first saw it, but I don't think it was in the optimization thread.

Right ... Which must be why both ...

Nokia COLOR LCD PicBasicPro 2.50a example code
http://www.picbasic.co.uk/forum/showthread.php?t=8135

122x32 GLCD basic code
http://www.picbasic.co.uk/forum/showthread.php?t=6574

have the exact same macro and code.
Except it's Colonized.<hr>

It doesn't surprise me at all that you refuse to follow thru.

That's pretty much your normal approach. Never answer directly, make them look it up in that "Little Green Book". Examples must be modified to work, and I'm not writing it for you.

And just like the way you say how other people's work won't pass by the instructors at the classes you take in the AF. &nbsp; If you were to show your only code examples (linked above), to a programming instructor ... well, after he got up off the floor from laughing, he'd write a big red F on the front.

So before you start your next "It's in the book" or "if you had read the datasheet".

Let's see if you can actually write a program. Not even a program really, just one simple function that works with PBP. Not chip specific, not version specific, just PBP compatible, that covers what people would need to do to copy a string from Flash. It should also pass those "instructors".

As the second highest poster on this forum, you really should have at least 1 "Passing" code example.

[skimask]

It doesn't surprise me at all that you refuse to follow thru.
That's pretty much your normal approach. Never answer directly, make them look it up in that "Little Green Book". Examples must be modified to work, and I'm not writing it for you.

Sounds like 'Instant Gratification' rules again. Give a guy a simple direct answer for a simple problem and that same guy will be back for more 'cause that person didn't figure out how to read and/or look for something somewhere else.

And just like the way you say how other people's work won't pass by the instructors at the classes you take in the AF.

Because most of the work that I have to do almost ALWAYS involves lives and/or equipment, most of the equipment 'one-off' or 'limited asset' type, or otherwise 'secret squirrel' stuff. You have to agree that the bulk of the work/code/schematics here are done by hobbyists and not people out for a buck or two (although it would be nice), and most likely doesn't have any time constraints placed upon it, therefore, time spent researching a problem, trying to figure it out wouldn't be a bad investment by the end user.

If you were to show your only code examples linked above, to a programming instructor ... well, after he got up off the floor from laughing, he'd write a big red F on the front.

Well, I'm not in any sort of class, I don't have to show my code to an instructor, I don't have to have it pass any others criteria except my own, and my main question at the end of the day is 'Does it work right?'. And besides that, how much 'real world' experience does the average instructor actually have?

So before you start your next "It's in the book" or "if you had read the datasheet". Let's see if you can actually write a program.

Even though you've never seen the stuff in person, you know as well as others probably do, that I've got plenty of working projects out there, both posted on that webpage of mine and otherwise. I don't think I'd still be doing this if I couldn't read a manual or a datasheet. I just discovered these forums a couple of years ago. Before that, nothing, just datasheets and printouts.

Not even a program really, just one simple function that works with PBP. Not chip specific, not version specific, just PBP compatible, that covers what people would need to do to copy a string from Flash. It should also pass those "instructors".

Tell that same thing to the guys at MeLabs and Microchip... Get THOSE guys to make PBP and MPASM compile and assemble an identical copy of the same program, any program, across all of the PIC families, all of the PIC revisions. But since we're talking PBP here, get the guys at MeLabs to write PBP so it'll compile 'BLINKY' so it'll work, first time, across all PIC devices, without the end user having to change around the CONFIG fuses to get 'BLINKY' to work. I mean the most popular answer to a problem here has to be along the lines of 'Set ADCON1 to this or ANSEL to that'. That's nothing new. The answer is in the PBP manual, it's in the datasheets, it's in the FAQ here, and yet we see that same question literally a few times a week. Why hasn't anything been done about that at MeLabs or Microchip (MPASM)? Well, except for the 'new' CONFIG bit in the newer PICs for bringing up A/D ports to digital on reset, which again, is that CONFIG bit set for analog or digital by default?

As the second highest poster on this forum,

Second highest poster? Poster of what? Poster child for colons:?

you really should have at least 1 "Passing" code example.

Passing who's criteria? Yours? Mine? The next noob to register?