PDA

View Full Version : PBP projects for R/C models



Pages : [1] 2 3 4

malc-c
- 28th October 2009, 23:02
Hi,

Following on from a suggestion on the main PBP forum, it is hoped to get people to post up code snippets for anything RC model related. I'll start the ball rolling by posting code that makes an LED pulse like a beacon and is controllable from a transmitter. - This was a result of my own bit of code and suggestions from guys on this forum on how to use pulsein command to detect the signal from the receiver.



'************************************************* ***************
'* Name : RC Input - 12F675 *
'* Author : *
'* Notice : Copyright (c) 2009 *
'* : All Rights Reserved *
'* Date : 27/10/2009 *
'* Version : 1.0 *
'* Notes : *
'* : *
'************************************************* ***************

' set up PIC config

@ __CONFIG _INTRC_OSC_NOCLKOUT & _WDT_ON & _PWRTE_ON & _MCLRE_OFF & _BODEN_ON

__CONFIG
_INTRC_OSC_NOCLKOUT
_WDT_ON
_PWRTE_ON
_MCLRE_OFF
_BODEN_ON

OPTION_REG = %10000000 ' Pull-ups = off, GPIO.2 = I/O, prescaler to Timer1
GPIO = %00000000 ' All outputs = 0 on boot
TRISIO = %00001000 ' GPIO.3 input, GPIO.0,2,3,4,5 output
ANSEL = 0 ' Set all digital
WPU = 0 ' Internal pull-ups = off
ADCON0 = 0 ' A/D off

;set varibles

signal VAR GPIO.3 'GPIO.3 is used to the receiver
pulse VAR BYTE 'pulse is used to store the result
led var GPIO.0 'GPIO.0 is the output we want to flash
i var byte 'i is used for the for next loop to generate width of pulses
getout var bit 'used to check switch routines

'-------------------------------------------------------------------------------

main:
PulsIn signal, 1, pulse ' reads signal from receiver
IF (pulse >= 100) AND (pulse <= 160) Then ' threshold for activation
Low GPIO.0 ' turns LED off
Else
goto flash 'if pulse is ouside range goto flash
EndIF
GoTo main ' do it all again

flash:
for i = 1 to 254 ' for next loop
Pwm GPIO.0,i,1 ' send pulse to GPIO.0 for lenght i increasing brightness
pause 1
if i=253 then ' test to see value of i
i=1 ' if test is true then set 1 to 1 and getout to 1
GetOut=1
if Getout=1 then goto down ' if getout is q then jump to down routine
endif
next i

down: ' same as flash but decreases brightness
for i = 254 to 1 step -1
Pwm GPIO.0,i,1
pause 1
if i=2 then ' test of value i, if i =1 then
i=1 ' set i to 1 and getout to 0
GetOut=0
if Getout=0 then goto main ' test value of getout - if 0 go to start of program
endif
next i

Kenjones1935
- 10th January 2010, 05:19
Please, if you are interested, take a look at the
"How do I give a radio control car autonomous control"
Thread. I have a PICkit 2 and PICbasic programming package.

Attached is a sketch of what i need to do. I think. Any suggestions would be greatly appreciated. The forum does not let me attach the same file twice.

http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3871&stc=1&thumb=1&d=1263008711


Ken Jones

ScaleRobotics
- 10th January 2010, 10:11
For pulse width measurement, I ran across an interesting page.

http://www.mcmanis.com/chuck/robotics/projects/lab-x3/pulse_measure.html

I borrowed a little bit of the code, and then added it to some DT_Interrupts. I am just measuring a servo pulse width, and sending raw tmr1 result to the serial port here, but you can change it to make it do other things. This was done with a PIC18f2520 in a LAB-X2. But the above gentleman used a PIC16F628, so it should be pretty flexible if you chose the corresponding DT_INTS include file. I would like to see more examples of pulse width measurement as well as pulse generation using interrupts, so if you have some, please share!



DEFINE OSC 20
DEFINE LOADER_USED 1
DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
DEFINE HSER_SPBRG 42 ' 115200 Baud @ 20MHz, 0.94%
SPBRGH = 0
BAUDCON.3 = 1 ' Enable 16 bit baudrate generator

LED0 VAR portb.0
LED1 VAR portb.1
LED2 VAR portb.2

adcon1=15 ;sets all to digital
TRISA=%00000000 ' Set PORTA
TRISB=%01110000 ' Set PortB
TRISC=%10000100 ' Set PortC bit.2 for input (ccp) and bit.7 for ser input

INCLUDE "DT_INTS-18.bas" ; Base Interrupt System
INCLUDE "sub16.inc" ; subtract 16 bit macro

LED0=0
LED2=0

risetime VAR WORD
falltime VAR WORD
falltime_l VAR falltime.Byte0
falltime_h VAR falltime.Byte1
risetime_l VAR risetime.Byte0
risetime_h VAR risetime.Byte1

ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler TMR0_INT, ToggleLED0, ASM, yes
INT_Handler CCP1_INT, PulseWidth, ASM, yes
endm
INT_CREATE ; Creates the interrupt processor
ENDASM

T0CON = %10000100
T1CON = %00000001
T2CON = %00111101
CCP1CON = %00000101
@ INT_ENABLE TMR0_INT ; Enable Timer 0 Interrupts
@ INT_ENABLE CCP1_INT ; Enable Capture Compare for pulse width measurement

Main:
PAUSE 1000
HSEROUT [DEC falltime,10]
GOTO Main

ASM
ToggleLED0
btg _LED0 ;blinky light
INT_RETURN
ENDASM


ASM
PulseWidth
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 ;this subroutine performs 16 bit subtraction
ISR_2
INT_RETURN
ENDASM

Kenjones1935
- 16th January 2010, 23:55
You all posted code specifically for the 12F675. My PIC is a 16F887.

I am at a loss to translate from one PIC to the other. My PBP compiler (set up for 16F887) has no idea what to do with GPIO.x references. When I set it for 12F675 it is happy, but the resulting code is useless to my PICkit2.

Is it my job to read about the 12F675 and try to figure out which register in my 16F887 is equivalent? That would be an excellent homework assignment.

Ken

tenaja
- 17th January 2010, 01:15
Is it my job to read about the 12F675 and try to figure out which register in my 16F887 is equivalent? That would be an excellent homework assignment.
Well, yes... but it will take a whole lot longer to open the file than it will to hit ctrl-f and search for gpio.

Kenjones1935
- 17th January 2010, 01:27
I do not have all the necessary includes. Judging from the code snip offered by scalerobotics I need the base interrupt system for the 16 bit machines.

"INCLUDE "DT_INTS-18.bas" ; Base Interrupt System
INCLUDE "sub16.inc" ; subtract 16 bit macro"

I have a PICkit 2 with a 16F887.
Does a DT_INTS-16.BAS exist? Where?

ken

ScaleRobotics
- 17th January 2010, 03:19
I do not have all the necessary includes. Judging from the code snip offered by scalerobotics I need the base interrupt system for the 16 bit machines.

"INCLUDE "DT_INTS-18.bas" ; Base Interrupt System
INCLUDE "sub16.inc" ; subtract 16 bit macro"

I have a PICkit 2 with a 16F887.
Does a DT_INTS-16.BAS exist? Where?

ken

Hello Ken,

The DT_INTS-14.bas covers the PIC16 devices. The newest version 1.00 can be found here (at botom left). http://darreltaylor.com/DT_INTS-14/intro2.html The code should be able to be modified for your chip, but there are PIC chips with more timers, and more ccp pins out there.

It might be best to try out some of the ready made samples that Darrel gives, just to get the hang of using his interrupts, and making sure your includes, and configs are working.


I am working on a DT_INTS based RC servo passthrough (servo pulse measurement and pulse generation, but it is a little jittery right now, so I have try to trouble shoot that.

Kenjones1935
- 17th January 2010, 04:04
Mr or Ms scalerobotics,

My original idea for an RC car that could toggle between RC control and autonomous control was to have DPDT relays switching between the RC receiver PWM outputs and the PIC PWM outputs. Please see:

http://www.ziplink.net/users/kjones/RCcar3_color_copy.jpg

I discounted the idea of routing the RC commands through the PIC as that route might be slow and/or noisy. It sounds like that is exactly what you are designing. Please keep me in touch with your progress.
I think that design would force me to choose another PIC as it would require three inputs from the radio receiver and two outputs to the electronic speed control and the steering servo. -- all interrupt driven I would think.

I am sort of stuck with the PICkit 2 since I have purchased three of them. They are also not toooo big. If I could get more confidence prototyping I might consider building my own PIC carrier, but just getting the prototyping bits, parts and pieces entails an hour's drive to a store with which I am not familiar.

Ken

ScaleRobotics
- 17th January 2010, 11:04
Hey Ken, OK, now I understand your project, and the use of the PicKit's!

Well, I was able to correct my servo jitter, an error on my part of course.

Here is some code for a single servo channel pass through, using DT_INTS. Next I will try adding the other CCP pin.





define OSC 20
DEFINE LOADER_USED 1
DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
DEFINE HSER_SPBRG 42 ' 115200 Baud @ 20MHz, 0.94%
SPBRGH = 0
BAUDCON.3 = 1 ' Enable 16 bit baudrate generator

LED0 var portb.0
LED1 var portb.1
LED2 var portb.2
halftime_bit var bit
adcon1=15 ;sets all to digital
TRISA=%00000000 ' Set PORTA
TRISB=%01110000 ' Set PortB switch inputs (not used)
TRISC=%10000100 ' Set PortC.2 to input for ccp1
' set portC.7 to input for serial port

INCLUDE "DT_INTS-18.bas" ; Base Interrupt System
include "sub16.inc" ; subtract 16 bit macro

LED1=1 ; Set to Output Low
LED0=0
led2=1
portb.3 = 0
servo_out var portb.3

risetime var word ;used for pulse width measure start of pw
falltime var word ;time at end of pulse width
timer0 var word ;used to load tmr0l and h bytes
falltime_l var falltime.byte0
falltime_h var falltime.byte1
risetime_l var risetime.byte0
risetime_h var risetime.byte1


pause 1000
ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
;INT_Handler TMR1_INT, ToggleLED1, ASM, yes
INT_Handler TMR0_INT, _PWMout, ASM, yes
INT_Handler CCP1_INT, PWMeasure, ASM, yes
INT_Handler TMR2_INT, _twentyMs, ASM, yes
endm
INT_CREATE ; Creates the interrupt processor
ENDASM
T0CON = %00000001
T1CON = %00000001
T2CON = %01011111
CCP1CON = %00000101
;@ INT_ENABLE TMR1_INT ; Enable Timer 1 Interrupts
@ INT_ENABLE TMR0_INT
@ INT_ENABLE CCP1_INT
@ INT_ENABLE TMR2_INT

Main:
NOP

GOTO Main

twentyMs: ;really 10ms, but only acted on half the time
toggle halftime_bit
if halftime_bit = 1 then ;only perform this every other time this is called
timer0 = falltime/4 ;measured pulse length, send to
;hserout [dec timer0,",",dec falltime,10,13]
tmr0h = 255 - timer0.byte1
tmr0l = 255 - timer0.byte0
T0CON.7 = 1 ;start t0
servo_out = 1 ;set servopin high
endif
@ INT_RETURN

PWMout:
T0CON.7 = 0
servo_out = 0 ;at completion of timer set servo pin low
@ NOP
@ INT_RETURN

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


Walter

Kenjones1935
- 18th January 2010, 02:46
Scalerobotics,

The code you sent me has some incompatibilities with my system. I can fix some. Others....

You include DT_INTS-18.bas. I have DT_INTS-14.bas a la Derral Taylor. I changed the code.

You use "BAUDCON.3 = 1 ' Enable 16 bit baudrate generator". My compiler kicks that out. I do not know how to find out whether I have the equivalent. I do not even know how to start.

You use T0CON.7. My system has no such thing. Again I have no idea how to find out what is my equivalent.

Nuts! Ken

Kenjones1935
- 18th January 2010, 05:19
I searched all the .inc files in the microchip/MPASM suite directory for the string BAUDCON. I got many hits. None were from the PIC16F8xx set of microprocessors.
The hits mostly said "BAUDCON EQU h'019f'" in BANK 3.

There are no such entrees in the PIC16F8xx .inc files.

How do I find out what BAUDCON means in its context so that I can translate to my PICkit 2 context?

ScaleRobotics
- 18th January 2010, 06:19
Hey Ken, you can either take the serial out, or change it a bit. Here is one to use a slower baudrate, without using the baudcon.3 setting.

DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_SPBRG 64 ' 19200 Baud @ 20MHz, 0.16%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically

I use a program from Mister E, called Mister E PIC Multi-Calc that spits all these above settings out after you pic a baud rate. Pretty cool! http://www.picbasic.co.uk/forum/showpost.php?p=65639&postcount=38

Sometimes PIC chips can be a pain because the newer chips will move things around on us. So when we try to learn a different chip, or upgrade to a different part, things do not work without a bit of leg work.

I was using a PIC18F2520, which had a register called T0CON for adjusting the Timer0 or TMR0. That sounds like it makes sense. However, on the PIC16F887 that you are using, the same Timer0 TMR0 is adjusted by using .... the Option Register. Not quite making as much sense, is it.

Anyway.... HOW do I know this? Answer: I do not. I have to look up both data sheets for each of those pic chips, and compare them. Not all 375 pages, but just whatever portions I think are giving me trouble. In this case, the Timer0. Then I have to see that everything that is set in the PIC18F2520 for the timer, is set for the PIC16F887. Then I will probably have to do the same thing for the other timers. AND, it will probably not work when I first try it, because I will probably miss something.

So, looking at page 77 of your data sheet, and page 125 of my data sheet, lets see what we can screw up, I mean "test".

Well I had it set to:

TMR0ON - off
T08Bit - configured as a 16 bit timer (this could be a problem)
T0CS - Internal instruction cycle clock
T0SE - increment on low to high transition of clock pin
PSA - use prescaler selection bits
T0PS - 1:4 prescaler selection bits

Now lets see what we have for the Option register...
Well, looking at the data sheet, your chip's T0 is only 8 bit, but if we are lucky, we will just have lower resolution. Timer0 is the time base for creating a servo pulse out from 1 to 2 ms.

Option_Reg
RBPU - Port B pull ups (nothing to do with timer) probably leave off - 1
INTEDG - Nothing to do with timer
T0CS - keep at 0 like above
T0SE - keep at 0 like above
PSA - keep at 0 like above
PS - we can start at 001 like above, but we might have to change things up since this
is not a 16 bit timer.....If I was smarter about how these worked, I could mathematically figure this out.....

Now, how do we start this timer0, because it looks like bit 7 is NOT going to do this for us...

To be continued .....

boroko
- 18th January 2010, 08:21
Scalerobotics,

Bravo! very well laid out explanation (well at least part one). That is the kind of stuff that drives newbees nuts and makes them give up in frustration. There is no easy place to learn it if you don't have a mentor. Patient, concise, and relevant. Nice job.

Bo

Kenjones1935
- 18th January 2010, 15:11
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

Archangel
- 18th January 2010, 16:20
There are no such entrees in the PIC16F8xx .inc files.

How do I find out what BAUDCON means in its context so that I can translate to my PICkit 2 context?
Hi Ken,
He is using an 18F part, look in the data sheet for the chip he is using.
For your code just comment that line out and try it. I think I would try different settings in the defines which control the Baud Rate of the hardware serial port as he set up for 19200, but you could use that.
Ok, 18F4520 has EUSART which uses BAUDCON and reconfigures pin as both input/output on the fly . . .
You got snow, we got rain . . .

ScaleRobotics
- 18th January 2010, 18:26
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
- 19th January 2010, 03:12
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
- 19th January 2010, 06:25
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
- 19th January 2010, 16:46
I did not expect this project to be so discombobulating.

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

ken

ScaleRobotics
- 19th January 2010, 17:41
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
- 19th January 2010, 22:56
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
- 19th January 2010, 23:17
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.

http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3897&stc=1&d=1263939268

Kenjones1935
- 20th January 2010, 03:07
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
- 20th January 2010, 04:43
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
- 20th January 2010, 09:02
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

mackrackit
- 20th January 2010, 11:02
Ken,

Get a USB to serial converter. You do not want to mess with USB from the PIC at this time. Keep it simple.

The use the serial terminal in MCS.

Kenjones1935
- 20th January 2010, 20:39
I have discovered the Analyzer Tool in the PICkit Tool Logic Tool package.

It looks like this tool will provide me a picture of the output of my radio receiver if I can get Scalerobotics' program to work. I have both MPLAB IDE and PICbasic PRO packages. They have some duplications. I have a book "PIC PROJECTS" which pontificates the advantages of MPLAB. I have an impressive PICkit Tool HELP menu.

My impression is that the PICkit package is what I should focus upon. Does that make sense?

Ken

Kenjones1935
- 21st January 2010, 05:32
I succeeded in getting scalerobotics second code sample to compile.

This is the one that samples PWM incoming and puts it out the serial port. It created an .asm file that would not build. The list of errors is too large to publish here. (Besides that it does not word wrap well.)

I am completely missing something. I do not understand PICBASIC PRO.The multiple hundred page microchip DATA SHEETS blow my mind. I try to read a section (16F887 Page 74 on SOFTWARE PROGRAMMABLE PRESCALER) and I can not put it in context.

I am not sure where the basics are that I am meant to go back to. I have a couple of paperback books. Maybe I should read page by page.

Ken

rmteo
- 21st January 2010, 16:51
A good understanding of PIC's as well as a some idea of how BASIC works will be a great help to your success in getting this project going. Here are 2 free books that will give you a good start.

PIC Microcontrollers (http://www.mikroe.com/en/books/picmcubook/)
Programming PIC MCUs in BASIC (http://www.mikroe.com/en/books/picbasicbook/00.htm)

Kenjones1935
- 21st January 2010, 18:23
Scalerobotics,

How did you know of the contents of:

http://darreltaylor.com/DT_INTS-14/asm_ints.html

and

http://www.picbasic.co.uk/forum/showpost.php?p=65639postcount=38

Is there a centralized resource?

Ken

Acetronics2
- 21st January 2010, 18:25
Hi, Rmteo

If your first reference is useful to understand the Pics themselves, the second is TOTALLY unadapted to help a PbP Beginner for Basic, as the two " basics" are much, much, much differents one from the other ...

let's say ... Pbp looks like the old GWBasic - or very close to Parallax Basic ... But Mikroelektronika Basic ( did I say " Basiç " ??? ) looks very, very, very close to " C " ...

Do not tell me " false " ... as I use those 3 Compilers !!!

Sooooo, the best Basic course for PbP you can find is PARALLAX ... here:

http://www.parallax.com/tabid/535/Default.aspx

here ... you'll find a progressive and comprehensive learning curve, with level adapted examples, and OVERALL ...
What you've learnt is directly re-usable ...

last, but not least !

Alain

Kenjones1935
- 21st January 2010, 20:49
The computer architecture part of

http://www.mikroe.com/en/books/picmcubook/ch0/

reminded me of the lectures I received in 1957 when I was hired as a computer programmer by Lincoln Labs to work on the SAGE Air Defense computer. If you want to read what preceeded the picmcubook (above) look at:

http://history.sandiego.edu/GEN/20th/sage.html

I started my career coding for SAGE. I graduated from CISCO Systems as a Senior Software Engineer in 2003. Since that time my mind has not been focused on technology.

I feel that my problem with PBP and the 16F887 is lack of access to the 'common knowledge'. How did scalerobotics know about darreltaylor?

mackrackit
- 21st January 2010, 21:06
How did scalerobotics know about darreltaylor?
Darrel is one of the moderators of this forum and one of the largest contributors.
Hands down he is the one with all of the "interesting" stuff.

Hang around and you will meet him.

Ken,
You are doing fine for starting work on a new system. We talk about "basics". Just work on things one piece at a time, not the whole project. When all of the pieces work then put it all together.

I get a laugh from the "Object Oriented" folks from other languages. And I even hear about "extreme programming".

Us working with MCUs have been doing the above sort of thing for.... ever.
Write your code in pieces, make sure each piece works, then combine the pieces.

So in your case, reading the PWM is one part, get that working.
Move on to running a motor with PWM, a separate little project and code.
Work on the sensors, another separate project.
And so on...

Pretty soon you will have the whole thing finished and understand it all.

Architecture... Princeton or Harvard? :)

rmteo
- 21st January 2010, 21:10
You can get a lot of "common knowledge" here Microchip Technology User Forums (http://www.microchip.com/forums/Default.aspx?) as well as quite a few other places.

Bruce
- 22nd January 2010, 02:02
Just curious .. rmteo ... do you use PBP?

Kenjones1935
- 22nd January 2010, 02:15
The PICBASIC PRO compiler book that comes (for $250) with MIcroEngineering Labs product does not mention built in routines. I found a chapter in a MikroElektrnonika "Programming PIC MCUs in BASIC"on line book devoted to these. I assume they work with my system. True? I don't think so.....sigh

http://www.mikroe.com/en/books/picbasicbook/05.htm


The above book says,

-------start snip---------------
Prototype sub procedure EEprom_Write(dim Address as byte, dim Data as byte)
Description

Function writes byte to [Address]. [Address] is of byte type, which means it can address only 256 locations. For PIC18 MCU models with more EEPROM data locations, it is programmer's responsibility to set SFR EEADRH register appropriately.

All interrupts will be disabled during execution of EEPROM_Write routine (GIE bit of INTCON register will be cleared). Routine will set this bit on exit

Ensure minimum 20ms delay between successive use of routines EEPROM_Write and EEPROM_Read. Although EEPROM will write the correct value, EEPROM_Read might return undefined result.
Example

for i = 0 to 20
EEPROM_Write(i, i + 6)
next i
-------------------end snip----------------

I tried the following bit in my PBP compiler.

i VAR BYTE
for i = 0 to 20
EEPROM_Write (i, i + 6)
next i

It complained that the EEPROM line has a syntax error.

What am I just not grasping.....??? I assume the two BASIC packages differ. The question is where do I find the built in routines that come with MY PBP?

Ken

Bruce
- 22nd January 2010, 02:26
Ken,

If you're working with PBP, you need to forget about anything you read for the Mikroe BASIC compiler. These are two totally different compilers.

Everything you need to know about PBP is in the PBP manual. What you don't understand, just ask about here.

mackrackit
- 22nd January 2010, 04:07
Ken,

Have you been to this page?
http://www.melabs.com/resources/samples.htm

As for routines. I would say that just about every "command" listed in the PBP manual is a routine. ADCIN for example. The routine for reading the chip's ADC is built into that command.

Keep asking questions :)

Kenjones1935
- 22nd January 2010, 05:36
This PWM exercise is designed just for what I have done.

http://www.melabs.com/resources/samples/pbp/hardpwm.bas

After loading the .hex into the RC car (carrying my PICkit2), hooking up another battery and connecting CCP1 to the electronic speed control, The wheels spin!!

Ain't technology grande!

Ken

mackrackit
- 22nd January 2010, 10:04
COOL!!!
Another piece down!

Did you get Walter's PWM reading code to work?
If so then maybe now you can combine the two.

If incoming PWM is X then wheels turn sort of thing?

ScaleRobotics
- 22nd January 2010, 18:36
Scalerobotics,

How did you know of the contents of:
http://darreltaylor.com/DT_INTS-14/asm_ints.html
and
http://www.picbasic.co.uk/forum/showpost.php?p=65639postcount=38

Is there a centralized resource?
Ken

I learned about them from the great folks on this forum. Without it, I couldn't do any of the things I think are pretty slick. Really, everything that I think is pretty amazing, was learned from reading, searching, and asking on this forum. Aside from the 222 page PicBasicPro manual, the forum is the most centralized resource that you will find.

I would agree with Alain, after reading the PBP manual and it's examples, the next best resource of examples is www.parallax.com site will have the best examples of basic. I have a Pic Basic Pro book that I hate, and I have browsed a few others that I dislike equally. Most are using examples of PIC16C devices and such that are older than my dog, and don't talk much on timers, interrupts, etc. I say save your money, and get the free examples that Parallax has in their documentation, and use this forum. Also read your manual from cover to cover two or three times. It will start to sink in, as you use the commands.

You can learn more about the DT_INTS by searching the forum. Besides Darrel's page, this is the only other source for information on how to use his interrupts.

Kenjones1935
- 22nd January 2010, 23:26
As I said, the wheels go round, but...

The wheels are not going round and round in the pattern I expected. In particular they only go backwards. The code claims to sweep from 20% to 80% cuty cycle.

SOOO, can I use my USB connection and PICkit 2 Logic and Analyze Tool to see what is actually happening?

Ken

ScaleRobotics
- 22nd January 2010, 23:58
I believe you are using the PWM example here: http://www.melabs.com/resources/samples/pbp/hardpwm.bas

This is a PWM that is not supposed to work with RC servo's. It's wave form is different. It is used to dim LED's etc. I am a little surprised that it can turn the wheels at all. I have a scope to help me view wave forms. I have tried for a few minutes to see what the pickit's logic tool can do, but I have not had any success. I am pretty sure it is just a problem with the operator (me).

rmteo
- 23rd January 2010, 00:03
This is what the program header says:

' PicBasic Pro Program to demonstrate hardware PWM.
' Output is a 1Khz signal with duty cycle sweeping
' from 20% to 80% once per second

Since the frequency is 1KHz, its period is 1mS. The duty cycle is sweeping from 20% to 80% therefore the pulse width is varying from 0.2mS to 0.8mS. There are 2 problems here. For R/C signals, the period should be 20mS or 50Hz. Second, the pulse width should be 1.5mS for neutral, 1.0mS for extreme left (or full reverse) and 2.0mS for extreme right (or full forward). So your car is responding to a very short pulse (even less than full reverse). You have to modify the values in the program to get it to do what you expect.

Kenjones1935
- 23rd January 2010, 01:31
Thanks gang.

I came to much the same conclusion myself. I have been trying to figure out what exactly this PWM code does so that I can modify it meet the RC specs. The comments in the program are fairly clear. My first attempts have not worked but I am optimistic.

Interesting how rusty my brain has become.

Ken

Kenjones1935
- 23rd January 2010, 05:14
Here is the code that makes the wheels spin.

http://www.melabs.com/resources/samples/pbp/hardpwm.bas

There are no PBP commands that overtly make pulses. They are created by appropriately loading CCP1CON and CCPR1L. I found CCP1CON easily enough. It is listed in the INDEX of the 16F887 Data Sheet. CCPRxL and CCPRxH are not in INDEX. They are quietly mentioned on page 127. But why is there no HPWM command per page 86 in the PBP manual?


Although I see how this might be a low cpu overhead way to create PWM, I don't want to learn about this now. I want to use PBP and ASM commands to control my motor and servo. Maybe tomorrow all this will make sense.

Ken

Kenjones1935
- 23rd January 2010, 23:49
The code in

http://www.melabs.com/resources/samples/pbp/hardpwm.bas

makes the wheels of my car go backwards in bursts. The bursts last, maybe 3/4 second then the wheels stop for a 1/4 second. I look at the code . I think that it is supposed to sweep through all pulse sizes in a second. I surmise the short ones are too short so the wheels don't move. As they get longer the come up near the low end of the electronic speed control spec. They start to move. Then the second is over.

I would like to pump PWM pulses out CCP1 that have a frequency of one every 20 msec (50 per second) and a pulse width that I can (by changing the code) vary from 1 msec to 2 msec. Am I correct in guessing that the frequency of the pulses is dictated by the PAUSE command. One pulse per loop through mainloop:

So far all my attempts have created no forward wheel motion at all! If one of you has the time please modify hardpwm.bas so that I understand it. Or, better yet, show me how to use PULSOUT. That does not work for me either.

Ken

Kenjones1935
- 25th January 2010, 00:33
I've got code that searches for "duty" that runs the motor. I have found the region that drives it backwards and that keeps it motionless. So far i have not found the forward moving pulse size, but it will not be long now.

Ken

mackrackit
- 25th January 2010, 02:47
A DC motor needs to have the polarity reversed to change the rotation???

Kenjones1935
- 25th January 2010, 03:27
Yes, DC motors need the polarity changed to change direction. I was led to believe that there is something magical in this electronic speed control that made it work differently. Thank you for reminding me to question assumptions.

Ken

Kenjones1935
- 25th January 2010, 03:47
If the electronic speed control does not reverse polarity as a function of pulse size, then I will need to use the technique Fritsl used in his wall hugging robot.

http://letsmakerobots.com/node/928

(which seems no longer available)

He cross wired the motor with multiple DPDT relay switches controlled by his PIC. I was going to copy that idea, but then I started believing the story of the magical ESC.

mackrackit
- 25th January 2010, 12:50
Hi Ken,
This may or may not be helpful, I think diagram "A" on page #3 might be to your fancy.
http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3034&d=1228220843

Acetronics2
- 25th January 2010, 13:17
I would like to pump PWM pulses out CCP1 that have a frequency of one every 20 msec (50 per second) and a pulse width that I can (by changing the code) vary from 1 msec to 2 msec. Am I correct in guessing that the frequency of the pulses is dictated by the PAUSE command. One pulse per loop through mainloop:


CCP1 PWM @ 50 Hz ??? ... just read your Datasheet first !!!

NOW ... triggering the CCP1 module ( in compare mode ) @ 50 Hz ( from a timer ) looks much better ...

might be the PULSOUT could also do the trick for a CPU " locking time " of 2 ms ... if possible.

Now, a good program flow allows many, many things for R/C systems without using interrupts or peripherals ...

Alain

Kenjones1935
- 25th January 2010, 21:27
FATUBA manufactured the radio receiver in my RC car. It is the output of that box that I am trying to emulate coming out of my 16F887. They say here that reversing direction is done by controlling the PWM pulse size above or below 1.5ms. That is what I have been doing - I thought.

Attached is a quote from Electronic Control for DC Motors Using Discrete Bridge Circuits. It seems to say that my ESC should accept servo type PWM signals.


Is the output signal digital?

Output signals are ANALOG. Receivers vary by design on how they RECEIVE and ENCODE signals. But all deliver very similar output pulse signals, which is used to drive the servo to the desired location. This output pulse ranges from 1000uS to 2000uS, with 1500uS typically being center.
Is the output signal an on/off signal or does it have an internal regulator?

The output signal for each channel is a pulsed signal. The pulse width (commonly 1000uS to 2000uS) is determined by the corresponding channel of the transmitter. When activated by one of the proportional channels (such as elevator, aileron, throttle, rudder, or knob control) the pulse width will vary. This controls the servo movement. Most servos will be centered when the pulse is at 1500uS. Channels that are controlled by a switch (such as the gear channel) will operate the pulse width from two set values such as 1100uS when in one position and 1900uS when set to the other position to activate servo movement.
What signal does the receiver emit to differentiate forward or backward movement?

Direction of movement is determined by the direction in which the respective pulse is shifted off of center (neutral). Center being 1500uS, if the pulse is shifted above 1500uS, the direction of travel is one direction. If the pulse is shifted below 1500uS, the direction of travel is in the opposite direction.

rmteo
- 25th January 2010, 21:38
I gave you that info in post #44.


Since the frequency is 1KHz, its period is 1mS. The duty cycle is sweeping from 20% to 80% therefore the pulse width is varying from 0.2mS to 0.8mS. There are 2 problems here. For R/C signals, the period should be 20mS or 50Hz. Second, the pulse width should be 1.5mS for neutral, 1.0mS for extreme left (or full reverse) and 2.0mS for extreme right (or full forward). So your car is responding to a very short pulse (even less than full reverse). You have to modify the values in the program to get it to do what you expect.

Kenjones1935
- 25th January 2010, 21:58
Thank you all for your help. I posted those quotes because they back up what you have been saying and what I thought I coded.

Trouble is my PIC code only makes my car wheels go backwards and stop. I have not been able to create a PWM stream that drives the wheels forward. I know the ESC works because the wheels go fine under radio control.

Oscilloscope, here I come.

Ken

ScaleRobotics
- 26th January 2010, 19:06
Oscilloscope, here I come.


Great idea Ken. I don't know how much you have modified hardpwm.bas, but here it is in it's native form. First pic is about 20 percent, and second pic is about 80 percent (of a 1ms pulse):

http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3919&stc=1&d=1264528836

http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3920&stc=1&d=1264528837

You will notice that the min is about 0.2ms and max is 0.8ms.

Your servo or speed controller requires a pulse width between 1.0ms and 2.0ms. It would probably like to see these pulses every 20ms or so, not every 1 ms (as seen here).

And here is what you want it to look like (from my rc receiver):
http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3921&stc=1&d=1264529813

Kenjones1935
- 27th January 2010, 03:13
The pictures you attached match my mental picture of what I have created. First I modified the .bas to make consistant 1.35ms pulses. The PAUSE command creates the spacing in time. This drove the car quite fast backwards with no hesitations. Next 1.5ms. The wheels stopped. From that point I increased (not automatically) the pulse width up past 2ms to no avail. I never got the car wheels to turn forward.

Where can I find the assembly language code for the Basic commands?

I gather from reading the manual that PAUSE is not a pure interrupt driven behavior. I can not use that command if it shuts down the PIC between pulses.

I have two plans.

1. Study Assembly Language programming. I do not see enough explanation in the PBP manual to feel confident in what Basic Pro is actually doing. I should be able to get the PIC to better communicate to me what it is doing via the LED's.

2. Attach CCP1 to the servo that steers the car instead of the drive wheels. I know what a servo is and I know this one works.

3. Make the effort to find an oscilloscope. My only access at this time is the CS department at Fitchburg State College. I would rather not use them. I do not really know them that well.

Ken

ScaleRobotics
- 27th January 2010, 04:54
First I modified the .bas to make consistant 1.35ms pulses. The PAUSE command creates the spacing in time.

The "Pause 17" lets you adjust how fast it moves from 20% and 80%. However, it does not adjust the pulse width, which is what you need to be adjusting. I can't explain why it works at all though, but it might be so confused from receiving pulses every 1ms, instead of every 20ms.



Where can I find the assembly language code for the Basic commands?


I suppose MeLabs could have just given us all the assembly code, but that probably does not make good business sense for the company. You can TRY to read some of the assembled code after you compile, but it looks a little jiberish. It is nameofyourfile.lst . Some people have suggested getting a dis-assembler, and disassemble the hex file ... but then I think you loose syntax then.



I gather from reading the manual that PAUSE is not a pure interrupt driven behavior. I can not use that command if it shuts down the PIC between pulses.


In my mind, an interrupt is better, as it will not stall your processing. Pauses can work well with servo's. I have not tried them much with motor controllers. The fact that the pulse code you were using sort of worked is encouraging for simplifying code, and staying away from interrupts.



I have two plans.

1. Study Assembly Language programming. I do not see enough explanation in the PBP manual to feel confident in what Basic Pro is actually doing. I should be able to get the PIC to better communicate to me what it is doing via the LED's.

2. Attach CCP1 to the servo that steers the car instead of the drive wheels. I know what a servo is and I know this one works.

3. Make the effort to find an oscilloscope. My only access at this time is the CS department at Fitchburg State College. I would rather not use them. I do not really know them that well.


I count three plans ..... here is my personal take on them which might be worth less than two cents...

Your plan 1 is for someone that really wants to learn all about each register and each bit, and what they control. This will require reading a lot of the 375 page datasheet. Picbasic takes care of a lot of these details for you, making it easier for most people to create useful projects in a much smaller amount of time. Yes, it masks many of these processes from you, but to me, this is a very good thing!

Plan 2, good idea. I still do not think you are really creating 1.5ms pulses. Why don't you PM me your code, or post it here, and I will PM you back, or post here what I see on my scope using your code.

Plan 3 See above.

Why don't you try this code, just don't use the analog. Change pos value to change servo, or motor controller. It will give you an idea if it only does servo's or if your motor controller will like it.

EDIT:

Ok this code http://www.melabs.com/resources/samples/x2/pbp/servox2.bas

Kenjones1935
- 27th January 2010, 05:04
I am realizing that using PAUSE can not work if my PIC is meant to do some thinking between pulses. I just discovered

http://darreltaylor.com/DT_INTS-14/SPWM.html

He is using interrupts. That is what I was hoping to do in the first place. I'll see if I can figure out what he is saying.

Meanwhile, would you be willing to take pictures of the pulses that my code is making if I posted the code?

Ken

ScaleRobotics
- 27th January 2010, 05:10
Sure! Post what you have, and I will send you some oscilloscope shots.

Kenjones1935
- 27th January 2010, 05:35
Scalerobotics:

This snippet has the capabiltiy to increment the pulse size a little bit at a time.

With this code the car starts out driving very fast backwards, then after five to ten seconds it stops, but never starts up forward.

My theory is that the (PAUSE 20) is what is causing the 50 pulses per second, Is that correct?



duty VAR WORD ' Duty cycle value (CCPR1L:CCP1CON<5:4>)
range VAR word
segment var word
TRISC.2 = 0 ' Set PORTC.2 (CCP1) to output
CCP1CON = %00001100 ' Set CCP1 to PWM
T2CON = %00000101 ' Turn on Timer2, Prescale=4

' Use formula to determine PR2 value for a 1KHz signal,
' 4MHz clock, and prescale=4. (4E6/(4*4*1E3))-1=249
' PR2 = 249 ' Set PR2 to get 1KHz out
' PR2 = 499 ' Set PR2 to get 2KHz out

' Use formula to determine CCPR1L:CCP1CON<5:4> value for
' ends of range 20% to 80%. (249+1)*4*0.2=200 (20% value)
' (249+1)*4*0.8=800 (80% value)
' duty = 200 ' Set duty cycle to 20%

range = 25
duty = 1650 ' Set duty cycle to 1.65msec
segment = 0

mainloop: CCP1CON.4 = duty.0 ' Store duty to registers as
CCP1CON.5 = duty.1 ' a 10-bit word
CCPR1L = DUTY >> 2
Pause 20 ' Pause 1/50 of second
duty = duty + 2 ' Increase duty cycle




IF (duty < (1650 + segment + range)) Then mainloop ' Do it again unless 2 msec

duty = duty + 2 ' Reset to 20% duty cycle

segment = segment + range

PAUSE 2000 'Pause 2 seconds

GoTo mainloop ' Do it forever

ScaleRobotics
- 27th January 2010, 05:59
Here is the result. It changes from off through the percentage points to all the way on, but the period remains constant at about 1.023ms. (I finally got my oscilloscope USB driver to work today!)

http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3924&stc=1&d=1264568200

Kenjones1935
- 27th January 2010, 15:48
Thank you soooo much. What a great tool..

Two things for me to consider.

1. PAUSE seems to not have the affect I expected.
2. The PR2 constant must mean something to PBP, but I can not figure out what.

Lastly, which version of oscilloscope software do you use? Is it freeware or did it cost money. If so, how much?

Ken

Kenjones1935
- 27th January 2010, 18:55
The following code makes the car go full speed backwards, then stop, then full speed forwards, then stop etc. Using the RC system I can control the motor continuously though varying speed. I have not yet figured what HPWM parameters produce various speeds to the ESC. It may be that the over-specification fast pulse frequency is overriding that nuance.

To really discover what this is doing I need to study and understand the ASM code. I think HPWM is interrupt driven. I am concerned because page 87 of the PBP Manual seems to say that the slowest pulse frequency is 245 hz. I want 50 hz.


'************************************************* ***************
'* Name : HPWMcommand.BAS *
'* Author : Ken Jones *
'* Notice : Copyright (c) 2010 [select VIEW...EDITOR OPTIONS] *
'* : All Rights Reserved *
'* Date : 1/27/2010 *
'* Version : 1.0 *
'* Notes : PBP has a HPWM command. Let's try it. *
'* : *
'************************************************* ***************
' Don't forget. The duty cycle is 0 to 256 resolution
MAINLOOP:
HPWM 1,110,50 ' Neutral discovered by experiment.
PAUSE 5000
HPWM 1,64,50 ' Full backwards
PAUSE 2000
HPWM 1,110,50
PAUSE 5000
HPWM 1,164,50 ' Full forward
PAUSE 2000
goto mainloop



Ken

rmteo
- 27th January 2010, 19:36
....I am concerned because page 87 of the PBP Manual seems to say that the slowest pulse frequency is 245 hz. I want 50 hz.

Period = [(PR2) + 1] * 4 * TOSC *(TMR2 Prescale Value)
Frequency = 1/Period

Therefore with a 4MHz clock, the lowest frequency is 244Hz.

Kenjones1935
- 27th January 2010, 22:15
I think I am being told that HPWM can not do the job that I need done. Who has a suggestion?

ScaleRobotics
- 27th January 2010, 22:39
I think I am being told that HPWM can not do the job that I need done. Who has a suggestion?

Did you just open the floor to my broken record again?! Here is my view, but I agree, you (we all) need to hear more viewpoints than mine.

Darrel Taylor Interrupts using TMR0 for pulse width, and TMR2 for 20ms period, and receiver pulse width sensing with CCP1_INT and TMR1. Your chip has them, just need to utilize them.

If you always have an RC receiver on, then you can use that as your time base for 20ms. So, you could use the CCP1_INT to read the pulse width coming from the receiver. (This will use TMR1). Then you could use TMR0, or TMR2 for the pulse width. Every time you calculated the pulse from your CCP1_INT, you would send out your servo pulse on whatever pin you like, or control multiple pins, using the same timer.

You really just need to start playing around with these timers and interrupts, and pulse some pins to get your head around it. But without a scope, it will be pretty difficult in my opinion.

Here some scope info that you asked me about. It is a stand alone, but has a USB port and free software that comes with it. It cost just under $300.00. http://picbasic.co.uk/forum/showthread.php?t=12483

rmteo
- 27th January 2010, 23:50
Ken,

Can you do a LED blinky without using PAUSE (or any other delay commands)? Try to do a 1 second blinky using a timer. When you can do that, you will be well on your way to solving your motor ESC problem.

Kenjones1935
- 28th January 2010, 05:45
Guys and maybe Gals,

I am getting frustrated. I can not find the documentation that I need. I need Assembler Language details for the 16-bit chips. I need 16-bit BASIC libraries (Microchip talks C, not Basic). Darrel Taylor is rebuilding his site. He is not accepting new members.

Microchip has screwed up on this link:

MPLAB Assembler, Linker and Utilities for 16-Bit Devices User's Guide
which points to-->
http://ww1.microchip.com/downloads/en/DeviceDoc/51317G.pdf

But when you download51317G you discover it is about the 24-BIt devices. It is the same document that -->

DS51317 - MPLAB Assembler, Linker and Utilities for PIC24 MCUs and dsPIC DSCs User's Guide

points to.

What is the number for the 16-Bit devices user's guide?? I have not found a complete list of Assembly language code, syntax, structure whatever! Without that I do not see how I can understand what this 16F887 is doing.

Also it is late. I am going to bed.:mad:

Ken

mackrackit
- 28th January 2010, 06:02
Ken,

Darrel's site must have been down for what evere reason. It seems to work now.
http://www.PBPgroup.com/

ASM instuctions are normally in the devices data sheet. But... Please do not take this the wrong way. If you are having trouble with Basic I doubt it ASM will do much good.

I like remto's sugesstion about blinky. Give that a shot.

rmteo
- 28th January 2010, 06:14
Firstly, your PIC16F887 is a 14-bit core device and the ASM manual is here MPASM™ Assembler, MPLINK™ Object
Linker MPLIB™ Object Librarian User’s Guide (http://ww1.microchip.com/downloads/en/DeviceDoc/33014K.pdf)

Next thing you really need to download is the data sheet PIC16F887 (http://ww1.microchip.com/downloads/en/DeviceDoc/41291F.pdf)

Also, download this FREE book and read it to understand how a PIC works PIC Microcontrollers (http://www.mikroe.com/en/books/picmcubook/)

The last one is the most useful - I pointed this out to you in an earlier post.

mackrackit
- 28th January 2010, 09:02
Ken,
I do not know anything about RC stuff, but here is something to play with.


<font color="#000080"><i>'16F887 INT RUPT
'44 PIN DEMO BOARD
</i></font>@ <font color="#0000FF"><b>__config _CONFIG1</b></font>, <font color="#0000FF"><b>_INTRC_OSC_NOCLKOUT </b></font>&amp; <font color="#0000FF"><b>_WDT_ON </b></font>&amp; <font color="#0000FF"><b>_MCLRE_OFF </b></font>&amp; <font color="#0000FF"><b>_LVP_OFF </b></font>&amp; <font color="#0000FF"><b>_CP_OFF
INTCON</b></font>.<font color="#800000"><b>5 </b></font>= <font color="#800000"><b>1 </b></font><font color="#000080"><i>'ENABLE TMR0 DATA SHEET SECTION 14.3.2
</i></font><font color="#0000FF"><b>OSCCON </b></font>= <font color="#800000"><b>%01110000 </b></font><font color="#000080"><i>'8 Mhz
</i></font><font color="#0000FF"><b>OPTION_REG </b></font>= <font color="#800000"><b>%10000111 </b></font><font color="#000080"><i>' 1:256 PRESCALE
</i></font><font color="#FF0000"><b>ON INTERRUPT GOTO </b></font><font color="#0000FF"><b>TLOOP
CNT </b></font><font color="#FF0000"><b>VAR BYTE
</b></font><font color="#0000FF"><b>D </b></font><font color="#FF0000"><b>VAR BYTE
</b></font><font color="#0000FF"><b>D </b></font>= <font color="#800000"><b>0

</b></font><font color="#0000FF"><b>START</b></font>:
<font color="#FF0000"><b>FOR </b></font><font color="#0000FF"><b>CNT </b></font>= <font color="#800000"><b>0 </b></font><font color="#FF0000"><b>TO </b></font><font color="#800000"><b>150
</b></font><font color="#FF0000"><b>PWM </b></font><font color="#0000FF"><b>PORTD</b></font>.<font color="#800000"><b>7</b></font>,<font color="#0000FF"><b>D</b></font>,<font color="#800000"><b>100
</b></font><font color="#0000FF"><b>D </b></font>= <font color="#0000FF"><b>D </b></font>+ <font color="#800000"><b>2
</b></font><font color="#FF0000"><b>NEXT </b></font><font color="#0000FF"><b>CNT
</b></font><font color="#FF0000"><b>GOTO </b></font><font color="#0000FF"><b>START

</b></font><font color="#FF0000"><b>DISABLE
</b></font><font color="#0000FF"><b>TLOOP</b></font>:
<font color="#0000FF"><b>INTCON</b></font>.<font color="#800000"><b>2</b></font>=<font color="#800000"><b>0 </b></font><font color="#000080"><i>' DATA SHEET SECTION 14.3.2
</i></font><font color="#FF0000"><b>TOGGLE </b></font><font color="#0000FF"><b>PORTD</b></font>.<font color="#800000"><b>4
</b></font><font color="#FF0000"><b>RESUME
ENABLE
</b></font>

mackrackit
- 28th January 2010, 09:39
http://www.picbasic.co.uk/forum/showthread.php?t=222
Might also help??

ScaleRobotics
- 28th January 2010, 10:34
I had earlier success in getting a servo pulse width to be smooth on a Pic18F2520. But I am now trying to make DT_INTS servo pulse width for a PIC12F683. I have it sweeping from about .95ms to 1.9 ms, but it is not smooth at all. In fact, on the scope, it sometimes switches direction (starts to get wider instead of narrower for a fraction of a second). It is pretty darn ugly in fact.

Any ideas what I might have done (or not done) to cause this?

PIC12f683


</i></font><b>DEFINE </b>OSC 8
<b>INCLUDE </b><font color="#FF0000">&quot;DT_INTS-14.bas&quot; </font><font color="#000080"><i>;interrupt routines
</i></font><b>INCLUDE </b><font color="#FF0000">&quot;sub16.inc&quot; </font><font color="#000080"><i>; subtract 16 bit macro

</i></font><b>DEFINE </b>DEBUG_REG GPIO
<b>DEFINE </b>DEBUG_BIT 0

<b>DEFINE </b>DEBUGIN_BIT 1
<b>DEFINE </b>DEBUG_BAUD 38400
<b>DEFINE </b>DEBUG_MODE 0

INTCON = %10101000 <font color="#000080"><i>'internal oscillator
</i></font>OSCCON = %01110000 <font color="#000080"><i>'set for 8mhz internal
</i></font>CMCON0 = 7 <font color="#000080"><i>'TURN COMPARITORS OFF
</i></font>TRISIO = %010000 <font color="#000080"><i>'Set GSIO 4 INPUT, others to OUTPUT
</i></font>OPTION_REG = %11000010
T1CON = %01000001
T2CON = %01001110
servo <b>VAR </b>GPIO.2
servo = 0
pulse <b>VAR BYTE

</b>pulse = 0
bittest <b>VAR BIT

ASM
</b><font color="#008000">INT_LIST macro </font><font color="#000080"><i>; IntSource, Label, Type, ResetFlag?
</i></font><font color="#008000">INT_Handler TMR0_INT, PulseOut, ASM, yes
INT_Handler TMR2_INT, period, ASM, yes
INT_Handler TMR1_INT, test, ASM, yes
endm
INT_CREATE </font><font color="#000080"><i>; Creates the interrupt processor

</i></font><font color="#008000">INT_ENABLE TMR0_INT </font><font color="#000080"><i>; Enable pulseout interrupts
</i></font><font color="#008000">INT_ENABLE TMR2_INT </font><font color="#000080"><i>; enable period interrupt (20ms)
</i></font><font color="#008000">INT_ENABLE TMR1_INT </font><font color="#000080"><i>; enable interrupt to increment pulse width (test)
</i></font><b>ENDASM

</b>Main:
nop
<b>GOTO </b>Main

<font color="#000080"><i>'---[TMR0_INT - interrupt handler]------------------------------------------

</i></font><b>ASM
</b><font color="#008000">PulseOut
btfsc _bittest </font><font color="#000080"><i>;test status of bittest bit
</i></font><font color="#008000">goto $+7 </font><font color="#000080"><i>;if high skip 7 lines
</i></font><font color="#008000">bcf OPTION_REG,5 </font><font color="#000080"><i>;stop timer
</i></font><font color="#008000">movf _pulse,w </font><font color="#000080"><i>;load TMR0 with value of pulse variable
</i></font><font color="#008000">movwf TMR0
bsf _bittest </font><font color="#000080"><i>;set bittest bit, indicating we are on second half
</i></font><font color="#008000">bsf OPTION_REG,5 </font><font color="#000080"><i>;start timer again for second interrupt
</i></font><font color="#008000">goto $+3 </font><font color="#000080"><i>;skip to return from interrupt
</i></font><font color="#008000">bcf OPTION_REG,5 </font><font color="#000080"><i>;stop timer
</i></font><font color="#008000">bcf _servo </font><font color="#000080"><i>;bring servo pin low for end of pulse width
</i></font><font color="#008000">INT_RETURN

</font><b>ENDASM
</b><font color="#000080"><i>'---[TMR2_INT - interrupt handler]------------------------------------------
</i></font><b>ASM
</b><font color="#008000">period
bsf _servo </font><font color="#000080"><i>;set servo pin high (begin pulse width)
</i></font><font color="#008000">movlw d'0' </font><font color="#000080"><i>;set timer0 to 0 (full length of timer)
</i></font><font color="#008000">movwf TMR0
bsf OPTION_REG,5 </font><font color="#000080"><i>;start timer0, now PulseOut interrupt will occur
</i></font><font color="#008000">bcf _bittest </font><font color="#000080"><i>;clear bittest bit
</i></font><font color="#008000">INT_RETURN
</font><b>ENDASM
</b><font color="#000080"><i>'---[TMR1_INT - interrupt handler]------------------------------------------
</i></font><b>ASM
</b><font color="#008000">test
incf _pulse
INT_RETURN
</font><b>ENDASM

</b></code></pre><!--EndFragment--></body>
</html>

Acetronics2
- 28th January 2010, 13:35
Hi,

I remember some batches of 12F683 did not like the duty value to be changed " on the fly " and needed to stop and restart the CCP module.

Was written on the µChip datasheet ( prior to D release )...

I think some lines about it exist on this forum.


But you don't use the CCP module ...

What I see more is you want to stop Timer0



bcf OPTION_REG,5 ;stop timer


Option.5 is the TOCS bit ... and that's not a good thing to switch clock to TockI pin ...

Alain

ScaleRobotics
- 28th January 2010, 19:02
Thanks Alain, that was it!

I changed those to:


bsf INTCON,5 ;enable timer0 interrupt

and

bcf INTCON,5 ;disable timer0 interrupt


and now the pulse runs smoothly. Only I don't get the initial set timer0 to 0, then add the second half of pulse width. I only get the second half where TMR0=pulse. So pulse width is between 0 and 1ms.

But I will work on that!

Thanks again,

Walter

Kenjones1935
- 28th January 2010, 20:12
Thank you for setting me straight on which document is which.

DS33014K is just what I have been looking for.

Tuesday Darrel Taylor's site said that it was under construction and that it would not accept new membership.

I have coded in C and in Assembly. More recently in shell and tcl. I never had a reason to use Basic as none of my professional work used a PC.

I think this 33014 will get me started.

Scalerobotics, if you get a chance see if you can record the radio receiver output signals for the other channels. In particular one which is just ON-OFF from the point of view of the transmitter.

Ken - thanks gang.

rmteo
- 28th January 2010, 20:34
Ken,

....ASM instuctions are normally in the devices data sheet. But... Please do not take this the wrong way. If you are having trouble with Basic I doubt it ASM will do much good.

I like remto's sugesstion about blinky. Give that a shot.

Ken, I highly recommend taking Dave's advise. You need a better understanding of what makes a PIC tick (hint, read the free book I linked to). When you have that under your belt, then the coding is the really easy part. It doesn't matter whether you use C, BASIC (PBP or some other variant) or ASM - the situation is the same.

ScaleRobotics
- 29th January 2010, 11:40
Here is some code that will measure an RC receiver pulse width coming in on GPIO.2, perform a little math on the value, and put out the wave form out on GPIO.1, using DT Interrupts.

It's on a little 12F683 and was written for 8mhz internal. Looks pretty good on the scope. I need to test it on a motor controller though. But time for bed.....



<html>
<head></head>
<body><!--StartFragment--><pre><code><font color="#000080"><i>
</i></font><b>DEFINE </b>OSC 8
<b>INCLUDE </b><font color="#FF0000">&quot;DT_INTS-14.bas&quot;</font><font color="#000080"><i>;interrupt routines
</i></font><b>INCLUDE </b><font color="#FF0000">&quot;sub16.inc&quot; </font><font color="#000080"><i>; subtract 16 bit macro

</i></font><b>DEFINE </b>DEBUG_REG GPIO
<b>DEFINE </b>DEBUG_BIT 0
<b>DEFINE </b>DEBUGIN_BIT 1

<b>DEFINE </b>DEBUG_BAUD 38400
<b>DEFINE </b>DEBUG_MODE 0

INTCON = %10101000 <font color="#000080"><i>'
</i></font>OSCCON = %01110000 <font color="#000080"><i>'set for 8mhz internal
</i></font>CMCON0 = 7 <font color="#000080"><i>'TURN COMPARITORS OFF
</i></font>ANSEL = %00000000 <font color="#000080"><i>'Set A/D OFF
</i></font>ADCON0 = %00000000 <font color="#000080"><i>'Analog converter OFF
</i></font>TRISIO = %010100 <font color="#000080"><i>'Set GSIO 4 and 2 to INPUT, others to OUTPUT
</i></font>OPTION_REG = %11000010
T1CON = %00110001
T2CON = %01001110
CCP1CON = %00000101

risetime <b>VAR WORD </b><font color="#000080"><i>;used for pulse width measure start of pw

</i></font>falltime <b>VAR WORD </b><font color="#000080"><i>;time at end of pulse width
</i></font>falltime_l <b>VAR </b>falltime.Byte0
falltime_h <b>VAR </b>falltime.Byte1
risetime_l <b>VAR </b>risetime.Byte0
risetime_h <b>VAR </b>risetime.Byte1
pulsewidth <b>VAR WORD
</b>pulsewidth_l <b>VAR </b>pulsewidth.Byte0
pulsewidth_h <b>VAR </b>pulsewidth.Byte1

ServoOut <b>VAR </b>GPIO.1
ServoOut = 0
pulse <b>VAR BYTE

</b>TMR0 = 0
pulse = 255
bittest <b>VAR BIT

ASM
</b><font color="#008000">INT_LIST macro </font><font color="#000080"><i>; IntSource, Label, Type, ResetFlag?
</i></font><font color="#008000">INT_Handler TMR0_INT, PulseOut, ASM, yes
INT_Handler TMR2_INT, period, ASM, yes
INT_Handler CCP1_INT, PWMeasure, ASM, yes
endm
INT_CREATE </font><font color="#000080"><i>; Creates the interrupt processor

</i></font><font color="#008000">INT_ENABLE TMR0_INT </font><font color="#000080"><i>; Enable pulseout interrupts
</i></font><font color="#008000">INT_ENABLE TMR2_INT </font><font color="#000080"><i>; enable period interrupt (20ms)
</i></font><font color="#008000">INT_ENABLE CCP1_INT </font><font color="#000080"><i>; enable interrupt to increment pulse width (test)
</i></font><b>ENDASM
PAUSE </b>200
Main:
<b>PAUSE </b>20
<font color="#000080"><i>;debug dec pulsewidth,&quot; &quot;,10,13
</i></font>pulse = ((pulsewidth * 8)/10)-167 <font color="#000080"><i>;scale to fit into a byte
</i></font>pulse = 255 - pulse <font color="#000080"><i>;reverse the stick


</i></font><b>GOTO </b>Main

<font color="#000080"><i>'---[TMR0_INT - interrupt handler]------------------------------------------

</i></font><b>ASM
</b><font color="#008000">PulseOut
btfsc _bittest </font><font color="#000080"><i>;test status of bittest bit
</i></font><font color="#008000">goto $+7 </font><font color="#000080"><i>;if high skip 7 lines
</i></font><font color="#008000">bcf INTCON,5 </font><font color="#000080"><i>;stop timer
</i></font><font color="#008000">movf _pulse,w </font><font color="#000080"><i>;load TMR0 with value of pulse variable
</i></font><font color="#008000">movwf TMR0
bsf _bittest </font><font color="#000080"><i>;set bittest bit, indicating we are on second half
</i></font><font color="#008000">bsf INTCON,5 </font><font color="#000080"><i>;start timer again for second interrupt
</i></font><font color="#008000">goto $+3 </font><font color="#000080"><i>;skip to return from interrupt
</i></font><font color="#008000">bcf INTCON,5 </font><font color="#000080"><i>;stop timer
</i></font><font color="#008000">bcf _ServoOut </font><font color="#000080"><i>;bring ServoOut pin low for end of pulse width
</i></font><font color="#008000">INT_RETURN



</font><b>ENDASM
</b><font color="#000080"><i>'---[TMR2_INT - interrupt handler]------------------------------------------
</i></font><b>ASM
</b><font color="#008000">period
movlw d'72' </font><font color="#000080"><i>;fine tune timer2 period
</i></font><font color="#008000">movwf TMR2
bcf INTCON,2 </font><font color="#000080"><i>;clear timer flag if set
</i></font><font color="#008000">movlw d'17' </font><font color="#000080"><i>;set timer0 first 1ms time base
</i></font><font color="#008000">movwf TMR0
bsf INTCON,5 </font><font color="#000080"><i>;enable timer0 interrupt
</i></font><font color="#008000">bsf _ServoOut </font><font color="#000080"><i>;set ServoOut pin high (begin pulse width)
</i></font><font color="#008000">bcf _bittest
INT_RETURN
</font><b>ENDASM
</b><font color="#000080"><i>'---[CCP1_INT - interrupt handler]------------------------------------------
</i></font><b>ASM

</b><font color="#008000">PWMeasure

BTFSS CCP1CON, CCP1M0 </font><font color="#000080"><i>; Check for falling edge watch
</i></font><font color="#008000">GOTO FALL_EDGE </font><font color="#000080"><i>; Go pick up the falling edge
</i></font><font color="#008000">MOVF CCPR1L,W </font><font color="#000080"><i>; else store leading edge value
</i></font><font color="#008000">MOVWF _risetime_l </font><font color="#000080"><i>; into 16 bit word risetime
</i></font><font color="#008000">MOVF CCPR1H,W
MOVWF _risetime_h
BCF CCP1CON, CCP1M0 </font><font color="#000080"><i>; Now capture the trailing edge
</i></font><font color="#008000">GOTO ISR_2 </font><font color="#000080"><i>; Exit the interrupt service routine

</i></font><font color="#008000">FALL_EDGE:
BSF CCP1CON, CCP1M0 </font><font color="#000080"><i>; Re-set for trailing edge capture
</i></font><font color="#008000">MOVF CCPR1L,W </font><font color="#000080"><i>; Store the captured value into
</i></font><font color="#008000">MOVWF _falltime_l </font><font color="#000080"><i>; falltime_l and ...
</i></font><font color="#008000">MOVF CCPR1H,W
MOVWF _falltime_h </font><font color="#000080"><i>; ... falltime_h
;
; 16 bit subtract
; falltime = falltime - risetime
;
</i></font><font color="#008000">SUB16 _falltime, _risetime </font><font color="#000080"><i>;do 16 bit subtraction to find width
</i></font><font color="#008000">movf _falltime_l,w
movwf _pulsewidth_l
movf _falltime_h,w
movwf _pulsewidth_h
ISR_2
INT_RETURN


</font><b>ENDASM


</b></code></pre><!--EndFragment--></body>
</html>

Kenjones1935
- 30th January 2010, 02:43
At last I am getting the correct reference materials.

DS33014K is telling me about MPASM Assembler, Library and Linker.

I have ordered from Belgrade "PIC Microcontrollers". It is being shipped by air. That alone is pretty amazing. Just a little paperback book.

I have also found an online book at:

http://www.mikroe.com/en/books/picmcubook/ch0/

It may be the same book only on line. I am old fashioned. I like to read from paper.

I have plenty of studying to do. Thank you again and again.

Ken

Kenjones1935
- 1st February 2010, 03:46
I copied your code snip from POST #73 at 3:02 on the 28th of January.

I noticed in the .asm code that it wanted to:

INCLUDE "MACKRA~1.MAC"

There is no such file in my computer. Do I need a copy? May I have one?

Also the compiler complained that:

Error 118: "Overwriting previous address contents (2007)

Page 157 of DS33014K says that Error 118 occurred because "Code was previously generated for this address" I assume it is talking about address (2007). I do not see where in the .asm code this is happening. I do not even know what to look for.

Ken

Kenjones1935
- 1st February 2010, 05:11
Mackrackit,

From what I understand your code will do a PWM every time TMR0 overflows.

What I need to do is make this overflow happen every 20ms. That is 50 pulses per second. We have a 4 meg oscillator. If I were designing this counter I think I would have it set to 20,000 each time it overflows. I gather from page 74 of the Data Sheet that this is not possible. The biggest prescaler is 256.

How about a routine that counts these interrupts until 1/50 of a second has elapsed then calls PWM? I would have it send one pulse out pin 1 with the duty as defined by "duty". It would look like

PWM 1,duty,1

I have found a section on Timers in a book called Running Small Motors with PIC Microcontrollers that has an example of MicroEngineering Labs code that makes an eight digit LCD display the time in hours, minutes and seconds. I think this code must do something like I need.

Ken

rmteo
- 1st February 2010, 05:29
You want 20,000 counts before it overflows. Setting the prescaler to 1:256, you will need 20,000/256 counts = 78. The counter rolls over (overflows and sets T0IF) when it reaches 255, so if you pre-load it with 255-78 = 177, then it will overflow approximately every 20mS.

mackrackit
- 1st February 2010, 12:54
I copied your code snip from POST #73 at 3:02 on the 28th of January.
I noticed in the .asm code that it wanted to:
INCLUDE "MACKRA~1.MAC"
There is no such file in my computer. Do I need a copy? May I have one?
Looks like you have the code named MACKRACKIT?
The *.MAC file is the macro file generated by PBP. It will be in your project directory. The name is chopped to the 8.1? standards.


Also the compiler complained that:
Error 118: "Overwriting previous address contents (2007)
Page 157 of DS33014K says that Error 118 occurred because "Code was previously generated for this address" I assume it is talking about address (2007). I do not see where in the .asm code this is happening. I do not even know what to look for.

Ken
Looks like you are setting the configs in the *.inc file. I have them in the code. Just comment that line out and it should be OK.

mackrackit
- 1st February 2010, 16:29
Mackrackit,
From what I understand your code will do a PWM every time TMR0 overflows.

The code in post #73 will toggle a LED when TMRO overflows. The LED on PORTD.7 will gradually become brighter then turn off and start over again.

This was just an example of an interrupt working with something else going on.

You do have to be careful with this as things will sometimes not work as expected. Like they say, the machine will do what it is told, not what you want :)

This is the same code as in post #73 with some modifications to demonstrate a "pitfall".
The START loop still has PORTD.7 PWMing the LED with PORTD.0 added to be toggled.
Inside of the interrupt loop the same PWM that is on PORTD.7 is now on PORTD.6.

What do you think will happen?
What does happen?


'16F887 INT RUPT
'44 PIN DEMO BOARD

@ __config _CONFIG1, _INTRC_OSC_NOCLKOUT & _WDT_ON & _MCLRE_OFF & _LVP_OFF & _CP_OFF

INTCON.5 = 1 'ENABLE TMR0 DATA SHEET SECTION 14.3.2
OSCCON = %01110000 '8 Mhz
OPTION_REG = %10000111 ' 1:256 PRESCALE
ON INTERRUPT GOTO TLOOP
CNT VAR BYTE
D VAR BYTE
D = 0
HIGH PORTD.0
PAUSE 500

START:
FOR CNT = 0 TO 150
PWM PORTD.7,D,100
D = D + 2
NEXT CNT
TOGGLE PORTD.0
PAUSE 100
GOTO START

DISABLE
TLOOP:
INTCON.2=0 ' DATA SHEET SECTION 14.3.2
TOGGLE PORTD.4
FOR CNT = 0 TO 150
PWM PORTD.6,D,100
D = D + 2
NEXT CNT
RESUME
ENABLE

Kenjones1935
- 1st February 2010, 23:10
Just like you said it would.

Now on to your next one. It compiles and works also. I see what it does. I need to figure out how.

Thank you!!

Kenjones1935
- 2nd February 2010, 03:49
Can anyone point me to a definition of "prescaler".
What I thought it meant does not seem to jive with what I am seeing.

Ken

Kenjones1935
- 2nd February 2010, 04:29
"Running Small Motors with PIC Microcontrollers" says, on page108

"A pre-scaler is applied to the system clock and affects the timer by slowing down the system clock as it applies to the timer. Normally the timer is fed by a fourth of the basic clock frequency, which is called Fosc/4. In a system running a 4 MHz the timer sees a clock running at 1 MHz. If the pre-scaler is set for 1:8, the clock will be slowed down by another eight times, and the timer will see a clock at 125kHz."

"The post-scaler setting determines how may overflows will go by before an interrupt is triggered."

If I pre-scale TMRO 1:256 I will get overflows at about 4K per second. If I add a post-scaler of 1:64 I will end up with about 62 interrupts per second.

Close enough for government work?

Ken

Kenjones1935
- 2nd February 2010, 04:52
I just found in DS33023 section 11.6.

"There is only one pre-scaler available which is mutually exclusively shared between Timer 0 and Watchdog Timer."

So I have to count the 4000 Interrupts per second using a

FOR CNT To 80
NEXT

loop. That will give me much closer to 50 pulses per second.

Correct?

rmteo
- 2nd February 2010, 06:07
See my post #84 above. Which part is unclear to you?

mackrackit
- 2nd February 2010, 10:19
Hi Ken,

I always get confused with this part of things too, so I will just point you to a couple of threads that I refer to when the need arises.

I think maybe the parts about
TMR1L
TMR1H
are the things you need to look at???

http://www.picbasic.co.uk/forum/showthread.php?t=961
http://list.picbasic.com/forum/messages/5058/5387.html?1049090059

Bruce
- 2nd February 2010, 18:30
You could simplify this a great deal if your PIC has Timer1 available, and Compare,
Capture, PWM .. by just using the Compare peripheral.

Here's an example:


DEFINE OSC 4

Match VAR WORD

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
PORTB = PORTB ^ 1 ' Toggle PORTB.0
PIR1.2 = 0 ' Clear compare interrupt flag bit
ENDIF
GOTO LOOPS

END
Just 1 single interrupt could take care of your 20mS timing VS a bunch to accumulate the
total 20mS time period.

A single interrupt every 20mS & no reloading anything. Timer1 is automatically cleared on
match, and the CCPR1L/CCPR1H registers contain the value loaded into them until you
change it.

rmteo
- 2nd February 2010, 19:11
For 20mS timing, you can do it with a single interrupt with any of the 3 timers on the PIC16F887.

Timer0 - Set prescaler to 1:256
Timer1 - As shown above by Bruce
Timer2 - Set prescaler to 1:16, set postscaler to 1:16

Kenjones1935
- 3rd February 2010, 00:32
It seems to me that the most important feature that must be continuously timed in my RC car in autonomous control is the 50 pulses per second Pulse Width Modulated simulation of the RC Receiver to Electronic Speed Control signal. Doing this job in background with one Interrupt sounds correct.

The oscillator seen by TMR0 with pre-scaler runs at 1000000Hz

The pre-scaler 1:256 cuts that down to 3906.25. ie 4kHz.

A post-scaler of 1:64 cuts this down to 61.035Hz. Close enough is my guess. I don't have a grip on how to code this yet. Do I at least understand the concept?

-----------------------another way---------------

Bruce suggests counting up to 20,000 in bits of 1 microsecond. That should be easy enough with a 16 bit register built from TMR1H and TMR1L.

------------now how do I get only one PWM pulse?----------------

Page 135 of the PBP manual seems to indicate that the command:

PWM Pin,Duty,Cycle

will produce "Cycle" number of pulses. It says, "This PWM cycle is repeated "Cycle" times." It also says that, "If a 4mHz oscillator is used, each "Cycle" is about 5ms long."

This seems to mean that the following command:

PWM 1, 75, 1

would produce one pulse about 1.5msec long. This is the neutral pulse for a ESC.

If this is true then writing a routines to control the drive wheels and the steering servo will not be difficult at all.

What do you think?

Ken

Kenjones1935
- 3rd February 2010, 03:58
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
- 3rd February 2010, 17:58
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
- 3rd February 2010, 20:54
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
- 3rd February 2010, 23:18
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?:confused:

Ken

mackrackit
- 3rd February 2010, 23:36
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
- 4th February 2010, 00:50
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
- 4th February 2010, 10:25
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 ???

Bruce
- 4th February 2010, 15:46
Hi Alain,

Yes. It's the 8-pin PIC12F1822.


Enhanced Mid-range Core with 49 Instruction, 16 Stack Levels
Flash Program Memory with self read/write capability
Internal 32MHz oscillator
Integrated Capacitive mTouch Sensing Module
Data Signal Modulator Module
MI2C, SPI, EUSART w/auto baud
ECCP (Enhanced/Capture Compare PWM) Module
Comparator with selectable Voltage Reference
4 Channel 10b ADC with Voltage Reference
25mA Source/Sink current I/O
Two 8-bit Timers (TMR0/TMR2)
One 16-bit Timer (TMR1)
Extended Watchdog Timer (EWDT)
Enhanced Power-On/Off-Reset
Brown-Out Reset (BOR)
In Circuit Serial Programming (ICSP)
On Board In-Circuit Debug
Wide Operating Voltage (1.8V – 5.5V)
Low Power PIC12LF182x variants (1.8V – 3.6V)
Standby Current (PIC12LF182X): 30 nA @ 1.8V, typical

Kenjones1935
- 4th February 2010, 21:25
Guys and Gals,

I might take a side trip to a scenic view along this road.

Here is a pointer to a BASIC (which BASIC I do not know) program that controls a toy level RC car. Toy levels have no Electronic Speed Control. The DC motor and servo are driven by direct current controlled by four DPDT switches. (Bang-Bang: full speed forward, full stop, full speed back.) This project has only autonomous control. The radio receiver has been eliminated. These simplifications plus the fact that the details are on the WEB make this diversion very tempting.

http://letsmakerobots.com/files/wall_racers.bas
and
http://letsmakerobots.com/node/928

I have an appropriate RC car.
I have a spare PICkit2.
I need to translate wall_racers.bas into PBP.
I need to adapt the resulting ASM to my 16F887.
I think I have enough proto. parts for both projects.

My ego needs a boost.

Ken:

mackrackit
- 4th February 2010, 22:33
Ken,

You are kind, intelligent, and I hear good looking.

There is your ego boost :D

Your new approach does sound like a good way to start. Save the PWM for later and work on the other parts.

You may want to think about what Bruce said and go "modular". Then when you do get back to the PWM part it could live on a separate chip.

You said you have some solder-less breadboards, so you could get a few of the 8 or 14 pin chips with ADC to play with. Remember MicrChip has a samples program so you could get three from them to start.

Kenjones1935
- 5th February 2010, 01:37
On the other hand==>

Look at this great oscilloscope-like picture of the PWM pulses (fifty per second) very close to 1.75ms long created by Bruce's PAUSEUS technique. I finally figured out the Analyzer part of the PICkit 2 Logic Tool.

Ken

ScaleRobotics
- 5th February 2010, 02:13
On the other hand==>

Look at this great oscilloscope-like picture of the PWM pulses (fifty per second) very close to 1.75ms long created by Bruce's PAUSEUS technique. I finally figured out the Analyzer part of the PICkit 2 Logic Tool.

Ken

Now that's progress! Great job Ken. That a pretty nice looking scope, and the price makes it look even better!

Now you can see what you are doing .... er (or not doing).

Kenjones1935
- 5th February 2010, 23:32
Fritsl's code compiles and runs on my PICkit2.

The proximity detector (Devantech SRF05) responds with different size pulses (depending on the distance from it to an echoing object) when queried by this code.

Next to prove out control of the four DPDT switches which steer DC to the motor and to the servo, destroy the toy car by ripping out its radio receiver. and figure out how to mount the PICkit, the switches board and the two SRF05's.

Question. Is there any way that I can read through the PICkit programmer what is happening in real time to some of the variables. How do I think about adding debugging code?

Ken

ScaleRobotics
- 7th February 2010, 02:44
In case someone wants to measure multiple RC channels with one CCP1 pin, I did a small expermiment. If you connect every other RC receiver channel to CCP pin using 1N914 diodes (or similar), you will be able to measure pulses from three (or four) RC channels using one pin. Without the diodes, the RC channels that are low, ground out the one that is trying to pulse.

Here is a picture of RC channels 2,4, and 6. Without a channel space between them, they stay high. So, with a PIC that has two CCP pins, you should be able to read all 8 channels!

This picture shows scope yellow probe (rc 2, 4, and 6) with their diodes attached to the scope probe. and scope red probe directly attached to RC channel 2.

http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3969&stc=1&d=1265506922

ScaleRobotics
- 7th February 2010, 22:34
Come to think of it, using one CCP pin, you can decode (however many channels your RC transmitter has - 1). So, using a 6 channel transmitter, you can decode 5 channels using a chip with a single CCP compare pin. To do this, connect RC1, RC3 and RC5 channels from your receiver to the CCP pin with some diodes, and a pulldown resistor. Then capture every transition with capture. The in between pulses are RC channels 2 and 4.

Now to write some code...

http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3975&stc=1&d=1265578229

Kenjones1935
- 9th February 2010, 04:45
Individually the parts of the system seems to pass their tests.
The DPDT switches worked according to their truth tables.
The proximity switches echoed what looked like sensible responses.
The wheels turned and the steering responded as the DPDT switches asked of them.

However, the car does not work as a system. The PIC is running. The proximity sensors have LED's that blink when pulsed. These work. After a while the proximity detectors stop. All this is in the code, but the steering does not move at all. The wheels do not reverse when something is seen to be right in front of the car.

Question is: What kinds of debugging power do I have once the code is in the PIC besides the Logic Tool Analyze mode?

Ken

Archangel
- 9th February 2010, 06:59
Question is: What kinds of debugging power do I have once the code is in the PIC besides the Logic Tool Analyze mode?

Ken
You can hook up a serial LCD to the system and use debug to send the value stored in your variables, you can store port status in a variable and debug too.

ScaleRobotics
- 9th February 2010, 18:09
I made some progress with 5 channel PWM measurement using a single pin. Curently 5 RC channels are being measured using capture on a PIC12f683. Right now, only one channel is being passed through, but it is possible to get a max of 4 channel pass through on this chip. Bruce gave me the idea of measuring all 5 channels on one pin with his remote code learning thread: http://picbasic.co.uk/forum/showthread.php?t=12555

I need to work on getting channel 1 to be recognized as channel 1. Somehow, I need to check for a low on CCP1 for 3ms or so (between channel 5 and channel1). Anyone got a suggestion on how to do this?

Right now, you have to restart the circuit a few times to get channel 1 output to be channel 1 input. It sometimes selects channel2,3,4 or 5 (depends when you turn the chip on, and which rise it sees first). But the output now is pretty rock solid, no jitters.

I tried to label my ASM pretty well, but I need to work on this overall, especially the variables.

total words used = 275

http://scalerobotics.com/PWMpassthrough.html

Acetronics2
- 9th February 2010, 19:00
Hi,

Ok, it's not PBP ... But it does the trick.

http://www.rcgroups.com/forums/showthread.php?t=576165

Alain

ScaleRobotics
- 9th February 2010, 20:07
Hi,

Ok, it's not PBP ... But it does the trick.

http://www.rcgroups.com/forums/showthread.php?t=576165

Alain

Thanks Alain (was that for me, or Ken??),

But I currently am able to encode 1 channel while decoding 5 channels with the below code:

http://scalerobotics.com/PWMpassthrough.html

And soon should be able to add 3 outputs, and have 4 encoded channels out, while decoding 5 channels in with the pic12f683 (and 3 diodes).

But, what I can't get my head around is how to ensure the CCP1 interrupt starts the first time on RC channel 1 (first pulse). It needs to look for a low of 3ms or so, to ensure channel 1 is looking at channel 1.

Oh .... and I need to do this in ASM.

Thanks for any help you can offer.

Acetronics2
- 9th February 2010, 21:33
Hi,

Sorry ... I didn't verify the link ... ( Xtal wrote both enc and dec ...)

those ones are real decoders

Alain

ScaleRobotics
- 9th February 2010, 23:24
Thank you very much Alain, just what I was looking for!

Need to see how they do their "sync gap", but I notice he has a number of other enhancements as well ... interesting.

Walter

Kenjones1935
- 11th February 2010, 04:56
Thanks everyone for working on the RC PWM problems.

Meanwhile I have built a autonomous toy car from the ideas voiced by fritsl in Lets Built Robots.

The DPDT switches work. I have two separate battery packs. The power for the servo and the wheels shares nothing with the power for the PIC and other logic. Not even the ground circuit! This should keep the noise down.

I am using the LED's on the PICkit2 to help debug. At least I can know which routines have been visited. I wish I could figure out a way to know what are in my variables. The USB programmer can read and write all memory locations. Where do I read about real time debugging?

Oh, yes, my new PIC16F887 book arrived via air mail at the Fitchburg, MA Post Office. It is published by MIKROELEKTRONIKA d.o.o in Belgrade, Serbia. How small the world has become.:)

Kenjones1935
- 11th February 2010, 15:59
That's the word I have been looking for.

Is there a mechanism in PBP for setting break points.

Once that is done, is there an easy way using PICkit 2 Programmer to read the contents of a particular register?

Ken

Kenjones1935
- 11th February 2010, 16:11
I see in the PICkit 2 Programmer HELP menu discussion of the Debugger tool. Part of MPLAB IDE.

Trouble is, the programmer in MPLAB seems to not get along with the programmer in PICkit 2. I have not been able to make hide nor hair of MPLAB IDE. I have been using Microcode Studio PBP and PICkit 2 programmer.

What am I missing?

KEn

ScaleRobotics
- 11th February 2010, 17:44
That's the word I have been looking for.

Is there a mechanism in PBP for setting break points.

Once that is done, is there an easy way using PICkit 2 Programmer to read the contents of a particular register?

Ken
The easiest way is to have your project do serial out using the debug statements. With your PicKit you can read the output using the uart tool. Using if then statements, you can set it to give you different information. I use this in trouble shooting a lot.

Kenjones1935
- 12th February 2010, 05:44
My PICkit 2 PORTB outputs do not consistently pull up the coils in the DPDT relays enough to activate them.

The 16F887 outputs measure 2.8v to 3v when driving a coil. I did not find mention of this potential problem in the PICkit2 Manual.. Any ideas anyone?

Is there another Microchip kit that has some output drivers?

Ken

rmteo
- 12th February 2010, 06:58
According to the data sheet, the output high voltage is VDD-0.7 (4.3V with 5V supply) when sourcing 3mA. The absolute max. current sourced/sunk by any I/O pin is 25mA. What does your relay require to activate?

Kenjones1935
- 12th February 2010, 21:04
My ZETTLER AZ8222-2C-5DSE spec says:
Nominal Coil VDC 5 volts
Coil Resistance 125 ohms
Must Operate VDC 3.8 volts.

3.8/125 = 30ma

One relay works out of six when driven by a PORTB output.

NUTS!

Ken

rmteo
- 12th February 2010, 21:20
The current being drawn by the relays is pulling down the voltage to <3V. You need to use a driver (or low VceSat transistor or logic level MOSFET).

Byte_Butcher
- 12th February 2010, 21:57
Keep in mind also that even though each port pin is rated at 25mA maximum, the maximum TOTAL rated current into Vdd or out of Vss is only 95mA.

So even if your relays only draw 20mA, which is within the limits of each port, you could only run 4 of them at once without exceeding the TOTAL current draw through Vdd, because of the 95mA limit.

Like RMTEO said... some nice logic level MOSFETS on the low side of your relay coil is what you need now...


steve

Kenjones1935
- 12th February 2010, 22:17
Does MICROCHIP make an auxiliary board that contains drivers for the PICkit 2 device? I am not capable of soldering onto that PICkit printed circuit board. I already have a good sized non-solder proto board carrying the four DPDT switches, two proximity sensors and a voltage regulator. I am trying to get this whole thing onto a 1/10 scale radio control car.

The guy from whom this idea came used a PICAXE.

Ken

Kenjones1935
- 12th February 2010, 23:05
There are more logic level MOSFET's than Carter has Liver Pills (an expression that easily shows my age).

What I want to do must be very standard.

Suggestions?

Ken

mackrackit
- 13th February 2010, 01:55
http://www.fairchildsemi.com/ds/FD%2FFDD8424H.pdf
I find these handy. Mouser has them.

Byte_Butcher
- 13th February 2010, 02:41
Just to confuse the issue a tad more, one of the other options would be to use a buffer/driver IC like this:
http://focus.ti.com/lit/ds/symlink/sn7407.pdf
Digikey has 'em for under $2, and it gives you up to 6 outputs if you like. MAX current is 40mA.

I did a quick search for nice little MOSFETS in a small through-hole style package (like to-92) and I've gotta say it's pretty depressing. 98% of the stuff out there these days is SMD.

Dave, those little dual MOSFETS are cute. But I'll bet Ken would like something in through-hole...


steve

Kenjones1935
- 13th February 2010, 03:24
I grabbed my "TTL Integrated Circuits Catalog From Texas Instruments" dated 1 August 1969 and found specs on the SN7400, SN7401, SN7402, SN7403, SN7404, SN7405, and SN7410!!

This SN7407 thingie must be one of those newfangled inventions. No wonder I did not recognize it:cool:

Thank you all!!

Byte_Butcher
- 13th February 2010, 05:25
Heh, you've got me beat for "vintage databooks". :)

I've got some National Semiconductor "TTL" and " Analog" data books that go back to '74, and a Signetics data book from '76, but nothing that goes back to the 60's...

Hey, It's 2010 and that means the NE/SE555 is celebrating it's 40th birthday!

Am I the only one that finds that amazing? 40 years in production for an IC type..

According to Wikipedia:
"As of 2003, it is estimated that 1 billion units are manufactured every year." Wow!
Sometimes technology doesn't change that much, it just gets... smaller.
Oooh look, now available in a TSSOP8 package.
http://www.st.com/stonline/products/literature/ds/4077/ts555.pdf

You're doing great Ken, and I'm looking forward to seeing photos of your car in action because I know you're going to get there. You're clearly a geek at heart with experiance behind you :cool: ...
You just need some fresher data books to work from. :)

You're doing great. Carry on.


steve

ardhuru
- 13th February 2010, 13:04
Hey, It's 2010 and that means the NE/SE555 is celebrating it's 40th birthday!



Sends you on a nostalgic trip, doesnt it?

My dad used to work in the avionics department of our national carrier, and I remember he showed it to me as an example of cutting edge technology.

Of course, I could only appreciate the significance after he showed me the equivalent transistorised module it replaced.

"What will they think of next..."

Regards,

Anand

ScaleRobotics
- 13th February 2010, 20:33
Ok, this pretty off topic, but since we are going down memory lane...

I still have my first development board, a 6950 Intercept Jr from Intersil (later bought out by Harris I think). Actually, it's not too shabby for 1976. Battery powered, 12 button input that allowed assembly programming via push buttons, 4 digit address, and 4 digit memory display. Though it is about 1 square foot in size, and the extra $145.00 for 1024 words of ram is a little steep. But I guess I was a slow learner, because the promise of "teaches you the basics of microprocessors, random access memories, read only memories, and input and output interfacing in less than 8 hours", took a little more time for me.

http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3987&stc=1&d=1266089174

Kenjones1935
- 15th February 2010, 02:32
Where do I find how to interpret the following .asm code? It is a piece of the wall_racers.asm file which was created when I compiled wall_racers.bas. If I am going to figure out exactly what my code is doing I need to be able to parse it. How do I do that?

; C:\PK2LES~1\44PIND~1\WALL_R~1.PBP 00132 if rangeright < desiredtrack and oldrangeright < rangeright then
CMPLT?WCB _rangeright, _desiredtrack, T1
CMPLT?WWB _oldrangeright, _rangeright, T2
LAND?BBW T1, T2, T2
CMPF?WL T2, L00005

I looked in all the Microchip documents I have for "CMPLT" and "WCB".
Where are these defined?

Also how, using PICkit 2 Programmer do I read contents of RAM addresses 40, 42 and 44??

Ken

mackrackit
- 15th February 2010, 04:01
Let me see wall_racers.bas and I will try to tell you what it does.

The basic code will be much easier to read.... One of the reasons basic is used???

Kenjones1935
- 15th February 2010, 05:01
My problem is that the code is not doing what I think it should be doing.

I have put LED blinkers at the beginnings of all subroutines. That way I can tell the path the code is taking. You understand, I have not been able to get MPLAB IDE to work at all. That is the tool with the debugging features. I am using PICkit 2 Programmer and my own ingenuity.

It looks like some arithmetic on the PULSIN results is not working correctly. I do not know how to read the VAR which stores the pulse size in units of 10 usec. I would like to see exactly what the PIC thinks it got, but that means reading RAM. I would like to put a break point in the code and read certain addresses at that point, but I have not been at all successful with that technique.

I planned, but did not get to it, to enter a Microchip FAQ forum to see what they all say about these two Microchip software products working together.

I'm tired. It is bed time. Thanks. Maybe things will be more clear in the morning.

Ken

ScaleRobotics
- 15th February 2010, 17:28
Let me see wall_racers.bas and I will try to tell you what it does.

The basic code will be much easier to read.... One of the reasons basic is used???
Here is the link: http://letsmakerobots.com/node/928

It's in Picaxe basic. Not sure how compatible that is... never tried any picaxe here. Picaxe appears to be built for 4mhz or 8mhz depending on the product.

Ken, beyond any possible incompatibilities with the code, are you sure you are running at the proper speed? That would throw your measurements off as well. Since PBP defaults to 4mhz, try 8mhz and see if it is any better, if not probably a code incompatibility, or a config setting that is already set to something for the Picaxe, and you need to try to duplicate.

Again, I have no experience with a picaxe, and had to do a search to find out what it was. Anyone have some Picaxe insight?

rmteo
- 15th February 2010, 17:43
See here PICAXE (http://www.rev-ed.co.uk/picaxe/)

mackrackit
- 15th February 2010, 20:55
I should have said to Ken, "Lets see your version of wall_racers, because you would have had to re-write it for PBP"

So....

Ken, post your code!!! :)

Kenjones1935
- 15th February 2010, 22:36
I need to clean it up a bit.

Yes, I did modify the original PICAXE basic to comply with our PCP rules. There were a couple of specification differences and there were a couple of typo's. My code compiles fine and runs OKAY. The flashing LED's tell me alot.

Last week I focused my attention on making the DC motor and Servo work. I am now anxiously awaiting the arrival of ten SN7407N (all for $5.00! plus shipping)

Now my focus has been on the arithmetic the code applies to echo pulse responses from the SRF05's. I am trying to reconcile what the code does with the SRF05 spec which reads:


The SRF04 provides an echo pulse proportional to distance. If the width of the pulse is measured in uS, then dividing by 58 will give you the distance in cm, or dividing by 148 will give the distance in inches. uS/58=cm or uS/148=inches.

My last post was just looking for information. Is there no way to read RAM from the PICkit? Is there no way to put a break point in the real code?

I'm going to try to better understand MPLAB IDE. It has a debugger mode.

Thanks, Ken

Thanks

Kenjones1935
- 16th February 2010, 03:46
I have been trying to activate PICkit2 Debugger per instructions in Chapter 4 of the PICkit 2 User's GUIDE DS51553E

I could not activate the project using 16F887Demo.asm per the User's Guide because my copy of that file is empty. Strange.

I could not activate the project using wall_racers.asm. Each time I hit "Build all" it considered for a few moments then in RED LETTERS said BUILD FAILED. No explanation. No comments. No helpful information.

I succeeded in activating a debug project using blink.asm from C:\PBP\PK2 Lessons\44 Pin Demo Board\02Blink.

I have not the faintest idea what I have learned with this exercise. I know from the listing file which RAM locations I wish to read. I think I could figure out where to place the break point if I could get the debugger to accept the wall_racer.asm code.

Ken

Ken

mackrackit
- 16th February 2010, 04:59
I could not activate the project using wall_racers.asm. Each time I hit "Build all" it considered for a few moments then in RED LETTERS said BUILD FAILED. No explanation. No comments. No helpful information.

Rename "wall_racers.bas" to something with 8 characters or less then start over with compiling and building.

MPLAB does not like long file names.

Try "racer.bas"

Kenjones1935
- 16th February 2010, 18:03
Thanks macracket. Shortening the name made MPLAB happier. It actually tried to build my PBP code, but was very unsuccessful. Understand this is exactly the code that can be built, downloaded and run by PICkit 2 debugger software.

MPLAB is not happy with the formate of the .asm code created by PBP. Below is a small snip of a huge list of complaints.


Error[122] C:\PK2 LESSONS\44PIN DEMO BOARD\RACERS\RACERS.ASM 235 : Illegal opcode (_blinkloop45)
Error[122] C:\PK2 LESSONS\44PIN DEMO BOARD\RACERS\RACERS.ASM 238 : Illegal opcode (_rangefront)
Error[122] C:\PK2 LESSONS\44PIN DEMO BOARD\RACERS\RACERS.ASM 241 : Illegal opcode (_blinkloop67)
Error[122] C:\PK2 LESSONS\44PIN DEMO BOARD\RACERS\RACERS.ASM 244 : Illegal opcode (_turnon)
Error[122] C:\PK2 LESSONS\44PIN DEMO BOARD\RACERS\RACERS.ASM 247 : Illegal opcode (_steerto)
Warning[207] C:\PK2 LESSONS\44PIN DEMO BOARD\RACERS\RACERS.ASM 250 : Found label after column 1. (GOTO?L)
Error[122] C:\PK2 LESSONS\44PIN DEMO BOARD\RACERS\RACERS.ASM 250 : Illegal opcode (_main)
Warning[207] C:\PK2 LESSONS\44PIN DEMO BOARD\RACERS\RACERS.ASM 253 : Found label after column 1. (LABEL?L)
Error[122] C:\PK2 LESSONS\44PIN DEMO BOARD\RACERS\RACERS.ASM 253 : Illegal opcode (L00001)

It would appear that PBP folks don't use MPLAB. True?

Ken

mackrackit
- 16th February 2010, 18:12
MPLAB is used by PBP folks often. I use it about 25% of the time. MCS about 25% and gEdit(Linux) the remainder.

Have you picked the correct PIC in MPLAB?

Post your code and I will check it out here if you want.

Kenjones1935
- 16th February 2010, 19:36
If I write in the C language provided by Microchip would the MPLAB ICD work better? I do wish I could see what is going on....

Ken

Kenjones1935
- 16th February 2010, 20:00
macracket,

Is it OKAY to post 371 lines of code on these forums? It is the copy that compiles, builds and works. However, it has comments, reminders and unnecessarys.


Maybe I should email my code to you.

Ken

mackrackit
- 16th February 2010, 20:16
Rename the file as a txt and attach it to the thread.

Byte_Butcher
- 16th February 2010, 21:29
If I write in the C language provided by Microchip would the MPLAB ICD work better? I do wish I could see what is going on....

Ken

An easy way to see "what's up" in absence of ICD is a simple 16x2 serial LCD module. Just connect it to an unused pin on your PIC and use "SEROUT" to send the values of assorted variables and stuff to right your display. Very easy, very handy...


steve

Kenjones1935
- 17th February 2010, 03:35
Here is the file that I have been compiling with MicroEngineering MicroCode Studio PICBasic Pro compiler, building with MPASM and programming with PICkit 2 successfully.

The assembly language result from this MicroCode Studio compile is not acceptable to the Microchip PICkit 2 Debug Express MPLAB IDE.

It says in RED "BUILD FAILED"

OH! I see now. It is complaining about PBPPIC14.LIB lines 607, 623, 640, 643, 649 etc.

These are all "if" statements that look like this:

7785 if ($ > 800h)
541 if ($ == (Label))
552 if (((Label) & 800h) == 0)
559 if (((Label) & 1000h) == 0)
705 if ((Label) > $)
722 if (((Label) & 1800h) == 0)
725 if (((Label) & 800h) == 0)
731 if (((Label) & 1000h) == 0)
607 if ((Label) < 1)
623 if ((Label) > $)
640 if (((Label) & 1800h) == 0)
643 if (((Label) & 800h) == 0)
649 if (((Label) & 1000h) == 0)
677 if ($ == (Label))
689 if ((Label) < 1)



Hundreds of:


Executing: "C:\Program Files\Microchip\MPASM Suite\MPASMWIN.exe" /q /p16F887 "racers.asm" /l"racers.lst" /e"racers.err" /o"racers.o" /d__DEBUG=1
Error[151] C:\PBP\PBPPIC14.LIB 7785 : Operand contains unresolvable labels or is too complex
Error[151] C:\PBP\PBPPIC14.LIB 607 : Operand contains unresolvable labels or is too complex
Error[151] C:\PBP\PBPPIC14.LIB 623 : Operand contains unresolvable labels or is too complex
Error[151] C:\PBP\PBPPIC14.LIB 640 : Operand contains unresolvable labels or is too complex
Error[151] C:\PBP\PBPPIC14.LIB 643 : Operand contains unresolvable labels or is too complex


Followed by:


Error[151] C:\PBP\PBPPIC14.LIB 559 : Operand contains unresolvable labels or is too complex
----------------------------------------------------------------------
Debug build of project `C:\Pk2 Lessons\44Pin Demo Board\racers\racers.mcp' failed.
Language tool versions: MPASMWIN.exe v5.35, mplink.exe v4.35
Preprocessor symbol `__DEBUG' is defined.
Tue Feb 16 20:56:41 2010
----------------------------------------------------------------------
BUILD FAILED


It appears that all I need to do is to figure out why this .lib file is incompatible with MPLAB IDE....

Hmmmm....

Ken

Kenjones1935
- 17th February 2010, 03:55
All I have to do is replace all the instances of '(Label)' with 'Label' in PBPPIC14.LIB

But how did it get that way in the first place?

Ken

mackrackit
- 17th February 2010, 04:00
I changed this line


loop while rangefront > frontfreetostopreverse and rangeright > outertrack and b0 < 20

TO


while rangefront > frontfreetostopreverse and rangeright > outertrack and b0 < 20
WEND
Because I am still using PBP 2.50

I compiled in MCS then created a project in MPLAB using the ASM from MCS work as the source.

No problems here.
http://www.picbasic.co.uk/forum/attachment.php?attachmentid=4000&stc=1&d=1266375307

Just wondering if you are selecting the correct PIC???

http://www.picbasic.co.uk/forum/attachment.php?attachmentid=4001&stc=1&d=1266375307

mackrackit
- 17th February 2010, 04:04
All I have to do is replace all the instances of '(Label)' with 'Label' in PBPPIC14.LIB

But how did it get that way in the first place?

Ken

'(Label)'
Is correct !!!

Kenjones1935
- 17th February 2010, 18:36
macracket:

I changed the do loop to a WHILE WEND loop. It compiled fine, but still would not assemble in the MPLAB Debugger. Same problem with the PICPBP14.LIB "if" statements. How can the .LIB files be at fault? Very strange. Sounds like some kind of compatibility problem.

Attached is my Device Select 16F887 Window. It looks a little more flexible than yours, but basically the same

http://www.picbasic.co.uk/forum/attachment.php?attachmentid=4003&stc=1&d=1266426473

Dennis
- 18th February 2010, 02:35
Hi all

Thought this might be of some interest, the code is in C and there is no schematic , was just thing of 4 well synchronized hard drive spindle motors a an RC chasis , would be quite a fast car.

Seems like a nice project though!
http://bradthx.blogspot.com/2010/02/fun-with-hard-drive-spindle-motors.html

Kind regards
Dennis

mackrackit
- 18th February 2010, 04:57
Ken,

Just to be sure we are all doing the same thing...

1-- Write and compile the code using MCS.
2-- Generating the ASM file with MCS set for MPASAM use.
3-- Open a project in MPLAB.
4-- Use the ASM file generated by MCS as the source for the MPLAB project.
5-- Everything is in the same project directory.

Kenjones1935
- 19th February 2010, 03:07
1-- Write and compile the code using MCS.
Compile PIC BASIC PRO code using
MicroCode Studio version 3.0.0.5
PICBASICPRO 2.6.0

2-- Generating the ASM file with MCS set for MPASAM use
Using MPASM per the following picture:

http://www.picbasic.co.uk/forum/attachment.php?attachmentid=4017&stc=1&d=1266545112
3-- Open a project in MPLAB.

Open the project in MPLAB IDE 8.43.00.00
MPDebugger 3.10

4-- Use the ASM file generated by MCS as the source for the MPLAB project.
5-- Everything is in the same project directory.

mackrackit
- 19th February 2010, 06:46
Looks like the only difference is you are using the latest software, I am still using PBP2.50 and MPLAB v8.00.

So I am at a loss now.

Kenjones1935
- 20th February 2010, 04:32
Progress has been slow. It will be more fun when the SN7407's show up and I can make the car move.

Ken

Kenjones1935
- 23rd February 2010, 04:10
It's been more than a week. They were supposed to have been shipped via USPS. The vendor is not answering its email. Does not look good.

Meanwhile I might as well get back to the REAL project. I have not decided on the least intrusive means to generate PWM. Using the toy level car all I have is bang/bang control. Full speed forward, full speed backward, stopped. Full turn left, Full turn right, straight ahead.

With PWM control I have CONTROL. Thing is, I do not know whether I really need this complication. Probably not. But I do need for the microprocessor to be doing things while the car is moving. PAUSE does not cut it.

Gotta put back on my thinking cap.

Ken

ScaleRobotics
- 23rd February 2010, 04:25
Hey Ken,

Don't know if you saw it, but some progress was made on the 12F683. It is decoding 5 channels, and encoding 4 channels. You could modify the servo output as you like in the main section, using PBP. The DT interrupts are done in assembly. (No pauses) All you would need is a $2.00 12f683, a capacitor, 3 diodes, and a breadboard.

http://www.picbasic.co.uk/forum/showthread.php?t=12657

Kenjones1935
- 23rd February 2010, 04:49
The wall racer code contains subroutines that do all the bang/bang controls by switching DC current through relay DPDT switches

The 16F887 has CCP1 and CCP2 each of which can be controlled by the HPWM Pic Basic Command. I could replace the six subroutines above with six that use HPWM. They would use these two outputs with three pulse widths each.

If I were to add a parameter to each GOSUB command thereby giving more nuance to the pulse width I could command in between wheel speed and steering angle.

Sounds like a piece of cake. What do you think?

Ken

ScaleRobotics
- 23rd February 2010, 07:33
The 16F887 has CCP1 and CCP2 each of which can be controlled by the HPWM Pic Basic Command. I could replace the six subroutines above with six that use HPWM. They would use these two outputs with three pulse widths each.

Hey Ken, I don't think I understand where you are heading. If you are talking about generating pulses for the servo's using HPWM, the low side for HPWM is 1.2 khz. Too fast for servos.

rmteo
- 23rd February 2010, 16:17
Using a single CCPx module in Compare mode, trigger special event (CCP2M<3:0> = 1011), you can do 8 servo outputs within a 20mS frame (50Hz) and 1uS resolution with a 4MHz clock.

Kenjones1935
- 23rd February 2010, 21:04
My original project uses a hobby level RC car. It has an electronic speed control which directs the DC power into the wheels. This ESC expects a pulse width modulated signal from the RC receiver. Last month I wrote very simple code using HPWM commands running in my 16F887 that made the wheels go forward, backward, stop and controlled the steering . With a little playing I got various speeds and less than full stop steering.

I jumped over to the wall-racer to get a feel for coding in BASIC on my PICkit 2. I stopped because the power requirements of the relay driven DPDT current switches exceed the capabilities of the microprocessor. I ordered some SN7407's. They never arrived. (I am in the process of complaining to EBAY.)

The only reason I need the DPDT switching for the hobby level car is to toggle from RC control to autonomous control. I have decided to start off by making wall-racer run on the hobby level car. Once that is going, I will implement the switch over.

Ken

Kenjones1935
- 25th February 2010, 20:09
My long awaited SN7407N's arrived today by priority USPS First Class mail.

I thought the package was empty. I could not feel the DIPS.

They are D package. I did not know this size dip existed. I can barely see the individual pins. They do not fit into any of my .100" grid prototype boards.

I think I need to specify J or N. Is there a difference from the prototyping point of view?

Ken

rmteo
- 25th February 2010, 20:21
This will tell you SN7407 (http://focus.ti.com/lit/ds/symlink/sn7407.pdf)

Byte_Butcher
- 26th February 2010, 02:57
Yep, the "D" package is SOIC (Small Outline Package)

You would want the "N" package for DIP. According to the TI data sheet, the "J" package is obsolete.

Don't feel bad, You ain't the first one to order parts in the "wrong" package.
I've got a few 16F727's sitting here that I meant to order in a nice compact 44-tqfp package and instead I ended up with these HUGE 40 pin DIP's. Cripes, they're bigger than the whole circuit board they're supposed to go on!



steve

Kenjones1935
- 26th February 2010, 16:26
The hobby car using HPWM seems to behave correctly.

I need to calibrate the wheel torques associated with the various PWM pulse sizes. The steering servo seems slow. I know it can work well because it did so with the radio receiver in charge.

My proto is too fragile to run the car on the floor. I have it up on a stand making the wheels free. It runs on its own 7.2V battery unattached to the USB port. I can make it think there are walls near by using an oak cutting board to fool the proximity detectors.

Once this thing makes sense I will post a video.

Ken

Kenjones1935
- 28th February 2010, 02:21
:mad:

Suddenly and without warning my PICkit2 programmer is not doing its job. See this picture. Any ideas? I can get rid of the Code Protect by erasing. Then it comes back. The memory error just starts happening...

http://www.picbasic.co.uk/forum/attachment.php?attachmentid=4048&stc=1&d=1267319862

NUTS! Or am I repeating myself.

Ken

mackrackit
- 28th February 2010, 03:49
Maybe it got turned on here?
http://www.picbasic.co.uk/forum/attachment.php?attachmentid=4049&stc=1&d=1267325270

Kenjones1935
- 1st March 2010, 22:13
Ladies and Gentlemen:

My project and I have a problem. PULSIN is putting zero into its target register even though my PICkit 2 LOGIC TOOL sees a reasonable pulse. See picture, below.

It is happening on the inputs from both SRF05 proximity detectors. My code, below, looks for zero and blinks some LED's if it sees a zero. They blink on the very first proximity tests.

Any suggestions? Is my code incorrect? Are there vulnerabilities or idiosyncrasies of which I should be aware?


symbol trigright = PORTB.0 ' Define output pin for Trigger pulse
symbol trigfront = PORTB.1 ' Define output pin for Trigger pulse

symbol echoright = PORTB.2 ' Define input pin for Echo pulse
symbol echofront = PORTB.3 ' Define input pin for Echo pulse

puls:
GOSUB blinkloop0
DEFINE PULSIN_MAX 65535
pulsout trigright,2 ' produce 20uS trigger pulse (must be minimum of 10uS)
pulsin echoright,1,rangeright ' measures the range in 10uS steps

pulsf:

pulsout trigfront,2 ' produce 20uS trigger pulse (must be minimum of 10uS)
pulsin echofront,1,rangefront ' measures the range in 10uS steps
pause 10 ' recharge period after ranging completes

'*****test for zeros******
IF rangeright = 0 then
gosub blinkloop45
endif
if rangefront = 0 then
gosub blinkloop67
endif
return

http://www.picbasic.co.uk/forum/attachment.php?attachmentid=4051&stc=1&d=1267477139

mackrackit
- 1st March 2010, 22:54
What I see of your code and your description I will guess the code never loops back for a second check.

Kenjones1935
- 1st March 2010, 23:36
That was just a segment of the whole wall racer code.

Here is a short piece written to test the hypothesis that the registers never get set. The blinkloop subroutines are simple blink ten times loops. And, yes, the blinker blink to their little hearts delight.

[QUOTE:]
symbol trigright = PORTB.0 ' Define output pin for Trigger pulse
symbol trigfront = PORTB.1 ' Define output pin for Trigger pulse

symbol echoright = PORTB.2 ' Define input pin for Echo pulse
symbol echofront = PORTB.3 ' Define input pin for Echo pulse

rangeright var word
rangefront var word
CNT VAR BYTE

main:
GOSUB blinkloop01
DEFINE PULSIN_MAX 65535
pulsout trigright,2
pulsin echoright,1,rangeright

pulsout trigfront,2
pulsin echofront,1,rangefront
pause 10 ' recharge period after ranging completes

'*****test for zeros******
IF rangeright = 0 then
gosub blinkloop45
endif
if rangefront = 0 then
gosub blinkloop67
endif
goto main: [QUOTE:]

Kenjones1935
- 2nd March 2010, 02:40
I wrote a snippet of code that:

1. set the 'range' registers, rangeright and rangefront, each to 1
2. gosub blinkloop01 if the 'range' registers are both 1
3. do the pulsout, pulsin exercise
4. gosub blinkloop45 and blinkloop67 if the range registers are 0

I ran the code. The LED's told me that pulsin is loading the range registers with 0. Why??

---------start code-----------
symbol trigright = PORTB.0 ' Define output pin for Trigger pulse
symbol trigfront = PORTB.1 ' Define output pin for Trigger pulse

symbol echoright = PORTB.2 ' Define input pin for Echo pulse
symbol echofront = PORTB.3 ' Define input pin for Echo pulse

rangeright var word
rangefront var word
rangeright = 1
rangefront = 1

if rangeright = 1 and rangefront = 1 then
gosub blinkloop01
endif

main:

DEFINE PULSIN_MAX 65535
pulsout trigright,2
pulsin echoright,1,rangeright

pulsout trigfront,2
pulsin echofront,1,rangefront
pause 10 ' recharge period after ranging completes

'*****test for zeros******
IF rangeright = 0 then
gosub blinkloop45
endif
if rangefront = 0 then
gosub blinkloop67
endif
goto main:

------------end code----------

Kenjones1935
- 2nd March 2010, 02:59
Maybe a PICBASIC robotics forum would know what is wrong with my PULSIN. They are always dealing with sensors.

Suggestions?

Ken

Kenjones1935
- 2nd March 2010, 04:00
Channel 2 is PULSOUT.
Channel 3 is the corresponding PULSIN.

PULSOUT is waaayyy to long. It is supposed to be 20 microseconds since I am using the 4meg oscillator and my command is

PULSOUT trigfront 2

PULSOUT is about 14 millisec according to the LOGIC TOOL. See picture. Oops. The forum won't honor my request to upload the picture. You'll have to take my word for it.

Any ideas?

Kenjones1935
- 2nd March 2010, 05:13
I chose, by flipping a coin, to have my PULSIN inputs on pins PORTB.2 and PORTB.3.

Is it possible that these pins can not accept pulses for width measurement? I read a two year old posting that seemed to say by changing his PULSIN pins from PORTA to PORTC everything suddenly worked. He was having the same problem as I. The pulse is on the pin, but the PIC does not act upon it.

KEn

Archangel
- 2nd March 2010, 05:29
Hi Ken, Are you still using 16F887. If so PortB is lousy with analog functions, just waiting to be disabled.

Kenjones1935
- 2nd March 2010, 15:18
Joe,

Are you saying that all I need to do to use PORTB is figure out how to appropriately configure it?

If so, please give me a hint? I am soooo close.

Ken

Archangel
- 2nd March 2010, 16:24
Joe,

Are you saying that all I need to do to use PORTB is figure out how to appropriately configure it?

If so, please give me a hint? I am soooo close.

Ken
Ken,
I am not an expert on pulseout or pulsein, and I have not read the manual lately, but I believe they are digital commands, which by default should require you to disable the analog functions on the pin you are using.
On this chip you have,
ADCON0
ADCON1
ANSEL
ANSELH
CMCON0
CCP1CON
CCP2CON
CM1CON0
CM2CON0
CM2CON1 and a couple more which all have effect on the I/O. Get into the data sheet and read about them, they are all listed in the index of the data sheet, and see how to set them up. Remember if a bit is SET it is a 1 if cleared it is a 0.
When you come out of the data sheet you will be a much more "Savy" programmer.

Kenjones1935
- 3rd March 2010, 03:30
My problem was that the length of the PULSOUT pulse was way toooo long. This was true even if I did a PULSOUT trigfront, 1.

So I changed it to:


HIGH trigfront
PAUSE 1
LOW trigfront.

It seems to respond correctly on its blocks with me moving a oak cutting board in front and on the right side to simulate inside a room with no furniture.

The battery needs charging and I need to neaten up the bundle of wires. I feel a video might not be long in coming.

Thanks, gang. Whomever you are.

Ken

Kenjones1935
- 4th March 2010, 03:46
I've got the car driving around using HPWM to control the electronic speed control and the steering servo. This is a high quality hobby level car. It seems to not react quickly enough to the PIC commands. It was designed to have a person at the radio transmitter controlling with finger and wrist movements while watching how the car performs. This is a beautiful mechanism when human judgment is included.

A toy level car runs the wheels with direct current. The steering is a bang bang servo with a mechanical mechanism forcing it straight. Fritzl used a toy level car in his wall racer. http://letsmakerobots.com/node/696

I have added 'kickers' to the steering commands. Realizing that steering straight is the servo's action when given no current, I figured that transitioning from hard left or hard right to straight might be faster if the go straight HPWM command were preceded by a momentary hard shot to the opposite extreme. My first experiment did little to improve response.

Of course it might be that my car needs a grease job.

Hmmm....

Ken

mackrackit
- 4th March 2010, 04:15
COOL!!! It works!!!
Videos???

Of course it might be that my car needs a grease job.
Or may the code is rusty? :)

Are you using interrupts or just running straight?
The PIC should be able to react faster than humans.

Kenjones1935
- 4th March 2010, 04:27
It is not that he PIC is slow, I think it is that the steering mechanism is too complex. It is a close match for what is in a real automobile. I need to get the car to go slower if it is going to drive along a wall no more than 15 inches away.

My code also needs some serious tweeking.

Ken

Kenjones1935
- 4th March 2010, 05:00
When up on blocks and I am fooling the sonar with my hands. (Remember it is supposed to hug the walls and thereby go around a room counter clockwise looking down.)

It:
1. goes straight when my hand is about 10 inches away on the car's right side and nothing is in front.
2. turns right when my hand is more than 10 inches away on the right
3. turns left when my hand is 15 to 20 inches away up front
4. goes backward when my hand is much closer up front. Once it has retreated 15 to 20 inches it turns left and tries again.

When on the floor the car is too fast for the PIC driven steering mechanism. It bumps into things, retreats, turns, and comes flying forward. It is too fast for me.

It is behaving similarly to those floor vacuuming robots only way too fast. I have the electronic speed control at its slowest PWM settings.

Needless to say, manipulating a video camera while waving my hand at this machine ain't easy.

Ken

malc-c
- 4th March 2010, 08:17
Ken,

Either the car needs to travel slower, or you need to increase the range / sensitivity of the sensors, or possibly use different servos which can react quicker (digital ?)

Kenjones1935
- 5th March 2010, 02:47
Took the car to the local radio control hobby shop. They played with the steering mechanism and told me that it was "all bound up". The ball joints had ceased within their plastic housing. (I got the car as a freebe.) The solution was new tie rods. (Fashioned out of two bits of plastic, tiny metal ball joints and #4-40 screws with their heads cut off. It took the guy behind the counter no more than five minutes.)

Now the thing steers like mad. Gotta calm it down a bit.

Ken

mackrackit
- 5th March 2010, 04:15
Ken,

You are doing one heck of a job. Four months from your first post here, give or take a day or two, with an idea and a new language.

Now you have a working project ready for fine tuning.

Nice Job!!!

Kenjones1935
- 7th March 2010, 02:45
I took the car to R/C Excitement yesterday and gave it a try. It worked quite well. It followed the wall then negotiated the left turns to go completely around the room. It was fast. I had to run to keep up. The wall following was too zigzag. Classic case of over compensation.

Took it to R/C again today. It did not work at all well. I screwed something up!!

Question: What makes the 16F887 reset or restart. I know a power glitch will do it, but I don't see how that can be. Possibly an inductive surge from telling the motor to reverse itself without first telling it to stop. That might do it. I am changing my code so that can not happen. What else? Anything?

Another question. Have any of you seen a PBP command snippet that interprets an incoming PWM signal and puts it into a register so that I can do IF statements like, "IF signal < 110 THEN ....." There's some code in the Q&A article in this month's SERVO magazine that seems to do that, but not in PBP.

Ken

ScaleRobotics
- 7th March 2010, 04:15
Another question. Have any of you seen a PBP command snippet that interprets an incoming PWM signal and puts it into a register so that I can do IF statements like, "IF signal < 110 THEN ....." There's some code in the Q&A article in this month's SERVO magazine that seems to do that, but not in PBP.

Ken
If it is just the pulse measurement that you need, a simple:
(w = pulse width)
PULSIN PWInputPin, 1, w
will get you there. But you must call this quite regulary if you need updated values.

Edit: Below is not really a PBP command snippet, but it does what you are asking:

I know it is different hardware than you were planning. But with $2.50 you could buy a board from Radio Shack, and a $2.00 12f683, you could solder your own hardware together. The only variables you would need to pay attention to is the Main. You can read and do your math to RC1, RC2, RC3, RC4, and read only for RC5.

http://www.scalerobotics.com/PWMpassthrough.html

Kenjones1935
- 7th March 2010, 04:40
I was not thinking. I am already using PULSIN to measure the echo from the sonar pinging. My code goes round and round. All I want is the signal from channel 3 on the RC receiver that toggles from RC control to PIC control and visa versa.

ken

Byte_Butcher
- 7th March 2010, 05:21
Hey Ken,
It sounds like the car moves pretty fast!
I'm not really familiar with RC car drive mechanisms. Is the motor connected to the wheels directly, or with belts or gears.. or?
Is there a way to change the gearing to make the top speed more manageable for your purpose? Or maybe run the motor on a lower voltage to mellow it out a bit and slow things down?

As far as the PIC resetting, it would be helpful to see a schematic of your circuitry. Got voltage regulators for your PIC?

You should probably have a fairly large electrolytic capacitor (maybe a few hundred to a couple thousand uF) in parallel with one or more ceramic caps of .001 to .1 uF placed fairly close to your PIC as well as on the input side of your regulator if you've got a motor running on the same battery as your PIC.

And probably a .001uF cap across right across the motor terminals would be beneficial as well?
DC motors can generate a lot of noise and trash as well as draw large current surges that can drop the battery voltage below "acceptable" levels.

Got a schematic of your PIC and motor drive circuitry to refresh our memory?


Sound like you're making good progress!


steve

tenaja
- 7th March 2010, 06:46
Another reset culprit is stack overflow. If you have too many nested gosubs, or gosubs without returns, the PIC will reset.

Kenjones1935
- 8th March 2010, 03:11
Today I took the proto to Main Street. We have a park that is surrounded by an old (Victorian?) cast iron fence seated in a straight curb that runs next to the sidewalk. A perfect spot to test Proto's ability to follow a wall.

It did very well. In that environment I could run and keep up:D

So, feeling confident, I took it to a store front that had inset entrance doors. It could follow the in going wall below the plate glass then turn left when it got to the doors themselves.

WRONG! It did not turn at all. It crashed straight into the right hand glass door.

Then it stopped working correctly. It behaved very strangely. NUTS. :confused:

Seven hours later I realized the impact had moved the forward looking proximity sensor. It was now reacting to that thing-a-ma-gig to which the 'C' clip is attached for holding on the plastic car body.

I had not calibrated the numeric proximity sensor responses relative to the speed of the car. I have now more than doubled the "WATCHOUT" threshold for the front facing sensor.

Technical question. How many nested subroutines brings down the code. Any idea?

Ken

Kenjones1935
- 9th March 2010, 05:12
I have forgotten most everything I ever knew about v=iR.

Is there any reason that you all can recall why I should not just put the a digital 16F887 output pin directly into one of the input lines of the SN7407N?

Ken

Kenjones1935
- 9th March 2010, 15:25
How does HPWM work when the pulses are set for 50 per second (20msec) period and the code loops more quickly than that. ie the next HPWM command happens before the last one got a chance to count out the 20 msec.

Is it obvious if I study the ASM code? I wish I could find a compact library so I could read ASM easily.

Ken

mackrackit
- 9th March 2010, 15:54
The hardware parts of the PIC run independant of the code.
That is one of the reasons we use interrupts. Gives the code a chance to see what the hardware is doing.

I do not think reading ASM will help much. The chip does not really care about the language.

ScaleRobotics
- 10th March 2010, 05:48
How does HPWM work when the pulses are set for 50 per second (20msec) period and the code loops more quickly than that. ie the next HPWM command happens before the last one got a chance to count out the 20 msec.

Is it obvious if I study the ASM code? I wish I could find a compact library so I could read ASM easily.

Ken

I don't know if I understand the question. To set HPWM at 20ms, you need to slow your pic down to 0.5 Mhz (if you are using the hardware PWM). But then you only get about 32 different settings from 1ms to 2ms. Maybe you are asking what happens to the servo when you send the 1.5ms pulses quicker than 50 hertz?

How are you doing it Ken?

Kenjones1935
- 11th March 2010, 05:01
When I toggle from radio control to PIC control I would like the car not to go through a sudden change of commands. I would like the PIC to know what the RC receiver had just told the electronic speed control and the steering servo so that at the instant of toggle it can duplicate these commands.

Hopefully a solution is while in RC mode to loop two PULSIN commands looking at the signals the radio receiver is sending to the ESP and the servo. The technical question I have is, "How do I process the input from a PULSIN to create a HPWM that is equivalent?"

The PBP textbook description is not clear to me.

Ken

Kenjones1935
- 11th March 2010, 05:07
The question I was trying to ask was this.

All my code is a continuous loop. The PIC is way fast compared to the fifty pulses per second which is the specification for the radio control car PWM.

I am doing many HPWM commands within a fiftieth of a second. What does that look like on the output pin? Actually now that i have an oscilloscope I can find out for myself.

Ken

ScaleRobotics
- 11th March 2010, 05:26
The question I was trying to ask was this.

All my code is a continuous loop. The PIC is way fast compared to the fifty pulses per second which is the specification for the radio control car PWM.

I am doing many HPWM commands within a fiftieth of a second. What does that look like on the output pin? Actually now that i have an oscilloscope I can find out for myself.

Ken

Hey Ken,

We would not know what it looks like, because we have not seen any code. We really do not know any details, HPWM settings, or oscillator settings even. But you do seem like you are getting along pretty well. This might help us answer your previous question too! I would be curious to see your oscilloscope measurements as well. The only way I know to use HPWM for the 20ms period HPWM, is to slow the oscillator down to 0.5 mhz . And the resolution kind of stinks using that method.

But I have a feeling you are using an "unkenventional" method, which is cool. Just would like to hear some details of what it is.

Thanks,

Walter

Kenjones1935
- 12th March 2010, 04:11
OKAY,

With the help of the new-to-me oscilloscope I saw what I had been suspecting. The PIC's HPWM signal is not structured like the RC receiver signal. This explains why the PIC has not been able to command a smooth gradation of steering servo positions or wheel driving torque.

The RC receiver produces a pulse every 20 milliseconds (50 Hz). The pulses are between 1 and 2 milliseconds long. The PIC's HPWM machine produces a pulse every 3.8 milliseconds (263 Hz). The pulses are between 1 and 2 milliseconds long.

This matches scalerobotics comment of yesterday. It also matches the PBP textbook. Now that I understand what it is saying.

What I have does give me steering and wheel drive control. It is more bang/bang than I would like. It goes FAST. Which leads me to the problem of getting the car to steer left soon enough when approaching a corner in the wall.

The RC versus PIC control toggle works. Under RC control the car reacts like the original system. RC channel 3 provides the toggle signal. The PULSIN command does a fine job differentiating short from long PWM on this incoming signal. The code then controls the AZ8222 Subminiature DIP DPDT Relay via the SN7407N DIP MOS driver. This DPDT switch selects either the PIC output or the RC receiver output to send to the electronic speed control and the steering servo.

I'll make a video when I get the kinks out. I am afraid my prototyping technique is not robust enough to withstand the bumps needed to straighten out the feed back loops.

Thanks again for your help and encouragement. :)

Ken

Kenjones1935
- 13th March 2010, 02:08
Here is a video of my RC car taken today at our Radio Control Hobby Shop's race track.

http://www.youtube.com/watch?v=seDKRDUdehE

Why does my code take so long to see and react to the information from the proximity sensors? :confused:There are no long PAUSE statements in my code. I am using HPWM to create the PWM control signals. Maybe I should take all the comments out of my code and post it for your consideration.

Ken

Kenjones1935
- 13th March 2010, 02:32
Here is my code as seen by WINDOWS notepad application. It does not make the PBP commands into capitals.

Were is the big delay?

Ken

mackrackit
- 13th March 2010, 02:57
WOW!!! That is cool!!! Very nice job so far.

After a quick look at the code I see a lot of things going on between range checks.
Just wondering what would happen it you setup a timer to trigger an interrupt routine.
The interrupt routine would be the range check. That way the range would be know almost instantly for corrections.

Or add range checking in between the IF/ENDIF statements. Places like this


aftermain:
gosub skidandreverse
frontfreetostopreverse = frontfreetostopreversesetup


if rangefront < frontfree then 'turn left as there is something ahead in front

gosub SteerFullLeft

goto main
endif



IF rangeright = 0 then
endif

if rangeright > outertrack then 'turn right as we are too far away
gosub SteerHalfRight
endif


if rangeright < desiredtrack and oldrangeright < rangeright then
gosub SteerStraight
endif



if rangeright > desiredtrack and oldrangeright > rangeright then
gosub SteerStraight
endif

Kenjones1935
- 13th March 2010, 03:17
I thought that a PIC runs at micro second speed. I thought that a loop clean through all my code would be indistinguishable by my human eyes.
The SRF05 have little red lights that flash each time they are pulsed. While the PIC is running the little flashes come about one per second.

How can that be? What is consuming the time?

Where can I get some information about the relation between PBP commands and real 16RF887 machine language code?

Ken

mackrackit
- 13th March 2010, 04:29
I am not good at figuring execution times but there is a thread around here some place talking about it... i can not find it :(

I do see a 200 pause, add that to the IF/THENs...

On the bench just to see you could remove some of the code and see it the LEDs blink faster. A primitive way yes. All I can say at the moment.

Byte_Butcher
- 13th March 2010, 06:24
What about PULSIN?

It has 16 bit resolution and at 4MHz, the PULSIN resolution is 10uS.
If you DON'T receive a pulse doesn't the PIC wait for 65535 x 10uS (0.655 seconds) before it "moves along" to something else?
Perhaps you need a define to determine the max PULSIN time?

IE:
PULSIN_MAX 1000 'Maximum counts allowed before pulsin times out


Just a thought.


steve

Ioannis
- 13th March 2010, 16:34
Is it possible to place the car on a stand and the camra above it. Then have an object approaching form the side and back again so we could see the reaction of your sytem.

Then I would suggest the ue of he PID routines of Henrik that are on this link to obtain smooth control: http://www.picbasic.co.uk/forum/showthread.php?t=5874

Ioannis

Kenjones1935
- 13th March 2010, 16:44
Inline code is probably faster than subroutine based code. I commented out all the HPWM subroutines and substituted in place of their calls the HPWM statements themselves.

My guess is that the SRF05's are blinking faster. That is very good.

I checked the SRF05 responses. They seem to be immediately after the one millisecond trigger pulse. PULSIN should not be timing out, but that is a vulnerability worth considering.

Ken

Kenjones1935
- 13th March 2010, 16:58
I did a DEFINE PULSIN_MAX 1000 and the car is falling into my 'failed' because 'rangefront' or 'rangeright' equals zero. Interesting!! Something there is not consistent.

Byte_Butcher
- 13th March 2010, 17:09
You'll probably need a longer timeout than 1000.
That would only be 10mS that it waits.
Maybe try 10000?

Fool around with it a bit. It needs to be long enough to see the whole pulse, but short enough that it doesn't waste excessive time waiting.


steve

Kenjones1935
- 13th March 2010, 17:12
When running independently off the 7.2v voltage regulated battery the SRF05's seem more consistent with their responses than when running off the PIKkit2 USB provided 5volt supply. Interesting if true.

Thanks again, all...

Ken

Kenjones1935
- 13th March 2010, 23:29
Added complexities. Classic amateur robot stuff I would guess.

1. The sonar proximity detectors have a fairly wide field of "vision". If the car bumps against the side wall at a sharpish angle, the front detectors see the wall. The program thinks the car has come to a corner in the room and makes a maximum sharp left turn. This sets the car up for a very zigzag pattern.

I tried making a "megaphone" for the front sonar pingers out of the cardboard tube on a toilet paper roll. The sonar "detected" the tube. Hmmmm

2. When the battery begins to fade the car has a difficult time moving from a dead stop. Given a nudge, it takes off. The net behavior becomes quite different. Discombobulating to say the least.

3. The wheels and the steering servo still appear to be reacting too slowly. Exactly what is the problem is not clear.

That is the report for today...

Ken

Kenjones1935
- 14th March 2010, 17:25
I am thinking that I need to better understand 16F887 machine language to make real progress. Certainly if I were to code in Assembly I would have a better feel for which macros take more time than others. I have not paid any attention to this until now.

This morning I looked at the ASM command list. I noticed that ASM has both a CALL and a RETURN command. This makes PBP's GOSUB and RETURN inexpensive I would think. Getting rid of subroutines will not improve speed.

I also note that PBP's IF, THEN, ELSE, ENDIF do not match straight into ASM code. Maybe I should write these case specific in ASM instead of PBP.

Somehow I have to speed up my processing loop.

Any suggestions?

Ken

ardhuru
- 14th March 2010, 17:37
I am thinking that I need to better understand 16F887 machine language to make real progress.

This might help:

http://www.mikroe.com/en/books/picmcubook/

Regards,

Anand

ScaleRobotics
- 14th March 2010, 18:15
I am thinking that I need to better understand 16F887 machine language to make real progress. Certainly if I were to code in Assembly I would have a better feel for which macros take more time than others. I have not paid any attention to this until now.

This morning I looked at the ASM command list. I noticed that ASM has both a CALL and a RETURN command. This makes PBP's GOSUB and RETURN inexpensive I would think. Getting rid of subroutines will not improve speed.

I also note that PBP's IF, THEN, ELSE, ENDIF do not match straight into ASM code. Maybe I should write these case specific in ASM instead of PBP.

Somehow I have to speed up my processing loop.

Any suggestions?

Ken

Hello Ken,

I don't think your gosub's, or commands are taking too long, although it is possible they are too many nested. The PIC is a very fast piece of hardware, and nothing you have should take it a second to complete. After all, at 4 mhz, it can do one million instructions per second. Your pause 200 takes the most time here (the equivalent of about 200,000 lines of assembly code). I do not think you need to write this in assembly. You just need to find a bug that seems to be monopolizing your 16f887, or minimizing your sonar pings.

Can you write some simple code to make your sonar sense at more than 1 pulse per second? That would be my first test. You could also blink an led as your code passes different spots, to see if you get caught in any loops.

I would change most of your gosubs to just include the HPWM command to make for easier reading. That would make it cleaner, and easier to spot a problem. Any chance you could post the whole code, with the variables, and the config settings?

By the way, nice job! It is really progressing nicely.

Walter

Edit:

I don't think this will help anything, but how about changing all your HPWM's to HPWM x,x,245 since that is the minimum for 4 mhz? Maybe it is just defaulting to that anyway, but it is outside the range given in the manual.

Byte_Butcher
- 14th March 2010, 18:22
Somehow I have to speed up my processing loop.

Any suggestions?


What oscillator speed are you running?
8MHz on internal osc?

I believe the 16F887 will run up to 20MHz with external crystal.
That would speed things up a bunch.


steve

ScaleRobotics
- 14th March 2010, 18:46
Another thing you could do, is ICD compile it in micro code studio (for something like a PIC16f876a) and run it to see where it is getting stuck. Of course, you would need a serial port, and a PIC16f876a laying around to test it that way.

It would show you step by step, or animated, something like this:
http://www.picbasic.co.uk/forum/attachment.php?attachmentid=4092

Walter

Kenjones1935
- 14th March 2010, 23:28
You all suspected my usage of PULSIN.:rolleyes:

You were correct.:D

To determine whether to take control itself or let the radio receiver do its thing, my PIC must read the PWM code from the radio receiver channel 3. That PWM comes in only fifty times per second.

I was asking PULSIN to measure that pulse without setting an interrupt for when it sees a rising edge. What are the chances of my PULSIN moment (plus delay waiting according to pulsin_max) seeing something happening only 50 times per second. Answer, not good.

What are the chances of my PIC seeing that pulse when the radio transmitter is not powered? None whatsoever!

So: When testing my car up on blocks in my "lab" and not remembering to turn on my radio transmitter the poor thing spends 99% its time waiting for a pulse that never arrives.

Yep. Turn on the transmitter (even with channel 3 in the autonomous control position) and my SRF05 blinkers flash like crazy. They are being continuously triggered.

I still have a problem with response time, but it is not because the PIC is lacking sensor information.

Ken

Kenjones1935
- 15th March 2010, 03:16
I don't think I have changed anything other than remove confusing comments.

Ken

Kenjones1935
- 16th March 2010, 01:30
Part of the reason my car keeps hitting the wall is that it is responding too slowly for the speed it is traveling.

Today I carefully calibrated my HPWM 2,xxx,50 commands.

If xxx = 110 the car does not move.
If xxx = 111 the car moves forward, but only on a non-carpeted floor.
If xxx = 112 the car moves forward forcefully but not too fast

xxx = 115 is too fast for my code.
xxx = 125 is full speed which is very fast.

Ken

Kenjones1935
- 17th March 2010, 02:27
Here's a video of our car running a hall in our house.

http://video.yahoo.com/watch/7164676/18657928:D

I moved the front sonic sensors closer to the front of the car and I figured out how to slow down the wheels a bit.

Next thing, I think, is to build a better looking and stronger prototype using a car with more room to attach stuff. What other kinds of sensors should I try and what other kinds of tasks will they help the PIC do?

Again, thank you for all your interest and help.

Ken

mackrackit
- 17th March 2010, 03:54
Looking good Ken!

Other sensors...
IR - Probably not do much better than the sonic, but they can be setup to "see" light and dark colors. Line follower. Maybe see the white wall...

Hall-effect - Have the car find and park or something on a metal plate, magnetic.

Solar cell or photo diode - Light seeking. You mentioned this at the beginning.

RFID - Place RFID tags along a path and have the car follow. (never done that myself)

Ioannis
- 17th March 2010, 09:07
Consider using PID control for your motors. This way your car will be less nervous in is reactions. Look for the routines by Henrik Olson at http://www.picbasic.co.uk/forum/showthread.php?t=5874

Ioannis

Kenjones1935
- 18th March 2010, 03:07
There is a large world wide subculture of robotics. Does it have a common higher level language? Are there some PIC's obviously better suited for certain kinds of sense and control tasks than others? Where can I read about such things? (I get SERVO magazine. I shall look more carefully for leads there. But where on the WEB?)

Ken

Ioannis
- 18th March 2010, 11:10
Maybe C is what you mean?

I think it's all in the software. Meaning the programmer.

Sure a dsPIC may do better in signal processing or faster, but requires that the programmer can code in C or assembly.

But generally speaking all micros can do more or less all sort of things.

Did you look at the link I posted? I think isthe key to your nervou problems. PID does just that.

Ioannis

Kenjones1935
- 19th March 2010, 03:18
This video is the same as the previous except it has an additional segment. The car goes down the hall, turns around and comes all the way back to me!!

http://video.yahoo.com/watch/7169550/18673820

Ioannis, I agree a potentiometer driven by a servo controlling direct current into the wheel motor would give the PIC smooth speed control.
For this home project with only my personal resources that is a complication I hope to avoid.

I would like some help directing me to a way to make interrupt driven PWM pulses delivered 50 times per second. My impression is with PBP GOSUB does not include arguments. This is very restricting. Am I correct?:(

Ken

Kenjones1935
- 19th March 2010, 14:01
I saw an article in SERVO which speaks about the VEX robotics computer package. The PIC is a 18F8520. My impression of the Microchip PICkit3 is that it is very close - it has a 18F8722 and a 18F87J11. The cost of a complete PICkit3 is only $164.00. Would using this tool make my project easier? more robust? more powerful? more flexible?

Ken

mackrackit
- 19th March 2010, 14:06
More code space is about all that you will get from those chip, might be some things that the 887 does not have but probably nothing to help you.

If you want to try one of those chips, check to see if the PicKit2 and PBP supports them, get on and put is on a solderless breadboard.

Save yourself $160.00

Ioannis
- 19th March 2010, 14:58
I may have not unerstood what exactly is your problem. Please can you repeat for me?

Ioannis

Kenjones1935
- 22nd March 2010, 15:38
Been thinking that a good middle school STEM hook would be simple racing on an oval indoor (gymnasium basketball court) track delineated by large cardboard boxes (big enough to be detected by the SRF05 sonar proximity detectors) on the inside. I imagine a ten lap race. For six laps the kids control the cars with their radio transmitters. For four laps the cars are autonomous.

I think I can design a PBP template that would make coding the PIC reasonably simple. The template would contain the code state machine. The students' job would be to choose the steering/wheels commands associated with each state.

I have a question for you all.

If I were to add a black tape line around the track, what electronic gimmick might I put on an RC car to make it into a line follower? Is there a commercially available light source and photo cell combo similar to the pre-canned SRF05 sonar device?

Ken

Ioannis
- 23rd March 2010, 08:29
The IR combo device is the least that I would be worry about.

Check the videos on YouTube and you will realize why I still insist on PID control.

Especially important on a line follower car! From the videos you will see that most ofthe cars are getting out of the path because they get very nervous. Or you have to make it really slow.

Ioannis

Kenjones1935
- 23rd March 2010, 18:48
I too have noticed the "nervousness" of my car and other line following devices. I made a line follower out of LEGOrobotics last summer. It too was too nervous to make fast progress.

For my project to progress from its present state I need to:

1. Get my hands on an appropriate RC vehicle. The "stadium truck" style has been suggested. It has two wheel drive, excellent miniature steering and suspension, and a broad flat frame structure to which it would be easy to attach my PIC and things. Thing is they are expensive. If I get a "ready to run" it's about $200. It will have a two channel RC. I need three channels - anther $100 or so.

2. Corral the help of some friends with access to the correct facilities to help me design and build a robust kit that can be attached to most any RC 1/10 scale vehicle.

3. Prototype a "simple" state machine structure for my PBP code. Non-computer nurd middle schoolers will throw up their hands in dismay if they had to code PBP from scratch for this 'race'. I have neither the resources nor the contacts to create a LOGO or ROBOlab like language.

4. ioannis suggests potentiometer based motor control to calm down the bot's oscillations. My inclination is to try to get my HPWM signal down to the RC spec of fifty pulses per second. With my present code one gradation plus or minus on my PWM pulse width is the difference between stopped and going pretty fast. I saw this plan (below) for Interrupt driven PWM, but I have not yet studied it.

-------------here's what I found------------



1) Decide on the resolution (the number of steps between off and 100% on. Go with 16. That's plenty.

2) Decide on a PWM frequency. Go with 30Hz. It sounds odd, but the reason becomes apparent next.

3) Set a 1:8 prescaler on an 8-bit timer.

4) Create a label "Count" and set it to the resolution (16).

5) Create a label "Demand"

6) In the interrupt service routine for the timer interrupt:

6.1) Decrement Count

6.2) When Count becomes zero, set it back to the resolution value again (16).

6.3) If Demand > Count, set the PWM output bit. Otherwise, clear it.

There you have a single PWM output. Put a value from 0 to 16 into "Demand" and the PWM output will perform accordingly. If you want two outputs, you create two Demands and perform two comparisons. (You only need one Count.)

What happens is that (assuming a 4MHz clock), this will interrupt every 256*8=2048us. Each time, the counter decrements by one. This happens 16 times meaning that each of your unique mark to space ratios is 2048us apart and that your PWM time is 2048 * 16 = 32768us, or 30.51Hz.

If your demanded PWM value is less that the PWM counter, then your PWM should be marking, otherwise, you should be spacing.

Of course 30Hz might be a bit lumpy. Swap your 4MHz crystal for a 20MHz one and suddenly you're at 150Hz. Irritatingly audiable. Your options are to reduce your resolution (half the resolution = double the frequency) or reduce your total pulse time (half the pulse time = double the frequency).

The disadvantage of reducing the resolution is obvious. The disadvantage or reducing the pulse time is that it leaves you fewer free processor cycles for your "main" program. In the example above, your interrupt is only called every 2048 cycles. Assuming it costs 200 cycles (that's generous) to process the interrupt, that leaves your main program 1948 cycles between interrupts.

You could come down to a 2:1 prescaler with a PWM resolution of 8 and a clock of 20MHz. that gives you a PWM frequency of 20/4/(2*256*8)*1000000 = 1.22kHz. BUT there are only 512 operations between interrupts then and 200(ish) of hem are taken up servicing the interrupt itself.

Kenjones1935
- 23rd March 2010, 22:25
I just realized that the innards of an Electronic Speed Control device is a servo driven potentiometer. In the old days these were actually mechanical pots but today my guess is that they are completely electronic (however that can be)

If I am wrong on this, please set me straight. What is a modern ESC?

Ken

rmteo
- 23rd March 2010, 22:54
Here is an example of an Electronic Speed Control (for brushed motors) based on a PIC12F675 that might give you an insight. For more info, source code, hex file, etc. see here Bi-Directional Speed Controller (http://homepages.paradise.net.nz/bhabbott/bridge.html)

ScaleRobotics
- 23rd March 2010, 23:03
The ESC usually comes in two main flavors. I think the most common for the cars (might) still the DC pulsed controller (for brushed motors). You could build one of these pretty easily for your car using the hardware PWM, with much the same techniques that you have already used.

http://www.designsoft.com.au/ahome/rc/PIC-ESC/ESC.html
http://www.jimfranklin.info/microchipdatasheets/00847a.pdf


As far as modern, the modern ones for RC planes are 3 phase brushless ESC's. I suspect this has made its way to the RC cars as well. This is pretty complex, although it has been done by a few do it yourselfers.

http://ww1.microchip.com/downloads/en/AppNotes/00857a.pdf


Walter

Kenjones1935
- 26th March 2010, 21:08
I keep saying that my RC car is meant to be a race car while being autonomous. Struggling to find its way around a room is not the demo that I want. I think an oval track in the gym bounded on the inside by many cardboard boxes at least a couple feet high. The kids with the RC transmitters must sit still in the lower seats of the roll out stands. The cars would be out of their sight when on the far side of the track.

My serious problem is that as a race car driver my 16F887 is not doing very well. It does not query the SRF05s quickly enough. The trigger pulses get to the sonars about one per second.

I am at a loss to figure what is consuming all the PIC compute time.

QUESTION? What would be the easiest, most efficient way for me to get on board with Assembly Language 16F887 coding? Machine language is not new to me. I used it professionally from 1957 till somewhere in the '80's. What is a clear and complete document on this ASM?

Ken

rmteo
- 26th March 2010, 21:58
Have you looked here? Getting Started with MPASM/MPLINK (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2123&param=en022517&Pagetitle=Getting%20Started%20with%20MPASM/MPLINK)

Kenjones1935
- 27th March 2010, 03:32
On page 251 of DS33014K in Appendix A. is the list of ASM instructions.
I had printed out that document last winter. Until now I did not find this list. (Except in a book printed by MikroElectroika in Belgrade.) I think this list ought to be the first thing in Chapter One!

Thanks, all. Gotta "hit the books".

Ken
Ken

Kenjones1935
- 28th March 2010, 21:46
I have not yet had to fall back on ASM code.

I did discover:

1. My PIC was resetting because of regressive subroutine calls. Changing a couple GOSUB's to GOTO's solved that.:)

2. My car was not being driven smoothly because of occasional zero responses from the SRF05's (or at least one of the SF05's). Implementing a - check again if the sensor says zero - routine after polling the sonar sensors smoothed things out.:D

I did notice that adding an IF THEN statement to the PBP code increased the size of the HEX code considerably. I still feel I need to understand the two compile processes.:(

Kenjones1935
- 30th March 2010, 23:39
Today I gained access to an abandoned gymnasium.

Immediately I realized that to make this project 'interesting' to middle school students I must greatly increase the speed. I will need to adjust the distances which trigger the car's autonomous maneuvers. My next video will be of this car racing and toggling between PIC and RC control.:rolleyes::rolleyes:

Ken

Kenjones1935
- 2nd April 2010, 23:59
Not going well at all.

When I up the speed the car does not respond quickly enough. At a corner Instead of seeing (hearing) ahead and turning, it crashes into the on coming wall, backs up, and tries again. Part of my problem is not understanding the machine language code behind the PICBASIC PRO commands. Another part is the PIC getting into little loops or resetting and thereby ignoring the real time signals. Lastly I need to expand the distances to which the code reacts. If the velocity is greater, it must start turning or braking sooner.

On the bench, the machine seems to behave as expected, but on the race track. NOPE.:mad::confused:

Ken

mackrackit
- 3rd April 2010, 16:53
Hi Ken,

I may have a solution to your problem, or part of a solution...

I picked up a PING module the other day and did some playing and watched the last video you posted very close.

My conclusion is you need to run the PIC at 20MHz.
I am running a very basic code to calculate distance so my findings may not be a total solution.

Watching the video it appears the car is pointing more at the corner the first time through, and the second time when it does not hit the wall it is just a bit to the right and a little more straight on. When I try corner targets the reading becomes very erratic. Maybe for you have the front sensor pivot slightly from left to right. Could be done with a spring and a cam bumping on the wheels?

Back to the software. I am using a PIC running a 20MHz.
When I set the PULSOUT at 10 giving the 20us you have in your code the readings become inaccurate with a great deal of fluctuation and slow to respond.

When I set the PULSOUT at 2 giving a 4us pulse the accuracy is within an inch and very very quick to respond.

Kenjones1935
- 4th April 2010, 03:01
First, my oscillator. I have been using the 16F887's internal oscillator. I think if I do nothing my prescaler is set at 4:1. The PIC has an 8mhz internal oscillator. Figure 4-1 on Page 61 of DS41291F (the x887 gospel) indicates that by setting OSCCON = %01110111 I can get the internal 8mhz oscillator and the prescaler of 1:1. Does this seem correct to you all? I will try this evening.

What do I need circuit-wise to implement the 20Meg external crystal oscillator?

Second, the placement of my forward looking SRF05. I thought I found that slanting them to the left just a bit makes less possible reflection from the side wall coming into the front pingers. That seemed to work on the bench, but again confusion in the real world. I have not thought through what the side pingers should be hearing while the car is turning left. For racing I have moved the desired track out to 24 inches away from the side wall.

Using a carpenters measuring stick I have calibrated my pingers. They seem consistent (again on my bench).

Ken

rmteo
- 4th April 2010, 03:20
First, my oscillator. I have been using the 16F887's internal oscillator. I think if I do nothing my prescaler is set at 4:1. The PIC has an 8mhz internal oscillator. Figure 4-1 on Page 61 of DS41291F (the x887 gospel) indicates that by setting OSCCON = %01110111 I can get the internal 8mhz oscillator and the prescaler of 1:1. Does this seem correct to you all? I will try this evening.

Ken
The oscillator (whether internal or external) frequency is always divided by 4 in these PIC's to get the instruction clock - it does not have anything to do with pre-scalers. Also, OSCCON.3:1 is read only.

Byte_Butcher
- 4th April 2010, 03:40
Yep, you got it. But no point in setting bits 1&2... they're read only.
This is what I use to set the 16F887 to 8MHz.:
OSCCON = %01110001 'Set Osc to 8MHz.

And don't forget to add to your define list: DEFINE OSC 8


For external xtal you will need a 20MHz crystal connected to OSC1 & OSC2 (RA7, RA6) and a small capacitor from each pin to ground. The recommended capacitor size will be in the xtal data sheet, but is typically a couple dozen pF or less.

steve

mackrackit
- 4th April 2010, 05:05
When bumping up to 8MHz try


pulsout trigfront,1

That should give you 5uS trigger. I was doing 4.

For external OSC I like ceramic resonators, good and bad to everything but with these you do not have to mess with capacitors, that is why I like them.
http://www.allelectronics.com/make-a-store/item/CER-20/20-MHZ-CERAMIC-RESONATORS/-/1.html
The two outside pins will go to RA6 and RA7, the center to the zero rail (ground).
The problem with the 44 pin demo board is Micro Chip did not "ground" the via between RA6 and RA7, so you will have to run a jumper if you go this route.
http://www.picbasic.co.uk/forum/attachment.php?attachmentid=4152&stc=1&d=1270350068

Kenjones1935
- 4th April 2010, 05:11
Bed time here on the east coast.

I tried both
OSCCON = %01110111
and
OSCCON = %01110001

I got the PIC to read the PWM signal from the radio channel 3 by doubling the threshold for differentiation. I can toggle between PIC and radio control.

But I have not been able to get the HPWM to behave. I tried using the original duty cycle. This made the wheels go backwards very fast no matter what was in the HPWM command. I tried doubling the duty cycle (to account for cutting in half the clock rate and the wheels did not turn at all. The Electronic Speed Control wants this PWM signal to arrive at 50 hz. In fact it is probably at 489Hz (according to page 87 of MicroEngineering Labs' PICBASIC PRO book). I'll put a 'scope on it tomorrow.

I think the book says that HPWM channel, 127, 50 will be a square wave of 489Hz. Does that agree with you guys' thinking?

I also have not gotten the PING echos to mean anything. The little red lights on the SRF05s are blinking. But my code is not making sense of the echo responses. I thought that all I would need to do was to double the expected echo pulse duration numbers.
Ken