I don't have a px, I'm just going off the documentation, but no one elses has responded, so I'll give it·a stab.
It seems you multiply all comparisons for PULSIN and RCTIME values by 2.5 (e.g. a value of 40 becomes 100··), but you may still have to tweak. You may be able to use "for next" at those speeds instead of sequential rctime commands.
Since I can't bench test this, I'm not 100% sure.· Or is that 40% on a PX???
Update
oops I had 25 instead of 40 - must have flipped too many beads on the abacus.
Thats multiply not divide since the PX is faster the counts appear longer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have Fun
TR
Post Edited (TechnoRobbo) : 9/3/2007 7:48:21 PM GMT
I still don't know either. I tried tweaking the values and got the program to recognize a key press on the remote, but it won't recognize which key was pressed. In the past, I did use the conversion values and factors given in the book, but had to do some serious mods to get the correct frequencies. You can download "IR Remote for the BoeBot" book here, and see the code to modify. If you want to modify the code and post it, I'll test it and see if it works.
I'm assuming that the PX is fast enough to do it's if-then's with in .600ms so I'm changing the rctimes that work when the pulses have already started with pulsins that wait for the pulse to start. Tell me how it works.
·[noparse][[/noparse]In order to not confuse people, this example was·removed·due second test posted later in the thread]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have Fun
TR
Post Edited (TechnoRobbo) : 9/7/2007 1:12:12 AM GMT
I made the change to pin 4 for the IR detect, then ran the code.
The first debug statement printed to the screen.
Nothing happened after that. Tried all the remote buttons.
I am changing the timing totally relying on the speed of the processor -this is starting to look like a code I'm using for an older NEC. It will not hang if it gets a header! It will simply time out at 52ms.·Lets hope the processor is fast enough to setup the next instruction with time to spare. Since clock cycles are critical I would not use any of the "POLL..."instructions in the PX since they are not true interrupts and detract from any timing loop. PS -·I hope this is the short code you were referencing.
'changed this dIrective FOR THE px
'{$STAMP BS2px}
'{$PBASIC 2.5}
time VAR Word
remoteCode VAR Byte
T4Const CON 2800
TConst· CON 1400
IR· CON 4· ' this is the pin you said
PULSIN IR, 0, time
IF time < T4Const THEN GOTO Get_Pulses
PULSIN IR,0, time ' Measure pulse
IF time > TConst THEN remoteCode.BIT0 = 1
PULSIN IR,0, time ' Measure next pulse
IF time > TConst THEN remoteCode.BIT1 = 1
PULSIN IR,0, time ' etc
IF time > TConst THEN remoteCode.BIT2 = 1
PULSIN IR,0, time
IF time > TConst THEN remoteCode.BIT3 = 1
PULSIN IR,0, time
IF time > TConst THEN remoteCode.BIT4 = 1
PULSIN IR,0, time
IF time > TConst THEN remoteCode.BIT5 = 1
PULSIN IR,0, time
IF time > TConst THEN remoteCode.BIT6 = 1
TechnoRobbo, You are a total genius, and the only person in this world to
make this work. It works perfect, the code is rock solid, and yes, this is the exact
code needed. Your idea (since clock cycles are critical) of not using any of the
"POLL..." instructions in the PX, since they are not true interrupts and detract from
any timing loop, is totally brilliant! I'm almost speechless and falling off my
chair with excitement! I just want to know how you gained so much experience
and knowledge!!! humanoido
Your welcome and thank you. Just one bit of parting advice.
To check for a button pressed on the remote use a code like this some where in your code loop:
RCTIME IR, 0 ,time
if time >0 then goto Get_Remote_Code
That way you don't waste code time polling for key presses. Don't worry if you miss a code the remote will send it again.
I cut my teeth on 6502, 6809E and 8088 Assembler programming in the early 80's and have done extensive MIDI programming for fun. I have some shareware out there (Roland once had a link to one on their website). I've written Comm terminals for the Radio Shack Color Computer and that's where I learned bit serial comm.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have Fun
TR
Post Edited (TechnoRobbo) : 9/8/2007 1:26:12 AM GMT
Comments
It seems you multiply all comparisons for PULSIN and RCTIME values by 2.5 (e.g. a value of 40 becomes 100··), but you may still have to tweak. You may be able to use "for next" at those speeds instead of sequential rctime commands.
Since I can't bench test this, I'm not 100% sure.· Or is that 40% on a PX???
Update
oops I had 25 instead of 40 - must have flipped too many beads on the abacus.
Thats multiply not divide since the PX is faster the counts appear longer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have Fun
TR
Post Edited (TechnoRobbo) : 9/3/2007 7:48:21 PM GMT
www.parallax.com/detail.asp?product_id=28139
I'm using the most simple code version for key recognition.
humanoido
·[noparse][[/noparse]In order to not confuse people, this example was·removed·due second test posted later in the thread]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have Fun
TR
Post Edited (TechnoRobbo) : 9/7/2007 1:12:12 AM GMT
The first debug statement printed to the screen.
Nothing happened after that. Tried all the remote buttons.
I am changing the timing totally relying on the speed of the processor -this is starting to look like a code I'm using for an older NEC. It will not hang if it gets a header! It will simply time out at 52ms.·Lets hope the processor is fast enough to setup the next instruction with time to spare. Since clock cycles are critical I would not use any of the "POLL..."instructions in the PX since they are not true interrupts and detract from any timing loop. PS -·I hope this is the short code you were referencing.
'changed this dIrective FOR THE px
'{$STAMP BS2px}
'{$PBASIC 2.5}
time VAR Word
remoteCode VAR Byte
T4Const CON 2800
TConst· CON 1400
IR· CON 4· ' this is the pin you said
DEBUG "Binary Value Decimal Value", CR,
"Bit 76543210 ", CR,
"
"
DO
Get_Pulses:
remoteCode = 0
PULSIN IR, 0, time
IF time < T4Const THEN GOTO Get_Pulses
PULSIN IR,0, time ' Measure pulse
IF time > TConst THEN remoteCode.BIT0 = 1
PULSIN IR,0, time ' Measure next pulse
IF time > TConst THEN remoteCode.BIT1 = 1
PULSIN IR,0, time ' etc
IF time > TConst THEN remoteCode.BIT2 = 1
PULSIN IR,0, time
IF time > TConst THEN remoteCode.BIT3 = 1
PULSIN IR,0, time
IF time > TConst THEN remoteCode.BIT4 = 1
PULSIN IR,0, time
IF time > TConst THEN remoteCode.BIT5 = 1
PULSIN IR,0, time
IF time > TConst THEN remoteCode.BIT6 = 1
DEBUG CRSRXY, 4, 3, BIN8 remoteCode,
CRSRXY, 14, 3, DEC2 remoteCode
LOOP ' Repeat main loop
·[noparse][[/noparse]reposted -there missing commas and use of is 4TConst label not allowed]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have Fun
TR
Post Edited (TechnoRobbo) : 9/6/2007 10:40:55 AM GMT
make this work. It works perfect, the code is rock solid, and yes, this is the exact
code needed. Your idea (since clock cycles are critical) of not using any of the
"POLL..." instructions in the PX, since they are not true interrupts and detract from
any timing loop, is totally brilliant! I'm almost speechless and falling off my
chair with excitement! I just want to know how you gained so much experience
and knowledge!!! humanoido
To check for a button pressed on the remote use a code like this some where in your code loop:
RCTIME IR, 0 ,time
if time >0 then goto Get_Remote_Code
That way you don't waste code time polling for key presses. Don't worry if you miss a code the remote will send it again.
I cut my teeth on 6502, 6809E and 8088 Assembler programming in the early 80's and have done extensive MIDI programming for fun. I have some shareware out there (Roland once had a link to one on their website). I've written Comm terminals for the Radio Shack Color Computer and that's where I learned bit serial comm.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have Fun
TR
Post Edited (TechnoRobbo) : 9/8/2007 1:26:12 AM GMT