Reading Input Value
DHogan
Posts: 40
Hello,
I'm a newbie to using SX/B. Currently, I am working on a project that involves taking an input value from a receiver and comparing that value against known values to see if they match, and if they match, lighting up an associated LED. I'm stuck on how to code this so it holds the input value I'm receiving from the receiver. The values are all 8 bits long. We currently have the input going to RA3, so I believe we would want to store the input value in a variable (i.e. PButton VAR RA.3). Below is what I have so far.
DEVICE SX28, OSC4MHZ, TURBO, STACKX, OPTIONX
FREQ 4_000_000
PButton PIN RA.3 INPUT
Lock PIN RB.1
PROGRAM Start
Start:
IF PButton = 10011111 THEN ' check input
High Lock
PAUSE 250
END
GOTO Start
' IF statements go here
Any help would be greatly appreciated.
Thank you very much for your assistance,
Dillon
I'm a newbie to using SX/B. Currently, I am working on a project that involves taking an input value from a receiver and comparing that value against known values to see if they match, and if they match, lighting up an associated LED. I'm stuck on how to code this so it holds the input value I'm receiving from the receiver. The values are all 8 bits long. We currently have the input going to RA3, so I believe we would want to store the input value in a variable (i.e. PButton VAR RA.3). Below is what I have so far.
DEVICE SX28, OSC4MHZ, TURBO, STACKX, OPTIONX
FREQ 4_000_000
PButton PIN RA.3 INPUT
Lock PIN RB.1
PROGRAM Start
Start:
IF PButton = 10011111 THEN ' check input
High Lock
PAUSE 250
END
GOTO Start
' IF statements go here
Any help would be greatly appreciated.
Thank you very much for your assistance,
Dillon
Comments
DEVICE SX28, OSC4MHZ, TURBO, STACKX, OPTIONX
FREQ 4_000_000
Test Var Word
'SignalDetect VAR Byte
PROGRAM Start
Start:
DO
SignalDetect PIN RA.3 INPUT
Lock PIN RB.1
Unlock PIN RB.2
Trunk PIN RB.3
Panic PIN RB.4
Do
RCx VAR Byte ' for storing input
WATCH RCx
Get_RC_Pulse:
IF SignalDetect = 1 THEN Get_RC_Pulse ' wait for pin to go low
PULSIN SignalDetect, 1, RCx ' measure 10 - 2550 us pulse, 0 = 0ms, 100 = 1ms, 200 = 2ms, 150 = 1.5ms (neutral)
' now RCX approx 100-200 (if there are actual pulses). You could adjust it so 128 = neutral...., etc
High Lock
Pause 500
Low Lock
GOTO Get_RC_Pulse
I now need to be able to capture all 8 bits coming across and compare them to predefined values and then light up an associated LED. I found some code for the IR BoeBot which seems close to what I'm needing, but not sure:
' IR Remote for the Boe-Bot - RecordAndDisplayPwm.bs2
' Measure all data pulses from SONY IR remote set to control a TV.
' {$STAMP BS2}
' {$PBASIC 2.5}
time VAR Word(12) ' SONY TV remote variables.
index VAR Nib
' Display heading.
DEBUG "time ARRAY", CR,
"PWM MEASUREMENTS", CR,
"Element Duration, 2-us", CR,
"
"
DO ' Beginning of main loop.
DO ' Wait for rest between messages.
PULSIN 9, 1, time(0)
LOOP UNTIL time(0) > 1000
PULSIN 9, 0, time(0) ' Measure/store data pulses.
PULSIN 9, 0, time(1)
PULSIN 9, 0, time(2)
PULSIN 9, 0, time(3)
PULSIN 9, 0, time(4)
PULSIN 9, 0, time(5)
PULSIN 9, 0, time(6)
PULSIN 9, 0, time(7)
PULSIN 9, 0, time(8)
PULSIN 9, 0, time(9)
PULSIN 9, 0, time(10)
PULSIN 9, 0, time(11)
FOR index = 0 TO 11 ' Display 12 pulse measurements.
DEBUG CRSRXY, 0, 4 + index, "time(", DEC index, ")",
CRSRXY, 9, 4 + index, DEC time(index)
NEXT
LOOP ' Repeat main loop.
That said, some of what you have is pretty unusual (i.e. seeing if a Pin value = %10011111; a pin can only be 0 or 1). Also what's the "lock" pin about?
Thank you for your response. I have attached the files. 8-bit Reader.SXB is the working program that lights up and LED when it sees an input value go high. Test1.SXB is what I'm playing with to try and store an 8-bit value. And just to be clear as I can, I'm trying to write a program that captures 8-bits, stores it, and then compares it to values to see if they match and then light up an associated LED. I'm just trying to figure out how to capture and store the 8-bits.
Thank you very much in advance,
Dillon
One more comment. I input the following code (see attachment) and I think this might be going down the right trail now, but its still not working.
Any input is appreciated.
Thanks again,
Dillon
That said, in my own work, I generally put IR transmit/receive schemes in an interrupt so that bytes and byte counts (total bytes received) are available magically "in the background" and the main program can just pull them out and see what the bytes "say" whenever necessary. I think though, that that approach might be a better challenge for you down the road
Am I right that you have just one detector, but three leds? Can you put some comments in your code to identify the purpose of each pin, or better yet, a schematic?
Thank you again for the assistance. I have attached a schematic for what we are working on. I have also attached some printouts from an oscilloscope and code with some comments. As we work on it, it seems that coding in a series of pulsins would be the best route to go, but still not clear on how to do this. To explain what is happening, we are trying to capture and store a signal that is shown on the oscilloscope printout I've attached. There are four different signals. In the schematic, this signal is transmitted to pin RA3 on the SX28. We are then trying to compare that input signal to the four values (the same that are in the oscilloscope printout ) and if they match (which would be in an IF statement), light up an associated LED.
Any assistance you could give would be greatly appreciated and if something isn't clear, please let me know.
Many thanks,
Dillon
Thank you very, very much for your help its greatly appreciated. What you sent makes sense and it's what I thought it would look like, just couldn't figure out the syntax. As you can tell were on a steep learning curve, and I do have a question for you from the file you posted. In this line of code (see below), what does the period mean in "time.7"? I looked through some examples and SX/B Help, and couldn't find anything.
IF time > oneBit THEN time.7 = 1 ' if one bit, make bit 11 of the word message a 1
Is it referring to a bit inside the word?
I'm still tweeking the code, but when it gets to the time.7 portion of code, an error occurs that says "Invalid Number of Parameters"
You've already done this -- your pins are defined no differently. Technically "RA" is an 8-bit byte that is all the pins on the RA port. By assigning a pin definition to RA.3 you are using bit 3 (pin 3) of the RA byte (port A).
You can also test bits in a similar way:
myByte VAR Byte
myByte = 128 ' same as binary %10000000
IF myByte.7 = 1 THEN
' I am greater than or equal to 128
ELSEIF myByte.4 = 1 THEN
' I am greater than or equal to 32
ENDIF
'etc
Ok, we've changed up the code to "try" and make it work, but hitting a road block. I've attached what we've done thus far. Two areas we're not clear on are:
1) the startbit, onebit, zerobit values. The statement is made that "these are not correct and need to match the pulsin parameters and the length of actual bits." I'm not clear on what these are being compared too or what these values are doing.
2) Also, I tried compiling the code and got an "Invalid number of parameters" message for the "If time > oneBit Then time.11 = 1" statement, but seemed to clear it by putting "time.11 = 1" below, which you'll see in the code.
I think....I'm not as Zoot at programming
time.11 and so forth: I have to say I didn't compile my code, my bad
Second, what Shawn said is basically correct, but you don't need to count cycles. You have the oscilloscope measurements. You can see that the "start" bit is a long pulse, then there are a string of "ones" and "zeros" where the pulses are longer for 1s and shorter for 0s, but neither as long as the "start" bit. The PULSIN statement will return the length of the pulse in X units. READ THE DOCUMENTATION ON PULSIN FOR SX/B TO SEE WHAT THE UNITS ARE AND HOW YOU CAN CHANGE THEM.
For example, say you are using pulsin to measure a pulse in 10us units. You look at the your scope trace and see that the "start" pulse is 3ms, or 3000us. Great. That means when you use pulsin you would expect to see *about* 3000/10 as the value when a start pulse is received. 300 = 3000us/10us units.
In the code you would then set the value of the startBit constant to 300. If it were me, I might set it to 290 or 295. That gives me a little bit of error in case I miss a tick or so of the pulse.
The same goes for the ones and zero bits. Again, I can't set these for you. And 10us units for PULSIN might be a bit coarse.
Note also that my code is not particularly rigorous on error checking (any "pulse bit" that follows a start bit will be a 1 if it's bigger than the oneBit constant and 0 unless it's too small -- you could refine the error checking to look for lengths that are too big or too small in every case).
Last but not least, your code is LSB first (the first pulse to come in is the 0 bit of the message value, the last pulse is the highest bit). Is that right? And your scope trace shows more than 8 bits which is all I see in your current code (unless you are disregarding any bits transmitted after the first 8 bits).
We've managed to get some fairly consistent responses, approx. 75%. Some LED's light up fairly consistently, but one input/value seems to be very inconsistent . We have condensed the code down as much as possible in case there was too much overhead and it was slowing down the process. I've attached the code, and the schematics and previous attempts at coding are in a previous post.
Any pointers on how to get consistent values would be greatly appreciated.
Thanks,
Dillon
Have you checked that you are never getting a value > 255 from the pulsins? Because if you are, it won't be good as you are storing the result in a byte, not a word, and the results could be erratic. Generally pulsin and the like are used with words.
Also, it seems you are just checking for any low on the input pin, not a low of sufficient duration to indicate a start pulse.
Thank you,
Dillon
In any case, two immediate general concerns:
1. What is the actual project and what is it for? What's it actually do and how is it used? And I'm trusting that this is NOT a class project.
2. I'm a bit slammed today and tomorrow so what's your real timeline on this?
Then, I have one technical question: it seems like you're using the internal SX clock? Do you have a resonator or crystal for this project? The internal clock is not that accurate. For something relatively "slow" like this, a 4mhz resonator or up should be OK.
I work for a company that produces wireless products for vehicles (www.keylessride.com) and we are creating a troubleshooting product to help us with diagnostics.
Timeline is asap.
Thank you for pointing out the resonator. We are having trouble with the debugger and we pulled it and never put it back in. We did a lot of troubleshooting to resolve the debugger issue and came across this post (http://forums.parallax.com/archive/index.php/t-106388.html) which stated that there was a bad batch of SX-Key USB devices, which right now is what we are suspicious of.
Please let me know any additional information you need.
Many thanks,
Dillon
If you need any more info, please let me know. Thank you very much.
Two more questions -- your most recent code checked specific bits in the message to decide which LED(s) to light. Aren't you looking for specific whole messages? If so, what are the actual values of the pertinent messages (again, these would be constants in the code that can be changed). Or are you really parsing significant bits and not the whole message.
Second, what resonator speed(s) do you have?
I'll try to carve out some time to whip up some code later tonight, but it might have to be sometime over the weekend. Is that OK?
Many thanks for your help. Anytime is fine and is greatly appreciated.
Note that I set a margin of error of about 10 percent for the pulsewidths, but each pulse is checked for a too-large/too-small condition, so it will probably be OK. If you get too many false messages, we can customize the margin of error for each pulse type (start, zero, one).
The only thing you should need to edit is which LED(s) light up for which message(s). You'll see that code below the "Message_Done" label.
I also set up the pulsin to measure LOW going pulses -- your original code appears to be measuring HIGH going pulses (sorry I didn't catch this earlier).
In any case, when you have a chance, give it a whirl and let me know. If it doesn't work, or doesn't work as expected, we'll take it from there. And of course, if you have any questions about the code, hit me up. I tried to document the code so you can follow it; hopefully it's clear.
Last but not least -- my code presumes all of the following:
- low going pulses
- 8 bits in the message + a start bit
- MSB first in the message
- 4mhz resonator
P.S. -- I won't be around till much later this afternoon...
Code looks great! Unfortunately I can't get it to work at the moment. The code compiles and runs, but won't lite up the LEDs. I've tried to go through all the variables (pulsewidth measurement units, high/low pulses, MSB first, LSB first) and I did edit the LED values for each message. I haven't exhausted every variable, but I've done quite a few. Any thoughts?
Many thanks.
Based on your scope trace, I would expect this code to work, outside of the fact that I do not have your actual message/LED combos. That said, if it doesn't work, I would refrain from changing values hoping for a better result, and we'll just narrow down what's going on. So...
- I'm using SX/B 2.00.31. I've included the .src file if you want to try it as is and are running an older compiler
- if the 4 messages in my code each light an led, you're good, and would just need to change the LEDs lit for each message
- if some or none of the leds light up individually, but you ARE getting messages, then I would expect to see the lower nibble of the message displayed on all 4 leds for 1 second followed by the upper nibble for 1 second. If this is the case, then
-- the messages themselves need to be changed
-- the messages are LSB first, not MSB first
- if that still fails then possibly...
-- my code still has an error
-- the SX is not running at the correct speed (i.e. the resonator is not clocking the chip correctly, bad OSC setting, etc)
-- bad wiring, noise, etc. but that seems unlikely