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: > > =A0Yigit, > > =A0I don't see where you have the initialization information for the PIC, > so I don't know whether this is an > =A0issue or not, but have you checked to see if you have the correct pins > selected for Analog measurement, and > =A0the correct ones selected for Digital use? =A0Check the AN10, AN11, an= d > AN12 bits in the ADCON1 register. > > =A0You may have already configured this correctly, but just in case you > haven't, it wouldn't hurt to check. > > =A0Regards, > > =A0Jim > >> -------- Original Message -------- >> Subject: [PIC] Why me ? >> From: Yigit Turgut >> Date: Tue, October 25, 2011 2:45 pm >> To: "Microcontroller discussion list - Public." >> >> >> 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 =A0sends 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 =A0X 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 eepr= om >> 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 l= ow >> >> That's it. Reading AN0 has no problem but that button and =A0motor >> rotation... =A0I 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.gi= f >> as =A0the 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() { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 TRISB =3D 000100= 00; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PORTB =3D 000100= 00; >> =A0 =A0 =A0 =A0 =A0 do { >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if(BTN3 !=3D 1){ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MOTL =3D 0; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MOTR =3D 1;} >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MOTL =3D 1; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> while(1); >> } >> >> With the press of BTN3 motor is expected to rotate to right and with >> the release =A0rotate 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() { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 TRISB =3D 000100= 00; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PORTB =3D 000100= 00; >> =A0 =A0 =A0 =A0 =A0 do { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MOTR =3D 1; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0delay_ms(500); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MOTR =3D 0; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MOTL =3D 1; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0delay_ms(500); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MOTL =3D 0; >> } >> while(1); >> } >> >> this function is independent of the BTN3 =A0but 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 >> times. >> >> Thank you and sorry for the long post. >> -- >> http://www.piclist.com PIC/SX FAQ & list archive >> View/change your membership options at >> http://mailman.mit.edu/mailman/listinfo/piclist > > > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .