16F or 18F ?
<br>
|
16F or 18F ?
<br>
DT
|
18F4620...Originally Posted by Darrel Taylor
Trying some asm at the moment...but I still know there's something easier and yet more compact than what I've got... just... what... is... it...
Spock...help... me ... here...
|
Here's a slight modification of the old Embedded String thread...Then you can do this...Code:lcdpx VAR byte lcdpy VAR BYTE Addr VAR WORD ASM PrintStr macro x, y, Str local TheString, OverStr goto OverStr TheString data Str, 0 OverStr MOVE?CB x, _lcdpx MOVE?CB y, _lcdpy MOVE?CW TheString, _Addr L?CALL _StringOut endm ENDASM Char VAR lcdchardata[0] StringOut: Readcode Addr, Char ' Get a character if Char = 0 then StringDone ' Look for Null char, Stop if found gosub puttext Addr = Addr + 1 ' Point to next character lcdpx = lcdpx + 1 goto StringOut ' Continue with rest of the string StringDone: return ;-----------------------------------------------------------------------------HTH,Code:@ PrintStr 0,0, "RESET ELM327..." @ PrintStr 0,1, "Hello World!"
DT
|
Actually, I just found what I was looking for a couple of minutes ago...and I think I'll kick myself now... how about a little LOOKUP !
But....I think I like your solution much better...
As soon as I figure out why my '4620 started double-resetting itself and locking up on initial powerup (without changing the code!!! left the room, came back, sat down, did a verify and it started!), I'll give it a whirl and see what happens. I see nothing but good stuff ('cept for that resetting bit. time to throw another chip I think).
|
Storing it as data in program memory uses about 1/4th the code space compared to LOOKUP.
If you'll have a lot of strings to display, it could save a big chunk of space.
Not that you need to worry about it with the 4620. (64kb)
<br>
DT
|
I just converted a few of my strings over to your format....
And after fighting with it for about an hour, I figured out that the thing is case sensitive...jeeze...what next...
I'm up to 40K used out of 64K on the '4620, might have to go to a 4685 (or maybe even an '8722 with my little 40 pin adapter I built awhile back). Hopefully this little routine helps me save a LOAD of space. I'm not even halfway done with my program yet.
|
Well, using an external EEPROM have it's advantages as well. If you Strings are LCD dedicated, you can also format them the right way in a HEX Editor.
I use bpsoft Hex WorkShop.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
|
Kudos to you and all that. I just went thru and converted all of my major string routines to your embedded routine example.
So far, I've saved 7,486 in code space (started with $9C22, now I'm only using $7EE4 of space).
And I've still got to optimize the rest of the code...
|
Sweet!
Let me know how it is after optimizing the rest. Just for curiosity sake.
<br>
DT
|
Not quite optimization...or is it?
Got a modification of the PRINTSTR macro for my nokia lcd...
Is there a conditional directive that'll "overload" (I suppose like C++) the PRINTSTR macro to either accept or ignore 2 extra parameters?Code:ASM PrintStr macro x, y, Str local TheString, OverStr goto OverStr TheString data Str, 0 OverStr MOVE?CB x, _lcdpx MOVE?CB y, _lcdpy MOVE?CW TheString, _Addr L?CALL _StringOut endm ENDASM StringOut: Readcode Addr, Char : if Char = 0 then StringDone ' Look for Null char, Stop if found gosub puttext : Addr = Addr + 1 : lcdpx = lcdpx + 1 : goto StringOut StringDone: return
In my case, I want to add foreground color and background color, but not neccessarily one or both at the same time...like this
If both are there, great, process them as normal.Code:PrintStr macro x, y, Str , forecolor , backcolor
If the background color value isn't there, ignore it and don't change it.
If the foreground color value isn't there, ignore both of them and don't change either.
Sure, it's easy enough to make 3 different versions of the same thing, and use 3 different names, i.e. printstr, printstrf (set foreground only ), printstrfb (set both foreground/background), printstrb (set background only).
If I assumed null-zero's would work, that would be fine except that I'm dealing with 8 bits of color (soon to be 16) and a zero-null is a valid color.
|
Well, as far as i'm aware of, MPASM don't provide any features like that. If you don't fill all arguments, it will prompt you. That's one downside.
So you'll probably need to build some different version of you macro, one calling the other or variant of.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
|
It'll prompt me all-right...prompt me with an error message!
I've been pouring over the MPASM documentation looking for some insight into 'overloading' macros like I want to do and not finding anything interesting. I guess it's back to multiple versions of the same thing, but different. It's either that or I'm going to try a version with a 'mode number' in the front, sort like that multiple LCD mod on another thread...So you'll probably need to build some different version of you macro, one calling the other or variant of.
@ printstr 1 , 5 , 5 , "works here" - mode 1 - no color modify
@ printstr 2 , 5 , 5 , 1 , "works here" - mode 2 - foreground color change...
...and so on...
Let the code in the macro do the choosing based on the mode number.
But if I go that way, I may as well have different versions.
More thought required...
|
That's one of only 2 circumstances in which I would prefer PM.EXE
With PM, you are not limited to a specific number of parameters supplied to a macro.
If paramaters are ommited, they show up as "undefined".
Then you can just do a IFNDEF to see if a parameter was included or not.
The second circumstance is IRPC, which can split up each character of a string and repeat the macro for each one.
However, since PM can't "Nest" macro's. It doesn't help a bit.
Not to mention the 18F problem.
And like you've both already pointed out...
MPASM can't do either one of them.
<br>
DT
Members who have read this thread : 0You do not have permission to view the list of names.
Posting Permissions
Bookmarks