SX/B Help example on 3x5 matrix keypad - coding to SEROUT
T&E Engineer
Posts: 1,396
I have taken the SX/B Help file on the 4x4 keypad and have a working version of it that uses an old Radio Shack 3x5 keypad. When a key is pressed it displays the digit on the 7 segment LED display. All of this was done on my Professional Development board and done fairly easily.
However, I have modified it to TX the character code out (SEROUT) to another SX28 and RX it in (SERIN). After doing a WATCH for the·RX variable I see that it is represented by a:
128 decimal (for a 0),
129 (for a 1),
130 (for a 2),
131 (for a 3),
132 (for a 4),
133 (for a 5),
134 (for a 6),
135 (for a 7),
136 (for a 8),
137 (for a 9),
138 (for a A),
139 (for a
,
140 (for a C),
141 (for a D),
142 (for a E)
I would think that I am sending out ascii characters and Im not sure why the SEROUT wants to start at 128 instead of an ASCII '0' code or something like I would think.
When sending them out:
Then when I receive it with something like this:
The Watch Datachr shows 128-141.
Is this correct?
However, I have modified it to TX the character code out (SEROUT) to another SX28 and RX it in (SERIN). After doing a WATCH for the·RX variable I see that it is represented by a:
128 decimal (for a 0),
129 (for a 1),
130 (for a 2),
131 (for a 3),
132 (for a 4),
133 (for a 5),
134 (for a 6),
135 (for a 7),
136 (for a 8),
137 (for a 9),
138 (for a A),
139 (for a
,140 (for a C),
141 (for a D),
142 (for a E)
I would think that I am sending out ascii characters and Im not sure why the SEROUT wants to start at 128 instead of an ASCII '0' code or something like I would think.
When sending them out:
Main:
theKey = GETKEY ' get a key
IF theKey < 15 THEN ' was a key pressed?
READ ReMap + theKey, theKey ' yes, remap keypad
READ Digits + theKey, LEDs ' output to display
[b]TX_Byte theKey[/b]
DELAY 100
ENDIF
GOTO Main
' ------------------------------------------------------
' Subroutine Code
' ------------------------------------------------------
' Use: TX_BYTE theByte {, repeats}
[b]TX_BYTE:
[/b] temp3 = __PARAM1 ' save byte
IF __PARAMCNT = 1 THEN ' check for repeats
temp4 = 1 ' set repeats to 1
ELSE
temp4 = __PARAM2 ' get repeats from user
ENDIF
SEROUT Sio, Baud, temp3
RETURN
Then when I receive it with something like this:
Main:
DataChr = RX_BYTE ' wait
watch DataChr
break
Goto Main
RX_BYTE: SERIN Sio, Baud, tmpB3 RETURN tmpB3
The Watch Datachr shows 128-141.
Is this correct?
Comments
It's not accurate enough for serial communications.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Educate your children to self-control, to the habit of holding passion and prejudice and evil tendencies subject to an upright and reasoning will, and you have done much to abolish misery from their future and crimes from society"
Benjamin Franklin
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·
Oh wait...you can't use a resonator with DEBUG to watch the variable. How do I get arround this?
Do you have an idea of what I should be seeing (if not 128 and higher)?
A few thoughts come to mind. First, from your stated output it does not look to me like you are experiencing unreliable communication. It seems like you are reliably receiving the same unexpected values for each key. Something seems to be setting your most significant bit to a one adding 128 to the received value. I suspect that your baud mode setting may be at fault. Try "ON” or "T” or “N” and see if one of those fixes it.
To answer some of your other questions…
When you use the debugger the SX-Key itself generates the required clock signal. So no resonator should be connected when running the debugger.
I expect that you should be seeing key values returned in the range of 0 to 14. To confirm this you can run the debugger on the sender and see what key values are being passed to the SEROUT command.
I hope this helps.
- Sparks
So the SX that you are using DEBUG has correct timing, the other that is running without the SX-Key does not have correct timing.
I've seen ALL kinds of problems using the internal oscillator.
That warning is there for a reason [noparse];)[/noparse]
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Educate your children to self-control, to the habit of holding passion and prejudice and evil tendencies subject to an upright and reasoning will, and you have done much to abolish misery from their future and crimes from society"
Benjamin Franklin
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·
I wish there was better protection built in. They are so easy to destroy - if you are not careful with them.
- Sparks
Someone may tell me this is not possible but it seems to me that I also experienced similar symptoms as the result of a software programming error. As I recall, I later discovered that I was inadvertently overwriting the Program Counter register while trying to optimize an assembly routine. The SX Simulator allowed me to discover this error and correct it. Thanks G
What I saw was very strange. I could not use DEBUG on that SX52 protoboard (always in a SLEEPING state) with the STEP, WALK, RUN ghosted. OK...what else was that certain programs would run. EG. I had a test program that displayed 1 LED at a time and it worked fine (no problems with programming it either). However, all of my other interupt driven·programs did nothing (nothing on the LED display "16x16").
Does this make sense that 1 simple program would work and another would not?
What I did was cut all the 32 wires and power from my 16x16 LED matrix and soldered them to a new SX52 protoboard. All of the programs worked with LEDs turning on/off as the should.
I will have to order a couple more SX52 protoboards next week.