Viper: can't do binary op between 'int' and 'object'

[jaguilar]

I have the following code in a class:

    @micropython.viper
    def _update(self, measured: int, dt: int):
        """Update the PID controller.

        measured: The measured value of the system.
        dt: The change in time, in seconds.
        """

        kp_num, kp_shr, ki_num, ki_shr, kd_num, kd_shr = (
            int(self._kp_num),
            int(self._kp_shr),
            int(self._ki_num),
            int(self._ki_shr),
            int(self._kd_num),
            int(self._kd_shr),
        )

        err = int(self.setpoint) - int(measured)
        p = int(0)
        if kp_num != 0:
            p = err * kp_num  # Line 294 **error here**
            p >>= kp_shr

When I run it in Micropython 1.11, I get the following error:

Traceback (most recent call last):
  File "/home/robot/gyroboy/main.py", line 18, in <module>
  File "/home/robot/gyroboy/pid.py", line 294, in _update
ViperTypeError: can't do binary op between 'int' and 'object'

I know supporting an old version of a library is nobody's idea of fun, so please just tell me to buzz off if this is too annoying to deal with. That said, am I doing something obviously wrong here? I feel like neither err nor kp_num are objects.

[rkompass]

Viper is not as intelligent as MP. And if in doubt it always falls back to handle things as MP objects.
So the tuple assignment was the culprit.

@micropython.viper
def _update(self, measured: int, dt: int):
    """Update the PID controller.

    measured: The measured value of the system.
    dt: The change in time, in seconds.
    """

    kp_num = int(self._kp_num)
    kp_shr = int(self._kp_shr)
    ki_num = int(self._ki_num)
    ki_shr = int(self._ki_shr)
    kd_num = int(self._kd_num)
    kd_shr = int(self._kd_shr)    

    err = int(self.setpoint) - int(measured)
    p = int(0)
    if kp_num != 0:
        p = err * kp_num  # Line 294 **error here**
        p >>= kp_shr

does not have this error any longer.

But a better way to got I think would be:

from array import array
k_params = array('I', [kp_num, kp_shr, ki_num, ki_shr, kd_num, kd_shr])

@micropython.viper
def _update(self, measured: int, dt: int, k_pars:ptr32):
    """Update the PID controller.

    measured: The measured value of the system.
    dt: The change in time, in seconds.
    """
    err = int(self.setpoint) - int(measured)
    p: int = 0
    if k_pars[0] != 0:     # kp_num
        p = err * k_pars[0]
        p >>= k_pars[1]    # kp_shr

[jaguilar]

Thanks, something along those lines is what I did end up doing. I should have used array rather than bytearray because the API is nicer. But it did get to working by doing this.

This is me learning about python -- I had always understood the comma assignment notion to be mere syntactic sugar. Sad that it's not!

[jaguilar]

One of the other viper weirdnesses I noticed:

d = (derr * data[_KD_NUM]) // (dt_deriv << data[_KD_SHR])

Does not work. But

d = derr * data[_KD_NUM]
d //= dt_deriv << data[_KD_SHR]

does. Very interesting! I assume the efficiency of one vs. the other is about the same in theory, so I'm not stressed.

[peterhinch]

I had always understood the comma assignment notion to be mere syntactic sugar.

Assigning from a tuple is not very efficient on a microcontroller as the tuple is created in RAM on the heap. Local integer variables exist on the stack, with the RAM automatically being reclaimed when the variable goes out of scope. It's worth reading this doc if you're coming to MicroPython from a background of Python on a PC.

Incidentally, have you considered using round() rather than int() to convert from a float? Might be more accurate, depending on your application.

[jaguilar]

Assigning from a tuple is not very efficient on a microcontroller as the tuple is created in RAM on the heap.

Right, I just didn't realize that I was assigning to a tuple. I thought that

x, y = int(a), int(b)

===

x = int(a)
y = int(b)

But plainly that equivalence is does not actually hold. I'm gonna have to look for any other places where I use this notation in my code. It might be a source of slowness!

Incidentally, have you considered using round() rather than int() to convert from a float?

For the variables we're discussing in this post, they are already ints. Possibly my "int()" calls aren't actually needed? I thought that perhaps I needed to do that to hint to Viper the types of the variables I am loading from.

[peterhinch]

The issue of allocations isn't just an immediate performance problem - it increases the frequency and duration of garbage collections. These block - typically for a few ms.

My guess is that the int() calls can be eliminated, but Viper coding is something of a black art. The other option is to try type hints which cost nothing in code:

x: int = a