Am I Objectifying My Architecture Too Much?

[cheeng]

Thank you all in advance!

Currently working on my first foray into micropython and want to get the experts' opinions.

I am working with a pycom board to read some voltages via the ADC and read some sensor data every minute. Rather than the loop/wait paradigm, I went with a shot timer calling a master function when it expires and passing in a state object. The master function then goes out and instantiates some built-in classes such as ADC and some custom classes that instantiate other built-in classes. I figured this was the best way to go about a problem like the above, but reading some books has me worried about instantiating new objects with each shot timer expiration. Worried about garbage collection and potential for heap fragmentation.

Should I instantiate all of the potential objects at the highest level and only once?

Are there better ways to solve a problem like the above in micropython?

Thank you very much!

[pythoncoder]

I tend to instantiate hardware either as globals or as class variables. This is because the lifetime of a device is usually the uptime of the application. There are rare exceptions, for example if you want to dynamically re-purpose the device pins, but in general, for the reasons you give, it seems best to instantiate it once only.

Instantiating hardware in a timer interrupt would fail on a device with hardware IRQ's because allocation is not allowed in an ISR unless you use micropython.schedule(). See the docs.

[cheeng]

Thanks so much for the reply. Good place to read as well. I will start to investigate down that path.

When you say instantiating hardware as a class variable, do you mean wrapping hardware in a custom class for encapsulation/abstraction but still only creating one object with that class?

Also, found something rather unique about pycom boards that are based on the ESP32 chips. They apparently allow memory allocation in their ISR because they load instructions to fire the callback into a queue which is then serviced by another thread in order of reception up to 12. Would not have expected that based on some of the other stuff I read. Probably still have to worry about race conditions, but maybe some of the other parts are easier?

https://docs.pycom.io/firmwareapi/notes ... t-handling

[pythoncoder]

I mean doing something like this:

Code: Select all

class Foo():
    adc = None
    @classmethod
    def setup(cls):
        if cls.adc is None:
            adcpin = pyb.Pin('X1')
            cls.adc = pyb.ADC(adcpin)

It all depends on your application: the above ensures that all Foo instances share a common ADC which is only ever instantiated once. It's just a way of localising it and avoiding a global.

Of course this may not be what you want: if each Foo instance needs its own separate ADC then the ADC will need to be instantiated in the Foo constructor (with a unique Pin).

The Pycom way of handling interrupts is a reflection of ESP32 hardware/vendor code. It has its merits but there will be latency which will be unacceptable in some applications. If you want real, low latency, hardware interrupts you can get them with a Pyboard or other STM solution. But a direct consequence of this is that you can't allocate in your ISR. The STM port gives you the choice: you also have the option of soft ISR's with micropython.schedule which allows allocation at the cost of latency.