ESP8266/160MHz - How to speed up GPIO state changes under 135us?

I've written a sizable application in LUA for ESP and ended up with an uninteresting problem.
I need to generate 50us waveforms and as it turns out this is probably impossible.


I clock the ESP at 160MHz and the minimum transition time between:
gpio.write(4,gpio.LOW)
gpio.write(4,gpio.HIGH)
is, as much as 130us. Is there any way to speed this up?

It can be accelerated. You just have to use the interface created for this, namely PWM.

I don't think this is quite the right solution. PWM has a whole waveform time of 1.1mS
so much longer than what happens directly when the GPIO state changes.
Yes, you can generate 2.1uS, but it will take the rest of the time to fill, which is not quite the effect you want.
I want to send a string to any GPIO:

0100000001101010000001000000000010000000000101111111101000000000010001100011100101110001

Each bit is supposed to last 50uS which means I am still missing 85uS.

In ESP Basic it is even less nice, because the state change time lasts as long as 2mS
If it were possible to do the insertion in Assembler, the problem would be solved quickly, but there is no such option in either Lua ESP or ESP Basic. I am still looking in the SDK to see if it is possible to tweak this quality or write a new class.

And why not use direct operations on the ports? After all, your whole problem stems from the time overhead of the library, not the performance of the processor itself.

Nevertheless, it's not a good idea anyway, and not because of performance but because of timing determinism. The built-in ESP software supports several interrupts and these will effectively interfere with the generation of the waveform by software writes to the port.

I2S + DMA, such as in the WS2812 controller designs.

BlueDraco wrote:

And why not use direct operations on the ports?

Here you are right that's what I'm getting at, the problem is that ESP LUA has ready-made modules for specific devices. Direct addressing is limited and that's where the problem is, unless I don't know something or haven't found it in the references.

It is not possible to "limit addressing". No one is telling you to use off-the-shelf, ultra-high-position modules where the port line state change procedure has 300 instructions. The right solution was pointed out by the colleague above - SPI/I2S + DMA.

And it seems to me and I am just trying to change the UART configuration, 19200 baud is very close to 50uS because it comes out about 11/19200=57.3us which I think is within the error limit , the only thing left is to force the UART to transmit in binary.
This would probably be the simplest solution. I found the UART.c library for LUA in C and as I see it even the baudrate can be corrected, maybe that would be the solution.
I2C, I tried it, a bit more fun with it than it originally looks and I'll leave it for last, but the concept is ok, thanks.

I'm listening to the thread, I used to work on embedding the Lua language into C/C++ applications and still remember something. It was cool.

I'm glad to see the language being used in such interesting systems, and it makes sense in a lot of circumstances - but I agree that handling a time-critical loop is not really ... though.
Even if it matches microseconds to some time, it will still be slightly variable.


Is this an openusur project of some sort?

The supposition was correct, on the UART the transmitted data at 19200b is close to the expected times.

I send 3 values as Byte (1,5,255) and they are read correctly.




Something is probably wrong with the UART.c module, because it doesn't change None to Even .
But.

Lua adds two values 62,32 from each other and crashes.
That is, prompt(62) and (32) comes in, ESP stops responding only unplugging, revives ESP.

As for the project, I am modifying an electrical management system at home, made a few years ago. Several components have been changed and I need to modify the software. The communication with the system was via GSM and now via ESP and with a local network with the possibility to go out to the world. Part of the network works on 485 Modbus, part in my protocol, I also want to change and standardise this. On top of that, I still have Zamel's EXTA Free integrated with ORNO.
[/code]

I did not give up, I was still looking for a solution to the problem of generating fast pulses in LUA ESP and after many attempts, I found a solution to the topic.

Well, the first fundamental issue is the Firmware. I was using the Custom version, where there are most simply errors in the C syntax. Just use, the "full" version, the Firmware of 2015.07 and the function:

works correctly.
Please note that the total time included in the table must not exceed 1,000,000

This was the cause of the whole problem, so I consider the topic closed and finally resolved.