Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
GPIO Pinout
Raspberry Pi Wishlist
Comparison Chart
Quiz
Group Actions
Engagement
  • Author Author: shabaz
  • Date Created: Date Created
  • Views 5908 views
  • Likes 0 likes
  • Comments 6 comments
Related
Recommended

Pi Pico (RP2040) MicroPython Double Precision

shabaz

 

Introduction

The Raspberry Pi Pico can be programmed in different ways, and the Python language is quite attractive. Code can be immediately typed at a prompt (known as a shell or console), or can be written in files and drag-and-dropped to the USB file storage drive letter that appears when you plug the Pi Pico into the PC.

 

The version/variant of Python that is installed on the Pi Pico can be changed at any time by also drag-and-dropping the Python firmware binary file onto the USB storage drive letter, but this time do it by first holding down the button that is on the Pi Pico, before plugging in the Pi Pico to the PC, and then release the button.

image

 

Unfortunately, the mathematic capabilities are quite limited with the Python variants available, which are CircuitPython and MicroPython. The pre-built ready-to-download CircuitPython and MicroPython firmware images are both configured for single-precision calculations. It is very easy for mathematics-related discrepancies to appear when using single-precision.

 

Here's an example with a downloaded (from the raspberrypi.com website) MicroPython image.

image

As can be seen from the screenshot above, very large numbers such as 5 x 10^38 cannot be represented properly.

 

The situation with CircuitPython is actually currently worse. The screenshot below shows the inaccuracy when calculating the remainder when dividing two large numbers. To be clear, these numbers are not very large in the engineering world. 845 x 10^6 happens to represent a phase locked loop (PLL) frequency, and 25 x 10^6 represents a cheap 25 MHz crystal.

image

 

From my perspective it's crippling having no sensible way to have double-precision in these Python variants; furthermore the maths capabilities ought to be a unique selling point of Python : )

 

Fortunately, it is easy to build a version of MicroPython with double precision capability. The information below is based on a very useful discussion here I have merely just added a few tiny bits to hopefully make it easy to follow.

 

Pre-built Double Precision MicroPython Firmware

Following the instructions below, I've created a binary file downloadable here that can be directly used. However, it won't be up-to-date forever, so the information below can be used at any time to create some new binaries (and please share them if you do build them, to save people time).

 

Setting up the PC to build MicroPython Firmware

On a Linux machine as root user (or prepend the text sudo to these lines) type the following:

 

apt-get update
apt-get install cmake gcc-arm-none-eabi libnewlib-arm-none-eabi build-essential

 

All the remainder commands below are executed as a normal user, not root/super-user.

 

Building a Release Version of MicroPython with Double Precision

Download the latest release source zip file to (say) ~/development/micropython

For example, type:

 

mkdir -p ~/development/micropython
cd ~/development/micropython
wget https://micropython.org/resources/source/micropython-1.17.zip

 

Unzip the file:

 

unzip *.zip

 

Now type:

 

cd micropython-*
make -C mpy-cross
cd ports/rp2

 

Edit the file mpconfigport.h and around line 65, change from:

 

#define MICROPY_FLOAT_IMPL                      (MICROPY_FLOAT_IMPL_FLOAT)

 

to:

 

#define MICROPY_FLOAT_IMPL                      (MICROPY_FLOAT_IMPL_DOUBLE)

 

Basically, change the end of the line, from FLOAT) to DOUBLE) and then save the file.

 

To build the code, type:

 

rm -rf build
mkdir build
cd build
cmake ..
make

 

It should take a minute or so to complete, and the folder will contain (amongst other files) firmware.uf2

 

shabaz@u18-nuc:~/development/micropython/micropython-1.17/ports/rp2/build$ ls -l firm*
-rwxrwxr-x 1 shabaz shabaz  289156 Oct 15 16:41 firmware.bin
-rw-rw-r-- 1 shabaz shabaz 4238463 Oct 15 16:41 firmware.dis
-rwxrwxr-x 1 shabaz shabaz  809608 Oct 15 16:41 firmware.elf
-rw-rw-r-- 1 shabaz shabaz 1161543 Oct 15 16:41 firmware.elf.map
-rw-rw-r-- 1 shabaz shabaz  813406 Oct 15 16:41 firmware.hex
-rw-rw-r-- 1 shabaz shabaz  578560 Oct 15 16:41 firmware.uf2

 

That firmware.uf2 file can be renamed to something sensible, and then uploaded to the Pi Pico in the normal manner (i.e. hold down the button that is on the Pi Pico, and plug the USB connector to the PC, release the button, and then drag the .uf2 file to the USB file storage drive letter that appears.

 

mv firmware.uf2 rp2-pico-micropython-doubleprecision-1-17.uf2

 

 

Building Latest Snapshot version of MicroPython with Double Precision

Type the following:

 

mkdir -p ~/development/micropython-latest
cd ~/development/micropython-latest
git clone -b master https://github.com/micropython/micropython.git
cd micropython
git submodule update --init -- lib/pico-sdk lib/tinyusb
make -C mpy-cross
cd ports/rp2

 

Edit the file mpconfigport.h as described before. Then, type:

 

rm -rf build
mkdir build
cd build
cmake ..
make

 

As before, the folder will now contain the firmware.uf2 file.

 

Example Double Precision Output

Sticking with the same example as above, here is what appeared for me with the double-precision version of firmware:

image

 

With the latest snapshot version as of 25th October 2021, this is the output:

image

 

Summary

it is possible to get far more accurate maths capabilities with the Pi Pico and MicroPython, by re-building the MicroPython firmware image. Example firmware is available here.

Thanks for reading!

  • in reply to shabaz

    That lines up with what I've seen with pwm duty that wants a u16.

    If a variable is assigned a value like 65535, duty will use it.

    A variable that was read from analog as u16, and mapped to duty directly , is happy.

    If any manipulation is used on that var, it ends up be classified as a float. Forcing it to INT makes a signed int.

  • Another interesting thing I learned this week, is that despite trying to force variables to be integers, some operations will provide a floating point result.

    Those need to then be converted to integer if that is important to whatever you're doing, otherwise one could continue to use the floating-point result of course. Python (not just MicroPython, but normal Python too) implicitly changes to float whenever it feels the need to.

     

    Another interesting thing is that the following is an integer:

    a = 100000000

    but the following is floating point:

    b = 100e6

     

    Here's the output with the double-precision build of MicroPython, but as mentioned, normal Python does the same thing:

    image

  • in reply to Jan Cumps

    Hi Jan,

     

    I think they are intending the PicoPI for more embedded controlling type applications.

    That said, I agree with you. I have done some very intricate math for some of my embedded applications.

     

    DAB

  • in reply to Jan Cumps

    Hi Jan,

     

    Good points, personally I'm on the other side of the fence, but see your point of view too. Python is unusual in that it's interpreted, so it's hard to have a 1:1 comparison in the microcontroller world, but I cannot think of a compiled scenario where the language restricts the user like this. For example in C I can happily use double-precision, provided I can link to the appropriate library (if the resources exist and if performance hit is ok). With the Python interpreter, I cannot do the same thing in the interpreted way, there's no plug-in. Even if some source code in Python exists to provide double-precision, it will not be plug-and-play if the interpreter on the Pico natively doesn't support it.

    As an example, even Arduino supports it. Granted performance won't be as good as algorithms redesigned to use (say) integers, but still, the capability exists. What's worse is that especially for Python, it's supposed to be a strong point. My Casio calculator has double-precision on its built-in Python too, but for sure that's its core purpose, calculations.

    Even schoolkids will likely be hitting single-precision limits if they try to implement on the Pico the things they learned in Physics or Maths classes. Granted that's a learning experience too, but it's still disconcerting if that is taught accidentally when they might normally expect results at least close to their typical calculators, and they'd have no option other than to accept the error with that default interpreter.

    Slightly related, I only hit this problem because I was merely trying to port existing C code to Python, code that Adafruit themselves use as driver code, which funnily would have been impossible for them to write in CircuitPython without the math errors appearing. However the CircuitPython issue is slightly different - their math is quite broken, they even have errors in integer mathematics, certainly in their latest release, which led me to try floating point.

    image