suspect-devices/circuitpython/extmod/machine_spi.c, branch 5.0.0-beta.3

protocols: Allow them to be (optionally) type-safe

2019-12-04T15:29:57+00:00

Protocols are nice, but there is no way for C code to verify whether a type's "protocol" structure actually implements some particular protocol. As a result, you can pass an object that implements the "vfs" protocol to one that expects the "stream" protocol, and the opposite of awesomeness ensues. This patch adds an OPTIONAL (but enabled by default) protocol identifier as the first member of any protocol structure. This identifier is simply a unique QSTR chosen by the protocol designer and used by each protocol implementer. When checking for protocol support, instead of just checking whether the object's type has a non-NULL protocol field, use `mp_proto_get` which implements the protocol check when possible. The existing protocols are now named: protocol_framebuf protocol_i2c protocol_pin protocol_stream protocol_spi protocol_vfs (most of these are unused in CP and are just inherited from MP; vfs and stream are definitely used though) I did not find any crashing examples, but here's one to give a flavor of what is improved, using `micropython_coverage`. Before the change, the vfs "ioctl" protocol is invoked, and the result is not intelligible as json (but it could have resulted in a hard fault, potentially): >>> import uos, ujson >>> u = uos.VfsPosix('/tmp') >>> ujson.load(u) Traceback (most recent call last): File "", line 1, in ValueError: syntax error in JSON After the change, the vfs object is correctly detected as not supporting the stream protocol: >>> ujson.load(p) Traceback (most recent call last): File "", line 1, in OSError: stream operation not supported

Fix unix build

2019-01-18T20:52:27+00:00

Fix esp and samd

2018-08-17T00:41:35+00:00

drivers/bus: Pull out software SPI implementation to dedicated driver.

2018-03-09T13:59:43+00:00

This patch takes the software SPI implementation from extmod/machine_spi.c and moves it to a dedicated file in drivers/bus/softspi.c. This allows the SPI driver to be used independently of the uPy runtime, making it a more general component.

extmod/machine_spi: Make SPI protocol structure public.

2018-03-02T12:55:08+00:00

So it can be referenced directly without the need for the uPy object.

extmod/machine_spi: Remove EVENT_POLL_HOOK from soft-SPI transfer func.

2017-02-06T03:38:33+00:00

SPI needs to be fast, and calling the EVENT_POLL_HOOK every byte makes it unusable for ports that need to do non-trivial work in the EVENT_POLL_HOOK call. And individual SPI transfers should be short enough in time that EVENT_POLL_HOOK doesn't need to be called. If something like this proves to be needed in practice then we will need to introduce separate event hook macros, one for "slow" loops (eg select/poll) and one for "fast" loops (eg software I2C, SPI).

extmod/machine_spi: Provide reusable software SPI class.

2016-12-08T02:47:01+00:00

So long as a port defines relevant mp_hal_pin_xxx functions (and delay) it can make use of this software SPI class without the need for additional code.

extmod/machine_spi: Add optional support for fast software SPI.

2016-10-04T02:46:40+00:00

If a port defines MICROPY_PY_MACHINE_SPI_MIN_DELAY then it can use a faster software SPI loop that does not make calls to the delay_us function.

extmod/machine_spi: Use delay_half, not baudrate, for internal timing.

2016-10-04T02:43:02+00:00

The delay_half parameter must be specified by the port to set up the timing of the software SPI. This allows the port to adjust the timing value to better suit its timing characteristics, as well as provide a more accurate printing of the baudrate.

extmod/machine_spi: Factor out software SPI code from esp8266 to extmod.

2016-10-03T05:43:44+00:00