Replacing existing pic

1 Attachment(s)

G'day there.

I'm sure what I have is a very simple problem, but I'm having a bit of trouble working out the back side to it.

Back story - I'm upgrading my home theater (if it can be called that) to be operated from a single remote through my media PC. I've already gotten most of the other stuff working (with help from here with the comparator stuff I was having problems with before)

I've pulled apart the receiver/controller for my motorized projection screen. Imagin my delight to see it's driven by a PIC chip - unfortunatly the chip that's existing has code protect so I can't just reverse engineer the chip and add my new feature (a 1 wire serial port). I'm forced to try and replicate the code.

I've got a fair understanding of most of it, but the input buttons have me lost.

Attached is a very very basic overview of the circuit that my new pic has to slot into.

How on earth can I tell what button is pushed?

Things I know.

Pin 6 to Pin 7 is 4.7v (it varies a little), pin 6 to gnd is 0.2v (it also varies a little) Pin 7 to gnd is 5v

Can you think of any way they might have been reading the 3 buttons in the original circuit?

Ideally I'd love keep the original RF remote working as well, but as I have no idea what signals it's using (And don't have a scope) I don't know how I can do that

If a pin varies a little, it may be changing state faster than the device you are trying to measure it with. I would think the code is doing something with the weak pull-ups on the pins. Fiddling with the weak pull-ups would allow the chip to scan the buttons, and the code may even use the ADC to read pin levels.

Sure enough they use internal pull-ups. Make sure you disable the ADCs and comparators before.

Now how to know which push button.. Are you sure of the current schematic? Any way it miss some resistors and/or diode in that?

I'm positive there's no missed resistors or diodes in relation to the push buttons - as much as it's a very abbreviated schematic, the circuit really doesn't have much more - I can upload some scans of the board if you like, but I've actually decided to approach this a different way.

Originally I was going to sacrafice the remote control function to gain a serial interface, but what I've since decided to do is take the two outputs from the original pic and feed it into another pic - this will give me my serial interface and keep the remote control - without having to deal

Now I have a problem with frightfully slow interrupts - I've tested this in PIC Simulator and it works reasonably quickly there. In real life tho, this code interrupts 'eventually' usually 5-20 seconds later. I can't see why, I'm only tying it up for 10 ms then I've inserted an extra pauseus so it's got something to interrupt before/after before returning to serin.

Anyway I can speed up the interrupt to... between 11 and 100 ms?

Code:

' Configure the pic @ device pic12F675, INTRC_OSC_NOCLKOUT, WDT_ON, PWRT_ON, MCLR_OFF, BOD_ON, CPD_OFF, PROTECT_OFF N9600 CON 6 CMCON = 7 ANSEL = 0 Relay1 VAR GPIO.5 Relay2 VAR GPIO.4 SlavePower VAR GPIO.2 SlaveRelay1 VAR GPIO.0 SlaveRelay2 VAR GPIO.1 Serial VAR GPIO.3 B0 var BYTE INPUT SlaveRelay1 INPUT SlaveRelay2 INPUT Serial OUTPUT Relay1 OUTPUT Relay2 OUTPUT SlavePower ON INTERRUPT GOTO slaveSpeaks IOC = %00000011 INTCON = %10001000 ' Turn on the original PIC HIGH SlavePower main: B0 = 0 PAUSEUS 1 SERIN Serial, N9600, 10, main, [1], B0 ' The original PIC latches it's output, we want to reboot the original pic if we get something from the serial port to force it's outputs low IF B0 > 1 THEN LOW SlavePower if B0 = 2 THEN GOSUB subUp IF B0 = 3 THEN GOSUB subDown IF B0 = 4 THEN GOSUB subStop IF B0 > 1 THEN PAUSEUS 1000 HIGH SlavePower ENDIF GOTO main DISABLE subUp: LOW Relay2 HIGH Relay1 RETURN subDown: LOW RELAY1 HIGH Relay2 RETURN subStop: LOW Relay1 LOW Relay2 RETURN slaveSpeaks: if SlaveRelay1 THEN GOSUB subUp ELSE IF SlaveRelay2 THEN GOSUB subDown ELSE GOSUB subStop ENDIF ENDIF INTCON = %10001000 RESUME ENABLE

I would probably skip the interrupt and perform everything in a tight loop instead. As the Relay check is done pretty quick. Not a fan of using GOSUBs in a ISR.

From what i feel, S2 should have dual contacts attach to GPIO<1:0>

To know which relay is activated, i would bet that...

Code:

WhichRelay VAR BYTE ' ' ' ' WhichRelay=GPIO & 3 Select case WhichRelay CASE 0 ' Relay 2 ' do stuff for relay 2 CASE 1 ' Relay 1 ' do stuff for relay 1 CASE 2 ' Relay 3 ' do stuff for relay 3 END SELECT

If you still want to use Ints, don't re-enable the GIE bit, the PIC will do it for you. Just clear the offending INT flag and get out of there.

If you play with GIE bit, you will run into problems, that's for sure.

Heh, never even thought about SELECT CASE

So something more like this then.

Code:

' Configure the pic @ device pic12F675, INTRC_OSC_NOCLKOUT, WDT_ON, PWRT_ON, MCLR_OFF, BOD_ON, CPD_OFF, PROTECT_OFF N9600 con 6 CMCON = 7 ANSEL = 0 Relay1 VAR GPIO.5 Relay2 VAR GPIO.4 SlavePower VAR GPIO.2 SlaveRelay1 VAR GPIO.0 SlaveRelay2 VAR GPIO.1 Serial VAR GPIO.3 B0 var BYTE SlaveState VAR BYTE WhichRelay VAR BYTE INPUT SlaveRelay1 INPUT SlaveRelay2 INPUT Serial OUTPUT Relay1 OUTPUT Relay2 OUTPUT SlavePower restart: SlaveState = 0 PAUSEUS 1000 HIGH SlavePower main: B0 = 0 pauseus 1 SERIN Serial, N9600, 10, main, [1], B0 IF B0 > 1 THEN LOW SlavePower if B0 == 2 THEN GOSUB subUp IF B0 == 3 THEN GOSUB subDown IF B0 == 4 THEN GOSUB subStop IF B0 > 1 THEN GOTO restart WhichRelay = GPIO & 3 IF SlaveState <> WhichRelay THEN SlaveState = WhichRelay SELECT CASE WhichRelay CASE 0 GOSUB subStop CASE 1 GOSUB SubUp Case 2 GOSUB subDown END SELECT ENDIF goto main subUp: LOW Relay2 HIGH Relay1 RETURN subDown: LOW RELAY1 HIGH Relay2 RETURN subStop: LOW Relay1 LOW Relay2 RETURN

Oh I feel like such an idiot - Note to self, double check the label in 'serin' if you change your code substantially...

Code:

' Configure the pic @ device pic12F675, INTRC_OSC_NOCLKOUT, WDT_ON, PWRT_ON, MCLR_OFF, BOD_ON, CPD_OFF, PROTECT_OFF N9600 con 6 CMCON = 7 ANSEL = 0 Relay1 VAR GPIO.5 Relay2 VAR GPIO.4 SlavePower VAR GPIO.2 SlaveRelay1 VAR GPIO.0 SlaveRelay2 VAR GPIO.1 Serial VAR GPIO.3 B0 var BYTE SlaveState VAR BYTE WhichRelay VAR BYTE INPUT SlaveRelay1 INPUT SlaveRelay2 INPUT Serial OUTPUT Relay1 OUTPUT Relay2 OUTPUT SlavePower restart: SlaveState = 0 PAUSEUS 1000 HIGH SlavePower main: B0 = 0 SERIN Serial, N9600, 15, testSlave, [1], B0 LOW SlavePower SELECT CASE B0 CASE 2 GOSUB subUp CASE 3 GOSUB subDown CASE 4 GOSUB subStop END SELECT GOTO restart testSlave: WhichRelay = GPIO & 3 IF SlaveState <> WhichRelay THEN SlaveState = WhichRelay SELECT CASE WhichRelay CASE 0 GOSUB subStop CASE 1 GOSUB SubUp Case 2 GOSUB subDown END SELECT ENDIF goto main subUp: LOW Relay2 HIGH Relay1 RETURN subDown: LOW RELAY1 HIGH Relay2 RETURN subStop: LOW Relay1 LOW Relay2 RETURN

Nope, that isn't working either.

It's working in the simulator but not in the real life.

Should I set up pulldown resistors on the inputs of the new pic from the outputs of the old pic?

This should work. The only thing i would suggest you, is to use a slower baudrate, check the manual for that. They suggest higher speed OSC for 9600 bauds.

Maybe not a bad idea to call the OSCCAL value to make sure you use the factory calibration for the internal OSC.

Code:

DEFINE OSCCAL_1K 1

Your code don't enable the internal pull-up :o

Code:

OPTION_REG.7=0

1 Attachment(s)

I'm not actually using the serial at the moment, I'm just trying to get to the "other" part of the code, but I'll try 2400 bps, I'll also try the osccal

So you're telling me I should set that bit to 0 in my code?

Nope still no go :( This is the code and attached is the schematic

I know the slave is bringing the pins high (multi-meter and beep confirms it)

Edit: One clue I have is.... if I comment out the serial routine and tell it to goto the 'testSlave' label, it works fine

Code:

' Configure the pic @ device pic12F675, INTRC_OSC_NOCLKOUT, WDT_ON, PWRT_ON, MCLR_OFF, BOD_ON, CPD_OFF, PROTECT_OFF DEFINE OSCCAL_1K 1 N2400 con 4 CMCON = 7 ANSEL = 0 OPTION_REG.7 = 0 Relay1 VAR GPIO.5 Relay2 VAR GPIO.4 SlavePower VAR GPIO.2 SlaveRelay1 VAR GPIO.0 SlaveRelay2 VAR GPIO.1 Serial VAR GPIO.3 B0 var BYTE SlaveState VAR BYTE WhichRelay VAR BYTE INPUT SlaveRelay1 INPUT SlaveRelay2 INPUT Serial OUTPUT Relay1 OUTPUT Relay2 OUTPUT SlavePower LOW Relay1 LOW Relay2 restart: SlaveState = 0 PAUSEUS 1000 HIGH SlavePower main: B0 = 0 SERIN Serial, N2400, 20, testSlave, [1], B0 LOW SlavePower SELECT CASE B0 CASE 2 GOSUB subUp CASE 3 GOSUB subDown CASE 4 GOSUB subStop END SELECT GOTO restart testSlave: WhichRelay = GPIO & 3 IF SlaveState <> WhichRelay THEN SlaveState = WhichRelay SELECT CASE WhichRelay CASE 0 GOSUB subStop CASE 1 GOSUB SubUp Case 2 GOSUB subDown END SELECT ENDIF goto main subUp: LOW Relay2 HIGH Relay1 RETURN subDown: LOW RELAY1 HIGH Relay2 RETURN subStop: LOW Relay1 LOW Relay2 RETURN

SOLVED

I think :)

Throw a 10k resistor from the serial pin to ground. The question now is, should that resistor remain even after I actually hook up the serial signal from the other device?

[PC - USB > serial] ---> [Main Board (PCCLD)] ---> {1 way serial} ---> [New/Master PIC]

Should that resistor remain, or can I turf it once I hook up the serial?

As you're using the Timeout, the serial pin must Idle at the right level. Not a bad idea to leave this resistor.

http://www.picbasic.co.uk/forum/show...86&postcount=5

Well, all in all it works - most of the time.... well half of the time

The PCCLD pic is a PIC16F628A running at 20 Mhz
The Master pic is a PIC16F675 running on internal clock at 4Mhz

I'm pretty sure my programmer has fried the CALIB so DEFINE OSCCAL_1K 1 breaks the serial function.

The ONLY baud of those I've tried (1200, 2400 and 9600) that works (somewhat randomly) is 9600 - none of the others work.

Not sure if that's more a function of the PCCLD pic or the Master pic

I'm about ready to give up on serial ports

It shouldn't work at 9600 yet it does randomly...

It should work at 2400 but it doesn't at all

IF the DEFINE OSCCAL break the serial comm and almost everything, it's a good sign your device programmer screwed the internal calibration, that's for sure. If you have a PICKIT2, you can recover it in few seconds with the OSCCAL Auto regenerate utility.

Acetronics also posted something here.

Lost your OSCCAL Value ???
http://www.picbasic.co.uk/forum/showthread.php?t=7588&

One thing is sure, you're using a BitBanging Serial communication, you may miss some bytes here and there. Using a Hardware USART provide a 2 bytes buffer and Interrupt capability... which are handy.

For a simple test, remove the relay check and keep only the serial part, without timeout. See if it works better.

Given up, moving up to the pic16f628a - Means I can do more as well.
Another consideration I had was using maxim one wire components to free up 4 of the pins, I could have put a crystal on it then.

Still can't really use the hardware uart on the pic16f628a because the pic it's talking to is already using it's hardware uart.

I'll keep a note on that recovery source, that will come in useful :)

But here's my new schematic - http://users.on.net/freman/images/el...ceiverplus.png

I used the interrupt pin for serial communication, so I could interrupt by sending it high, then send bytes :)
The other option is to use the hardware uart but it'd be connected to software serial at the other end...

I'm not set on that yet, this one's still on the breadboard.

Gone completely back to the idea of replacing the pic.

I think I'll be best served by hooking up my soundcard scope and seeing if it is indeed scanning the input buttons.

Ok guys, I've replicated the functionality of the original 8 pin chip, here's the code - any thoughts?

This is why there's pin fiddling on BUTTONA and BUTTONB
Attachment 2617

Thanks some more :)

Code:

' Configure the FUSE options for the compiler @ device pic16F628A, hs_osc, wdt_off, pwrt_on, lvp_off, protect_off, bod_on, cpd_off, pwrt_off, mclr_off ' Running a 20Mhz clock DEFINE OSC 20 DEFINE PULSIN_MAX 3000 CMCON = 7 VRCON = 0 ALL_DIGITAL ' Setup the USART DEFINE HSER_RCSTA 90h ' Receive register to receiver enabled DEFINE HSER_TXSTA 20h ' Transmit register to transmitter enabled DEFINE HSER_BAUD 19200 ' Set baud rate ' Alias our pins BEEP VAR PORTA.0 ' Buzzer RFIN VAR PORTA.1 ' Remote input RELAY1 VAR PORTB.4 ' Relay 1 output RELAY2 VAR PORTB.5 ' Relay 2 output BUTTONA VAR PORTB.6 ' Primary panel button input BUTTONB VAR PORTB.7 ' Secondary panel button input ' Set the pin directions INPUT RFIN INPUT BUTTONA INPUT BUTTONB OUTPUT BEEP OUTPUT RELAY1 OUTPUT RELAY2 ' Configure the output pins as low LOW BEEP LOW RELAY1 LOW RELAY2 ' Turn on weak pull-ups - IMPORTANT: After making relays and beepers low... OPTION_REG.7 = 0 ' Set us up some variables PBITS VAR BYTE[24] ' The bits we've read RAW VAR WORD ' The raw pulsin value ADDRESS VAR WORD ' Storage for the address DBYTE VAR BYTE ' Storage for the data LOOPADDRESS VAR WORD ' Second loop storage of first loop addres LOOPDBYTE VAR BYTE ' Second loop storage of first loop data byte X VAR BYTE ' Loop/TMP var Y VAR BYTE ' Loop/TMP var STATE VAR BYTE ' Current state of the device ' Constants STATE_STOPPED CON 0 ' Screen is stopped STATE_GOING_UP CON 1 ' Screen is going up STATE_GOING_DOWN CON 2 ' Screen is going down ' Default state STATE = STATE_STOPPED ' Reset all the primary RF variables TOP: ADDRESS = 0 : RAW = 0 : DBYTE = 0 ' This is the real main - almost all the looping comes back here MAIN: ' Set both buttons for input INPUT BUTTONA INPUT BUTTONB ' Check to see if the individual buttons are toggled IF NOT BUTTONA THEN GOSUB subDown IF NOT BUTTONB Then GOSUB subUp ' Fiddle with the inputs to see if the middle button is pushed LOW BUTTONB X = BUTTONA ' If it's LOW then there's a good chance the middle button is down HIGH BUTTONB INPUT BUTTONB LOW BUTTONA Y = BUTTONB ' If it's LOW then there's a good chance the middle button is down HIGH BUTTONA INPUT BUTTONB INPUT BUTTONA IF NOT Y AND NOT X THEN GOSUB subStop ' Both register as LOW then the middle button is down! ' Look for one huge low pulse PULSIN RFIN, 0, RAW ' 2350 is about mean average IF RAW < 2340 OR RAW > 2360 THEN MAIN ' Read 16 address bits and 8 data bits FOR X = 0 TO 23 PULSIN RFIN, 0, RAW ' Check the pulse parameters IF RAW < 30 OR RAW > 240 THEN MAIN PBITS[x] = NCD RAW NEXT X ' Gather the address ADDRESS = 65535 ' Maxmimum known ID FOR X = 0 to 15 IF PBITS[x] > 7 THEN ADDRESS.0[X] = 0 NEXT X ' Gather the data DBYTE = 255 ' Maximum known data value Y=0 FOR X = 16 TO 23 IF PBITS[X] > 7 THEN DBYTE.0[Y] = 0 Y = Y + 1 NEXT X ' If we've done a loop... IF ADDRESS == LOOPADDRESS AND DBYTE == LOOPDBYTE THEN SELECT CASE DBYTE CASE 3 GOSUB subUp CASE 12 GOSUB subStop CASE 192 GOSUB subDown END SELECT LOOPDBYTE = 0 LOOPADDRESS = 0 ELSE ' Start a loop LOOPDBYTE = DBYTE LOOPADDRESS = ADDRESS ENDIF GOTO TOP END subUp: IF STATE != STATE_GOING_UP THEN HIGH BEEP ' Start making noise HSEROUT ["UP",10,13] ' DEBUG LOW RELAY1 ' Make sure the down relay is off (Don't know what happens otherwise, don't want to know!) PAUSEUS 65355 ' Wait a bit HIGH RELAY2 ' Turn the up relay on LOW BEEP ' STFU :) STATE = STATE_GOING_UP ENDIF RETURN subStop: IF STATE != STATE_STOPPED THEN HIGH BEEP ' Start making noise HSEROUT ["STOP", 10, 13] ' DEBUG LOW RELAY1 ' Turn off the down relay LOW RELAY2 ' Turn off the up relay PAUSEUS 65355 ' Wait a bit LOW BEEP ' STFU :) STATE = STATE_STOPPED ENDIF RETURN subDown: IF STATE != STATE_GOING_DOWN THEN HIGH BEEP ' Start making noise HSEROUT ["DOWN",10,13] ' DEBUG LOW RELAY2 ' Make sure the up relay is off (Don't know what happens otherwise, don't want to know!) PAUSEUS 65355 ' Wait a bit HIGH RELAY1 ' Turn the down relay on LOW BEEP ' STFU :) STATE = STATE_GOING_DOWN ENDIF RETURN

He guys.

Is there any way (other then DarrelTaylor's elapsed timer) to work out how many seconds have passed?

Darrel's method K/O's my pulsin code.

I was looking to time the descent of the screen and stop it at 44 seconds - which is the right height for viewing.

My fall back method is a reed switch - but that'll mean that there's an ugly reed switch visible to the naked eye when the screen is up.

For the record the screen takes 49 seconds to fully descend but that leaves it about a foot too long.

Search the forum for Mel's Olympic Timer and RTC. The might do the trick.

Paul has one also.

http://www.picbasic.co.uk/forum/show...eal+time+clock

http://www.picbasic.co.uk/forum/show...=olympic+timer

Thanks mackrackit, I'll have a look at these.

I've already worked out I can't rely simply on adding 1 to a word (while in theory this works, in reality there's quite a deviation)

I am prepared to fall back on pullies, string, and a piece of pvc with a magnet/reed switches if I have to - this will allow me to put the sensors out of sight... hopefully

Quote:

Originally Posted by Freman

I am prepared to fall back on pullies, string, and a piece of pvc with a magnet/reed switches if I have to - this will allow me to put the sensors out of sight... hopefully

Haven't read the whole thread..but...
Couldn't you put a small piece of something reflective on the back of the screen, have an IR led/detector module or similar mounted in the wall behind the screen, if even a few feet behind the screen, and use the detector output as the start/stop sensor? One gets set up so when the beam is there (i.e. reflective piece is bouncing back the light), the screen is all the way down, the other is set up at the top so when the beam is there, the screen isn't quite all the way up. You really wouldn't even need the beam on continuously, just a quick blip every second or so might tell you what you want to know.

I did consider that - and it's not off the drawing board.

I was concerned with the amount of bending anything reflective attached to the back of the screen might suffer - I was also worried about possible damage of the front facing screen (it's a glass beaded screen).

I suppose if it came down to it, I could drill a small hole in the support behind the screen (it's held free-standing from the wall/ceiling by two large timber towers - full of dvd's :)) and stick something reflective to the backside of the felt side strips.

I've looked at http://www.rentron.com/PicBasic/infr..._detection.htm for the basic idea - I just need to find something that's reflective, sticky, and can handle being rolled and unrolled over and over again.

Bending - well, you really wouldn't need anything crazy. I'd bet just a piece of scotch tape would reflect well enough. Or maybe a piece of black electrical tape...the inverse of what I was thinking earlier...it DOESN'T reflect.

As far as sticky and reflective, why even use any tape at all? The white screen itself should be reflective enough to bounce some light back into a sensor. Then it would be a matter of 'dialing out' the ambient light.

It would be mounted behind the screen - the back side of the screen is a flat black - haven't tested it's reflectivity.

The other alternative is to use one piece of shiny 'something' on the back of the screen at the bottom (where it doesn't bend) and use 2 detectors.

Which of these would you use?
* Phototransistor (Say: http://tinyurl.com/5bspbk for example)
* Photodiode (Say: http://tinyurl.com/58wuwp for example)
* or a full on IR Receiver (Like: http://tinyurl.com/54vqs6) and PWM the IR led(s) to the right frequency.

Edit: Oooh, just found the Sharp IS471F proximity detector... that could be nice - cept for shipping - I can pick the other options up locally...

Quote:

Originally Posted by Freman

Which of these would you use?
* Phototransistor (Say: http://tinyurl.com/5bspbk for example)
* Photodiode (Say: http://tinyurl.com/58wuwp for example)
* or a full on IR Receiver (Like: http://tinyurl.com/54vqs6) and PWM the IR led(s) to the right frequency.

Can't really say for sure. Phototransistor/diode would probably require a bit of 'lensing' to aim to light right, but you wouldn't need to be really accurate or anything. But...you might trip the sensor with the ambient light in the room, so you'd need to throw a bit of 'fuzzy logic' in the program, maybe a counter that say counts 10 times in a row it senses the light and kicks out whatever it is you want to kick out.
An IR TX/RX may have it's advantages...relatively easy to do, one obvious one being that you'd only be looking for the signal that you're sending out, fewer false triggers.
Either way you go, if you know when the IR is on, then you can sense if the IR is really being reflected vs. with ambient light, if you know the IR is off, and you're sensing the signal, then you know the room light is getting in the way.

Why not a mouse sensor

Hi,

Why not attach a sensor with encoder from an old PC mouse on the end of the rotating axis. Then you can count how many pulses and position your screen within mm from where it should be.

You might even have a pin on your pic to a hardware counter and then it will more or less count by itself.

/me

Quote:

Originally Posted by Jumper

Why not attach a sensor with encoder from an old PC mouse on the end of the rotating axis. Then you can count how many pulses and position your screen within mm from where it should be.
You might even have a pin on your pic to a hardware counter and then it will more or less count by itself.

I thought about that too...but, if that count goes off by one this time, one the next time, and so on, one of those times, the motor is gonna drive too far, burn out, the screen is going to fall off, whatever. Still need some sort of end of travel sensor to reset the counter to zero (or 100 or whatever) once in awhile to keep things straight.

Actually the motor has it's own cut-out

When the screen is fully extended it kills the motor, and when it's fully retracted it does the same. That's built in the head end. The worse that'll happen is it'll extend to far for my use and knock something off the TV unit :)

I did consider it, and still haven't ruled it out (as a mouse is cheaper then my parts order ;) - and I should have one laying around)

But I have questions like - how do I count without causing the remote to fail, or while still being able to respond on the serial port. - If I remember right
one of these timer/pwm/things/ works as a counter also - perhaps I can let it do the counting in the background and interrupt when it overflows.

I suppose it's one of those things I'd have to experiment with.

The option is open for a combination of the two.

A sensor at the top to tell it when it's fully retracted, and using the mouse sensor to count the way down.

But, just knowing absolutely whether the screen is UP or DOWN will be so much easier.

My biggest problem now comes from being completely broke and not being able to afford the parts I need to make sensors.