| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Previously they used historical "pyb" affix causing confusion and
inconsistency (there's no "pyb" module in modern ports; but people
took esp8266 port as an example, and "pyb" naming kept proliferating,
while other people complained that source structure is not clear).
|
|
|
|
|
| |
Utility functions for keyboard interrupt handling, to be reused across
(baremetal) ports.
|
| |
|
|
|
|
|
| |
Exposed as esp.dht_readinto. Probably should go somewhere less
port-specific.
|
|
|
|
|
| |
mp_hal_pin_config_od is renamed mp_hal_pin_open_drain, and mp_hal_pin_low
is mp_hal_pin_od_low.
|
| |
|
| |
|
|
|
|
| |
Returning free number of various WiFi driver packet buffers.
|
| |
|
|
|
|
| |
Now I2C works with GPIO16 as the SCL or SDA pin.
|
|
|
|
|
|
|
|
|
| |
Most pin I/O can be done just knowing the pin number as a simple
integer, and it's more efficient this way (code size, speed) because it
doesn't require a memory lookup to get the pin id from the pin object.
If the full pin object is needed then it can be easily looked up in the
pin table.
|
| |
|
|
|
|
|
| |
It doesn't do anything and is not needed. ets_loop_iter/ets_event_poll
now take care of feeding the WDT.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The idea is following: underlying interrupt-driven or push-style data source
signals that more data is available for dupterm processing via call to
mp_hal_signal_dupterm_input(). This triggers a task which pumps data between
actual dupterm object (which may perform additional processing on data from
low-level data source) and input ring buffer.
|
|
|
|
|
|
|
|
| |
But now it's generic ring buffer implemented via ringbuf.h, and is intended
for any type of input, including dupterm's, not just UART. The general
process work like this: an interrupt-driven input source puts data into
input_buf, and then signals new data available via call to
mp_hal_signal_input().
|
|
|
|
|
|
|
| |
That is: aps = if0.scan()
TODO: make sure that returned list has tuple with values in "standard"
order (whatever that standard is).
|
|
|
|
|
|
|
|
|
| |
Helpful when debugging dupterm support (because otherwise all output is
spooled to dupterm too).
To use:
mp_printf(&mp_debug_print, "...");
|
|
|
|
| |
ets_event_poll() polls both system events and uPy pending exception.
|
| |
|
|
|
|
|
|
|
|
|
| |
Initialize RTC period coefficients, etc. if RTC RAM doesn't contain valid
values. time.time() then will return number of seconds since power-on, unless
set to different timebase.
This reuses MEM_MAGIC for the purpose beyond its initial purpose (but the whole
modpybrtc.c need to be eventually reworked completely anyway).
|
| |
|
|
|
|
|
|
| |
py/mphal.h contains declarations for generic mp_hal_XXX functions, such
as stdio and delay/ticks, which ports should provide definitions for. A
port will also provide mphalport.h with further HAL declarations.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pasting more or less sizable text into ESP8266 REPL leads to random chars
missing in the received input. Apparent cause is that using RTOS messages
to pass individual chars one by one is to slow and leads to UART FIFO
overflow. So, instead of passing chars one by one, use RTOS msg to signal
that input data is available in FIFO, and then let task handler to read
data directly from FIFO.
With this change, lost chars problem is gone, but the pasted text is
truncated after some position. At least 500 chars can be pasted reliably
(at 115200 baud), but 1K never pastes completely.
|
|
|
|
|
| |
Now all ports can use pybstdio.c to provide sys.stdin/stdout/stderr, so
long as they implement mp_hal_stdin_* and mp_hal_stdout_* functions.
|
|
|
|
|
|
| |
This enables proper interfacing with underlying OS - MicroPython doesn't
run the main loop, OS does, MicroPython just gets called when some event
takes place.
|
|
|