3
\$\begingroup\$

On an arduino project I'm working on (ATMega328 at the moment) I have a bunch of vector distance data that I need to use for various pixels in a matrix.

It's a relatively simple calculation:

d = math.sqrt(math.pow(x2 - x1, 4) + math.pow(y2 - y1, 2)) //Not the arduino code

Very slightly modified coordinate distance formula (with exaggerated x values)

I know that a modern computer can do that easily, but is this going to be any slower or faster than having the values for a 22x12 matrix stored as a PROGMEM 2-D array of uchar? (x1 and y1 are fixed at the center point... so one grid only).

These values are basically fixed, I just need to know them. I know that accessing values in flash is much slower than in SRAM but not really sure how many clock cycles that's going to take compared to the above equation. An AVR isn't exactly optimized for such math.

Update: Also, it's not like I only need to look up some of the vector distance values on each pass. On every loop I need ALL of those values.

\$\endgroup\$
5
  • 1
    \$\begingroup\$ Less than not optimized...floating point ops are entirely absent in the AVR. You can perform floating point calculations sure, by including a floating point library which won't fit except on the bigger ATMegas, and isn't fast by any measure. Have you considered fixed point math? \$\endgroup\$
    – Phil Frost
    Jan 22 '13 at 19:11
  • \$\begingroup\$ Well, I guess it would just use the Math.h pow and square functions... not sure how fast those are. Maybe not really floating point in the strictest sense... \$\endgroup\$
    – Adam Haile
    Jan 22 '13 at 19:50
  • \$\begingroup\$ I think you'll find the overhead to read data out of flash is pretty minimal compared to running the calculation. Depending on what else you need to store, you might even be able to copy the table into ram at startup. But if I was going to do the calculation on the fly, I'd be likely to do a fixed point implementation. \$\endgroup\$ Jan 22 '13 at 20:30
  • \$\begingroup\$ I'm not really used to the limitations of AVR... what is even required to do fixed point? I assume that double and float are both still floating point values? Or is that not the case on AVR? \$\endgroup\$
    – Adam Haile
    Jan 22 '13 at 20:38
  • \$\begingroup\$ On a machine without an FPU, concepts like double and float only exist in the compiler, and can end up generating a lot of code to implement. A simple fixed point implementation would be to multiply your inputs by some scaling factor (for example 256), essentially making everything a fraction, then do integer math on the numerator and keep track as you write your program of what the various operations have done to the constant denominator . \$\endgroup\$ Jan 22 '13 at 20:41
1
\$\begingroup\$

Here is my example of using the FLASH memory space for looking up 2D table. define CONST ARRAY & READ from it

The key is to use special macros to force and read the pointers from Flash ( PROGMEM and pgm_read_word_near ) as the compiler defaults to RAM space.

I can only imagine it is way faster then calculating it.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.