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

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

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. 

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

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


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

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.

In article <vDZwd.55501$yf.19880@fe2.texas.rr.com>,
Anthony Fremont <spam@anywhere.com> wrote:
-
-"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?

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

BAJ

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.

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

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

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

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

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