Unexpected behaviour when toggling GPIO pin

[paulg]

I was curious how fast could a TinyPICO board toggle a GPIO pin? I flashed the following code into boot.py and main.py and attached a scope to pin 26.

Code: Select all

# boot.py: does nothing

Code: Select all

# test24.py: Basic loop timing test
print('\nHello. This is test 24')
from machine import Pin
led2=Pin(26, Pin.OUT)
while True:
    led2.on()
    led2.off()

The answer is about 77.6kHz. However, I did not get a stable trigger. A little twiddling with the scope revealed why.



I wondered how frequently this happened.





It appears that 1 in 32 cycles are stretched. However, this is not all. I occasionally see:



And I have once captured:



The board is a brand new one with factory firmware, i.e. v1.11-267-gc430567b6-dirty.

I have also seen almost identical behaviour on two other TinyPICO boards with esp32-idf3-20191220-v1.12.bin firmware. In this case the frequency is slightly lower at 74.0kHz and the 'normal' waveform has almost a 50% duty cycle.

Can anybody explain this behaviour?

[jimmo]

Can anybody explain this behaviour?

Sorry the images in your post don't seem to work -- if I go directly to the URL I get a 403 error from dropbox.

I think I'll need to see the images to understand the question -- if it's that the frequency is low (only 75kHz), that's just how MicroPython works. If you need something faster then using RMT might be a good option. See docs here: http://docs.micropython.org/en/latest/l ... 2.html#rmt

Also if there's jitter, then there are a few things that happen in the background that could explain this. If you want to just do short bursts of pin activity, then disabling interrupts (machine.disable_irq / machine.enable_irq) and disabling GC (gc.disable / gc.enable) during the operations would help.

[paulg]

@jimmo. This is unfortunate! I can recreate the problem by viewing the forum on an iPad that is not linked to my Dropbox account.

Unlike the 'regulars' on this forum, I do not have permission to upload images to the forum, so I used my Dropbox Public folder thinking it would do the trick. Obviously it doesn't. The problem is that none of the instructions that I've seen either online or on the Dropbox web site match up with what I see on the Dropbox site or what I get when I right click on files in my Mac Finder Dropbox Public folder.

I have experimented with Google Drive, but so far haven't got it to work. Suggestions are welcome!

[jimmo]

right click on files in my Mac Finder Dropbox Public folder.

I think the trick is to do this from the web interface. You should be able to "share by URL".

I have experimented with Google Drive, but so far haven't got it to work. Suggestions are welcome!

This definitely works, I've used this to share firmware images here before. Once the file is in Drive, share by URL.

I'm not sure whether embedding as images into the post will work, but at least you can post the URLs.

[paulg]

@jimmo, thanks for the suggestions. Let's try again!

I have posted the images in the correct order below together with the links. Hopefully one or the other will work.

Normal waveform:



https://drive.google.com/file/d/17ZYKrG ... sp=sharing

Stretched waveform:



https://drive.google.com/file/d/1SJueKA ... sp=sharing

Big picture:



https://drive.google.com/file/d/1TNCWWJ ... sp=sharing

32 cycles:



https://drive.google.com/file/d/1LQGIhY ... sp=sharing

4 + 32 cycles:



https://drive.google.com/file/d/1aGuspc ... sp=sharing

Low and High stretched:



https://drive.google.com/file/d/1zsRpz6 ... sp=sharing

I will have to submit this to see whether or not it works.

[pythoncoder]

OK, we can see them now. I'm no expert on the ESP32 but I may know what's going on. Unlike the Pyboards, the ESP32 has an underlying OS. I think interrupts are occurring which periodically grab small amounts of CPU time: this is stretching your cycles. In general ESP32 and ESP8266 do not provide good realtime performance. In addition to the effects you are seeing MicroPython interrupts are subject to relatively large and variable amounts of latency.

For excellent realtime performance you need a baremetal port such as a Pyboard: such ports are deterministic, and in the case of Pyboards, faster.