Can only use ancient LWIP version #370
Comments
eriksl
changed the title
|
my fork of esp82xx-nonos-linklayer can be compiled against esp-open-sdk. |
|
good luck getting an response from them, this sdk is as good as dead. The best thing they could do is patch wifi bugs aginst 2.x SDK which is what everyone uses since 3.x introduced so many problems. You would think the fact they hired people like igrr would mean ESP8266 could get some love and that the community could come together and sort out what some of the problems are. But nope, nothing. I'm sure they will continue to manufacture ESP8266 modules for a while but if you can make your project/code work with ESP32 that is definitely the way to go. Ai-Thinker who made the popular ESP12-x series of modules is stopping production of those and moving to their own brand of devices based on various non-espressif chips like RTL8710. ESP-WROOM will probably be the only ESP8266 module being made for a while and with ESP32-WROOM costing almost the same, I imagine most people will switch to that. |
|
I already would be very happy if I could use LWIP 2. How does it work, does this yield code that can be linked in and translates between the APIs? Although ESP32 may sound interesting, it has some interesting additional hardware and some extra memory, it's really not for me. It dictates the use of de IDK which means even less access to hardware and even more obligatory use of Espressif code. That may be fine for someone who is a programming newbie, so they can use arduino or python or whatever, but I want full control. If only because I want to be the only source of bugs, I don't want to be dependent on some other party to fix bugs and bad programming practices. Unfortunately that is a very real issue with Espressif. Besides that, I's a lot harder to (hand) solder an ESP32 module than my favourite: ESP12, which has exactly enough pins broken out, in a comfortable spacing. I don't care at all for "development" boards on a DIP module. I don't care for the small difference in price as well. The ESP8266 will continue to be produced for several years, I am sure. Simply because there are many gadget devices that are using it. Not because of the big share of hobbyists, Espressif doesn't care for them at all. I'd really like to say: Espressif, be a man about this, admit you don't care and just release the sources of all non-wifi stuff. Or at least the documentation (if there is any, I doubt it). Then we can (amongst others) adapt the code to work with newer LWIP sources. |
|
I really wish the three of us could take over this SDK - the fundamental problem is that they seem to think all it is used for is the AT firmware, when there are so many more projects built against the NonOS SDK than that. I would probably pull the AT firmware out completely - let them use the RTOS based build of that. But then I would upgrade the NonOS so we all can keep using it for projects @xcguang - please can Espressif consider this?? |
|
@someburner @eriksl - I am starting to do what AI Thinker is doing and I am actively investigating non ESP chipsets to move to. |
|
I don't think it's about the AT firmware. I think there are (still) lots of gadgets that use ESP8266 with the NONOS SDK. They usually perform simple functions (like a remote switch) so for them it doesn't matter if the SDK isn't developed or maintained. These are probably in some way paying customers (either by buying the chips in considerable quantities or having some sort of support contract) so they could make the difference, but apparently they're not fussed. Hobbyists may even be commercially interesting for Espressif too, are supposed to move to the IDK and then to ESP32. Which in some ways is not a bad suggestion, as the ESP32 is simply more powerful and has much much better documentation and support. But for us (at least for me), the "advanced" group, the ESP32 is not interesting, nor is the IDK. Much too high level. In the end it's all simply a commercial consideration. Too little money to be made from advanced hobbyists. Sad but true. The difference with e.g. Atmel being that the advanced hobbyists use the same chips as the professionals. But that is going to change too, more and more of their microcontrollers are no longer produced in solder-friendly packages :-( I've been considering for a few years now to use the ESP8266 just for wifi connectivity and hook it up to a proper microcontroller, with full hardware disclosure and documentation. It wouldn't be an Atmel or Microchip because I've gotten used to 32 bit and a fair amount of RAM. I wouldn't be using the AT firmware though, but a custom minimal image that does nothing other than passing packets using SPI and interrupts. If possible even ethernet frames, so I wouldn't be dependent on one LWIP version (where we started this...) If you have suggestions please do. |
|
The bl602 (used in most AI Thinker's products) looks promising. At least they have full hardware disclosure, neat documentation. Now only find out how to make an image ;-) I will look into the Realtek chips too. |
I am not the original author of the hack but essentially, yes, it translates the lower level lwip input/output calls to work for lwip2, where the SDK is making calls in a lwip1 format.
Realistically you are going to get that with most of the cheap chips. The IDF is not perfect but it is at least maintained and they respond to issues/bugs quickly. Most of it is open source, just not core the wifi libs. And apparently there is not the same licensing restrictions so I believe it could be open sourced eventually. There are lots of projects floating around where people don't use IDF or make minimal use of it. You can also choose to not run freertos on one core of the ESP32. I have different goals, and just want WiFi to be stable for my product. The IDF libraries I use work pretty well, are stable, and maintained. That is more than you can say for most companies making similar chips. I did a bunch of googling about different vendors and the consensus from reddit seemed to be that the SDKs of most vendors have the same sorts of limitations as this repo- lack of documentation, sporadic and cryptic vendor releases, no open source wifi, not maintained, etc. Not defending espressif, but please point me to a repo of another vendor where they are taking issues and PRs from their users. |
|
Yes I agree it's all the same. It's a bummer because all the controllers I've grown to love don't need any code and just have all of their hardware fully documented. |
Then I guess I should give it a go. I am a bit woried by the #defines, where they come into play. I'd rather have a clean interface, that only operates in code. But who knows, maybe I can get it that way now. I am already very pleased that apparently someone has managed to reverse engineer the interface (which shouldn't be necessary, don't get me started...) |
|
FYI- easiest way is to do |
|
It doesn't need to be easy. Doable should be enough. I am quite picky when it comes to coding standards and integration to my own code, so I'll probably end up making my own version anyway, it's just the reverse engineering I'm interested in and the proof that it can be done ;-) |
We know that but I don't think they think that way - they see the reason for this SDK is just for the AT firmware. You can see it in their responses to issues here where they keep referring people to the RTOS AT firmware. I wish they would just open this up, remove the AT build parts, and let the userbase maintain this |
|
Just leave out the parts that cannot be open sourced (i.e. the radio licensed parts). I know wifi cards for PC's are actually largely implemented in software, using a fast DSP, which means that if you'd have direct access to this DSP, you could send any radio signal you'd like, which of course is unacceptable. I think something similar goes for the ESP8266, although I don't think there is actually a versatile DSP inside, but there will be some hardware that can be programmed at will, maybe giving access to unlicensed channels or arbitrary wave forms. On the other side, security by obscurity is never a good thing and at some time there will be someone reverse engineering the whole thing. It's only that I have a day job too ;-) I don't even care for any of the non-radio SDK code (be it open or closed). I only ask for the possibility to not use it, which is impossible now. For that the interface between the SDK and LWIP should be documented. It would be nice to have a generic interface not dependent on LWIP at all (e.g. simply "init radio", "associate", "deassociate", "send frame", "receive frame" with some metadata, "timer function" to be called x times a second). Also the remaining hardware should be documented. Or just disclose the source, either way. I am quite sure that would free up lots of DRAM and IRAM, by leaving out all sorts of stuff I am never using and gets included anyway. |
Please do either of these:
The LWIP version we're now bound to have some serious issues with TCP flood control under stress, requiring me to monitor the connection, check for timeouts and then closing and reopening the connection, as that is the only fix. I have no such issues with UDP which uses the same code. I would not be surprised if these issues have been address in the last few years...
I already tried to do option 2 myself, by taking the LWIP version used, updating LWIP in little steps and resolving issues that arose, but at some point I got stuck and couldn't progress any further without breaking all of it (= no packets at received at all, either UDP or TCP).
The text was updated successfully, but these errors were encountered: