Dear $Espressif_CEO,

i'd like to raise a few point with regards to the SDK stuff for your ESP8266 Chip.

I have seen that you now have released a VirtualBox-Image that runs Lubuntu and has the GCC for the lx106 core, which your chip uses, preinstalled. However, as you are aware, this is just not enough to get people started to compile their own code for the chip. While you make it very easy for people to "sign" your NDA and get access to the basic SDK, it is far from being a ready-t-go solution. I have several issues/ideas/hints that i want to bring to your attention, in the hopes that you are receptive to them.

First of all, let me ask you: what is the point of providing a Linux based VM that has just the compiler installed, but nothing else? I mean, really, let's face it: The cat is out of the bag already. That is, your SDK sources are available elsewhere on the net, if one looks for them. However, people like to stay on the legal side of things if possible. Why don't you just release at least a basic SDK as well? Your chip became quite popular "overnight", so to say, in the maker and hobbyist scene. Mind you, quite some of those tinkerers (like me) work on professional projects or in companies. Providing them with easy access to the stuff required to get your chips working them means that they will remember it, and are far more likely to integrate them in real products. Which in turn means real business for you terms of chips sold.

Just look at the esp8266.com forum. You see, people are using that chip, and they are using the SDK from wherever it comes. Help them out a bit by providing free access to the SDK. They use it anyways. There is no real need to get perfect translations or the likes. People can, and will, figure it out anyways. Mind you, i have "signed" an NDA with your company, and was rather disappointed to see that even with newer version you don't really provide much more than what is already out there.

Another point is the status of the precompiled libraries that are in the SDK, as well as libc.a and libhal.a which are in the Xtensa toolchain. As for the latter two, their sources come with a permissive license, so it should no problem to release them as sources. Or at least as binary .a files (however, i would prefer sources). But then there are the libraries that are in your SDK. It would be really good to have the sources for them as well. After all, quite some of them are based on freely available sources, like lwip, json, ssl, etc. Keeping them locked up gives a bit of a bad taste: on one side you benefit from such code being freely available to build the firmware of your chips, but then you lock it up and provide it only as binaries. I understand that you are legally entitled to that, but morally it leaves a bad taste. So i ask: Why?

Next is the issue of the compiler. As you know (after all, you just released a VM image containing it) there is now a working GCC out there. What's more, people have written tools to create the required fimrwamre binaries out of the compiled .out file, as well as uploading them to the chip. Those tools are rather portable, and open-source. I would welcome you to integrate them in your SDK. Especially on Windows the esptool i have written provides the benefit of being much faster when it comes to generate the .bin files. This means that you and your customers can benefit from having a faster turn-around time during development of firmwares as well. And then: What's the business with creating a lot of xt-* links that point to the gcc equiavlents? Why not simply clean up your makefiles and have them use the proper tool(s) directly? (Oh, and i have created a very simple makefile to compile stuff from your SDK as well).

Finally, what about the code that is in the internal ROM of the chip? It would be great to have some form of API documentation for that. I mean, you yourself must have that already, otherwise you could not use it in the first place. No need for sources there (it can't be changed anyways, since it is in ROM), but at least the header files for that would be great. A few lines describing what each function does would be an added bonus. In case it is not clear: i mean the functions that are provided through the linker script. This would have anotther benefit: Having the headers means that the compiler can check for the syntax/arguments required, and throw an error if it is used the wrong way.

I would be very happy to help you out whereever i can, as long as you are willing to provide the results as much open-source as you can. That means at least the SDK, even if that means only pre-compiled libs for now, but i would also like to urge you too release the sources for them as well.

You have a really, really huge chance here to make the ESP8266 to be _the_ low-cost solution for connecting things to WiFi. It is a fantastic chip, and so far people really like it. Help us to make it a bit more accessible, by providing the SDK and the sources for the libs. People who will tinker with it, and see that they have easy access to all that is required to use the chip, will remember that and have it in mind when it comes to adding WiFi functionality to a real product. On the other hand, staying secretive about it will mark it as "not so easy to use" in their minds, making them look elsewhere for solutions to put in their products. Plus, as i said, the issue of you using freely available sources to make your chip work, while at the same time closing the midified sources up and only provding a binary file. That is just not right, in my (and many others) opinion.

As said, a lot of that stuff is already out there anyways. You now have the chance to "legalize" the use of it. To be clear, i do _not_ refer to the Xtensa toolcahain, but only your SDK, libraries, documenatation, etc. I mean, you _do_ want to have people use your chips, right? If so, the easier you make it for them to do so, the more will use them.

Again, i can only repeat: i would be more than happy to help you wherever i can. I have no problem with sitting down with a bunch of sources and headers with chinese comments, having them auto-translated for a rough overview, and then trying to get it into a more useful english, if that is a problem. I can also help with writing tools, if needed. I could also create a VM image that contains all that is needed to start developing right away (Linux, toolchain, tools, editors, etc.).

I would be happy if you would consider my points, and if you could give me feedback on them.

Greetings,

Christian Klippel