Standard API for drivers?

Discuss development of drivers for external hardware and components, such as LCD screens, sensors, motor drivers, etc.
Target audience: Users and developers of drivers.
pfalcon
Posts: 1155
Joined: Fri Feb 28, 2014 2:05 pm

Re: Standard API for drivers?

Post by pfalcon » Tue May 10, 2016 10:02 pm

miltmobley wrote: 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.
Awesome MicroPython list
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/

User avatar
deshipu
Posts: 1385
Joined: Thu May 28, 2015 5:54 pm

Re: Standard API for drivers?

Post by deshipu » Tue May 10, 2016 10:48 pm

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.

User avatar
Roberthh
Posts: 2441
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Standard API for drivers?

Post by Roberthh » Wed May 11, 2016 6:56 am

For many of us, the journey is the reward.

Turbinenreiter
Posts: 288
Joined: Sun May 04, 2014 8:54 am

Re: Standard API for drivers?

Post by Turbinenreiter » Wed May 11, 2016 6:44 pm

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
- ???

User avatar
jwissing
Posts: 29
Joined: Thu Jun 19, 2014 12:23 pm
Location: Germany

Re: Standard API for drivers?

Post by jwissing » Wed May 11, 2016 8:35 pm

Turbinenreiter wrote: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.

User avatar
deshipu
Posts: 1385
Joined: Thu May 28, 2015 5:54 pm

Re: Standard API for drivers?

Post by deshipu » Wed May 11, 2016 9:55 pm

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
Posts: 1155
Joined: Fri Feb 28, 2014 2:05 pm

Re: Standard API for drivers?

Post by pfalcon » Thu May 12, 2016 8:47 am

deshipu wrote: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.
Awesome MicroPython list
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/

pfalcon
Posts: 1155
Joined: Fri Feb 28, 2014 2:05 pm

Re: Standard API for drivers?

Post by pfalcon » Thu May 12, 2016 8:56 am

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.
Awesome MicroPython list
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/

pfalcon
Posts: 1155
Joined: Fri Feb 28, 2014 2:05 pm

Re: Standard API for drivers?

Post by pfalcon » Thu May 12, 2016 9:00 am

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.
Awesome MicroPython list
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/

User avatar
deshipu
Posts: 1385
Joined: Thu May 28, 2015 5:54 pm

Re: Standard API for drivers?

Post by deshipu » Thu May 12, 2016 9:36 am

pfalcon wrote:
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?

Post Reply