FC11 Read float fr LUT err (Solved)

[viktor_aust]

Hi
I have no problems reading the uint from Lut2.
Cannot read the floats from Lut1 for some reason.
Any help please?

[mnfisher]

Doesn't look right - even in simulation. The float read isn't correct (4.76e-44!) - which is displayed as 0.0

Martin

[chipfryer27]

Hi

Appears to run OK in v10

In v11 the float lut states 4 values, but in v10 it states 5

Regards

[BenR]

Hello,

Aha I see the problem, we made a massive efficiency boost for v11 where the byte values for the LUT are now parsed by the flowcode engine directly rather then having to get it as a string and have to manually crunch through the string in an event macro. This doesn't make much of a difference for small LUT data but for things like the GLCD where you have potentially big fonts and up to 8 of them which was causing significant slowdown on project launch and simulation start.

I'll see if I can make an exception for floats so they use the old parsing system.

[BenR]

Hopefully resolved for you now via the library updates.

[viktor_aust]

Thank you Ben. All good. Works now.

Floats and Atmega328 question.

Is it a good idea to use floats with Ard Nano?
I can use uint and insert the dot later on (to mimic the float).
Will it ease the load on Atmega328 and save the space in the memory if I stay away from the floats?

[mnfisher]

I'd try and avoid floats whenever possible especially on a 8 bit MCU.

With an 8bit MCU - with no floating point hardware - it's always going to be a lot slower than integer maths. A float variable is 32bits (as for a long) - so might not use more storgae so in a similar vein - always use the smallest variable type that will 'fit' the data - if you look at the code generated for adding a 16 or 32 bit number compared to adding an 8 bit variable - then things get bigger and slower. Just be sure you aren't going to overflow - a common mistake - a loop 256 times using a byte (all been there!)

Of course it depends what you are trying to do - if you can use fixed point numbers by multiplying values by, say, 100 - then it will be quicker - but if you need trig functions or bigger range then the trade off might be worthwhile. Also bear in mind that some values can't be represented exactly by floats - so sometimes care is needed with comparisons (if .x == 0.1).

Martin