Two or three very quick suggestions. These are focused on potention read-mo=
dify-write
issues on the port:

1) For the outputs use the LATCHB registers instead of the PORTB registers.

2) Try testing with the switch on another port.

3) You may need some filtering/debouncing on the button. On the first
button change state, change your action, then wait awhile (50 mS or so)
before checking that button again.

BTW what's the current load on the motor? Do you have proper decoupling
caps? Have you tried optoisolating the motor drive from the control. Any of
these types of flaky behaviors can be caused by noise or power dips when
the motor kicks in.

Good Luck.

BAJ

On Tue, Oct 25, 2011 at 10:45:51PM +0300, Yigit Turgut wrote:
> Hi all,
>=20
> As some of you may have noticed recently, I was trying to implement a
> custom algorithm in Spartan 3E development board - which can be
> assumed to be completed now. FPGA  sends an analog signal (X) to PIC
> 18F, PIC rotates a motor back or forward depending on the content.
> This trigger is both variable in amplitude and frequency (0-5V /
> 0-50HZ). I am not getting into details of this not to mix things up.
> This is a very small part of the project and yet can't move on to
> further parts because this is not completed yet.
>=20
> There is a critical level in the range of  X that PIC decides to
> rotate the motor or stay still. This critical level is saved to eeprom
> and from then on PIC reads analog signal and compares to the value
> stored in eeprom. There is a tiny metal stick embedded to motor,
> rotating right - left depending on the choice. This metal stick spans
> approximately 45 degrees where there are active low push buttons at
> both ends (right - left) of the stick so that PIC will know when to
> stop rotation.
>=20
> Sounds like a piece of cake right ?
>=20
> Read AN0 constantly;
> if button is pressed save the current AN0 value (critical_level) to eepro=
m

> if AN0 >> critical_level rotate motor to right until pushbutton_right is =
low
> if AN0 << critical_level rotate motor to left until pushbutton_left is lo=
w
>=20
> That's it. Reading AN0 has no problem but that button and  motor
> rotation...  I can't find words that will express my anger. It's such
> a simple thing but yet not doable, at least for me. PCB is in perfect
> condition, paths are checked a dozen times and components are brand
> new. To save some time I test with
> http://www.semifluid.com/PIC18F2550_usb_hid_oscilloscope/Full-Circuit.gif
> as  the skeleton, without rs232 and usb connections. First I tried to
> rotate the motor back and forth with the push of the button. A very
> simple test consists of ;
>=20
> sbit MOTR at RB0_bit;
> sbit MOTL at RB1_bit;
> sbit BTN3 at RB4_bit;
>=20
> void main() {
>                             TRISB =3D 00010000;
>                             PORTB =3D 00010000;
>           do {
>=20
>               if(BTN3 !=3D 1){
>                MOTL =3D 0;
>                MOTR =3D 1;}
>                else
>                MOTL =3D 1;
>                }
> while(1);
> }
>=20
> With the press of BTN3 motor is expected to rotate to right and with
> the release  rotate to left. System doesn't provide a reliable
> response with this code, it rotates to left even if BTN3 is not
> pressed. On the other hand ;
>=20
> sbit MOTR at RB0_bit;
> sbit MOTL at RB1_bit;
> sbit BTN3 at RB4_bit;
>=20
> void main() {
>                             TRISB =3D 00010000;
>                             PORTB =3D 00010000;
>           do {
>                MOTR =3D 1;
>                delay_ms(500);
>                MOTR =3D 0;
>                MOTL =3D 1;
>                delay_ms(500);
>                MOTL =3D 0;
> }
> while(1);
> }
>=20
> this function is independent of the BTN3  but when I run the board
> with this basic firmware, initially there is no motor movement (stays
> still). But when I press BTN3, it starts to rotate to right and when I
> press it for the second time it stops or rotates to left
> (unpredictable responses). This is a very unexpected behavior IMHO and
> I tried the same with 4 other PIC's to make sure the ones I use are
> not corrupted. Same motor is perfectly driven with the same algorithm
> on Atmega328p.
>=20
> Either I am doing something fundamentally wrong and I can't spot it or
> this is a bug or something;
>=20
> What can I possibly be doing wrong ? It's a simple I/O operation and
> is driving me crazy. I have been trying to get over this for more than
> 40 hours and couldn't succeed. Seeking for serious guidance here, I am
> sure most of you implemented much more complex stuff thousands of
> times.
>=20
> Thank you and sorry for the long post.
> --=20
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist

--=20
Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjeff
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.