number format multiply divide in STM32H757

[vishalb1911]

Hi,

I am looking macro, in-bult function or lib to

1 - I can do 2 16-bit signed fraction number multiply or divide and result should also be in 16-bit signed fraction.

2 - define to convert any integer number (value less will be less than "1" to 16-bit) fraction number

[vishalb1911]

we are working on real time data, so scaling is not working for us

[TDK]

> 1 - I can do 2 16-bit signed fraction number multiply or divide and result should also be in 16-bit signed fraction.

In the same instruction? There isn't an instruction for that. You could make your own macro but it wouldn't be particularly fast, which seems like the goal here.

[vishalb1911]

Please suggest alternative for it, as in other mcu we get this type of functionality

[KnarfB]

> define to convert any integer number (value less will be less than "1" 

The only non-negative integer number less than 1 I know of, is 0.

Arm CMSIS-DSP is a library which supports a q15_t type calculations and conversions for 16-bit fraction numbers.

hth

KnarfB

[Ozone]

> Arm CMSIS-DSP is a library which supports a q15_t type calculations and conversions for 16-bit fraction numbers.

Would have been my suggestion, too.

As a side note, this q<nn> datatypes are natively supported by almost all DSPs, usually in the single-instruction fashion the OP asks for.
Cortex M is not a platform otimized for realtime, high-throughput applications.

[gbm]

For multiplication, (a * b) >> 16 should do. For division - go figure your school task by yourself. ;)

[bramble]

If the number you are dividing by (the divisor) is a constant, or one that changes less frequently than the numerator, then normal practice is to calculate k=1/d (where d = your divisor), save that value, then use: y = x*k (= x/d) as your real-time single cycle divide operation. You can of course wrap other scaling operations into this by using k = s / d, then y = k*x = s*x/d as a single cycle multiply and divide operation.

[Andrew Neil]

---

@vishalb1911 wrote:

we are working on real time data, so scaling is not working for us

---

That's a non-sequitur - the fact that it's real-time data does not preclude the use of scaling.

Perhaps you do have other reasons why scaling may not work in your particular application - but simply being "real time" is not one.

[Ozone]

I believe this is a veiled admission that the project management significantly underestimated the requirements, and chose a MCU with insuffient performance and resources for financial reasons. 
A recurring theme, if you ask me.