adafruit / circuitpython

CircuitPython - a Python implementation for teaching coding with microcontrollers

CircuitPython

circuitpython.org | Get CircuitPython | Documentation | Contributing | Branding | Differences from Micropython | Project Structure

CircuitPython is a beginner friendly, open source version of Python for tiny, inexpensive computers called microcontrollers. Microcontrollers are the brains of many electronics including a wide variety of development boards used to build hobby projects and prototypes. CircuitPython in electronics is one of the best ways to learn to code because it connects code to reality. Simply install CircuitPython on a supported USB board usually via drag and drop and then edit a code.py file on the CIRCUITPY drive. The code will automatically reload. No software installs are needed besides a text editor (we recommend Mu for beginners.)

Starting with CircuitPython 7.0.0, some boards may only be connectable over Bluetooth Low Energy (BLE). Those boards provide serial and file access over BLE instead of USB using open protocols. (Some boards may use both USB and BLE.) BLE access can be done from a variety of apps including code.circuitpython.org.

CircuitPython features unified Python core APIs and a growing list of 300+ device libraries and drivers that work with it. These libraries also work on single board computers with regular Python via the Adafruit Blinka Library.

CircuitPython is based on MicroPython. See below for differences. Most, but not all, CircuitPython development is sponsored by Adafruit and is available on their educational development boards. Please support both MicroPython and Adafruit.

Get CircuitPython

Official binaries for all supported boards are available through circuitpython.org/downloads. The site includes stable, unstable and continuous builds. Full release notes are available through GitHub releases as well.

Documentation

Guides and videos are available through the Adafruit Learning System under the CircuitPython category. An API reference is also available on Read the Docs. A collection of awesome resources can be found at Awesome CircuitPython.

Specifically useful documentation when starting out:

• Welcome to CircuitPython
• CircuitPython Essentials
• Example Code

Contributing

See CONTRIBUTING.md for full guidelines but please be aware that by contributing to this project you are agreeing to the Code of Conduct. Contributors who follow the Code of Conduct are welcome to submit pull requests and they will be promptly reviewed by project admins. Please join the Discord too.

Branding

While we are happy to see CircuitPython forked and modified, we'd appreciate it if forked releases not use the name "CircuitPython" or the Blinka logo. "CircuitPython" means something special to us and those who learn about it. As a result, we'd like to make sure products referring to it meet a common set of requirements.

If you'd like to use the term "CircuitPython" and Blinka for your product here is what we ask:

• Your product is supported by the primary "adafruit/circuitpython" repo. This way we can update any custom code as we update the CircuitPython internals.
• Your product is listed on circuitpython.org (source here). This is to ensure that a user of your product can always download the latest version of CircuitPython from the standard place.
• Your product supports at least one standard "Workflow" for serial and file access:
  • With a user accessible USB plug which appears as a CIRCUITPY drive when plugged in.
  • With file and serial access over Bluetooth Low Energy using the BLE Workflow.
  • With file access over WiFi using the WiFi Workflow with serial access over USB and/or WebSocket.
• Boards that do not support the USB Workflow should be clearly marked.

If you choose not to meet these requirements, then we ask you call your version of CircuitPython something else (for example, SuperDuperPython) and not use the Blinka logo. You can say it is "CircuitPython-compatible" if most CircuitPython drivers will work with it.

---

Differences from MicroPython

CircuitPython:

• Supports native USB on most boards and BLE otherwise, allowing file editing without special tools.
• Floats (aka decimals) are enabled for all builds.
• Error messages are translated into 10+ languages.
• Concurrency within Python is not well supported. Interrupts and threading are disabled. async/await keywords are available on some boards for cooperative multitasking. Some concurrency is achieved with native modules for tasks that require it such as audio file playback.

Behavior

• The order that files are run and the state that is shared between them. CircuitPython's goal is to clarify the role of each file and make each file independent from each other.
  • boot.py runs only once on start up before workflows are initialized. This lays the ground work for configuring USB at startup rather than it being fixed. Since serial is not available, output is written to boot_out.txt.
  • code.py (or main.py) is run after every reload until it finishes or is interrupted. After it is done running, the vm and hardware is reinitialized. This means you cannot read state from code.py in the REPL anymore, as the REPL is a fresh vm. CircuitPython's goal for this change includes reducing confusion about pins and memory being used.
  • After the main code is finished the REPL can be entered by pressing any key.
    • If the file repl.py exists, it is executed before the REPL Prompt is shown
    • In safe mode this functionality is disabled, to ensure the REPL Prompt can always be reached
  • Autoreload state will be maintained across reload.
• Adds a safe mode that does not run user code after a hard crash or brown out. This makes it possible to fix code that causes nasty crashes by making it available through mass storage after the crash. A reset (the button) is needed after it's fixed to get back into normal mode.
• Safe mode may be handled programmatically by providing a safemode.py. safemode.py is run if the board has reset due to entering safe mode, unless the safe mode initiated by the user by pressing button(s). USB is not available so nothing can be printed. safemode.py can determine why the safe mode occurred using supervisor.runtime.safe_mode_reason, and take appropriate action. For instance, if a hard crash occurred, safemode.py may do a microcontroller.reset() to automatically restart despite the crash. If the battery is low, but is being charged, safemode.py may put the board in deep sleep for a while. Or it may simply reset, and have code.py check the voltage and do the sleep.
• RGB status LED indicating CircuitPython state.
  • One green flash - code completed without error.
  • Two red flashes - code ended due to an exception.
  • Three yellow flashes - safe mode. May be due to CircuitPython internal error.
• Re-runs code.py or other main file after file system writes by a workflow. (Disable with supervisor.disable_autoreload())
• Autoreload is disabled while the REPL is active.
• code.py may also be named code.txt, main.py, or main.txt.
• boot.py may also be named boot.txt.
• safemode.py may also be named safemode.txt.

API

• Unified hardware APIs. Documented on ReadTheDocs.
• API docs are Python stubs within the C files in shared-bindings.
• No machine API.

Modules

• No module aliasing. (uos and utime are not available as os and time respectively.) Instead os, time, and random are CPython compatible.
• New storage module which manages file system mounts. (Functionality from uos in MicroPython.)
• Modules with a CPython counterpart, such as time, os and random, are strict subsets of their CPython version. Therefore, code from CircuitPython is runnable on CPython but not necessarily the reverse.
• tick count is available as time.monotonic()

---

Project Structure

Here is an overview of the top-level source code directories.

Core

The core code of MicroPython is shared amongst ports including CircuitPython:

• docs High level user documentation in Sphinx reStructuredText format.
• drivers External device drivers written in Python.
• examples A few example Python scripts.
• extmod Shared C code used in multiple ports' modules.
• lib Shared core C code including externally developed libraries such as FATFS.
• logo The CircuitPython logo.
• mpy-cross A cross compiler that converts Python files to byte code prior to being run in MicroPython. Useful for reducing library size.
• py Core Python implementation, including compiler, runtime, and core library.
• shared-bindings Shared definition of Python modules, their docs and backing C APIs. Ports must implement the C API to support the corresponding module.
• shared-module Shared implementation of Python modules that may be based on common-hal.
• tests Test framework and test scripts.
• tools Various tools, including the pyboard.py module.

Ports

Ports include the code unique to a microcontroller line.

Supported	Support status
atmel-samd	SAMD21 stable | SAMD51 stable
cxd56	stable
espressif	ESP32 beta | ESP32-C3 beta | ESP32-S2 stable | ESP32-S3 beta
litex	alpha
mimxrt10xx	alpha
nordic	stable
raspberrypi	stable
silabs (efr32)	alpha
stm	F4 stable | others beta
unix	alpha

• stable Highly unlikely to have bugs or missing functionality.
• beta Being actively improved but may be missing functionality and have bugs.
• alpha Will have bugs and missing functionality.

Boards

• Each port has a boards directory containing boards which belong to a specific microcontroller line.
• A list of native modules supported by a particular board can be found here.

Back to Top

circuitpython's Issues

SamD21E18 SD card support

Hi, I understand that this is Adafruit business, But I want ask for help, or maybe somebody can push small branch for this MCU. I think that it need only small changes just add another SPI and add a27, a28 to pins.
I using this binaries on my board without changes, All works but in E variant missing pins for SPI = SD card not working
My connection is: (like uno D11,D12,D13)
miso a19
mosi a16
sck a17
ss a18

Onboard RGB led is connected to a19, a17, a27
Onboard user button is connected to a28

I have no money to pay development but I can offer free board for testing and as a reward.
Details about WINXI project Hackaday.io

i2c fails init on soft reboot

a collision between #29 & auto-reset
if your main.py uses i2c it can't be re-run/saved because i2c will fail.

(i think this is also causing main.py with i2c in it to fail on first run but its impossible to tell cuz i can't see main.py error output)

>>> i2c = machine.I2C(machine.Pin('SCL'), machine.Pin('SDA'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: I2C bus init error

Enable framebuf module and fix SSD1306 driver to work with hardware I2C

We should enable the framebuf module to build in support for a framebuffer and basic font that's used by the SSD1306 (OLED wing) module. Enabling framebuf just requires adding this to the mphalconfigport.h:

#define MICROPY_PY_FRAMEBUF         (1)

However the SSD1306 driver (in drivers/display) doesn't work with SAMD21's I2C interface because it uses low level I2C start and stop bits to manually construct a transaction. This is fine for the ESP port with software I2C, but most hardware I2C interfaces don't support it so we need to do something else.

My quick thought is to expand the size of the framebuffer the SSD1306 class allocates so that it can include the extra address register byte sent before the buffer data: https://github.com/adafruit/micropython/blob/master/drivers/display/ssd1306.py#L118-L121 Then have the SSD1306 class read and write framebuffer data 1 byte shifted up so that it can blast out the framebuffer including address byte in one SPI write transaction.

Not a high priority, for now OLED feather wing support can wait for this fix.

Unify apis into shared-bindings

Any C backed Python api should be defined in shared-bindings with inline Sphinx docs using \\|. Move all of machine there plus other 'standard' libraries such as uos and utime.

I2C (seemingly) doesn't work

from machine import I2C, Pin

i2c_bus = I2C(scl=Pin.board.SCL, sda=Pin.board.SDA, freq=400000)
print(i2c_bus.scan())

A scan of the I2C bus always turns up empty, although there are I2C devices connected, as confirmed with other hardware that finds the devices.

Implement utime module ticks_ms function.

Right now the utime module just has sleep functions, but it would be very useful to add at least a ticks_ms function that returns a monotonically increasing millisecond tick count (at least increasing until it overflows and wraps around). This is handy for loops and such that need to know how much time has elapsed since the previous iteration. The ESP8266 port has a ticks_ms, ticks_us, etc. functions that are a good model to follow.

To implement this we probably want to use the SysTick counter and expose its value with the MicroPython HAL ticks function (currently just implemented to return 0). Poking around the ASF for the M0 I don't see many handy functions for it so might need to just deal with the SysTick registers, etc. directly.

flashing feather m0 on OS X El Capitan

This micropython version for M0 feathers is great news !

The tools/bossac_osx does not work on my Mac (OSX El Capitan). So I managed to rebuild it from https://github.com/shumatech/BOSSA.

Then, in order to avoid a "not found" error message, it seems to be easier with this track

• connect a lipo to the feather
• connect the feather to the mac
• reset the board by connecting a 10 kOhm resistor between Reset and Gnd pins
  and then launch the bossac tool.

This way, I managed to flash a feather m0 basic proto and a feather m0 adalogger.

Add descriptive help() function

Currently help() is unimplemented, but we should add a descriptive block of text that explains at least the micropython firmware version. Ideally it would have something with instructions on getting started, like with the esp8266 and microbit ports, would be nice to add too. See esp8266 help implementation: https://github.com/adafruit/micropython/blob/master/esp8266/help.c

Stop using machine in favor of microcontroller.

MicroPython's machine module varies a lot between different ports. Instead, we should define a separate API microcontroller in shared-bindings that ensures identical APIs by sharing code. It should be divided into three submodules:

• microcontroller.core Processor related functionality such as sleep states.
• microcontroller.pin Microcontroller level pin definitions such as PA13. Board names should live elsewhere. (In a separate board for example.)
• microcontroller.peripheral Provides classes for common hardware peripherals such as GPIO, I2C, SPI, Timers, UART, DAC and ADC.

Initial SPI support not working at MicroPython layer

As a quick test I tried out SPI with the MAX31855 thermocouple sensor, but it looks like at least with read calls you only get back 0x00 value bytes.

Example usage:

import machine
spi = machine.SPI(baudrate=5000000, polarity=0, phase=0, MOSI=machine.Pin('MOSI'), MISO=machine.Pin('MISO'), clock=machine.Pin('SCK'))
spi.init()
cs = machine.Pin('D6', machine.Pin.OUT)
cs.high()
# Read a temp reading.
cs.low()
data = spi.read(4)  # Read 4 bytes
cs.high()
print('Received: {0}'.format(data)))

The result from spi.read(4) is a byte string with 4 zero values, however if you look at the trace on the wires with a Saleae we're actually receiving data from the chip (channel 0 is CS, channel 1 is clock, channel 2 is the data out / MISO line with the response data from the chip, it's not all zeros):

Likely there's some plumbing to be done to get the MicroPython SPI interface working with what's supported internally for SPI flash. Opening bug as a reminder and example to test with later since SPI is still a work in progress.

esp8266: Ctrl-c during time.sleep resets the board

Odd thing I noticed, perhaps not related to our firmware but worth looking at further, if you press Ctrl-C during a time.sleep operation the board does a soft reset.

To repro, in the REPL run:

import time
time.sleep(5)

Then press Ctrl-C and you'll see the board resets instead of breaking out of the sleep:

>>> import time
>>> time.sleep(5)
PYB: soft reboot
#13 ets_task(40100164, 3, 3fff8408, 4)
Adafruit MicroPython v1.8.6-147-gd2aa05a on 2016-11-28; ESP module with ESP8266
>>> 

Analog input with string instead of machine.Pin instance fails without error

Not a high priority but it looks like accidentally configuring a ADC using a pin string name will succeed:

adc = machine.ADC('A0')

However attempting to read values with read() will just return max value 4095.

>>> adc.read()
4095

The right way for this to work is to send a machine.Pin instance like:

adc = machine.ADC(machine.Pin('A0'))

Then the values are read as expected. However it's odd that passing a string vs. machine.Pin succeeds and doesn't fail with an error. Ideally we should catch this and throw an error that tells the user they need to specify a pin instance.

atmel-samd: ILI9341 TFT driver locks up device when attempting hardware SPI calls

Trying to use the TFT FeatherWing with atmel-samd from the current master but am noticing during its initialization it appears get stuck and lock up (not even ctrl-c saves it). Connect the TFT FeatherWing to the board and make sure the FeatherWing on switch is flipped on. Then load the latest ili9341.mpy and rgb.mpy from the releases here: https://github.com/adafruit/micropython-adafruit-rgb-display/releases Try the following code:

import machine
import ili9341
spi = machine.SPI(baudrate=32000000, clock=machine.Pin('SCK'), MOSI=machine.Pin('MOSI'), MISO=machine.Pin('MISO'))
display = ili9341.ILI9341(spi, cs=machine.Pin('D9'), dc=machine.Pin('D10'))

You'll see the display creation never finishes and locks up the board. I have a feeling it's getting stuck during its SPI calls to initialize the display (the display MISO is never actually used, it's only MOSI with the board sending the display data). Tried it with 8mhz and 1mhz clock rates but got the same issue too.

Also this might be hitting a hard fault or other similar issue. I noticed the USB device disappears when it locks up so it's likely not running the USB processing interrupts, etc.

v1.8.5-20161020-13-gf5ca668 experimental build boot.py and file writing

this is for the experimental build (v1.8.5-20161020-13-gf5ca668 on 2016-10-24', machine='Adafruit Metro M0 with Flash (Experimental) with samd21g18)

boot.py does not load on start and writing to the file system on mac 10.11.6 (usb drive MICROPYTHON) gives an error, but does save (see screenshot).
.................
Traceback (most recent call last):
File "", line 1, in
NameError: name 'help' is not defined
import os
os.uname()
(sysname='samd21', nodename='samd21', release='1.8.5', version='v1.8.5-20161020-13-gf5ca668 on 2016-10-24', machine='Adafruit Metro M0 with Flash (Experimental) with samd21g18')
...............

Explain when main is running on connect

When you plug in the board and main is running make sure that it explains whats going on.

autoreset doesn't work when no serial is connected

It doesn't work immediately after a reset or after the repl has been disconnected.

Support 'clean slate' reset of peripherals

Right now we use context managers to ensure peripherals like sercoms, timers, etc. are deinitialized. This helps ensure soft reboots don't run into problems where peripherals are left in an initialized state and fail to initialize again. However we'd prefer to on reset explicitly deinitialize all the peripherals and put the board into a known 'clean' state.

NeoPixel write for SAMD21 only needs to delay 50 microseconds, not milliseconds

Right now the delay for neopixel writes is 50 milliseconds, but it should really be 50 microseconds. Pixels still work but updates are much slower.

Reduce FS caching

Make sure that MicroPython can access a file after you flush or eject a mass storage device without a board reset.

CTRL-D should reset board, but does nothing

On the REPL, CTRL-D should reset the board.
Instead the board doesn't reset and REPL becomes unresponsive.

Tested with picocom and screen.

esp8266: nativeio.DigitalInOut doesn't seem to drive most pin values as outputs

Digital outputs seem to not work for me on most pins, here's what I'm trying (with the 11/28/16 Monday build). Test main.py with useful helper function to blink a pin 3 times:

import nativeio
import board
import time

def test_pin(pin):
        digital_pin = nativeio.DigitalInOut(pin)
        digital_pin.switch_to_output()
        for i in range(3):
                print('Toggle {0}'.format(i))
                digital_pin.value = 1
                print('High')
                time.sleep(2)
                digital_pin.value = 0
                print('Low')
                time.sleep(2)

I tried it with all the digital pins and only GPIO0 seems to work and toggle the pin high and low (when reading with a multimeter). The other pins just seem to float or stay at their same values. For example try:

import board
test_pin(board.GPIO15)
test_pin(board.GPIO0)

GPIO0 seems to toggle but not GPIO15 or these other pins I tried:

• GPIO4 & SDA: no toggle
• GPIO5 & SCL: no toggle
• GPIO2: no toggle
• GPIO16: resets the board (IIRC expected for this pin, it's special on the ESP8266)
• GPIO0: toggles!
• GPIO15: no toggle
• GPIO13: no toggle
• GPIO12: no toggle
• GPIO14: no toggle
• MISO: no toggle
• MOSI: no toggle
• SCL: no toggle

Add a random number generator

The os module has a urandom function which is currently unimplemented (by default it assumes some hardware means of generating random numbers). We should investigate what's possible and worst case put in a basic software random number generator (perhaps based on Arduino's AVR generator).

utime.sleep() in main.py can "brick"

i momentarily forgot that utime.sleep() takes seconds instead of milliseconds and called utime.sleep(5000) in main.py and now i can't ^C to the REPL (COM port does appear tho), ^D, or get the mass storage to appear. yay!

probably some bug? who knows :) imma reflash this feather m0 to clear out the storage - but if this were a metro m0 you wouldn't be able to, so having some sort of external tool to clear out the SPI flash could be handy (e.g. #40). probably just a .hex that does the erasing so you can bossac it.

Investigate cookiecutter templates for easy library generation

Putting this on the main micropython lib but this really applies to the libraries (micropython-adafruit-* repos). We're starting to get a lot of conventions for libraries, like having a .travis.yml to support auto MPY generation or adding libraries as submodules to the micropython bundler repo. Let's see if we can capture all these things in a adafruit micropython library template so that a command can be run to give the scaffolding for a new library. This could include stuff like .travis.yml, a readme with instructions on exactly what to do to get bundler support, an examples folder, etc.

Cookiecutter is a generic project templating tool worth checking out for this: https://github.com/audreyr/cookiecutter

Digital output on A0 with DAC enabled doesn't work or fail

This might be by design and isn't necessarily expected to be supported, but I noticed if I enable the DAC (which uses A0 as the output) I can still create a digital output for pin A0, like:

import machine
# Enable DAC and output 0V
dac = machine.DAC()
dac.write(0)
# Now make a digital out for A0 and set it high
led = machine.Pin("A0", machine.Pin.OUT)
led.high()

After running the above the A0 pin is still at 0V. This seems expected since only one thing can control that pin at a time, however it might be nice to fail in some way so the user knows they are doing something wrong. Perhaps if you try to use pin A0 as a digital output with the DAC enabled we catch that state and fail with an error.

Not a huge priority issue.

Stop aliasing os to uos and time to utime.

Instead, provide os and time wrappers that only expose methods that match CPython's corresponding modules. Having them as an alias risks unexpected behavior as a user moves their knowledge and/or code to CPython and expects the same API.

Add enumerate function

It looks like the samd21 port doesn't have python's enumerate function enabled. The ESP port seems to have it so there must be a magic define to find and flip on. Need to dig into the code further to find it and enable support (enumerate is a very useful core function).

esp8266 & atmel-samd: nativeio.SPI should support mode / polarity & phase

Right now the nativeio.SPI implementation only supports mode 0 devices (polarity & phase = 0). We should add support for all 4 modes though, this will let the firmware work with any SPI device (stuff like flash chips that might not use mode 0, the CC3000 I remember used mode 1 IIRC, and other chips that don't use mode 0). Not a blocker but definitely something to add--there's no workaround if you're trying to talk to a device that isn't mode 0.

Does not compile for BOARD=feather_m0_bluefruit_le

$ make CROSS=1 BOARD=feather_m0_bluefruit_le
CC ../py/../extmod/vfs_fat_file.c
../py/../extmod/vfs_fat_file.c:257:13: error: 'MP_QSTR_FileIO' undeclared here (not in a function)
     .name = MP_QSTR_FileIO,
             ^
../py/mkrules.mk:47: recipe for target 'build-feather_m0_bluefruit_le/py/../extmod/vfs_fat_file.o' failed
make: *** [build-feather_m0_bluefruit_le/py/../extmod/vfs_fat_file.o] Error 1

Support disable of debug output for atmel-samd

We should support disabling any debug output, like in the esp port. The os.debug(None) call in the esp port accomplishes this task--let's see how it's implemented and do it for samd21 too.

blinly example not working

Hello,
I pulled the whole project, rebuilt the image and flashed a feather_m0_basic (as of Nov 24th).
Then I tried the blinky example as in http://tannewt-micropython.readthedocs.io/en/microcontroller/shared-bindings/nativeio/__init__.html
And I get an error : OSError: Cannot set value when direction is input

I have to add a led.switch_to_output() before led.value = True in order to make it work.

Since we have to set the direction (output or input), would it be easier to have the same approach as you made with AnalogIn and AnalogOut ?

Externall flash

Hi, just question .... Where is externall flash connected and which type 25 ... 45 ...? Thanks

atmel-samd: Can't save to drive from Mac's built in text editor

Trying to save a main.py on the board's mass storage drive I get an error from the built in text editor that the drive can't be found or the file can't be saved:

PT & Pedro have noticed this too. Perhaps something is up with the drive and how text edit expects the filesystem, etc. to work. Needs a bit more investigation.

Add new USB PID for Feather M0 with CDC + MSC

Right now the feather M0 bluefruit uses the USB PID 0x000b. This is the same as the bootloader PID though and can cause some confusion. Talking to Limor we really want a new PID for this since it's a new 'class' of device with CDC + MSC (vs. just CDC alone that would be PID 0x800b).

Check AnalogIn and AnalogOut to make sure they are all 16 bit

The DAC object allows passing to write a value that's greater than the DAC supports, like 1024, 9999, etc. We should catch this and fail with an out of bounds error. Example:

import machine
dac = machine.DAC()
dac.write(9999)

Interestingly a write of 9999 outputs a voltage around 2.5v when the reference is 3.3v. Values within the 10-bit range (0-1023) have the expected out and are all good, so this is a minor issue.

need a spi flash formatter

hi hi! need a spi flash formatter to start over with a clean file system in case something goes really wrong (testing on macs with autosaving on for text edit for example!)

UART module not implemented yet

UART module is missing.

build broken for feather_m0_basic

Hello,
Build works for default arduino_zero board, but it doest not work anymore for feather_m0_basic

In file included from access_vfs.h:33:0,
from access_vfs.c:29:
asf/common/services/storage/ctrl_access/ctrl_access.h:142:25: fatal error: rom_fs.h: No such file or directory
#include LUN_0_INCLUDE
^
compilation terminated.
../py/mkrules.mk:47: recipe for target 'build-feather_m0_basic/access_vfs.o' failed

I tried to get arround with a symbolic link between access_vfs.h and rom_fs.h but I get more error messages.

(This seems linked to PR 31 #31)

Add built-in neopixel library

So that they can't delete it off the file system.

Characters dropped with picocom

@turbinenreiter reported troubles with the USB REPL when using picocom on Ubuntu.

Some GPIO not accessible

Hi, some special ZERO GPIO are not accessible.

etc

• | 25 | | PB03 | RX
• | 26 | | PA27 | TX
• | 27 | | PA28 | USB_HOST_ENABLE
• | 42 | AREF | PA03 |
• | 30 | | PB22 | EDBG_UART TX
• | 31 | | PB23 | EDBG_UART RX
• | 32 | | PA22 | EDBG_SDA
• | 33 | | PA23 | EDBG_SCL

Add module to enable/disable autoreset on write

That way people can turn it off in boot.py.

import errors on feather_m0_basic

Hello,
With release v1.8.5-20161020, on feather_m0_basic, commands like import os or import time are running.
But with latest build, it does not work.
I guess it is linked to uos and utime aliasing. But this breaks other modules like ssd1306
https://github.com/adafruit/micropython-adafruit-ssd1306

NeoPixel module enhancements

Right now the neopixel modules supports GRB order 400khz and 800khz pixel strips. We should update the module to support a wider range of pixel types:

• RGB and other arbitrary byte orders
• RGBW strips

This can probably all be done in the Python module as the low level pixel write function just takes an array of bytes to send out to the pixels (so it can change from 3-tuples to 4-tuples of color info for RGBW easily).

Implement changing PWM frequency

Right now the PWM objects just let you change duty cycle with the duty function (0-255, 8 bit values). However it would be handy to also support changing the frequency with the freq function which takes in a frequency in hertz for the PWM signal to use. This is similar to the behavior in the ESP8266 port (IIRC there is a limitation that the frequency is global across all PWM output, so it's not the end of the world if we need a similar limitation vs. trying to have a mess of timers for each PWM output).

mac OS displays free space as MB and set creation time to more appropriate date

on a mac (os 10.11.6) metro express will show up with 48KB, 39.3 MB free. also, the time volume (partition create time/date) is "Wednesday, December 31, 1969 at 7:00 PM" ... we could pick a more appropriate date.

running - 1.8.5-20161020 on 2016-10-20 Adafruit Feather M0 Basic with samd21g18

image attached.

atmel-samd: Tight loops without sleep will stop mass storage from responding

Right now mass storage processing is only done in sleep calls which means if you have a loop without any kind of sleep you'll starve mass storage and the drive will disappear. We should move this logic to a VM idle/processing macro that will get called periodically during any python code execution. This will help prevent the drive from disappearing and mass storage handling from being starved of CPU time.

Analog input reading for Feather M0 pins A1 and A2 always return max value 4095

Trying to read analog inputs A1 and A2 on a Feather M0 always returns the max value of 4095 regardless of the voltage on the pin. For example:

import machine
adc = machine.ADC(machine.Pin("A1"))
adc.read()

Returns 4095 even if you check with a multimeter the voltage going to the pin is below 3.3v.

This seems to happen only for analog inputs A1 and A2. ADC pins A0, A3, A4, A5 work great and return expected values proportional to the voltage on their pins.

Repro steps:

• Flash latest atmel-samd MicroPython firmware on Feather M0 proto board (firmware built with BOARD=feather_m0_bluefruit_le)
• Add potentiometer used as a variable resistor for checking analog inputs (3.3 volts to one end, ground to other end, middle pin/wiper to ADC input A1 or A2). Any variable voltage source could work though, just something to send some voltage to the ADC.
• Try reading the ADC value and fiddling the knob to move between different voltages:

import machine
adc = machine.ADC(machine.Pin("A1"))
adc.read()

• Notice only 4095 is returned (even when connected to ground).

Switch ticks to TC5 and combine it with the autoreset timer.

SysTick is used by the ASF delay routines. I tried the alternate cycle counter implementation but it breaks USB.

https://github.com/adafruit/micropython/blob/master/atmel-samd/asf/common2/services/delay/sam0/systick_counter.h#L72

Support named SPI pins on Arduino Zero

Not a high priority but the Arduino Zero board config doesn't have SCK, MOSI, MISO pins like the feather board. Although not as common and easy to use it might be nice to support these as digital IO / named pins to be consistent. This might also mean SPI doesn't currently work on the Zero board (untested).