- Wed Apr 29, 2015 8:53 am
#16013
This really great stuff! I have been looking for a long time for something like this.
I have a couple of atmega328's (no arduino!) previously connected to enc28j60's (ethernet transceiver) which I am in the process of replacing with esp8266's.
I have it more or less working, but it's never 100% stable like I was used to with the enc28j60's. Especially when you "fire" a lot of data (either in separate connections or in one) to the device, all goes wrong. For a part that's due to the esp not releasing a tcp connection quick enough, so the available number of the tcp connections (4) get filled up real quickly, even though only one connection is required. Some firmwares support udp, which is good for my use, but there are problems with that to; it also counts as a tcp connection and replies don't always go to right address/port combination.
Besides that all, it's very hard to make a fail-safe state machine (especially with the little resources on the atmega328). Sooner or later an +IPD message will cross regular at-command exchange and the state machine will be completely borked. Also I suspect that sometimes uart bytes are dropped by bad framing, because this particular board doesn't have a crystal (yet...).
I now totally worked around it by using timeouts and other workarounds for esp bugs and it now more or less works and keeps working, if you keep the data rate low (i.e. wait 0.2 second between two transmissions). If stuff gets weird, the state machine gets reset rather quickly so there is no hanging/freezing, which I experienced earlier.
BUT the transparent bridge seems to solve all of this. I am now running a test where I send data to esp8266 with the bridge firmware, continuously without delays, and it just works. No hangs, no data loss, just great. I can remove a few hundred lines of code from the atmega328 now
I have one request though, I know it's not peanuts, but at least I would like to have it mentioned.
Communication via UART is very cumbersome for a simple microcontroller like the atmega328. Due to the asynchronous nature, data can come in at any moment, unsollicited. That's not optimal. Also it requires the use of an external crystal which is not always possible.
To overcome above two issues, I would request to use SPI instead. It works synchronously (no crystal required) and also always sollicited. The enc28j60 works that way and it works quite well.
I know that the esp8266 has a hardware SPI implementation, but we probably can't use it, because it's used to address the flash memory. Also it's on the wrong pins. I was thinking of an SPI emulation over de U(S)ART. Depending on the U(S)ART that can be very simple or a somewhat less simple.
The atmega328 has an USART that can be configure as second SPI interface and it will do SPI over the USART just fine. I was hoping the esp8266 has a similar mode in the U(S)ART.
If not, if it supports synchronous mode (USART), it wouldn't too hard to implement also, iirc, hook up the spi clock to the usart clock and we should be almost done already. Otherwise it would get a bit hairy I think, a software SPI implementation with a pin change interrupt :-/
Afaik there is at least one free pin on every esp, to be used as clock. There would be no slave select, but with only one device, it's not really required imho.
Anyone wanting to brainstorm about this please welcome
You can find my fork of this repository on 
