Yahoo Groups archive
Thread
2012-01-25 by Mike Bronosky
Checking with a sales rep would be a great idea. http://www2.atmel.com/about/contact/default.aspx?contactType=Atmel+Sales+Office You can probably get some free samples to get you started. -- Linux since March 2004 www.counter.li.org Registered Linux User: #482134 Taking up Linux Ubuntu and give-up the Windos habit. Hasta la Vista, Baby. I won't be back! [Non-text portions of this message have been removed]
2012-01-25 by tim gilbert
Rule #1 of product development: don't design in parts that are hard to get! If the major distributors don't stock it; don't use it. Customers tend to get upset when their production runs get delayed because you used a non-stocked part. Free sample are nice, but I want to know that I can get parts when needed and not have to wait 12 weeks for the factory to ship. Regards, Tim Gilbert JEM Innovation Inc. 303-926-9053 (office) 303-437-4342 (cell) www.jeminnovation.com www.pdksolutions.com
----- Original Message -----
From: Mike Bronosky
To: AVR-Chat@yahoogroups.com
Sent: Wednesday, January 25, 2012 11:08 AM
Subject: [AVR-Chat] Re: aviation use of atmega's
Checking with a sales rep would be a great idea.
http://www2.atmel.com/about/contact/default.aspx?contactType=Atmel+Sales+Office
You can probably get some free samples to get you started.
--
Linux since March 2004
www.counter.li.org
Registered Linux User: #482134
Taking up Linux Ubuntu and give-up the Windos habit.
Hasta la Vista, Baby. I won't be back!
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]2012-01-25 by wagnerj@proaxis.com
Arrow has 1,730 of ATmega88-15AD. I would call them a "major distributor". However, the spec'd "Absolute Maximum" of -55C to +150C is not matched by the spec sheet data which only covers the range of -40C to +150C. Bummers! Jim Wagner Oregon Research Electronics
> Rule #1 of product development: don't design in parts that are hard to > get! If the major distributors don't stock it; don't use it. Customers > tend to get upset when their production runs get delayed because you used > a non-stocked part. > > Free sample are nice, but I want to know that I can get parts when needed > and not have to wait 12 weeks for the factory to ship. > > Regards, > > > Tim Gilbert > JEM Innovation Inc. > 303-926-9053 (office) > 303-437-4342 (cell) > www.jeminnovation.com > www.pdksolutions.com > > > ----- Original Message ----- > From: Mike Bronosky > To: AVR-Chat@yahoogroups.com > Sent: Wednesday, January 25, 2012 11:08 AM > Subject: [AVR-Chat] Re: aviation use of atmega's > > > > Checking with a sales rep would be a great idea. > http://www2.atmel.com/about/contact/default.aspx?contactType=Atmel+Sales+Office > You can probably get some free samples to get you started. > > -- > Linux since March 2004 > www.counter.li.org > Registered Linux User: #482134 > Taking up Linux Ubuntu and give-up the Windos habit. > Hasta la Vista, Baby. I won't be back! > > [Non-text portions of this message have been removed] > > > > > > [Non-text portions of this message have been removed] > >
2012-01-26 by Alex A
Actually, if you want to look for the automotive grade parts, look at something like part number ATmega168-15AZ. These are the rated more for the upper end of the scale rather than the lower end. When the data sheet says Absolute Maximum, these are the specs that the vendor will guarantee the part. However, the Atmel datasheet also states "Exposure to absolute maximum rating conditions for extended periods may affect device reliability." This is pretty much the case for any vendor you look at. --- In AVR-Chat@yahoogroups.com, wagnerj@... wrote:
> > Arrow has 1,730 of ATmega88-15AD. I would call them a "major distributor". > > However, the spec'd "Absolute Maximum" of -55C to +150C is not matched by > the spec sheet data which only covers the range of -40C to +150C. Bummers! > > Jim Wagner > Oregon Research Electronics > > > Rule #1 of product development: don't design in parts that are hard to > > get! If the major distributors don't stock it; don't use it. Customers > > tend to get upset when their production runs get delayed because you used > > a non-stocked part. > > > > Free sample are nice, but I want to know that I can get parts when needed > > and not have to wait 12 weeks for the factory to ship. > > > > Regards, > > > > > > Tim Gilbert > > JEM Innovation Inc. > > 303-926-9053 (office) > > 303-437-4342 (cell) > > www.jeminnovation.com > > www.pdksolutions.com > > > > > > ----- Original Message ----- > > From: Mike Bronosky > > To: AVR-Chat@yahoogroups.com > > Sent: Wednesday, January 25, 2012 11:08 AM > > Subject: [AVR-Chat] Re: aviation use of atmega's > > > > > > > > Checking with a sales rep would be a great idea. > > http://www2.atmel.com/about/contact/default.aspx?contactType=Atmel+Sales+Office > > You can probably get some free samples to get you started. > > > > -- > > Linux since March 2004 > > www.counter.li.org > > Registered Linux User: #482134 > > Taking up Linux Ubuntu and give-up the Windos habit. > > Hasta la Vista, Baby. I won't be back! > > > > [Non-text portions of this message have been removed] > > > > > > > > > > > > [Non-text portions of this message have been removed] > > > > >
2012-03-26 by Don Kinzer
--- In AVR-Chat@yahoogroups.com, fireweaver <firewevr@...> wrote: > Can I somehow tell the C compiler that comes with AVR > Studio that these certain five registers are reserved > for the exclusive use of the decoder and therefore avoid > using them in any way? In general, no. It is possible to "reserve" any of the registers r2 to r7 but doing so requires great care in constructing your application so that *no other code* uses the reserved registers. In particular, this means that the register reservation must be specified in every module comprising your application and, further, that you either avoid using any of the AVR-libc routines or confirm that the ones that you do use do not use your chosen reserved registers. Note, too, that you must perform this confirmation exercise for *every* new release of AVR libc because register allocation may change with each release. This question has been posed many times on the AVR Freaks forum. The strategy is generally discouraged because of the potential problems. Don Kinzer ZBasic Microcontrollers http://www.zbasic.net
2012-03-26 by David Kelly
On Mar 26, 2012, at 2:57 PM, fireweaver wrote: > > I have a question of some concern to me, perhaps you could help. > > In overview, it involves mixing assembly language and C code. > > In detail: > > The CPU that I am using is ATmega328 using AVR Studio 5 as a development > environment. > > I an writing a motor control application that involves a quadrature encoder > attached to the motor shaft and a corresponding decoder with the following > characteristics: > > [1] The decoder itself is implemented entirely in assembly language. > [2] All the rest of the application will be written in C. > [3] It maintains a running 24-bit count of the encoder's position. > [4] It will be called by a periodic interrupt at 25 kHz sample rate. > [5] THE DECODER RESERVES FIVE OF THE MACHINE REGISTERS FOR ITS EXCLUSIVE > USE. > This is the big deal I want to question you about. > > What I want to do is this: Can I somehow tell the C compiler that comes > with AVR Studio that these certain five registers are reserved for the exclusive > use of the decoder and therefore avoid using them in any way? Question for you: Why are you so determined to implement the decoder in assembly? What evidence do you have to support the additional effort and future difficulty in maintaining the code? The biggest compromise I see to use C is that the counter will be 32 bits. If you must, let C calculate to 32 bits and then chop it down to 24. You can use a mask to reach the high 8 bits, or overlay the 32 bits with a bitfield. Don't worry about the "5 dedicated registers". Use static variables in C and if they have to be stashed in RAM then let them. Its a machine, its not going to complain about repetitive tasks. And as a machine if its fast enough to get the job done, and done correctly, then don't sweat the details. -- David Kelly N4HHE, dkelly@HiWAAY.net ============================================================ Whom computers would destroy, they must first drive mad.
2012-03-26 by Don Kinzer
--- In AVR-Chat@yahoogroups.com, fireweaver <firewevr@...> wrote: > The decoder I have does its thing in about 28 cycles. As a C > interrupt routine, it is well over 100 cycles and may not be > able to keep up with the encoder. If you are willing to post the existing assembly code and provide an upper limit on the number of cycles that is acceptable, I expect that you would have several people rise to the challenge to make it avr-gcc compatible or re-implement it so that it is compatible. Don Kinzer ZBasic Microcontrollers http://www.zbasic.net
2012-03-26 by fireweaver
I have a question of some concern to me, perhaps you could help.
In overview, it involves mixing assembly language and C code.
In detail:
The CPU that I am using is ATmega328 using AVR Studio 5 as a development
environment.
I an writing a motor control application that involves a quadrature encoder
attached to the motor shaft and a corresponding decoder with the following
characteristics:
[1] The decoder itself is implemented entirely in assembly language.
[2] All the rest of the application will be written in C.
[3] It maintains a running 24-bit count of the encoder's position.
[4] It will be called by a periodic interrupt at 25 kHz sample rate.
[5] THE DECODER RESERVES FIVE OF THE MACHINE REGISTERS FOR ITS EXCLUSIVE
USE.
This is the big deal I want to question you about.
What I want to do is this: Can I somehow tell the C compiler that comes
with AVR
Studio that these certain five registers are reserved for the exclusive
use of the
decoder and therefore avoid using them in any way?
erikc2012-03-26 by fireweaver
On 3/26/2012 1:33 PM, David Kelly wrote: > On Mar 26, 2012, at 2:57 PM, fireweaver wrote: > >> I have a question of some concern to me, perhaps you could help. >> >> In overview, it involves mixing assembly language and C code. >> >> In detail: >> >> The CPU that I am using is ATmega328 using AVR Studio 5 as a development >> environment. >> >> I an writing a motor control application that involves a quadrature encoder >> attached to the motor shaft and a corresponding decoder with the following >> characteristics: >> >> [1] The decoder itself is implemented entirely in assembly language. >> [2] All the rest of the application will be written in C. >> [3] It maintains a running 24-bit count of the encoder's position. >> [4] It will be called by a periodic interrupt at 25 kHz sample rate. >> [5] THE DECODER RESERVES FIVE OF THE MACHINE REGISTERS FOR ITS EXCLUSIVE >> USE. >> This is the big deal I want to question you about. >> >> What I want to do is this: Can I somehow tell the C compiler that comes >> with AVR Studio that these certain five registers are reserved for the exclusive >> use of the decoder and therefore avoid using them in any way? > Question for you: Why are you so determined to implement the decoder in assembly? What evidence do you have to support the additional effort and future difficulty in maintaining the code? This is a one off hobby project. I am retired and living within a very tight budget, so buying a dedicated decoder chip like this one below would hurt. http://www.avagotech.com/pages/en/motion_control_encoder_products/integrated_circuits/decoder_ic/hctl-2022/ The decoder was originally created (in a two-channel version) to act as a digital readout for a milling machine. I used rotary encoders attached to the table leadscrews to generate the count pulses. That project was 100% assembler (for small code size - originally written for an ATTiny2313). It works very well. The motor control thing is mainly experimental. I suppose I could talk an ATTiny part into doing the decoder function, it is an idea worth considering, At least they're in my price range. > > The biggest compromise I see to use C is that the counter will be 32 bits. If you must, let C calculate to 32 bits and then chop it down to 24. You can use a mask to reach the high 8 bits, or overlay the 32 bits with a bitfield. > > Don't worry about the "5 dedicated registers". Use static variables in C and if they have to be stashed in RAM then let them. Its a machine, its not going to complain about repetitive tasks. And as a machine if its fast enough to get the job done, and done correctly, then don't sweat the details. Implementing the decoder in C would just massively slow things down. I'll try it but I think there will be problems. The decoder I have does its thing in about 28 cycles. As a C interrupt routine, it is well over 100 cycles and may not be able to keep up with the encoder. On second thought, perhaps by dividing the task among more than one processor might be a good way to go.
> > -- > David Kelly N4HHE, dkelly@HiWAAY.net > ============================================================ > Whom computers would destroy, they must first drive mad. > > > > > > ------------------------------------ > > Yahoo! Groups Links > > > >
2012-03-27 by fireweaver
On 3/26/2012 3:46 PM, Don Kinzer wrote:
> --- In AVR-Chat@yahoogroups.com, fireweaver<firewevr@...> wrote:
>> The decoder I have does its thing in about 28 cycles. As a C
>> interrupt routine, it is well over 100 cycles and may not be
>> able to keep up with the encoder.
> If you are willing to post the existing assembly code and provide an upper limit on the number of cycles that is acceptable, I expect that you would have several people rise to the challenge to make it avr-gcc compatible or re-implement it so that it is compatible.
>
> Don Kinzer
> ZBasic Microcontrollers
> http://www.zbasic.net
>
Here is the code. I don't know how this will appear since the group
forbids attachments.
Use a fixed width font like Courier to make it look right.
The general idea is to control a motor which can run up to 3000 RPM. It
has an built-in
encoder with 400 counts (at 4X) per revolution.
; SINGLE CHANNEL QUADRATURE DECODER
;*******************************************************************************;
;
;
; This is the quadrature decoder. This decoder is designed to decode
two ;
; channels to a resolution of one part in 2^24. It is designed to run
as fast ;
; as
possible. ;
;
;
; Selling
points: ;
; 1. One channel to 24-bit
precision. ;
; 2. Very fast execution time = 25 cycles worst
case. ;
; 3. Small code
size. ;
; 4. Extensible to more channels (as dedicated
encoder) ;
; Weak
points: ;
; 1. Commandeers 4 registers for its own
use. ;
;
;
;*******************************************************************************;
.include "m168Adef.inc"
;*******************************************************************************;
; Defined by original
project ;
;
ATmega168 ;
;
/----U----\ ;
; PC6 | 01 28 |
PC5 ;
; (X-axis I in) PD0 | 02 27 |
PC4 ;
; (X-axis Q in) PD1 | 03 26 |
PC3 ;
; (X error out) PD2 | 04 25 |
PC2 ;
; PD3 | 05 24 |
PC1 ;
; PD4 | 06 23 |
PC0 ;
; VCC | 07 22 |
GND ;
; GND | 08 21 |
AREF ;
; PB6 | 09 20 |
AVCC ;
; PB7 | 10 19 |
PB5 ;
; PD5 | 11 18 |
PB4 ;
; PD6 | 12 17 |
PB3 ;
; (duty cycle) PD7 | 13 16 |
PB2 ;
; PB0 | 14 15 |
PB1 ;
;
\---------/ ;
;
;
; (duty cycle) is used to see how long the routine
runs ;
;
;
;
;
; PORTD bits are laid out as
follows: ;
.equ CH_X0 = PD0 ; Channel A inphase in
.equ CH_X1 = PD1 ; Channel A quadrature in
.equ ERR_X = PD2 ; Channel A error signal out
.equ OC2B = PD3 ; Timer overflow bit (diagnostic output).
.equ Q_DEBUG = PD7 ; Duty cycle informs on CPU usage ()
;
;
; Reserved register
assignments. ;
;
;
; Encoder
management ;
.def encoder_state = R9
; X-count accumulator (dedicated to
encoder) ;
.def X_count_0 = R21 ; low byte
.def X_count_1 = R22
.def X_count_2 = R23 ; high byte
; This code is may be located anywhere in
memory. ;
;
;
; _______ ___________ _______ ___
___ ;
; A |___/ | \___|___/ | | \___|___/ | \___/ \___|___/
\___/ ;
; | | |___|___| | |___| | |___|___| | |___| |___|
|___ ;
; B \___|___/ | \___|___/ \___|___/ | \___|___/ \___/
\___/ \ ;
; -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6 ? ? OK
? ? ;
;
;
; | normal operation | error
codes | ;
; ? = Error, K =
Okay ;
;
;
; The encoder is periodically sampled. Each sample is compared to the
previous ;
; sample giving one of 16 possible choices. These choices funnel into
four ;
; possible actions, depending on how the bits change between
samples. ;
; Sampling rate is required to be at least twice the rate of incoming
encoder ;
; pulses to ensure accurate
counting. ;
;
;
; These actions
are: ;
; Increment - add one to the count
register ;
; Decrement - subtract one from the count
register ;
; Idle - inputs did not change, do
nothing ;
; Error - should never happen, both inputs changed at the same
time. ;
; If the error signal comes and goes, it is a sign that
the input ;
; is changing too fast for the decoder to keep up
with. ;
;
;
; A,B
A,B ;
; Was Is Do
This ;
;
------------------------------
;
; 00 00
idle ;
; 00 01
increment ;
; 00 10
decrement ;
; 00 11
error ;
;
;
; 01 00
decrement ;
; 01 01
idle ;
; 01 10
error ;
; 01 11
increment ;
;
;
;
;
; 10 00
increment ;
; 10 01
error ;
; 10 10
idle ;
; 10 11
decrement ;
;
;
; 11 00
error ;
; 11 01
decrement ;
; 11 10
increment ;
; 11 11
idle ;
;*******************************************************************************;
.cseg
.org 0x100
Quadrature_Decoder:
; do all preparation in advance ;(cycles)
lsr encoder_state ;(1) current X,Z state becomes
previous
in ZH,PIND ;(1) sample the inputs once
; update the state of the X-input
bst ZH,CH_X1 ;(1)
bld encoder_state,1 ;(1)
bst ZH,CH_X0 ;(1)
bld encoder_state,3 ;(1) copy port bits to current
X state
;
decode_X:
ldi ZH,high( X_actions) ;(1) load once, doesn't change.
mov ZL,encoder_state ;(1)
andi ZL,15 ;(1)
subi ZL,0xFF-low(X_actions) ;(1)
ijmp ;(2) do an X action
;
X_actions:
.db low(X_idle), low(X_increment), low(X_decrement),
low(X_error)
.db low(X_decrement), low(X_idle), low(X_error),
low(X_increment)
.db low(X_increment), low(X_error), low(X_idle),
low(X_decrement)
.db low(X_error), low(X_decrement), low(X_increment),
low(X_idle)
X_error: ; both inputs changed at same time, or encoder turning too fast.
sbi PORTD,ERR_X ;(2) "X error" = 1
X_idle: ; not moving
reti ;(2)
X_increment: ; counting up
cbi PORTD,ERR_X ;(2) "X error" = 0
subi X_count_0,low(-1) ;(1)
sbci X_count_1,byte2(-1) ;(1)
sbci X_count_2,byte3(-1) ;(1)
reti ;(4) longest path = (13)
X_decrement: ; counting down
cbi PORTD,ERR_X ;(2) "X error" = 0
subi X_count_0,low(1) ;(1)
sbci X_count_1,byte2(1) ;(1)
sbci X_count_2,byte3(1) ;(1)
reti ;(4)
;*******************************************************************************;
; End of
decoder ;
;*******************************************************************************;
;AVRASM: AVR macro assembler 2.1.43 (build 48 May 30 2011 10:07:37)
;Copyright (C) 1995-2011 ATMEL Corporation
;
;D:\videos\quadrature_encoder_1_1.s(20): Including file
'D:\videos\m168Adef.inc'
;
;ATmega168A memory use summary [bytes]:
;Segment Begin End Code Data Used Size Use%
;---------------------------------------------------------------
;[.cseg] 0x000200 0x00023e 46 16 62 16384 0.4%
;[.dseg] 0x000100 0x000100 0 0 0 1024 0.0%
;[.eseg] 0x000000 0x000000 0 0 0 512 0.0%
;
;Assembly complete, 0 errors. 0 warnings
erikc2012-03-27 by Don Kinzer
--- In AVR-Chat@yahoogroups.com, fireweaver <firewevr@...> wrote: > I don't know how this will appear since the > group forbids attachments. It got quite mangled, of course. If you don't have a server where you can store files you can use a service like DropBox. An account with a 2GB limit is free. I converted your code to an avr-gcc compatible ISR. As you surmised, it did grow in size and number of cycles. If I counted correctly, the worst case is 70 cycles, not counting the cycles to get into the ISR. It is also about twice the size of your original code. You can see the code (untested) here: http://dl.dropbox.com/u/43035239/decoder.S Incidentally, unless I'm missing something, the code sequence below from your post doesn't do what you intend. It looks like the code is supposed to load an offset from the table, selected by the combined previous state/next state, and then jump to that offset. However, the LPM instruction to actually load from Flash is missing. As it stands, the code will jump to a table entry and start executing but the table contains offsets, not instructions. >ldi ZH,high( X_actions) >mov ZL,encoder_state >andi ZL,15 >subi ZL,0xFF-low(X_actions) >ijmp Don Kinzer ZBasic Microcontrollers http://www.zbasic.net
2012-03-27 by Don Kinzer
--- In AVR-Chat@yahoogroups.com, fireweaver <firewevr@...> wrote: > So I should write: > subi ZL,0xFF-low(X_actions) > lpm ZL,Z ;<--- > ijmp Yes, if you want to load the value from the table entry into ZL. Also, I suspect that the instruction preceding the lpm should actually be subi ZL,0-low(X_actions) This subtracts the negative of the low byte of the X_actions address, effectively adding the low byte of the X_actions address. I thought you said (or perhaps I inferred) that this code was working. It doesn't seem that that is so. Don Kinzer ZBasic Microcontrollers http://www.zbasic.net
2012-03-27 by fireweaver
On 3/27/2012 9:27 AM, Don Kinzer wrote: > > > --- In AVR-Chat@yahoogroups.com, fireweaver<firewevr@...> wrote: >> I don't know how this will appear since the >> group forbids attachments. > It got quite mangled, of course. If you don't have a server where you can store files you can use a service like DropBox. An account with a 2GB limit is free. > > I converted your code to an avr-gcc compatible ISR. As you surmised, it did grow in size and number of cycles. If I counted correctly, the worst case is 70 cycles, not counting the cycles to get into the ISR. It is also about twice the size of your original code. You can see the code (untested) here: > http://dl.dropbox.com/u/43035239/decoder.S > > Incidentally, unless I'm missing something, the code sequence below from your post doesn't do what you intend. It looks like the code is supposed to load an offset from the table, selected by the combined previous state/next state, and then jump to that offset. However, the LPM instruction to actually load from Flash is missing. As it stands, the code will jump to a table entry and start executing but the table contains offsets, not instructions. > >> ldi ZH,high( X_actions) >> mov ZL,encoder_state >> andi ZL,15 >> subi ZL,0xFF-low(X_actions) >> ijmp > Don Kinzer > ZBasic Microcontrollers > http://www.zbasic.net So I should write: ldi ZH,high( X_actions) mov ZL,encoder_state andi ZL,15 subi ZL,0xFF-low(X_actions) lpm ZL,Z ;<--- ijmp ??? The intent is to do a case jump to one of the four action routines. erikc
2012-03-28 by Don Kinzer
--- In AVR-Chat@yahoogroups.com, fireweaver <firewevr@...> wrote: >This is the version that I am using in my DRO. It would be a lot more convenient for those trying to help you if you would put the file on DropBox or some other server so that it can be accesses with the formatting preserved. Don Kinzer ZBasic Microcontrollers http://www.zbasic.net
2012-03-28 by fireweaver
On 3/27/2012 11:43 AM, Don Kinzer wrote:
> --- In AVR-Chat@yahoogroups.com, fireweaver<firewevr@...> wrote:
>> So I should write:
>> subi ZL,0xFF-low(X_actions)
>> lpm ZL,Z ;<---
>> ijmp
> Yes, if you want to load the value from the table entry into ZL. Also, I suspect that the instruction preceding the lpm should actually be
>
> subi ZL,0-low(X_actions)
>
> This subtracts the negative of the low byte of the X_actions address, effectively adding the low byte of the X_actions address.
>
> I thought you said (or perhaps I inferred) that this code was working. It doesn't seem that that is so.
>
> Don Kinzer
I screwed up and sent the wrong code. This is the version that I am
using in my DRO.
What I sent you was an attempt to compress it even further. My bad.
===begin code===
; SINGLE CHANNEL QUADRATURE DECODER
;*******************************************************************************;
;
;
; This is the quadrature decoder. This decoder is designed to decode
two ;
; channels to a resolution of one part in 2^24. It is designed to run
as fast ;
; as
possible. ;
;
;
; Selling
points: ;
; 1. One channel to 24-bit
precision. ;
; 2. Very fast execution time = 25 cycles worst
case. ;
; 3. Small code
size. ;
; 4. Extensible to more channels (as dedicated
encoder) ;
; Weak
points: ;
; 1. Commandeers 4 registers for its own
use. ;
;
;
;*******************************************************************************;
;.include "m168Adef.inc"
;*******************************************************************************;
; Defined by original
project ;
;
ATmega168 ;
;
/----U----\ ;
; PC6 | 01 28 |
PC5 ;
; (X-axis I in) PD0 | 02 27 |
PC4 ;
; (X-axis Q in) PD1 | 03 26 |
PC3 ;
; (X error out) PD2 | 04 25 |
PC2 ;
; PD3 | 05 24 |
PC1 ;
; PD4 | 06 23 |
PC0 ;
; VCC | 07 22 |
GND ;
; GND | 08 21 |
AREF ;
; PB6 | 09 20 |
AVCC ;
; PB7 | 10 19 |
PB5 ;
; PD5 | 11 18 |
PB4 ;
; PD6 | 12 17 |
PB3 ;
; (duty cycle) PD7 | 13 16 |
PB2 ;
; PB0 | 14 15 |
PB1 ;
;
\---------/ ;
;
;
;
;
;
;
; PORTD bits are laid out as
follows: ;
.equ CH_X0 = PD0 ; Channel A inphase in
.equ CH_X1 = PD1 ; Channel A quadrature in
.equ ERR_X = PD2 ; Channel A error signal out
.equ Q_DEBUG = PD7 ; Duty cycle informs on CPU usage out
;
;
; Reserved register
assignments. ;
;
;
; Encoder
management ;
.def encoder_state = R16
; X-count accumulator (dedicated to
encoder) ;
.def X_count_0 = r26 ; low byte
.def X_count_1 = r27
.def X_count_2 = r28 ; high byte
; This code is may be located anywhere in
memory. ;
;
;
; _______ ___________ _______ ___
___ ;
; A |___/ | \___|___/ | | \___|___/ | \___/ \___|___/
\___/ ;
; | | |___|___| | |___| | |___|___| | |___| |___|
|___ ;
; B \___|___/ | \___|___/ \___|___/ | \___|___/ \___/
\___/ \ ;
; -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6 ? ? OK
? ? ;
;
;
; | normal operation | error
codes | ;
; ? = Error, K =
Okay ;
;
;
; The encoder is periodically sampled. Each sample is compared to the
previous ;
; sample giving one of 16 possible choices. These choices funnel into
four ;
; possible actions, depending on how the bits change between
samples. ;
; Sampling rate is required to be at least twice the rate of incoming
encoder ;
; pulses to ensure accurate
counting. ;
;
;
; These actions
are: ;
; Increment - add one to the count
register ;
; Decrement - subtract one from the count
register ;
; Idle - inputs did not change, do
nothing ;
; Error - should never happen, both inputs changed at the same
time. ;
; If the error signal comes and goes, it is a sign that
the input ;
; is changing too fast for the decoder to keep up
with. ;
;
;
; A = old phase A, B = old phase
B ;
; a = new phase A, b = new phase
B ;
;
;
; Aa
Bb ;
;
------------------------------
;
; 00 00
idle ;
; 00 01
up ;
; 00 10
down ;
; 00 11
idle ;
;
;
; 01 00
down ;
; 01 01
error ;
; 01 10
error ;
; 01 11
up ;
;
;
; 10 00
up ;
; 10 01
error ;
; 10 10
error ;
; 10 11
down ;
;
;
; 11 00
idle ;
; 11 01
down ;
; 11 10
up ;
; 11 11
idle ;
;*******************************************************************************;
.cseg
.org 0x100
;
Quadrature_Decoder:
; do all preparation in advance ;(cycles)
lsl encoder_state ; 00000B0A -> 0000B0A0
in ZH,PIND ;(1) sample the inputs once
; update the state of the X-input
bst ZH,0 ; read A
bld encoder_state,0 ; 0000B0A0 -> 0000B0Aa
bst ZH,1 ; read B
bld encoder_state,2 ; 0000B0Aa -> 0000BbAa
andi encoder_state,15 ; trim encoder state
;
decode_X:
ldi ZH,high( X_actions) ;(1) load once, doesn't change.
mov ZL,encoder_state ;(1)
subi ZL,-low(X_actions) ;(1)
ijmp ;(2) do an X action
;
X_actions:
rjmp X_idle
rjmp X_increment
rjmp X_decrement
rjmp X_idle
;
rjmp X_decrement
rjmp X_error
rjmp X_error
rjmp X_increment
;
rjmp X_increment
rjmp X_error
rjmp X_error
rjmp X_decrement
;
rjmp X_idle
rjmp X_decrement
rjmp X_increment
rjmp X_idle
;
X_error: ; both inputs changed at same time, or encoder turning too fast.
sbi PORTD,ERR_X ;(2) "X error" = 1
X_idle: ; not moving
reti ;(4)
X_increment: ; counting up
cbi PORTD,ERR_X ;(2) "X error" = 0
subi X_count_0,low(-1) ;(1)
sbci X_count_1,byte2(-1) ;(1)
sbci X_count_2,byte3(-1) ;(1)
reti ;(4)
X_decrement: ; counting down
cbi PORTD,ERR_X ;(2) "X error" = 0
subi X_count_0,low(1) ;(1)
sbci X_count_1,byte2(1) ;(1)
sbci X_count_2,byte3(1) ;(1)
reti ;(4)
===end code===
erikc2012-03-28 by fireweaver
On 3/27/2012 8:30 PM, Don Kinzer wrote: > --- In AVR-Chat@yahoogroups.com, fireweaver<firewevr@...> wrote: >> This is the version that I am using in my DRO. > It would be a lot more convenient for those trying to help you if you would put the file on DropBox or some other server so that it can be accesses with the formatting preserved. > > Don Kinzer http://dl.dropbox.com/u/69622804/quadrature_encoder_1_0.s is where you will find it. Thanks for the tio. erikc