PBP projects for R/C models

[Kenjones1935]

I can count up to 60,000 micro seconds using Bruce's mechanism. This is long enough to make the LED on PORTD.0 blink visibly!

Next step is to add the PWM command and connect the output to my RC car's ESC box.

Thanks again, All

Ken

[Bruce]

This is pretty crude, but see if it does what it should when changing to Forward, Back, etc
with your ESC.

    DEFINE OSC 4

    Match VAR WORD
    
    Forward CON 1000     ' ~1mS pulse
    Neutral CON 1500     ' ~1.5mS pulse
    Back    CON 2000     ' ~2mS pulse
    
    Match   = 20000         ' 20,000 * 1uS = 20mS until compare match
    CCPR1H  = Match.HighByte' Load compare register high
    CCPR1L  = Match.LowByte ' Load compare register low
    CCP1CON = %00001011     ' Compare mode, auto reset Timer1
    
    '/ TRIS & Port Setup
    PORTB.0=1
    TRISB = $FE  ' PORTB.0 output, rest inputs
    
    '/ disable interrupts
    INTCON.7 = 0 ' Disable global ints
    INTCON.6 = 0 ' Disable peripheral ints
    PIE1.0   = 0 ' Disable Timer1 int
    PIE1.2   = 0 ' Disable CCP1 int

    T1CON = %00000000 ' Timer1 off, internal clock, 1:1 prescale
    TMR1H = 0         ' Clear Timer1 high
    TMR1L = 0         ' Clear Timer1 low
    
    T1CON.0 = 1  ' Turn on Timer1

LOOPS: ' NOTE: PIR1.2 is the CCP1IF compare interrupt flag bit.
       ' this bit is set when Timer1 reaches the value in
       ' CCPR1L & CCPR1H
    IF PIR1.2 = 1 THEN   ' If CCP1 to TMR1 compare match occured
       HIGH 0
       PAUSEUS Forward   ' change this to Neutral, Back, Forward to see effect
       LOW 0
       PIR1.2 = 0        ' Clear compare interrupt flag bit
    ENDIF
    GOTO LOOPS

    END

[Kenjones1935]

Not only does your code work (with a couple of adjustments specific to my PICkit 2 setup) but it also makes my car go not-so-fast, faster, and fastest.
It also successfully drives the steering servo left, center and right. This validates the rumors that I was getting from the RC people about the shape and timing of their PWM signals.

GREAT!! Now on to bigger and better stuff like light sensing and proximity sensing. First I need to write some car control routines

FORWARD speed,duration
BACKWARD speed, duration
STEER_RIGHT ?
STEER_LEFT ?



Ken

[Kenjones1935]

Am I correct in thinking that PAUSEUS stops the PIC.

To run my car the PIC must control steering and wheel rotating. It also monitors whether channel 3 from the RC receiver is calling for a return to RC control.

Meanwhile the car must be able to sense and react to light, ultra sound proximity, and other timers. It has to find its way to a destination.

The PWM pulses are generated at 50 per second. That is 20ms between clock matching interrupts. The longest PAUSEUS is 1.75ms which is 8.75% of total time. Steering concurrent with wheel rotation could consume 17.5% of compute time.

Is this a problem? I just don't know enough about real time PIC coding to know the answer. What do you all think?

Ken

[mackrackit]

PAUSE puts the code into a loop for a certain amount of instructions. It does not stop the hardware interrupts.

This is what a PAUSE in ASM looks like. Just a routine to eat some time.

; Delay = 0.1 seconds
; Clock frequency = 4 MHz
; Actual delay = 0.1 seconds = 100000 cycles
; Error = 0 %
Delay	;99993 cycles
	movlw	0x1E
	movwf	d1
	movlw	0x4F
	movwf	d2
Delay_0
	decfsz	d1, f
	goto	$+2
	decfsz	d2, f
	goto	Delay_0	;3 cycles
	goto	$+1
	nop		;4 cycles (including call)
	return

[Bruce]

If you have hardware interrupts enabled, it will jump out of any code routine, execute whatever code you have in your interrupt handler, then return to where it was prior to the interrupt.

Note I wasn't recommending you use this routine to control your motors, I was just curious if it worked. Once you know what you'll need to do to handle all the other things you need to like light sensing, ultrasonic, etc, then you'll have some idea of how to incorporate all your routines (or most) into a single interrupt handler.

Your particular type of application could also benefit from a few dedicated application specific ICs like maybe some 8-pin PICs programmed to do nothing but generate your motor control signals by just monitoring a few inputs, and using these inputs to determine speed, direction, etc. Then you main controller could control motors by just taking a pin or 2 high or low.

A lot of robotics applications use distributed processing like this to take some of the repetitive tasks off of the primary controller.

Example: Instead of using a sonar sensor, you could build this into your main controller. But then your main controller wastes a ton of time doing what the external sonar sensor does.

So - most people will just buy & use a sonar sensor rather than design it into the main circuit. Just take that a step further, and make your own 8-pin servo controllers.

If you have a lot of things going on, motors, sensors, measurements, etc, etc, you can take a huge burden off the main controller by just creating a few of your own litle application specific PICs with a few I/O-pins on the primary controller telling them what to do.

You could have a whole herd of little 8-pin PICs interfaced & controlled by the primary controller, and it only takes a few pins on the primary to control them, and just a few instruction cycles to make that happen.

Or you could shove it all into just one with some crafty interrupt handler to sort it all out. Just an idea. Sounds like a fun project.

Microchip has a new 8-pin PICs coming shortly with a hardware USART & other goodies that could make some really interesting little peripheral controllers.

[Acetronics2]

Microchip has a new 8-pin PICs coming shortly with a hardware USART & other goodies that could make some really interesting little peripheral controllers.

Hi, Bruce ...

Could you give some little details ... please ??? a number ???

I have been DREAMING of it for so long !!!

Alain

PS: 1822 ???