PBP projects for R/C models

[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

[ScaleRobotics]

Most of the RC stuff out there uses something like this, but there are exceptions:

And it is done 50 times per second, or every 20ms.

The hobby RC folks at our local RC Excitement racetracks and store say that neutral (braking) is 130ms.

I think the guys at your RC Excitement might be off by a decimal point or two if they are telling you neutral is 130ms.


If that was neutral, it would take about 1 second to make any corrections to steering or throttle. In my mind that is a little slower than you need for a fast car like the one I saw in your other thread.

Most RC receivers send out a pulse, one at a time, to each servo. So with the longest (2ms) pulse, an eight channel receiver can still fit all 8 x 2ms pulses in the 20ms bandwidth given by the cyclic 50 times per second update rate.

[Kenjones1935]

These RC Excitement guys just said 150 and 125 and 175. They never said the units. I just surmised milliseconds.

Last week you sent me two short programs. You also suggested that I go to Darrel Taylor's page and grab some code. I got his "blinky" to compile and work with the minor adjustments of changing the output to an LED register and the DT_INT-14.bas fix. I never got either of yours to compile and run.

On page 125 of your 18F2520 spec I found T0CON containing TMR0ON, T08BIT, T0CS, T0SE, PSA, T0PS2 AND T0PS1. I could not relate any of this to the contents of pages near 77 of my 16F887 spec. I also could not find in any code you posted where you set these bits.

Scalerobotics thought I might be able to measure the PWM radio receiver outputs if I converted it to a serial stream. Good idea, but I don't know what to do with a serial signal.

I would feel successful if I could see on a flashing LED that my radio receiver is working and that the PIC can read it. (I know it is working because the car wheels turn.) This is the intent of the first code (RC-Input - 12F675) Scalerobotics sent me. It originate with Malcolm from Hertfordshire, UK.

I'd like to get that working.

Time out. Gotta check the TV for results of the Massachusetts special US Senatorial election.

Ken

[Kenjones1935]

You guys keep suggesting the serial signal. Could it be that you have a method of debugging/trouble shooting your microprocessor code on line?

I just looked up USB on wikipedia. It is a "Universal Serial Buss" OH! I did not know that. So NOW I look at the "view" pull down menu on my MicroCode Studio GUI and discover "Serial Communicator" and "Easy HID USB Wizard".

There is clearly a lot for me to learn in C:\PBP\USB. Is that where I should start? I just opened MPLAB IDE for which I could see no purpose. I am beginning to understand but I am not sure where to start.

Ken

[ScaleRobotics]

Last week you sent me two short programs. You also suggested that I go to Darrel Taylor's page and grab some code. I got his "blinky" to compile and work with the minor adjustments of changing the output to an LED register and the DT_INT-14.bas fix. I never got either of yours to compile and run.

Mine will only compile properly for a PIC18F device, for sure with a PIC18F2520. It will need some work to translate for PIC16F devices.

On page 125 of your 18F2520 spec I found T0CON containing TMR0ON, T08BIT, T0CS, T0SE, PSA, T0PS2 AND T0PS1. I could not relate any of this to the contents of pages near 77 of my 16F887 spec. I also could not find in any code you posted where you set these bits.

Sorry, it is page 75 in the datasheet, and page 77 on Acrobat. Look for the page that has:
REGISTER 5-1: OPTION_REG: OPTION REGISTER on it. Where I set these registers is here:

T0CON = %00000001
T1CON = %00000001
T2CON = %01011111
CCP1CON = %00000101

Scalerobotics thought I might be able to measure the PWM radio receiver outputs if I converted it to a serial stream. Good idea, but I don't know what to do with a serial signal.

You mean you don't have any computers laying around with a serial port? Yeah, I guess it is like that in my house too! Your PicKit2 comes with a great resource (in my opinion). It has a serial port built in, and you can use it to see what your program is doing. Or in this case, figure out what your Pulse Width Measurement is doing. With the Pickit2 software, go to tools, then choose the Uart tool. Make sure you are sending your serial data to the right pin. In this case, you will have to use the serout commands, as the pickit pins will not be connected the the hardware serial port. Follow the serout as defined in the PBP manual.

I would feel successful if I could see on a flashing LED that my radio receiver is working and that the PIC can read it. (I know it is working because the car wheels turn.) This is the intent of the first code (RC-Input - 12F675) Scalerobotics sent me. It originate with Malcolm from Hertfordshire, UK.

LED's can be a good trouble shooting tool. However, we do not even know if the timebase is going to be similar in your chip, or what crystal you are running, etc. The serial port will be able to tell you so much more about what is going on. I think you will feel even more satisfied seeing actual results.

I'd like to get that working.

Me too!

One thing I learned about was MicroCode Studio's ICD (in circuit debugger). It is a great tool to see what your code is doing. It lets you step through, or view it, while allowing you to view registers, etc. I used it a lot in the beginning, then I started a few projects that were very time dependent, so I could not use the ICD in them, so I have not used it in a long time.

And about that USB HID ... what about the back to basics part?

-Walter