suspect-devices/circuitpython - CircuitPython - a Python implementation for teaching coding with microcontrollers

Age	Commit message (Collapse)	Author
2021-03-15	run code formatting script	microDev

2020-06-26	shared-bindings: Factor out validate_list_is_free_pins	Jeff Epler
	This will ultimately be used by SDIO, where a variable length list of data lines is called for.
2020-04-14	Add Protomatter and FramebufferDisplay	Jeff Epler

2020-03-05	rename routines to be clearer; fix wiznet arg types	Dan Halbert

2020-02-28	new pin validation routines; don't use mp_const_none if NULL will do	Dan Halbert

2019-11-15	revert error	Hierophect

2019-11-15	move neopixel_in_use flag to shared-bindings	Hierophect

2019-11-15	Add never_reset and reset to pin common hal, adjust files	Hierophect

2017-08-25	Initial merge of micropython v1.9.2 into circuitpython 2.0.0 (in ↵	Dan Halbert
	development) master. cpx build compiles and loads and works in repl; test suite not run yet esp8266 not tested yet
2017-04-12	atmel-samd: Rework status LED implementation	Scott Shawcroft
	* Track status pin use by user code separately so it can take over the pins and then give them back. * Switch to hardware SPI for APA102 on Gemma and Trinket. * Merge microcontroller/types.h into microcontroller/Pin.h to better match approach going forwards.
2016-12-07	atmel-samd & esp8266: Make sure pins are not already in use.	Scott Shawcroft
	This prevents corrupting previous functional objects by stealing their pins out from under them. It prevents this by ensuring that pins are in default state before claiming them. It also verifies pins are released correctly and reset on soft reset. Fixes #4, instantiating a second class will fail. Fixes #29, pins are now reset too.
2016-11-29	shared-bindings: Ensure pin objects are actually pins.	Scott Shawcroft
	Fixes #12
2016-11-21	This introduces an alternative hardware API called nativeio structured ↵	Scott Shawcroft
	around different functions that are typically accelerated by native hardware. Its not meant to reflect the structure of the hardware. Docs are here: http://tannewt-micropython.readthedocs.io/en/microcontroller/ It differs from upstream's machine in the following ways: * Python API is identical across ports due to code structure. (Lives in shared-bindings) * Focuses on abstracting common functionality (AnalogIn) and not representing structure (ADC). * Documentation lives with code making it easy to ensure they match. * Pin is split into references (board.D13 and microcontroller.pin.PA17) and functionality (DigitalInOut). * All nativeio classes claim underlying hardware resources when inited on construction, support Context Managers (aka with statements) and have deinit methods which release the claimed hardware. * All constructors take pin references rather than peripheral ids. Its up to the implementation to find hardware or throw and exception.