mirrors
/
micropython
mirror of https://github.com/micropython/micropython.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updated ContributorGuidelines (markdown)

Jim Mussared 2022-08-30 16:59:43 +10:00
parent 9e6f38b557
commit ffbf74283d
1 changed files with 5 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
ContributorGuidelines.md

@ -21,6 +21,8 @@ It's often a good idea before starting a piece of work to get some feedback from
MicroPython itself is written in C, but most of the support tooling and build infrastructure, as well as drivers and libraries are written in Python. In general, if it's possible to implement something in either C or Python, we prefer Python. It is possible to extend MicroPython in C++, but no C++ code is used in the main repository. MicroPython itself is written in C, but most of the support tooling and build infrastructure, as well as drivers and libraries are written in Python. In general, if it's possible to implement something in either C or Python, we prefer Python. It is possible to extend MicroPython in C++, but no C++ code is used in the main repository.
When working on MicroPython, especially the core VM, runtime, or standard library, it is much more productive to use the Unix or Windows ports, as you can run it locally without having to deploy it to a device. The Unix port works on Linux (including embedded Linux distributions), macOS, and *BSD, and Windows Subsystem for Linux. The Windows port provides both a Visual Studio project and a Cygwin-based makefile build.
# What to contribute # What to contribute
## Bug fixes ## Bug fixes
@ -29,12 +31,12 @@ When submitting a fix, please include a detailed description of how the bug occu
Bug fixes can sometimes have unintended and complicated interactions with other features and an the "obvious" fix might not always be the "correct" fix. It might take a bit of backwards-and-forwards discussion to resolve this. Bug fixes can sometimes have unintended and complicated interactions with other features and an the "obvious" fix might not always be the "correct" fix. It might take a bit of backwards-and-forwards discussion to resolve this.
## New features ## New features
When it comes to adding features to MicroPython, it's important to remember that MicroPython is named "micro" for a reason. We don't want to compete with CPython or replace it, rather to try to find the right subset that makes sense for the embedded world. We support devices with as little as 128kiB of flash and 16kiB of RAM. Even the Unix port can be used to run MicroPython on truly minimal Linux systems with just 4MiB or even 2MiB of flash. As much as we'd like to, in the spirit of keeping things "micro", not all features can be added to MicroPython. It's important to find the right subset of functionality that makes sense for the embedded world.
MicroPython supports devices with as little as 128kiB of flash and 16kiB of RAM. Even the Unix port can be used to run MicroPython on truly minimal Linux systems with just 4MiB or even 2MiB of flash. To give you an idea of how highly we value code size, the MicroPython team will spent hours of effort just to save 100's (or even 10's) of bytes. This unfortunately means that the code can be more complicated, but it is a worthwhile trade-off.
In many cases, features can be enabled conditionally for a given target (i.e. boards with lots of flash or RAM, or the Unix/Windows ports). The continuous integration will check any new changes to ensure that our "minimal" ports do not increase in size. In many cases, features can be enabled conditionally for a given target (i.e. boards with lots of flash or RAM, or the Unix/Windows ports). The continuous integration will check any new changes to ensure that our "minimal" ports do not increase in size.
To give you an idea of how highly we value code size, the MicroPython team will spent hours of effort just to save 10's of bytes from a given feature. This unfortunately means that the code is more complicated, but it's a worthwhile trade-off.
## Ports ## Ports
We welcome ports to new architectures and microcontroller families. However, not all ports can be accepted into the main repository as each port is a significant maintenance overhead for the core team. It is straightforward to maintain a third-party "out-of-tree" port using MicroPython as a submodule. We welcome ports to new architectures and microcontroller families. However, not all ports can be accepted into the main repository as each port is a significant maintenance overhead for the core team. It is straightforward to maintain a third-party "out-of-tree" port using MicroPython as a submodule.