This one sets the flash image length properly for the teensy loader, such
that the file system is not erased. It was already set in commit
8e54225140 but got lost when the MIMXRT1176
board was added.
Signed-off-by: robert-hh <robert@hammelrath.com>
Three bugs have been fixed in this commit:
1. When the duty was set with duty_u16(), changing the freq with pwm.freq()
would not keep relative duty rate, but the absolute pulse duration.
2. Fix another inconsistency when displaying the PWM pin's properties of a
QTMR channel.
3. Improve the error checks for the second channel being a PWM pin and pin
pairs to be a FLEXPWM A/B pair.
Signed-off-by: robert-hh <robert@hammelrath.com>
These have by default FAT support. The SAMD21 build does not support FAT.
The nrf port also implements os.sync(), but has it's own copy of moduos.c.
Code size increases seen: 40 to 56 bytes.
Signed-off-by: robert-hh <robert@hammelrath.com>
It was treated as an error before. The error surfaced when using the
NINAW10 drivers for WiFi support. Even if this is a bad behavior of the
NINA driver, machine_spi can be forgiving in that situation.
Separate low level flash access from mimxrt flash driver object. Allows
better abstraction from hardware for testing and reuse in other areas (e.g.
bootloader).
Signed-off-by: Philipp Ebensberger <philipp.ebensberger@3bricks-software.de>
All ports that enable MICROPY_PY_MACHINE_PWM now enable these two
sub-options, so remove these sub-options altogether to force consistency in
new ports that implement machine.PWM.
Signed-off-by: Damien George <damien@micropython.org>
And also fix/improve the following:
- Simplify the duty handling a little bit.
- Allow duty_u16(65536), which sets the output high.
- Rename machine_pwm_start() to mp_machine_pwm_start(), in preparation for
a possible start/stop method pair.
Based on extmod/utime_mphal.c, with:
- a globals dict added
- time.localtime wrapper added
- time.time wrapper added
- time.time_ns function added
New configuration options are added for this module:
- MICROPY_PY_UTIME (enabled at basic features level)
- MICROPY_PY_UTIME_GMTIME_LOCALTIME_MKTIME
- MICROPY_PY_UTIME_TIME_TIME_NS
Signed-off-by: Damien George <damien@micropython.org>
If a board defines a custom bootloader entry function it will be called
first, if not and the ROM API supports RUN bootloader API, then
`machine.bootloader()` will jump to the ROM serial downloader in USB mode.
This commit allows boards to disable Ethernet and keep the networking stack
enabled, to use an alternate networking interface, such as WiFi.
Note that the `network` and `socket` modules are now enabled by default for
a board.
This commit is necessary to make MicroPython work on this eval kit out of
the box, as the eval kit ships with the HyperFlash physically disconnected
from the bus (refer to the schematics or the user guide) and the QSPI
connected instead, but the fuses/board/pins are configured to boot from
internal flash (on FlexSPI2).
Note that enabling the HyperFlash is not trivial, as it requires soldering
and desoldering of many small footprint resistors and changing fuses.
Helps prevent the filesystem from getting formatted by mistake, among other
things. For example, on a Pico board, entering Ctrl+D and Ctrl+C fast many
times will eventually wipe the filesystem (without warning or notice).
Further rationale: Ctrl+C is used a lot by automation scripts (eg mpremote)
and UI's (eg Mu, Thonny) to get the board into a known state. If the board
is not responding for a short time then it's not possible to know if it's
just a slow start up (eg in _boot.py), or an infinite loop in the main
application. The former should not be interrupted, but the latter should.
The only way to distinguish these two cases would be to wait "long enough",
and if there's nothing on the serial after "long enough" then assume it's
running the application and Ctrl+C should break out of it. But defining
"long enough" is impossible for all the different boards and their possible
behaviour. The solution in this commit is to make it so that frozen
start-up code cannot be interrupted by Ctrl+C. That code then effectively
acts like normal C start-up code, which also cannot be interrupted.
Note: on the stm32 port this was never seen as an issue because all
start-up code is in C. But now other ports start to put more things in
_boot.py and so this problem crops up.
Signed-off-by: David Grayson <davidegrayson@gmail.com>
The dispatch active flag is only set once and never reset, so it will
always call the dispatch handler (once enabled), and it's not really
needed because it doesn't make things more efficient.
Also remove unused included headers.
This is a best-effort implementation of write polling. It's difficult to
do correctly because if there are multiple output streams (eg UART and USB
CDC) then some may not be writeable while others are. A full solution
should also have a return value from mp_hal_stdout_tx_strn(), returning the
number of bytes written to the stream(s). That's also hard to define.
The renesas-ra and stm32 ports already implement a similar best-effort
mechanism for write polling.
Fixes issue #11026.
Signed-off-by: Damien George <damien@micropython.org>
This provides a standard interface to setting the global networking config
for all interfaces and interface types.
For ports that already use either a static hostname (mimxrt, rp2) they will
now use the configured value. The default is configured by the port
(or optionally the board).
For interfaces that previously supported .config(hostname), this is still
supported but now implemented using the global network.hostname.
Similarly, pyb.country and rp2.country are now deprecated, but the methods
still exist (and forward to network.hostname).
Because ESP32/ESP8266 do not use extmod/modnetwork.c they are not affected
by this commit.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
This allows:
$ make BOARD_DIR=path/to/board
to infer BOARD=board, rather than the previous behavior that required
additionally setting BOARD explicitly.
Also makes the same change for VARIANT_DIR -> VARIANT on Unix.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Signed-off-by: Damien George <damien@micropython.org>
Before, both uwTick and mp_hal_ticks_ms() were used as clock source. That
assumes, that these two are synchronous and start with the same value,
which may be not the case for all ports. If the lag between uwTick and
mp_hal_ticks_ms() is larger than the timer interval, the timer would either
rush up until the times are synchronous, or not start until uwTick wraps
over.
As suggested by @dpgeorge, MICROPY_SOFT_TIMER_TICKS_MS is now used in
softtimer.c, which has to be defined in a port's mpconfigport.h with
the variable that holds the SysTick counter.
Note that it's not possible to switch everything in softtimer.c to use
mp_hal_ticks_ms() because the logic in SysTick_Handler that schedules
soft_timer_handler() uses (eg on mimxrt) the uwTick variable directly
(named systick_ms there), and mp_hal_ticks_ms() uses a different source
timer. Thus it is made fully configurable.
This will ensure that any board with networking support gets:
- webrepl
- mip
- urequests
- ntptime
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
This drops the `.cpu` directive from the ARM gchelper_*.s files. Having
this directive breaks the linker when targeting older CPUs (e.g. `-mthumb
-mthumb-interwork` for `-mcpu=arm7tdmi`). The actual target CPU should be
determined by the compiler options.
The exact CPU doesn't actually matter, but rather the supported assembly
instruction set. So the files are renamed to *_thumb1.s and *thumb2.s to
indicate the instruction set support instead of the CPU support.
Signed-off-by: David Lechner <david@pybricks.com>
The RT1176 has two cores, but the actual firmware supports only the CM7.
There are currently no good plans on how to use the CM4.
The actual MIMXRT1170_EVK board is on par with the existing MIMXRT boards,
with the following extensions:
- Use 64 MB RAM for the heap.
- Support both LAN interfaces as LAN(0) and LAN(1), with LAN(1)
being the 1GB interface.
The dual LAN port interface can eventually be adapted as well for the
RT1062 MCU.
This work was done in collaboration with @alphaFred.
If USB CDC is connected and the board sends data, but the host does not
receive the data, the device locks up. This is fixed in this commit by
having a timeout of 500ms, after which time the transmission is skipped.
