PBP projects for R/C models

[Kenjones1935]

I awoke this morning looking out my window onto eight new inches of wind packed snow. Plenty of time to think.

What scalerobotics said makes sense to me. In 1957 I was programming the AN/FSQ-7 SAGE Air Defense computer. We worked in machine language. It took us years to develop and distribute a symbol and subroutine library sufficient to allow us to focus on the radar data reading, intercept calculating algorithms needed to accomplish air defense. Building this subroutine library was a big task. The architecture of the machine did not change.

This morning I said to myself, "Back to basics." It may have been a mistake for me to purchase PICbasic PRO. Without being able to tap into the developments of others on the 16F88x structure, I may be better off in ASM. That way I will be forced back to basics.

This world of microprocessors reopens the academic importance of old fashioned "computer science". I was afraid that we had become too product oriented to care what is a "register".

I have two PIC books:
PIC PROJECTS by Parchizadeh and Vuksanovic
and
RUNNING SMALL MOTORS WITH PIC MICROCONTROLLERS by Sandhu

Seems like I should cease dreaming of getting a prototype to blink in sync with a PWM input signal and get back to the books. I've got plenty of time. Did I mention that we are snowed in without an all wheel drive car?

Ken

[ScaleRobotics]

This morning I said to myself, "Back to basics." It may have been a mistake for me to purchase PICbasic PRO. Without being able to tap into the developments of others on the 16F88x structure, I may be better off in ASM. That way I will be forced back to basics.

This world of microprocessors reopens the academic importance of old fashioned "computer science". I was afraid that we had become too product oriented to care what is a "register".
Ken

Ken, I hope I did not discourage, for it was my intent to encourage. But back to basics is always a good idea, no matter what path you choose. For PIC devices, it can be a difficult task to transfer a program from one type of device to another.

A better place to start on the learning curve, might be to use Darrel Taylors interrupt code examples, and try to get the interrupt blinking led going on your device. Then try to modify it in some way that is closer to the end product you want. In that way, it forces you to learn about different registers, but only a few at a time. Here is Darrels blinky example. http://darreltaylor.com/DT_INTS-14/blinky.html

Joe had some great advice. In trouble shooting, it is always helpful to figure out what parts of the code DO work. I always like using the serial port to help tell me what is happening in the device, and to check register values, etc.

Let us know how we can help you.

Walter

[Kenjones1935]

I got Darrel Taylor's blinky to work on my PICkit 2 16F887. I had to change the output pin to the LED to match the printed circuit on the 44 pin demo board.

Now I would like to get blinky to interrupt on the rising edge and the falling edge of a signal coming in CCP1 which is RC2.

Darrel Taylor's blinky contains this line

@ INT_ENABLE TMR1_INT ; enable Timer 1 interrupts

Where do I look for the definition of INT_ENABLE? I used SEARCH. I had no luck at all.

Ken

[ScaleRobotics]

That's a great start Ken!

INT_ENABLE is a Darrel Taylor command for his DT_INTS. This is the same as enabling, or disabling a certain interrupt. To set up CCP interrupts, you first add a line like my code had:

INT_Handler   CCP1_INT,      PWMeasure,   ASM,  yes

Then enable it:
@ INT_ENABLE CCP1_INT

But you will also have to configure it. Make portc.2 an input. And configure your CCP1
CCP1CON = %00000101 ;capture every rising edge

Now I used Chuck's code to do the capture. It needs the sub16.inc include file to be included, and we will need some variables like

risetime var word      ;used for pulse width measure start of pw
falltime var word      ;time at end of pulse width
falltime_l var falltime.byte0
falltime_h var falltime.byte1
risetime_l var risetime.byte0
risetime_h var risetime.byte1

asm
PWMeasure

    BTFSS   CCP1CON, CCP1M0 ; Check for falling edge watch
    GOTO    FALL_EDGE       ; Go pick up the falling edge
    MOVF    CCPR1L,W        ; else store leading edge value
    MOVWF   _risetime_l         ; into 16 bit word risetime
    MOVF    CCPR1H,W
    MOVWF   _risetime_h
    BCF     CCP1CON, CCP1M0 ; Now capture the trailing edge
    GOTO    ISR_2           ; Exit the interrupt service routine
        
FALL_EDGE:
    BSF     CCP1CON, CCP1M0 ; Re-set for trailing edge capture
    MOVF    CCPR1L,W        ; Store the captured value into
    MOVWF   _falltime_l         ; falltime_l and ...
    MOVF    CCPR1H,W
    MOVWF   _falltime_h       ;             ... falltime_h
    ;
    ; 16 bit subtract 
    ;     falltime = falltime - risetime
    ;
    SUB16   _falltime, _risetime
ISR_2
    INT_RETURN

endasm

Now, if you read the data sheet, you see in 11.1 Table 11-1 that capture mode uses timer1. So you will have to set this. Looks like it may be same settings as I have in T1CON. This will also start the timer. It runs continuously, and we don't care about interrupts on T1. We just want to read the timer at interrupt high edge of CCP1, and read timer on low edge of pulse. Then we should have a value present at falltime, representing the length of the pulse.

[Kenjones1935]

I did not expect this project to be so discombobulating.

Thanks to this forum's help, I think I will get it.

ken

[ScaleRobotics]

Yes, you have picked a very challenging project.

The servo part broken down into basic steps of what is going on here. (Other interrupt sources, and different timers could be substituted, but this is what I am using).
__________________________________________________ _________________________________________________
Pulse Sensing:
Using CCP interrupt and calculate (pulse_width = falltime - risetime) with CCP capture low byte CCPR1L and capture high byte CCPR1H (these use Timer1). To do this, bits must be changed from capture on rise, to capture on fall.

Pulse Width Generation:
Need to create interrupt from about 1ms to 2ms in length. To do this, we load a timer with pulse width value, bring servo pin high, start timer, when interrupt occurs, bring servo pin low. I used Timer0.

Pulse Period Generation:
Need to generate 20ms time frame for sending servo signals. I used Timer2. Servo out pins need to pulse every 20 ms.
__________________________________________________ _________________________________________________

On a side note:
Now just to discombobulate things a little bit (more!), cheating can sometimes work. Problem is, that you want to run one of your outputs through a motor controller, and these don't like cheaters. They like very reliable 20ms time (Pulse Period) frames for the servo pulses. So, where you might have gotten away with using PBP's pulsin and pulsout commands for sensing and controlling servo's, you will not get away with using the pulsout command for controlling your motor controller.

One place you could get away with a little cheating, is to use Pulsin command to sense your receiver's servo pulses. Then you would not have to worry about the servo Pulse Width sensing. I have used this with an RC autopilot project, and it was smooth enough to fly. But, since you are doing all this work learning about interrupts, and timers, you might as well do it the right way, and measure the pulse with an interrupt.

[Kenjones1935]

Scalerobotics.

I have not been successful getting the RC knowledgeable folks to come clean with the exact signal pulse width specs. The hobby RC folks at our local RC Excitement racetracks and store

http://www.rcexcitement.com/

say that neutral (braking) is 130ms. This makes sense if the max pulse size is 256ms (2 to the 8th for convenient digital counting). How often that pulse is expected I am not sure. I think I read that the shortest pulse is about 50ms and the longest about 200ms. But I have no idea where or how I got that impression.

It would be nice if I could implement a program on my PICkit such that my eyes could detect this variation by observing the glow of an LED.

I neither own an oscilloscope nor have easy access to one. I do have some contacts at the Fitchburg State College Computer Science Department. I could call them and take over my car for a definitive answer.

Enough talk. I'm supposed to be thinking and tinkering.
Ken