TheBackShed.com

Forum Index : Microcontroller and PC projects : Micormite Plus issue with C modules and floating point variables.

Author

Message

Fenderman
Newbie

Joined: 13/07/2021
Location: United Kingdom
Posts: 3

Posted: 05:07pm 21 Jul 2021

Copy link to clipboard

Print this post

I didn't get a response to my first post but I believe I've found the reason for my issue with the C Module FloatSort. Micromite Plus uses double precision floating point, i.e. 8 bytes, this is mentioned in the Micromite manual which refers to the Micromite Plus manual but I could not find it documented there. Using Peek, which was vary tedious, to debug the issue I confirmed floating point numbers are stored as 8 bytes (64 bits) but it appears that FloatSort has been written for the Micromite which stores floating point as single precision i.e. 4 byes (32 bits). This seems to explain why I was seeing half the array corrupted and the rest untouched. Each element in the array is 64 bits but the FloatSort addresses it as 32 bits and only indexes half the array. My C is rusty and I have never used MPLAB X to develop C (only assembler for 8 bit PICs) but I managed to write and get working a integer sort that works with Micromite Plus. However I've run into issues with floating point. If I declare the arguments as "double" the compiler still defaults to 32 bits. I got round this by using "long double" not sure if this is the correct way but it works and I can now index the array of 64 bit elements correctly. I thought there might be a compiler directive to specify "double" as 64 bits but couldn't see one. The problem now is that I can't use the Micromite floating point routine FCmp to compare two floating point numbers because it expects "float" arguments. I can't cast the "long double" to "float" because of unresolved reference to "dptofp". What's confusing is that declaring "float" arguments in my C function I can pass double precision number to it and there are then no problems calling FCmp. It's only when passes a floating point array that there is a issue because the index doesn't work correctly unless the array is declared as "long double". I assume that non arrays arguments are converted from double precision to single in the call. Anyway if anyone can shed any light on what's going on I would be extremely grateful. As I say I've not touched C for 20 years so definitely struggling on this platform. Regards Richard

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10610

Posted: 05:28pm 21 Jul 2021

Copy link to clipboard

Print this post

The micromite+ was converted from single to double precision floating point in release 5.04.09. This included automatic convertion of floating point parameters to/from double BUT NOT ARRAYS. This is documented in the C routines.PDF document. I don't think anyone has tried to work with floating point in CFunctions since on the MM+. Floating point in general is clunky in Cfunctions because of the way the compiler works hence the need for routines FCMP etc.
AFAIK there is no answer to your problem with the MM+ code as-is. You need CFUNCTIONS.h to expose a casting mechanism and this doesn't currently exist. This will need Geoff to include something in the next release.
Edited 2021-07-22 03:32 by matherp

Fenderman
Newbie

Joined: 13/07/2021
Location: United Kingdom
Posts: 3

Posted: 06:57pm 21 Jul 2021

Copy link to clipboard

Print this post

Hello Peter, thank you for the prompt reply and also for your great tutorial on C routines without which I don't think I'd have got this far.

I reread the the .pdf and it is clear. I don't know how I missed the explanation, would have saved some time. However it was interesting and a learning experience.

Do you know the correct way to submit enhancement requests? In the past I reported a couple of firmware bugs directly to Geoff which he fixed but I understand he is busy and suggested I use this forum in future.

I could work round this issue, for example, by multiplying / dividing the values by a suitable scaling factor and sorting as integers. But that's going to add an overhead and it would be better to do it properly. I did look for the conversion function in the .h file but couldn't see anything likely. I hope Geoff will be able to add this in a future release.

Regards

Richard

Print this page

To reply to this topic, you need to log in.