summaryrefslogtreecommitdiff
path: root/extmod/virtpin.h
AgeCommit message (Collapse)Author
2020-07-06Add license to some obvious files.Diego Elio Pettenò
2019-12-04protocols: Allow them to be (optionally) type-safeJeff Epler
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
2017-07-18all: Unify header guard usage.Alexander Steffen
The code conventions suggest using header guards, but do not define how those should look like and instead point to existing files. However, not all existing files follow the same scheme, sometimes omitting header guards altogether, sometimes using non-standard names, making it easy to accidentally pick a "wrong" example. This commit ensures that all header files of the MicroPython project (that were not simply copied from somewhere else) follow the same pattern, that was already present in the majority of files, especially in the py folder. The rules are as follows. Naming convention: * start with the words MICROPY_INCLUDED * contain the full path to the file * replace special characters with _ In addition, there are no empty lines before #ifndef, between #ifndef and one empty line before #endif. #endif is followed by a comment containing the name of the guard macro. py/grammar.h cannot use header guards by design, since it has to be included multiple times in a single C file. Several other files also do not need header guards as they are only used internally and guaranteed to be included only once: * MICROPY_MPHALPORT_H * mpconfigboard.h * mpconfigport.h * mpthreadport.h * pin_defs_*.h * qstrdefs*.h
2017-04-11extmod/machine_signal: Support all Pin's arguments to the constructor.Paul Sokolovsky
This implements the orginal idea is that Signal is a subclass of Pin, and thus can accept all the same argument as Pin, and additionally, "inverted" param. On the practical side, it allows to avoid many enclosed parenses for a typical declararion, e.g. for Zephyr: Signal(Pin(("GPIO_0", 1))). Of course, passing a Pin to Signal constructor is still supported and is the most generic form (e.g. Unix port will only support such form, as it doesn't have "builtin" Pins), what's introduces here is just practical readability optimization. "value" kwarg is treated as applying to a Signal (i.e. accounts for possible inversion).
2016-05-27extmod/virtpin: Initial implementation of open-ended C-level Pin interface.Paul Sokolovsky
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).