Searching \ for '[PIC] Why me ?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page:
Search entire site for: 'Why me ?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Why me ?'
2011\10\25@154552 by Yigit Turgut

picon face
Hi all,

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.

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.

Sounds like a piece of cake right ?

Read AN0 constantly;
if button is pressed save the current AN0 value (critical_level) to eeprom
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 low

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
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 ;

sbit MOTR at RB0_bit;
sbit MOTL at RB1_bit;
sbit BTN3 at RB4_bit;

void main() {
                           TRISB = 00010000;
                           PORTB = 00010000;
         do {

             if(BTN3 != 1){
              MOTL = 0;
              MOTR = 1;}
              MOTL = 1;

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 ;

sbit MOTR at RB0_bit;
sbit MOTL at RB1_bit;
sbit BTN3 at RB4_bit;

void main() {
                           TRISB = 00010000;
                           PORTB = 00010000;
         do {
              MOTR = 1;
              MOTR = 0;
              MOTL = 1;
              MOTL = 0;

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.

Either I am doing something fundamentally wrong and I can't spot it or
this is a bug or something;

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

Thank you and sorry for the long post

2011\10\25@162919 by Byron Jeff

Two or three very quick suggestions. These are focused on potention read-modify-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.


On Tue, Oct 25, 2011 at 10:45:51PM +0300, Yigit Turgut wrote:
{Quote hidden}

> -

2011\10\25@170755 by jim



I don't see where you have the initialization information for the PIC,
so I don't know whether this is an  issue or not, but have you checked to see if you have the correct pins
selected for Analog measurement, and
the correct ones selected for Digital use?  Check the AN10, AN11, and
AN12 bits in the ADCON1 register.

You may have already configured this correctly, but just in case you
haven't, it wouldn't hurt to check.



> ---{Original Message removed}

2011\10\25@170822 by Yigit Turgut

picon face
Hi Byron,

1)  This may change something, I will try this and report back.*

2) Behavior of the switch is the same all along PORTB.

3) I added delay_ms(50) after the first action change, still the same.

Motor draws ~6-7mA approximately, There no coupling around motor.
Normally I know this is equivalent to suicide (or worse) but this
motor is very tiny and I used it the same way with my other 18f boards
without -any- problems. Surely, this doesn't mean the complication is
not originating from back emf but  I had driven an identical motor
with the same hardware configuration a while ago.

On Wed, Oct 26, 2011 at 12:35 AM, Byron Jeff <> wrote:
{Quote hidden}

>> -

2011\10\25@194851 by Yigit Turgut

picon face
Hi Jim,

AN0 exists on pcb but not in the test code I provided above, , I
didn't post them here because then thread would become such a mess and
people would have to consume more energy for results.

At another post someone had stated that open analog read pins might
cause fluctuations even if they are not used. There is approximately
3cm of 0.16 wide copper tracing from Spartan to AN0. Even if Spartan
is powered off, problem is valid.

You are right, I'll check again, I might have missed a bit.

On Wed, Oct 26, 2011 at 12:07 AM,  <> wrote:
{Quote hidden}

>> ---{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2011 , 2012 only
- Today
- New search...