#almost the whole size. IMporting it adds

1 messages · Page 1 of 1 (latest)

rough aurora
#

@fervent sand let's start a thread

#

the meeting is going on now so I'd like to keep the transcript clean

fervent sand
#

dmcomm:

Hi, my team has a hardware design with a Pico W in it. RAM is getting tight on the Pico W image on CircuitPython 8, and currently blocking upgrade to 9. There are savings to be made in code that was written when there seemed to be plenty of RAM, but may not go far enough.
If we were looking to add an official board, is there a minimum quantity to be considered, and would it require its own USB VID/PID despite being a Pico W? (Noting that Badger 2040 W has one.)
If we were looking to release a modified CircuitPython ourselves, are there guidelines about that?

danh:

If you're making your own board that you'd like to release as an official board (as opposed to some product where CircuitPython is not visible to the user, say), then it's fine to make that a contributed board. You can get a USB PID from https://github.com/raspberrypi/usb-pid or from https://pid.codes/.
If you want to fork and maintain your own version, we ask that you not call it "CircuitPython". See https://docs.circuitpython.org/en/latest/README.html#branding
I think a regular board definition with more features turned off (PICO DVI, USB host, etc.) may get you back enough RAM.
Or you can ship with 8.2.x for now.
[...] i think whether we remove some stuff or not from the current Pico W build is still up in the air. Also I want to look at the RAM consumption.

dmcomm:

[...] Submitting a board would make some things easier but there could be issues with not having control over lib versions if it does have extra frozen libs in it

danh:

is the badger a similar example?
It's a bit like Badger but with a standard app that most people will be using, though people in that community may also be interested in it as a dev platform

rough aurora
#

if you submit a PR to update a frozen library that you wanted to update, you could distribute builds of that, either from the PR artifacts, the merged PR, or your own build. You don't have to wait for a release from us

#

the point about your own fork is that we don't want people to say something is CircuitPython when it isn't, due to whatever changes they've made (e.g., noticeable semantic changes)

fervent sand
#

It's more the other way. The only serious case is that we were stuck on minimqtt 5.5.1 for a year, and that was when we were targeting the Nano Connect, so that sort of thing may not happen again

rough aurora
#

It's more the other way.
Not sure what you mean by that -- you mean changes you don't want?

fervent sand
#

Updates to libraries that break things for us

rough aurora
#

you can tell people which release is supported on your own support apges, and you could include that in the board definition on circuitpython.org

fervent sand
#

So the board definition can freeze a different version of a library from what other boards are using?

fervent sand
rough aurora
fervent sand
#

We already pick one version of CircuitPython to target for quite a long time

rough aurora
#

it's totally up to you. We haven't had anyone that I remember who forked us for a product, so there may be a bit to work out in terms of presented names in the firmware

fervent sand