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
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
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
DT
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
If your steppers are on PORTA or PORTB. ADCON1 will probably fix them too.
<br>
DT
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
you may wonder about some of the code. It was originally written for a button to determine the direction, but to make it less confusing, I just say 1=1 to get to the heart of the code. I could have taken it out, but it will go back in.
-Sterling
I figured as much.
When I look at this page ...
http://www.sas.org/E-Bulletin/2002-0...ctro/body.html
Your phase sequence seems to be different.
I guess it depends on which pin connects to which phase.
Might try a little more than 2ms delay to start too.
<br>
DT
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?
Last edited by leisryan; - 1st September 2008 at 11:02.
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>
DT
Bookmarks