Standard API for drivers?

[pfalcon]

I am surprised to hear that a developer of a new port would have made, for example, an SPI device that did not have the same API
as the standard, documented SPI device.

And yet that's what people are doing all the time. Example: esp8266 port forks, recently created mbed fork: forum.micropython.org/viewtopic.php?f=12&t=1781&p=10342 , etc. Of course, such efforts look like waste of effort, and sometimes actually become such, as soon as conformant port appears (e.g. reloaded esp8266 port). But it's true that there're lot of duplicated and wasted effort, and if people directed even a share of that effort towards further developing mainstream MicroPython, it would be much farther along the way.

[deshipu]

I wouldn't call it a waste of time. People are still learning a lot doing that, and exploring the problem space. It's not like they don't work on the main branch of Micropython because they work on some port -- if they didn't work on that port, they would probably work on something completely unrelated to Micropython altogether. So it's not a loss for the Micropython project and its community -- on the contrary, it lets the community grow and mature, and brings in more experienced people.

I know this is counter-intuitive, and it's hard to stop oneself from thinking "if only they would work on things that actually need doing". But it's really totally fine, and the net result is overall improvement. It's the cathedral vs. bazaar thing.

[Roberthh]

For many of us, the journey is the reward.

[Turbinenreiter]

How about we review some existing drivers and use that as a starting point to define how we want things to be done?

Like: https://github.com/micropython-IMU/micropython-bmp180
- properties should be avoided
- ???

[jwissing]

How about we review some existing drivers and use that as a starting point to define how we want things to be done?

Like: https://github.com/micropython-IMU/micropython-bmp180
- properties should be avoided
- ???

Here are some subtle differences in the BME280 driver between the WiPy and the ESP port.
http://forum.micropython.org/viewtopic. ... 315#p10559
I would like to use these drivers unmodified for the different ports, except where constraints have to be met.

[deshipu]

I added a page on the wiki for this, and I took the liberty of putting some points there already. Please discuss here, and add there anything useful.

https://github.com/micropython/micropyt ... Guidelines

[pfalcon]

I wouldn't call it a waste of time.

...

But it's really totally fine, and the net result is overall improvement. It's the cathedral vs. bazaar thing.

Right, right, and yet the shortest path from point A to point B is a straight line. It's totally fine for me, and as long as you and other folks use the above to answer their regular questions of why and when, it's just totally fine. The point I'm emphasizing is that the main developers can do a lot, but not everything (or everything, but in ever-growing amount of time). A lot depends on community, and as long as the community makes responsible choices like "I can do something which benefits MicroPython overall and directly, or can cycle loops for fun. I fully understand that everybody else will do it like me. Hereby, I choose looping around." - it's all fine. And the more people do the opposite choice, the faster progress we make.

And again, this thread is an example of direction towards faster progress, and as somebody brought up that topic, there're counterexamples too.

[pfalcon]

https://github.com/micropython/micropyt ... Guidelines

Don't create Pin/SPI/I2C/UART/etc. objects in your driver

This design pattern is called Dependency Injection and is indeed how MicroPython hardware API is intended to be used. I suggest linking to Wikipedia article to give fuller background/reminder to interested folks.

And to develop that idea further, the way portable across *any* hardware apps are intended to be written is to define all the HW interfaces in a separate file, e.g. hw_config.py. It should define full HW objects, i.e. not just pins, but also SPIs, Timer's, etc.:

Code: Select all

# LED to signal working state
led_working = Pin(...)
# LED to signal error state
led_error = Pin(...)
# SPI to communicate with a dedicated motion controller
spi_motion = SPI(...)
# Timer to measure ultrasound sensor pulses
timer_ultrasound = Timer(...)

Then a user can edit this single file for their particular hardware and all will (should) just work.

[pfalcon]

Always pass bytearray to the methods that write bytes

It's misleading to talk exactly about bytearray and I don't know where you got an idea that "On some ports methods such as I2C.writeto or I2C.writeto_mem only accept bytearray parameters". Any stream-like write method accepts buffer-like object, the first example of which is bytes object, second example - bytearray.

[deshipu]

Always pass bytearray to the methods that write bytes

It's misleading to talk exactly about bytearray and I don't know where you got an idea that "On some ports methods such as I2C.writeto or I2C.writeto_mem only accept bytearray parameters". Any stream-like write method accepts buffer-like object, the first example of which is bytes object, second example - bytearray.

That's what I gathered from the above example for porting the BME280 driver to esp8266. If it's not correct, can you please amend it in the wiki?