I had the pleasure to play with different platforms running micropython. Pyboards, Wipys, esp-based boards and very recently lopy boards. One thing I always struggle is to identify which function I could expect in which library. Never really can remember whether it should be within the machine or the esp, wipy or pyb lib.
It came to my mind that the naming scheme might be one of the reasons (the bigger reason might be my aging brain).
Now we have the lib
"machine" which as written in the docs contains - functions related to the board
and we have a special libs e.g.
"esp" - functions related to the ESP8266
"wipy" - WiPy specific features
"pyb" - contains functions related to the board
This naming is already kind of twisting my brain. Why do we have two libs which are basically address both the board itself (wipy, pyb)?
(I know for the pyb, this has historical reasons). Furthermore, even the "machine" lib is called the same on each platform the content differs slightly (is that true, just what I observed). This might confuse people switching between platforms, since code which seemed to work on one, does not on the other, despite the fact that they called the same lib.
If we project this into the future with much more boards and much more chips, thing will get more and more complicated.
Thus, I thought it would be a good idea to make a more clear separation. Having a lib-duo called
$soc (system on chip) which is basically the soc family name and $board, which is basically the board name.
Thus the structure would look like this:
"$soc" contains all and everything which based on the actual chip. The name could be STM32F4, ESP8266, nRF51, ESP32, etc.
Thus, this includes Pin, ADC, DAC, Timer, SPI, I2C. All the stuff a blank chip is capable to do in theory.
Yes, there are hundreds of deviations but I think that is something we could deal with by calling a init function
E.g. a
Code: Select all
import soc.stm32f4 as stm
stm.init("STM32F405RG")
stm.list() could return a list of all supported models.
Thus, users could now simply identify the chip of a certain board and if there is a soc-lib, chances are high that this board can be used directly with micropython,
The second lib would be the board libs, which contains all functions to address peripherals on the board itself. LEDs, switches, other chips, etc. This would help to let people now whether a certain board has already full support. It would also be easy for people to write a board-lib for a new board and hence enlarge the board family. It basically wraps many of the soc lib stuff and make it easier accessible for the user. E.g. an additional chip connected via a SPI port could be directly addressed since we know this is hard wired on that particular board. Thus users, do not have to deal with the SPI stuff but can directly use functions to utilise the chip itself.
The distinction between boards and chips sounds rather logical to me. Micropython can easily support hundred of boards based on the same chip, without to much effort.
E.g. we would have an soc lib for the esp8266 and board libs for huzzah, feather, d1mini, etc. The soc lib would remain the same, whereas the board libs cover the features of the individual boards. If someone manages to get micropython running on another esp8266-based board he could contribute another board lib. Thus, a complete access to a certain board would be achieved by
Code: Select all
import soc.esp8266 as esp
import board.d1mini as d1
#just as an example, in case there are several deviates of the esp8266
esp.init("esp8266ex")
#direct access of board functions no pin init needed
d1.led(1)
stat = d1.button.status()
#access of the soc functions
a = esp.Pin(0, Pin.OUT)
a.value(0)
esp.deepsleep()
