We use some essential cookies to make our website work.

We use optional cookies, as detailed in our cookie policy, to remember your settings and understand how you use our website.

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?

Mon Sep 22, 2025 2:54 pm

hippy wrote: ↑
Mon Sep 22, 2025 2:11 pm
jamesh wrote: ↑
Mon Sep 22, 2025 1:36 pm
hippy wrote: ↑
Mon Sep 22, 2025 1:28 pm
 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.
Why single out Micropython for special treatment when there are so many other projects?
1) Because this is the MicroPython sub-forum.

2) Because this thread relates to MicroPython documentation issues which might well be resolved through more sponsorship.

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 also seems 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.
You must do a lot of lamenting, because every time someone buys a Pi to run something from `apt`, we make a (small) profit.

1. The question of sponsorship is broader than just Micropython
2. Would they?
Software guy, working in the applications team.
hippy
Posts: 19831
Joined: Fri Sep 09, 2011 10:34 pm

Re: Possible hardware or MicroPython bug?

Mon Sep 22, 2025 3:26 pm

jamesh wrote: ↑
Mon Sep 22, 2025 2:54 pm
 1. The question of sponsorship is broader than just Micropython
Indeed but this is the sub-forum for MicroPython so lamenting lack of Raspberry Pi sponsorship for MicroPython is pertinent and valid here IMO.

Whatever the wider issues of sponsorship are I don't believe it invalidates my lament that Raspberry Pi doesn't sponsor the MicroPython project.
jamesh wrote: ↑
Mon Sep 22, 2025 2:54 pm
 2. Would they?
I believe so. The issue of RP2 specific documentation being incomplete or lacking might however be better addressed by Raspberry Pi contributing their expertise in those areas. That would at least serve RP2 and Pico-range users if no one else. It currently seems Raspberry Pi does neither.
DirkS
Posts: 11516
Joined: Tue Jun 19, 2012 9:46 pm

Re: Possible hardware or MicroPython bug?

Mon Sep 22, 2025 3:34 pm

hippy wrote: ↑
Mon Sep 22, 2025 3:26 pm
jamesh wrote: ↑
Mon Sep 22, 2025 2:54 pm
 1. The question of sponsorship is broader than just Micropython
Indeed but this is the sub-forum for MicroPython so lamenting lack of Raspberry Pi sponsorship for MicroPython is pertinent and valid here IMO.
This is a topic on a (possible) bug which you hijacked to start 'lamenting'.
Something you seem to enjoy...
hippy
Posts: 19831
Joined: Fri Sep 09, 2011 10:34 pm

Re: Possible hardware or MicroPython bug?

Mon Sep 22, 2025 3:44 pm

DirkS wrote: ↑
Mon Sep 22, 2025 3:34 pm
hippy wrote: ↑
Mon Sep 22, 2025 3:26 pm
jamesh wrote: ↑
Mon Sep 22, 2025 2:54 pm
 1. The question of sponsorship is broader than just Micropython
Indeed but this is the sub-forum for MicroPython so lamenting lack of Raspberry Pi sponsorship for MicroPython is pertinent and valid here IMO.
This is a topic on a (possible) bug which you hijacked to start 'lamenting'.
Something you seem to enjoy...
I don't agree with either but you are entitled to your opinion.

My lament was in response to a poster noting that MicroPython "do not have the time ..." and that's very true. They are a small and poorly funded team running a rather huge project. That could IMO be improved upon if they received more sponsorship.
gmx
Posts: 1845
Joined: Thu Aug 29, 2024 8:51 pm

Re: Possible hardware or MicroPython bug?

Mon Sep 22, 2025 5:03 pm

MicroPython is part of a business entity.

But back to the problem:

Code: Select all 

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
I think it's a concept issue how the PWM slices (modules) and channels are tied to pins in MicroPython.
The second constructor (user_led) should throw an error as the same hardware (PWM slice) and the same channel is already used (conflict).
If want to use multiple pins, the user should do it through GPIO function select.
hippy
Posts: 19831
Joined: Fri Sep 09, 2011 10:34 pm

Re: Possible hardware or MicroPython bug?

Mon Sep 22, 2025 6:24 pm

gmx wrote: ↑
Mon Sep 22, 2025 5:03 pm
 The second constructor (user_led) should throw an error as the same hardware (PWM slice) and the same channel is already used (conflict).
If want to use multiple pins, the user should do it through GPIO function select.
I am not against that though I'd favour a 'yes_i_want_that=True' as a 'machine.PWM' parameter to allow it than having to invent some new means of function select.

The problem is someone has to implement it and handle the knock-on effects elsewhere. That it's such a rare issue it is easier to just document it, leave the code as is, and get on with other things which would be more beneficial for the MicroPython community.

The first step for anyone wanting to implement improvements would be to raise it as an issue or discussion, make a proposal and determine the MicroPython team's position on that, then work on a PR which delivers it.
gmx
Posts: 1845
Joined: Thu Aug 29, 2024 8:51 pm

Re: Possible hardware or MicroPython bug?

Mon Sep 22, 2025 9:17 pm

What do you mean by "having to invent some new means of function select"?

The problem here is a hardware conflict.
gmx
Posts: 1845
Joined: Thu Aug 29, 2024 8:51 pm

Re: Possible hardware or MicroPython bug?

Mon Sep 22, 2025 11:00 pm

BTW can use print on PWM objects:

Code: Select all 

>>> print( machine.PWM(9) )
<PWM slice=4 channel=1 invert=0>
>>> print( machine.PWM(25) )
<PWM slice=4 channel=1 invert=0>
hippy
Posts: 19831
Joined: Fri Sep 09, 2011 10:34 pm

Re: Possible hardware or MicroPython bug?

Tue Sep 23, 2025 9:38 am

gmx wrote: ↑
Mon Sep 22, 2025 9:17 pm
 What do you mean by "having to invent some new means of function select"?
If the solution is "If want to use multiple pins, the user should do it through GPIO function select", there has to be some means for a MicroPython user to do that, apply a "GPIO function select", some MicroPython method available to call to allow that to be done.

As far as I could see no such method existed and would therefore need to be invented.

Basically; what are you going to replace the last line here with ... ?

Code: Select all 

from machine import PWM
PWM(9, freq=1000, duty_u16=0x8000)
PWM(25, freq=1000, duty_u16=0x8000)
However it appears this does work -

Code: Select all 

from machine import PWM, Pin
PWM(9, freq=1000, duty_u16=0x8000)
Pin(25, alt=Pin.ALT_PWM)
But I still believe this would be better, using whatever parameter name can be agreed upon -

Code: Select all 

from machine import PWM
PWM(9, freq=1000, duty_u16=0x8000)
PWM(25, freq=1000, duty_u16=0x8000, yes_i_really_want_to_do_this=True)
That doesn't preclude 'alt=Pin.ALT_PWM' being used if preferred and simplifies things if the two pins were only known at run-time.

But 'do nothing except improve the documentation' is still the easiest option.
gmx
Posts: 1845
Joined: Thu Aug 29, 2024 8:51 pm

Re: Possible hardware or MicroPython bug?

Tue Sep 23, 2025 4:46 pm

Maybe discovered :) , as it has already been invented: https://docs.micropython.org/en/latest/ ... e.Pin.html
As you have seen, can use the constructor or Pin.init method.

By doing "yes_i_really_want_to_do_this=True" way, you still have a hardware conflict.
As specified above, the Pin class allows to set an alternate function for a particular pin, but it does not specify any further operations on such a pin. Pins configured in alternate-function mode are usually not used as GPIO but are instead driven by other hardware peripherals. The only operation supported on such a pin is re-initialising, by calling the constructor or Pin.init() method. If a pin that is configured in alternate-function mode is re-initialised with Pin.IN, Pin.OUT, or Pin.OPEN_DRAIN, the alternate function will be removed from the pin.
Also look at other peripherals like UART, SPI, I2C etc.
class machine.UART (id, ...)
Construct a UART object of the given id.

class machine.SPI (id, ...)
Construct an SPI object on the given bus, id. Values of id depend on a particular port and its hardware. Values 0, 1, etc. are commonly used to select hardware SPI block #0, #1, etc.

class machine.I2C (id, *, scl, sda, freq=400000, timeout=50000)
Construct and return a new I2C object using the following parameters:
id identifies a particular I2C peripheral. Allowed values for depend on the particular port/board
hippy
Posts: 19831
Joined: Fri Sep 09, 2011 10:34 pm

Re: Possible hardware or MicroPython bug?

Tue Sep 23, 2025 5:29 pm

gmx wrote: ↑
Tue Sep 23, 2025 4:46 pm
 By doing "yes_i_really_want_to_do_this=True" way, you still have a hardware conflict.
I don't understand how you mean. If it's legitimate to route the same channel-slice to multiple pins - as it is, then I don't see that as a hardware conflict, I don't see how it's any different to routing the same channel-slice to that pin using alternative functions, which is what MicroPython does under the hood.
gmx
Posts: 1845
Joined: Thu Aug 29, 2024 8:51 pm

Return to "MicroPython"

AltStyle によって変換されたページ (->オリジナル) /