Jump to content

JF1980

Trusted Member
  • Content Count

    31
  • Joined

  • Last visited

Community Reputation

0 Neutral

About JF1980

  • Rank
    RC-Cam'er
  1. Not quite sure where I asked for a password?!? Apparently MikroC Pro supports the 16F726; the free version is still good for up to 2K of program code. I'll just go with the 16F882, it has all the same features and is cheaper.
  2. It seems neither MikroC nor Proteus support the 16F726 so I'm going to look at porting my current code to the 16F822 instead.
  3. Still having problems with this, it's fine if I use a servo time of 0.6 - 2ms but if I go above 2ms then the next servo (say servo 1 if I am moving servo 0) off-sets by a small amount. Think I'm going to be best off ditching the 16F690 and looking for something similar with two CCP modules. The 28 pin 16F726 looks like a good match.
  4. It's just not possible to use a whole port for servo output on a chip this size whilst still using the com ports. I know this is a dirty fix but it does the job: if (servostatus == 1) { // CCP1 Special Compare Event Interrupt // servo output on code here activeservo++; activeservo = activeservo & 7; //move to next servo switch (activeservo) { case 0 : { S1 = 1; S2 = 0; S3 = 0; S4 = 0; S5 = 0; S6 = 0; S7 = 0; S8 = 0; servo[activeservo] = ComShadowServo[activeservo] + 10; // copy servo position from Comms array
  5. I use 2.4Ghz radio so have been considering 1.3Ghz or 900Mhz video transmitters. Any reason you want to stick with 2.4Ghz for video?
  6. Agreed, the fact that the servo offset increases with each servo also leads me to believe that something is delaying with increasing effect on each servo update cycle. I can only imagine this is the switch statement. Here is the full ISR code block. The PIC is running on the internal ocs running at 4Mhz. It's capable of 8Mhz but I figured I don't really need 8 Mhz and the PIC would use possibly less power if running at half the frequency. void interrupt(void) { servostatus = !(servostatus); if (servostatus == 1) { // CCP1 Special Compare Event Interrupt // servo output on c
  7. I've gotten quite some way towards building a 16F690 based servo control board. I'm using 1 CCP module to drive the servos and am currently only working with USART. I have kept the SPI/I2C pins free and will implement them once everything else works as it should. I've based my theory on the mikroBasic example here (second example from top uses 1CCP, the first uses 2CCP's). My data is sent over the serial link as ASCI characters as my terminal emulator will only allow me to send ASCI. I did post my questions over there but the forum is pretty dead and it can take weeks for people to come
  8. Very much so! Now I've got the basics covered I'm going to become a little more ambitious. I would like to build a servo control board so that the timers/CCP in the main MCU will be free for other things. I have some 16F690 samples which would seem to be ideal with one CCP (will modify the code to use one CCP module) and USART/SPI/I2C capabilities. I was wondering what the preferred protocol would be? There seem to be a lot of sensors using SPI so that would seem like the logical choice as I could share all but the CS line, however I'm not sure that it's fast enough? I haven't seen any
  9. You're right Mr RC, after one rotation Servo_Output is 0b00000000 because I forgot to reset it. Threw a temporary 'if' statement in there and now the code works. The original code I used as a reference was written in Basic and targeted at the 18F chips. It uses an ASM bitshift instruction which rotates the bits in the register. I couldn't find a similar instruction for the 16F877A and forgot to reset the register after a complete cycle. Thanks for looking over it, this has been driving me crazy for the last 24 hours!
  10. Thanks for the fast reply. I did think I can do this with one CCP, once this is working I'll modify it to use one CCP and run on a 628A or something similar. You're right in saying that once an interrupt is triggered, a conditional statement selects the desired course of action depending on the trigger. I've checked it with the debugger and it seems to work fine in theory, I can check on the various registers and see the expected numbers. Good call on using the LCD, it won't be much more bother than using the LED's for diagnostics and will give me more specific information. I did plac
  11. I'm trying to learn how to drive servos using a PIC 16F877A. My project is trying to drive up to 8 servos on PORTB using two CCP modules; I have the servo signal wire connected to the PIC output pins with the servos getting 5v from a standard 4.8v RX pack. I have connected the -ve battery terminal to my proto board so that the servos share a common ground. My code is written in MikroC: /* * Project name: MoveServo1 * Description: Move Servo with TMR0/1 Interrupts. * Test configuration: MCU: PIC16F877A Dev.Board: EasyPic4 Oscillator: HS, 08.000 M
  12. Hi all, I've been lucky enough to have a bit of time to start playing around with my electronics gear. I would like to make my own tilt/pan head tracker and later on work towards autonomous flight. Currently I have an EasyPIC4 development board which will allow me to play with any PIC up to the 18F range. I've had it for years and have had an active interest in PIC's but very little time to get hands-on. So far I've experimented with decoding a servo signal from a R/C receiver (nav lights project) and taking readings from a two-axis accelerometer then outputting them on an LCD display
  13. Just understood what you meant. I think you missed the point of this project. It was for me to learn how to interface a PIC and R/C system using MikroC. Sure I could have just copied someone else's design and code but that would have defeated the point. I could have saved the effort and brought a set off eBay for £10 if all I wanted were NAV lights
  14. Why not encode the GPS data along with other data like airspeed, temp, current draw etc. It would seem to be a waste, streaming the GPS data by itself.
×
×
  • Create New...