pic16f77 acting goofy - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: pic16f77 acting goofy

Quoted text here. Click to load it

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



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


Re: pic16f77 acting goofy
Dear Steve,

snipped-for-privacy@hotmail.com schrieb:
Quoted text here. Click to load it

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


Re: pic16f77 acting goofy
Wolfgang,

Why not and what is the alternative?

Thanks,

Steve


Re: pic16f77 acting goofy
Hi Steve,


Quoted text here. Click to load it

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


Re: pic16f77 acting goofy
Quoted text here. Click to load it

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.


Re: pic16f77 acting goofy

Quoted text here. Click to load it
be no
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.  ;-)


Re: pic16f77 acting goofy
On Sat, 18 Dec 2004 15:30:21 GMT, the renowned "Anthony Fremont"

Quoted text here. Click to load it

The 18F series at least allows you to avoid that "feature".


Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: pic16f77 acting goofy

Quoted text here. Click to load it
it

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.


Re: pic16f77 acting goofy
-
-> 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?

No. There is a separate latch output register that is not affected by RMW
instructions.

BAJ

Re: pic16f77 acting goofy
On Sat, 18 Dec 2004 17:18:19 GMT, the renowned "Anthony Fremont"

Quoted text here. Click to load it

Yes, there's another SFR address (LATx) in addition to PORTx, that
behaves that way. So you can still have it the old way if you like.

Quoted text here. Click to load it

I've recently designed a couple of products with the 18F85xx series.
Pretty nice parts, but I think the next step up is to 32 bits.

Quoted text here. Click to load it


Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
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.


Re: pic16f77 acting goofy
I've seen a much simpler conversion routine that others have written,
where you would decrement flag1 while incrementing a counter.  This is
looped until flag1 hits zero and some if-statements keep track of the
ones, tens and hundreds placeholders.  I thought since I'm only working
with a number up to 20, I could do the same conversion with a series of
logic statements using fewer instruction cycles.  I think I
accomplished that (though maybe not by much) and hence the confusing
conversion routine you see.

What does the resolution for a program like this need to be?  I don't
know, but my goal was to maximize it.  Right now, trying to remember
off the top of my head, I'm somewhere in the microsec range.


Re: pic16f77 acting goofy
Well, the problem is solved.

Noel was right.  I hadn't properly initialized one of my variables
(dig1a).  Everything's working fine now.  Thanks to everone for the
insights and help.  You're good people!

Merry Christmas,

Steve


Site Timeline