LCDout and large filesize 18F452 -> paging problem?

[mara]

Howdy,

LCD is in portD (data=D.0-D.3,RS=D.4,En=D.5)
TRISD = %01000000 (D.6 is input)
LCDout interferes pin D.7 as program size grows
PortD.7 = 1 won't make pin high...
pulsout portD.7,10000 still works... cannot figure it out.. o:-)

If I decrease code size, the problem disappears...
Has anyone faced same kinda problems?

thnx adv.
m.

[skimask]

Post the code...

[mara]

Code is basicly like this:

DEFINE LCD_BITS 4
DEFINE LCD_DREG PORTD
DEFINE LCD_DBIT 0
DEFINE LCD_RSREG PORTD
DEFINE LCD_RSBIT 4
DEFINE LCD_EREG PORTD
DEFINE LCD_EBIT 5
TRISD = %01000000
LED VAR portD.7
...
--->8---(klipeti-klipeti)--->8--- (lots of stuff)
...
Lcdsub:
lcdout $FE,2,"hello"
lcdout $FE,C0,"world"
return
...
main:
LED=1 ' This should illuminate the led?
gosub Lcdsub
pause 500
LED=0
pause 500
goto Main

So, if I replace LED=1 with pulsout portD.7,65530 it will blink..
Otherwise it wont.. BUT..
If I remove gosubs away, LED=1 will work and it LED will blink..




Post the code...

[skimask]

--->8---(klipeti-klipeti)--->8--- (lots of stuff)
...
...


It's this that makes it suspicious.


And which version of PBP are you using?

[mara]

> It's this that makes it suspicious.
yep, I know.. the code is 500 lines...
I just tried to save some bandwidth.. o:-)

> And which version of PBP are you using?[/QUOTE]
pbpro v:2.50a and uCodeStudio+ v:3.005

[skimask]

Ok, how about this code, and ONLY this code:



DEFINE LCD_BITS 4
DEFINE LCD_DREG PORTD
DEFINE LCD_DBIT 0
DEFINE LCD_RSREG PORTD
DEFINE LCD_RSBIT 4
DEFINE LCD_EREG PORTD
DEFINE LCD_EBIT 5
TRISD = %10000000
LED VAR portD.7
Lcdsub: lcdout $FE,2,"hello" : lcdout $FE,C0,"world" : return
main: LED=1 : gosub Lcdsub : pause 500 : LED=0 : pause 500 : goto Main
END

[mara]

> Ok, how about this code, and ONLY this code:

Well, I dunno.. BUT I got another question..

What would happen if IF-THEN-ELSE overlaps from memory-page to another? Is it allowed? Is pbp-compiler capable of handle veeeeery loooooong IF-THEN-ELSE structures (like 200lines long?) including gosubs from page to page? If not-should I get a warning? o:-)

[skimask]

> Ok, how about this code, and ONLY this code:
Well, I dunno.. BUT I got another question..
What would happen if IF-THEN-ELSE overlaps from memory-page to another? Is it allowed? Is pbp-compiler capable of handle veeeeery loooooong IF-THEN-ELSE structures (like 200lines long?) including gosubs from page to page? If not-should I get a warning? o:-)

I don't have any problem with what you're talking about, with 2.50a anyways. But quite frankly, I just avoid it altogether by just making the 'middle' of the If/Then another routine.
I've had some programs (one in particular), over 4300 lines long (and that's compacted with a lot of colons like I do often, uncompacted, figure roughly 13,000+ lines). Never had a problem with the amount of code inside of an If/Then, Select Case, While/Wend, or otherwise.

You tend to forget things like RETURN after a GOSUB, or maybe you RETURN from somewhere that you had GOTO'd instead of GOSUB'd. Keep that in mind. I just fixed a buried GOSUB (one of the drawbacks of 'compacting' source code) that would only show up after the loop went thru itself 32 times and ended up causing a stack overflow which killed my entire OS on the one project. I've been fighting it for over 6 months now.

And paging really isn't so much of an issue, moreso with 18F series PICs, and even moreso with PBP for the last few years.

[mara]

> You tend to forget things like RETURN after a GOSUB..

Yep, gosubs and if-then-else-endif structures are like women-
one has to be veeery careful with them.. o:-)

I downsized the code a little bit - any comments?

It works if naytto is low,
If naytto is high then portD.7 wont go high (except pulsout-command)

[skimask]

> You tend to forget things like RETURN after a GOSUB..
Yep, gosubs and if-then-else-endif structures are like women-
one has to be veeery careful with them.. o:-)
I downsized the code a little bit - any comments?
It works if naytto is low,
If naytto is high then portD.7 wont go high (except pulsout-command)

Yes, does the code in Post #6 work?

[mara]

> Yes, does the code in Post #6 work?
Well, did ya mean reversing direction-bit of portD.7?
I don't think it would resolve the problem-
in this case the problem is deepper-I think it is in compiler...
The code works ok, only the LCDout routine is causing problems..
(=jamming portD.7)

m.

[skimask]

> Yes, does the code in Post #6 work?
Well, did ya mean reversing direction-bit of portD.7?
I don't think it would resolve the problem-
in this case the problem is deepper-I think it is in compiler...
The code works ok, only the LCDout routine is causing problems..
(=jamming portD.7)

m.

Ok, typo on my part...
TRISD = %10000000 should have been
TRISD = $40

Did it work or not?

Looking at your program as a whole, I think the problem is that the LED is actually coming on, but that it flickers too fast for you to see it. With the pulsout, you are seeing a .13 second pulse, if your code says something to the effect of:
LED1 = 1
LED1 = 0
then you probably won't see it come on at all...unless you got really super special eyes.

[mister_e]

Be careful with 18Fs.. when you write to a PORT you should use LATx instead of PORTx. If you write to adjacent bits, you should write to a shadow register first, then copy it to the whole port to avoid the Read-Modify-Write behaviour.

I would tend to change the LCDOUT statement... reading the Magn bit (from PORTD.7), save the result to a Temp variable then after show the result. When writing to Magn, you use LATD.7.

[skimask]

Be careful with 18Fs.. when you write to a PORT you should use LATx instead of PORTx. If you write to adjacent bits, you should write to a shadow register first, then copy it to the whole port to avoid the Read-Modify-Write behaviour.

I would tend to change the LCDOUT statement... reading the Magn bit (from PORTD.7), save the result to a Temp variable then after show the result. When writing to Magn, you use LATD.7.

I've never used, or had to use, LATD.x on the 18F's.
But if you say it takes care of some of the R-M-W issues, then it must be true.

[mara]

> I've never used, or had to use, LATD.x on the 18F's.
> But if you say it takes care of some of the R-M-W issues,
> then it must be true.

This might be worth deepper inspection..

I'm sorry I didn't identify the problem clearly-basicly LCDout works just fine. LCD-display can be used only for testing purposes cause it's so damn slooooow.. o:-) That's why all lcd-routines are normally bypassed by "naytto" input signal. Only problem is that if I want to use LCDout for testing, it will shut down (low) portD.7 output (MAGN) as well.. There cannot be hardware problem cause in next line I put pulsout portD.7,65530 command for testing purposes and it will flash Led in portD.7 but I cannot understand why in previous line command portD.7=1 (Magn=1) will NOT illuminate the same led.. (see line marked in RED=near lines 145 and 182)

[mister_e]

as i said, you want to use LATD instead of PORTD. Pulsout also do more than a single PORT/LAT=x. If my memory serves me well it set the TRIS.. then do what it has to do. Hence wasting a few instruction cycle before and after... why the R-M-W behaviour don't happen.. or is reduced to a minimum.

[mara]

> as i said, you want to use LATD instead of PORTD.

Ok, u do have a point and that must be the issue here.. BUT..
could it be so that the LCDout-command is causing this RMW behaviour and not the other way around?
I mean without LCDout everything works fine.. o:-)
what can I do about that build-in LCDout-command?
I don't have time and energy to write my own LCDout-command..
o:-)

[mara]

> as i said, you want to use LATD instead of PORTD.

Ok, Now i know it is about RMW. As I put "pause 5000" right after portD.7=1 command, the led in portD.7 will light for 5seconds.

There ain't any other solution than find another port for output-like portB.1?

[mara]

as i said, you want to use LATD instead of PORTD. Pulsout also do more than a single PORT/LAT=x. If my memory serves me well it set the TRIS.. then do what it has to do. Hence wasting a few instruction cycle before and after... why the R-M-W behaviour don't happen.. or is reduced to a minimum.

Ok, now it works: instead of portD.7=1 I write:

latd.7=0
latd.7=1

and now portD.7 will stay high even if LCDout is used..
BUT.. why do I have to do it that way? o:-)