Hi,

I am sure someone will point out that the answer to my question is buried in the specs, but I've spent a considerable time reading them and still can't see the answer, so here goes...

I am controlling a stepper motor via pins RB0 thru RB3 (and a darlington array). All works just fine.

Now I want to incorporate a command interface using USART, so I can no longer use RB1 and RB2, hence I need to assign other pins to controlling the stepper. BTW, I also have RB4 thru RB6 assigned as inputs from various microswitches, so they're already in use.

So, I'm trying to use PORTA pins for controlling the stepper.
First I did a simple substitution, RA0 for RB0, RA1 for RB1 etc. This resulted in the motor stalling, or to be more precise, it just moved slightly one way, then back again. Changing (extending) the time between pulses didn't help the problem.

I then tried RA4 thru RA7 (again simple substitution for the RBx pins) and again this failed.

I realise PORTA pins have multiple functions, but I have set comparators off, and have not knowingly enabled any other PORTA function.

I've been hacking around at this for a couple of days now, and feel sure I must be missing something basic regarding how to use PORTA as digital output.

Any thoughts, suggestions, or better still answers most appreciated

 

On the pic16f628a you need to turn the comparators off

COMCON = 0x07; // in C

banksel CMCON
movlw 0x07
movwf CMCON ; in asm

Sorry... I didn't read the last bit... disregard this post!!!

BTW! Port a pin 4 is an input only!!!

 

You set the comps off by setting CMCON to 0x07.

Do note that some Port A pins (5 for one) are only input pins, they don't do output.

This is perfect for the MPLAB (X or not) simulator. Set up a program (yours or just a throw down simple thing) to wiggle the port pins. Work at it till you can control all the pins.

IF it don't sim you can't win.

 

The other thing is port a pin 3 is open drain...( requires a pullup / cannot source 5v)

 

Thanks to all who responded. I had forgotten that RA4 was open drain...so that explains why my test that used RA4-RA7 failed.

I then did a bit more experimenting on the RA0-RA3 pins and found that I couldn't get RA2 to source 5V. I'm not sure why that is but the only difference I can see between this pin and another which CAN source 5V (say RA1) is that it can also be configured to provide VREF output. However, I have comparators disabled, so I was not expecting that to be a problem.

In the end, I ran a test on every RAx pin to see if it could source 5V and my results show that all can apart from the following

RA2 - not sure why? If anyone can enlighten me, I'd be grateful.
RA4 - as pointed out already, this is open drain
RA5 - as pointed out already, this is input only

So, I will reconfigure my controller program to use only those RA pins that are capable of sourcing 5V and that should fix my problem.

 

Did you set VRCON to 0?

 

No I haven't explicitly done this, but the specs show that it is set to 0 by default. I've just run my program through the simulator and it also shows VRCON set to 0x00.

 

No I haven't explicitly done this, but the specs show that it is set to 0 by default. I've just run my program through the simulator and it also shows VRCON set to 0x00.

Some compilers like to do wacky stuff when burning code to a device. If you need to rely on a reset value, you are likely to run into trouble someday...

 

...
I am controlling a stepper motor via pins RB0 thru RB3 (and a darlington array). All works just fine.

Now I want to incorporate a command interface using USART, so I can no longer use RB1 and RB2, hence I need to assign other pins ...
...
Any thoughts, suggestions, or better still answers most appreciated

I think the best suggestion would be to use the USART, it is one of the most powerful features of that small PIC.

It's trivial to connect the 4 stepper motor wires to any pins you like.

But the very useful USART has to be on one specific pin.

Good design would dictate using the USART for serial comms and just using other pins for the stepper.

 

Some compilers like to do wacky stuff when burning code to a device. If you need to rely on a reset value, you are likely to run into trouble someday...

Point taken tshuck. However, just to completely eliminate this investigation path, I have now explicity cleared VRCON and the behaviour persists, i.e. RA2 does not appear to be capable of sourcing 5v.

 

Have you set RA2 as an output in the TRISA register ?

 

Point taken tshuck. However, just to completely eliminate this investigation path, I have now explicity cleared VRCON and the behaviour persists, i.e. RA2 does not appear to be capable of sourcing 5v.

Hmmmm...this is odd...could you post the code you used to test?

 

What the others said.. plus, I would consider shadowing the outputs i.e. maintain an port image in RAM, update the image then write the image to the port as a byte instead of flipping individual bits.

Midrange PICs are notorious for IO problems when individual bits on ports are set/cleared.

 

Hmmmm...this is odd...could you post the code you used to test?

Very odd indeed.... and I've just found out why it has been behaving this way....

A bad solder joint on my ZIF socket

This problem has plagued me for weeks now, and I've just worked around it by using other pins. Never for a moment thought to check the basic joints... I have a ZIF socket that wouldn't plug into my breadboard, so I extended the ZIF pins by soldering on 2 rows of header pins...and one of the pins (yep, pin1 = RA2) was a dry joint. Sometimes making contact, other times not.

Mystery solved!!

 

I hate when that happens.

On the bright side, you found the cause and it makes sense...