SpotlightKid wrote: ↑Thu Oct 11, 2018 4:33 am
The I2C slave mode of pyb.I2C is built on-top of the STM32CubeMX library and the I2C and DMA hardware support of the ST chips. It can not be be directly ported to other architectures, not even those with also a Cortex-M.
Sure, and the ESP32 port is built on the ESP-IDF where there's support for
I2C slave mode.
But the python API we present ought to be the same for both ports. That API should be in
machine.I2C. The ESP32 could support the same MicroPython I2C slave API that's currently in
pyb. It seems fairly generic.
pythoncoder wrote: ↑Thu Oct 11, 2018 5:14 am
@mattyt I think the situation is quite simple. Try to code using
machine. If you hit a roadblock where you need a port-specific feature, use the port-specific module and accept that your code is no longer portable.
I agree, but shouldn't we put only truly port-specific features in the port-specific modules? Take a look at the
pyb module; an
awful lot of that module is
not port specific and is duplicated in
machine.
I've had
many newcomers to MicroPython get confused over this. I've also ported a few libraries that used the
pyb module instead of the generic alternatives - and worked perfectly fine on all ports when modified. I think we should be helping developers 'fall into the tar pit of success'
by making it easy to write cross-port code.
pythoncoder wrote: ↑Thu Oct 11, 2018 5:14 am
I'm not sure deprecation warnings are practicable. Is instantiating
pyb.Pin or
pyb.Timer to be deprecated? The answer depends on how you plan to use it.
I would be happier if
pyb.Pin was deprecated, yes. Or at least most of it. There's not
much there that looks port-specific. You could still retain the
pyb.Pin.board.X3 named-pins for example; but return an instance of
machine.Pin.
I agree that Timers are currently fairly port specific because hardware support does differ fairly dramatically. So leave that port-specific, at least for now.
pythoncoder wrote: ↑Thu Oct 11, 2018 5:14 am
Unfortunately there is a persistent view that
pyb is obsolescent; as far as I can see it is not. It is potentially one of a family of port-specific modules providing access to hardware features unique to that port. I don't really see a problem with this.
I guess I'm just making the case that some (a lot?) of
pyb should be obsoleted - anything that has a generic equivalent. The port-specific features are all that should be in the port-specific modules.
pythoncoder wrote: ↑Thu Oct 11, 2018 5:14 am
Hardware features like
esp32.TouchPad probably cannot be ported to STM: AFAICR the hardware simply does not exist. The timer channels on STM are completely platform-specific and you can be sure that other platforms will have their own incompatible realisations.
I'm not convinced. The
esp32.TouchPad API is quite generic; it looks compatible with the SAMD range for example. It's basically just a value corresponding to the amount of capacitance detected on a pin.
If TouchPad was instantiated on a platform
without cap touch features - like STM - then either the API shouldn't exist for that port or, better, an exception ("Capacitive touch not present for this port") should be raised.
pythoncoder wrote: ↑Thu Oct 11, 2018 5:14 am
A generic machine module can support interfaces which are well-defined industry standards such as UART's, I2C, and SPI. You can produce abstractions for common pieces of hardware such as an RTC, but even there you'll find alligators - alarms, wakeups and suchlike. And, as @SpotlightKid suggested, a truly generic I2C has an issue. I think
machine will always represent a lowest common denominator of functionality which all platforms can be expected to support.
I think I feel the same way though I think my definition of what should be in
machine is perhaps a little larger. Debating what should be in or out of machine is reasonable. But I don't see any good reason to leave methods in
pyb that already have equivalents.
There
are going to be differences between hardware - like you highlighted with RTC. There are a few ways we can handles this but carving out different port-specific API's when the majority - or the 80% - of features used is less than ideal since user code will be bound to a port.
In RTC for example we could define the common interface (including basic wakeup and alarm features) and throw exceptions on ports that don't have that support. Or, if that port has incompatible low-level API's then that functionality could go into the port-specific module - probably passing in the generic RTC instance as a parameter.
pythoncoder wrote: ↑Thu Oct 11, 2018 5:14 am
As for lobbying Damien, this is your call. The subject was discussed
ad nauseam on GitHub with no clear resolution. I suspect he's very busy, hopefully preparing Pyboard D for us
I've seen some of the vast bikeshedding that happens on these kinds of tickets...
I don't expect Damien to do any of this work - I want PYBD as much as anyone! - but my reason for 'lobbying' is because I wouldn't want to raise a PR modifying
pyb unless it had his blessing.