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

Wolfgang,

Why not and what is the alternative?

Thanks,

Steve

mcki0127@hotmail.com wrote:

> 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

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

Hi Steve,

mcki0127@hotmail.com wrote:

> 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

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

"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.  ;-)

On Sat, 18 Dec 2004 15:30:21 GMT, the renowned "Anthony Fremont"
<spam@anywhere.com> wrote:

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

"Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message
> 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.

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.