AVR-Chat

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