Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed-point scalar types #13

Open
pavel-kirienko opened this issue Aug 16, 2018 · 1 comment
Open

Fixed-point scalar types #13

pavel-kirienko opened this issue Aug 16, 2018 · 1 comment
Labels

Comments

@pavel-kirienko
Copy link
Member

@jschall once proposed to add those to the set of native DSDL types:

Can we use a floating point standard that matches IEEE 754 for 16, 32, 64 and 128-bit floats, but also provides for arbitrary bit lengths of floating point fields? I've got a spot where I'd like to use a 24-bit float, but there isn't really any support for it.
Actually what I really want to use here is fixed point Q16.8 - because I want uniform precision for this field. This keeps coming up, again and again and again, and I'd really like built-in support for it.
I can't make it a 32-bit float without spilling into another CAN frame

To which I said:

while I do like the idea in general, it seems like too much work right now, and besides there are questions on how to represent fixed-point numbers in generated DSDL classes. In Python there is support for fixed-point arithmetics in the standard library; but what about libuavcan. We'll have to either cast fixed-point numbers to floats, which pretty much defeats the purpose, or we'll need to code up custom fixed-point arithmetic classes (I know that many modern MCU support fixed-point in hardware, but the solution has to be generic). Overall I'm not sure if this feature is worth the extra complexity, at least right now.

This issue is to attract relevant discussion and feedback.

In this thread over there there was also a related discussion on how to represent the elements of rotation quaternions in the most efficient and usable way; fixed-point types could be applied there greatly: OpenCyphal/public_regulated_data_types#34

@kjetilkjeka
Copy link
Contributor

It would also be possible (and quite low effort) to do some experimentation with this without protocol support if we created DSDL definitions similar to the following

# Q16_8
uint16 integer_bits
uint8 fractional_bits

If it was found out that having these as native types would improve things a lot we could then upgrade them to first class citizens of dsdl and deprecate the experimentation types. This would leave the problem of using the fixed point types up to do application writer until native support was implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants