Commit Graph

4 Commits

Author SHA1 Message Date
Paul Sokolovsky 0161939ed1 zephyr/machine_pin: Use native Zephyr types for Zephyr API calls.
In 1.8, Zephyr made a controversial change of dumping C99 stdint types
and switching to its own types.
2017-06-10 19:40:31 +03:00
Paul Sokolovsky bcf31a3908 esp8266, stmhal, zephyr: Rename machine.Pin high/low methods to on/off.
For consistent Pin/Signal class hierarchy. With it, Signal is a proper
(while still ducktyped) subclass of a Pin, and any (direct) usage of Pin
can be replace with Signal.

As stmhal's class is reused both as machine.Pin and legacy pyb.Pin,
high/low methods actually retained there.
2017-05-21 17:44:58 +03:00
Paul Sokolovsky 0a88b44248 zephyr/machine_pin: Implement pin protocol for machine.Signal support. 2017-04-08 14:27:36 +03:00
Daniel Thompson 67b6d9d499 zephyr: Initial implementation of machine.Pin.
The integration with Zephyr is fairly clean but as MicroPython Hardware API
requires pin ID to be a single value, but Zephyr operates GPIO in terms of
ports and pins, not just pins, a "hierarchical" ID is required, using tuple
of (port, pin). Port is a string, effectively a device name of a GPIO port,
per Zephyr conventions these are "GPIO_0", "GPIO_1", etc.; pin is integer
number of pin with the port (supposed to be in range 0-31).

Example of pin initialization:

pin = Pin(("GPIO_1", 21), Pin.OUT)

(an LED on FRDM-K64F's Port B, Pin 21).

There is support for in/out pins and pull up/pull down but currently
there is no interrupt support.

Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@linaro.org>
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
2016-10-27 00:47:26 +03:00