GPIO Performance
GPIO Performance
Postby skywave » Thu Aug 20, 2015 9:33 pm
I found a wonderful article about GPIO performance here: http://naberius.de/2015/05/14/esp8266-g ... rformance/
and tried to include as asm on my project to set GPIO fast:
__asm__ volatile ("movi a2, 0x60000304\n"
"movi a4, %0\n"
"memw\n"
"s32i a4, a2, 0\n"
::"r" (setbits):"a2", "a4");
setbits is a static uint16;
However the linker gives me: undefined reference to `a5' (that I'm not using). Could you please advice on what can be wrong? Thank's in advance.
and tried to include as asm on my project to set GPIO fast:
__asm__ volatile ("movi a2, 0x60000304\n"
"movi a4, %0\n"
"memw\n"
"s32i a4, a2, 0\n"
::"r" (setbits):"a2", "a4");
setbits is a static uint16;
However the linker gives me: undefined reference to `a5' (that I'm not using). Could you please advice on what can be wrong? Thank's in advance.
Re: GPIO Performance
Postby dkinzer » Thu Aug 20, 2015 11:03 pm
I haven't attempted to discover what's going on with the inline assembler code but I say why bother? The eagle_soc.h file contains definitions that allow direct port manipulation that results in similar code. For example:
My hypothesis is that the W1TS in the name of the register means "write 1 to set". There are other definitions in eagle_soc.h containing W1TC meaning "write 1 to clear".
You could create some macros that are less verbose and, perhaps, more suggestive of their function, e.g.
Code: Select all
40211000: 60000304
40211004: 8000
[...]
GPIO_REG_WRITE(GPIO_OUT_W1TS_ADDRESS, 0x8000);
40211022: fff831 l32r a3, 40211004 <_irom0_text_start+0x4>
40211025: fff621 l32r a2, 40211000 <_irom0_text_start>
40211028: 0020c0 memw
4021102b: 006232 s32i a3, a2, 0
My hypothesis is that the W1TS in the name of the register means "write 1 to set". There are other definitions in eagle_soc.h containing W1TC meaning "write 1 to clear".
You could create some macros that are less verbose and, perhaps, more suggestive of their function, e.g.
Code: Select all
#define GPIO_OUT_SET(m) GPIO_REG_WRITE(GPIO_OUT_W1TS_ADDRESS, m)
Don Kinzer
Beaverton, OR, USA
Beaverton, OR, USA
Re: GPIO Performance
Postby eriksl » Fri Aug 21, 2015 5:04 am
Also the assembly code won't give you any speed increase, because the rate at which the GPIO's can be toggled is limited and is way lower than you can ever achieve with compiled C code, so there is no point.
I keep wondering why all these people want to toggle GPIO pins at Mhz rate???? If it's for pwm, just use the supplied pwm functionality, no need to re-invent it yourself.
I keep wondering why all these people want to toggle GPIO pins at Mhz rate???? If it's for pwm, just use the supplied pwm functionality, no need to re-invent it yourself.
Re: GPIO Performance
Postby skywave » Fri Aug 21, 2015 8:12 am
If you want to do PWM at 1000Hz with 1000 steps -> the minimum step/stage must have 1us ON and 999us OFF. So it really matters to toggle the pins at Mhz rate. I have also find out that the interrupt routine (on PWM file) takes around 3us to execute, even if we don't do a thing inside (only reload the timer). So that code won't work for the smallest steps 1us, 2us, 3us.
Re: GPIO Performance
Postby eriksl » Fri Aug 21, 2015 4:07 pm
I know. That's why other microcontroller have this stuff in hardware, it must act incredibly fast (and do nothing most of the time as well).
The atmega328p has a 16 bits counter/timer/pwm that can run directly on the system clock which is 20 MHz at most. That will give you a 16 bit resolution at 305 Hz AT MOST. I've found that actually the required resolution is about 12 bits (for tuning leds right down to almost invisible in the dark), then you could achieve 5 KHz rate. And then we're talking dedicated hardware on the not-low-end-atmel series.
I think you should reconsider if your goals are realistic. The SDK PWM functionality already is quite efficient, I doubt you can do very much better than that (and still keep the SDK code happy).
The atmega328p has a 16 bits counter/timer/pwm that can run directly on the system clock which is 20 MHz at most. That will give you a 16 bit resolution at 305 Hz AT MOST. I've found that actually the required resolution is about 12 bits (for tuning leds right down to almost invisible in the dark), then you could achieve 5 KHz rate. And then we're talking dedicated hardware on the not-low-end-atmel series.
I think you should reconsider if your goals are realistic. The SDK PWM functionality already is quite efficient, I doubt you can do very much better than that (and still keep the SDK code happy).
Who is online
Users browsing this forum: No registered users and 12 guests
Login
Newbies Start Here
Are you new to ESP8266?
Unsure what to do?
Dunno where to start?
Start right here!
Latest SDK
Documentation
Complete listing of the official ESP8266 related documentation release by ESPRESSIF!
Must read here!
- All times are UTC+08:00
- Top
- Delete all board cookies
About Us
Espressif Systems is a fabless semiconductor company providing cutting-edge low power WiFi SoCs and wireless solutions for wireless communications and Internet of Things applications. We are the manufacturer of ESP8266EX.