Timers with us

[Aris]

Hello,

It seems there is a problem using timers with intervals under 1ms. Taking an example of a pin toggle using interrupts every 0.5ms here is the output based on a logic analyzer:

code used:

from machine import Pin
from machine import Timer

test_pin = Pin('P11', mode=Pin.OUT)
test_pin(True)

class Clock:

    def __init__(self):
        self.loops = 0
        self.__alarm = Timer.Alarm(self._seconds_handler, us=500, periodic=True)

    def _seconds_handler(self, alarm):
        self.loops += 1
        test_pin.toggle()
        
        if self.loops == 20:
            alarm.cancel()

clock = Clock()

this happened also with

self.__alarm = Timer.Alarm(self._seconds_handler, s=0.0005, periodic=True)

PWM seems to working fine for the same Pin / Frequency. If a change the period to 1ms and above everything is working fine.

[Stevo52]

@robert-hh Thanks for that. I really like the look of that new board! Hope it is released to market very soon.

[robert-hh]

@stevo52 Some properties of the new board are here: https://forum.micropython.org/viewtopic.php?f=19&t=4957
Besides the "linear" improvement over Pyboard v1.x there is WiFi and BT included, using a separate coprocessor.

[rcolistete]

@stevo52 Try "contact@micropython.org" to ask about 'Pyboard D' availability. I'm sure it will be released on February, but no specific day.
By the way, Pyboard Lite 1.0 is better for low power usage, see the MicroPython pyboard feature table.

[Stevo52]

@rcolistete Thanks for that. Some Pyboards V1,1 are available from stockists here in Australia, so I can get my hands on one. However, I would like to know what the spec's/improvement are with the new version before committing to a purchase. Most of the time new versions bring better, bigger features :-). Where can I find information on the new version?

[rcolistete]

Pyboard Lite 1.0 (with or without accelerometer) is on stock :
https://store.micropython.org/category/pyboards

[robert-hh]

@stevo52 Lack of documentation is surely something that is hindering. Pycom's documentation improved over time, but it still could be better. The documentation form micropython.org used to be better, but fell a little bit behind. The PyBoard itsef, ot let#s say, the Port for the STM32F4xx family is pretty mature. That's the one MicroPython was ported to in the first place. The the forum at microypthon.org is also pretty active. But unlike Pycom, micropython.org is not driven by a commercial company. It is a few people around Damien George and a lot of first grade contributers, especially Paul, then Dave, McSurly, .. But the are pretty realistic in what they promise.

[Stevo52]

@robert-hh Not sure I can wait for that new Pyboard.. is there any info available on it and what guarantee is there that it will deliver on time and won't also be plagued with perhaps overly optimistic capability or performance claims, poor documentation, errors in command descriptions, lack of corrections/updates, no action on some issues etc.

From the forum there seem to be a whole lot of issues with the Pycom products that are hindering a number of people doing development work. I'm a little disappointed really as when selecting a product, for any purpose, we rely very much on product documentation to make informed choices, so that aspect of the Pycom product range lets it down.

[robert-hh]

@stevo52 If you want to stay with MicroPython, try the PyBoard. Itis currently out of stock, but there is a new version expected for February. It is based on a STM controller with a classical memory architecture. ISR times are in the range of <5µs. The new board will have WiFi, if you need that.
The Pycom device are good, but the ESP32 is not suited for reliable timing in the µs range.

[Stevo52]

@robert-hh I'll try going back to using sleep_ms, sleep_us I guess, even though I thought it would be less precise! Otherwise, I'll have to change to a different microcontroller that can do what I need - some of the limitations of the GPY's FiPY's Micropython implementation and physical constraints (GPIO Pins) have made my development tasks harder and more time consuming than I wanted them to be! Might be time to cut my losses :-)

[robert-hh]

@stevo52 Part of that is the architecture with SPI Flash and SPI RAM. If code or data is required which is not cached, it has to be imported for the SPI device, which takes time, 100-300µs. Short ISR routines can be held in internal RAM, but larger sections code typicality not. This property is common to all devices with similar architecture.

[Stevo52]

@robert-hh Yeah.. I have noticed that. Bit poor really, makes it hard to apply fast accurate, sampling cycles..

[robert-hh]

@aris No. The interrupt response of the ESP32 and the Micropython architecture is poor. Response times vary from 10 µs to over 1 ms.

[Stevo52]

Was there a resolution to this issue?