Compiling for teensy 3.2 (ARM 32-bit) about fixedpointsarduino HOT 16 CLOSED

master works great on teensy 3.2 and 3.5. At some point I will make some time comparisons for matrix multiplication with different types on different boards. I expect the results from the teensies to be quite good.

Thank you for taking the time to work on this request! When I integrate those types in my flight controller, I will notify you regarding issue #25 Add Project Showcase.

from fixedpointsarduino.

My original plan was to eventually port it to proper C++ environments (i.e. with access to a stdlib implementation),
but other projects have ended up taking precedence.

I've heard of Teensy but haven't used one so I'm not sure what the available libraries and/or general 'ecosystem' are like.
If teensy does convert decimal literals to float then that would explain things.
(I have a feeling that probably violates the C++ standard and means the Teensy compiler is non-conforming.)

It would certainly be possible to overcome that particular issue, either by implementing a few type traits (which is something I've done before) to eliminate overload conflicts, or by specifically adjusting the type definitions to account for Teensy's strange behaviour.

from fixedpointsarduino.

If teensy does convert decimal literals to float then that would explain things.

They indeed do that, to avoid using soft floats whenever there is one decimal literal in some formula. All their FPUs are single precision.

https://forum.pjrc.com/threads/31116-problem-with-double-precision-floating-point-constants

from fixedpointsarduino.

Well, that's annoying.

I think a better solution would have been to just keep reminding people to suffix their floating point literals with f or F.

(float and double are implementation defined, but I'm still pretty sure that the rules are that a literal without a suffix has to be a double. I'm not sure if the rules require double and float to have different implementations so they might have been able to get away with making float and double have the same implementation and making long double behave like the double type.)

The easiest solution (though least robust) for getting it working on Teensy would be to use #if to detect Teensy boards and either get rid of the conflicting constructors or redefine them as the type they're supposed to be.
I'll have a crack at it sometime in the next few days, though I don't have a suitable test setup, so I'll have to rely on either you or someone else to test the code.

(I might rethink the 'take the type of a literal' approach at a later date.)

from fixedpointsarduino.

making long double behave like the double type.)

they recommend using the 'L' suffix for numbers where double precision is needed. The project creator himself is unhappy with the solution it seems.

I am happy to test on my teensy 3.2 and 3.5. of there is some repetitive task like ifdef-guarding all constructors, I'd give it a try if you want. Just show me one example.

from fixedpointsarduino.

I'd need to know what preprocessor symbol the Teensy defines to be able to detect that the compiler is compiling for Teensy.

A quick look around and the best I could find was a suggestion that CORE_TEENSY might work,
in which case something like this should work for now:

#if !defined(CORE_TEENSY)
	using DecimalLiteral = decltype(0.0);
	using DecimalLiteralF = decltype(0.0F);
	using DecimalLiteralL = decltype(0.0L);
#else
	using DecimalLiteral = double;
	using DecimalLiteralF = float;
	using DecimalLiteralL = long double;
#endif

(Details.h line 146.)

I've opened up a Teensy support branch.
If that fix solves the conflict then I'll add it to the branch.

I've also made a branch that removes the literal types and uses fundamental types instead.
Try giving that a go and see if it does the same.

Even with the conflict resolved there might be other errors, so just post them as you find them.

from fixedpointsarduino.

Works like a charm! With the fix you posted.
The CORE_TEENSY definition also applies to the old teensy 2 boards, and I cannot test those, but on teensy 3.2(also 3.1) and 3.5 it works really well.

from fixedpointsarduino.

Did you try both approaches or did you only try the #if !defined(CORE_TEENSY) approach?

(If that genuinely was the only bug then I'm pleasantly surprised.)

from fixedpointsarduino.

It only worked after applying the fix. Before, there were the same compilation errors.

I am glad and grateful that you were able to do this so quickly! Thank you very much and let me know if there is any further testing.

from fixedpointsarduino.

I mean did the remove-literal-types branch work or not?
Did it give an error?

I am glad and grateful that you were able to do this so quickly! Thank you very much and let me know if there is any further testing.

No problem. Luckily I have had the time spare to work on it.

If I'd realised there would only be the one problem I would have sorted it sooner.
I've been taking things slow because I expected this to take a lot of back and forth.
Also I don't always notice the messages immediately because I don't always have github open and I've been working on other projects as well, if I'd noticed your reply sooner I would have replied sooner.

from fixedpointsarduino.

I mean did the remove-literal-types branch work or not?

works fine on both boards without any adjustments! Whereas the teensy-support branch only works and compiles fine when removing the decltype(...)s.

Also I don't always notice the messages immediately because I don't always have github open and I've been working on other projects as well, if I'd noticed your reply sooner I would have replied sooner.

Same here.

from fixedpointsarduino.

works fine on both boards without any adjustments! Whereas the teensy-support branch only works and compiles fine when removing the decltype(...)s.

In that case, I think I will merge those changes instead.
Hopefully doing so won't break any other boards, e.g. the SAMD boards or ESP boards.

(I don't like having to use the #if defined approach if I can avoid it because it makes things more complicated if there's too many special cases.)

I'll contemplate it for a bit before merging anything, but when I've merged I'll probably ask for one last confirmation that the master branch works on Teensy and then mark this issue as closed.

I might not make a new release immediately because I might add one or two other changes first, but the next release will definitely be within the next day or so.

from fixedpointsarduino.

Your activity on this library is awesome.

I can test on an arduino due too (though only in 2 weeks).

If it compiles, it works... ...right?

from fixedpointsarduino.

Your activity on this library is awesome.

I'm not always this active.
There was a 2-3 month gap between v1.0.4 and v1.0.5.

Usually I'll be more active when there's some new interest and then it drops off for a while when I'm working on other projects.

I can test on an arduino due too (though only in 2 weeks)

I'll probably make a new release before then.
It would still be worth you giving it a go then, just in case.
I'm fairly confident that it will still work on Due after the changes, but I also thought nobody would be crazy enough to make a compiler that treats decimal literals as floats - the world is full of surprises.

If it compiles, it works... ...right?

In this case it should do because I haven't changed any logic, just the types involved.

All types are converted to the fixed point representation before doing any operations on them.
I do that specifically so that optimising compilers will (hopefully) attempt to do the conversion at compile time when possible.

I haven't actually had to fix a runtime bug in the library itself since v1.0.1.
Every bugfix since then has been related to fixing issues on boards I haven't tested on,
and (with the exception of adding Serial.begin to the example) all of those have been compile-time issues.

from fixedpointsarduino.

Sorry for the 2 day delay.

Before I close this, could you check the master branch compiles properly on Teensy?

There's no hurry and it's just a precaution, but I like to be sure the master branch works,
that way the nasty surprises happen before the next release instead of afterwards.

from fixedpointsarduino.

master works great on teensy 3.2 and 3.5.

In that case I can close this issue and prep for the next release.

At some point I will make some time comparisons for matrix multiplication with different types on different boards.

It would be nice to know how things pan out in terms of size/space/time.

Originally the main reason for creating FixedPoints wasn't as much about being fast as it was about reducing RAM usage and making fixed point types more accessible (a nice natural interface using operators instead of C-like functions like fixed_add).

I expect the results from the teensies to be quite good.

I know for a fact AVR struggles to cope with multiplication of fixed point types other than 8x8 because of its limited instruction pool and small register size,
but I imagine 32-bit ARM Cortex boards would indeed cope much better.

When I integrate those types in my flight controller, I will notify you regarding issue #25 Add Project Showcase.

I look forward to it, and I hope the fixed point types are suitable to your needs.

from fixedpointsarduino.