| Author |
Message |
Noel Henson
Guest
|
 Posted:
Fri Dec 17, 2004 11:47 pm Post subject:
Re: pic16f77 acting goofy |
|
|
mcki0127@hotmail.com wrote:
| Quote: | Noel,
Do you mean that your inputs are active low? Mine are active high. I
have 1K pull-down resistors from each pin to ground.
Steve
|
Both the outputs, because I scan key matricies, and the inputs are
active-low. This is done for noise immunity and habit from two decades of
design with TTL-level circuit. Since mine are active-low, I initialize the
device with high (negated) outputs.
Your technique will work fine. I hope you didn't think I was being
remedial.
Noel |
|
| Back to top |
|
 |
Noel Henson
Guest
|
| Posted:
Fri Dec 17, 2004 11:53 pm Post subject:
Re: pic16f77 acting goofy |
|
|
mcki0127@hotmail.com wrote:
| Quote: | I will try to make this question as short as possible. I'm making a
"quiz box" that displays the first two of any 20 players that buzz in.
I'm using a pic16f77. The program scans 20 ports (buttons) and
displays the first two numbers (1-20) on four single digit 7-segment
LED displays via a display driver. Also, a speaker buzzes after the
first player has buzzed in. Everything works great except for this one
"little" bug.
When I first turn on the power, the displays get set to zero's and the
program starts scanning the buttons. If I first push a button in the
teens (10-19) the first digit is always wrong. For example, in stead
of displaying 12, it displays 32 or 72. Next I push a button (1-9) and
it displays correctly. If I reset the program and push the same
buttons in the same order, the problem occurs again. However, if I
reset the program and first push a button (1-9), then push a button
(10-20), it displays correctly and every time thereafter until the
power switch is toggled off then on again.
The same thing happens when I turn the power on and first press a
button (1-9) then a button (10-19) - it displays incorrectly until I
reverse the order. I push one (10-19) then one (1-9) and everything
works fine.
So, everytime I want to use it, I have to "intialize" it to get past
the bug before it will work right. This problem is very perplexing.
The program debugs fine. There is absolutely no reason for the mc to
be spitting out these goofy numbers. Does anyone have any idea,
hardware or software, what could be causing this problem? I hope this
wasn't too confusing. Thanks in advance.
Steve
|
After re-reading your description, and in light of the rest of the thread,
it looks like your scanning and port initialization are correct. Perhaps
there is an uninitialized variable in the routine that converts the scanned
key to a displayed value.
You mentioned that if you press, say, key 19, you see key 39 or key 79. in
binary:
19: 0001 1001
39: 0011 1001
79: 0111 1001
Since I have not seen your conversion routines I cannot be sure but it
looks like a register used for the most-significant digit is not being
initialized.
Noel |
|
| Back to top |
|
|
Guest
|
| Posted:
Sat Dec 18, 2004 12:49 am Post subject:
Re: pic16f77 acting goofy |
|
|
Noel,
Remedial is fine with me. I'm open to improvement and I in no wise
consider myself an expert (competent? :=) )at any of this.
Now that I look back over my program I can see that I don't initialize
dig1a or dig1b (I've changed things around a lot while
troubleshooting). My thinking there was that those registers get
rewritten anyway before being used to send data to the display. Here
is my conversion routine:
___movf flag1,0
___movwf temp ; move flag1 to temp for safe keeping
___movlw .10 ; store 10 in W
___subwf temp,0 ; subtract 10 (W) from temp (flag1)
___btfsc STATUS,C ; check if flag1<10
___goto aGreater10 ; no (C=0)
___movf flag1,0 ; yes (C=1), move flag1 to W
___movwf dig1b ; we have dig1b
___clrf dig1a ; we have dig1a (0)
___goto Output1
aGreater10
___btfsc flag1,4 ; check if flag1=20 (10100)
___btfss flag1,2
___goto aNot20
___movlw .2
___movwf dig1a ; we have dig1a (2)
___clrf dig1b ; we have dig1b (0)
___goto Output1
aNot20
___movf flag1,0
___movwf temp ; move flag1 to temp for safe keeping
___movlw .10 ; store 10 in W
___subwf temp,0 ; subtract 10 (W) from temp
___movwf dig1b ; we have dig1b
___bsf dig1a,0 ; we have dig1a (1)
Output1
"
sends data to the display
"
Since I only have 20 buttons, the only possibilities for dig1a is
either 0, 1, or 2 - not 3, 5, 7, or "F" like I'm getting. How
(generally) can I read or write to RAM in order to check the
initializations like some of the earlier posts were referring to?
Steve |
|
| Back to top |
|
|
Noel Henson
Guest
|
| Posted:
Sat Dec 18, 2004 1:07 am Post subject:
Re: pic16f77 acting goofy |
|
|
mcki0127@hotmail.com wrote:
| Quote: | Noel,
Remedial is fine with me. I'm open to improvement and I in no wise
consider myself an expert (competent? :=) )at any of this.
Now that I look back over my program I can see that I don't initialize
dig1a or dig1b (I've changed things around a lot while
troubleshooting). My thinking there was that those registers get
rewritten anyway before being used to send data to the display. Here
is my conversion routine:
___movf flag1,0
___movwf temp ; move flag1 to temp for safe keeping
___movlw .10 ; store 10 in W
___subwf temp,0 ; subtract 10 (W) from temp (flag1)
___btfsc STATUS,C ; check if flag1<10
___goto aGreater10 ; no (C=0)
___movf flag1,0 ; yes (C=1), move flag1 to W
___movwf dig1b ; we have dig1b
___clrf dig1a ; we have dig1a (0)
___goto Output1
aGreater10
___btfsc flag1,4 ; check if flag1=20 (10100)
___btfss flag1,2
___goto aNot20
___movlw .2
___movwf dig1a ; we have dig1a (2)
___clrf dig1b ; we have dig1b (0)
___goto Output1
aNot20
___movf flag1,0
___movwf temp ; move flag1 to temp for safe keeping
___movlw .10 ; store 10 in W
___subwf temp,0 ; subtract 10 (W) from temp
___movwf dig1b ; we have dig1b
___bsf dig1a,0 ; we have dig1a (1)
Output1
"
sends data to the display
"
Since I only have 20 buttons, the only possibilities for dig1a is
either 0, 1, or 2 - not 3, 5, 7, or "F" like I'm getting. How
(generally) can I read or write to RAM in order to check the
initializations like some of the earlier posts were referring to?
Steve
|
clearing dig1a in initialization may help. You may also want to change:
bsf dig1a,0
to:
movlw 0x01
movwf dig1a
I don't see dig1a being in the case of a key in the 10-19 range.
Just an educated guess,
Noel |
|
| Back to top |
|
|
Wolfgang Mahringer
Guest
|
| Posted:
Sat Dec 18, 2004 1:13 am Post subject:
Re: pic16f77 acting goofy |
|
|
Dear Steve,
mcki0127@hotmail.com schrieb:
| Quote: | ___movf flag1,0
___movwf temp ; move flag1 to temp for safe keeping
___movlw .10 ; store 10 in W
___subwf temp,0 ; subtract 10 (W) from temp (flag1)
___btfsc STATUS,C ; check if flag1<10
___goto aGreater10 ; no (C=0)
___movf flag1,0 ; yes (C=1), move flag1 to W
___movwf dig1b ; we have dig1b
___clrf dig1a ; we have dig1a (0)
___goto Output1
aGreater10
___btfsc flag1,4 ; check if flag1=20 (10100)
___btfss flag1,2
|
^^^^^^ NEVER do this. Two btfsc/gtfss in a row are no good idea!
HTH
Wolfgang
--
From-address is Spam trap
Use: wolfgang (dot) mahringer (at) sbg (dot) at |
|
| Back to top |
|
|
Guest
|
| Posted:
Sat Dec 18, 2004 1:21 am Post subject:
Re: pic16f77 acting goofy |
|
|
Noel,
"I don't see dig1a being in the case of a key in the 10-19 range."
Let me be more clear. If, for example, button 15 is pushed, flag1
stores the value 15 (0F). Then the conversion routine splits that up
so that dig1a stores a 1 and dig1b stores a 5. Is that what you were
getting at?
By the way, these are good suggestions which I will try early next week
as I don't have my box with me right now.
Steve |
|
| Back to top |
|
|
Guest
|
| Posted:
Sat Dec 18, 2004 1:23 am Post subject:
Re: pic16f77 acting goofy |
|
|
Wolfgang,
Why not and what is the alternative?
Thanks,
Steve |
|
| Back to top |
|
|
Noel Henson
Guest
|
| Posted:
Sat Dec 18, 2004 1:42 am Post subject:
Re: pic16f77 acting goofy |
|
|
mcki0127@hotmail.com wrote:
| Quote: | Noel,
"I don't see dig1a being in the case of a key in the 10-19 range."
Let me be more clear. If, for example, button 15 is pushed, flag1
stores the value 15 (0F). Then the conversion routine splits that up
so that dig1a stores a 1 and dig1b stores a 5. Is that what you were
getting at?
By the way, these are good suggestions which I will try early next week
as I don't have my box with me right now.
Steve
|
I see that you set dig1a to a '1' with:
bsf dig1a,0
That leaves the other bits at some potentially uninitialized value. When
you have a key in the 1-9 range, you specifically clear dig1a thus
initializing all the bits.
Just my take on it.
Noel |
|
| Back to top |
|
|
Guest
|
| Posted:
Sat Dec 18, 2004 2:20 am Post subject:
Re: pic16f77 acting goofy |
|
|
Noel,
Your right, dig1a never gets initialized in the event it gets set to
1. That's a problem which I'll have to fix.
Steve |
|
| Back to top |
|
|
Wolfgang Mahringer
Guest
|
| Posted:
Sat Dec 18, 2004 3:11 pm Post subject:
Re: pic16f77 acting goofy |
|
|
Hi Steve,
mcki0127@hotmail.com wrote:
| Quote: | Why not and what is the alternative?
|
Well, the bit-test-and-skip is intended to skip
the next opcode in row if the test condition is false.
What happend if one uses a skip intruction to eventually skip
another one....who knows.
However, this is not a good programming style.
To check if the flag1 register has a value of 20 you can do:
movf flag1,w
sublw 20
btsfc STATUS,Z
goto equal
not_eq:
...
....or something similar.
Your test (2 btfs in row) does not test for a 20 in flag1,
since you don't test the zero bits.
HTH
Wolfgang
--
From-address is Spam trap
Use: wolfgang (dot) mahringer (at) sbg (dot) at |
|
| Back to top |
|
|
Gary Kato
Guest
|
| Posted:
Sat Dec 18, 2004 7:05 pm Post subject:
Re: pic16f77 acting goofy |
|
|
| Quote: | Well, the bit-test-and-skip is intended to skip
the next opcode in row if the test condition is false.
What happend if one uses a skip intruction to eventually skip
another one....who knows.
|
As far as I know, there shouldn't be a problem with two or more skip
instructions in a row. A skip merely increments the PC. There should be no
problem with the CPU if you skipped from one skip instruction to another. |
|
| Back to top |
|
|
Anthony Fremont
Guest
|
| Posted:
Sat Dec 18, 2004 8:30 pm Post subject:
Re: pic16f77 acting goofy |
|
|
"Gary Kato" <garykato@aol.com> wrote in message
news:20041218090519.06002.00001475@mb-m21.aol.com...
| Quote: | Well, the bit-test-and-skip is intended to skip
the next opcode in row if the test condition is false.
What happend if one uses a skip intruction to eventually skip
another one....who knows.
As far as I know, there shouldn't be a problem with two or more skip
instructions in a row. A skip merely increments the PC. There should
be no
problem with the CPU if you skipped from one skip instruction to
another. |
There isn't, it's a perfectly valid (albeit confusing) construct or it
would be documented as illegal in the datasheets. Back to back bit
flipping on loaded output ports.......now that's another matter. ;-) |
|
| Back to top |
|
|
Spehro Pefhany
Guest
|
| Posted:
Sat Dec 18, 2004 8:38 pm Post subject:
Re: pic16f77 acting goofy |
|
|
On Sat, 18 Dec 2004 15:30:21 GMT, the renowned "Anthony Fremont"
<spam@anywhere.com> wrote:
| Quote: |
"Gary Kato" <garykato@aol.com> wrote in message
news:20041218090519.06002.00001475@mb-m21.aol.com...
Well, the bit-test-and-skip is intended to skip
the next opcode in row if the test condition is false.
What happend if one uses a skip intruction to eventually skip
another one....who knows.
As far as I know, there shouldn't be a problem with two or more skip
instructions in a row. A skip merely increments the PC. There should
be no
problem with the CPU if you skipped from one skip instruction to
another.
There isn't, it's a perfectly valid (albeit confusing) construct or it
would be documented as illegal in the datasheets. Back to back bit
flipping on loaded output ports.......now that's another matter. ;-)
|
The 18F series at least allows you to avoid that "feature".
Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com |
|
| Back to top |
|
|
Anthony Fremont
Guest
|
| Posted:
Sat Dec 18, 2004 10:18 pm Post subject:
Re: pic16f77 acting goofy |
|
|
"Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message
| Quote: | I wrote:
There isn't, it's a perfectly valid (albeit confusing) construct or
it
would be documented as illegal in the datasheets. Back to back bit
flipping on loaded output ports.......now that's another matter. ;-)
The 18F series at least allows you to avoid that "feature".
|
I'm assuming that the 18F's read the port latch during RMW instead of
the actual pin state, is that correct?
I haven't started using them yet, but I just got Peatman's "new" book on
the 18F452. They look real nice, but a bit different from what I'm used
to. I started with an F84 and progressed to the F628. I'm anxious to
play with some F88's as well now, since I've never tinkered with an
internal ADC yet.
I'm going to build up Peatman's circuit board, but Digikey is lacking
one of the parts in their kit so shipping is delayed until Jan or Feb
2005. I'm going to see if they will ship what they have and back order
the missing piece. I hope my Picall programmer will be able to install
the boot loader into the 18F452. |
|
| Back to top |
|
|
Guest
|
| Posted:
Sat Dec 18, 2004 10:23 pm Post subject:
Re: pic16f77 acting goofy |
|
|
Wolfgang,
Your test (2 btfs in row) does not test for a 20 in flag1,
since you don't test the zero bits.
Actually, if everything is working right, it does test for a 20 because
in my conversion routine I rule out other possibilities first. Note
that there will never be a number greater than 20 written to flag1. So
if the <5> bit is 1, it is a 20, otherwise, it's less than 20. I
admit, this may not be the most efficient, straight forward code, but
it works (theoretically).
Nonetheless, I will take your advice and avoid using double btfs in
the future though I'm still not 100% sure why. |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in