djsundog
/
circuitpython
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
circuitpython/extmod/virtpin.c

20 lines
718 B
C
Raw Normal View History

Add license to some obvious files.
2020-06-03 18:40:05 -04:00
// Copyright (c) 2016 Paul Sokolovsky
// SPDX-FileCopyrightText: 2014 MicroPython & CircuitPython contributors (https://github.com/adafruit/circuitpython/graphs/contributors)
//
// SPDX-License-Identifier: MIT
extmod/virtpin: Initial implementation of open-ended C-level Pin interface. Using usual method of virtual method tables. Single virtual method, ioctl, is defined currently for all operations. This universal and extensible vtable-based method is also defined as a default MPHAL GPIO implementation, but a specific port may override it with its own implementation (e.g. close-ended, but very efficient, e.g. avoiding virtual method dispatch).
2016-05-26 17:57:18 -04:00
#include "extmod/virtpin.h"
protocols: Allow them to be (optionally) type-safe 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 "<stdin>", line 1, in <module> 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 "<stdin>", line 1, in <module> OSError: stream operation not supported
2019-12-03 15:50:37 -05:00
#include "py/proto.h"
extmod/virtpin: Initial implementation of open-ended C-level Pin interface. Using usual method of virtual method tables. Single virtual method, ioctl, is defined currently for all operations. This universal and extensible vtable-based method is also defined as a default MPHAL GPIO implementation, but a specific port may override it with its own implementation (e.g. close-ended, but very efficient, e.g. avoiding virtual method dispatch).
2016-05-26 17:57:18 -04:00
int mp_virtual_pin_read(mp_obj_t pin) {
mp_obj_base_t* s = (mp_obj_base_t*)MP_OBJ_TO_PTR(pin);
protocols: Allow them to be (optionally) type-safe 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 "<stdin>", line 1, in <module> 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 "<stdin>", line 1, in <module> OSError: stream operation not supported
2019-12-03 15:50:37 -05:00
const mp_pin_p_t *pin_p = mp_proto_get(MP_QSTR_protocol_pin, s);
extmod/virtpin: Initial implementation of open-ended C-level Pin interface. Using usual method of virtual method tables. Single virtual method, ioctl, is defined currently for all operations. This universal and extensible vtable-based method is also defined as a default MPHAL GPIO implementation, but a specific port may override it with its own implementation (e.g. close-ended, but very efficient, e.g. avoiding virtual method dispatch).
2016-05-26 17:57:18 -04:00
return pin_p->ioctl(pin, MP_PIN_READ, 0, NULL);
}
void mp_virtual_pin_write(mp_obj_t pin, int value) {
mp_obj_base_t* s = (mp_obj_base_t*)MP_OBJ_TO_PTR(pin);
protocols: Allow them to be (optionally) type-safe 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 "<stdin>", line 1, in <module> 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 "<stdin>", line 1, in <module> OSError: stream operation not supported
2019-12-03 15:50:37 -05:00
const mp_pin_p_t *pin_p = mp_proto_get(MP_QSTR_protocol_pin, s);
extmod/virtpin: Initial implementation of open-ended C-level Pin interface. Using usual method of virtual method tables. Single virtual method, ioctl, is defined currently for all operations. This universal and extensible vtable-based method is also defined as a default MPHAL GPIO implementation, but a specific port may override it with its own implementation (e.g. close-ended, but very efficient, e.g. avoiding virtual method dispatch).
2016-05-26 17:57:18 -04:00
pin_p->ioctl(pin, MP_PIN_WRITE, value, NULL);
}