Lpc2000

Aalt Lokhorst wrote:
>    C = (int64_t)A * (int64_t)B;
>     	E3E0300F   mvn r3, #0x0000000F            ;some calculation of
>     	E24B2018   sub r2, r11, #0x00000018       ;stack address for
>     	E0821003   add r1, r2, r3                 ;the mul result
> 
>     	E51B201C   ldr r2, [r11, #-28]            ;get value 'A' in R2
>     	E51B3020   ldr r3, [r11, #-32]            ;get value 'B' in R3
>     	E0C65392   smull r5, r6, r2, r3           ;multiply R2*R3 and
>                                                    ;put result in R5R6
> 
>     	E1A04006   mov r4, r6                     ;R4 = Result 'High'
>     	E1A03005   mov r3, r5                     ;R3 = Result 'Low'
>     	E8810018   stmia r1, {r3-r4}              ;store result
> 
> Not a bad result I think, no library function needed.

I think it's excellent ;-)

> And now the final question:
> Do I really need 32 bit or even 64 bit intermediate results???

> But if something 
> went wrong with a setpoint, the process or the PID-parameters then the 
> error-value can increase enormous and a integrator windup might occur.

Isn't it easier just to limit error signal? So as long as error signal
is within certain limits there is no overflow. That's what I'm doing.
Also it's good to limit integration (to avoid windup problems).

> I can check for all the problematic situations but it is a lot easier if 
>    the intermediate variables have simply enough bits to hold the 'worst 
> case' results, or if I could a use a 'saturate' solution.

-- 
Jerzy Lelusz
Electronics Engineer

Geola Technologies Ltd
Sussex Innovation Centre
Science Park Square
BN1 9SB Falmer, East Sussex
United Kingdom
phone: +44 1273 704 443
fax:   +44 1273 704 477