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?

[Darrel Taylor]

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

Actually, you do.

Crownhill was very specific with the rules in this Announcement.
http://www.picbasic.co.uk/forum/announcement.php?f=4


But instead of hijacking threads, you are highjacking the whole forum.
At least 80% of all new posts are replied to first by skimask. Often in 5 minutes or less from the original post.

It's almost never a direct answer. And usually something like ... What have you done before, can you blink an LED, have you even looked at the datasheet. The answers are in the "Little Green Book".

As a moderator, I can not allow the forum to be dominated by someone that has clearly shown he has no idea how to write a program for PBP.

You could change that opinion, or you can stop doing what you're doing.

Your choice.
<br>

[skimask]

Actually, you do.
Crownhill was very specific with the rules in this Announcement.
http://www.picbasic.co.uk/forum/announcement.php?f=4
But instead of hijacking threads, you are highjacking the whole forum.
At least 80% of all new posts are replied to first by skimask. Often in 5 minutes or less from the original post.

The machine is on, I walk by, there it is... Usually, I answer during an F9, which on my dev system takes a little over a minute (haven't put together the new system yet to cut that time down).

It's almost never a direct answer. And usually something like ... What have you done before, can you blink an LED, have you even looked at the datasheet. The answers are in the "Little Green Book".

So, the answers are already there...

As a moderator, I can not allow the forum to be dominated by someone that has clearly shown he has no idea how to write a program for PBP.

Stop! You're hurting me!

General
This site hopes to provide an educational environment for people to discuss and share ideas that relate to melabs pic basic and pic basic pro products

Sharing ideas...
Now that's good. This isn't sharing. The bulk of the time it ends up being a give and take. A few give, a lot take.
And I just figured out what you meant by '2nd highest poster'. Didn't realize you could sort on 'Posts' under 'Members List'. Look at the number of 1-2-3 post users that never come back to share their experiences. Somebody gave, they took, and bailed out.

General posting rules and tips:
Please try to do some basic research before posting.
Most fundamental questions have already been asked and replied to ....many times. Use the Forum search feature.

Ya think this might apply to the bulk of the new thread? Maybe instead of 'It's in the book' or 'It's in the datasheet', I'll just start referring to this little bit and it should cover it...right?

I don't think anything else in there really applies (i.e. vulgar, illegal, etc).

[T.Jackson]

I think you've got some form of obsessive compulsive disorder Jeremy. There's some really good medication available to treat that sort of thing. Nothing to be ashamed of mate -- we all get sick throughout some stage of our lives. I personally had a mild case of depression a few years back.

Trent Jackson

[skimask]

I think you've got some form of obsessive compulsive disorder Jeremy. There's some really good medication available to treat that sort of thing. Nothing to be ashamed of mate -- we all get sick throughout some stage of our lives. I personally had a mild case of depression a few years back.

Trent Jackson

Yep, that's me...that's me...that's me...that's me...
I see that [Submit Reply] block and I can't pass it up....
I have to click on it.
Doesn't matter what the subject is...I have to click on [Submit Reply]
I aches to have me, just me, and only me click on [Submit Reply] I must [Submit Reply]

Let me know how it all works out for you when you get over it....or don't....preferably option #2...nah, never mind, take option #3...repeatedly...then again, I have been applying poly to my latest couple of projects...maybe I should ventilate a bit more...wait a minute! I'm outside. Well, not really outside, more of a screened-in greenhouse. How much more ventilation do I need? This laptop is hard to see in the sunlight. Do they make a pill for that too?

[T.Jackson]

I think it's a mild case because you're not really that particular with your work, as in being eccentric enough to the point where every non-critical bolt on an engine must be tightened exactly the same to a specific amount of torque when there's absolutely no need to.

Trent Jackson

[skimask]

What is this 'torque' you speak of?

And how tight should it be?

[T.Jackson]

What is this 'torque' you speak of?

And how tight should it be?

Well, in my humble opinion the only bolts on an engine that need to be tightened to a specific, exact amount of tension are the head bolts. In all other cases 1/4 to 1/2 a turn adequately suffices. Perhaps I'm wrong? I'm not a mechanic, but I am in the process of practically rebuilding a 2001 model, Ford Falcon AU2, XLS UTE.

Trent Jackson

[nomad]

what about the crank bolts? connecting rod end caps? hmm guess it's in the manuel. lol

[T.Jackson]

what about the crank bolts? connecting rod end caps? hmm guess it's in the manuel. lol

I haven't gone that deep into an engine yet. Done things like; head gaskets, water pumps, alternators, starter motors, radiators, heater cores (what a nightmare), brakes, exhausts. You're probably right in saying that there is a few other bolts that should be desirably torqued to (n) ft lbf -- foot pound force.

Trent Jackson

[manwolf]

All bolts have dataheets, all bolts have torque specs. Based on PICBaisc Forum replys all bolts must be torqued.

[T.Jackson]

All bolts have dataheets, all bolts have torque specs.

This is true. Robots need to know this information, therefore engineers will calculate a torque spec. But when a mechanic installs your new starter motor, those bolts will be tightened to approx 1/2 a turn, which is probably about 20 ft lbf at a very wild guess.

Trent Jackson

[Archangel]

Well, in my humble opinion the only bolts on an engine that need to be tightened to a specific, exact amount of tension are the head bolts. In all other cases 1/4 to 1/2 a turn adequately suffices.
Trent Jackson

You could make that assumption, and you would be wrong.

[nomad]

I usually just crank 'em down so they wont come off.

[T.Jackson]

You could make that assumption, and you would be wrong.

With regards to 1/4 to 1/2 of a turn I reference to Motorcraft components with what I'm saying. Namely the installation instructions for spark plugs and water pumps.

Trent Jackson

[T.Jackson]

I usually just crank 'em down so they wont come off.

Me too. I think you'll find that to be somewhere between 1/4 to 1/2 of a turn with a decent ratchet.

Trent Jackson

[Archangel]

Hmmm Nomad, you are probably turning bolts of not less than 18mm shank, Big old trucks, likely you are not getting them too tight, maybe not tight enough, Trent, I could argue this with you forever in OFF Topic area, I realize Having been both a Mechanic, and Machinist, engineers are a little over the top with specifications, but there really is some good science used to calculate torque specs. especially in failure prone areas like connecting rod bolts, main bearing bolts, carrier bolts, etc . . .

[rhino]

This is the kind of thread hijacking that turns me and I'm sure others off to this forum. Is it really necessary? Please, if you want to argue into oblivion, do it in your own thread in the Off Topic area.

[skimask]

This is the kind of thread hijacking that turns me and I'm sure others off to this forum. Is it really necessary? Please, if you want to argue into oblivion, do it in your own thread in the Off Topic area.

Refer to Post #3 and the end of Post #8...