Unexpected behaviour when toggling GPIO pin

All ESP32 boards running MicroPython.
Target audience: MicroPython users with an ESP32 board.
Post Reply
paulg
Posts: 29
Joined: Fri Oct 23, 2015 1:06 pm

Unexpected behaviour when toggling GPIO pin

Post by paulg » Tue Feb 04, 2020 5:16 pm

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()
Image

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

Image

I wondered how frequently this happened.

Image

Image

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

Image

And I have once captured:

Image

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?

User avatar
jimmo
Posts: 1177
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia

Re: Unexpected behaviour when toggling GPIO pin

Post by jimmo » Wed Feb 05, 2020 1:33 am

paulg wrote:
Tue Feb 04, 2020 5:16 pm
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
Posts: 29
Joined: Fri Oct 23, 2015 1:06 pm

Re: Unexpected behaviour when toggling GPIO pin

Post by paulg » Wed Feb 05, 2020 6:54 pm

@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!

User avatar
jimmo
Posts: 1177
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia

Re: Unexpected behaviour when toggling GPIO pin

Post by jimmo » Wed Feb 05, 2020 9:03 pm

paulg wrote:
Wed Feb 05, 2020 6:54 pm
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".
paulg wrote:
Wed Feb 05, 2020 6:54 pm
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
Posts: 29
Joined: Fri Oct 23, 2015 1:06 pm

Re: Unexpected behaviour when toggling GPIO pin

Post by paulg » Sun Feb 09, 2020 6:25 pm

@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:

Image

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

Stretched waveform:

Image

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

Big picture:

Image

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

32 cycles:

Image

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

4 + 32 cycles:

Image

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

Low and High stretched:

Image

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

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

User avatar
pythoncoder
Posts: 3925
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Unexpected behaviour when toggling GPIO pin

Post by pythoncoder » Mon Feb 10, 2020 5:40 am

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.
Peter Hinch

Post Reply