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.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.
Standard API for drivers?
Re: Standard API for drivers?
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/
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/
Re: Standard API for drivers?
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.
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.
Re: Standard API for drivers?
For many of us, the journey is the reward.
-
- Posts: 288
- Joined: Sun May 04, 2014 8:54 am
Re: Standard API for drivers?
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
- ???
Like: https://github.com/micropython-IMU/micropython-bmp180
- properties should be avoided
- ???
Re: Standard API for drivers?
Here are some subtle differences in the BME280 driver between the WiPy and the ESP port.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
- ???
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.
Re: Standard API for drivers?
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
https://github.com/micropython/micropyt ... Guidelines
Re: Standard API for drivers?
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.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.
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/
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/
Re: Standard API for drivers?
deshipu wrote: https://github.com/micropython/micropyt ... Guidelines
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.Don't create Pin/SPI/I2C/UART/etc. objects in your driver
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(...)
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/
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/
Re: Standard API for drivers?
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.Always pass bytearray to the methods that write bytes
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/
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/
Re: Standard API for drivers?
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?pfalcon wrote: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.Always pass bytearray to the methods that write bytes