Possible hardware or MicroPython bug?
So I've been developing a couple of projects on the Pico (1st gen) using MicroPython firmware 1.26.0 and I may have bumped into a possible bug, either in MicroPython or the Pico hardware itself. I've tested this on more than one Pico and I get the same results. The bug is that under certain conditions--as described in the comments below--GPIO9 behaves as if it is connected to the Pico's on-board LED (GPIO25).
Here's how to reproduce this bug, at least this is how I am able to easily reproduce it:
1. Wire up a typical common cathode LED to GPIO9.
2. Run the script below.
Here's how to reproduce this bug, at least this is how I am able to easily reproduce it:
1. Wire up a typical common cathode LED to GPIO9.
2. Run the script below.
Code: Select all
from machine import Pin, PWM
from time import sleep
pico_led = PWM(Pin(25), freq=1000) # Pico's on-board LED (GPIO25)
user_led = PWM(Pin(9), freq=1000) # standalone LED wired to GPIO9
# When the code below executes, both LEDs will turn on, and then after
# two seconds, both will turn off. This occurs despite only one LED at
# at time being given a duty cycle value, and it occurs only when both
# LEDs are defined as PWM devices. This strange connection does not
# appear to exist between the on-board LED and any other GPIO pin, and
# is not observed if either (or both) LEDs are defined as regular Pin
# devices.
pico_led.duty_u16(49000) # approx 75% brightness
sleep(2)
user_led.duty_u16(0)
Re: Possible hardware or MicroPython bug?
"Possible hardware or MicroPython bug?"
Or maybe neither?
Perhaps simply undefined - and therefore apparently variable - behaviour when a MicroPython script terminates?
That is pretty much what I would expect to happen based on reading your code.
Or maybe neither?
Perhaps simply undefined - and therefore apparently variable - behaviour when a MicroPython script terminates?
# When the code below executes, both LEDs will turn on, and then after
# two seconds, both will turn off.
That is pretty much what I would expect to happen based on reading your code.
Beware of the Leopard
Re: Possible hardware or MicroPython bug?
Just see the RP2040 datasheet. The answer is in there.
Re: Possible hardware or MicroPython bug?
It might help to explain what the answer is rather than expect a first time poster to wade through a 640+ page datasheet trying to figure out where the answer is without knowing what they are even looking for.
I would also suggest it should never be necessary for a MicroPython user to have to open the RP2040 datasheet, that any gotchas should be included in the relevant MicroPython documentation. Unfortunately - https://docs.micropython.org/en/latest/rp2/quickref.html - isn't very clear on the issue the OP appears to be encountering.
I presume the issue is that PWM on Pin 9 and 25 are both controlled by the same PWM hardware; change one and you change the other, turn one off and the other goes off as well.
It wouldn't have taken much more effort to have written that and would have been far more useful.
If you are suggesting it's something else you'll have to explain that to me.
Re: Possible hardware or MicroPython bug?
It's more important to me to see folks acquire the skills of problem solving and troubleshooting, rather than having the answers handed out at once. And TLDR == I'm allergic to spoon-feeding :D :D
Obviously a person troubleshooting would go to the PWM section in the datasheet to find some answers to the issue.
So to everyone here, feel free to fill in the blanks. :P
Obviously a person troubleshooting would go to the PWM section in the datasheet to find some answers to the issue.
So to everyone here, feel free to fill in the blanks. :P
Re: Possible hardware or MicroPython bug?
I'll try again.
We have two PWM'd outputs controlled by a trivial Micropython script.
What do we expect - backed up by documentation if possible - the behaviour of those outputs to be when the script ends?
To me it is unsurprising that both outputs revert to OFF.
Which is the behaviour documented by @zslane -
# When the code below executes, both LEDs will turn on, and then after
# two seconds, both will turn off.
Beware of the Leopard
Re: Possible hardware or MicroPython bug?
OP is surprised there is a connection.
OP's code comment as follows:
OP shouldn't be surprised if OP had read the datasheet section on PWM.
OP's code comment as follows:
Code: Select all
# When the code below executes, both LEDs will turn on, and then after
# two seconds, both will turn off. This occurs despite only one LED at
# at time being given a duty cycle value, and it occurs only when both
# LEDs are defined as PWM devices. This strange connection does not
# appear to exist between the on-board LED and any other GPIO pin, and
# is not observed if either (or both) LEDs are defined as regular Pin
# devices.
Re: Possible hardware or MicroPython bug?
The 16 PWM channels (8 2-channel slices) appear on GPIO0 to GPIO15, in the order PWM0 A, PWM0 B, PWM1 A...
This repeats for GPIO16 to GPIO29.
GPIO16 is PWM0 A, GPIO17 is PWM0 B, so on up to PWM6 B on GPIO2
GP9 & GP25 BOTH refer to the SAME slice 4B
If you read the 640 page document this is explained in section 4.5.2 but for some inscrutable reason is not listed on pinout or any accessible user documentation (as least as far as I can see).
This repeats for GPIO16 to GPIO29.
GPIO16 is PWM0 A, GPIO17 is PWM0 B, so on up to PWM6 B on GPIO2
Code: Select all
GPIO 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
PWM Channel 0A 0B 1A 1B 2A 2B 3A 3B 4A 4B 5A 5B 6A 6B 7A 7B
GPIO 16 17 18 19 20 21 22 23 24 25 26 27 28 29
PWM Channel 0A 0B 1A 1B 2A 2B 3A 3B 4A 4B 5A 5B 6A 6B
If you read the 640 page document this is explained in section 4.5.2 but for some inscrutable reason is not listed on pinout or any accessible user documentation (as least as far as I can see).
Last edited by Milliways on Fri Sep 19, 2025 12:10 pm, edited 2 times in total.
Re: Possible hardware or MicroPython bug?
I guess we have differing views on what's helpful or appropriate, and what's spoon-feeding, but I think most would agree that "RTFM" - especially thrown at first time posters - isn't at all useful nor welcoming.
Along with software and hardware development I have spent much of my life doing technical support for users which often includes the newbies and inexperienced, those taking their first tentative steps into an unknown world. Most importantly, I remember how it was when I was in their position and have reflected on what helped and what didn't, what was useful or insightful, what went over my head, or was pretty much useless.
I am therefore pretty sympathetic to those who need a little help in figuring something out, especially when there's the danger they will just throw in the towel and consider programming as something not for them, something they don't have an aptitude for, walk away and never be seen again.
Sometimes just telling them the answer is the best way to get them over the initial hurdles, especially when frustration at something not doing as expected, would reasonably be expected, is growing.
And, let's be honest, this issue is pretty esoteric, not what most would be expecting. I would hazard a guess that more than a fair few could only say "no idea" when it came to whatever the problem was. Those were my initial thoughts.
I entirely disagree.
The whole point of using a high-level programming language is to distance oneself from the underlying hardware and architecture, and that IMO applies to documentation and datasheets as well.
The first port of call should be the MicroPython documentation and, as said, that should explain any gotchas in respect of 'machine.PWM', should not require going deeper than that. The MicroPython documentation alludes to the issue here, but doesn't spell it out, and it could be improved. Maybe someone could raise an issue against that.
What I initially expected was the program ending but continuing to run whatever background tasks it had running. I would include hardware PWM in that so I was surprised both LED were turned off.
I then thought that maybe MicroPython resets everything it was doing when a program ends which would also explain what the OP was seeing, but that seemed at odds with my personal experience.
I am not sure if or where what a MicroPython does and doesn't do when it terminates is documented.
Only then did I think it was related to using PWM and the gotchas that involves.
Re: Possible hardware or MicroPython bug?
Hence the need for users to know both the software and hardware. :D
Usually there is no compelling reason for the hardware designer to put in a mux-everything block for PWM lines.
@hippy, I too got tripped by stuff when I first started using the Pico C SDK. Problem is, there is so much information to digest that it is not practical for software documentation to tell you everything there is to know. Hence, one should read both software and hardware Or browse, at least.
It's a complexity problem.
Usually there is no compelling reason for the hardware designer to put in a mux-everything block for PWM lines.
@hippy, I too got tripped by stuff when I first started using the Pico C SDK. Problem is, there is so much information to digest that it is not practical for software documentation to tell you everything there is to know. Hence, one should read both software and hardware Or browse, at least.
It's a complexity problem.
Re: Possible hardware or MicroPython bug?
Thank you very much for this information.Milliways wrote: ↑Fri Sep 19, 2025 11:56 amThe 16 PWM channels (8 2-channel slices) appear on GPIO0 to GPIO15, in the order PWM0 A, PWM0 B, PWM1 A...
This repeats for GPIO16 to GPIO29.
GPIO16 is PWM0 A, GPIO17 is PWM0 B, so on up to PWM6 B on GPIO2
GP9 & GP25 BOTH refer to the SAME slice 4BCode: Select all
GPIO 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 PWM Channel 0A 0B 1A 1B 2A 2B 3A 3B 4A 4B 5A 5B 6A 6B 7A 7B GPIO 16 17 18 19 20 21 22 23 24 25 26 27 28 29 PWM Channel 0A 0B 1A 1B 2A 2B 3A 3B 4A 4B 5A 5B 6A 6B
I am going to update my quick reference Pico pinout diagram to the one from adafruit. Even though it lists the PWM slices (which others I've found online don't), it fails to show which slices are assigned to GPIO23 - GPIO25, though it could be reasonably deduced from the revealed assignment pattern.
To be honest, even if I had the adafruit diagram on hand from the start, I don't think I would have grasped what the PWM labels were telling me, at least in terms of this notion of "slice sharing". I'm a software guy not a hardware guy, and this microcontroller stuff is all very new to me.
Re: Possible hardware or MicroPython bug?
Look here: Raspberry Pi Pico – PWM Primer
https://www.codrey.com/raspberry-pi/ras ... wm-primer/
https://www.codrey.com/raspberry-pi/ras ... wm-primer/
- GPIO_PWM-Table.jpg
- GPIO_PWM-Table.jpg (42.47 KiB) Viewed 2294 times
- Raspberry-Pi-Pico-PWM-Pins.jpg
- Raspberry-Pi-Pico-PWM-Pins.jpg (49.54 KiB) Viewed 2294 times
Re: Possible hardware or MicroPython bug?
Unfortunately if are planning to use the hardware there is no shortcut to reading some of the documentation describing HOW to use the hardware.zslane wrote: ↑Fri Sep 19, 2025 6:32 pmTo be honest, even if I had the adafruit diagram on hand from the start, I don't think I would have grasped what the PWM labels were telling me, at least in terms of this notion of "slice sharing". I'm a software guy not a hardware guy, and this microcontroller stuff is all very new to me.
The 640 page Reference is intimidating, even to an engineer, and most irrelevant to using a Pico (as distinct from designing your own hardware) but you treat it as a Reference; use the index to find the relevant bits.
gmx has found & posted the relevant bit i.e. the Programmers Model which is what I referenced.
-----------
NOTE this is also documented in the MicroPython documentation General information about the RP2xxx port
PWM (pulse width modulation)
There are 8 independent PWM generators called slices, which each have two channels making it 16 PWM channels in total which can be clocked from 8Hz to 62.5Mhz at a machine.freq() of 125Mhz. The two channels of a slice run at the same frequency, but can have a different duty rate. The two channels are usually assigned to adjacent GPIO pin pairs with even/odd numbers. So GPIO0 and GPIO1 are at slice 0, GPIO2 and GPIO3 are at slice 1, and so on. A certain channel can be assigned to different GPIO pins (see Pinout). For instance slice 0, channel A can be assigned to both GPIO0 and GPIO16.
Last edited by Milliways on Sat Sep 20, 2025 1:43 am, edited 2 times in total.
Re: Possible hardware or MicroPython bug?
Right below the table is this sentence:
The datasheet is wordier than other company's docs -- it's supposed to be easier to digest versus docs from traditional chip companies. So at some point it's impossible to make things simpler. Familiarization is important; that's why I suggest browsing. I browse a lot of datasheets -- same concept as browsing an entire DIY superstore like Ace HW; you'd get an idea what's in there. We've all started from zero, made plenty of mistakes too.
"Try SCE to Aux"
https://en.wikipedia.org/wiki/John_Aaron
Was around 26 when he saved the Apollo 12 mission with a call that nobody had a clue about. Familiarization with systems is a good thing. While one can abstract a lot of things away into the background using software stacks, for modern complex MCUs the scheme often breaks down. Pico intro books etc mostly do not broach this issue of systems complexity.
[Edit] Here is a more nuanced view:
More than SCE to AUX - Apollo 12 Lightning Strike Incident
https://www.nasa.gov/history/afj/ap12fj ... trike.html
Everyone acquitted themselves well, but hindsight is 20/20. Sure, "Try SCE to Aux" is a bit of myth-making, but more sensible than the "failure is not an option" mantra which pundits often leave out the endless tests and sims performed to iron out kinks and got everyone well-preped. Today hobbyists like me are running smash into complexity in systems, so certainly there are lessons to be learned from the past about problem solving and getting things done.
Code: Select all
The same PWM output can be selected on two GPIO pins; the same signal will appear on each GPIO."Try SCE to Aux"
https://en.wikipedia.org/wiki/John_Aaron
Was around 26 when he saved the Apollo 12 mission with a call that nobody had a clue about. Familiarization with systems is a good thing. While one can abstract a lot of things away into the background using software stacks, for modern complex MCUs the scheme often breaks down. Pico intro books etc mostly do not broach this issue of systems complexity.
[Edit] Here is a more nuanced view:
More than SCE to AUX - Apollo 12 Lightning Strike Incident
https://www.nasa.gov/history/afj/ap12fj ... trike.html
Everyone acquitted themselves well, but hindsight is 20/20. Sure, "Try SCE to Aux" is a bit of myth-making, but more sensible than the "failure is not an option" mantra which pundits often leave out the endless tests and sims performed to iron out kinks and got everyone well-preped. Today hobbyists like me are running smash into complexity in systems, so certainly there are lessons to be learned from the past about problem solving and getting things done.
Re: Possible hardware or MicroPython bug?
This is where the MicroPython documentation is lacking. If it were complete there would be no need to have to look at any datasheets.Milliways wrote: ↑Sat Sep 20, 2025 12:41 amThe two channels are usually assigned to adjacent GPIO pin pairs with even/odd numbers. So GPIO0 and GPIO1 are at slice 0, GPIO2 and GPIO3 are at slice 1, and so on. A certain channel can be assigned to different GPIO pins (see Pinout). For instance slice 0, channel A can be assigned to both GPIO0 and GPIO16.
I am still rejecting the idea that any MicroPython user should have to look at any chip datasheet. It may be useful to do so if one can understand such things but it should never be necessary. If it is it shows something is lacking in documentation elsewhere. And that's what should be fixed.
The two channels are usually assigned to adjacent GPIO pin pairs with even/odd numbers.
That's not right; there is no "usually" about it; it is always the case. Saying "usually" suggests there are cases when that's not true which confuses things.
Having a table or diagram showing which channels and slices on each pin as per the datasheet would help here.
A certain channel can be assigned to different GPIO pins (see Pinout). For instance slice 0, channel A can be assigned to both GPIO0 and GPIO16.
What this actually means could be much better described; that channels wrap after the 16th and explicitly noting that changing the slice directed to one pin will change the other pin it is routed to. That also apples to frequency of both slices of a channel.
I would prefer it describing pins being driven by channels and slices rather than what channels and slices can be directed to. Two diagrams would cater for both.
Re: Possible hardware or MicroPython bug?
Sure; having knowledge saves the day - Just as it has in this thread with people being able to explain what the OP didn't know.katak255 wrote: ↑Sat Sep 20, 2025 1:15 am"Try SCE to Aux"
https://en.wikipedia.org/wiki/John_Aaron
Was around 26 when he saved the Apollo 12 mission with a call that nobody had a clue about.
And thankfully he didn't reply "Read the datasheet; it's all in there", "RTFM".
While Aaron was rightly hailed a hero the real lesson is that his failing to document and disseminate his discovery could have doomed the flight. It was only good fortune he was there to provide the knowledge when needed, that he hadn't been taken ill or had been hit by the proverbial bus.
No one is denying that reading a datasheet can provide knowledge. It's whether a user is required to read the datasheet to attain the knowledge they need. Reading the datasheet should in my view always be a matter of last resort.
Re: Possible hardware or MicroPython bug?
@hippy, I think your expectations about MicroPython documentation is a little too high. :D :D :D
Realistically, a scenario of perfect documentation is never gonna happen. Parts gets released too fast for MicroPython to appear like a nicely stable piece of software.
We know most of these software projects chronically lack resources; why does one persist in expecting that somehow their documentation will be maintained such that it absolutely smooths the way for every user of that software?
I guess I'm not going to convince you of anything. Have a nice day! :P
Realistically, a scenario of perfect documentation is never gonna happen. Parts gets released too fast for MicroPython to appear like a nicely stable piece of software.
We know most of these software projects chronically lack resources; why does one persist in expecting that somehow their documentation will be maintained such that it absolutely smooths the way for every user of that software?
I guess I'm not going to convince you of anything. Have a nice day! :P
Re: Possible hardware or MicroPython bug?
I don't believe so though I am happy to accept that it could always be better than it is and will unlikely ever be perfect.
It's pretty much there in this case, just needs some minor work doing. I would issue a PR to have that updated myself but I won't be able to do so for the usual reasons. But if anyone wants to do that by linking to this post to help others, this is how I would write it ...
<quote>
https://docs.micropython.org/en/latest/rp2/quickref.html
PWM (pulse width modulation)
On the RP2040 and RP235xA there are 8 independent hardware PWM generators, 0 to 7, called slices. Each slice has two channels, A and B, providing 16 hardware PWM outputs in total.
On the RP235xB there are 12 independent hardware PWM generators, 0 to 11, called slices. Each slice has two channels, A and B, providing 24 hardware PWM outputs in total.
Each slice can be independently clocked from 8Hz to 62.5Mhz at a machine.freq() of 125Mhz. The two channels of each slice run at the same frequency, but each can have a different duty rate.
Every output pin can have a particular PWM slice and channel routed to it as shown in the following tables -
For the RP2040 and RP235xA -
Code: Select all
.------------------.-------. .------------------.-------.
| GPIO0 GPIO16 | 0 A | | GPIO1 GPIO17 | 0 B |
| GPIO2 GPIO18 | 1 A | | GPIO3 GPIO19 | 1 B |
| GPIO4 GPIO20 | 2 A | | GPIO5 GPIO21 | 2 B |
| GPIO6 GPIO22 | 3 A | | GPIO7 GPIO23 | 3 B |
| GPIO8 GPIO24 | 4 A | | GPIO9 GPIO25 | 4 B |
| GPIO10 GPIO26 | 5 A | | GPIO11 GPIO27 | 5 B |
| GPIO12 GPIO28 | 6 A | | GPIO13 GPIO29 | 6 B |
| GPIO14 | 7 A | | GPIO15 | 7 B |
`------------------^-------' `------------------^-------'
Code: Select all
.------------------.-------. .------------------.-------.
| GPIO0 GPIO16 | 0 A | | GPIO1 GPIO17 | 0 B |
| GPIO2 GPIO18 | 1 A | | GPIO3 GPIO19 | 1 B |
| GPIO4 GPIO20 | 2 A | | GPIO5 GPIO21 | 2 B |
| GPIO6 GPIO22 | 3 A | | GPIO7 GPIO23 | 3 B |
| GPIO8 GPIO24 | 4 A | | GPIO9 GPIO25 | 4 B |
| GPIO10 GPIO26 | 5 A | | GPIO11 GPIO27 | 5 B |
| GPIO12 GPIO28 | 6 A | | GPIO13 GPIO29 | 6 B |
| GPIO14 GPIO30 | 7 A | | GPIO15 GPIO31 | 7 B |
`------------------^-------' `------------------^-------'
Code: Select all
.------------------.-------. .------------------.-------.
| GPIO32 GPIO40 | 8 A | | GPIO33 GPIO41 | 8 B |
| GPIO34 GPIO42 | 9 A | | GPIO35 GPIO43 | 9 B |
| GPIO36 GPIO44 | 10 A | | GPIO37 GPIO45 | 10 B |
| GPIO38 GPIO46 | 11 A | | GPIO39 GPIO47 | 11 B |
`------------------^-------' `------------------^-------'
When two or more output pins are driven from the same slice, for example GPIO0, GPIO1, GPIO16 and GPIO17, any change in one of the pin's PWM frequency will also change the PWM frequency for the others.
When two output pins are driven from the same slice and channel, for example GPIO0 and GPIO16, any change in either pin's duty rate will also change the duty rate of the other.
More information on the internal workings of the PWM hardware can be found in section 4.5 of the RP2040 datasheet and section 12.5 of the RP2350 datasheet.
</quote>
Last edited by hippy on Sat Sep 20, 2025 6:08 pm, edited 1 time in total.
Re: Possible hardware or MicroPython bug?
What exactly do you mean by this? Not sure if it's true...
hippy wrote: Also note that if you have routed a slice's B channel to an output pin, and then use the other pin which would be on the same slice and channel as an input, the output pin will be the hardware PWM output OR'd with the input. For example, if GPIO1 (0B) were made an input and GPIO17 (also 0B) were a PWM output, GPIO17 would deliver PWM only while GPIO1 input were low. While GPIO1 input is high the GPIO17 output will also be high.
Re: Possible hardware or MicroPython bug?
That was my interpretation of ...
- CAPTURE.jpg
- CAPTURE.jpg (9.18 KiB) Viewed 1833 times
But it's as clear as mud, not at all clear to me what the author is trying to convey. Having Gated PWM made sense to me but perhaps I have misunderstood it.
I am now thinking that applies to counter modes so I've removed it from the earlier text.
Re: Possible hardware or MicroPython bug?
I think that's just a reminder of
(削除) and GPIO17 (also 0B) were a PWM output (削除ここまで)" when having the same function (PWM). It's the peripheral which controls the same direction for all selected pins/pads.
SIO and PIO inputs do not count as they have dedicated input lines, and can always read the lines regardless of the selected function/direction.
Basically you cannot do this: "if GPIO1 (0B) were made an input2.19.2. Function Select
...
Each GPIO can have one function selected at a time. Likewise, each peripheral input (e.g. UART0 RX) should only be
selected on one GPIO at a time. If the same peripheral input is connected to multiple GPIOs, the peripheral sees the
logical OR of these GPIO inputs.
SIO and PIO inputs do not count as they have dedicated input lines, and can always read the lines regardless of the selected function/direction.
Re: Possible hardware or MicroPython bug?
You could pick any Microcontroller from any company, and you'll always do have limitations. e.G. the ESP32 could not use ADC0-Block, if WiFi is enabled. Don't blame Micropython, because they do not have the time to read every single page of the datasheet. So maybe someone will make a pull request with some hints for rp2 & PWM.
Re: Possible hardware or MicroPython bug?
I still consider it lamentable that, even though Raspberry Pi profit from having MicroPython available for RP2 devices and Pico-range boards, they still do not appear to be a sponsor of the MicroPython project, helping to improve MicroPython and its documentation for the users of it.
- jamesh
- Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator - Posts: 35174
- Joined: Sat Jul 30, 2011 7:41 pm
Re: Possible hardware or MicroPython bug?
Why single out Micropython for special treatment when there are so many other projects?hippy wrote: ↑Mon Sep 22, 2025 1:28 pmI still consider it lamentable that, even though Raspberry Pi profit from having MicroPython available for RP2 devices and Pico-range boards, they still do not appear to be a sponsor of the MicroPython project, helping to improve MicroPython and its documentation for the users of it.
Software guy, working in the applications team.
Re: Possible hardware or MicroPython bug?
1) Because this is the MicroPython sub-forum.jamesh wrote: ↑Mon Sep 22, 2025 1:36 pmWhy single out Micropython for special treatment when there are so many other projects?hippy wrote: ↑Mon Sep 22, 2025 1:28 pmI still consider it lamentable that, even though Raspberry Pi profit from having MicroPython available for RP2 devices and Pico-range boards, they still do not appear to be a sponsor of the MicroPython project, helping to improve MicroPython and its documentation for the users of it.
2) Because this thread relates to MicroPython documentation issues which might well be resolved through more sponsorship.
3) My take regarding other projects would be off-topic in this thread and sub-forum.
I think it's lamentable when any company profits from the work of others but doesn't reward those who help generate those profits. To me it's no better than profiting from the work of unpaid interns - which Raspberry Pi does seem to find abhorrent.
If you can provide a list of projects Raspberry Pi profits from but doesn't sponsor or contribute to in return I will be happy to pass judgement on those. It's probably better to start a separate thread if there are so many.
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