ESP8266 Community Forum

- Mon Jan 12, 2015 12:00 pm #7098 Thanks. I'll give it a shot. Can you please tell me which version of visual studio you're using ?

I also saw a post somewhere about an eclipse setup, also on windows. I guess I should be able to get something working

- Tue Jan 13, 2015 12:56 am #7167 Ok... so I got a build setup with eclipse.
Took a while to figure out how to set the baud rate to 9600, but it worked. I was able to compile the AT20 firmware, change the AT+GMR string and see it being returned in the terminal.

I'll get back to this post with my tests on a non-AT firmware.

- Sat Jan 17, 2015 3:12 pm #7545

Just a beginner here, but the AT command mode seems like a pain-in-the-*** to work with. The commands work just fine in terminal mode, but once you try to hook up a microcontroller, things get awkward.

Not being able to find much on this, I was wondering if anyone here would know about an API frame-based firmware, much like the xBees from Digi have.

Thanks in advance for any ideas on this matter.

I have a similar problem. I just want to connect my ESP-01 to a micro. In my case this is a Microchip PIC18F25K80 as I need a CAN interface. Could this be more suited to the IoT version of the ESP code? While there is some info on the AT command set, I am at a loss as to finding out about the IoT version and how to interface to it.

Mike B

- Wed Jan 21, 2015 3:09 pm #7891 I'm kinda in the same boat - looking for a better solution.
In my case i have a large codebase running on my host micro that's expecting a socket interface, and currently running on lwIP.
hacking that to directly use AT+ commands instead would be a bad idea.

I'm thinking a fairly quick & easy short-term solution would be to use SLIP or PPP.
PPP is built-in to lwIP, so its reasonably safe to assume its supported (or can be) on ESP8266 -
SLIP is so simple its 1 page of 'C' code, thus easy to port into any system,
though connecting that cleanly into ESP8266' lwIP stack to route through would take more knowledge of lwIP & ESP8266 internals than i have or care to learn at this time.
ideally i would love to have an AT+ command to start PPP on the same uart (after some setup & switching to a higher baudrate)
In this mode ESP8266 is essentially acting as a proxy/router.
using a couple of IO pins for handshaking / flow control might be useful for efficiency, but not really necessary.

Longer term i'd prefer to avoid the duplication of IP stacks and use only the one on the ESP8266;
to that end what i imagine as an ideal solution for me is a kind of binary socket tunnel through the serial link,
which would need only a very minimal, lightweight 'C' API library on the external MCU to replicate the socket API to my application.
If there's no way to get PPP/SLIP running without compiling my own ESP8266 firmware,
I *may* attempt to do this "binary socket tunnel" interface initially as a wrapper for a couple of the AT+ commands,
as a proof of concept, but i'm concerned that could end up wasting a lot of time.
I'd much rather collaborate with someone who can do the ESP8266 firmware side of things.