Cortex M0+ math lib

[gf]

There is also this fixed-point FFT implementation: https://gist.github.com/Tomwi/3842231
Certainly not as optimized as some other FFT libs, but completely self-contained and no externals libs required.
Compiles to less than 600 bytes of code for the cortex-m0 with gcc -Os, plus the space required for the sine table (1.5 kiB for 1024 points).

[westfw]

Quote from: ataradov on November 19, 2023, 10:03:52 am

Generic GCC libraries are not extremely optimized specifically for Cortex-M0.

Yeah, that.  "popular" architectures will get a carefully hand-written set of software floating point function, usually written in assembly language, and designed for speed and/or space efficiency.  If no one has written such a library for an architectures, gcc "falls back" to some very generic floating point libraries written in C.  I'm sure it's all correct and complete, but it is neither fast nor small :-(
avr-gcc has an assembly-language math library for 32bit floats.
arm-v7m (CM3, CM4, etc) has an assembly language math library for both 32 and 65 bit floats.
arm-v6m (CM0, CM0+) doesn't, and uses the generic gcc C functions. (last time I looked. anyway.)

have a look at that: https://www.quinapalus.com/qfplib.html

Yes; highly recommended.  They fit a relatively complete 32bit float library for CM0 in 1k, a more complete and faster 32/64 bit float library for CM0 in 6k, and have an improved CM3 library as well.
The RPi Pico has adopted qfplib as their standard float library in their SDK, and put the qfplib functions in ROM.  (alas, not all development environments include all the magic linker statements needed to make this work.)

[nctnico]

Unfortunatly qfplib is under the GPL license so no go for commercial projects.

[DavidAlfa]

No problem with gpl license and commercial projects.
Basically, you simply have to indicate it somewhere (I.E. in the manual), listing the GPL software used and linking to their sources.
The code will be still under GPL license if you modify it for your needs.
Companies might ship the GPL code in the CD/DVD having the PC software, or in their website (Very common to see User manual, PC software, firmware update... And GPL code), or making a GitHub account and uploading it there.
Usually you find thw bunch of libraries used in the fw, and that's it, nothing about the propietary firmware itself.
Private code is still private, no sharing required, it's completely your's.

[brucehoult]

have a look at that: https://www.quinapalus.com/qfplib.html

Yes; highly recommended.  They fit a relatively complete 32bit float library for CM0 in 1k

Correctly rounded to even 0.5 ULP +-*/ in 1 KB is quite impressive. The overview page doesn't say whether that includes denorms, but as they claim IEEE compliance and don't say it doesn't, I assume that it does.

Most MCU software doesn't require that level of accuracy -- when your ADC is 10 or 12 bits it doesn't matter whether your maths is accurate to 23 bits or only 20 --  so an even smaller library is possible.

[brucehoult]

No problem with gpl license and commercial projects.
Basically, you simply have to indicate it somewhere (I.E. in the manual), listing the GPL software used and linking to their sources.
If you modify it, you must also make it open source, most companies simply indicate you might ask for a copy of the sources by contacting them.
Some also ship it in a CD having the PC software, user manual...
But the private code is still private, no sharing required, it's completely your's.

Under GPL2 (which this uses) for PC software where you ship the GPL code as a DLL, yes, because the user can replace the library with a different library, or newer version, or whatever.

If you statically link then you must make all of your commercial code open source also.

Embedded code, in a ROM, is by definition statically linked.

[nctnico]

No problem with gpl license and commercial projects.

Yes it is. Or do you want to have a runtime linker on your MCU to link the library dynamically at startup? Last time I checked GPL prohibits linking code statically into closed source projects without disclosing the source of the entire project.

https://www.revenera.com/blog/software-composition-analysis/field-notes-understanding-gpl-linking-exceptions/

[SiliconWizard]

have a look at that: https://www.quinapalus.com/qfplib.html

Yes; highly recommended.  They fit a relatively complete 32bit float library for CM0 in 1k

Correctly rounded to even 0.5 ULP +-*/ in 1 KB is quite impressive. The overview page doesn't say whether that includes denorms, but as they claim IEEE compliance and don't say it doesn't, I assume that it does.

I will check that out.

Most MCU software doesn't require that level of accuracy -- when your ADC is 10 or 12 bits it doesn't matter whether your maths is accurate to 23 bits or only 20 --  so an even smaller library is possible.

Yes, and often FP is not required at all either. But people like it because it's usually much easier to deal with than fixed point.

(Note that the FP library provided in ROM for the RP2040 is based on qfplib AFAIR.)

[nimish]

Embedded code, in a ROM, is by definition statically linked.

Strictly, no. There is no settled definition of what a derivative work w.r.t. the GPL means that matters to a court (yet). If this matters to you, consult an IP lawyer.

Do not rely on the internet to determine what is and isn't distribution, linkage and other critical terms or you might regret it. There are always ways to isolate code and argue it's communicated over a "network" or in a separate executable process, or other such workarounds -- hence the AGPL.

Every RTOS worth its salt has a dynamic linker built in, so this is not an academic exercise.

[Nominal Animal]

Free Software Foundation, the authors of the GPL license, are of the opinion that Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

While one can argue whether this is the correct understanding of derivative work in any particular legal jurisdiction, I personally would take heed, especially because of the associated Software Freedom Conservancy's Copyleft Compliance programs.

In particular, you might wish to read about the The Strategic GPL Enforcement Initiative, and the Firmware Liberation Project (which albeit focusing on Linux-based systems, is exactly about combining GPL-licensed works with proprietary code).

So no, please do not assume that you can dynamically link GPL-licensed libraries to proprietary binaries.


The LGPL license is the one that explicitly allows linking with proprietary code, without pulling that proprietary code under the LGPL license.  From the GPL FAQ: Does the LGPL have different requirements for statically vs dynamically linked modules with a covered work?

For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):

    (1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

    (2) If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides.

This is how for example one can use LGPL-licensed Qt modules to create a commercial application with proprietary components, without purchasing a commercial Qt license.  For example, one can use Python for the UI, dynamically linking to the standard Qt dynamic libraries, but also to your own proprietary dynamic libraries.  (Python itself provides the relinking mechanism, as the user only needs to replace the dynamic library file with a different one.)


As to avr-libc, it is licensed under a modified BSD license, which explicitly allows its use in proprietary applications.  Similarly, newlib (or newlibc) is licensed under BSD- and MIT-style licenses, allowing its use in proprietary applications.  The GNU C library itself is licensed under LGPL 2.1, allowing its use with proprietary applications, noting the points from the LGPL FAQ above.

As to Qfplib (and its variants), it is licensed under GPL v2, and I do not know of any way to use it in a proprietary firmware whose source will not be available to the customers.  Regardless of whether one links statically or dynamically, the combined work falls under the GPL license, as far as I am concerned.

You will get better results by contacting the authors, explaining your use case and business model and asking for a separate license (perhaps LGPL), than concocting a novel legal theory that allows you to use GPL-licensed libraries as if they were LGPL-licensed originally.

[DavidAlfa]

If you statically link then you must make all of your commercial code open source also.

Ah! I'm used to see gpl in devices running an OS, so they do as you say, ”gpl used: libjpeg, busybox..., here you have their tar files".
Didn't know the static thing. Thanks for the lesson!

[cfbsoftware]

I know that there is no FPU, even the basic instruction set is smaller, but I still think that the calculation of the sine function should not cost 20kB of flash.

That certainly sounds excessive. Is that just the calculation of the sine function or are you including the code required to show results, trap runtime errors etc.?

For comparison, the 32-bit FPU and Math (ArcTan, Cos, Exp, Ln, Sin and Sqrt) libraries written in the Oberon language that we use in the Astrobe compiler for Cortex-M0 on STM32 hardware are only 1312 bytes and 2632 bytes of code respectively.

[SiliconWizard]

RISC-V has its own, but it's only arithmetic operations: https://github.com/pulp-platform/RVfplib
The license is GPL3.

[westfw]

Quote from: DavidAlfa on Yesterday at 04:16:09 pm

No problem with gpl license and commercial projects.

That could be true if it were licensed LGPL (maybe: AFAIK, FSF (still!) doesn't have clear guidance for how LGPL applies to deeply embedded microcontroller code (ROM/Flash/etc), but QFPLIB is very explicitly NOT LGPL.

OTOH, the qfplib author says that they have alternate licensing schemes available for commercial use.  Unless you've investigated them, you shouldn't eliminate it as a possibility.

(huh.  I wonder if the RPi ROMed qfplib counts as "dynamically linked"?  On the one hand, a user's application will contain none of the GPL code, just "OS calls."  OTOH, being in ROM and thus not user-replaceable seems to go against the intended spirit.  ("It's a trap: the ROM code is OK to use commerically, but if you need to upgrade the FP code (via static linking with a new version of the library), WHAM!")

[SiliconWizard]

(huh.  I wonder if the RPi ROMed qfplib counts as "dynamically linked"?  On the one hand, a user's application will contain none of the GPL code, just "OS calls."  OTOH, being in ROM and thus not user-replaceable seems to go against the intended spirit.  ("It's a trap: the ROM code is OK to use commerically, but if you need to upgrade the FP code (via static linking with a new version of the library), WHAM!")

qfplib's team mentions it:

The Raspberry Pi RP2040 microcontroller includes a version of this library, slightly modified to take advantage of special hardware available on that device.

Given that the team openly talks about it, and it's been modified for the RP2040, so a derivative work AFAICT, I'm pretty sure they have arranged an appropriate licensing for the RPi foundation. That wasn't just "let's use that in our chip and see if we get away with it."

I'm all the more convinced about the fact they've likely contracted a commercial license, for the reason that they have modified the library and the RPi haven't released the modified source code (at least AFAIK, if you can find the source code for the ROM FP library officially released, then I'm wrong.) Imagine that under a GPL license.

[westfw]

if you can find the source code for the ROM FP library officially released, then I'm wrong.

https://github.com/raspberrypi/pico-bootrom/tree/master/bootrom
mufplib.S, mufplib-double.S

But you're not wrong, either...

Code: [Select]

/**
 * Copyright (c) 2020 Mark Owen [url]https://www.quinapalus.com[/url] .
 *
 * Raspberry Pi (Trading) Ltd (Licensor) hereby grants to you a non-exclusive license to use the software solely on a
 * Raspberry Pi RP2040 device. No other use is permitted under the terms of this license.


[SiliconWizard]

Ah thanks, didn't know they had released the source code for the boot rom entirely. Cool stuff.

Yes, it would still look like this is a commercial license. Since the RPi released the source code, I'm not entirely sure why they have not been able to use the GPL. Other than they didn't want to have to license the bootrom source code under the GPL itself. Which may have its own reasons.

Given that there seems to be an exclusive copyright of Mark Owen (the owner of quinaplus) in the modified files, I'm assuming *he* did optimize the library for the RP2040, and not someone from the RPi's team, probably as contract work. Just a guess.