Lpc2000

Hello

Well, I think I have two solutions.

  1 Limiting and probably scaling the numbers into smaller values.
  2 Go for the 32x32 multiply and saturate the 64 bit result.

I will look into it and make a choice. Both options are Ok I think, but 
solution 2 has the advantage that I only have to limit the result. That 
is no problem because the process 'actuator' has also it limits so it 
will be 'saturated' anyway.

As Brendan already mentioned, saturated math can be messy if the results 
are used for further calculations. Indeed, this is true, preventing such 
  situations is the best solution. But if i have to choose between 
'saturation' and 'overflow with inverted sign' then i will prefer 
saturation.

Speed is also an issue for me but I have to investigate what I can 
tolerate. The difference between my 8-bit processor history and the 
32-bit ARM is so big that everything is relative. For the 8-bit 
processor I used a 32-bit multiply routine which chopped the calculation 
in several 8-bit chunks. It was written in assembly but still took a lot 
of microseconds to execute. The ARM processor does the complete multiply 
in less time than what the 8-bit processor needed to save some registers 
  in preparation of the multiply.

Last year I attended a 'Hands on Training', this was my first experience 
with the ARM processor. Olaf Pfeiffer from Embedded System Academy was 
there to present the ARM processor. (Thanks Olaf it was a nice day, I 
bet you are reading this forum) Olaf explained the letters TDMI-S:

ARM7TDMI-S

T = Thumb Instruction set
D = includes Debug extension
M = enhanced Multiplier
I = core has embeddedICE logic extensions
S = fully synthesisable (soft IP)

Thanks for your help
Aalt

-- 
==============================
Aalt Lokhorst
Schut Geometrische Meettechniek bv
Duinkerkenstraat 21
9723 BN Groningen
P.O. Box 5225
9700 GE Groningen
The Netherlands
Tel: +31-50-5877877
Fax: +31-50-5877899
E-mail: Lokhorst@...
==============================

Jerzy Lelusz wrote:
> 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
>