Lpc2000

Hello All,

I have concerns about a PID routine which is doing some calculations 
with 32-bit values. It uses multiply and add instructions. My concern 
about this is, how to detect overflow.

A overflow can result in a process correction with a wrong sign and this 
is not acceptable for the process. What I need in a overflow situation 
is a saturated value.

In the past I was using a 8052, multiplying 32-bit values was possible 
but it was done in a lot of 8-bit portions.
With the ARM I can do the same in one instruction but I am missing the 
overflow flag. Is there a option to detect an overflow after a multiply?

I am using the LPC2129 (ARM7)

Greetings
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@...
==============================

On 9 Aug 2005 at 16:54, Aalt Lokhorst wrote:

> Hello All,
> 
> I have concerns about a PID routine which is doing some calculations
> with 32-bit values. It uses multiply and add instructions. My concern
> about this is, how to detect overflow.
> 
> A overflow can result in a process correction with a wrong sign and
> this is not acceptable for the process. What I need in a overflow
> situation is a saturated value.
> 
> In the past I was using a 8052, multiplying 32-bit values was possible
> but it was done in a lot of 8-bit portions. With the ARM I can do the
> same in one instruction but I am missing the overflow flag. Is there a
> option to detect an overflow after a multiply?
> 
> I am using the LPC2129 (ARM7)

You can do a 32x32 bit multiply to get a 64 bit result. You can either use the 64bit result
directly or force the 32-bit answer to the maximum. If you are using gcc you
can declare your variable as a long long which is 64 bits.

Regards
  Anton Erasmus-- 
A J Erasmus

Hi,

In the general case, you're pretty much guaranteed overflow: 
multiplying two numbers of a fixed precision (e.g. 16-bits) gives a 
result twice that precision (in that case 32-bits). As another reply 
has pointed out, you can simply declare the result to have twice the 
precision of the two arguments. However, for 32-bit arguments this is 
likely to be slow, as there's no native processing of 64-bit values: 
the compiler will call an internal library function to do the math.

It might be worth your while looking at the "Enhanced DSP 
instructions" (see ARM documentation from ARM): these provide various 
forms of multiply and add, including some that saturate. The LPC2000 
series as ARM7TDMI devices support these instructions.

A final thought that strikes me is that do you really need 32-bit 
arguments? In general 16-bit is fine for most purposes as an input 
resolution. You can still accumulate at 32- or 64-bits (scaling back 
to 16-bits if further processing is required).

Hope this is of some help.

Regards
Brendan Murphy

--- In lpc2000@yahoogroups.com, "Aalt Lokhorst" <lokhorst@s...> wrote:
> Hello All,
> 
> I have concerns about a PID routine which is doing some 
calculations 
> with 32-bit values. It uses multiply and add instructions. My 
concern 
> about this is, how to detect overflow.
> 
> A overflow can result in a process correction with a wrong sign and 
this 
> is not acceptable for the process. What I need in a overflow 
situation 
> is a saturated value.
> 
> In the past I was using a 8052, multiplying 32-bit values was 
possible 
> but it was done in a lot of 8-bit portions.
> With the ARM I can do the same in one instruction but I am missing 
the 
> overflow flag. Is there a option to detect an overflow after a 
multiply?

> 
> I am using the LPC2129 (ARM7)
> 
> Greetings
> 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@S...
> ==============================

Thanks for your answers,

I have tried the solution of Anton and I think this will do the job.
(See also the resulting assembler code further in this email)

At first I was thinking about a function which should estimate the 
number of result-bits needed. (By adding the number of bits needed for 
each variable without counting the leading zero's) This would be only a 
rough estimation, see this example for two 3-bit values:

  100b * 100b =   10000b  (result 5 bit)
  111b * 111b =  110001b  (result 6 bit)

Adding the number of bits of both variables results in the worst case 
situation. This is not ideal because there are situations which need a 
bit less than the estimation shows I don't even mention the issues 
involved with negative numbers.

Even if my 'solution' would work after solving all the issues then it 
will be slow compared to a multiply with 64 bit result (and saturating 
the result to 32 bit)


Brendan Murphy wrote:
 >> However, for 32-bit arguments this is
 >> likely to be slow, as there's no native processing of 64-bit values:
 >> the compiler will call an internal library function to do the math.

A small test shows the following:

void test (void)
{
   int32_t A, B;
   int64_t C;

   A = 0x12345678;
   B = 0x11223344;
   C = (int64_t)A * (int64_t)B;
}

Results in: (code for entering and leaving the function is stripped)

   A = 0x12345678;
    	E59F3038   ldr r3, [pc, #56]              ;R3 = 0x12345678
    	E50B301C   str r3, [r11, #-28]            ;write R3 to stack

   B = 0x11223344;
    	E59F3034   ldr r3, [pc, #52]              ;R3 = 0x11223344
    	E50B3020   str r3, [r11, #-32]            ;write R3 to stack

   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.

Brendan also wrote about "Enhanced DSP instructions" for the LPC2000 
series. Such instructions are perfect for my application, but are you 
sure the LPC2000 does support these instructions? I think the ARM7 does 
not have such instructions.

And now the final question:
Do I really need 32 bit or even 64 bit intermediate results???
Well, actually almost never. My application runs fine with smaller 
numbers if the closed loop process behaves correct. 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.
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.


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@...
==============================

brendanmurphy37 wrote:

> 
> Hi,
> 
> In the general case, you're pretty much guaranteed overflow:
> multiplying two numbers of a fixed precision (e.g. 16-bits) gives a
> result twice that precision (in that case 32-bits). As another reply
> has pointed out, you can simply declare the result to have twice the
> precision of the two arguments. However, for 32-bit arguments this is
> likely to be slow, as there's no native processing of 64-bit values:
> the compiler will call an internal library function to do the math.
> 
> It might be worth your while looking at the "Enhanced DSP
> instructions" (see ARM documentation from ARM): these provide various
> forms of multiply and add, including some that saturate. The LPC2000
> series as ARM7TDMI devices support these instructions.
> 
> A final thought that strikes me is that do you really need 32-bit
> arguments? In general 16-bit is fine for most purposes as an input
> resolution. You can still accumulate at 32- or 64-bits (scaling back
> to 16-bits if further processing is required).
> 
> Hope this is of some help.
> 
> Regards
> Brendan Murphy
> 
> --- In lpc2000@yahoogroups.com, "Aalt Lokhorst" <lokhorst@s...> wrote:
>  > Hello All,
>  >
>  > I have concerns about a PID routine which is doing some
> calculations
>  > with 32-bit values. It uses multiply and add instructions. My
> concern
>  > about this is, how to detect overflow.
>  >
>  > A overflow can result in a process correction with a wrong sign and
> this
>  > is not acceptable for the process. What I need in a overflow
> situation
>  > is a saturated value.
>  >
>  > In the past I was using a 8052, multiplying 32-bit values was
> possible
>  > but it was done in a lot of 8-bit portions.
>  > With the ARM I can do the same in one instruction but I am missing
> the
>  > overflow flag. Is there a option to detect an overflow after a
> multiply?
>  >
>  > I am using the LPC2129 (ARM7)
>  >
>  > Greetings
>  > 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@S...
>  > ==============================
> 
> 
> 
> 
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
> 
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
> 
> 
> ------------------------------------------------------------------------
>

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

I stand corrected: the "smull" instruction does indeed produce a 64-
bit result.

The LPC2000 series parts definitely do have the DSP extensions: we 
use them in some of our signal processing software. I believe the "M" 
in ARM7TDMI indicates this (I could be wrong on this).

Using saturated math can get quite messy: apart from the fact that 
compilers generally don't support them well (if at all), you have to 
be very careful about downstream effects if the result is fed into 
further calculations.

I'd still be inclined to work at 16-bit values with 32-bit results, 
as some operations on 64-bit values can be quite slow. I'm making the 
assumption here that speed is of the essence: if not, there's no 
problem with just getting the compiler and processor to get on with 
it. Having said that, we've just completed a very acurate phase 
measurement system using a LPC2134 that uses 64-bit intermediate 
results, so I'm not really following my own advice.

Brendan

--- In lpc2000@yahoogroups.com, "Aalt Lokhorst" <lokhorst@s...> wrote:
> Thanks for your answers,
> 
> I have tried the solution of Anton and I think this will do the job.
> (See also the resulting assembler code further in this email)
> 
> At first I was thinking about a function which should estimate the 
> number of result-bits needed. (By adding the number of bits needed 
for 
> each variable without counting the leading zero's) This would be 
only a 
> rough estimation, see this example for two 3-bit values:
> 
>   100b * 100b =   10000b  (result 5 bit)
>   111b * 111b =  110001b  (result 6 bit)
> 
> Adding the number of bits of both variables results in the worst 
case 
> situation. This is not ideal because there are situations which 
need a 
> bit less than the estimation shows I don't even mention the issues 
> involved with negative numbers.
> 
> Even if my 'solution' would work after solving all the issues then 
it 
> will be slow compared to a multiply with 64 bit result (and 
saturating 
> the result to 32 bit)
> 
> 
> Brendan Murphy wrote:
>  >> However, for 32-bit arguments this is
>  >> likely to be slow, as there's no native processing of 64-bit 
values:
>  >> the compiler will call an internal library function to do the 
math.
> 
> A small test shows the following:
> 
> void test (void)
> {
>    int32_t A, B;
>    int64_t C;
> 
>    A = 0x12345678;
>    B = 0x11223344;
>    C = (int64_t)A * (int64_t)B;
> }
> 
> Results in: (code for entering and leaving the function is stripped)
> 
>    A = 0x12345678;
>     	E59F3038   ldr r3, [pc, #56]              ;R3 = 0x12345678
>     	E50B301C   str r3, [r11, #-28]            ;write R3 to stack
> 
>    B = 0x11223344;
>     	E59F3034   ldr r3, [pc, #52]              ;R3 = 0x11223344
>     	E50B3020   str r3, [r11, #-32]            ;write R3 to stack
> 
>    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.
> 
> Brendan also wrote about "Enhanced DSP instructions" for the 
LPC2000 
> series. Such instructions are perfect for my application, but are 
you 
> sure the LPC2000 does support these instructions? I think the ARM7 
does 
> not have such instructions.
> 
> And now the final question:
> Do I really need 32 bit or even 64 bit intermediate results???
> Well, actually almost never. My application runs fine with smaller 
> numbers if the closed loop process behaves correct. 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.
> 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.
> 
> 
> 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@S...
> ==============================
> 
> brendanmurphy37 wrote:
> > 
> > Hi,
> > 
> > In the general case, you're pretty much guaranteed overflow:
> > multiplying two numbers of a fixed precision (e.g. 16-bits) gives 
a
> > result twice that precision (in that case 32-bits). As another 
reply
> > has pointed out, you can simply declare the result to have twice 
the
> > precision of the two arguments. However, for 32-bit arguments 
this is
> > likely to be slow, as there's no native processing of 64-bit 
values:
> > the compiler will call an internal library function to do the 
math.
> > 
> > It might be worth your while looking at the "Enhanced DSP
> > instructions" (see ARM documentation from ARM): these provide 
various
> > forms of multiply and add, including some that saturate. The 
LPC2000
> > series as ARM7TDMI devices support these instructions.
> > 
> > A final thought that strikes me is that do you really need 32-bit
> > arguments? In general 16-bit is fine for most purposes as an input
> > resolution. You can still accumulate at 32- or 64-bits (scaling 
back
> > to 16-bits if further processing is required).
> > 
> > Hope this is of some help.
> > 
> > Regards
> > Brendan Murphy
> > 
> > --- In lpc2000@yahoogroups.com, "Aalt Lokhorst" <lokhorst@s...> 
wrote:
> >  > Hello All,
> >  >
> >  > I have concerns about a PID routine which is doing some
> > calculations
> >  > with 32-bit values. It uses multiply and add instructions. My
> > concern
> >  > about this is, how to detect overflow.
> >  >
> >  > A overflow can result in a process correction with a wrong 
sign and
> > this
> >  > is not acceptable for the process. What I need in a overflow
> > situation
> >  > is a saturated value.
> >  >
> >  > In the past I was using a 8052, multiplying 32-bit values was
> > possible
> >  > but it was done in a lot of 8-bit portions.
> >  > With the ARM I can do the same in one instruction but I am 
missing
> > the
> >  > overflow flag. Is there a option to detect an overflow after a
> > multiply?
> >  >
> >  > I am using the LPC2129 (ARM7)
> >  >
> >  > Greetings
> >  > 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@S...
> >  > ==============================
> > 
> > 
> > 
> > 
> > ------------------------------------------------------------------
------
> > YAHOO! GROUPS LINKS
> > 
> >     *  Visit your group "lpc2000
> >       <http://groups.yahoo.com/group/lpc2000>" on the web.
> >        
> >     *  To unsubscribe from this group, send an email to:
> >        lpc2000-unsubscribe@yahoogroups.com
> >       <mailto:lpc2000-unsubscribe@yahoogroups.com?
subject=Unsubscribe>
> >        
> >     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> >       Service <http://docs.yahoo.com/info/terms/>.
> > 
> > 
> > ------------------------------------------------------------------
------
> >

brendanmurphy37 <brendan.murphy@...> schrieb am Wed, 10 Aug 2005 
16:09:49 -0000:

>
> I stand corrected: the "smull" instruction does indeed produce a 64-
> bit result.
>
> The LPC2000 series parts definitely do have the DSP extensions: we
> use them in some of our signal processing software. I believe the "M"
> in ARM7TDMI indicates this (I could be wrong on this).
          ||||_ ?
          |||__ HW multiply
          ||___ Debug (ICE)
          |____ Thumb

-- 
42Bastian Schick

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
>