LCD and PIC18F4550

[mister_e]

As usual... post your code here, the whole thing.

Make sure you have disabled the analog stuff on PORTA, PORTB.

Without the right config fuses setting, it may ruine your life.. sure there's a few to set.

[SterlingY]

See attached, for settings and code.

On the Microchip forum, I was given this info:

Most example LCD code is written for chips operating a bit slower than the 48 MHz that the 18F USB chips can run. Much of the code also uses dead-loop timing (executing NOP instructions) to set the timing. You may very well be violating one or more of the timing requirements of the LCD.

You have several options:

1) Change the PIC's configuration to run the CPU at a slower clock rate to see if the timing is the problem. (Even with the PLL enabled, you can run the CPU as low as 16 MHz by just changing the CPUDIV value to divide-by-6. Lower frequencies can be set by disabling the PLL.) If the LCD works at the lower clock speed, you can proceed to either step 2 or 3 to resolve the problem. If not, there's something other than the timing causing the problem.

2) Check the code with the MPLAB simulator to ensure that all of the timing for the LCD control signals meets all of the timing requirements as specified in the LCD datasheet.

3) Check the controls signals with an oscilloscope rather than using the MPLAB simulator.

[SterlingY]

I have it working. The solution was to replace PORTB abd PORTA with LATB and LATA.

This is a major omission from the compiler docs.

-Sterling

[Darrel Taylor]

All you've done is treat the symptom.
The problem is still there.
And you've created some new problems in the process.

Changing the LCD DEFINEs to LATA/B just overcomes the R-M-W (Read-Modify-Write) problem when ports are set to analog mode. It might seem like it's working fine, but it's not the right way to go.

By doing that, the LCDOUT routines can't find the TRIS registers. Normally it finds TRIS by adding 12h to the Defined PORTx address. PORTA is F80h, if you add 12h, you get F92h which is the correct address for TRISA. But when you specify LATA (F89h), add 12h and you get F9Bh which is the OSCTUNE register.

The only reason it worked is because you had already set all pins to output with the TRISA and TRISB assignments. (and you weren't using the internal oscillator)

But, here's the good news.

ADCON1 = $0F

should fix it.

Be sure to change the LCD DEFINEs back to PORTA/B

[SterlingY]

Thanks,

I'll try your solution when I get my stepper motors running. They seem to just vibrate, and I'm sure the wiring is correct as I had it working on a PIC16F877.

Cheers,

Sterling

[Darrel Taylor]

If your steppers are on PORTA or PORTB. ADCON1 will probably fix them too.
<br>

[SterlingY]

I tried that:

DEFINE OSC 48

ADCON1 = $0F

' set variables:
x VAR BYTE
steps VAR WORD
stepArray VAR BYTE(4)
clear

TRISB = %11110000
PORTB = 255

Pause 1000

stepArray[0] = %00001010
stepArray[1] = %00000110
stepArray[2] = %00000101
stepArray[3] = %00001001


main:
if 1 = 1 then
steps = steps + 1
else
steps = steps - 1
endif

PORTB = stepArray[steps //4]
pause 2

GoTo main

[leisryan]

All you've done is treat the symptom.
The problem is still there.
And you've created some new problems in the process.

Changing the LCD DEFINEs to LATA/B just overcomes the R-M-W (Read-Modify-Write) problem when ports are set to analog mode. It might seem like it's working fine, but it's not the right way to go.

By doing that, the LCDOUT routines can't find the TRIS registers. Normally it finds TRIS by adding 12h to the Defined PORTx address. PORTA is F80h, if you add 12h, you get F92h which is the correct address for TRISA. But when you specify LATA (F89h), add 12h and you get F9Bh which is the OSCTUNE register.

The only reason it worked is because you had already set all pins to output with the TRISA and TRISB assignments. (and you weren't using the internal oscillator)

But, here's the good news.

ADCON1 = $0F

should fix it.

Be sure to change the LCD DEFINEs back to PORTA/B

Sir Darrel:
I'm a bit confused,does it mean when I'm trying to read a Port configured as output in PIC16F877A, I will get the state of the Pin even if it's already an output, rather than the state of the Latch that switch that particular pin to output? is "LAT*" a work-around in PIC18F series?

[Darrel Taylor]

Sir Darrel:
I'm a bit confused,does it mean when I'm trying to read a Port configured as output in PIC16F877A, I will get the state of the Pin even if it's already an output, rather than the state of the Latch that switch that particular pin to output? is "LAT*" a work-around in PIC18F series?

Exactly!

On 16F's, reading a pin in output mode reads the state of the pin itself, not the state you told it to output.

Usually they are the same thing, unless there is capacitance on the pin that makes it change slowly. Or if the pin is in analog mode, the digital input is disabled and ALWAYS reads 0.

On the 18F's, the LATx latches allow you to read the requested output state regardless of the actual state of the pin. This makes it easy to overcome the R-M-W problem found on the 16F's.
<br>