diff options
| author | Benjamin Shockley <benjaminshockley@hotmail.com> | 2020-08-20 13:48:15 -0500 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2020-08-20 13:48:15 -0500 |
| commit | 0084f0af24e4e219bc040c52ee723959423de6e2 (patch) | |
| tree | 1aebdb362f08bf6417caa87836e3e4e739afc964 /docs/porting.rst | |
| parent | 9aebe2f1efc99871fcf283c304e3a8700050d736 (diff) | |
| parent | 4d7b9cde33934a44c4c905a49d2f831339fc8bd2 (diff) | |
Merge pull request #2 from adafruit/master
Master
Diffstat (limited to 'docs/porting.rst')
| -rw-r--r-- | docs/porting.rst | 42 |
1 files changed, 40 insertions, 2 deletions
diff --git a/docs/porting.rst b/docs/porting.rst index 6bb514458..d28f56f47 100644 --- a/docs/porting.rst +++ b/docs/porting.rst @@ -1,5 +1,5 @@ We love CircuitPython and would love to see it come to more microcontroller -platforms. With 3.0 we've reworked CircuitPython to make it easier than ever to +platforms. Since 3.0 we've reworked CircuitPython to make it easier than ever to add support. While there are some major differences between ports, this page covers the similarities that make CircuitPython what it is and how that core fits into a variety of microcontrollers. @@ -19,7 +19,7 @@ prepping file systems and automatically running user code on boot. In CircuitPython we've dubbed this component the supervisor because it monitors and facilitates the VMs which run user Python code. Porting involves the supervisor because many of the tasks it does while interfacing with the -hardware. Once its going though, the REPL works and debugging can migrate to a +hardware. Once complete, the REPL works and debugging can migrate to a Python based approach rather than C. The third core piece is the plethora of low level APIs that CircuitPython @@ -42,6 +42,44 @@ to the port's directory (in the top level until the ``ports`` directory is present). This includes the Makefile and any C library resources. Make sure these resources are compatible with the MIT License of the rest of the code! +Circuitpython has a number of modules enabled by default in +``py/circuitpy_mpconfig.mk``. Most of these modules will need to be disabled in +``mpconfigboard.mk`` during the early stages of a port in order for it to +compile. As the port progresses in module support, this list can be pruned down +as a natural "TODO" list. An example minimal build list is shown below: + +.. code-block:: makefile + + # These modules are implemented in ports/<port>/common-hal: + CIRCUITPY_MICROCONTROLLER = 0 # Typically the first module to create + CIRCUITPY_DIGITALIO = 0 # Typically the second module to create + CIRCUITPY_ANALOGIO = 0 + CIRCUITPY_BUSIO = 0 + CIRCUITPY_NEOPIXEL_WRITE = 0 + CIRCUITPY_PULSEIO = 0 + CIRCUITPY_OS = 0 + CIRCUITPY_NVM = 0 + CIRCUITPY_AUDIOBUSIO = 0 + CIRCUITPY_AUDIOIO = 0 + CIRCUITPY_ROTARYIO = 0 + CIRCUITPY_RTC = 0 + CIRCUITPY_FREQUENCYIO = 0 + CIRCUITPY_I2CSLAVE = 0 + CIRCUITPY_DISPLAYIO = 0 # Requires SPI, PulseIO (stub ok) + + # These modules are implemented in shared-module/ - they can be included in + # any port once their prerequisites in common-hal are complete. + CIRCUITPY_BITBANGIO = 0 # Requires DigitalIO + CIRCUITPY_GAMEPAD = 0 # Requires DigitalIO + CIRCUITPY_PIXELBUF = 0 # Requires neopixel_write or SPI (dotstar) + CIRCUITPY_RANDOM = 0 # Requires OS + CIRCUITPY_STORAGE = 0 # Requires OS, filesystem + CIRCUITPY_TOUCHIO = 0 # Requires Microcontroller + CIRCUITPY_USB_HID = 0 # Requires USB + CIRCUITPY_USB_MIDI = 0 # Requires USB + CIRCUITPY_REQUIRE_I2C_PULLUPS = 0 # Does nothing without I2C + CIRCUITPY_ULAB = 0 # No requirements, but takes extra flash + Step 2: Init -------------- Once your build is setup, the next step should be to get your clocks going as |
