ESP8266 Community Forum

- Sun Feb 15, 2015 4:07 pm #9864 Here is what you need to do to make this working
In the UART, enable TXBUFFER_EMPTY interrupt source
create a nice buffer that will act as middle guy (i pushed 1400+ packages so size matters)
when you get data from the WiFi, put it in the buffer and return from the function so the ack can be sent
then your UART interrupt routine will pick up that there are bytes waiting in the buffer and will send those over the line.
When you get data in the UART ISR, send that over to the wifi.

You need to understand that anything you do holding the data receive callback will slow you down lots
without anything, but filling a buffer, I was able to upload over HTTP (running on the ESP) a 7MB file for 6.3 seconds.

What ESP model are you using?
How are you getting the data from avrdude to the ESP? Custom avrdude or another ESP?
I will advise you to get an ESP with GPIOs 12,13 and 14 exposed, take a look at my arduino-like library and go ISP
I have example code that I can give you that turns those avrdude commands into ISP SPI commands and can program just about any AVR chip.
ISP can run at 8MHz for most chips which will increase the programming and response time by lots!
I'm already thinking about using that upload code I just created to test your issues and make a web ISP programmer open the page, select options, pick the hex and upload you go

- Sun Feb 15, 2015 4:54 pm #9866 Thanks for the tips! Your projects sounds very interesting! Although I'm not looking for ISP programming, I use optiboot and just want to update the sketch and not the bootloader itself.
To do what you describe I need to figure out how to turn the txbuffer_empty interrupt off when I have no data. Do you have a piece of code you can point me at? I wonder whether there's another way to have the RTOS schedule a callback in a few usecs instead of using the interrupt...
Note though that 4 characters stuffed into the UART only take 350us to transmit and I'm seeing delays of 300-400ms, so I have a hard time believing that it's all the uart's fault...

- Thu Feb 19, 2015 2:10 am #10139 After a long wild goose chase (troubleshooting this thing is not trivial...) I've come to realize that the uart is not the cause of my long latency. What I'm seeing is that after calling espsentbuffer it takes ~400ms-500ms before the sent callback is invoked even though the other end sends an ACK in under a millisecond. I do not believe that the problem is in the wireless itself 'cause other round trips work great. Basically what kills performance is:
server send packet to esp
esp reponds with 1st packet
esp responds with 2nd packet
What I observe is that the first response packet arrives at the server within 20-30ms, but then my esp app waits for the sent callback ~400-500ms and only then can send the 2nd packet. Has anyone observed anything similar?

- Fri Feb 27, 2015 7:31 pm #10942 I've experienced this with my firmware. The callback functions don't execute very quickly for some reason, and I bet it has to do with their overhead being pretty big for the processor to handle in a reasonable time.

When setting up my ESP as an access point, I pinged it from my computer, and the latency was around 400ms (this is not going through the internet, but my local area network).

What I have found out is that if you send and receive larger ammounts of data less frequently, you get rid of that overhead associated with the callback functions. I'm not sure if that would help in your case.