David Grayson c046b23ea2 shared/runtime/pyexec: Don't allow Ctrl+C to interrupt frozen boot code.
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>
2023-04-05 10:38:50 +10:00
..
2021-05-26 00:12:42 +10:00
2021-05-26 00:12:42 +10:00
2023-03-07 15:09:07 +11:00
2023-04-05 10:16:22 +10:00

Port of MicroPython to NXP iMX RT 10xx

Currently supports Teensy 4.0, Teensy 4.1, and the MIMXRT1010_EVK, MIMXRT1020_EVK, MIMXRT1050_EVK, MIMXRT1060_EVK and MIMXRT1064_EVK boards.

Features:

  • REPL over USB VCP
  • machine.ADC
  • machine.I2C
  • machine.LED
  • machine.Pin
  • machine.PWM
  • machine.RTC
  • machine.SDCard
  • machine.SPI
  • machine.Signal
  • machine.SoftI2C
  • machine.SoftSPI
  • machine.Timer
  • machine.UART
  • LFS2 file system at the internal Flash
  • SDCard support (not on MIMXRT1010_EVK)
  • Ethernet (not on Teensy 4.0 and MIMXRT1010_EVK)

Known issues:

TODO:

  • More peripherals (Counter, I2S, CAN, etc)
  • More Python options

Build Instructions

Before building the firmware for a given board the MicroPython cross-compiler must be built; it will be used to pre-compile some of the built-in scripts to bytecode. The cross-compiler is built and run on the host machine, using:

$ make -C mpy-cross

This command should be executed from the root directory of this repository. All other commands below should be executed from the ports/mimxrt/ directory.

An ARM compiler is required for the build, along with the associated binary utilities. The default compiler is arm-none-eabi-gcc, which is available for Arch Linux via the package arm-none-eabi-gcc, for Ubuntu via instructions here, or see here for the main GCC ARM Embedded page. The compiler can be changed using the CROSS_COMPILE variable when invoking make.

In addition newlib is required which is available for Arch Linux via the package arm-none-eabi-newlib, for Ubuntu/Debian install package libnewlib-arm-none-eabi

Next, the board to build must be selected. Any of the board names of the subdirectories in the boards/ directory is a valid board. The board name must be passed as the argument to BOARD= when invoking make.

All boards require certain submodules to be obtained before they can be built. The correct set of submodules can be initialised using (with SEEED_ARCH_MIX as an example of the selected board):

$ make BOARD=SEEED_ARCH_MIX submodules

Then to build the board's firmware run:

$ make BOARD=SEEED_ARCH_MIX

The above command should produce binary images in the build-SEEED_ARCH_MIX/ subdirectory (or the equivalent directory for the board specified).

Flashing

Deploy the firmware following the instructions here https://docs.micropython.org/en/latest/mimxrt/tutorial/intro.html#deploying-the-firmware