summaryrefslogtreecommitdiff
path: root/extmod/machine_signal.c
AgeCommit message (Collapse)Author
2021-03-15run code formatting scriptmicroDev
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
2019-01-18Fix unix buildScott Shawcroft
2017-12-11extmod/machine_signal: Change VLA to use new scoped allocation API.Damien George
2017-07-26extmod/machine_signal: Fix parsing of invert arg when Pin is first arg.Damien George
2017-04-15extmod/machine_signal: Rename "inverted" arg to "invert", it's shorter.Damien George
A shorter name takes less code size, less room in scripts and is faster to type at the REPL. Tests and HW-API examples are updated to reflect the change.
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).
2017-02-08extmod/machine_signal: Implement Signal .on() and .off() methods.Paul Sokolovsky
Each method asserts and deasserts signal respectively. They are equivalent to .value(1) and .value(0) but conceptually simpler (and may help to avoid confusion with inverted signals, where "asserted" state means logical 0 output).
2017-01-29extmod/machine_signal: Implement "signal" abstraction for machine module.Paul Sokolovsky
A signal is like a pin, but ca also be inverted (active low). As such, it abstracts properties of various physical devices, like LEDs, buttons, relays, buzzers, etc. To instantiate a Signal: pin = machine.Pin(...) signal = machine.Signal(pin, inverted=True) signal has the same .value() and __call__() methods as a pin.