Searching \ for ' Increment' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=increment
Search entire site for: 'Increment'.

No exact or substring matches. trying for part
PICList Thread
'PIC16C5X PC increment'
1995\12\05@023101 by Nuno Alexandre Marques

flavicon
face
Hi!
I think there is a mistake on the funcional description of the PIC16C5X
Serie about the PC increment operation, after the execution of each
instruction.
On page 1-8 of the Microchip Databook, it says explicitly:

"During program execution [PC] is autoincremented with each instruction
unless the result of that instruction changes the PC itself:
a) ...
b) ...
c) ...
d) If PC is the destination in any instruction (e.g MOVWF 2, ADDWF 2, or
BSF 2,5) then the computed 8-bit result will be loaded into the low
8-bits of the PC (...)"

I thought case d) was one of the cases PC is not incremented, because
"the result of that instruction changes the PC itself". However,
executing simulations of several programs (some of them included in
application notes), the PC is incremented in those cases (namely, after
the instruction ADDWF 2,1 for example).

Are the simulators not correct or there is, in fact, a mistake in the
description ?

Thanks in advance.

- Nuno Marques

1995\12\05@024601 by Andrew Warren

flavicon
face
Nuno Alexandre Marques <spam_OUTnacmTakeThisOuTspamELVIS.INESC.PT> wrote:

>  On page 1-8 of the Microchip Databook, it says explicitly:
>
>  "During program execution [PC] is autoincremented with each
> instruction unless the result of that instruction changes the PC
> itself:
> ....
> d) If PC is the destination in any instruction (e.g MOVWF 2, ADDWF
> 2, or BSF 2,5) then the computed 8-bit result will be loaded into
> the low 8-bits of the PC (...)"
>
>  I thought case d) was one of the cases PC is not incremented,
>  because "the result of that instruction changes the PC itself". However,
> executing simulations of several programs (some of them included in
> application notes), the PC is incremented in those cases (namely,
> after the instruction ADDWF 2,1 for example).
>
>  Are the simulators not correct or there is, in fact, a mistake in
> the description ?

Nuno:

It's a mistake in the documentation.  The data book SHOULD say that
the PC is always incremented, and that instructions that modify the
PC will act on the NEW value.  For example, look at the following
code:

       MOVLW   2
       ADDWF   PC
       RETLW   100
       RETLW   101
       RETLW   102

When the ADDWF PC is executed, the first thing that happens is that
the PC is incremented (so it now points to the "RETLW 100".  Then
the contents of the W-register (2) are added to the PC, so it'll
point to the "RETLW 102".  Finally, the RETLW 102 is executed, so
the PIC will return from the subroutine with W = 102.

-Andy


Andrew Warren - .....fastfwdKILLspamspam@spam@ix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geopages.com/SiliconValley/2499

1995\12\06@032927 by Tony Grimer

flavicon
picon face
In responce to this question ...
{Quote hidden}

Being quite new to the PIC but having investigated numerous Von Neuman and
Harvard architectures there seems nothing strange or obviously wrong with
the PC being incremented when ever an instruction is fetched..

In fact you see the PC is incremented before instruction execution - i.e.
following the instruction fetch.

A typical fetch cycle for any processor follows the standard..

               Program Counter to Memory Buffer Registers
               Read Memory for that location (i.e. read the instruction )
               Put result of read into the processor Instruction Register.
               Program Counter to Program Counter + 1.


The execution cycle for the instruction, since this PIC has a RISC set no
further memory access will be needed, will then modify the registers etc as
necessary.

If the Program Count to Program Count + 1 action in the fetch did not happen
on every fetch, the instruction itself would need to have the address of the
next instruction to execute.

The much more interesting ideas on this topic are to be found in CISC based
systems with pipe line pre-fetch such as the 80x86. The advances in P5 and
P6  try to be too clever in my view... Any Comments ...


----------------------------------------------------------------------------
----------
Tony Grimer ----  cm1918spamKILLspamscitsc.wlv.ac.uk (Tony D. Grimer)

School of Computing (SCIT)  Room MC108 Tel - 0902-322764.

----------------------------------------------------------------------------
----------


'Erratic PC increment through interrupt'
1996\04\26@074704 by Wolfram Liebchen
flavicon
face
Does anyone know, if there is danger of erratic PC increment
caused by an interrupt during a MOVWF PCL ?
The application note AN556, concerning table reads / computed GOTO
on a PIC 16Cxx device, says, that one has to disable interrupts to
prevent the computed GOTO from jumping one instruction too far.

The data book (at least for PIC 17C42) says, that increment of PC
is inhibited after GOTO, CALL, RETURN... and MOVWF PCL. So then, there
should be no danger?
Or even worse, an interreupt during a normal GOTO could also cause a
false jump ?!?

I would like to hear, if anyone has tested for this problem.

TIA

Wolfram


+-----------------------------------------------+
! Wolfram Liebchen, .....liebchenKILLspamspam.....ipserv.ffo.fgan.de !
!      Forschungsinstitut fuer Optik            !
!      Schloss Kressbach                        !
!      D-72072 Tuebingen                        !
!      Tel: +49 (0)7071 / 709-158               !
!      Fax: +49 (0)7071 / 709-270   (G3 / G4)   !
+-----------------------------------------------+

1996\04\26@090603 by myke predko

flavicon
face
>Does anyone know, if there is danger of erratic PC increment
>caused by an interrupt during a MOVWF PCL ?
>The application note AN556, concerning table reads / computed GOTO
>on a PIC 16Cxx device, says, that one has to disable interrupts to
>prevent the computed GOTO from jumping one instruction too far.
>
>
>Wolfram

Wolfram, my ownly comment would be that interrupts may be disabled during a
"movwf PCL", but I believe the command that is normally used in
tables/computed jumps is "addwf PCL,f" (which is not in your list of
interrupt disabling commands).

I think I have lucked out in my applications by doing table reads _before_
interrupts are enabled and inside interrupt handlers (in which interrupts
are disabled).

I will definitely add this to my list of "things to avoid".

Myke
Myke

"We're Starfleet officers, weird is part of the job."

Capt. Catherine Janeway

1996\04\26@114316 by Scott Dattalo

face
flavicon
face
Wolfram Liebchen wrote:
>
> Does anyone know, if there is danger of erratic PC increment
> caused by an interrupt during a MOVWF PCL ?
> The application note AN556, concerning table reads / computed GOTO
> on a PIC 16Cxx device, says, that one has to disable interrupts to
> prevent the computed GOTO from jumping one instruction too far.
>
> The data book (at least for PIC 17C42) says, that increment of PC
> is inhibited after GOTO, CALL, RETURN... and MOVWF PCL. So then, there
> should be no danger?
> Or even worse, an interreupt during a normal GOTO could also cause a
> false jump ?!?
>
> I would like to hear, if anyone has tested for this problem.
>

The information in AN556 is incorrect. You do not need to disable interrupts
in computed GOTOs.

Scott


P.S.
Andy W., I just checked your PIC question 5. It still references AN576.


'Reading "bleeps" from incremental encoder'
1998\04\09@172848 by frougi01
flavicon
face
Hi,

I am implementing a robot control circuit using the PIC16C73.  The motor is
driven by a National LMD18201 H-Bridge that is being fed from the
microcontroller with a PWM pulse train.
I successfully used the Timer2 (TMR2) in conjunction with the CCP1 pin to
generate the pulse.
Now, I need to read "bleeps" or pulses from a digital encoder mounted on the
motor shaft.
I want to be able to count the number of bleeps from the encoder while the
pulse train is being generated by the pic, then shut the motor down.
I tried implementing on pin change interrupt from PORTB pin, so that each
time an interrupt occur, a counter is incremented. But when I debugged the
code, everything was working fine. That is the TMR2 will increment and set
CCP1 at the appropriate timing even if it is in the interrupt service
routine.  I built the circuit and nothing happened. Actually, the pic would
read a series of pulse from the encoder then turn off the pulse train. I
can't find the culprit!

So my questions are:

* how do I read the bleeps from the encoder (digital)?
* Does the TMR2 overflow interrupt is turned off when the code goes in the
ISR causing a o% duty cycle?

Help me please.


Franck


PS: Please use the same subject for mail sorting purposes. Thank you.


'Reading "bleeps" from incremental encoder'
1998\05\04@171430 by frougi01
flavicon
face
Hi,

I am implementing a robot control circuit using the PIC16C73.  The motor is
driven by a National LMD18201 H-Bridge that is being fed from the
microcontroller with a PWM pulse train.
I successfully used the Timer2 (TMR2) in conjunction with the CCP1 pin to
generate the pulse.
Now, I need to read "bleeps" or pulses from a digital encoder mounted on the
motor shaft.
I want to be able to count the number of bleeps from the encoder while the
pulse train is being generated by the pic, then shut the motor down.
I tried implementing on pin change interrupt from PORTB pin, so that each
time an interrupt occur, a counter is incremented. But when I debugged the
code, everything was working fine. That is the TMR2 will increment and set
CCP1 at the appropriate timing even if it is in the interrupt service
routine.  I built the circuit and nothing happened. Actually, the pic would
read a series of pulse from the encoder then turn off the pulse train. I
can't find the culprit!

So my questions are:

* how do I read the bleeps from the encoder (digital)?
* Does the TMR2 overflow interrupt is turned off when the code goes in the
ISR causing a o% duty cycle?

Help me please.


Franck


PS: Please use the same subject for mail sorting purposes. Thank you.

1998\05\07@214845 by Sujay Sirur

flavicon
picon face
Hi Franck,

Your question has truly purplexed me. What are these "Bleeps"? I used to
think that a shaft encoder gives 2 signals in quadrature (90 deg. out of
phase). Both signals need to be used to know where the motor has moved to?
Or are you doing speed control? If you are doing position control, I would
suggest you use the HCTL2020 from HP. Its a rugged and proven design, might
cost a bit though.

At 16:56 5/4/98 -0400, Franck D Rougier wrote:
{Quote hidden}

with best wishes and regards
Sujay Sirur

Email: EraseMEsirurspam_OUTspamTakeThisOuTgiasbg01.vsnl.net.in
Home: 604, Chitrapur Housing Society, Plot no 68, 15th Cross, 8th Main,
Malleshwaram
           Bangalore 560 055. INDIA   Tel. no: 91-80-344

1998\05\08@092403 by Montaigne, Mike

flavicon
face
I just ordered and tried out some LS7083 & LS7084 encoder to counter
interface chips from the URL below and I am very pleased.  Much easier
than doing it the hard way with 74LS123's and gates.  The 83/84 is an
eight pin cmos dip that takes your quadrature encoder signals and gives
you a count up/count down or a pulse/direction to feed directly to your
PIC or a 74193 or a 4516 counter.  They also have a X1 / X4 option.  I
wish I had found these chips earlier.  If anyone knows of other encoder
chips (other than the HP), pls. post or email me.  They make working
with encoders easy.  BTW we use Intelligent Motion Systems stepper motor
drivers and would really like to find a servo motor controller that took
encoder inputs and pulse & direction control inputs.

http://www.usdigital.com/
http://www.usdigital.com/products/ls7083-84/
good luck

Mike Montaigne
Atomic Energy of Canada Ltd.
Station 18, Chalk River, Ontario
K0J 1J0, Canada

Phone (613) 584-3311 Ex. 4005
Fax:     (613) 584-4040
email:   montaignemspamspam_OUTaecl.ca

{Quote hidden}

1998\05\08@103000 by Stuart Allen

flavicon
face
>The 83/84 is an
>eight pin cmos dip that takes your quadrature encoder signals and gives
>you a count up/count down or a pulse/direction to feed directly to your
>PIC or a 74193 or a 4516 counter.


Hello,

Siemens manufacture rotary encoders with this functionality built in. I only
know of one model: SFH-910. I am sure other manufacturers include this too.

Stuart.

__________________________________________________________________

Stuart Allen                         Tel   : +49 (0)711 5858-501
Development Engineer                 Fax   : +49 (0)711 5858-199
Sony Stuttgart Technology Center
Stuttgarter Strasse 106
D-70736 Fellbach, Germany
__________________________________________________________________


'[OT] Using a mouse as a cheap incremental encoder?'
1998\06\23@033305 by Charlos Potma
flavicon
face
I am working on a project where I use a BOURNS mechanical
incremental encoder to modify the frequency generated by
a DDS. The DDS and the encoder are connected to a PIC.
I would like to use a higher resolution optical encoder but
the price is prohibitive. I am now considering using a
PC mouse, or at least some part of it as an encoder.
The standard PC mouse seems to have a DATA and CLOCK
output. Does anyone here have detailed information on the
protocol used? Any information on the pinout of the
6-pin header that is frequently found on the PCB?
Any information on how the mouse is normally connected to
the PC hardware?

thanks,
Charlos Potma
spamBeGonecharlos.potmaspamBeGonespamrivm.nl

'[Re: OT] Using a mouse as a cheap incremental enco'
1998\06\23@122155 by Joe Little

flavicon
face
part 0 2476 bytes content-type:text/plain------ =_NextPart_001_01BD9EB9.9702B070
Content-Type: text/plain

    I started with a nice 1024 slot encoder on my front panel.  I was
spending
    a lot of time and code trying to make it easy to adjust. It was
just too
    sensative.  I tried 512, 256, 64 and 16 count models. The one that
works
    best for me, is the 64 slot optical encoder from HP.  About $17.
Works
    smooth, and seems quite sturdy.

    The 16 count mechanical one needed so much de-bounce, that it
almost had to
    be turned one click at a time.  It did have a push button (Push
knob?)
    contact built in that I kind of liked.

------ =_NextPart_001_01BD9EB9.9702B070
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.1960.3">
<TITLE>[Re: OT] Using a mouse as a cheap incremental encoder?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; I started with a nice 1024 slot encoder
on my front panel.&nbsp; I was spending </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; a lot of time and code trying to make
it easy to adjust. It was just too </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; sensative.&nbsp; I tried 512, 256, 64
and 16 count models. The one that works </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; best for me, is the 64 slot optical en
coder from HP.&nbsp; About $17.&nbsp; Works </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; smooth, and seems quite sturdy.</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; The 16 count mechanical one needed so
much de-bounce, that it almost had to </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; be turned one click at a time.&nbsp; I
t did have a push button (Push knob?) </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; contact built in that I kind of liked.
</FONT>
</P>

</BODY>
</HTML>
------ =_NextPart_001_01BD9EB9.9702B070--

'[OT] Using a mouse as a cheap incremental encoder?'
1998\06\23@124914 by Larry N. Fraysier

flavicon
face
Check out:   http://www.worldaccessnet.com/~dstixrud

Larry

----------
{Quote hidden}

1998\06\23@130150 by Mike Keitz

picon face
On Tue, 23 Jun 1998 09:20:36 +0200 Charlos Potma <EraseMECharlos.PotmaspamRIVM.NL>
writes:
> I am now considering using a
>PC mouse, or at least some part of it as an encoder.
>The standard PC mouse seems to have a DATA and CLOCK
>output. Does anyone here have detailed information on the
>protocol used?

Sounds like a PS/2 type mouse.  These use two TTL lines with
bidirectional synchronous signals very similar to a keyboard.  A serial
mouse would be simpler to use a since it sends data one way over one
wire.  The data is just standard asynchronous at 1200 baud.  Microchip
made some pre-programmed PICs once to use as mouse controllers.  The data
for these had fairly good descriptions of the signal format.

For a Microsoft-type serial mouse, groups of three 7-bit characters are
sent LSB first with start and stop bits just like standard async data.
The data is sent only after the user activates something on the mouse, if
it is sitting still no data is sent.  The characters are:

1(LB)(RB)(V7)(V6)(H7)(H6) - (LB, RB are 1 if the button is pressed)
0(H5)(H4)(H3)(H2)(H1)(H0)
0(V5)(V4)(V3)(V2)(V1)(V0)

The PIC would look at the MSB of each character and wait until one with a
1 is found, indicating the start of a new packet.  Then it could
accumulate the V and H bits in proper order.  I think the two 8-bit
numbers are two's complement reperesentation of how far the mouse has
moved since the last report.



_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

1998\06\23@141015 by Sean Breheny

face picon face
On Tue, 23 Jun 1998, Mike Keitz wrote:

> On Tue, 23 Jun 1998 09:20:36 +0200 Charlos Potma <RemoveMECharlos.PotmaEraseMEspamEraseMERIVM.NL>
> writes:
> > I am now considering using a
> >PC mouse, or at least some part of it as an encoder.
> >The standard PC mouse seems to have a DATA and CLOCK
> >output. Does anyone here have detailed information on the
> >protocol used?
>
> Sounds like a PS/2 type mouse.  These use two TTL lines with
> bidirectional synchronous signals very similar to a keyboard.  A serial
> mouse would be simpler to use a since it sends data one way over one
> wire.  The data is just standard asynchronous at 1200 baud.  Microchip
> made some pre-programmed PICs once to use as mouse controllers.  The data
> for these had fairly good descriptions of the signal format.

I thought that I'd seen simple (no IC's or active components, just wires)
adapters to go between a serial mouse and a PS/2 bus mouse port. If what
you are saying is true, how can a simple adaptor convert an asynchronous
signal to a bi-directional synchronus signal? I could be wrong, its just
that I seem to remember these adaptors.

THanks,

Sean


{Quote hidden}

1998\06\23@145942 by Joe Little

flavicon
face
part 0 3247 bytes content-type:text/plain------ =_NextPart_001_01BD9ED9.67C20AA0
Content-Type: text/plain

    The mice that work with those adapters ain't your everyday old
mouse.  They
    need to have both interfaces built in.  PS2 mice have clock and
data lines.
    Older mice have RS-232 RX & Tx.  The newest mice have all four
signals.
    The designers were clever selecting the pins, so that the unused
signals
    are connected where they will do no harm to the existing hardware.

    -------------------

    I thought that I'd seen simple (no IC's or active components, just
wires)
    adapters to go between a serial mouse and a PS/2 bus mouse port. If
what
    you are saying is true, how can a simple adaptor convert an
asynchronous
    signal to a bi-directional synchronus signal? I could be wrong, its
just
    that I seem to remember these adaptors.

------ =_NextPart_001_01BD9ED9.67C20AA0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.1960.3">
<TITLE>RE: [OT] Using a mouse as a cheap incremental encoder?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; The mice that work with those adapters
ain't your everyday old mouse.&nbsp; They </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; need to have both interfaces built in.
&nbsp; PS2 mice have clock and data lines. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; Older mice have RS-232 RX &amp; Tx.&nb
sp; The newest mice have all four signals.&nbsp; </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; The designers were clever selecting th
e pins, so that the unused signals </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; are connected where they will do no ha
rm to the existing hardware.</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; -------------------</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; I thought that I'd seen simple (no IC'
s or active components, just wires) </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; adapters to go between a serial mouse
and a PS/2 bus mouse port. If what </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; you are saying is true, how can a simp
le adaptor convert an asynchronous </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; signal to a bi-directional synchronus
signal? I could be wrong, its just </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; that I seem to remember these adaptors
.</FONT>
</P>

</BODY>
</HTML>
------ =_NextPart_001_01BD9ED9.67C20AA0--

1998\06\23@150121 by Bob Blick

face
flavicon
face
On Tue, 23 Jun 1998, Sean Breheny wrote:
>
> I thought that I'd seen simple (no IC's or active components, just wires)
> adapters to go between a serial mouse and a PS/2 bus mouse port. If what
> you are saying is true, how can a simple adaptor convert an asynchronous
> signal to a bi-directional synchronus signal? I could be wrong, its just
> that I seem to remember these adaptors.

Hi Sean,

Those adapters only work on highly intelligent mice, the kind that figure
out what they are hooked upon powerup and communicate the correct way. All
the new Logitech mice are like that, probably some others too.

-Bob

'Re[2]: [OT] Using a mouse as a cheap incremental e'
1998\06\23@152027 by Martin Green

flavicon
face
    The interface to a PS/2 mouse is NOT TTL. It is open collector and is
    very similar in concept to I2C. Just because the interface is
    bidirectional doesn't mean you have to use it that way. Just pull the
    clock and data lines up with a resistor (the active pullups in a PIC
    should work ok) and read the levels with a PIC. It is much simpler to
    use a PS/2 mouse than a serial one since there are no rigid timing
    requirements or level translations needed as with RS-232 (everything
    is 5V). It is a simple matter of using the CLOCK line to determine
    when the level on the DATA line is valid. In fact, it is so simple you
    could probably capture mouse output with a common shift register.

    Definitely go with the PS/2 mouse instead of the serial one.


    CIAO - All.


______________________________ Reply Separator _________________________________
Subject: Re: [OT] Using a mouse as a cheap incremental encoder?
Author:  pic microcontroller discussion list <RemoveMEPICLISTspam_OUTspamKILLspamMITVMA.MIT.EDU> at
Internet
Date:    6/23/98 12:52 PM


On Tue, 23 Jun 1998 09:20:36 +0200 Charlos Potma <RemoveMECharlos.PotmaTakeThisOuTspamspamRIVM.NL>
writes:
> I am now considering using a
>PC mouse, or at least some part of it as an encoder.
>The standard PC mouse seems to have a DATA and CLOCK
>output. Does anyone here have detailed information on the
>protocol used?

Sounds like a PS/2 type mouse.  These use two TTL lines with
bidirectional synchronous signals very similar to a keyboard.  A serial
mouse would be simpler to use a since it sends data one way over one
wire.  The data is just standard asynchronous at 1200 baud.  Microchip
made some pre-programmed PICs once to use as mouse controllers.  The data
for these had fairly good descriptions of the signal format.

For a Microsoft-type serial mouse, groups of three 7-bit characters are
sent LSB first with start and stop bits just like standard async data.
The data is sent only after the user activates something on the mouse, if
it is sitting still no data is sent.  The characters are:

1(LB)(RB)(V7)(V6)(H7)(H6) - (LB, RB are 1 if the button is pressed)
0(H5)(H4)(H3)(H2)(H1)(H0)
0(V5)(V4)(V3)(V2)(V1)(V0)

The PIC would look at the MSB of each character and wait until one with a
1 is found, indicating the start of a new packet.  Then it could
accumulate the V and H bits in proper order.  I think the two 8-bit
numbers are two's complement reperesentation of how far the mouse has
moved since the last report.



_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

1998\06\23@153048 by Martin Green

flavicon
face
    The adaptors you describe rely on the mouse encoder chip being able to
    "auto-detect" the type of interface it is connected to. Many newer
    mice can, but el-cheapo's or older mice often can't. I have a
    beautiful older Logitech 3-button mouse that unfortunatly is serial
    only (the internal mechanics of this thing make all other mice I've
    opened look like toys, it has NEVER needed cleaning in 5 years,
    including the ball). If I remember correctly, the Logitech M-series
    mice are auto-detect, while the C-series mice are not.

    So you see, the adapter you describe just allows the physical
    connection of one connector type to another. It is the mouse itself
    which behaves totally differently depending on whether it is connected
    to a serial port or a PS/2 connector.


    CIAO - Martin.


______________________________ Reply Separator _________________________________
Subject: Re: [OT] Using a mouse as a cheap incremental encoder?
Author:  pic microcontroller discussion list <EraseMEPICLISTspamspamspamBeGoneMITVMA.MIT.EDU> at
Internet
Date:    6/23/98 2:09 PM


On Tue, 23 Jun 1998, Mike Keitz wrote:

{Quote hidden}

I thought that I'd seen simple (no IC's or active components, just wires)
adapters to go between a serial mouse and a PS/2 bus mouse port. If what
you are saying is true, how can a simple adaptor convert an asynchronous
signal to a bi-directional synchronus signal? I could be wrong, its just
that I seem to remember these adaptors.

THanks,

Sean


{Quote hidden}

'[OT] Using a mouse as a cheap incremental encoder?'
1998\06\23@155545 by Brian Whittaker

flavicon
face
Hi Charles & Larry

Cool Web site but what is not said is the output waveform
from the detector section is 2-bit quadriture as follows

        clockwise rotation
     .---.   .---.   .---.
[a]___|   |___|   |___|   |___

   .---.   .---.   .---.   .-
[b]_|   |___|   |___|   |___|

    counter-clockwise rotation
   .---.   .---.   .---.   .-
[a]_|   |___|   |___|   |___|

     .---.   .---.   .---.
[b]___|   |___|   |___|   |___

Each mouse will have 4 outputs 2 for horizontal and
2 for vertical

Counting the transitions of both outputs and adding them
together doubles the counts per revolution

Detecting which output leads ( which goes positive first )
will tell you which direction you are turning

Please excuse the commercialism but the company I work for
sells mouse guts made by Logitech. They simply buffer the
quaditure waveforms with a ttl inverter and sends them to
the computer.

The small pcb has all of its parts including mounted encoder
wheels and micro switches. All that is missing is the cable
and case. Schematics are included. Price is 2 for $5 + S/H
>{Original Message removed}

1998\06\23@222146 by Louis Marquette

flavicon
face
Sean Breheny wrote:

{Quote hidden}

they exist, i have one, it is a ps2 to rs232 converter. it does not seem to
work though, when i plug my trackball into it and then plug it into my rs232
port(com1) it is not recognised, but trackball works when i plug it into rs232
port. maybe it only eorks for mice, not trackballs

{Quote hidden}

1998\06\24@151252 by Leon Heller

flavicon
picon face
In message <spamBeGonePine.SOL.3.91.980623140529.23306A-100000STOPspamspamEraseMEtravelers.mail.corn> ell.edu>, Sean Breheny <KILLspamshb7spamBeGonespamCORNELL.EDU> writes
{Quote hidden}

I think that Charlos's best bet is to just use one of the encoders and
forget about the mouse electronics. It will generate an in-phase and
quadrature signal which can be sorted out with software or hardware to
get the required direction and count information.

Leon
--
Leon Heller: @spam@leon@spam@spamspam_OUTlfheller.demon.co.uk http://www.lfheller.demon.co.uk
Amateur Radio Callsign G1HSM    Tel: +44 (0) 118 947 1424
See http://www.lfheller.demon.co.uk/dds.htm for details of a simple AD9850
DDS system. See " "/diy_dsp.htm for a simple DIY DSP ADSP-2104 system.


'TMR0 increment.'
1998\12\16@225543 by netquake
flavicon
face
HI!

I would appreciate if someone could tell me how
should I set OPTION and TRIS registers (and also
the configuration word) to let TMR0 (GP2) increment
on each pulse (low-to-high transition) of an external
clock signal applied to GP2 (on a 1:1 basis).
PIC is a 12C508, WDT is not necessary in my code and
I use 4Mhz internal oscillator.
I've already tried and cannot get an increment in
MPLAB's simulator.

My settings:
       movlw   0xe8    ;set OPTION register 00110 100
       OPTION
       movlw   0xfe    ;set GPIO i/o port directions / GP0 output
       TRIS    GPIO

Thank you!

-----------------------------------------------------
"Hiroshima '45  Tsjernobyl '86 ... Windows '95"
Windows 95: n. 32 bit extensions and a graphical
shell for a 16 bit patch to an 8 bit operating system
originally coded for a 4 bit microprocessor, written
by a 2 bit company...

netQ
<spamBeGonenetquakespamKILLspaminnocent.com>


'range comparison (was Re: Increment/Decrement "w")'
1999\06\30@154540 by Eric Smith
flavicon
face
John Pfaff <.....pfaffspam_OUTspamWRITEME.COM> wrote:
> ...and yes, it does work.

Walter Banks <TakeThisOuTwalter.....spamTakeThisOuTBYTECRAFT.COM> wrote:
> It works for all values of Hi and Lo except 255 and 0.

It works even for those values.  However, it is not the optimal
instruction sequence for such cases.

In fact, it even works for ranges that wrap around 255 back to 0.  For
instance, if you set Lo to 240 and Hi to 15, it will match 0..15 and also
240..255.

And it works for signed numbers.  You can set Lo to -3 and Hi to 5 to
match -3..+5.

The only requirement is that your assembler must truncate literals to
eight bits.  If not, you can still use it by masking the literals yourself:

       addlw (255 - Hi) & 0ffh
       addlw ((Hi - Lo) + 1) & 0ffh

Previously when I jokingly wrote:
> That can't possibly work!  There aren't enough instructions!  And I
> refuse to try it out to see if it works, since I know I'm right!
I forgot to include the other (incorrect) criticism that this code
often receives, which is that it can't work because the carry resulting
from the first addlw gets lost.


'32-bit increment challenge'
1999\08\24@230959 by Dan Larson
flavicon
face
Does anybody see any problem with the following
32-bit increment, other than it not being
isosynchronous ?

; 32-bit increment-------------------

      INCFSZ   COUNT_0,F     ;  LSB
      GOTO     DONE          ;
      INCFSZ   COUNT_1,F     ;
      GOTO     DONE          ;
      INCFSZ   COUNT_2,F     ;
      GOTO     DONE          ;
      INCF     COUNT_3       ;  MSB
DONE:

;------------------------------------

I am also looking for a 32-bit add, subtract,
and compare snippets.  The subtract could be
used for the compare if Z is valid after the
subtract.

Dan

1999\08\25@103012 by Scott Dattalo

face
flavicon
face
On Tue, 24 Aug 1999, Dan Larson wrote:

> Does anybody see any problem with the following
> 32-bit increment, other than it not being
> isosynchronous ?
>
> ; 32-bit increment-------------------
>
>        INCFSZ   COUNT_0,F     ;  LSB
>        GOTO     DONE          ;
>        INCFSZ   COUNT_1,F     ;
>        GOTO     DONE          ;
>        INCFSZ   COUNT_2,F     ;
>        GOTO     DONE          ;
>        INCF     COUNT_3       ;  MSB
> DONE:

If you wish to make it isochronous:

 incf   count_0,f
 skpnz
  incf  count_1,f
 skpnz
  incf  count_2,f
 skpnz
  incf  count_3,f

On the 18cxxx parts you could do this:

 infsnz count_0,f
  incf  count_1,f
 skpnz
  incf  count_2,f
 skpnz
  incf  count_3,f

or
 clrf   wreg
 setc
 addwfc count_0,f
 addwfc count_1,f
 addwfc count_2,f
 addwfc count_3,f

Scott


'Quardature incremental pot decoding on PIC16C54'
1999\10\01@113543 by email
flavicon
picon face
Has anyone any code for decoding the pair of quadrature signals from an
incremental digital pot on a PIC16C54

Ideally I also want to build and acceleration characteristic into the signal
treatment. i.e. If the pot is turned continuously for more than 2 seconds
the rate of increment is increased.

Tim

'Reading Quadrature Incremental Encoders'
1999\10\01@120951 by Randy A.

picon face
Does anyone have information regarding how to read the Quadrature signals
from an incremental encoder such as those used for feedback loops on servo
motors on CNC machinery.  In fact I am working on a low cost controller for a
single axis machine.

Any and all suggestions will be GREATLY appreciated.

Randy A.

1999\10\01@135935 by Steve Kelley

picon face
Randy . . . .
Not sure how much info. you need , but it would most likely be using * two *
photosensors , with a single encoder disc . . . it would use one sensor for
the position and the other sensor is slightly offset ( in the encoder cut-out ).
The dual encoder disc would use two sensors and the offset would be
produced by the offset angle of the second disc.  The direction of movement
can be determined by the pulse that is seen first , while the disc travels.
Most setups rely on the difference in the phase of the two pulses , I like to
think of it as simular to a doppler shift , but mechanical .  If you need details
or designs . . . .please email offline . . .

Regards . . .
                       Steve Kelley

{Original Message removed}

'Quardature incremental pot decoding on PIC16C54'
1999\10\01@165910 by Morgan Olsson

picon face
Hej Tim Craig. Tack fšr ditt meddelande 16:33 1999-10-01 +0100 enligt nedan:
>Has anyone any code for decoding the pair of quadrature signals from an
>incremental digital pot on a PIC16C54

Generally,

Get the two phase bits

Together with the two bits from the last read form a 4-bit word

Use this for a 16 entry goto table

The table will contain 4 each of gotos for count up, count down, no change (glitch) and error (both phase changed, probably overspeed).

An easy way of getting the bits right is to left rotate them into a register, then mask using andlw 1111b before addwf PCL.  Save the register until next call to this routine.

Interrupt on change is excellent for getting an interrupt on any change.

But the routine can also be called anytime as it will handle no change too.

I did this on a F877 this week, using interrupt on change  :)

It did reach 13kHz+ count and at the same time 4kHz timer 0 int driving some software timers etc, using 4,096 MHz xtal and 2-level interrupt structure.
(Interrupt get what happened / Interrupt post service with interrupt re-enabled (soft timers, safety checks, buffers, etc) / Main prog)

...wait I'll dump the 2-phase decoder right here... there is some macros, i.e ifc=if clear then execute next instruction = Mchip btfss.  there are also some debug macros DEBUGsomething, 16-bit count variable is named W_something...

But I think you will get the idea.
I«ll threw in a few english words...
Enjoy!

----8<----

        ifc             INTCON,RBIF             ;Har porttillstŒndet Šndrats?
          goto  isrP_NoRBIF             ;Om inte: hoppa till nŠsta kollrutin

;LŠs in nya tillstŒndet
        movf    PORTB,w                 ; *** Ingen annanstans fŒr PORTB lŠsas dierkt! ***
        c               INTCON,RBIF             ;Kvittera att vi har lŠst
        movwf   B_PORTBIN               ;lagra fšr denna samt andra rutiner pŒ port B

;Bearbeta tvŒfassignal genast!
;HŠmta fasbitarna frŒn B_PORTBIN till B_2phState 1:0, de fšrra i 3:2...
        cc                              ;Rotate the new bits in...
        ifs             B_PORTBIN,5
          sc
        rlf             B_2phState,f
        cc
        ifs             B_PORTBIN,4
          sc
        rlf             B_2phState,f
        movf    B_2phState,w
        andlw   b'1111'
        addwf   PCL,F           ;Before Now     don«t care this below

        goto    isrBchange_NO   ; 0 0   0 0             00      00
        goto    isrBchange_UP   ; 0 0   0 1             01      10
        goto    isrBchange_DN   ; 0 0   1 0             10      01
        goto    isrBchange_ERR  ; 0 0   1 1             11      11

        goto    isrBchange_DN   ; 0 1   0 0             01      01
        goto    isrBchange_NO   ; 0 1   0 1             00      11
        goto    isrBchange_ERR  ; 0 1   1 0             11      00
        goto    isrBchange_UP   ; 0 1   1 1             10      10

        goto    isrBchange_UP   ; 1 0   0 0             10      10
        goto    isrBchange_ERR  ; 1 0   0 1             11      00
        goto    isrBchange_NO   ; 1 0   1 0             00      11
        goto    isrBchange_DN   ; 1 0   1 1             01      01

        goto    isrBchange_ERR  ; 1 1   0 0             11      11
        goto    isrBchange_DN   ; 1 1   0 1             10      01
        goto    isrBchange_UP   ; 1 1   1 0             01      10
;       goto    isrBchange_NO   ; 1 1   1 1             00      00
isrBchange_NO
;       DEBUGIND_const 4        ; TEST <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
        s               F_2phGlitch     ;Indikera "glitch"      GLITCH?
        ;ev godkŠnna glitch?  NŠe; lšs ut = prioritera sŠkerhet
isrBchange_ERR
        DEBUGIND_const 5        ; TEST <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
        s               F_2phSpeed      ;Indikera "šverfart"  OVERSPEED
        goto    isrP_2phEnd
       
isrBchange_UP
        INC2    W_2phcnt
        ifzc
          goto isrP_2phEnd
        s               F_2phRange      ;Indikera "utanfšr skala"
        comf    W_2phcnt,f      ;€ndra 0000h till FFFFh
        comf    W_2phcnt+1,f
;       DEBUGIND_const 7        ; TEST <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
        goto    isrP_2phEnd

isrBchange_DN
        FDEC2   W_2phcnt
        comf    W_2phcnt+1,W    ;€r hšgbyten annat Šn FF sŒ Šr det OK
        ifzc                                    ;AlltsŒ: Šr ettkomplementet annat Šn 0?
          goto isrP_2phEnd              ;I sŒ fall OK!
        comf    W_2phcnt,W      ;Annars kolla lŒgbyten likadant...
        ifzc
          goto isrP_2phEnd
                                                ;Om wrappade till FFFF:
        s               F_2phRange      ;Indikera "utanfšr skala"
        clrf    W_2phcnt        ;nollstŠll rŠknaren..
        clrf    W_2phcnt+1      ;

;       DEBUGIND_const 6        ; TEST <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

isrP_2phEnd

;       DEBUGIND_low4 W_2phcnt  ; TEST <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
       
isrP_NoRBIF

        DEBUGIND_const 4;Int on change klar <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


Morgans Reglerteknik, HŠllekŒs, 277 35 KIVIK, SWEDEN
  tel +46(0)414-446620, fax -70331,   TakeThisOuTmrtKILLspamspamspaminame.com

1999\10\01@201055 by Matthew Ballinger

picon face
   Or a much more efficient routine would be (in parallax mnemonics):
ChkEncoder  mov new,encoder ;move the ra port the new var
               and     new,#00000011   ;clear all but encoder bits
               mov temp, new
               xor     temp,old        ;is old and new same?
               jz      :Return         ;if so quit
               clc                     ;clear carry
               rl      old             ;shift old to align old.0 with new.1
bit
               xor     old,new         ;xor bits to determine direction
               jb      old.1,:up       ;if bit is 1 then up (CW,etc), if bit
is 0 then down (ccw,etc)


In a message dated 10/1/99 4:59:48 PM Eastern Daylight Time,
.....morgans.rtspamRemoveMETELIA.COM writes:

{Quote hidden}

register,
>  then mask using andlw 1111b before addwf PCL.  Save the register until
next
> call to this routine.
>  
>  Interrupt on change is excellent for getting an interrupt on any change.
>  
>  But the routine can also be called anytime as it will handle no change too.
>  
>  I did this on a F877 this week, using interrupt on change  :)
>  
>  It did reach 13kHz+ count and at the same time 4kHz timer 0 int driving
some
> software timers etc, using 4,096 MHz xtal and 2-level interrupt structure.
>  (Interrupt get what happened / Interrupt post service with interrupt re-
> enabled (soft timers, safety checks, buffers, etc) / Main prog)
>  
>  ...wait I'll dump the 2-phase decoder right here... there is some macros,
i.
> e ifc=if clear then execute next instruction = Mchip btfss.  there are also
> some debug macros DEBUGsomething, 16-bit count variable is named
W_something..
{Quote hidden}

rutiner
{Quote hidden}

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> <
>           s               F_2phGlitch     ;Indikera "glitch"      GLITCH?
>           ;ev godkŠnna glitch?  NŠe; lšs ut = prioritera sŠkerhet
>  isrBchange_ERR
>           DEBUGIND_const 5        ; TEST
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
{Quote hidden}

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> <
>           goto    isrP_2phEnd
>  
>  isrBchange_DN
>           FDEC2   W_2phcnt
>           comf    W_2phcnt+1,W    ;€r hšgbyten annat Šn FF sŒ Šr det OK
>           ifzc                                    ;AlltsŒ: Šr
ettkomplementet
{Quote hidden}

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> <
>  
>  isrP_2phEnd
>  
>  ;       DEBUGIND_low4 W_2phcnt  ; TEST
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> <
>          
>  isrP_NoRBIF
>  
>           DEBUGIND_const 4;Int on change klar

1999\10\02@034438 by Morgan Olsson

picon face
Matthew Ballinger wrote:
>     Or a much more efficient routine
Yes less instructions, but I have hard to see if it can beat an "addwf PCL" in decode speed, once the input bits are retrieved, and we also have to store them for next time.
But I will try your suggestion too.

{Quote hidden}

And then wee need to rotate the other way to align the other bits and xor them to see if it was up.
And if neither up or dn, and not same, both bits changed = overspeed or error.

Did I get it right?

/Morgan


Morgans Reglerteknik, HŠllekŒs, 277 35 KIVIK, SWEDEN
  tel +46(0)414-446620, fax -70331,   RemoveMEmrtspamspamBeGoneiname.com

'Reading Quadrature Incremental Encoders'
1999\10\02@041422 by Alvaro Deibe Diaz

flavicon
face
Hi Randy

I've posted this code several times in this list, and got no comments on it.
I hope this help you

; Encoder read
#define encx    PORTA,1    ; Encoder inputs
#define ency    PORTA,2
;
;
; Inic (usually needless)
       clrf    auxint     ; Clear aux var
       btfsc   encx       ; and get encoder inputs
       bsf     auxint,0   ; in bit 0...
       btfsc   ency
       bsf     auxint,1   ; ...and 1
;
; Here starts the hard work
       movf    auxint,W   ; encod <- (actual state) xor (previous one)
       xorwf   encod,F    ; (only bits 0 and 1 affected)
;
       rrf     auxint,F   ; XOR results, reordered, get
       rlf     encod,F    ; into encod, in bits 0 and 1.
       rrf     auxint,F   ; This bits are the motion indicators
       rlf     encod,F
;
At this point you have a new read of the encoder. Bits 2 and 3 of 'encod'
have the information about the direction of movement of the encoder. If you
have to translate this information into a variable, then you can do
something like this:
;
       btfsc   encod,2    ; Direction 'X' motion
       incf    posenc,F
       btfsc   encod,3    ; ...or 'Y'
       decf    posenc,F
;
Bits 4,5 and 6,7 of 'encod' have the previous reads.

I place this routine in an time based interrupt (about 20ms time period).
The frequency of the interruption have to deal with the speed of the
incoming changes in the encoder signals.

Hope this helps,

çlvaro.

----- Mensaje original -----
De: Randy A. <spamBeGoneCnc002@spam@spamspam_OUTAOL.COM>
Para: <TakeThisOuTPICLISTspamspamMITVMA.MIT.EDU>
Enviado: viernes, 01 de octubre de 1999 18:08
Asunto: Reading Quadrature Incremental Encoders


> Does anyone have information regarding how to read the Quadrature signals
> from an incremental encoder such as those used for feedback loops on servo
> motors on CNC machinery.  In fact I am working on a low cost controller
for a
> single axis machine.
>
> Any and all suggestions will be GREATLY appreciated.
>
> Randy A.
>

1999\10\02@093548 by Randy A.

picon face
Alvaro:

I do believe that the code you posted will help me.  I am fairly new to the
PICs but have determined that they are a much more cost effective way and
that they perform much faster than a "STAMP".  Therefore I am attempting to
use them in a controller for a single axis CNC application.

Thanks for the reply.

Randy A.

'Quardature incremental pot decoding on PIC16C54'
1999\10\02@222512 by Matthew Ballinger

picon face
In a message dated 10/2/99 3:46:23 AM Eastern Daylight Time,
morgans.rtEraseMEspamTELIA.COM writes:

> Matthew Ballinger wrote:
>  >     Or a much more efficient routine
>  Yes less instructions, but I have hard to see if it can beat an "addwf
PCL"
> in decode speed, once the input bits are retrieved, and we also have to
store
{Quote hidden}

new.
> 1
>  >bit
>  >                 xor     old,new         ;xor bits to determine direction
>  >                 jb      old.1,:up       ;if bit is 1 then up (CW,etc),
if
> bit
>  >is 0 then down (ccw,etc)
>
>  And then wee need to rotate the other way to align the other bits and xor
> them to see if it was up.
>  And if neither up or dn, and not same, both bits changed = overspeed or
> error.
>
>  Did I get it right?
>
   Not quite. *Everything* is taken care of with this code.
1.If code jumps to :return , then no change in posistion was made.
2.If the final xor produces a 1 then the encoder went CW
3.If the final xor produces a 0 then the encoder went CCW
Nothing more to do. Ok, well, add 1 instruction to store the old bits (oops).
Speed doesn't really suffer either. I'll count the instructions though to be
sure. You may be right.
Matt Ballinger

'Quadrature incremental pot decoding on PIC'
1999\10\03@060811 by Morgan Olsson

picon face
Hej Matthew Ballinger. Tack fšr ditt meddelande 22:22 1999-10-02 -0400 enligt nedan:
{Quote hidden}

Well.. To be safe, the routine has to detect also when both phases has changed (180¡ cycle rotation since last time)  This will indicate overspeed or hardware error, noise or other error.  W often has to now when/if the routine fail so we dont tahe an erroneous cont for correct, especially in machine positioning...

>Ok, well, add 1 instruction to store the old bits (oops).
>Speed doesn't really suffer either. I'll count the instructions though to be
>sure. You may be right.

Take in count that parrallax macros often is more than one instruction.


goto table method cycles:

First get two phase bits into the same byte as the old ones, by rotating them into the storebyte (the previous phase bits then is in bit 2 and 3, and the now new bits will be used as old next call) :  Total 8 cycles

movf storebyte, W       1 cycle
andlw b'1111'           1 cycle
addwf PCL ,f            2 cycles
...
goto appropriate_routine  2 cycles
...

Making total 14 cycles, isosynchronous, including jump to appropriate routine (count up/down/error/nochange)


We may shave off two cycles by redesigning so we have 00xxxx00  to add to PCL, so every entry in the goto table then can be a small routine upto 3 instructions + "goto nextinterruptservice"

Save cycles, but wastes a lot code space.


regards
/Morgan

>Matt Ballinger

Morgans Reglerteknik, HŠllekŒs, 277 35 KIVIK, SWEDEN
  tel +46(0)414-446620, fax -70331,   @spam@mrtRemoveMEspamEraseMEiname.com

1999\10\03@233620 by Matthew Ballinger

picon face
In a message dated 10/3/99 6:08:38 AM Eastern Daylight Time,
EraseMEmorgans.rtspam@spam@TELIA.COM writes:

> Well.. To be safe, the routine has to detect also when both phases has
> changed (180¡ cycle rotation since last time)  This will indicate overspeed
> or hardware error, noise or other error.  

In a hardware error, most likely 1 or both outputs would not change at all.

>W often has to now when/if the
> routine fail so we dont tahe an erroneous cont for correct, especially in
> machine positioning...
>  

ChkEnc  mov new,Enc     ;get new input
   and new,#%00000011  ;get rid of all but 2 enc bits
   mov temp,new    ;make copy
   xor temp,old    ;is old = new
   jz  ChkEnc      ;then no change, go back
   cje temp,#3,err ;goto "error" if both bits changed
   clc         ;get ready for right shift
   rl  Old     ;align bits
   xor old,new     ;check for direction
   jb  old.1,up    ;if 1 then up direction, if 0 then down direction

   Error detected! I use scenix chips at 50-85MHz.The chances of missing a
change are slim, however. As long as it is scanned every 1/(resolution of
encoder*max changes per sec).
Matt Ballinger


'[PICLIST] Increment'
2001\04\17@182556 by David Cary
flavicon
face
Dear PIC assembly language programmers,

I can't help myself. I see someone else's code, and I think -- I could make that
at least 1 instruction shorter.

I saw this code:

; from Dmitry Kiryashov
; piclist.org/techref/microchip/math/incdec/gp.htm
inc24:
       movlw   1
       addwf   count0,F
       skpnc
       addwf   count1,F
       skpnc
       addwf   count1,F
       ;... {ed: repeat the last two lines for as wide a counter as is needed}
       return

Would this work just as well ? Or is there some ``gotcha'' I'm missing ?

; from David Cary
inc24:
    incf count0,f
    skpnz
    incf count1,f
    skpnz
    incf count2,f
    ;... {repeat the last two lines for as wide a counter as is needed}
    return

--
David Cary

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\17@183221 by Scott Dattalo

face
flavicon
face
On Tue, 17 Apr 2001, David Cary wrote:

{Quote hidden}

Yes that works fine. Mike Keitz proposed something like this several years ago,
btw.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\04\17@200035 by Don Hyde

flavicon
face
I usually prefer

       incfsz  count0,f
       return
       incfsz  count1,f
       return
       ... for as wide a counter as desired...

It's not constant-time, but it uses fewer cycles for the most common case
where there's no overflow.

> {Original Message removed}

2001\04\18@032014 by Dmitry Kiryashov

flavicon
face
Hi David. ;)

The reason why I was using addwf instead of incf because
I tried to kept final carry in Cy flag after everything
is done.

And this code can be modified with no efforts for subtraction.
(with decf it is more tricky to do)

You damn right about that every program can be squeezed down
at least by one byte ;)

WBR Dmitry.


David Cary wrote:
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\04\18@191350 by David Cary

flavicon
face
Dear PIC assembly language programmers,

I can't help myself. I see someone else's code, and I think -- I could make that
at least 1 instruction shorter.

I saw this code:

; from Dmitry Kiryashov
; piclist.org/techref/microchip/math/incdec/gp.htm
inc24:
       movlw   1
       addwf   count0,F
       skpnc
       addwf   count1,F
       skpnc
       addwf   count1,F
       ;... {ed: repeat the last two lines for as wide a counter as is needed}
       return

Would this work just as well ? Or is there some ``gotcha'' I'm missing ?

; from David Cary
inc24:
    incf count0,f
    skpnz
    incf count1,f
    skpnz
    incf count2,f
    ;... {repeat the last two lines for as wide a counter as is needed}
    return

--
David Cary

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\04\19@084809 by Drew Vassallo

picon face
>I can't help myself. I see someone else's code, and I think -- I could make
>that
>at least 1 instruction shorter.
>
>I saw this code:
>; from Dmitry Kiryashov

Trying to reduce *Dmitry's* code??? That's blasphemy!

>Would this work just as well ? Or is there some ``gotcha'' I'm missing ?
>
>; from David Cary
>inc24:
>      incf count0,f
>      skpnz

I'm not sure, but I thought that "incf" didn't exist on 12-bit cores.  Maybe
I'm wrong, though; it just seems that Dmitry wouldn't miss so simple a
reduction.

--Andrew

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.



'[PIC]: Jump table, increment of counter question'
2002\01\01@165306 by Lasse Madsen
flavicon
face
Dear Sirs

I've found a nice serial routine on the internet which I would like to modify to work with a program which I have written

my program consists of 8 subroutines called
nr1
nr2
....
nr8

The serial code < http://www.mastincrosbie.com/mark/electronics/pic/io.html > which I found to be working fine.

It turns off a LED when an ASCII "0" is sent to it and turns it on when an ASCII "1" is send.

As im not so good with assembler programming (Easy Pic'n skills only) I hope some of you guys can help me.
I have an idea which may be stupid but I may be "usable" here it goes

The serial code works like this:

; See if the character is 0, if so, turn off the LED
movf INCHAR, w
sublw '0'
btfsc STATUS, Z
bcf PORTB, LED_BIT ; turn off the LED
btfss STATUS, Z
bsf PORTB, LED_BIT ; turn on the LED

My idea is to make 2 subroutines which is called insted of turning on or off the led like this:

; See if the character is 0, if so, turn off the LED
movf INCHAR, w
sublw '0'
btfsc STATUS, Z
call subtract1
btfss STATUS, Z
call increase1

And the 2 routines "Subtract1" and "Increase1" will modify a counter by either increasing it or decreasing it
and then lookup the current count and fetch my subroutine which is equal to the count
For instance if the counter has advanced to 3 it calls my subroutine "nr3"

To advance the counter one must send as many "1"'s as one wants the counter to advance to and to decrease the counter one sends as many "0"'s as needed


Am I approaching this from the wrong angle ?
Best Regards
Lasse Madsen

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestspam_OUTspam.....mitvma.mit.edu


2002\01\01@171421 by Jinx

face picon face
> And the 2 routines "Subtract1" and "Increase1" will modify a
> counter by either increasing it or decreasing it and then lookup
> the current count and fetch my subroutine which is equal to the
> count

> For instance if the counter has advanced to 3 it calls my
> subroutine "nr3"

> To advance the counter one must send as many "1"'s as one
> wants the counter to advance to and to decrease the counter
> one sends as many "0"'s as needed

If you do it that way you'll need to tell the PIC how many 0s or 1s
to expect, or either send an end-of-file byte or use a timeout to
tell the program that the transmission is over

Say you want the counter to increase by 4, you'd send 4 1s. But
the program would increase the counter and then execute nr1,
even though there are still 3 1s pending

As you have just 8 routines, how about using the 8 bits of one
byte of transmitted data to either increment/decrement the
counter or find out the subroutine address ?

For example, if the first bit is 0, decrement the counter by however
many 0s follow (up to 8). If the first bit is 1, then increment the counter
by however many 1s follow. You can expand this over more bytes
if you add more subroutines

data received = 00001111, decrement counter by 4 (stop
decrementing as soon as the first 1 bit is detected) and do
the same but opposite for a leading 1

or

data received = 00000100 = jump to subroutine nr6

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestEraseMEspammitvma.mit.edu


2002\01\01@172643 by Jinx

face picon face
> data received = 00000100 = jump to subroutine nr6

Tut-tut, forgot the most obvious one

data received = 00000110 = 6

simply add to PCL and jump, like you would for any
normal table

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamBeGonespammitvma.mit.edu


2002\01\01@173934 by Jinx

face picon face
> data received = 00001111, decrement counter by 4 (stop
> decrementing as soon as the first 1 bit is detected) and do
> the same but opposite for a leading 1

Alternatives that would save time and code -

data received = 0xxxxxxx, decrement counter by up to 127

data received = 1xxxxxxx, increment counter by up to 127

data received = bbbbbbbb, jump to nr(x), where x=1 to 255

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-request@spam@spamspamBeGonemitvma.mit.edu


2002\01\01@175835 by Bob Barr

flavicon
face
On Tue, 1 Jan 2002 22:51:03 +0100, Lasse Madsen wrote:

{Quote hidden}

I'm not sure what you mean by 'send as many "1"s as one wants' but you
may want to consider using the 'addwf PCL, f' instruction.
In its simplest form (no bank check, no range check), it would look
something like this:

   movfw    INCHAR, w
   sublw    '0'
   addwf    PCL, f    ; this branch 'vectors' into the table


   goto    LED_off    ; here if INCHAR was '0'
   goto    LED_on   ; here if INCHAR was '1'
   goto    Func        ; here if INCHAR was '2'

;   additional vectors for '3' through '9' go here in sequence


LED_off:
 .
 .
   goto  Done

LED_on:
 .
 .
   goto Done


Func:
 .
 .
Done:

; code continues here



Two cautions:  
1) All of the entries in the table must be located in the same page of
memory. An overflow generated from adding to PCL doesn't propogate
into the higher bits of the PC register. (I've seen a way to check
this at assembly time but I don't have it handy right now and I can't
seem to recall it offhand.)

2) All possible INCHAR values must have a corresponding 'goto'
instruction in the table. Any unexpected INCHAR value will branch you
off into never-never land. You need to ensure that you've got an ASCII
digit ('0' through '9') before you get to this code.


Regards, Bob

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-request@spam@spamEraseMEmitvma.mit.edu



'[PIC]: incrementing in steps'
2002\06\05@164028 by Gordon Varney
flavicon
face
I need a pin to clock out a square wave at 800Hz. Simple, just set pin high for 625us, set pin low for 625us, and
repeat.

Now I need to increment the clock frequency by 50Hz, do some work and increment by 50Hz again, continue incrementing
until complete. The step duration in a time period is not a constant. What is the best method to incrementing the
frequency by 50Hz.

(Note: I am using a combination of Assembly and the CCS compiler for this program.)

Gordon Varney
http://www.iamnee.com

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestRemoveMEspammitvma.mit.edu


2002\06\05@172659 by Gordon Varney

flavicon
face
sorry for the bother, I got this one...:-)

    frequency=800;     //Starting value
    freq_dur=(1/frequency)/2;

Sometimes it is right in front of your nose and your can't see it.

Also, 4 hours of sleep last night can make things fuzzy.

Gordon Varney
http://www.iamnee.com


{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam@spam@mitvma.mit.edu


2002\06\05@173106 by Lawrence Lile

flavicon
face
Gordon,

I've sent you an excel spreadsheet under separate cover in oorder to not
post a big attachemtn to the list.

Here is the idea:  Teach Excel to do some of your work for you.  The
spreadsheet does the following:

1.  Calculates 1/F,  1/F / 2, and converts it to microseconds, which is the
same as machine cycles in a 4mHz PIC.

2. Formats this info into an array:    int16 freqlookup[] = { 625, 588, etc
etc };  << All this tedious symtax is generated inside Excel

3.  Now cut and paste the array into your C code

4. Place it in a constant table like this:

BYTE CONST freqlookup[] = { 625, 588, etc etc };
warning, this works in CCS C, may not in Hitech

5.  Use it in your code like this:

freqlookup[5];


6.  Stuff this number into a timer preset, say you are using timer2, preset
Timer2 with 65535 - freqlookup[x], where x is incremented each timer
interrupt.

This is all off the top of my head, YMMV.

--Lawrence

{Original Message removed}

2002\06\05@173527 by Lawrence Lile

flavicon
face
Oh well, I had a cool trick anyway.  Teaching Excel to format a big long
string of numbers and write code for your is a neat trick, keep it around.

--Lawrence

{Original Message removed}

'[PICLIST] (Re: [PIC]: incrementing in steps'
2002\06\05@223529 by Bob Ammerman

picon face
Gordon,

You can do this with a 1-bit output direct-digital synthesis technique.


Given the following variables:

unsigned long increment_value;
unsigned long phase_accumulator;

for (some number of iterations)
{
   phase_accumulator += increment_value;

   // copy hi bit of phase_accumulator to output pin
   // code could look something like:
   movf    output_port,W               ; get existing port bit
   andlw    ~(1 << output_bit)       ; turn off current value
   btfsc     phase_accumulator;      ; is high bit on?
   iorlw     1 << output_bit            ; yes: turn the bit on
   movwf   output_port                 ; send it back to the hardware
}

The output frequency is directly proportional to 'increment_value'.

Bob Ammerman
RAm Systems


{Original Message removed}

2002\06\05@235351 by Scott Dattalo

face
flavicon
face
On Wed, 5 Jun 2002, Bob Ammerman wrote:

{Quote hidden}

A simpler way is to toggle the output everytime the phase accumulator
rolls over:

    movf    increment_value,w
    addwf   phase_accumulator,f     ; or better, a 16-bit phase acc.
    movlw   1<<output_bit
    skpnc
     xorwf  output_port,f           ;rmw, oh well.


If you're worried about read-modify-writes to an I/O pin, then do this:

    movf    increment_value,w
    addwf   phase_accumulator,f     ; or better, a 16-bit phase acc.

    movlw   1<<output_bit
    xorwf   output_port,w
    skpnc
     movwf  output_port


Note that monitoring the carry gives you an extra bit too. (But, you're
counting on the I/O line to accurately retain the state.)

Scott

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamspamBeGonemitvma.mit.edu


'[PIC]: incrementing in steps'
2002\06\06@033204 by Vasile Surducan

flavicon
face
Use the PWM for frequency generation, change the pr2 (period) and t2con
values ( prescaler ) for 50Hz incrementation.

regards,
Vasile
http://www.geocities.com/vsurducan


On Wed, 5 Jun 2002, Gordon Varney wrote:

> I need a pin to clock out a square wave at 800Hz.
Simple, just set pin high for 625us, set pin low for 625us, and
> repeat.
>
> Now I need to increment the clock frequency by 50Hz,
do some work and increment by 50Hz again, continue incrementing
> until complete. The step duration in a time period is not a constant.
What is the best method to incrementing the
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\06\06@081308 by Olin Lathrop

face picon face
> I need a pin to clock out a square wave at 800Hz. Simple, just set pin
high for 625us, set pin low for 625us, and
> repeat.
>
> Now I need to increment the clock frequency by 50Hz, do some work and
increment by 50Hz again, continue incrementing
> until complete. The step duration in a time period is not a constant. What
is the best method to incrementing the
> frequency by 50Hz.

It depends on the frequency resolution you need and the highest frequency of
interest.  800Hz is slow enough that this is easy to do with a timer
interrupt.  Timer 1 would be easiest because a CCP module can be used to
provide a 16 bit period value.  For higher frequencies, the PWM hardware
might be more suitable.  As the frequency gets higher, the resolution will
go down because all these methods devide the instruction clock by an
integer, and the integer values get small at high frequencies.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads



'[EE]: 5 cent incremental cost modem'
2003\02\13@061559 by Russell McMahon
face
flavicon
face
A somewhat misleading title.
Good and long article discusses the addition of 300 baud full duplex modem
solely in software on a PSOC CPU. Incremental hardware cost is a few cents
(apart from the external DAA :-( ).

       http://www.planetanalog.com/features/OEG20030212S0053

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


'[PIC:] Fastest/Best Increment and Decrement for 18'
2004\10\20@174145 by Robert James Kaes
flavicon
face
Hi Everyone,
I'm trying to work out the best and fastest method of incrementing a
multibyte variable.  I'm only treating the 18C family, so I can use
the expanded instruction set of the 18C.  The numbers are stored in
little endian format (lowest byte first.)  Are the following the best
routines in the term of the amount of code memory used, and also the
fastest for the common case?  (The common case being when there is no
overflow or underflow in the first byte.)

Increment:

 ;; 16 bit word
 infsnz reg, F
 incf reg + 1, F

 ;; 24 bit word
 clrf WREG
 incf reg, F
 addwfc reg + 1, F
 addwfc reg + 2, F

 ;; 32 bit word
 clrf WREG
 incf reg, F
 bnc _out  ; branch if no overflow, the common case
 addwfc reg + 1, F
 addwfc reg + 2, F
 addwfc reg + 3, F
_out:


Decrement:

 ;; 16bit word
 clrf WREG
 bcf STATUS, C
 subwfb reg, F
 subwfb reg + 1, F

 ;; 24 bit word
 clrf WREG
 bcf STATUS, C
 subwfb reg, F
 subwfb reg + 1, F
 subwfb reg + 2, F

 ;; 32 bit word
 clrf WREG
 bcf STATUS, C
 subwfb reg, F
 bc _out ; branch for the common case of no underflow
 subwfb reg + 1, F
 subwfb reg + 2, F
 subwfb reg + 3, F
_out:

Thank you for any help or insight you can provide into this problem.
       -- Robert

--
Robert James Kaes
WormBytes Consulting and Contracting
http://www.wormbytes.ca/
____________________________________________

2004\10\20@184528 by olin_piclist

face picon face
Robert James Kaes wrote:
>   ;; 32 bit word
>   clrf WREG
>   incf reg, F
>   bnc _out  ; branch if no overflow, the common case
>   addwfc reg + 1, F
>   addwfc reg + 2, F
>   addwfc reg + 3, F
>  _out:

The CLRF WREG should go after the BNC.  You should also add bank switching,
or a comment that warns that the bank must already be set properly for
access to REG, and that all bytes of the number must be in the same bank.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\10\20@203058 by Scott Dattalo

face
flavicon
face

Robert,

The increment routines you posted are efficient. The only optimization I
see is for the 32-bit increment:

>  ;; 32 bit word
>  clrf WREG
>  incf reg, F
>  bnc _out  ; branch if no overflow, the common case
>  addwfc reg + 1, F
>  addwfc reg + 2, F
>  addwfc reg + 3, F
> _out:


  ;; 32 bit word
  incf reg, F
  bnc _out  ; branch if no overflow, the common case
  clrf WREG
  addwfc reg + 1, F
  addwfc reg + 2, F
  addwfc reg + 3, F
_out:

In other words, there's no need to clear W if there's no carry.

For the Decrements, I see a few optimizations:

> Decrement:
>
>  ;; 16bit word
>  clrf WREG
>  bcf STATUS, C
>  subwfb reg, F
>  subwfb reg + 1, F

   tstfsz reg
    decf  reg+1
   decf   reg,F



>  ;; 24 bit word
>  clrf WREG
>  bcf STATUS, C
>  subwfb reg, F
>  subwfb reg + 1, F
>  subwfb reg + 2, F

;; 24 bit word
   decf   reg,F
   bc     _out
   clrf   WREG
   subwfb reg + 1, F
   subwfb reg + 2, F
_out:

{Quote hidden}

;; 32 bit word
   decf   reg,F
   bc     _out
   clrf   WREG
   subwfb reg + 1, F
   subwfb reg + 2, F
   subwfb reg + 3, F
_out:


These are untested.

Scott
____________________________________________

2004\10\20@210150 by Ken Pergola

flavicon
face

Hi Robert,

Let's just take a look at the 24-bit increment example:


This method below will be approximately 14% faster than the method you
posted *if* you iterate 'Count' 16,777,216 times, from 0x000000 to 0x000000
(rollover condition):



     .
     .
     .

Increment:

   INCFSZ  Count, F        ; Increment LSB of 24-bit data variable
   BRA     EndOfIncrement  ; If no further increments are necessary,
                             bail out early to save clock cycles

   INCFSZ  Count + 1, F    ; Increment MID byte of 24-bit data variable
   BRA     EndOfIncrement  ; If no further increments are necessary,
                             bail out early to save clock cycles

   INCF    Count + 2, F    ; Increment MSB byte of 24-bit data variable

EndOfIncrement

     .
     .
     .


I would not say my method is the fastest or the bestest (poetic license
intended), but it's just another angle to consider.


Preconditions:

1) Count = 0x000000

2) Banking is not necessary.


Comparison of your method and my method is on the basis that the 'Increment'
section will be invoked 16,777,216 times.


Best regards,

Ken Pergola


____________________________________________

2004\10\21@005921 by Robert James Kaes

flavicon
face
On Wed, 20 Oct 2004, Scott Dattalo wrote:
> In other words, there's no need to clear W if there's no carry.

Thanks for the insight.

{Quote hidden}

Does this version work correctly?  Maybe I'm missing something but if I
currently have 0x0100 as:

 reg = 0x00
 reg + 1 = 0x01

The TSTFSZ instruction will test reg as being zero, skip the next
instruction and then decrement reg leaving me with 0x01ff:

 reg = 0xff
 reg + 1 = 0x01

instead of what I would think to be correct as 0x00ff:

 reg = 0xff
 reg + 1 = 0x00

Am I missing something in the instruction set?

One other question: does the decf instruction actually update the carry
bit?  The data sheet implies that the carry bit is affected by the decf
instruction, but it doesn't actually show an example of decreasing a
register already at zero.  Also, the gpsim program doesn't seem to
change the carry bit when doing a decf.  Is that a bug in the program,
or do 18Cs not update the carry for decf instructions?

Thank you for your help.
       -- Robert

--
Robert James Kaes
WormBytes Consulting and Contracting
http://www.wormbytes.ca/
____________________________________________

2004\10\21@012902 by Ken Pergola

flavicon
face

Hi Robert,


Similarly to what I posted for incrementing, you can also improve (by saving
clock cycles) your decrement routines as well:


      .
      .
      .

Decrement:

       ; *** Decrement composite 24-bit 'Count' variable by 1

       DECF        Count, F         ; Decrement LSB of 24-bit data variable.
     BC    EndOfDecrement   ; If no further decrements are necessary, bail
                            ; out early (to save clock cycles).

       DECF        Count + 1, F     ; Decrement MID of 24-bit data variable.
     BC    EndOfDecrement   ; If no further decrements are necessary, bail
                            ; out early (to save clock cycles).

       DECF        Count + 2, F     ; Decrement MSB of 24-bit data variable.

EndOfDecrement

   ; ***
      .
      .
      .




Best regards,

Ken Pergola


















____________________________________________

2004\10\21@015218 by Scott Dattalo

face
flavicon
face
On Wed, 20 Oct 2004, Scott Dattalo wrote:

> For the Decrements, I see a few optimizations:
>
>> Decrement:
>>
>>  ;; 16bit word
>>  clrf WREG
>>  bcf STATUS, C
>>  subwfb reg, F
>>  subwfb reg + 1, F
>
>   tstfsz reg
>    decf  reg+1
>   decf   reg,F

That one's wrong! I should've used the tstfsnz, but that mnemonic has too
many letters and therefore it's invalid :). Here, this is still 3
instructions and works

  decf  reg, F
  skpc
   decf reg+1,F

Or:

  decf  reg, F
  bc    _out
  decf  reg+1,F
_out:


Scott
____________________________________________

2004\10\21@021339 by Ken Pergola

flavicon
face

Hi Robert,

In summary, taking the examples I posted for 24-bit composite variables, and
assuming 16,777,216 increment/decrement iterations, your speed improvement
savings will be:


    24-bit Increment: ~ 14% faster than your snippet
    24-bit Decrement: ~ 25% faster than your snippet


It's interesting to see that the decrement speed improvement savings is
significantly more than the increment. My hunch was that it would be the
same.

Moreover, Scott's 24-bit decrement is also very quick:
    ~ 25% faster than your snippet
   (same number of clock cycles as the snippet I posted)



Now what are you going to do with all those extra clock cycles? :)


Best regards,

Ken Pergola

P.S. I indirectly obtained these figures from the MPSIM simulator in MPLAB
IDE v6.62.



____________________________________________

2004\10\21@035638 by Scott Dattalo

face
flavicon
face
On Thu, 21 Oct 2004, Robert James Kaes wrote:

> On Wed, 20 Oct 2004, Scott Dattalo wrote:
>>
>>    tstfsz reg
>>     decf  reg+1
>>    decf   reg,F
>
> Does this version work correctly?  Maybe I'm missing something but if I

I was wrong. Unfortunately, the 2 hour delay in the PIC list prevented you
from seeing my other post sooner...

> One other question: does the decf instruction actually update the carry
> bit?  The data sheet implies that the carry bit is affected by the decf
> instruction, but it doesn't actually show an example of decreasing a
> register already at zero.  Also, the gpsim program doesn't seem to
> change the carry bit when doing a decf.  Is that a bug in the program,
> or do 18Cs not update the carry for decf instructions?

It's my understanding that a DECF on the 18F is identical to a subtract
instruction where the value subtracted is always 1. I just checked that my
simulator (gpsim) was indeed handling the flags incorrectly. The fix is in
CVS.

Scott

____________________________________________

2004\10\21@133811 by Robert James Kaes

flavicon
face
Hi Everyone,
First off, thank you to Scott and Ken for their help with my
increment/decrement question.  Also, I'd like to thank Scott for fixing
the status bit bug in gpsim.

Using gpsim to test the code I believe the following routines are the
fastest implementations.

8 bit inc:  incf reg, F
16 bit inc:  infsnz reg, F
            incf reg + 1, F
24 bit inc:  incfsz reg, F
            bra _done
            incfsz reg + 1, F
            bra _done
            incf reg + 2, F
           _done:
32 bit inc:  incf reg, F
            bnc _done
            clrf WREG
            addwfc reg + 1, F
            addwfc reg + 2, F
            addwfc reg + 3, F
           _done:

8 bit dec:  decf reg, F
16 bit dec:  decf reg, F
            btfss STATUS, C
            decf reg + 1, F
24 bit dec:  decf reg, F
            bc _done
            decf reg + 1, F
            bc _done
            decf reg + 2, F
           _done:
32 bit dec:  decf reg, F
            bc _done
            clrf WREG
            subwfb reg + 1, F
            subwfb reg + 2, F
            subwfb reg + 3, F
           _done:

Hopefully this information will also provide useful to other 18C
developers.  Thank you again to everyone who helped!
       -- Robert

--
Robert James Kaes
WormBytes Consulting and Contracting
http://www.wormbytes.ca/
____________________________________________

2004\10\21@181241 by Scott Dattalo

face
flavicon
face
On Thu, 21 Oct 2004, Robert James Kaes wrote:

> 24 bit inc:  incfsz reg, F
>             bra _done
>             incfsz reg + 1, F
>             bra _done
>             incf reg + 2, F
>            _done:

Here's one more optimization:

24 bit inc:
    incfsz reg, F
     bra _done
    infsnz reg + 1, F
     incf reg + 2, F
 _done:


Scott
____________________________________________

2004\10\21@192513 by Ken Pergola

flavicon
face

Scott Dattalo wrote:

> Here's one more optimization:
>
> 24 bit inc:
>      incfsz     reg, F
>      bra        _done
>      infsnz     reg + 1, F
>      incf       reg + 2, F
>   _done:



Hi Scott,

Yup, that one takes the cake so far...good job!

It's approximately 0.06% faster over 16,777,216 iterations than the previous
one -- every clock cycle counts! :)

Best regards,

Ken Pergola


____________________________________________

2004\10\22@113308 by Robert James Kaes

flavicon
face
On Thu, 21 Oct 2004, Scott Dattalo wrote:
> Here's one more optimization:
>
> 24 bit inc:
>     incfsz reg, F
>      bra _done
>     infsnz reg + 1, F
>      incf reg + 2, F
>  _done:

Thanks Scott!  I can't imagine a more optimized version since we're
incrementing a three byte word with only four instructions.  I'll have
to test if a similar trick can be used for the 32bit increment code.
Right now it uses six instructions to do a 32bit increment.  Hmm...
       -- Robert

--
   Robert James Kaes    ---  Flarenet Inc.  ---    (519) 426-3782
                http://www.flarenet.com/consulting/
     * Putting the Service Back in Internet Service Provider *
____________________________________________

2004\10\22@115110 by Robert James Kaes

flavicon
face
On Thu, 21 Oct 2004, Ken Pergola wrote:
> Hi Scott,
>
> Yup, that one takes the cake so far...good job!
>
> It's approximately 0.06% faster over 16,777,216 iterations than the previous
> one -- every clock cycle counts! :)

Ken,
Can you test if the following 32 bit increment code is faster than the
code I posted originally:

       incfsz        reg, F
       bra        _done
       incfsz        reg + 1, F
       bra        _done
       infsnz        reg + 2, F
       incf        reg + 3, F
       _done:

If my cycle calculations are correct, this version should be about
0.013% faster over the full 2^32 iterations.
       -- Robert

--
Robert James Kaes
WormBytes Consulting and Contracting
http://www.wormbytes.ca/
____________________________________________

2004\10\22@222440 by Ken Pergola

flavicon
face

Robert James Kaes wrote:

> Ken,
> Can you test if the following 32 bit increment code is faster than the
> code I posted originally:


Hi Robert,

The other night I tried to do some 32-bit increment comparisons, and MPSIM
was acting strange -- execution time changed from seconds to microseconds on
its own -- I could not trust it. It was billions and billions of clock
cycles, and miles to go before I sleep, and miles to go before I sleep...

Not sure if I was overflowing MPSIM's counters -- I don't have time to look
into this...


Best regards,

Ken Pergola


____________________________________________

2004\10\23@144232 by Scott Dattalo

face
flavicon
face
On Fri, 22 Oct 2004, Robert James Kaes wrote:

> Ken,
> Can you test if the following 32 bit increment code is faster than the
> code I posted originally:
>
>        incfsz        reg, F
>        bra        _done
>        incfsz        reg + 1, F
>        bra        _done
>        infsnz        reg + 2, F
>        incf        reg + 3, F
>        _done:
>
> If my cycle calculations are correct, this version should be about
> 0.013% faster over the full 2^32 iterations.

Since Ken says that there are some issues with this for MPLAB, I ran this
under gpsim. Here's a cut-n-paste of the 32 and 24 bit routines:

    ; 32-bit increment loop takes 42983292927 cycles to run through
    ; all 2^32 iterations. In the loop, there are 7 cycles
    ; of over head. So the Total cycles are:
    ;    42,983,292,924 - 7*2^32 => 12,918,521,856
    ;
    ; Analytically,
    ; total cycles = 255/256 * 2^32 * 3 cyc  + 1/256 * 2^32 * 2 cyc +
    ;                1/256 * 2^32 * ( 255/256 * 3 cyc + 1/256 * 2 cyc) +
    ;                1/256/256 * 2^32 * 2 cyc
    ;              = ((255*3 + 2) * 257 + 2) * 2 ^16
    ;              = 197121 * 65536
    ;              = 12,918,521,856

inc32Loop:
       incfsz reg, F
        bra   done32
       incfsz reg + 1, F
        bra   done32
       infsnz reg + 2, F
       incf   reg + 3, F
done32:
       clrwdt
       movf        reg,W
       iorwf        reg+1,W
       iorwf        reg+2,W
       iorwf        reg+3,W
       bnz        inc32Loop

dd
       bra        dd

and for the 24-bit routine:


    ; 24-bit increment takes 151060479 cycles to run through
    ; all 2^24 iterations. In the loop, there are 6 cycles
    ; of over head. So the Total cycles are:
    ;    151060480 - 6*2^24 => 50397184
inc24Loop:
       incfsz reg, F
        bra   done
       infsnz reg + 1, F
       incf   reg + 2, F
done:
       clrwdt
       movf        reg,W
       iorwf        reg+1,W
       iorwf        reg+2,W
       bnz        inc24Loop


Incidently, gpsim has a 64-bit cycle counter. Early on there was only a
32-bit counter, but that is only good for 7 minutes or so of simulation
(for a 20MHz Pic). To run through all 2^32 iterations of the 32-bit
increment test routine takes over 11 hours of simulated time (and on my
old 900 MHz PIII takes about 3 hours of real time.

 Scott
____________________________________________


'[PIC ] Increment Button and Enter Button'
2006\04\18@140747 by Lawrence Burrowes
picon face
What I am trying to do is have just 2 buttons.  One will be an Increment and the other will be a Enter Button.  I want to incrememnt to say "5" then press enter then Increment to lets say "2"  then press enter then it will jump to my serial routine that will wait 5 min then recive 2 bytes of data and stop.

my starter for the button loops.  It is not working like I want too...

 LIST P=16F84A, R=DEC
 errorlevel 0,-305
 INCLUDE "p16f84A.inc"

SECNT     EQU H'0C'          ; used in counting 50, 20 msec delays for 1 sec
CNTMSEC   EQU H'0D'          ; used in timing of milliseconds
MAX          EQU H'0E'             ; Max count of 11
count      EQU H'0F'

;-------------------------------------------------------------------------;
;    Here we give names to some numbers to make their use more clear      ;
;-------------------------------------------------------------------------;

  #DEFINE   START_PB  D'3'
  #DEFINE   ROUNDS    D'4'
 
  PAGE
__CONFIG _CP_OFF & _XT_OSC & _PWRTE_ON  & _WDT_OFF

;-------------------------------------------------------------------------;
;         We set the start of code to orginate a location zero            ;
;-------------------------------------------------------------------------;

     ORG 0

           GOTO MAIN                  ; jump to the main routine
           
;-------------------------------------------------------------------------;
;          Initialization routine sets up ports and timer                 ;
;-------------------------------------------------------------------------;            
INIT      movlw  0x000                  ;  Turn 0ff LED on RB0-4 When Output Enabled
           movwf  PORTB
 
            movlw  0x010
           movwf  PORTA

           bsf    STATUS, RP0
 
           bcf    TRISB ^ 0x080, 0        ;  Enable RB0 for Output
           bcf    TRISB ^ 0x080, 1       ;  Enable RB1 for Output
           bcf    TRISB ^ 0x080, 2       ;  Enable RB2 for Output
           bcf    TRISB ^ 0x080, 3        ;  Enable RB3 for Output
           movlw  0x0FF                  ;  Enable Internal Pull-Ups
           movwf     OPTION_REG ^ 0x080
           bcf    STATUS, RP0
           RETURN
           
;-------------------------------------------------------------------------;
;         We jump to the main part ofthe program                          ;
;-------------------------------------------------------------------------;

MAIN        clrf count
             CALL INIT       ; set up ports etc.

;-------------------------------------------------------------------------;
;      This loop checks for either pushbutton and acts  accordingly       ;
;-------------------------------------------------------------------------;

KEYCHKLOOP  BTFSS PORTA,ROUNDS          ; check ROUNDS pushbutton pressed
           GOTO SETROUNDS             ; yes, select starting ROUNDS count
           BTFSS PORTA,START_PB       ; check for START pressed
           GOTO STARTWRKT             ; yes, start Workout
           GOTO KEYCHKLOOP            ; loop to catch key press
           
;-------------------------------------------------------------------------;
;        Start SERIAL routine
;-------------------------------------------------------------------------;            
STARTWRKT   CALL WAITSTARTUP           ; wait for release of START key
           CLRF  PORTB               ; clear PORTB
           GOTO  SETB

;-------------------------------------------------------------------------;
;                    Wait for release of START button                     ;
;-------------------------------------------------------------------------;

WAITSTARTUP BTFSS PORTB,START_PB       ; wait for release
           GOTO WAITSTARTUP           ; not released yet
           CALL DLY20                 ; debounce release
           BTFSS PORTB,START_PB       ; 2nd check, make sure released
           GOTO WAITSTARTUP           ; keep checking
           RETURN

;-------------------------------------------------------------------------;
;                    Wait for release of ROUNDS button                       ;
;-------------------------------------------------------------------------;

WAITROUNDS  BTFSS PORTA,ROUNDS         ; wait for release
           GOTO WAITROUNDS            ; not yet
           CALL DLY20                 ; debounce release
           BTFSS PORTA,ROUNDS         ; 2nd check, make sure released
           GOTO WAITROUNDS            ; keep checking

           RETURN


REUP        movlw 0x0C        ;load W with 11
             movwf MAX        ;transfer W to BLUET
             CLRF  PORTB
             RETURN
;-------------------------------------------------------------------------;
;        Selects starting Incrementing and displaying on BCD              ;
;-------------------------------------------------------------------------;

SETROUNDS   movf   count, W
             movwf  PORTB
             incf   count, F

           decf   MAX                   ; Decrement MAX, ;if zero skip
           BTFSC  STATUS,Z
           GOTO  REUP
             CALL WAITROUNDS            ; make sure select switch is up
           GOTO KEYCHKLOOP            ; start checking buttons again

;-------------------------------------------------------------------------;
;  The following are various delay routines based on instruction length.  ;  
;  The instruction length is assumed to be 1 microsecond (4Mhz crystal).  ;
;-------------------------------------------------------------------------;

DLY20       MOVLW 20                   ; delay for 20 milliseconds
               ;*** N millisecond delay routine ***
NMSEC       MOVWF CNTMSEC              ; delay for N (in W) milliseconds
MSECLOOP    MOVLW D'248'               ; load takes 1 microsec
           CALL MICRO4                ; by itself CALL takes ...
                                      ; 2 + 247 X 4 + 3 + 2 = 995
           NOP                        ; 1 more microsec
           DECFSZ CNTMSEC,f           ; 1 when skip not taken, else 2
           GOTO MSECLOOP              ; 2 here: total 1000 per msecloop
           RETURN                     ; final time through takes 999 to here
                                      ; overhead in and out ignored

               ;***  1 millisecond delay routine ***
ONEMSEC     MOVLW D'249'               ; 1 microsec for load W
                                      ; loops below take 248 X 4 + 3 = 995
MICRO4      ADDLW H'FF'                ; subtract 1 from 'W'
           BTFSS STATUS,Z             ; skip when you reach zero
           GOTO MICRO4                ; loops takes 4 microsec, 3 for last
           RETURN                     ; takes 2 microsec
                                      ; call + load  W + loops + return =
                                      ; 2 + 1 + 995 + 2 = 1000 microsec
;------                                      
SETB        BSF     PORTB,3
                                     
           END


               
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.

2006\04\18@142746 by David Segonds

flavicon
face
Lawrence,

It seems that you are never going through the initialization portion
of the code and jump directly to the MAIN label.

{Quote hidden}

--
David Segonds
PGP: 1F7A3E7A Finger: 9949 521B 1B39 CE5A E193  FC49 866A 1255 1F7A 3E7A

2006\04\18@143913 by Maarten Hofman

face picon face
2006/4/18, Lawrence Burrowes <ljburrowesspam_OUTspam@spam@yahoo.com>:
>
> What I am trying to do is have just 2 buttons.  One will be an Increment
> and the other will be a Enter Button.  I want to incrememnt to say "5" then
> press enter then Increment to lets say "2"  then press enter then it will
> jump to my serial routine that will wait 5 min then recive 2 bytes of data
> and stop.
>
> my starter for the button loops.  It is not working like I want too...


It might be a good idea to actually state what it is doing wrong as well. It
would also be nice to know which button is connected to which port, and how.
As far as I can see the buttons seem to cause a '1' when pushed, this is
odd, as most buttons are implemented using a pull up resistor. Please give a
schematic.

LIST P=16F84A, R=DEC
> errorlevel 0,-305


Why leave out -305?

INCLUDE "p16f84A.inc"


I pity the developer that is still using the 16F84A.

SECNT     EQU H'0C'          ; used in counting 50, 20 msec delays for 1 sec
> CNTMSEC   EQU H'0D'          ; used in timing of milliseconds
> MAX          EQU H'0E'             ; Max count of 11
> count      EQU H'0F'


It is probably much wiser to use CBLOCK, and even better to use a linker
script and have your variables allocated by your linker.

;-------------------------------------------------------------------------;
{Quote hidden}

You could just put the MAIN routine here instead of jumping to it.

;-------------------------------------------------------------------------;
{Quote hidden}

It is better to use banksel rather than setting the RP0 bit manually. I
would personally make sure TRISA and TRISB are in a known state as well,
although you can indeed assume that they are set to a certain value at this
point.

          bcf    TRISB ^ 0x080, 0        ;  Enable RB0 for Output
>            bcf    TRISB ^ 0x080, 1       ;  Enable RB1 for Output
>            bcf    TRISB ^ 0x080, 2       ;  Enable RB2 for Output
>            bcf    TRISB ^ 0x080, 3        ;  Enable RB3 for Output
>            movlw  0x0FF                  ;  Enable Internal Pull-Ups
>            movwf     OPTION_REG ^ 0x080
>            bcf    STATUS, RP0
>            RETURN


Since initialisation happens only once, you could put it inside the
beginning of the main routine, rather than make it a separate subroutine.
Especially on the lower end PICmicros this saves a stack level.

;-------------------------------------------------------------------------;
{Quote hidden}

          BTFSS PORTB,START_PB       ; 2nd check, make sure released
{Quote hidden}

I would recommend adding a ,f or ,w to make sure you know what it is doing.
Also, if you want it to skip when zero, you could just use "decfsz".

          BTFSC  STATUS,Z
>            GOTO  REUP


CERTAIN ERROR: REUP is a subroutine. You should not GOTO to it.

            CALL WAITROUNDS            ; make sure select switch is up
{Quote hidden}

CERTAIN ERROR 2: And what happens after this? That is anyone's guess: your
processor keeps running, but there is no code... You at least will need
something that causes the system to stop here.

          END


Greetings,
Maarten Hofman.

2006\04\18@162743 by rosoftwarecontrol

flavicon
face
with two buttons, you can have 3 function.
that gives you lots of possibility.

My button from 5 changed to 4, then 3, now is 2.
Less button, less user error and light sw.


{Original Message removed}

2006\04\18@222359 by Maarten Hofman

face picon face
> with two buttons, you can have 3 function.
> that gives you lots of possibility.
>
> My button from 5 changed to 4, then 3, now is 2.
> Less button, less user error and light sw.


I still like the combination of the demo board of the PicKit 2: one button
and one potentiometer. I discovered it is very convenient to use those for
all sorts of inputs, and the potentiometer allows very fast selection of a
number of a list: with a bit of practice even alphanumerical input
reasonably easy (although interpreting the PS/2 protocol isn't that
difficult either).

Greetings,
Maarten Hofman.

P.S. With a proper capacitor/resistor it is possible to read the value of
the potentiometer even if you don't have an A/D converter, although it would
require some calibration: charge the capacitor using by making the port an
output and sending a 1, and then see how long it takes to become 0 again.

2006\04\19@133826 by Byron A Jeff

face picon face
On Tue, Apr 18, 2006 at 10:23:59PM -0400, Maarten Hofman wrote:
> > with two buttons, you can have 3 function.
> > that gives you lots of possibility.
> >
> > My button from 5 changed to 4, then 3, now is 2.
> > Less button, less user error and light sw.
>
>
> I still like the combination of the demo board of the PicKit 2: one button
> and one potentiometer. I discovered it is very convenient to use those for
> all sorts of inputs, and the potentiometer allows very fast selection of a
> number of a list: with a bit of practice even alphanumerical input
> reasonably easy (although interpreting the PS/2 protocol isn't that
> difficult either).

This is the interface I settled on. It's possible to gut an incandescent
dimmer and get the pot and switch on the same step. My debounce routine that
I used for my sunrise/sunset outdoor light controller still bounces a bit
too much. I would also modify it so that the pot would have to change from its
initial value in order for the value of the entry item to change. That way
you can skip an entry simply by pressing the button multiple times.

BAJ

2006\04\19@141401 by Timothy Weber

face picon face
>> I still like the combination of the demo board of the PicKit 2: one button
>> and one potentiometer. I discovered it is very convenient to use those for
>> all sorts of inputs, and the potentiometer allows very fast selection of a
>> number of a list: with a bit of practice even alphanumerical input
>> reasonably easy (although interpreting the PS/2 protocol isn't that
>> difficult either).

My favorite is something similar: one button and one quad encoder with
detents and built-in button.  Still just two affordances.  The quad
encoder selects values from a list; its button selects the current value
and goes forward to the next one; and the other button goes back -
basically the buttons are Enter and Escape.
--
Timothy J. Weber
http://timothyweber.org


'[SX] Incremental Encoder --> Absolute Encoder'
2006\10\05@051234 by crgwbrn/a
flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, crgwbr wrote:

Hello Everyone,
I'm working on a project that requires the use of a very acurette encoder.  We should be using a 12 bit absolute encoder with PWM output, but because of budget cuts, we have to use this one (2500 ppr incrementle encoder).  It has an "NPN open collecter output."  I have yet to figure out what that means.  What I would like to do is, as soon as the unit turns on, assign the ENCODER varible 0.  Then every step the encoder takes up, add one too ENCODER; every step down, subtract one.  I could most likely figure this out on my own, however, I am concerned about the encoder moving while the program is doing somthing else (read keypad, display stuff on LCD, ect.).  At most, the encoder will be moving at 0.5 rpm, but moving almost constantly.  How can I avoid this "slipage affect."
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=147629
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\10\05@061602 by beann/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, bean wrote:

2500 ppr * 30 revolutions per second = 7500 pulses per second.
So as long as you sample faster than that, you shouldn't lose any pulses.
Or you could use the PortB interrupts and that would be even better.

NPN Open collector just means you need a pull-up resistor on the outputs.

Bean.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=147629#m147641
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\10\05@063815 by crgwbrn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, crgwbr wrote:

Thanks Bean,
Although I'm not sure where you got the 30 revolutions per second.  I had mentioned 0.5 rpm, meaning about 0.008 revolutions per secound or about 20 pulses per second.  Eather way it shouldn't be a problem.  Pull-up resister, that means the pulses will be low, and the space will be high, corect.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=147629#m147645
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\10\05@074940 by beann/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, bean wrote:

Oops,
 Ol' bean multipled instead of divided. 75000 pps or 21 pps... I was close...

 Your right about 21 pulses per second. That can easily be handled without missing any by using a period interrupt. For example "INTERRUPT 100" will run the interrupt routine 100 times a second.

Bean.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=147629#m147659
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\10\05@075428 by crgwbrn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, crgwbr wrote:

Sorry, but I have never used Interrupts before.  I'm assuming you write a block of code, with Interrupt 100 in it, then write the rest of the code after that.  And it automaticly goes to the interruppt every 100 mS, nomatter where it is in the code.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=147629#m147661
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\10\05@080137 by beann/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, bean wrote:

Basically yes, except it will run every 10mSec (100 times per second).
 You must put the interrupt routine BEFORE any SUBs or code.
 Then use:

 INTERRUPT 100
   ' Run this code 100 times per second (every 10mSec)
 RETURNINT
Bean.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=147629#m147663
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\10\05@080307 by crgwbrn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, crgwbr wrote:

Thank You.  I think I have it now.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=147629#m147664
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\10\05@104510 by wbahnn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, wbahn wrote:

Is this incremental encoder just an optical sensor and a disk? Or does it have some smarts (some kind of logic) that is producing the pulses. If the former, then you have to be concerned with transition bounce. This is when the output bounces up and down a few times as the disk transitions from a shaded region to a clear region (or vice versa). If you sample fast enough, you can catch these bounces and interpret them as the disk moving faster than it really is. Most basic encoders have two outputs that change in quadrature to permit you to detect and compensate for this. This also lets you detect what direction the disk is turning in. Incremental encoded intended purely for speed measurement on systems that don't change speed very much often only have a single output.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=147629#m147706
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\10\05@104914 by wbahnn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, wbahn wrote:

I finally got my browser to follow your link and the one you pointed to has quadrature outputs. I noticed that there is also a model that has line driver outputs, which would eliminate the need for pull-up circuitry. You might consider that one.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=147629#m147712
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\10\05@112646 by crgwbrn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, crgwbr wrote:

I did think about the line driver version, but I was unable to figure out what a line driver was.  The NPN open collecter sounded simpler, so I ordered it already.  The pull-up circuitry isn't a big deal.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=147629#m147719
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\10\06@104321 by James Newtonn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, James Newton wrote:

[Quoting: "Bean (Hitt Consulting)"]
Basically yes, except it will run every 10mSec (100 times per second).
You must put the interrupt routine BEFORE any SUBs or code.
Then use:

INTERRUPT 100
' Run this code 100 times per second (every 10mSec)
RETURNINT
Bean.

I just have to say: That is SUCH a COOL feature of SX/B. Doing all the ISR setup and allowing the user to just specify how often the interrupt should run. Once again: Nice job Bean.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=147629#m147878
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

'[SX] Scanning a matrix and incrementing some value'
2006\10\22@025631 by ALTITUDEAPn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, ALTITUDEAP wrote:

i have been working this evening on the 4x4 matrix program that Parallax has written.
I can make the program work and understand, after much playing, how it works.  I want to be able to take this program farther though.  What i want to be able to do is to have a byte value for each key 0-16.  I want to adjust each value each time that that key is pressed.  For instance, i want an led to light once the 3 key has been pressed 15 times and a different LED to light once key 16 has been pressed 25 times. The led will stay lit until until the system is reset.  I did not know what approach to take to keep track of these 16 variables 'Key0 - Key15' and then also let the system know what the different key press amounts are for each key.  Any ideas will be greatly appreciated.



' =========================================================================
'
'   File...... KEYPAD.SXB
'   Purpose... Scanning a 4x4 Matrix Keypad
'   Author.... (c) Parallax, Inc. -- All Rights Reserved
'   E-mail.... support@parallax.com
'   Started...
'   Updated... 05 JUL 2006
'
' =========================================================================
' -------------------------------------------------------------------------
' Program Description
' -------------------------------------------------------------------------
'
' This program demonstrates the scanning of a 4x4 matrix keypad. If no
' key is pressed the GET_KEY routine will return a value of 16.
'
' Key values (hex):
'
'      C1    C2    C3    C4
'
' R1  [ 0 ] [ 1 ] [ 2 ] [ 3 ]
'
' R2  [ 4 ] [ 5 ] [ 6 ] [ 7 ]
'
' R3  [ 8 ] [ 9 ] [ A ] [ B ]
'
' R4  [ C ] [ D ] [ E ] [ F ]
' -------------------------------------------------------------------------
' Device Settings
' -------------------------------------------------------------------------
DEVICE          SX28, OSC4MHZ, TURBO, STACKX, OPTIONX
FREQ            4_000_000
ID              "KEYPAD"
' -------------------------------------------------------------------------
' IO Pins
' -------------------------------------------------------------------------
Keys            VAR     RC                      ' keyboard scan port
TRIS_Keys       VAR     TRIS_C
PLP_Keys        VAR     PLP_C
Col1            VAR     Keys.7                  ' column inputs
Col2            VAR     Keys.6
Col3            VAR     Keys.5
Col4            VAR     Keys.4
LEDs            VAR     RB
TRIS_LEDs       VAR     TRIS_B
' -------------------------------------------------------------------------
' Constants
' -------------------------------------------------------------------------
Yes             CON     0                       ' active low input
No              CON     1
Dash            CON     %01000000               ' segment G only
' -------------------------------------------------------------------------
' Variables
' -------------------------------------------------------------------------
theKey          VAR     Byte                    ' from keypad, 0 - 16
row             VAR     Byte                    ' keyboard scan row tmpB1           VAR     Byte                    ' subroutine work vars
tmpB2           VAR     Byte
tmpW1           VAR     Word
' =========================================================================
 PROGRAM Start
' =========================================================================
' -------------------------------------------------------------------------
' Subroutine Declarations
' -------------------------------------------------------------------------
GET_KEY         SUB     0                       ' get key from pad
DELAY           SUB     1, 2                    ' delay in milliseconds
' -------------------------------------------------------------------------
' Program Code
' -------------------------------------------------------------------------
Start:
 LEDs = Dash                                   ' dash in display
 TRIS_LEDs = %00000000                         ' LED pins are outputs
Main:
 theKey = GET_KEY                              ' get a key
 IF theKey < 16 THEN                           ' was a key pressed?
   READ ReMap + theKey, theKey                 ' yes, remap keypad
   READ Digits + theKey, LEDs                  ' output to display
   DELAY 100
 ELSE
   LEDs = Dash
 ENDIF
 GOTO Main
' -------------------------------------------------------------------------
' Subroutine Code
' -------------------------------------------------------------------------
' This routine works by activating each row, then scanning each column.
' If a particular row/column junction is not active (pressed), the key
' value is incremented and the scan continues.  As soon as a key is found,
' the routine exits.  If no key is pressed the routine will exit with a key
' value of 16.
'
' Use: aByte = GET_KEY
' -- scans keyboard and places key value into 'aByte'
GET_KEY:
 tmpB1 = 0                                     ' reset keyboard value
 Keys = %0000_0111                             ' activate first row
 TRIS_Keys = %1111_0000                        ' refresh IO state
 PLP_Keys = %0000_1111                         ' pull-up input pins
 FOR tmpB2 = 1 TO 4                            ' scan four rows
   IF Col1 = Yes THEN EXIT                     ' check buttons on column
   INC tmpB1                                   ' update key value
   IF Col2 = Yes THEN EXIT
   INC tmpB1
   IF Col3 = Yes THEN EXIT
   INC tmpB1
   IF Col4 = Yes THEN EXIT
   INC tmpB1
   Keys = Keys >> 1                            ' select next row
   Keys = Keys | %0000_1000                    ' clear previous row
 NEXT
 RETURN tmpB1
' -------------------------------------------------------------------------
' Use: DELAY ms
' -- 'ms' is delay in milliseconds, 1 - 65535
DELAY:
 IF __PARAMCNT = 1 THEN
   tmpW1 = __PARAM1                            ' save byte value
 ELSE
   tmpW1 = __WPARAM12                          ' save word value
 ENDIF
 PAUSE tmpW1
 RETURN
' =========================================================================
' User Data
' =========================================================================
' Matrix to remap keypad values
ReMap:
 DATA   1,  2,  3, $A
 DATA   4,  5,  6, $B
 DATA   7,  8,  9, $C
 DATA  $E,  0, $F, $D
' Seven-segment digit maps
Digits:
'        .gfedcba
 DATA  %00111111                               ' 0
 DATA  %00000110                               ' 1
 DATA  %01011011                               ' 2
 DATA  %01001111                               ' 3
 DATA  %01100110                               ' 4
 DATA  %01101101                               ' 5
 DATA  %01111101                               ' 6
 DATA  %00000111                               ' 7
 DATA  %01111111                               ' 8
 DATA  %01100111                               ' 9
 DATA  %01110111                               ' A
 DATA  %01111100                               ' B
 DATA  %00111001                               ' C
 DATA  %01011110                               ' D
 DATA  %01111001                               ' E
 DATA  %01110001                               ' F


---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=150795
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)


'[PIC] Multiple incremental encoder coding'
2013\12\23@052659 by CDB
flavicon
face
I've been asked if I can conjure up  a device that will allow 6 incremental rotary encoders and 10 ADC inputs. I suspect this is for some sort of gaming doodad.

I'm wondering on what the lists thoughts are on saving 12 port pins with the following.

Attach channel A of all the encoders to a single interrupt on change pin. The IOC will look for high to low and then low to high.

Attach all the B channels to individual pins on a port.

On interrupt the complete port with 6 channel B's will be read in and masked in a sequential series to see which pin changed and the state it changed to - Xoring with a previous state buffer to get direction and count.

Does this seem feasible and have I overlooked any pitfalls, other than possibly more than one encoder being twiddled at the same time?

I would debounce in hardware with probably a 10K pullup and 10nF capacitor per input.  Pushbuttons on the encoders are not required, but the pins used by an encoder could be substituted with push buttons,  I was thinking of having a Pic pin that could be set high or low to signal whether push buttons or encoders were attached.

It wouldn't surprise me if there wasn't a future requirement for the last option to be set via a PC to the Pic.

Colin
--
cdb,  on 23/12/2013






-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2013\12\23@073604 by alan.b.pearce

face picon face
I would look at using chips with the QEI peripheral in them to handle at least some of the quadrature encoders. IIRC there are PIC24/33 chips that will handle either 2 or 4 QEI ports, and the 100 pin versions of these chips have zillions of ADC lines.

Check the PIC24E/PIC33E series as a starting point - but whichever chips you look at, check the errata, I know some chip families have errors in the QEI.


{Quote hidden}

-- Scanned by iCritical.

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2013\12\23@091237 by Spehro

picon face
I would first look at using an inexpensive PIC with a high clock speed ( like 64MHz) and just poll regular GPIOs and a single timer interrupt -- evaluate if that's fast enough for the application. You can debounce  in firmware and save at least a dozen components. 10K and 10nF have a tau of 100us, so if those values are realistic, polling at 10 kHz or 20 kHz might be fast enough. If they are mechanical encoders that is more than fast enough...there is a limit to the count period set by the bounce time.

I don't see how you can connect all A's to a single INT pin-- unless you exclusive OR'd each together, but that would require several gate chips and could be pattern sensitive in terms of missing steps. Maybe it's a true 3D ' mouse' or a Stewart platform-- 6 DOF would be required for that. If the latter, the consequences of missing steps might be more serious. You might want to determine that, and whether multiple encoders will be moving at once.

Best regards,
--sp


{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2013\12\23@135711 by Dwayne Reid

flavicon
face
Comments in-line.

At 03:02 AM 12/23/2013, CDB wrote:
>I've been asked if I can conjure up  a device that will allow 6 incremental
>rotary encoders and 10 ADC inputs. I suspect this is for some sort of
>gaming doodad.
>
>I'm wondering on what the lists thoughts are on saving 12 port pins with
>the following.
>
>Attach channel A of all the encoders to a single interrupt on change pin.
>The IOC will look for high to low and then low to high.

This won't work.  Assume that the encoders are open-collector (or mechanical switches) that go to Ground when closed.

When any one encoder is in a position that channel A is grounded, none of the other encoders can change that pin.  You will see changes on the individual channel B lines, but without seeing the changes on the channel A line, you can't tell direction.

Also note that the method you are proposing, which is treat channel A as the clock line and channel B as the direction line; can suffer from false counts because of jitter on the channel A line.  That is: assume that the encoder is right at the transition point for channel A.  You get clock edges but no direction changes.  This results in false counts.

Been there, done that, learned NOT to do it that way <grin>.

There are a couple of ways to do this.  But, honestly, I'd dedicate either a small PIC (with enough pins for all 12 encoder lines) and poll the pins at a very fast rate.  Then use the standard 4-entry lookup table for each of the encoders or, if you are feeling ambitious, the also-standard 4-state state machine for each of the encoders..

dwayne

-- Dwayne Reid   <RemoveMEdwaynerEraseMEspamKILLspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2013\12\23@154516 by Bob Axtell

face picon face
On 12/23/2013 11:57 AM, Dwayne Reid wrote:
{Quote hidden}

I'm using a seperate PIC16F1933 as a quad decoder for 4 channels of motors. Firmware de-bouncing is very reliable, with a huge memory for keeping track of the count. During non-motor movement times, the PIC handles RS232 access to a small notebook PC to help us to setup our solar installations. The various counts are stored in EEPROM in triplicate to be sure that the count is always accurate, even during power off situations.

The PIC16F1933 officially can be run at 32Mhz but I can run it easily at 40Mhz at 5V by using a 10M resonator instead of an 8M. Plenty fast for anything we're doing.

These PIC's are cheap, too; about $2 USD. Special quad decoders cost $15 or more.

--Bob

--
The only place success comes before work is in the dictionary.

VINCE LOMBARDI

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2013\12\24@040055 by cdb

flavicon
face
Thanks for the responses. Looks like a rethink is needed.

Colin
--
cdb, spamBeGonecolinspam_OUTspamRemoveMEbtech-online.co.uk on 24/12/2013
Web presence: http://www.btech-online.co.uk   Hosted by:  http://www.justhost.com.au
 This email is to be considered private if addressed to a named  individual or Personnel Department, and public if addressed to a blog,  forum or news article.
 
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2013\12\24@050515 by cdb

flavicon
face
I have just had a thought on a different approach. A Pic with 5 or 7 input capture modules.

I'll probably end up extending my current one encoder code to take account of 6.

Colin
--
cdb, .....colinspamRemoveMEbtech-online.co.uk on 24/12/2013
Web presence: http://www.btech-online.co.uk   Hosted by:  http://www.justhost.com.au
 This email is to be considered private if addressed to a named  individual or Personnel Department, and public if addressed to a blog,  forum or news article.
 
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2013\12\24@050717 by cdb

flavicon
face
On Mon, 23 Dec 2013 13:45:09 -0700, Bob Axtell wrote:
:: I'm using a seperate PIC16F1933 as a quad decoder for 4 channels of
:: motors.

Are you using the CCP or a total code based algorithm?

Colin
--
cdb, colinspam@spam@btech-online.co.uk on 24/12/2013
Web presence: http://www.btech-online.co.uk   Hosted by:  http://www.justhost.com.au
 This email is to be considered private if addressed to a named  individual or Personnel Department, and public if addressed to a blog,  forum or news article.
 


-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2013\12\24@102321 by Jason White

picon face
> I've been asked if I can conjure up  a device that will allow 6 incremental
> rotary encoders and 10 ADC inputs. I suspect this is for some sort of
> gaming doodad.
>
> I'm wondering on what the lists thoughts are on saving 12 port pins with
> the following.
Two ideas
1) If large IO is a concern I would be tempted to use a small CPLD to
route the encoders to the MCU (make them addressable like a RAM), and
then perhaps give it some logic to generate an interrupt on change for
the processor.
2) Of course, if that is not an option maybe a multiplexer chip could
do the job (ie. the 16:1 CD4067 analog multiplexer). Though a quick
search does not reveal a one chip (through-hole) mux solution to your
problem.

-- Jason White
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2013\12\24@115544 by Dwayne Reid

flavicon
face
At 08:23 AM 12/24/2013, Jason White wrote:
> > I've been asked if I can conjure up  a device that will allow 6 incremental
> > rotary encoders and 10 ADC inputs.
>
>Two ideas
>1) If large IO is a concern I would be tempted to use a small CPLD to
>route the encoders to the MCU (make them addressable like a RAM), and
>then perhaps give it some logic to generate an interrupt on change for
>the processor.

The above is sort of what I suggested - but a CPLD could, I think, potentially be a better solution than a PIC.  The advantage of a CPLD is that the inputs could be self-clocking and implementing the full state-machine decoder (times 6) within the CPLD is trivial.

The interface to the host processor would be similar to using another small PIC, except that using I2C might be easier on the CPLD than with a PIC.  SPI is similar in both cases.

But two different options to accomplish the same task.

The real bonus of off-loading the encoder tasks to a separate device is that the host is now much less busy because it doesn't have to deal with the rotary encoders.  This can be a very worthwhile tradeoff.

dwayne

-- Dwayne Reid   <EraseMEdwaynerRemoveMEspamSTOPspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2013\12\24@124935 by Denny Esterline

picon face
There's a few different ways to handle encoders and (as usual) "best" is
dependent on what you're trying to do with it.

For servo motor drives and measurement of real world stuff, you generally
want to do a full 4x decode and get as much resolution as possible.
For less demanding applications (human interface is a good example)  you
can usually get by with the simpler implementation.

The "best" 4x decode I've worked with uses 2 interrupt on change pins on
the A and B lines. On each interrupt you exclusive-OR the _previous_ A
value with the current B value, increment if it's a one, decrement
otherwise. Then capture the _current_ A value for the next comparison. Very
low overhead, tolerant of real world noise, etc. The problem is running
multiples in one PIC. You have to get very creative to keep track of which
encoder generated the interrupt and even more creative to make sure you
don't miss a change on one encoder while you're servicing another. With a
bit of creativity it may be possible to "bend" the input capture
interrupt(s) to achieve the same end.

If you can deal with the inherent latency, it may be a good choice to use a
small (perhaps a 10F) PIC that only monitors one encoder and behaves as a
slave node. Plenty of low-overhead simple serial protocols that would be
suitable here. Interrupt driven, even a relatively slow processor can
handle surprisingly fast encoder data. I can see that working such that you
could reliably handle 40kHz+ encoder rates if you can live with 50Hz or
less data update rate. There are trade-offs you could play with to get that
higher, but in practical terms, it's hard to get any serial slave node to
update more than a few kHz. (and even if you did, what would you do with
that much data?)

Others have mentioned a faster processor and polling for the data. I've
tried this before and been very disappointed. Even with low-resolution hand
turned encoders, I was able to generate skips and misses. For front-panel
human interface things, that may be acceptable. For physical feedback
systems, no.


Most of my recent work has been done with the more capable dsPIC33 family
of parts. Some of them have two QEI interfaces (hardware encoder module),
with that, multiple CN pins and the IC, you could probably manage it, but
it'd be messy.

-Denny



On Mon, Dec 23, 2013 at 3:02 AM, CDB <RemoveMEcolinKILLspamspamTakeThisOuTbtech-online.co.uk> wrote:

> I've been asked if I can conjure up  a device that will allow 6 incremental
> rotary encoders and 10 ADC inputs. I suspect this is for some sort of
> gaming doodad.
>
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2013\12\24@144110 by Bob Axtell

face picon face
On 12/24/2013 3:07 AM, cdb wrote:
{Quote hidden}

code-based decoder written in assembly. But it is easy assembly, using a jump table rather than bit tests.

Notice that the PIC16F1939 offers instant interrupts, so setting the int-on-change change detector on the highest 4-bits of portB, then xor'ing the A and B of each channel allows 8 inputs to be handled by 4 IOC inputs.

--Bob A



--
The only place success comes before work is in the dictionary.

VINCE LOMBARDI

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2013\12\24@153342 by Bob Axtell

face picon face
On 12/24/2013 9:55 AM, Dwayne Reid wrote:
{Quote hidden}

BUT the advantage of the PIC would be that you could advance the counters INSIDE the PIC, offloading the entire task.

--Bob

--
The only place success comes before work is in the dictionary.

VINCE LOMBARDI

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2013\12\24@164325 by Dwayne Reid

flavicon
face
At 01:33 PM 12/24/2013, Bob Axtell wrote:
> >
> > The real bonus of off-loading the encoder tasks to a separate device
> > is that the host is now much less busy because it doesn't have to
> > deal with the rotary encoders.  This can be a very worthwhile tradeoff.
>
>BUT the advantage of the PIC would be that you could advance the
>counters INSIDE the PIC, offloading the entire task.
>
>--Bob

Sure!  You've described something that, with the addition of a glue chip outside of the PIC (4- XOR gates), will handle 4 encoders.  Because you can detect all 4 state changes, you can easily implement the full 4X decoding.

But how does he handle 6?

My point was that if you have to add an external chip, do it in such a fashion that it makes the job of the main controller easier in the long run.

A small CPLD would handle 6, 8, 10 encoders easily - up to pin limit of the package.  You get edge detection on both encoder inputs and implementing the full 4X decode with on-board logic (state machines) is trivially easy.

The only consideration is communications between the CPLD and the host controller.  As I mentioned earlier, both I2C and SPI are easily done.  Personally, I prefer SPI.  But that's just me.

dwayne

-- Dwayne Reid   <RemoveMEdwaynerspam_OUTspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2013\12\24@165045 by Dwayne Reid

flavicon
face
At 12:41 PM 12/24/2013, Bob Axtell wrote:

>Notice that the PIC16F1939 offers instant interrupts, so setting the
>int-on-change change detector on the highest 4-bits of portB, then
>xor'ing the A and B of each channel allows 8 inputs to be handled by 4
>IOC inputs.

Hi there, Bob.

I'm not familiar with the 16f1939.  Thanks for pointing an easy way to handle 4 rotary encoders.  I'll tuck that into the back of my brain for later use.

Many thanks!

dwayne

-- Dwayne Reid   <dwaynerspamspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.


'[EE] Incremental Encoders'
2017\04\05@170447 by Phil Keller
flavicon
face
I am looking into a design where I would like to use a single incremental encoder for two separate controls.  In order for me to accomplish this I need to understand what the outputs (A & B) are held to when there is no rotation.  Are the outputs held OFF (aka open), ON or one of each based on the last rotation?  What happens when the user rotates the knob very slowly?  Is the pulse a fixed width or is it base on shaft rotational speed?  What is the state of the outputs if the rotation is halted between detents?  Is the nominal output state manufacture dependent or is there a "standard".

  Thanks for any guidance you can provide.
-Phil-
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\05@173048 by Josh Koffman

face picon face
On Wed, Apr 5, 2017 at 5:04 PM, Phil Keller <spam_OUTphilspam_OUTspamspam_OUTpkeller.net> wrote:
> I am looking into a design where I would like to use a single
> incremental encoder for two separate controls.  In order for me to
> accomplish this I need to understand what the outputs (A & B) are held
> to when there is no rotation.  Are the outputs held OFF (aka open), ON
> or one of each based on the last rotation?  What happens when the user
> rotates the knob very slowly?  Is the pulse a fixed width or is it base
> on shaft rotational speed?  What is the state of the outputs if the
> rotation is halted between detents?  Is the nominal output state
> manufacture dependent or is there a "standard".

Hi Phil,

In my experience it's been manufacturer dependent. Best thing to do
would be to check the datasheet for the encoder you wish to you.

I think part of this is determined by the detents, how many, etc. If
you choose an encoder with no detents then there is no way to know
what state it will stop in.

Josh
-- A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\05@173327 by Sean Breheny

face picon face
Hi Phil,

The traditional incremental encoder is nothing but two optical interrupters
and a wheel with slots cut in it around the perimeter. The two optical
interrupters are offset by 1/4 of the slot spacing. As the wheel rotates,
the interrupters turn on and off once per slot, but which one leads and
which one lags depends on direction of rotation.

When the wheel is not rotating, both A and B signals are static, and each
can be either high or low depending on the exact position where the wheel
stopped. Sometimes there can be some "dithering" where one signal (let's
say A) is very close to a transition point and rapidly toggles between high
and low. However, in this case, the other signal will always be in the
middle of either a slot or the metal solid part between slots and will not
be switching.

The process of extracting step and direction information from the encoder
is called Quadrature Decoding. In quadrature decoding, each edge (rising or
falling) of each signal is considered a step. The type of edge (rising or
falling) and the level of the other signal (high or low) determines the
direction. If B is constant low, for example, and A is dithering, then each
rising edge of A will count as a forward step and each falling edge will
count as a backwards step, so the overall motion will be zero, just
increasing and decreasing by one count like any digital quantity which is
near its transition point.

Some encoders are implemented differently than this but they are all
designed to roughly emulate the behavior of the prototypical optical
incremental encoder. Some use mechanical switches. Some use magnetic or
capacitive technologies.

Sean


On Wed, Apr 5, 2017 at 5:04 PM, Phil Keller <philspam_OUTspampkeller.net> wrote:

{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\05@173457 by jim

flavicon
face

Phil,

I'm not an expert on incremental encoders, but most encoders I have
worked with output GRAY CODE,  ie, only one bit changes at each detent.
The outputs connect to ground, so they need a pull-up resistor from
each output to Vdd.
And regarding the output state when not moving, they remain in the
state that the last  rotation left them in.  
Regards,

Jim

> ---{Original Message removed}

2017\04\05@173502 by Sean Breheny

face picon face
I think the detents would be located at each quadrature step (i.e., four
detents per cycle of A and B) so it would be possible to get any
combination of A and B depending on which detent you stop at. The only
thing the detents would do to modify the behavior is that they would
prevent dithering (and give human feedback)


On Wed, Apr 5, 2017 at 5:30 PM, Josh Koffman <RemoveMEjoshybearKILLspamspam@spam@gmail.com> wrote:

{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\05@173635 by Sean Breheny

face picon face
Quadrature-output incremental encoders are indeed a very simple example of
Gray code as Jim says. A and B never change at the same time. Gray code is
also often used in absolute encoders, too, where it has more than just two
bits A and B.

On Wed, Apr 5, 2017 at 5:34 PM, <KILLspamjimspam.....jpes.com> wrote:

{Quote hidden}

> > ---{Original Message removed}

2017\04\05@173808 by jim

flavicon
face

I forgot to add that the outputs are in quadrature.  This allows one to
determine direction of rotation.

Regards,

Jim

> ---{Original Message removed}

2017\04\05@180134 by Brent Brown

picon face
Two outputs named A & B is common with quadrature encoding.

https://en.wikipedia.org/wiki/Rotary_encoder
https://en.wikipedia.org/wiki/Rotary_encoder#/media/File:Quadrature_Diagram..svg

On 5 Apr 2017 at 14:04, Phil Keller wrote:

{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\05@183621 by Van Horn, David

flavicon
face

I think part of this is determined by the detents, how many, etc. If you choose an encoder with no detents then there is no way to know what state it will stop in.


If it's optical or magnetic, and you loose power to the sensor, then it may not be in the same state when you apply power as it was when shut down.
They are a barrel of fun.

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\05@185436 by Bob Blick

flavicon
face
Hi Phil,

The typical cheap ones have detents in the "both switches off" position. As you move from detent to detent you get a full quadrature cycle, the outputs sequentially connecting to common in an order depending on which direction you are turning.

They are simple mechanical devices so they bounce and glitch just like any cheap switch. You can hold them(and even balance them) in between detents. Since the ones I use a cheap little things, the exact state while in-between is not really defined. But pretty much you can count on both outputs being open when within a detent.

I decode them so that a single increment or decrement only happens upon both switches opening. Getting maximum resolution (X4) is not reasonable or desirable on these type of encoders.

Cheerful regards, Bob

________________________________________
From: spam_OUTpiclist-bouncesspamKILLspammit.edu <RemoveMEpiclist-bouncesRemoveMEspamEraseMEmit.edu> on behalf of Phil Keller
Sent: Wednesday, April 5, 2017 2:04 PM
To: PICLIST Post
Subject: [EE] Incremental Encoders

I am looking into a design where I would like to use a single
incremental encoder for two separate controls.  In order for me to
accomplish this I need to understand what the outputs (A & B) are held
to when there is no rotation.  Are the outputs held OFF (aka open), ON
or one of each based on the last rotation?  What happens when the user
rotates the knob very slowly?  Is the pulse a fixed width or is it base
on shaft rotational speed?  What is the state of the outputs if the
rotation is halted between detents?  Is the nominal output state
manufacture dependent or is there a "standard".

  Thanks for any guidance you can provide.
-Phil-

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\06@000551 by Sean Breheny

face picon face
Hmm, I used the Grayhill 61C series in a project and it had detents at each
quadrature position. I thought that this was standard when detents were
used.

On Wed, Apr 5, 2017 at 6:54 PM, Bob Blick <KILLspambobblickspamspamBeGoneoutlook.com> wrote:

{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\06@011207 by Bob Blick

flavicon
face
Hi Sean,

Those Grayhill ones definitely don't qualify as cheap :)

The ones I use are like this:

http://www.ebay.com/itm/-/311716200695

Although I usually pay about $0.40 each for them.

Friendly regards,

Bob

________________________________________
From: KILLspampiclist-bouncesspamBeGonespammit.edu <@spam@piclist-bouncesSTOPspamspam@spam@mit.edu> on behalf of Sean Breheny
Sent: Wednesday, April 5, 2017 9:05 PM
To: Microcontroller discussion list - Public.
Subject: Re: [EE] Incremental Encoders

Hmm, I used the Grayhill 61C series in a project and it had detents at each
quadrature position. I thought that this was standard when detents were
used.

On Wed, Apr 5, 2017 at 6:54 PM, Bob Blick wrote:

{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\06@021505 by Clint Jay

picon face
I've used the cheap eBay encoders Bob mentions, they output the full range
of codes between detents which came as quite a surprise to me and took a
little time to figure out when my code didn't appear to be working as
expected.

Of course there was no data sheet to reference so I assumed the first out
of the pack was faulty, when I got to the third I had to accept that I'd
misunderstood something and ordered a slightly more expensive branded part
from a local supplier.

Which did exactly the same thing.

So it appears a lot of the cheaper detented encoders output all codes
between detents, still useful but something to be aware of.

The Bournes optical ones I'm using now are considerably more expensive but
have no detent and make for a delightful VFO control input.

On 6 Apr 2017 6:13 am, "Bob Blick" <bobblickspamBeGonespamspamBeGoneoutlook.com> wrote:

{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\06@105321 by Phil Keller

flavicon
face
I am a little confused.  When you say they output the full range of codes between detents, what exactly do you mean?  A - Do they continue to output the last code until the next detent is reached or B - that the outputs are actually switching between any code unless it is in the detent position or C - something else.  I assume "A".

-Phil-
On 4/5/2017 11:15 PM, Clint Jay wrote:
{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\06@105639 by Phil Keller

flavicon
face
Thanks to everyone for your input and suggestions.  It looks like they will solve my problem and I think I have enough working knowledge so now the next step is to purchase a couple play with them on the bench.

  Thanks

-Phil-
On 4/5/2017 2:04 PM, Phil Keller wrote:
{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\06@112122 by Denny Esterline

picon face
On Thu, Apr 6, 2017 at 7:53 AM, Phil Keller <philRemoveMEspampkeller.net> wrote:

> I am a little confused.  When you say they output the full range of
> codes between detents, what exactly do you mean?



I believe he means that as they are turned the output:

00 - detent
01
11
10
00 - detent
01
11
10
00 - detent

so in this example they output 00 at every detent.


This adds a lot more complexity, but there is several ways to decode an
encoder. The previous example works very well with what is commonly called
x1 mode. Effectively, interrupt on the rising edge of "A" and increment or
decrement based on the status of "B". One count per detent.

For other types of encoder uses (motor position feedback, etc) I prefer x4
mode. Interrupt on both rising and falling edges of both signals. Increment
or decrement based on (current A XOR last B). That gives four counts per
detent from the last example. (don't use detent encoders on motors, but
that's not the point here :-)



-Denny
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\06@112309 by Bob Blick

flavicon
face
Hi Phi,

If we start from a detent and rotate in one direction it's like this:

-- detent
A-
AB
-B
-- detent
A-
AB
-B
-- detent
etc...

going the other direction it would be:

-- detent
-B
AB
A-
-- detent
-B
AB
A-
-- detent
etc...

Friendly regards,

Bob

________________________________________
From: EraseMEpiclist-bouncesSTOPspamspamRemoveMEmit.edu <spam_OUTpiclist-bouncesRemoveMEspamEraseMEmit.edu> on behalf of Phil Keller
Sent: Thursday, April 6, 2017 7:53 AM
To: Microcontroller discussion list - Public.
Subject: Re: [EE] Incremental Encoders

I am a little confused.  When you say they output the full range of
codes between detents, what exactly do you mean?  A - Do they continue
to output the last code until the next detent is reached or B - that the
outputs are actually switching between any code unless it is in the
detent position or C - something else.  I assume "A".

-Phil-
On 4/5/2017 11:15 PM, Clint Jay wrote:
{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\06@112348 by alan.b.pearce

face picon face
> I am a little confused.  When you say they output the full range of codes
> between detents, what exactly do you mean?  A - Do they continue to
> output the last code until the next detent is reached or B - that the outputs
> are actually switching between any code unless it is in the detent position or
> C - something else.  I assume "A".

He means that there will be four switching edges between detents. Some decoders will have only one switching edge between detents.



-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\06@112902 by David C Brown

picon face
I usually use a look-up table to decode the x4.   Either interrupt on every
edge or sample at an appropriate rate.  Then use the previous and present
values as indices to a 16 entry table which returns 1 for clockwise, -1 for
anti-clockwise and 0 for illegal transitions

__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak                           Phone: 01663 733236
Derbyshire                eMail: EraseMEdcb.homeRemoveMEspamgmail.com
SK23 7ND          web: http://www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>



*Sent from my etch-a-sketch*

On 6 April 2017 at 16:21, Denny Esterline <spamdesterline.....spamspamgmail.com> wrote:

{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\06@114315 by Denny Esterline

picon face
On Thu, Apr 6, 2017 at 8:28 AM, David C Brown <.....dcb.homespamspam.....gmail.com> wrote:

> I usually use a look-up table to decode the x4.   Either interrupt on every
> edge or sample at an appropriate rate.  Then use the previous and present
> values as indices to a 16 entry table which returns 1 for clockwise, -1 for
> anti-clockwise and 0 for illegal transitions
>


Also a good mechanism for some applications.
"Sample at appropriate rate" has never worked out for me on feedback
applications, but front panel user input applications it works very well.
Basically, assume it _will_ miss a transition now and then. For a user
interface, that's usually a non issue, for motion feedback that can be a
non issue or a deal breaker depending on app.

I've also extended the "concatenate previous and present values, use them
as an index in a lookup table" to use the three phases from the hall
sensors of brushless motor as an encoder. Works quite well.

-Denny
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\06@115102 by Clint Jay

picon face
I can't remember the exact sequence right now but if we say we have a 2
bit, 24 detent encoder then in position 1 we will get, for instance code
00, IIRC it will then transition through the other 3 codes until detent 1
where I think it becomes 00 and the sequence repeats between every detent .

I am traveling right now (train)  but I think i have the correct action for
the encoders i bought, they definitely sequence through the codes between
detents but my memory could be misleading me as to where they finish

I will check later

On 6 Apr 2017 3:54 pm, "Phil Keller" <philKILLspamspamEraseMEpkeller.net> wrote:

{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\07@022305 by James Cameron

flavicon
face
Detents are a human factors thing; helps the user estimate the
rotation, but they have only a statistical impact on the pulse train;
they don't prevent specific states.  Code should still expect and
handle contact noise.  A way to do that is to hide the least
significant bit, so the noise that occurs does not affect whatever
you're using the data for.

Phil wrote:
> Is the pulse a fixed width or is it base on shaft rotational speed?

For a bare encoder with A & B output only, the width of the pulses
will vary by speed of rotation; and you might be able to use the width
for something.  But it is the rising and falling edges that matter for
most purposes.

-- James Cameron
http://quozl.netrek.org/
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\07@043420 by David C Brown

picon face
My experience with cheap mechanical encoders is that the pulse width is
essentially undefined varying considerably from the tidy 50-50 shown in the
data sheets. You have to use the edges.  In fact my experience with them
has been so negative that I have reverted to using up-down push buttons
with software acceleration of the change rate

__________________________________________
David C Brown
43 Bings Road
Whaley Bridge
High Peak                           Phone: 01663 733236
Derbyshire                eMail: RemoveMEdcb.homeKILLspamspamRemoveMEgmail.com
SK23 7ND          web: http://www.bings-knowle.co.uk/dcb
<http://www.jb.man.ac.uk/~dcb>



*Sent from my etch-a-sketch*


>
> For a bare encoder with A & B output only, the width of the pulses
> will vary by speed of rotation; and you might be able to use the width
> for something.  But it is the rising and falling edges that matter for
> most purposes.
>
>
>
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\17@141519 by Phil Keller

flavicon
face
All,
  Well it looks like all things being equal, they aren't.  I purchased an incremental encoder (PEC12R Incremental Encoder) and did a little testing:
(A & B pulled to Vcc via a 10K, C connected to GND)
- The encoder puts out a single pulse for each detent position.
-- For clockwise rotation the A Signal falls while B is held high.
-- For counter-clockwise the  A Signal falls while B is held low.

POOR ASCII drawing:
Clockwise
A -----|____|-------|____|-------
B -------|_____|-------|_____|----
Counter-Clockwise
A -----|____|-------|____|-------
B ---|_____|-----|_____|--------

  No counting or multiple pulse between detents, just the phase shift between A & B that indicate the direction of rotation.

-Phil-
On 4/6/2017 7:56 AM, Phil Keller wrote:
{Quote hidden}

-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\04\17@162621 by Denny Esterline

picon face
On Mon, Apr 17, 2017 at 11:15 AM, Phil Keller <TakeThisOuTphilspampkeller.net> wrote:

> All,
>    Well it looks like all things being equal, they aren't.  I purchased
> an incremental encoder (PEC12R Incremental Encoder) and did a little
> testing:
>

Good on you. When in doubt, measure something. World would be a better
place if more people did that.




{Quote hidden}

Looks to be pretty much in line with what was discussed a couple weeks ago.

Also, note that these are mechanical encoders and - if not now, then
eventually - will suffer from contact bounce just like any other mechanical
switch. Plan now for some method of debouncing, or it will bite you in the
backside at some point.

-Denny
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

More... (looser matching)
- Last day of these posts
- In 2017 , 2018 only
- Today
- New search...