MicroPython vs. Circuit Python

[David16962]

What are the difference between MicroPython vs. CircuitPython for Pico?

Which one to choose, for long time C programmer learning Python for physical computing, I2C, SPI, GPIO, accessing internet, Bluetooth, Wi-Fi, PIO, register-level programming as needed, etc. Thank you

[B.Goode]

What are the difference between MicroPython vs. CircuitPython for Pico?

Which one to choose, for long time C programmer learning Python for physical computing, I2C, SPI, GPIO, accessing internet, Bluetooth, Wi-Fi, PIO, register-level programming as needed, etc. Thank you

This is what the maintainers of CircuitPython say -
https://docs.circuitpython.org/en/8.2.x ... icropython

[hippy]

Which one to choose, for long time C programmer learning Python for physical computing, I2C, SPI, GPIO, accessing internet, Bluetooth, Wi-Fi, PIO, register-level programming as needed, etc. Thank you

I would suggest MicroPython.

Simply because Raspberry Pi officially supports the use of MicroPython on the RP2040. Which means users are more likely to have experience of using MicroPython than CircuitPython. People will have gained MicroPython specific knowledge from that, and there is this sub-forum for MicroPython, while there is nothing here specifically for CircuitPython.

But as to which is better or more suitable for use cases; that's no easier to answer than trying to choose between makes of car. Each has their pro's and con's, and each their own philosophy as to what they seek to be and how they achieve that.

This is an interesting read - https://andywarburton.co.uk/2023/i-aske ... icropython

I'm no fan of ChatGPT and a lot of what it produced there is what I would call posturing, waffle, padding and repetition, but I don't think I could put it any better. Swings and roundabouts. Neither IMO are as ideal as I believe they could be. So, unless prepared to research into which might be best on your own criteria, it's choose your poison and hope you haven't picked the wrong one.

[ame]

MicroPython. It's the original.

[Mike**K]

MicroPython. It's the original.

So's the Ford Model T. There's got to be a better argument than that?

[hippy]

MicroPython. It's the original.

So's the Ford Model T. There's got to be a better argument than that?

Especially if we continue the analogy, label MicroPython 'the production model', which lets us consider CircuitPython to be 'the tricked-out custom job'.

I think a car analogy is appropriate. MicroPython and CircuitPython are built around the same chassis and the same engines and it's mostly in the bodywork, fixtures and fittings, that they differ. Which library modules they offer and particularly in terms of how they approach libraries and modules for hardware interfacing.

From the big picture perspective, MicroPython's approach can be described as delivering a vehicle based around the engine and chassis chosen. How the driver's fascia will look will depend on what those support. CircuitPython have taken an approach that they want all their vehicles to look the same from the inside no matter what engine or chassis is chosen.

But that matters little when you've chosen the engine and a chassis, it is about what's on offer when one climbs into the driver's seat of the respective offerings.

And then it's quickly into the nitty-gritty of detail, toggle switches versus rotary, square dials against round, indicators on the left or the right. These will often be matters of personal preference but don't in themselves determine which is better.

Like buying an actual car it perhaps comes down to what extras are available, whether you currently need them or not.

I can't be a fair judge on that but I do know CircuitPython offers things which MicroPython doesn't or not yet, USB HID, MP3 playing capability, better internationalisation, more refined USB configuration, some sort of 'crash recovery', more hardware interface modules. I am sure there are some things which aren't so great with MicroPython having features of acclaim, even if I can't list them; I have never sat down to compare them.

[bgolab]

I am playing with MicroPython - I also have C background. And the latest version is pretty good for my purposes (WiFi, BLE) when the 2nd Core is not involved.

I do see some issues related to 2nd Core. I cannot make it working with WiFi, have some issues when the 2nd Core is mixed with regular timers (random freezes) (BTW. When mentioning timers I mean software emulated timers - I believe they do not support hw timers at least until now).

I do not know if the CPythom performs better in these areas. I stick to the MP as it is officially supported by the Raspberry (whatever it means).

[ame]

MicroPython. It's the original.

So's the Ford Model T. There's got to be a better argument than that?

Micropython is Free. Circuitpython exists only to boost sales for a parts company.

[hippy]

Micropython is Free. Circuitpython exists only to boost sales for a parts company.

I don't believe that characterisation of CircuitPython is correct, certainly not the "only" part. CircuitPython is no less free than MicroPython.

[ame]

Micropython is Free. Circuitpython exists only to boost sales for a parts company.

I don't believe that characterisation of CircuitPython is correct, certainly not the "only" part. CircuitPython is no less free than MicroPython.

Then why does it exist?

[Douglas6]

Then why does it exist?

They think they can do a better job.

[hippy]

They think they can do a better job.

Exactly that. The people at Adafruit thought there were ways to do things different to how MicroPython did them, which would be better for MicroPython users, but the MicroPython people did not agree.

Unable to reach a consensus they agreed to disagree. CircuitPython forked from MicroPython and both headed in the direction they believed was right.

I don't know the exact details but the main bone of contention appears to be that Adafruit believed what was on offer should be the same for every supported board, that code written for one board, if it could run on another board, should run on that board without change, that there should be a standardised HAL to facilitate this.

MicroPython appears to have not agreed, thought what was on offer should be tailored to each chip and board, that the 'machine' module did not need to be a standardised HAL or be replaced by one.

When modules written for a PyBoard running MicroPython don't run under MicroPython for an RP2040 simply because the HAL is subtly different for each I find it hard to say CircuitPython were wrong.

MicroPython do these days seem to be moving towards having a unified HAL.

This is how Scott Shawcroft, who forked MicroPython into CiruitPython, described the reasoning and history -

https://pyfound.blogspot.com/2019/05/sc ... ython.html

CircuitPython isn't the only fork of MicroPython but is perhaps the most well known one -

https://github.com/adafruit/awesome-micropythons

[scruss]

I do see some issues related to 2nd Core. I cannot make it working with WiFi

wifi is only supported on one core on the RP2040/CYW43 combo that is the Raspberry Pi Pico W. Doesn't matter what language you use, you won't get wifi access on both cores.

Flaws in Adafruit's "One HAL, Many Chips" approach include:

1. methods have been known to go away completely between versions in a seemingly arbitrary manner
2. examples for one board may no longer work with newer CircuitPython/library versions, and Adafruit is not always good at updating the documentation
3. the CircuitPython standard library list is huge, and barely fits in a 4 MB flash board. It has to be cut down selectively to fit in 2 MB. (It's also a pain to keep up to date)

CircuitPython has not always been a “friendly fork” (as Scott Shawcroft put it). Adafruit's work on SAMD chips was never fed back to MicroPython, which now has its own SAMD implementation from a volunteer developer.

[hippy]

It's definitely swings and roundabouts and, as I said, I don't consider either MicroPython or CircuitPython to be perfect.

I am not sure why CircuitPython didn't just take MicroPython, add board ports as needed, and add the 'making it easier' on top, which is what we effectively seem to have when running CircuitPython libraries under MicroPython using 'blinka'. Whether hubris or a desire for differentiation it doesn't really matter as it's done now. And, if MicroPython won't accept proposals for what one wants, or there are philosophical differences in where it's heading, the only option is to 'put up and shut up' or to 'fork it'. Unfortunately it does mean it's often not so easy to move between CircuitPython and MicroPython, one is somewhat forced to choose one or the other, pick and choose on a per project basis.

Because of divergence it does seem it has made it harder for CircuitPython to keep up to date with MicroPython changes, incorporate what MicroPython may have added. It's not even easy to discover which version of MicroPython the latest CircuitPython is based on.

MicroPython hasn't made things easy either. Being a law unto themselves allows fundamental changes which can break things for those trying to use MicroPython while 'adding value to it'. Just trying to tweak things for my own port of 'latest MicroPython' has been something of a nightmare and I imagine it's even worse for CircuitPython, and I would expect divergence to get worse in the future.

[scruss]

... And, if MicroPython won't accept proposals for what one wants, ...

It will, and does. On github. Workable proposals with adequate sponsorship attached get action. Otherwise, whistle.

Looking at the date of the micropython forks repo, it's fairly clear it was created by Phil T at Adafruit to justify their fork to CircuitPython. And there were lots of forks, and so many incompatible (like wifi but no floats on the early Pycom forks) but most have fallen away.

[hippy]

... And, if MicroPython won't accept proposals for what one wants, ...

It will, and does. On github. Workable proposals with adequate sponsorship attached get action. Otherwise, whistle.

But only if Damien and the MicroPython team approve of the change, believe it sits well with MicroPython philosophy and dogma, which is fair enough.

One of the CircuitPython disagreements was in arguing things should be properties, if one wants to get a 16-bit ADC reading ...

• reading = adcPin.read_u16

MicroPython disagreed, stood by things being methods ...

• reading = adcPin.read_u16()

Is MicroPython going to accept a proposal to move from methods to properties ? It didn't and I doubt it ever will. If you want properties, 'fork it'.

Likewise when it comes to 'please don't do that'. If it's decided that's the way it's going to be that's the way it will be. Don't like it 'fork it'.

[scruss]

Damien will always be in charge of language decisions. It's his project.

Sure, you can always fork it. But you can also be forgotten, like the loboris fork, the Pycom fork, ...

[Gavinmc42]

I would say MicroPython is generic and Circuit Python is specific.

If your application uses Adafruit hardware then CircuitPython will probably have a Library for it.
Working hardware and a working library is a great starting point towards a working application.

I uses whatever is quicker and will work and needs the least debugging
The more choices available is better in MHO.
Personally I prefer Free Pascal on Pico, but cross compiling that is not supported yet on my Aarch64 Pi400

CircuitPython running on baremetal Pi's is an interesting option too.
The more options, the more languages, the more libraries, the more choices for us.

[hippy]

Sure, you can always fork it. But you can also be forgotten, like the loboris fork, the Pycom fork, ...

Yes, but I am not sure what your point is. The bottom line is CircuitPython has proven itself successful, has been embraced by many who prefer it and its philosophy over MicroPython. And MicroPython has successfully continued in its chosen direction.

I would say MicroPython is generic and Circuit Python is specific.

I would say it was the other way round, that you are more likely able to take a CircuitPython program which runs on one board and have it run on another without major change than you are with MicroPython.

But I can agree with the description in terms of MicroPython being the generic foundation, CircuitPython the icing on top which makes it more usable by users in applications.

If your application uses Adafruit hardware then CircuitPython will probably have a Library for it.
Working hardware and a working library is a great starting point towards a working application.

I would say it's more about external hardware support than controller board support. If you want to use some external chip, module or breakout board, then CircuitPython will likely have a driver module for it which will work no matter what controller board you have. The same is often true for on-board features.

That's not the case for MicroPython. There are fewer universal driver modules and, if you can find a driver module for an external chip or even an on-board feature for one board, it will likely need changing to run on a different board.

We see the that in this forum when people want to use a particular chip with a Pico, are seeking a driver for it, and there isn't one.

There might be a driver module for another MicroPython board but it doesn't run on a Pico. There might be a CircuitPython driver module for it but it's not as simple as just installing it and using it under MicroPython.

That CircuitPython likely will have a library for what one wants to use which will just work is CircuitPython's main selling feature.

That CircuitPython likely does while MicroPython more likely doesn't, but has its own USP, is why both are in the running as options and users have to make a choice as to which to use. And why questions as to which would be best to choose and use regularly come up, here and elsewhere.

And there is no simple answer, no single answer.

[Gavinmc42]

And there is no simple answer, no single answer.

Yep and more than a few times I just use Arduino instead of Pythonese.
The more choices, the more ways to skin the cat app.

Depends on the app and the particular chip or chip choices for the hardware spec and who has a working lib for that chip.
If it is a simple i2c chip then I can write my own driver, anything more complex I prefer libs from better coders than myself

C, C++, Basic, Python's...., I have even used Ada on the Pico.
Even generic/specific takes a different meaning when looking at this from a different direction.

I do tend to stick with the Pico micro-controller and swap languages/IDEs instead of micos.
The tools/language options for other micros can be limited