AVR Freaks

Trying to find out how many clock cycles it takes for atmega32u4 to multiply two unsigned 16 bits integers to an 32 bits integer?

As you note, there is no 'instruction' for that.  Rather, code must work 8-bits at a time.

The general method for multiplying multi-byte operands is the same as for pencil-and-paper multiplication in decimal.

For two 2-byte unsigned operands:

• multiply the low bytes of each operand together, get a 16-bit result,
• move that into lower 16-bits of a 32-bit accumulator
• clear the higher 16-bits of the 32-bit accumulator
• multply the low byte of operand A with the high byte of operand B, get a 16-bit result
• shift that result left by 8 bits, add that to the 32-bit accumulator
• multply the high byte of operand A with the low byte of operand B, get a 16-bit result
• shift that result left by 8 bits, add that to the 32-bit accumulator
• multply the high byte of operand A with the high byte of operand B, get a 16-bit result
• shift that result left by 16 bits, add that to the 32-bit accumulator

A naive approach might be:

; operand A in r17:16
; operand B in r19:18
; result in r23:20
; r2 used as zero

    clr     r2          ; our zero          ; 1
    mul     r16, r18    ; LSB A x LSB B     ; 2
    movw    r20, r0     ; to accumulator    ; 1
    mov     r22, r2     ; clr 2 MSB of acc  ; 1
    mov     r23, r2     ; "                 ; 1
    mul     r16, r19    ; LSB A x MSB B     ; 2
    add     r21, r0     ; accumulate        ; 1
    adc     r22, r1     ; "                 ; 1
    adc     r23, r2     ; "                 ; 1
    mul     r17, r18    ; MSB A x LSB B     ; 2
    add     r21, r0     ; accumulate        ; 1
    adc     r22, r1     ; "                 ; 1
    adc     r23, r2     ; "                 ; 1
    mul     r17, r19    ; MSB A x MSB B     ; 2
    add     r22, r0     ; accumulate        ; 1
    adc     r23, r1     ; "                 ; 1
                                            ; 20 total

20 cycles, but there is some opportunity to improve that.

The AVR lacks a multiply-and-accumulate instruction, so multiplying multi-byte operand incurs extra cycles for the addition of terms.

This has all been covered ad nauseam.  Search with Google or withing these fora.  Different toolchains will implement multiply in different ways.  Note that a 16x16=32 multiply is not supported by the C standard.  Binary operators will promote operands according to the rules of promotion, making them the same width and type, then perform the operation at the same width as the promoted operands.  So a 16x16 will always yield a 16.

Maybe you could tell us what your end goal is, and a bit more about your development environment (toolchain, device, etc.)

void glide(uint16_t in, uint16_t & out)
{
  static uint16_t accumilator = 0;
  uint16_t factor = analogRead(KNOB_1_PIN);
  else if(in==out) return;
  out = ((uint32_t)accumilator * (1024 - factor)) >> 10;
  accumilator = accumilator - out + in;
}

Huh?  Are those typos?  Please tell me you're not retyping code into a post.  Never do that.  You will get it wrong, and we will chase our tails.  Only ever copy/paste code from your IDE into a post.

OK, so you're maintaining a 16-bit accumulator (not accumilator), then you cast it to 32-bit before multiplying with a term which could be anywhere from 1 to 1024.  That's fine, it will fit into 32 bits no problem.  Then you divide that result by 1024, so that result will never be any larger than the original value of your accumulator, which is good because you're assigning that result to the 16-bit argument out.

However, you then adjust accumulator by subtracting the (new) value of out and adding the value of in.

Let's go over what happens when factor is small, say 0:  out will equal accumulator, and then accumulator will equal in.  Is that what you want?

Say what is happening.  Say what you want to happen.  You say you want to scale accumulator.  Looks like that's what you're doing.

So why are you concerned about cycles?

As I've said a few times in the past, I know enough C++ to get my face slapped at a party ;-)

A quick, empirical, way to figure out how long it takes (time, rather than cycles) is to toggle a pin at start & end of the process - then just measure the time.