Pin output extremly slow

[robert-hh]

Changing the value of a Pin with the pin method is extremely slow. It takes about 2.5 ms (!) to change the pin output level. A 0/1 burst then has a frequency of 200 Hz.
Other micropython port are in the range of 1-4 µs, 1000 times faster.
Is there any way to speed this slow pace?

Test code:

from machine import Pin
p1 = Pin("D1", Pin.OUT, value=1)

def run():
    global p1
    p = p1
    p.value(0);p.value(1)
    p.value(0);p.value(1)
    p.value(0);p.value(1)
    p.value(0);p.value(1)
    p.value(0);p.value(1)
    p.value(0);p.value(1)
    p.value(0);p.value(1)
    p.value(0);p.value(1)
    p.value(0);p.value(1)
    p.value(0);p.value(1)

run()

[mikewadsten]

Hi @robert-hh,

We will look into some possibilities to speed up the GPIO accesses in future Digi XBee firmware releases. No guarantees on when this would be completed or how much faster things can get, but I think we may be able to get into the rough ballpark of the speeds of other ports, at least for the time it takes to execute a single .value call.

[robert-hh]

Hi @mikewadsten, thanks for the reply. It's not urgent. I just tried to implement a SPI link using Pin bitbanging. Even if it worked in principal, it is too slow. The Digi MicroPython port is pretty good, especially the documentation. You had to make a choice about what to include and what to drop.
I like the easy ways of compiling on-board and bundling frozen code. That's definitely something that would be good for the main line, given the confusion about mpy-cross versions and the complexity to freeze code.

[tomlogic]

@robert-hh, I'd like to see some of the work to implement os.bundle() get merged upstream, but it got entwined with the XBee platform code a bit. If there was someone interested in doing the porting work, I imagine we could hand off some of the key code pieces for integration on another port, hopefully with a cleaner split between generalized code for relocating byte code from heap to addressable flash, and the platform code necessary to write it to flash.

[robert-hh]

@tomlogic I recall faintly some discussion about a os.bundle() or os.compile() logic in the forum or repository. Maybe there is a PR. I have the impression that this was dropped in favor of native C modules. And there is also the discussion open about embedded Python modules. But even with XBEE, if you want to bundle a large python script then you have to cross-compile that externally.
B.T.W.: Do you or @mikewadsten know whether pins in Pin.OUT mode are configured with strong drivers = 20 mA drive capability?

[mikewadsten]

@robert-hh Which XBee device(s) are you using?

[robert-hh]

@mikewadsten It's an XBEE 3, model XB3-24Z8PT-J (very fine print on the label)

[mikewadsten]

I'm not sure what the drive strength is for that hardware or what (if any) configuration for drive strength exists on XBee 3 Zigbee. You can probably get an answer by emailing tech.support AT digi.com

[tomlogic]

@robert-hh, in our case, MicroPython runs as a separate task, and the end-user doesn't have the ability to compile their own firmware. Use of .mpy files allows for source code that can't be compiled on device due to limited heap space. But then relocating that byte code to flash allows for maximal run-time use of that limited heap.

[robert-hh]

But then relocating that byte code to flash allows for maximal run-time use of that limited heap.

That's what I'm doing.

[johnwayner]

Was any progress ever made with regard to the original slow pin value calls issue?

[robert-hh]

No progress was reported. And I lost that port out of focus.

[nillovanillo]

Hi,

Any update on the slow pin value call issue?

[NathanPeter]

I'm also looking for an answer to this and this is one of the few threads I've found. Running MicroPython on XBee 3 the digital output is very slow on the XB3-24 module. I'm seeing just under 2.5 ms to set the output. Tried firmware 300D and 3012, and it's the same. I'm using the TH module. Using machine library, same as above.

Any feedback is greatly appreciated.

[mikewadsten]

@NathanPeter Put simply, the MicroPython implementation on XBee 3 modules (XB3-24, XB3-C-*) is designed for adding simple edge intelligence to the module (e.g. upon receipt of a certain message, set a digital output, or do some I²C communication), not for bit-banging or other high-speed digital interfacing. We do have an internal ticket tracking this request, but it has not been prioritized. If you have are in touch with Digi sales, please contact them to raise this request.

Out of curiosity, what are you trying to accomplish using digital pin output where the slow GPIO access is an issue?

[NathanPeter]

Hi Mike, Thanks for the quick reply. It’s just so much slower - like by a factor of 1000 - than one might expect so I thought maybe I’m doing something wrong or there’s a workaround. The fact that there’s a microcontroller in the XBee is great and it’s really nice not to have an additional controller if possible, so that’s my goal. It saves a lot of hassle at production. I’m currently using the XBee3 with a character display that communicates with i2c and that is working fine. I’m also looking at another display that is parallel or SPI. SPI isn’t an option with the XBee3, so I’ve tested the parallel and it works but it’s slow enough that the text appears to scroll across. So it ‘works’ but just trying to see if it can be more responsive. I’m not already in touch with Digi sales. I’m sure there would be many other applications that could use the faster DIO, and also SPI while they’re at it.