@kwagyeman @iabdalkader this implements a fast mp_hal_ticks_ms() on mimxrt. But see the above description for downsides (it stops counting if IRQs are disabled) and alternatives.

@robert-hh you may be interested in this change. Maybe you have a better way to get a fast ms counter.

Code size report:

Reference:  extmod/moductypes: Be more defensive with uctypes_struct_agg_size args. [8a56be6]
Comparison: mimxrt/mphalport: Run events at least once in mp_hal_delay_ms. [merge of ab6c2a5]
  mpy-cross:    +0 +0.000% 
   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
      esp32:    +0 +0.000% ESP32_GENERIC
     mimxrt:   +24 +0.006% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

Cleaning out unused stuff is always good. I'm a little bit skeptic about disable IRQ stopping the ms tick. IRQ is disabled often during flash write/erase, e.g. when files are written. I cannot estimate how serious the problem is for using ticks_ms(). It seems better to keep the timer based ticks and provide a separate function.

Edit: No all GPT devices are used. So maybe one could set up a GPT counting at 1kHz or a power of 2. Using the low frequency reference clock, 1kHz is possible. When the 24MHz crystal is used, a 8kHz timer can be set up, The GPT prescaler has a range of 1-4096.

For our use cases, it's expected that the value wouldn't increment when there are no IRQs. STM32 systick behavior sets the standard, which does not increment when interrupts are disabled.

Still mp_hal_ticks_ms() as the source for time.ticks_ms() should have no dropouts. So your use case would more be covered by a separate function, e.g. mp_hal_ticks_ms_fast().

So your use case would more be covered by a separate function, e.g. mp_hal_ticks_ms_fast().

Yes, I agree, I think it would be best to leave the existing implementation of mp_hal_ticks_ms() as-is (using GPT), and hence retain the current behaviour of time.sleep() and time.sleep_ms() (which are based on mp_hal_ticks_ms().

Then we could provide mp_hal_ticks_ms_fast() as a uniform API across ports. (I still think my original proposal #19076 (comment) of having the timebase unspecified is better, eg on mimxrt it allows using the raw GPT count value as the timebase, which is fast, accurate, and keeps going even with IRQs disabled).

I've updated this PR to go back to using GPT for mp_hal_ticks_ms(), and added a new function mp_hal_ticks_ms_fast() which gives access to the low-level SysTick counter.

Based on discussion I've now removed the new mp_hal_ticks_ms_fast() function. So this PR is mostly a clean up PR and should be good to merge.

Looks fine. Tested with three representative candidates: MIMXRT1010 (Makerdiary), MIMXRT1015 (MIMXRT1015-EVK), MIMXRT1062 (Teensy 4.1) and MIXRT1176 (MIMXRT1070-EVK) and the test suite packages micropython and extmod. MIMXRFT1010 fails some test running out of heap space.

On a side note: Looking why the MIMX1010 failed a socket test I wondered, why it was not skipped. Reason: socket and network modules are enabled on MIMXRT1010 and MIMXRT1015, even if they have no network support. I cannot recall if that was for a reason or just an oversight. Disabling it saves ~3k flash. I can make a separate PR for that, or revive the habit of maintenance PRs collecting small uncritical changes.

Edit: Another aspect of test: I noticed that with MIMXRT all vfs_lfs tests are skipped, just because the MIMXRT port does not support VFS_LFS1. Maybe the tests could be adapted to support either one.

MIMXRFT1010 fails some test running out of heap space

That might be improved by #19074.

Looking why the MIMX1010 failed a socket test

I think that's fixed by #19055.

socket and network modules are enabled on MIMXRT1010 and MIMXRT1015, even if they have no network support.

That's also the case on stm32. The network module there doesn't do much, but I guess it's mainly for consistency and so it's easy to enable the Wiznet driver. So I think we can leave that enabled on all mimxrt boards, unless they are running out of flash.

Another aspect of test: I noticed that with MIMXRT all vfs_lfs tests are skipped, just because the MIMXRT port does not support VFS_LFS1. Maybe the tests could be adapted to support either one.

Yes, that's possible, to support either one, and would allow lfs to be tested more widely on bare-metal. Maybe those tests need to be rewritten to use unittest first, and then supporting both lfs1 and lfs2 becomes easier.