I would like support for double precision floating point to be available as an option on Core2. I am currently working on a design that requires that higher level of precision. You can view this thread “Is Double Precision Floating Point available in micropython on a Core2? (Needed for a GPS project)” under micropython software for details. I believe this is as simple as building a second firmware image which supports double precision floating point. The Pyboard does support this by having 5 different images available for their board supporting different features including double precision floating point. (https://pyboard.org/download/ ) Micropython does support this option. It appears as a simple change to the mpconfigport.h file. The line MICROPY_FLOAT_IMPL_FLOAT needs to be changed to MICROPY_FLOAT_IMPL_DOUBLE. Here is a link to a post describing doing this for a PI PICO. https://forums.raspberrypi.com/viewtopic.php?t=319525 I am sure there are other commercial or industrial applications that may encounter the same problems I did when dealing with very large and very small numbers in the same calculation. Anyone decoding the uBlox GPS proprietary messages will have a problem calculating an accurate time from these messages.

Thanks for your consideration.

Burke

I am designing a GPS disciplined oscillator and the goal is for a short-term stability to be better than 1 part per 10 to the 9th cycles. The uBlox GPS has 2 counter inputs. Approximately every second (1 measurement cycle) the GPS reports the count and the time of the last rising and falling edges on the counter inputs. These are reported to the nanosecond (10 to the -9 seconds). By subtracting the previous count and rising edge time from the current measurement you will get the number of counts and the time difference. From this you can calculate the frequency to approximately 1 part in 10 to the 9th. In the actual implementation you do this over a period of hundreds of seconds. In the example I gave the single precision calculation was in error by over 46 milliseconds. In a 1 second measurement this is approximately a 4.6% error! The problem arises because you are adding a very large number (5.31316281 x 10 to the 5th) to a very small number (657346 x 10 to the -4) and you need a result accurate to 9 decimal places not 1 decimal place. In the actual calculation these numbers were first scaled by a factor of 1000 and 1000000000 respectively so they were even larger numbers to start with. This code runs fine on a Pyboard with their double precision code. I would prefer to use a Core2 unit which has a much nicer display and form factor than the Pyboard and its display.
I believe the effort to create this new image is as simple as changing 1 definition to tell the compiler to compile code for double precision instead of single precision. If you interested here is a link to an individual who did this for the PI Pico. https://forums.raspberrypi.com/viewtopic.php?t=319525 For someone with the correct tools, knowledge and the source it appears to be a relatively easy task. Tools and knowledge I don’t have. In this case most of the effort would be in making people aware of the other firmware image and making it available for download.

I believe micropython already supports building a firmware image that uses double precision floating point as the default. This is a software emulation as opposed to the hardware implementation of the single precision floating point found in many controllers. As a result, the execution will be slower. In the case of the Pyboard they provide 5 different standard build images for download. In addition to the image shipped with the Pyboard they have images that include double precision floating point, multitasking and network support. https://pyboard.org/download/ The optimum solution would be for M5Stack to offer a standard build that defaulted to double precision floating point. I am sure I am not the only user that has experienced this problem. This would be an issue for others using the GPS module which contains a Ublox M8N GPS module and who try to decode the Ublox proprietary messages.
Thank you for your response to my question.

I am looking for information on the availability of double precision floating point math on a Core2 using micropython. Is it available as an option or some configuration setting? I am aware that the PyBoard has different official micropython images to load that support Double Precision Floating Point math and other options. Is there something similar for a Core2? Is this something that an individual could make?
I believe many others could benefit from this feature. I am trying to build a GPS disciplined oscillator using a Core2 and a Ublox M8T GPS timing receiver. I am decoding the Ublox proprietary messages. The Time of Week (TOW) in the messages is encoded as two 32-bit words. The first word (TOWms) is the count of the number of milliseconds. This clock restarts every week and a week’s worth of counts is more than 600 million counts. The second 32-bit word (TOWns) is the number of nanoseconds. The maximum value is 999999. To calculate the time (TOW)in seconds requires the following
TOW = (TOWms/1000) + (TOWns/1000000000)
Here is an example how bad the error between single and double precision floating point can be.
TOWms = 531316281
TOWns = 657346
Core2 result = 531316.328048706 seconds
Double Precision result = 531316.281657346 seconds
Error = 46.39136 milliseconds
This is a significant error in a one second period. I am sure others have had similar results with similar errors in their projects.
Any help resolving this issue would be greatly appreciated!