AVR-Libc's float sqrtf takes a maximum execution time of ~500 ticks if MUL is available (MUL should not matter for sqrtf implementation) so I'd guess fixed point math is considerably faster? AVR-Libc computer 23 fractional digits which is ~22 Ticks per digit.

Unfortunately that function isn't in ASF it seems - the sensor library was initially developed by the team over in the US on a PC, and then ported to AVRs. I then ported that *again* to integrate it into ASF after the source code was approved for general release. As a result, some of the previously hidden test code is still in the library today, including stubs such as fixed_sqrt().

Actually, it looks like I can remove the fixed.h and fixed_t.h header files, since they are part of the original PC C++ code that isn't used in the AVR implementation.

- Dean

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

From the documentation I depicted that ASF comes with a reasonable complete fixed-point arithmetic, but as it appears this is not the case.

The header you nominated is part of the sensor library, which used to be distributed as a separate binary library (no source code). The fixed point code and C++ classes were part of the initial PC implementation made before the hardware was ready to ship, and wasn't meant to be used in user applications. When I did the ASF integration I just forgot to remove those header files.

Quote:

Does that part of ASF focus on filers and DSP-related stuff, or is all the arithmetics and functions and filters just stubs and interfaces that the user has to fill out?

That's the UC3 DSP library, which is very much complete and full featured; if there's something in there you are interested in seeing the full source code is in ASF.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

The ASF contains the DSPlib, optimized for AVR UC3 devices, which has the fixed point square root implementation for 16-bit and 32-bit

Ah, thanks for the pointer.

The benchmark page states that 16-bit square root takes 61 ticks.

This means that I am doing something fundamentally wrong. I am just trying to implement 0.16 square roots and the WCET is 240 ticks with 80 bytes of flash, provided the core has a MUL instruction. WIthout MUL instruction it is 340 ticks and 60 bytes flash.

Searching for an AVR benchmark to see whether my implementation performs reasonably, I came cross the the ASF manual page.

My approach does not use lookup because I strive to minimize both flash and time with reasonable balancing.

You know what algorithm the ASF uses?

I don't intend to use ASF, just want to get a feeling and orientation for typical fixed-point jobs and searched for some land marks.

From your links and from how the algorithms are implemented I depict that ASF is not intended to be used with AVR and aims at bolide devices like ARM or AVR32.

Thanks for the clarification.

ASF is targeted at UC3, XMEGA, SAM3/4 devices - so technically yes, it's targeted at AVRs, just the 32-bit and 8/16-bit hybrids. You can download the standalone package from the Atmel website and take a look yourself.

Oh dear God. First Amtel try to hoodwink people into believing that AP7000/UC3 had something to do with AVR8 by calling it AVR32 even though there is no connection whatsoever but now this appears to be claiming that SAM3/4 are "AVR" too?!? No Atmel, only in your blinkered vision of the world.

Oh dear God. First Amtel try to hoodwink people into believing that AP7000/UC3 had something to do with AVR8 by calling it AVR32 even though there is no connection whatsoever but now this appears to be claiming that SAM3/4 are "AVR" too?!? No Atmel, only in your blinkered vision of the world.

I meant it was targeted at AVRs, but not exclusively. SAM (ARM) devices are very much not part of the AVR brand. No need to jump to conclusions without reading.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Dean re-read your first sentence. I don't see any other interpretation??

Quote:

ASF is targeted at UC3, XMEGA, SAM3/4 devices
it's targeted at AVRs, just the 32-bit and 8/16-bit hybrids.

Well I take 8/16-bit hybrid in that to mean Xmega (the 16bit thing is a bit of a stretch by the way ;-)). The rest seems to be saying that UC3 and SAM3/4 devices are "32-bit AVRs". How else could one read this?

Notice "megaAVR". You might add this to the list of things to talk about with the Atmel web team.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Pretty much all of globals Apps is contributing in some way - this way we have a set of standard device peripheral drivers, services and component drivers and around 2000 examples which users can use, rather than just a hundred or so application notes (which are still being produced in some number).

Quote:

Dean re-read your first sentence. I don't see any other interpretation??

I suppose it was open to interpretation somewhat - I meant that "ASF support includes the subset of XMEGA and UC3, which are AVRs, as well as other devices". My apologies.

Quote:

Notice "megaAVR". You might add this to the list of things to talk about with the Atmel web team.

As I said above, technically this is true as we have a very small set of MEGA AVR modules. However, this is currently very limited so I didn't want anyone to get prematurely excited and then have their hopes dashed.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!