suspect-devices/circuitpython/shared-bindings/bitbangio/__init__.c, branch main CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=main 2021-03-15T13:57:36+00:00 run code formatting script 2021-03-15T13:57:36+00:00 microDev 70126934+microDev1@users.noreply.github.com 2021-03-15T13:57:36+00:00 urn:sha1:a52eb88031620a81521b937f2a0651dbac2bb350 wip 2021-03-02T20:16:55+00:00 Dan Halbert halbert@halwitz.org 2021-03-02T20:16:55+00:00 urn:sha1:9939c59caa4e13011e9d1f63079cb4a7942cfcc4 Swap sphinx to autoapi and the inline stubs 2020-05-13T00:28:24+00:00 Scott Shawcroft scott@tannewt.org 2020-05-13T00:15:28+00:00 urn:sha1:4e8de3c554024d3ac89e9ee77b958a6932a64bec Did audiopwmio, bitbangio, and _bleio 2020-05-01T22:23:27+00:00 dherrada dylan.herrada@gmail.com 2020-05-01T22:23:27+00:00 urn:sha1:0e465e63b98c3825298219e2144a145208aaff7f shared-bindings: Update docs to remove with statements from examples but add more detail to the design guide about their use. 2017-06-07T21:39:12+00:00 Scott Shawcroft scott.shawcroft@gmail.com 2017-06-07T21:39:12+00:00 urn:sha1:714521a4c7a6814c365c061bcf967c4c45692e3d Split up nativeio. 2017-04-10T20:32:19+00:00 Scott Shawcroft scott.shawcroft@gmail.com 2017-04-10T20:32:19+00:00 urn:sha1:f28f8ba56809fd56e777eabceae21127f95b89ed This was done to allow greatly granularity when deciding what functionality is built into each board's build. For example, this way pulseio can be omitted to allow for something else such as touchio. Add low-level OneWire support class. 2017-03-25T12:04:49+00:00 Scott Shawcroft scott.shawcroft@gmail.com 2017-03-25T12:04:49+00:00 urn:sha1:ff208d767741104f7d2644a58269d7064d4c1b6a This class focuses on the timing sensitive parts of the protocol. Everything else will be done by Python code. This also establishes that its OK to back a nativeio class with a bitbang implementation when no hardware acceleration exists. When it does, then bitbangio should be used to explicitly bitbang a protocol. Add uheap for debugging the size of objects. Still not perfect though. 2016-11-23T01:32:28+00:00 Scott Shawcroft scott.shawcroft@gmail.com 2016-11-23T01:32:28+00:00 urn:sha1:ea1320bee7fbd0f895e8afe528e4b528489b2c5e This introduces an alternative hardware API called nativeio structured around different functions that are typically accelerated by native hardware. Its not meant to reflect the structure of the hardware. 2016-11-21T22:11:52+00:00 Scott Shawcroft scott@chickadee.tech 2016-11-03T22:50:59+00:00 urn:sha1:ccbb5e84f980e252f7380d96fcc5c417a8a64523 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.