Replacing existing pic

[Freman]

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

[falingtrea]

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.

[mister_e]

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?

[Freman]

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?

' 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

[mister_e]

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...

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.

[Freman]

Heh, never even thought about SELECT CASE

So something more like this then.

' 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

[Freman]

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

' 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

[Freman]

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?

[mister_e]

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.

DEFINE OSCCAL_1K 1

Your code don't enable the internal pull-up

OPTION_REG.7=0

[Freman]

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

' 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

[Freman]

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?

[mister_e]

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

[Freman]

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

[Freman]

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

[mister_e]

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.

[Freman]

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.

[Freman]

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.

[Freman]

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

' 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

[Freman]

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.

[mackrackit]

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

Paul has one also.

[mackrackit]

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

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

[Freman]

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

[skimask]

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.

[Freman]

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.

[skimask]

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.

[Freman]

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...

[skimask]

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.

[Jumper]

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

[skimask]

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.

[Freman]

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.