Re: Micropython embedded in a C program?
Yes, that should work. But to keep proving the minute one declares something 'impossible' the solution instantly arrives ...
I remembered I had a hell of a time getting early MicroPython to compile using the Pico SDK under Windows; line length too long for the build environment Raspberry Pi had chosen. It's been refactored now so doesn't do things the same way but it reminded me that the tricks used then should work now. And they do - I can now create the same as what the 'micropython-embed.mk' does using a linear shell script.
And, best of all, that can be turned into a CMake sequence so a completely self-contained build is possible.
Though I'm going through the same trials and tribulations as I did with Windows so not there yet.
Re: Micropython embedded in a C program?
Yes, " ... We'll get there...."!
For the moment, I am a little "tool-chained" with cmake / make having little knowledge,
of this tools, and I work with object and function access between C and Micropython.
This morning I tried to work with float, (mp_obj_new_float() and so on) but I still have
to solve it, probably there is a setting in a #define to activate.
Just to encourage, seeing in pi/pico/micropython/py directory we''ll see all the object
and function possibilities.
For the moment, I am a little "tool-chained" with cmake / make having little knowledge,
of this tools, and I work with object and function access between C and Micropython.
This morning I tried to work with float, (mp_obj_new_float() and so on) but I still have
to solve it, probably there is a setting in a #define to activate.
Just to encourage, seeing in pi/pico/micropython/py directory we''ll see all the object
and function possibilities.
Re: Micropython embedded in a C program?
Yes, the 'py' directory is basically the complete internals of MicroPython, what gets built for the mininimal builds and comes in at around 250 KB. Not everything is included such as 'mod*.c' modules; 'bytearrays' and other built-in are not supported by the minimal builds.
The 'shared' holds a few things which are included in the minimal builds, particularly 'gc'.
The 'extmod' holds other common modules which could be added but aren't included by default.
Adding "#define MICROPY_FLOAT_IMPL (MICROPY_FLOAT_IMPL_FLOAT)" in 'mpconfigport.h' will enable support for floats but that throws linking errors for a number of maths functions.
I haven't figured out how to get maths functions automatically included and adding "#define MICROPY_PY_MATH (1)" doesn't do it. But I did however manage to hack it to work ...
Not doing so well for using 'double' rather than 'float'.
The 'shared' holds a few things which are included in the minimal builds, particularly 'gc'.
The 'extmod' holds other common modules which could be added but aren't included by default.
Adding "#define MICROPY_FLOAT_IMPL (MICROPY_FLOAT_IMPL_FLOAT)" in 'mpconfigport.h' will enable support for floats but that throws linking errors for a number of maths functions.
I haven't figured out how to get maths functions automatically included and adding "#define MICROPY_PY_MATH (1)" doesn't do it. But I did however manage to hack it to work ...
Code: Select all
Running float test - print(0.123456789123456789, 1.2 + 2.1 + 3.3) ...
0.12345679 6.6
Re: Micropython embedded in a C program?
In the sources I find this used defines
...
#if MICROPY_PY_BUILTINS_FLOAT
#if MICROPY_PY_BUILTINS_FLOAT && MICROPY_FLOAT_USE_NATIVE_FLT16
#if MICROPY_PY_BUILTINS_FLOAT && MICROPY_COMP_CONST_FLOAT
#if MICROPY_FLOAT_IMPL == MICROPY_FLOAT_IMPL_DOUBLE
#if MICROPY_PY_BUILTINS_FLOAT && MICROPY_PY_BUILTINS_COMPLEX && MICROPY_PY_CMATH
#if MICROPY_PY_BUILTINS_FLOAT && MICROPY_PY_MATH
#if MICROPY_PY_BUILTINS_FLOAT && MICROPY_PY_MATH && MICROPY_COMP_CONST_FLOAT
#if MICROPY_FLOAT_IMPL == MICROPY_FLOAT_IMPL_FLOAT
#define MICROPY_PY_BUILTINS_FLOAT (1)
if could be a little help
...
#if MICROPY_PY_BUILTINS_FLOAT
#if MICROPY_PY_BUILTINS_FLOAT && MICROPY_FLOAT_USE_NATIVE_FLT16
#if MICROPY_PY_BUILTINS_FLOAT && MICROPY_COMP_CONST_FLOAT
#if MICROPY_FLOAT_IMPL == MICROPY_FLOAT_IMPL_DOUBLE
#if MICROPY_PY_BUILTINS_FLOAT && MICROPY_PY_BUILTINS_COMPLEX && MICROPY_PY_CMATH
#if MICROPY_PY_BUILTINS_FLOAT && MICROPY_PY_MATH
#if MICROPY_PY_BUILTINS_FLOAT && MICROPY_PY_MATH && MICROPY_COMP_CONST_FLOAT
#if MICROPY_FLOAT_IMPL == MICROPY_FLOAT_IMPL_FLOAT
#define MICROPY_PY_BUILTINS_FLOAT (1)
if could be a little help
Re: Micropython embedded in a C program?
Thanks. I am going to have to dig deeper but have been trying bring in the 'bigger feature' stuff first. Given you are interested in doubles I will take a look to see what more I can do for that.
I had got it to include the double code equivalent to the single code but that is throwing errors for '__sin', '__cos' and '__tan' -
It makes sense to me that '__sin', '__cos' and '__tan' would be 'double(double)' for typical "y = sin(x);" use so I am at a loss as to why MicroPython would define it any other way, have three parameters.
I had abandoned that without really thinking about it but, as it's only three functions, I might be able to figure out how to exclude those.
I'm guessing my hacking fell far short in respect of functioality but it does seem to seeing double, as they say ...
Some more hacking and Bingo!
All the actual double maths functions are now incorrect but at least add works.
I had got it to include the double code equivalent to the single code but that is throwing errors for '__sin', '__cos' and '__tan' -
Code: Select all
In file included from /home/pi/pico/micropython/lib/libm_dbl/acos.c:36:
/home/pi/pico/micropython/lib/libm_dbl/libm.h:96:8:
error: conflicting types for ‘__sin’; have ‘double(double, double, int)’
96 | double __sin(double, double, int);
| ^~~~~
Code: Select all
In file included from /usr/include/features.h:489,
from /usr/include/arm-linux-gnueabihf/bits/libc-header-start.h:33,
from /usr/include/stdint.h:26,
from /usr/lib/gcc/arm-linux-gnueabihf/12/include/stdint.h:9,
from /home/pi/pico/micropython/lib/libm_dbl/libm.h:15:
/usr/include/arm-linux-gnueabihf/bits/mathcalls.h:64:1:
note: previous declaration of ‘__sin’ with type ‘double(double)’
64 | __MATHCALL_VEC (sin,, (_Mdouble_ __x));
| ^~~~~~~~~~~~~~
I had abandoned that without really thinking about it but, as it's only three functions, I might be able to figure out how to exclude those.
I'm guessing my hacking fell far short in respect of functioality but it does seem to seeing double, as they say ...
Code: Select all
Running float test Example 5 ...
0.000000000000287445e+34 0.000000001081344
Code: Select all
Running float test Example 5 ...
0.12345678912345678 6.6
Re: Micropython embedded in a C program?
About the messages linked to setting in mpconfigport.h:
searching "MP_QSTR_" I see that in /micropython/tools/mpy_ld.py
they search this prefix (in the source code?!) and make some working;
starting from the fact that in /micropython/py many MP_QSTR_xxxx
are called but never defined, is possible that there is some external code
that assign a value, and perhaps I have the python in my Raspberry Pi
not aligned?
Don't waste time about this doubt, only I ask an impression if I am on
the right way or abandon it.
Thanks
searching "MP_QSTR_" I see that in /micropython/tools/mpy_ld.py
they search this prefix (in the source code?!) and make some working;
starting from the fact that in /micropython/py many MP_QSTR_xxxx
are called but never defined, is possible that there is some external code
that assign a value, and perhaps I have the python in my Raspberry Pi
not aligned?
Don't waste time about this doubt, only I ask an impression if I am on
the right way or abandon it.
Thanks
Re: Micropython embedded in a C program?
In theory the QSTR needed should all be determined at the time the MicroPython executable is built so there should be no issues.
But in the case of these minimal and embedded builds they are mostly a two step process so it is possible to get out of sync.
And all the minimal and embedded builds seem to do things slightly differently so how to do something doesn't carry from one to the other and what one can achieve seems to vary.
The online example allows modules to be created and used by placing two entries in the right place, same as it was in the good old days of MicroPython for RP2. For the pre-build those try to figure things out with USER_C_MODULES supposedly what's to be used but that is as buggy as it was with MicroPython for RP2 but with no obvious way around that.
If it does what you want there's no reason to abandon this adventure but I am no longer convinced it can do what I want. The online example which builds modules looks like it may be a challenge to turn in a build for a Pico or actually embedding, the one which had looked promising doesn't look like it's going to handle modules without tweaking inside the MicroPython toolchain.
Hacking and gutting the existing RP2 build may be back on the cards but it's easy to take something out in one place but not another and everything comes crashing down. And we still have to make it work at the command line and have it embeddable. There's too much undocumented 'make' and CMake magic going on for me to really get to grips with. I don't understand 'make' and it seems to be doing some quite advanced stuff, dynamically deciding what it will do.
MicroPython's advice is "start with a minimal or embedded build" but nothing I can see on how to proceed once you have or where you might need to be looking. Seems that if you do want a new port or a modification you have to do what Raspberry PI did and coerce the author into doing it for you.
That might well be the rationale for Qualcomm acquiring Arduino though in comparison their tools seem a lot easier to hack than MicroPython.
Did I mention I have a love-hate relationship with MicroPython :|
But in the case of these minimal and embedded builds they are mostly a two step process so it is possible to get out of sync.
And all the minimal and embedded builds seem to do things slightly differently so how to do something doesn't carry from one to the other and what one can achieve seems to vary.
The online example allows modules to be created and used by placing two entries in the right place, same as it was in the good old days of MicroPython for RP2. For the pre-build those try to figure things out with USER_C_MODULES supposedly what's to be used but that is as buggy as it was with MicroPython for RP2 but with no obvious way around that.
If it does what you want there's no reason to abandon this adventure but I am no longer convinced it can do what I want. The online example which builds modules looks like it may be a challenge to turn in a build for a Pico or actually embedding, the one which had looked promising doesn't look like it's going to handle modules without tweaking inside the MicroPython toolchain.
Hacking and gutting the existing RP2 build may be back on the cards but it's easy to take something out in one place but not another and everything comes crashing down. And we still have to make it work at the command line and have it embeddable. There's too much undocumented 'make' and CMake magic going on for me to really get to grips with. I don't understand 'make' and it seems to be doing some quite advanced stuff, dynamically deciding what it will do.
MicroPython's advice is "start with a minimal or embedded build" but nothing I can see on how to proceed once you have or where you might need to be looking. Seems that if you do want a new port or a modification you have to do what Raspberry PI did and coerce the author into doing it for you.
That might well be the rationale for Qualcomm acquiring Arduino though in comparison their tools seem a lot easier to hack than MicroPython.
Did I mention I have a love-hate relationship with MicroPython :|
Re: Micropython embedded in a C program?
Yes, is hard to work in these conditions.
I found in the only micropython/py directory 262 tokens "MICROPY_..." linked to some #define, with little
or no explication in micropython/ports/rp2/mpconfigport.h.
I continue to investigate and test, putting in this topic the results
I found in the only micropython/py directory 262 tokens "MICROPY_..." linked to some #define, with little
or no explication in micropython/ports/rp2/mpconfigport.h.
I continue to investigate and test, putting in this topic the results
Re: Micropython embedded in a C program?
Having gone back to hacking the 'rp2' port that's somewhat like pulling a strand from a spider's web without breaking any other but I am getting there. I have managed to strip out modules and functionality I don't want, add in my own modules and, by virtue of it all being run from 'main' it is implicitly embedded in C.
The main thing I haven't got is it building for the Pi command line, nor as bare metal PI, but the framework is in place. The greatest challenge is likely to be in removing the Pico SDK stuff and replacing that with C library calls.
I am going to have to think about how to handle file systems. Given all interaction is block-based, reads and writes via 'rp2_flash.c', I am tempted to load a file system image, interact with that, and save it if it has changed. At least to start with.
So I will accept 'katak255' was right and this does seem to be easiest route even if there are hurdles surrounding the bottom of the mountain to climb.
So far the cut-down 'rp2' port, basically no 'machine' and 'rp2' modules, has reduced the Pico image to 240 KB. That's from about 280 KB so not a huge saving but saving memory isn't the primary goal.
The main thing I haven't got is it building for the Pi command line, nor as bare metal PI, but the framework is in place. The greatest challenge is likely to be in removing the Pico SDK stuff and replacing that with C library calls.
I am going to have to think about how to handle file systems. Given all interaction is block-based, reads and writes via 'rp2_flash.c', I am tempted to load a file system image, interact with that, and save it if it has changed. At least to start with.
So I will accept 'katak255' was right and this does seem to be easiest route even if there are hurdles surrounding the bottom of the mountain to climb.
So far the cut-down 'rp2' port, basically no 'machine' and 'rp2' modules, has reduced the Pico image to 240 KB. That's from about 280 KB so not a huge saving but saving memory isn't the primary goal.
Re: Micropython embedded in a C program?
Now, the next hurdle. What to do about files which need to be changed to support a build not using Pico SDK ... ?
The 'CMakeLists.txt' can be modified to include the original sources when built with Pico SDK and alternatives when not, but it seems the include files would need to have conditional compilation added so they contain what's needed for a Pico SDK build or select the alternatives when not. Conditional compilation may be the better path for some of the other files but I am going to start with duplications and worry about rationalising things once it is all working.
The refactoring needed is fairly easy to do, but the question is; what to do should MicroPython change any of those files ?
Battling MicroPython refactoring has been the biggest challenge in keeping my own fork of MicroPython up to date, has made me want to throw in the towel more than once.
It is not too bad when it's generic stuff which has little affect outside of the core itself so perhaps the risk is low, but those have often been my 'famous last words'.
The alternative is to take a snapshot of MicroPython in its entirety and build within that, update only rarely. Which seems to be what CircuitPython did. And why they are still on 1.25 while 1.27.1 is the leading edge MicroPython.
Perhaps the pragmatic solution is to run with the leading edge and see what happens.
I don't know if anyone else has any bright ideas ?
Code: Select all
clocks_extra.c
fatfs_port.c
help.c
main.c
modtime.c
mphalport.c
mutex_extra.c
rp2_flash.c
usbd.c
Code: Select all
mpconfigport.h
mphalport.h
mutex_extra.h
pendsv.h
The refactoring needed is fairly easy to do, but the question is; what to do should MicroPython change any of those files ?
Battling MicroPython refactoring has been the biggest challenge in keeping my own fork of MicroPython up to date, has made me want to throw in the towel more than once.
It is not too bad when it's generic stuff which has little affect outside of the core itself so perhaps the risk is low, but those have often been my 'famous last words'.
The alternative is to take a snapshot of MicroPython in its entirety and build within that, update only rarely. Which seems to be what CircuitPython did. And why they are still on 1.25 while 1.27.1 is the leading edge MicroPython.
Perhaps the pragmatic solution is to run with the leading edge and see what happens.
I don't know if anyone else has any bright ideas ?
Re: Micropython embedded in a C program?
Well; some degree of success. I have a version of the 'rp2' port which cleanly compiles for the command line but it produces numerous unresolved linking errors, undefined functions. Not surprising but far more than I had anticipated. That feels like too much of a mountain to climb for the rewards so I am throwing in the towel on that, at least for now.
I am now moving on to the 'unix' port which we know compiles for the command line. I will be stripping everything out of that to get it down to brae bones then seeing how compiling it for the Pico goes. Making it work for Pico should hopefully be just like making it work for bare metal on the Pi.
I am now moving on to the 'unix' port which we know compiles for the command line. I will be stripping everything out of that to get it down to brae bones then seeing how compiling it for the Pico goes. Making it work for Pico should hopefully be just like making it work for bare metal on the Pi.
Re: Micropython embedded in a C program?
My best congratulations!
Unfortunately I can't be of any help, I can only experiment little variations in the
standard installation.
If of any utility here enclosed is a scan of all defines "MP_" in micropython sources,
at the end of the file are list
ed in alphabetical order.
Unfortunately I can't be of any help, I can only experiment little variations in the
standard installation.
If of any utility here enclosed is a scan of all defines "MP_" in micropython sources,
at the end of the file are list
- MICROPY.ZIP
- (11.96 KiB) Downloaded 4 times
Re: Micropython embedded in a C program?
Thanks for that.
The 'unix' port looked promising, even details how to build a completely standalone executable. Unfortunately that doesn't work.
There are also other issues like using your own C Modules which need resolving. What MicroPython provides does mostly work in all its incarnations. It's when one wants to add, remove, or change something, that there are challenging hurdles to jump.
The state of play as I see it is -
For the things I consider critical none of the options have it all, and all are lacking things others have which don't seem so easy to provide -
I am sure I could eventually figure it out but I have lost the will to do so. So I have abandoned this adventure to move on to other things.
The 'unix' port looked promising, even details how to build a completely standalone executable. Unfortunately that doesn't work.
There are also other issues like using your own C Modules which need resolving. What MicroPython provides does mostly work in all its incarnations. It's when one wants to add, remove, or change something, that there are challenging hurdles to jump.
The state of play as I see it is -
Code: Select all
.-----------.-----------.-----------.-----------.
| On-line | Minimal | Embed | Unix | Need
.-----------------------|-----------|-----------|-----------|-----------|
| Builds for Pico | - | - | Yes | - | < 4
| Builds for Pi | Yes | Yes | Yes | Yes |
| Bare metal on Pi | - | - | Should | - |
| Access to REPL | Yes | Yes | - | Yes | < 1
| USB serial access | - | - | Yes | - |
| Networking | - | - | - | Linux |
| Wireless networking | - | - | - | Linux |
| Internal file system | - | - | - | Linux | < 1
| SD Card FAT support | - | - | - | Linux |
| Single floats | Yes | - | Yes | Yes | < 1
| Double floats | - | - | Hacky | Yes |
| Select MP modules | - | - | - | - |
| Add own C modules | Yes | - | - | - | < 2
| Call funcs from C | Yes | Yes | Yes | Yes |
| Run Py code from C | Yes | - | Yes | ? | < 1
| Build with CMake | - | - | Yes | - |
|-----------------------|-----------|-----------|-----------|-----------|
| Score | 5 | 1 | 6 | 3 | = 10
`-----------------------^-----------^-----------^-----------^-----------'
Call funcs from C means 'mp_obj_t o = mp_new_int(1);' etc in 'main'.
Run Py code from C means creating a text string of Python and runing it.
Code: Select all
.-----------.-----------.-----------.-----------.
| On-line | Minimal | Embed | Unix | Need
.-----------------------|-----------|-----------|-----------|-----------|
| Builds for Pico | - | - | Yes | - | < 4
| Access to REPL | Yes | Yes | - | Yes | < 1
| Internal file system | - | - | - | Linux | < 1
| Single floats | Yes | - | Yes | Yes | < 1
| Add own C modules | Yes | - | - | - | < 2
| Run Py code from C | Yes | - | Yes | ? | < 1
|-----------------------|-----------|-----------|-----------|-----------|
| Score | 5 | 1 | 6 | 3 | = 10
`-----------------------^-----------^-----------^-----------^-----------'
Re: Micropython embedded in a C program?
Here enclosed are two results of my efforts:
1 - refinement of main.c to build and change a list
2 - dirty and temporary solution to embed
1
I added other Python object, now are integer, string,
list, boolean, bytes, dictionary, tuple and access and
modify of Python variables from C, and a little loop
similar to REPL to test Python commands and expressions.
Due to:
#define MICROPY_CONFIG_ROM_LEVEL (MICROPY_CONFIG_ROM_LEVEL_MINIMUM)
in mpconfigport.h the resulting kernel is very poor, missing
float, import libraries (sys,...), also the 4 integer operators
are only + - *, not /.
All tentatives of modify and add #defines in mpconfigport.h
are unsuccessful, for now.
This main.c can substitute main in @hippy pico-embed-2025年10月13日.zip
2
I reverted the building of embedding; working in
/home/pi/pico/micropython/ports/rp2 I made little changes in
main.c to build a new image firmware.uf2 where in the main
loop we can add our C pieces of code.
The changes are in lines 84 - 98 where are the hooks for new
C code, lines 248 - 255 printing a menu, lines 259 - 268 where
exclude the standard py....() loop, lines 271 - 276 where the
user select a choice.
We have to convert printf("",args) to mp_printf(&mp_plat_print,"",args)
or mp_hal_stdout_tx_str(), getchar to mp_hal_stdin_rx_chr(),
but other instructions like gpio_init(), gpio_set_dir(), gpio_put()
can be used.
The kernel is huge(630kbytes) and contains all code of RP2 standard
REPL micropython.
Is a simple test, any attempt is well accepted. Probably I find where
printf() can be reactivated, the other problems are unknown and
pending.
Obviously I saved the original ../ports/rp2 directory as ../ports/rp2_old!
The enclosed main_rp2_modif.c overwrite main.c.
1 - refinement of main.c to build and change a list
2 - dirty and temporary solution to embed
1
I added other Python object, now are integer, string,
list, boolean, bytes, dictionary, tuple and access and
modify of Python variables from C, and a little loop
similar to REPL to test Python commands and expressions.
Due to:
#define MICROPY_CONFIG_ROM_LEVEL (MICROPY_CONFIG_ROM_LEVEL_MINIMUM)
in mpconfigport.h the resulting kernel is very poor, missing
float, import libraries (sys,...), also the 4 integer operators
are only + - *, not /.
All tentatives of modify and add #defines in mpconfigport.h
are unsuccessful, for now.
This main.c can substitute main in @hippy pico-embed-2025年10月13日.zip
- main.zip
- (2.26 KiB) Downloaded 8 times
2
I reverted the building of embedding; working in
/home/pi/pico/micropython/ports/rp2 I made little changes in
main.c to build a new image firmware.uf2 where in the main
loop we can add our C pieces of code.
The changes are in lines 84 - 98 where are the hooks for new
C code, lines 248 - 255 printing a menu, lines 259 - 268 where
exclude the standard py....() loop, lines 271 - 276 where the
user select a choice.
We have to convert printf("",args) to mp_printf(&mp_plat_print,"",args)
or mp_hal_stdout_tx_str(), getchar to mp_hal_stdin_rx_chr(),
but other instructions like gpio_init(), gpio_set_dir(), gpio_put()
can be used.
The kernel is huge(630kbytes) and contains all code of RP2 standard
REPL micropython.
Is a simple test, any attempt is well accepted. Probably I find where
printf() can be reactivated, the other problems are unknown and
pending.
Obviously I saved the original ../ports/rp2 directory as ../ports/rp2_old!
The enclosed main_rp2_modif.c overwrite main.c.
- main_rp2_modif.zip
- (4.12 KiB) Downloaded 3 times
Re: Micropython embedded in a C program?
Yes, that's the sort of thing which wore me down.
Excellent work.
It's not quite so bad as that. The UF2 files are twice the size of the executable so it's 309 KB. Your version is actually about 850 bytes smaller than a standard build with the original 'main.c'.
Jump to
- Community
- General discussion
- Announcements
- Other languages
- Deutsch
- Español
- Français
- Italiano
- Nederlands
- 日本語
- Polski
- Português
- Русский
- Türkçe
- User groups and events
- Raspberry Pi Official Magazine
- Using the Raspberry Pi
- Beginners
- Troubleshooting
- Advanced users
- Assistive technology and accessibility
- Education
- Picademy
- Teaching and learning resources
- Staffroom, classroom and projects
- Astro Pi
- Mathematica
- High Altitude Balloon
- Weather station
- Programming
- C/C++
- Java
- Python
- Scratch
- Other programming languages
- Windows 10 for IoT
- Wolfram Language
- Bare metal, Assembly language
- Graphics programming
- OpenGLES
- OpenVG
- OpenMAX
- General programming discussion
- Projects
- Networking and servers
- Automation, sensing and robotics
- Graphics, sound and multimedia
- Other projects
- Media centres
- Gaming
- AIY Projects
- Hardware and peripherals
- Camera board
- Compute Module
- Official Display
- HATs and other add-ons
- Device Tree
- Interfacing (DSI, CSI, I2C, etc.)
- Keyboard computers (400, 500, 500+)
- Raspberry Pi Pico
- General
- SDK
- MicroPython
- Other RP2040 boards
- Zephyr
- Rust
- AI Accelerator
- AI Camera - IMX500
- Hailo
- Software
- Raspberry Pi OS
- Raspberry Pi Connect
- Raspberry Pi Desktop for PC and Mac
- Beta testing
- Other
- Android
- Debian
- FreeBSD
- Gentoo
- Linux Kernel
- NetBSD
- openSUSE
- Plan 9
- Puppy
- Arch
- Pidora / Fedora
- RISCOS
- Ubuntu
- Ye Olde Pi Shoppe
- For sale
- Wanted
- Off topic
- Off topic discussion