suspect-devices/circuitpython/lib/libc, branch 4.0.0-alpha.3 CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=4.0.0-alpha.3 2017-08-26T02:17:07+00:00 Initial merge of micropython v1.9.2 into circuitpython 2.0.0 (in development) master. 2017-08-26T02:17:07+00:00 Dan Halbert halbert@halwitz.org 2017-08-26T02:17:07+00:00 urn:sha1:ef61b5ecb59e9b4e37e3e3c023c62d583c23eb16 cpx build compiles and loads and works in repl; test suite not run yet esp8266 not tested yet all: Use the name MicroPython consistently in comments 2017-07-31T08:35:40+00:00 Alexander Steffen devel.20.webmeister@spamgourmet.com 2017-06-30T07:22:17+00:00 urn:sha1:55f33240f3d7051d4213629e92437a36f1fac50e There were several different spellings of MicroPython present in comments, when there should be only one. 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. lib/libc/string0: Remove better-than-standard strncpy() implementation. 2016-05-02T15:53:21+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2016-05-02T15:53:21+00:00 urn:sha1:c6923f52f09f03468e6720c7ba8fbdef065eec58 ANSI C doesn't require that strncpy() produced null-terminated string, so it's basicly useless for string manipulation. lib/libc/string0: Add strncpy() implementation. 2016-05-02T15:38:19+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2016-05-02T15:38:19+00:00 urn:sha1:bd9de5ec9020384334b63582c7640372a9a2d022 lib/libc/string0: Use uintptr_t instead of uint32_t. 2015-12-31T14:11:18+00:00 Damien George damien.p.george@gmail.com 2015-12-31T14:11:18+00:00 urn:sha1:64ececb72fe8ccf769f4751cbd591fde650bc83a This makes the code portable to non-32-bit architectures. lib/libc: Add memchr. We already have strchr, but memchr is useful too. 2015-04-28T14:48:20+00:00 Daniel Campora daniel@wipy.io 2015-04-28T13:44:14+00:00 urn:sha1:abea1c38a94183999c07c848f0b48ca55b42b653 lib/libc/string0.c: Remove include of std.h, replace with string.h. 2015-04-18T13:27:55+00:00 Damien George damien.p.george@gmail.com 2015-04-18T13:27:55+00:00 urn:sha1:f53a8e712f6b38f15be81cb692c03c1afacce7ae Much more portable this way. string0.c: Move from stmhal/ to lib/. 2015-04-05T18:57:55+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2015-04-05T18:44:20+00:00 urn:sha1:3a84c8b58d7c87785bf1ae48eb41c91ecde9fc1c