BeagleBoard/GSoC/2021 Proposal/Micropython for BeagleConnect Freedom

=[Micropython for BeagleConnect Freedom] =

About Student: Szymon Duchniewicz Mentors: Jason Kridner Code: No code just yet Wiki: https://elinux.org/BeagleBoard/GSoC/2021_Proposal/Micropython_for_BeagleConnect_Freedom GSoC: GSoC entry

=Status= Submitted for review.

About you
IRC: Willmish Github: Willmish School: University College London Country: United Kingdom/Poland Primary language: Polish Typical work hours: 8AM-5PM CET Previous GSoC participation: I haven't participated before in GSoC but I am very intrigued by the idea of being able to work with an Open Source organization, as I always wanted to get involved with Open Source and this looks like a great place to start! Furthermore, I believe that through this project I could develop my current skill-set substantially both in software and hardware domains. As I have some previous experience in working with embedded systems such as Arduino and Rpi and programming them in Python, I thought that the idea of bringing Micropython to BeagleConnect Freedom is great and would fit my current capabilities quite well, while also posing an interesting challenge!

About your project
Project name: Micropython for BeagleConnect Freedom

Description
The goal of this project is to enable Micropython for BeagleConnect Freedom along with basic GPIO, I2C, SPI, PWM, ADC drivers. MicroPython is a C implementation of the widely known and used Python3 language aimed specifically to run on a microcontroller. A ported MicroPython would allow for easy out-of-the-box development and prototyping with BeagleConnect Freedom, Python being an easy to learn and use language, with powerful capabilities at the same time being very concise. The drivers would be written in C as an extension and interface to MicroPython. The port itself along with additional extensions would be based on the official documentation by MicroPython for porting the language. Additionally after the MicroPython port and writing the basic drivers I could test them in practice using the supported MikroElectronika boards.

Porting MicroPython
Before doing anything else, MicroPython itself needs to be ported to work on Zephyr RTOS and the BealgeConnect Freedom itself, as the rest of the project relies on a working ported version of it. A work-in-progress port for Zephyr would be the starting point for this part of the project. Ensuring that a minimal build with a simple REPL loop can be built and run on the BeagleConnect board would be the next step.

To do this, first mpconfigport.h would need to be configured to board-specific configuration. As BeagleConnect is using Zephyr, some of it can be carried over from the main port of Zephyr, but many other configs will need to be modified to CC1352P chip-specific, others such as the heap size have to be verified. CC1352P has 80kB total RAM and the current ported version requires 16kB for its heap so this value could be kept as is.

As a step-by-step explanation, the porting process will look as follows:
 * Cloning the existing Zephyr port for MicroPython
 * Testing if the port can be properly built on the BeagleConnect Freedom, if not it will have to be adapted to work properly. Alternatively a completely new port can be set up.
 * Any further configurations and edits will be done with accordance to MicroPython's guide to porting, which can be found here.
 * Further modules (in our case SPI, I2C etc. drivers) can be added by following an example shown in the guide mentioned above, which can be found here

Writing drivers
The basic drivers required by this project include GPIO, I2C, SPI, PWM and ADC, since they would allow many sensors interfacing with the BeagleConnect Freedom to be programmable and utilised via MicroPython. As Python in general is more space and time hungry than C, and given we have limited resources on the microcontroller, it is logical to write those basic drivers in C and create MicroPython interfaces for them.

In the current port of MicroPython for Zephyr a MicroPython module machine is already implemented with some basic submodules and functionalities for I2C and GPIO. Therefore these modules would need to be extended or rewritten to be able to interface with BeagleConnect Freedom as well as additional such drivers would be implemented for SPI, PWM and ADC. The BeagleConnect Freedom uses Greybus to communicate with connected devices, so a possible approach would be to make the drivers communicate through Greybus which is a possible extension to the project. The main goal is to make this communication direct with Zephyr and an implementation of such driver is described next based on a example for I2C module:


 * Initially, implementation in Zephyr RTOS for each driver has to be identified and thoroughly understood. All of these drivers (GPIO, I2C, SPI, PWM and ADC) can be found here. (Additionally bluetooth driver as well as many others are also implemented, allowing for future extensions).
 * Then for I2C and GPIO the already implemented versions in the ported MicroPython for Zephyr have to be checked and rewritten if not compatible with BeagleConnect Freedom.
 * For all other modules, a driver has to be implemented as a submodule of the machine module to interface with the already existing Zephyr drivers.
 * Lastly, each driver needs to be thoroughly tested using a MikroElectronika board or by other means. This can for example entail using a simple LED to test PWM output, or connecting other I2C devices and collecting data from them.

The graph below is a visualisation of the implementation of basic drivers and their interface with MicroPython on one end, and Zephyr RTOS on the other.



Below is a rough requirement list of the drivers, a short description of them and how they will interact with BeagleConnect Freedom. All these drivers will be submodules of the machine module. These requirements are based on the actual implementation of those modules in MicroPython.

GPIO Module
The GPIO driver should allow developers to manipulate and read from GPIO pins on the BeagleConnect Freedom. Actions such as setting a pin to HIGH, LOW or reading current state would be required. More detailed explanation of necessary functions and constructors can be found on MicroPythons documentation for GPIO module. As mentioned before this driver will interface with the existing Zephyr driver.

I2C Module
The I2C module allows for 2 wire communication using the I2C protocol. This should allow for software and hardware I2C connections, sending data over I2C, receiving data and scanning for connected devices. Unlike MicroPython implementation for boards without RTOS such as Zephyr, I2C memory registers and pins do not have to be defined as its already handled in Zephyr main repo and the whole MicroPython driver only needs to interface with that Zephyr driver. Full list of requirements for I2C can be found here.

SPI Module
The SPI module allows for 4 wire communication using the SPI protocol/interface. The driver should allow for software and hardware SPI connections, sending and receiving data over SPI. Just as all the other modules, full list of requirements for SPI driver can be found here and will interface with the already in place Zephyr driver found here.

PWM Module
The PWM module allows for Pulse-Width modulated signals sent from GPIO pins with PWM capabilities. More information on PWM can be found here. This is not implemented in the main MicroPython library, so it will be based on the port specific implementation for ESP8266/ESP32 with documentation examples which can be found here. Similarly to previous modules it will interface with an existing PWM driver for Zephyr RTOS, which can be found here

ADC Module
The ADC module provides an interface to analog-to-digital convertors. In principle, it should allow continues voltage to be converted to a discrete, quantized value from a particular pin. Full list of requirements can be found here and will interface with an existing ADC driver for Zephyr RTOS, which can be found here.

Project Deliverables
As the project is somewhat extensive, it is necessary to have a list of elements which will be produced as a part of the end result of the project. Here is a list of these components along with a short explanation for each one:
 * Ported version of MicroPython, working on BeagleConnect Freedom with Zephyr RTOS.
 * Working and tested GPIO, I2C, SPI, PWM and ADC drivers.
 * Code examples for each module, thoroughly commented for other developers to use.
 * Documentation of the drivers and the port itself.
 * REAMDE with build instructions, description of implemented modules, etc.

CircuitPython port
After successfully completing a MicroPython port for the BeagleConnect Freedom and writing the minimal drivers, porting CircuitPython would be a good addition. Although CircuitPython is far less advanced than MicroPython, it is more newbie-friendly. This would allow beginners easier entry to the world of IOT and for experimenting with the BeagleConnect. Adafryut has a similar guide to MicroPython's for creating a new port, which can be found here. After successfully porting, the ported version can be tested using Adafruit's CircuitPython boardtest.

Adding more MicroPython modules to work with the BeagleConnect Freedom
There are many libraries (modules) implemented in the core version of MicroPython, ranging from libraries derived from original Python3 core libraries to MicroPython-specific libraries (such as machine module). Adding some of those libraries would give more possibilities when developing on BeagleConnect Freedom using MicroPython. An example would be to implement ubluetooth library which could be used by the BeagleConnect node device. Also adding UART duplex serial communication would be a nice extension to increase the number of possible MikroElectronika devices to be used with BeagleConnect.

Rewriting the drivers to communicate via Greybus
Although I have not met Greybus before, after reading about it and talking with other members of BeagleBoard community, it seems like writing the drivers to communicate using them could be a good idea, as BeagleConnect already utilities it. More precisely it could be useful for development if a BeagleConnect enabled host with a Greybus was to communicate with other peripherals/BeagleConnect node devices over Bluetooth, cause these communications could be established and controlled with MicroPython. This would eliminate the need to resort to other devices when using MicroPython to communicate via GreyBus.

Experience and approach
I am currently a first year Computer Science student, but Programming, Electronics and Computer Science in general is a hobby of mine for many years now. I have managed to create a few project and gain a lot of experience since then. Some of my knowledge of C I have gained while working on a project developing a simple Shell in C, which can be found here. The project encouraged me to dive deeper into the inner workings of a Shell as well as a REPL loop, while also gaining valuable knowledge of Linux in general.

Additionally I have a strong knowledge base of Python, as it was one of my first languages to ever learn and I completed multiple projects involving this technology. The projects worth mentioning here include a Sorting Algorithm Complexity Analysis Tool (SACAT), whose first prototype me and my colleagues from university recently have finished. The project can be found here along with a extensive report/proposal of that project. Main principle of it is to give a simple-to-use tool which given any sorting algorithm can estimate and display its time and space complexity, as well as test the algorithms correctness. Another interesting project was actually part of my end-of-high school examination and involved creating an IDE for statically typed Python, with type checking and can be found here, though it is a prototype with limited capabilities.

Furthermore I have done some small contributions to open source projects such as Raspberry Pis docs and even though it was just a small change it showed me that everyone can contribute to such projects. I would like to continue contributing to such open source projects (though maybe this time in slightly bigger contributions!).

I have previous experience with microcontrollers and embedded systems such as Ardunio, Raspberry Pi and STM32, starting from a project I completed 4 years ago based on Arduino Micro for a follow liner robot with colour sensors, a brief presentation explaining its design process and some videos of it in action can be found here. Along with my brothers I have also taken part in and completed element14's design challenge: 1 meter of pi, during which we have created a prototype of a gardening drawer that fits under your bed - Envidrawer. More information on that project can be found on our blogs here.

I also have a lot of experience in 3D printing (as well as fixing them, as most of 3D printer users probably do :D!) and all parts used in my electronics projects are designed and 3D printed by me! Samples of that can be found in the Envidrawer project linked above.

Contingency
Since the project requires mostly individual work on the project, I will make sure to get in touch with the BeagleBoard community to get feedback/help from more experienced developers if my mentor is not available. It is crucial to remain calm when a big obstacle is met in project development and I so keeping that in mind I will look for alternative solutions to the problem. Additionally there is plenty of information to help me out already available in MicroPython documentation as to how porting should be done and many examples of already complete ports on MicroPython's github. If taking the above into consideration I still do not find the answer, I can ask on relevant subreddits for help as there are other smart people who may know the solution to my problem :).

Also I could look at the already ported versions of MicroPython and their implementation of all those drivers.

Benefit
Below are some quotes from the BeagleBoard community regarding the proposal as well as stretch goals mentioned. Doing a Micropython Greybus host would be great. Doing it on the Wio Terminal has been a thought. So, Freedom is a Greybus device and Wio Terminal would access the peripherals over Greybus over BLE. ~Jkridner

Misc
Pull request required for qualification can be found here.