PDA

View Full Version : need audible pulse out that varies "on time"



MUC
- 21st April 2009, 14:12
Hello,

PBP
16F88
4MHz int osc

I need to send a pulse out to a buzzer that will vary in on time. I need the program to continue running/taking readings while the pulse is generated. I have a variable that ranges from 1-64. I want to beep a piezo slowly at a reading of one, say 500ms. At a variable reading of 64 it would be a constant tone.

I have no idea where to begin with this. Would I use HPWM?. Do I need to use timer1 with INT instead? Please help set me on the right track here.

Thanks,
Mark

Acetronics2
- 21st April 2009, 14:48
Hi, Mark

Could you tell more about what you intend to do ???

Especially the rate your program takes samples ... you need at least one clock @ 2Hz for your buzzer ( active one ??? ) , it's sure.
But could it be derived from another clock ( sampling clock ??? )

many solutions ... but we need to know a little much about your project !!!

Alain

MUC
- 22nd April 2009, 03:07
Made a mistake. I'm using a 18F4620 for this. 20mhz resonator. I'm communicating to a 16F88 but I need to have the piezo on the 18F4620. And the more I think about it I would like to have 1 beep per second at 0 and full on at 64.

This is a small tracking unit for my RC plane. It could be used to track anything really. I am using two xBee modules to serially communicate between the two pics. The 16F88 is in the plane. When the handheld (18F4620) is in range they start to communicate. I send a command to the plane and then AT commands directly to the xBee to get the signal strength of the last packet. I'm using a directional antenna on the handheld to determine the direction.

I'm not using the hardware serial port because I had to many problems. Things worked with software serial so that is what I stayed with. I'll probably move the xBee module off the hardware serial pins and use it for the LCD.


' 18F4620
'************************************************* ************************

DEFINE OSC 20 ' 20Mhz resonator use HS when programming

'********* Defines for Hardware Serial Port*******************************

'DEFINE HSER_RCSTA 90h ' Receive enabled (pin)
'DEFINE HSER_TXSTA 20h ' Transmit enabled (pin)
'DEFINE HSER_BAUD 38400 ' Baud
'DEFINE HSER_CLROERR 1 ' Auto Reset Buffer Overrun Errors

'********* Setup registers, 18F4620 ****************************************

CMCON = %00000111 ' Disable Comp
ADCON1 = %00001111 ' all pins digital

TRISA = %11111111 ' Set PORTA input/output
TRISB = %11111111 ' Set PORTB input/output
TRISC = %10111000 ' Set PORTC input/output
TRISD = %11111001 ' Set PORTD input/output
TRISE = %11101011 ' Set PORTE - set I/O bits 0,1,2 only leave rest alone

'************************************************* **************************

LCDbaud CON 84 ' 9600bps
RxDataBaud con 84 ' 6 = 38400 : 32 = 19200 : 84 = 9600 true, non-inverted
TXDataBaud con 84 ' 6 = 38400 : 32 = 19200 : 84 = 9600 true, non-inverted

RunLED var PORTC.2 ' pic pin 17 Program running
RxData var PORTC.7 ' pic pin 26 connected to data-out on xbee
TxData var PORTC.6 ' pic pin 25 connected to data-in on xbee
SparkLCD var PORTB.4 ' pic pin 37 connected to data on LCD
buzzerOn var PORTE.1 ' pic pin 9 buzzer on
buzzerOff var PORTE.0 ' pic pin 8 buzzer off
forceSleep var PORTA.5 ' pic pin 7 put remote to sleep for X time
failSafe var PORTA.4 ' pic pin 6 get remote in area to report ID
SW1 var PORTA.0 ' address select switch

command var byte ' command sent to remote
Xcommand var byte ' command executed by remote - reported back from remote
address var word ' number/address sent to remote
rssi var word
valid var byte

'************************************************* *************************

PORTC.6 = 1 ' PIC Tx pin(25) to Rx on XBee module
address = 0
command = 1
high RunLED

'************************************************* ************************

start:
gosub getAddress
gosub getCMD
gosub sendCMD
gosub getRSSI
gosub displayLCD
pause 250 'delay needed to read number on LCD
goto start

siglost:
serout2 commands to print to serial LCD "no signal" ' takes ~17ms with pauses required
GOTO start

'*****//Subs//************************************************** ****

getAddress
read input pins on pic and set address. reads a four position dip

getCMD
read input pins on pic that set command for remote to execute. i have a loud alarm i can remotely turn on and off

sendCMD
serout2 TxData, TxDataBaud,[address, command]
serin2 RxData, RxDataBaud, 250, siglost,[wait ("ACK"), address, Xcommand] ' echo back to confirm command was executed
return

getRSSI
communicate with wireless module, takes ~10ms
'this is where i get 0-64 for signal strength
'WANT TO SET BEEP ON PIEZO HERE
return

displayLCD
Serout2 RSSI data to serial LCD
return

mister_e
- 22nd April 2009, 03:32
So from what I feel, you'll need to use HPWM. Look in your datasheet to spot the CCP1, CCP2 pins, see if they're free, and If so, well, it's just a matter of few lines of code then.

Play around this one


if Strenght= 0 then
HPWM Channel, DutyCycle, Frequency
PAUSE 500
CCP1CON = 0 ' turn of PWM
LOW YourBuzzerOut (or high depending)
PAUSE 500
endif

if Strenght= 64 then
HPWM Channel, DutyCycle, Frequency
endif

MUC
- 22nd April 2009, 04:13
thanks Steve,

So this would require a pause of 1 second if the reading is zero? I can't afford that kind of delay. Is there another way?

Mark

mister_e
- 22nd April 2009, 04:21
Yes, you could start an endless timer interrupt (let's say few milliseconds) in which you check your value, then start the HPWM and keep track of the required delay.

OR, enable the timer interrupt in your code, and assign a duration or flags for the HPWM.

Jerson
- 22nd April 2009, 11:19
The way I would do it is to implement a soft PWM. I think it's been covered on this site already. Let a timer run in the background every mS. Give it a value for on time of the buzzer (0-1000mS) Every time the timer ticks, you can verify if the buzzer needs to be on or off. Now, all you have to do is give it a value from your mainline code.

MUC
- 22nd April 2009, 12:46
jerson,

why soft and not HPWM? Honestly I'm not fully getting this...

Mark

Jerson
- 22nd April 2009, 14:22
MUC

Frankly :o simply because I'm so used to it by now, I've never had to do the HPWM. I do a lot of temperature controllers with cycle times in the range of 1 to 30 seconds. So, ..... It's more a matter of personal taste.

Jerson