Updates being made directly to release branches instead of trunk -> merge

[davydnorris]

The current SCM approach taken in this repo seems to be to make all changes to trunk, and then create a release branch every time a new stable release is made. It is then assumed that any bugs discovered in a release would then be fixed on trunk and pushed to any affected release.

However it appears that changes are being made directly on the release branches and are not pushed back to trunk, or perhaps made separately to both branches - this means that when you compare the release/3.0.0 branch you find it's 35 commits ahead of the trunk (as well as being behind, which is expected).

A great example of this is that version.h on trunk still says it's at SDK 2.2.0, while the one in the release/3.0.0 branch is showing 3.0.0.

I tried a compare in order to merge the commits from release/3.0.0 but there are numerous changes to the binary lib files and it's impossible to know what's changed. Would it be possible to please update and keep trunk at the very latest of all files, including merging in any outstanding changes made on the release/x.x.x branches? This will make testing and debugging the SDK so much easier

[xcguang]

Hi,
Could you use release/v3.0.0 branch? With our plan, we will gradually stop the maintenance of NonOS versions, and move to RTOS SDK. Maybe release/v3.0.0 is our last release branch, of course, there may also be some sub versions to fix bugs, for example 3.0.1, 3.0.2.
If possible or new projects, please use RTOS SDK.

[davydnorris]

That's a real shame - right now I do a lot with i2s and I need the predictability of the NonOS SDK.

Is the release/v3.0.0 branch up to date? It shows it is 21 commits behind master

[xcguang]

Thanks for your advice, I will update master branch to the latest today.

[marcelstoer]

Thanks Davyd! This has been bothering me for quite some time. My PRs to address the version inconsistency have been ignored.

we will gradually stop the maintenance of NonOS versions, and move to RTOS SDK.

That's bad news - not good for the NodeMCU project I'm involved in. And ESP8266 Arduino-core I guess.

[MaJerle]

@xcguang, what will happen with AT commands software development?

You will move to RTOS SDK?

[xcguang]

Hi @MaJerle,
Yes, ESP8266 AT will be moved to the latest RTOS SDK, in the future, the command sets, ESP8266 can support, will be the same as ESP32.
Now We just fix bugs in NonOS, and not going to add feature to NonOS SDK and NonOS AT.

[MaJerle]

Thanks for quick feedback. Do you have any timeline when we can expect this to happen?

[kriegste]

Would you compile the SDK like promised here?
#162 (comment)
So if it's the last version without new features, it will be as small as possible.

[davydnorris]

The current Arduino ESP8266 core is based on NonOS too - I know there is an RTOS based port but it's not official. Will you be moving that as well?

[d-a-v]

Will there be some kind of nonos-sdk API wrapper for users to run their code with RTOS sdk without modification ?

About arduino we need to understand all implications of the API changes before considering and being able to switch.

[davydnorris]

@d-a-v it's not really possible to have a wrapper, however there is a migration guide and pretty detailed instructions in the RTOS SDK User Guide for earlier versions of the RTOS SDK. Essentially, applications using the timer system can stay unchanged but those using the event queue system have to be rewritten. There are other small changes but the rest of the API can stay the same.

However, the problem is that not only is the NonOS SDK going away, the RTOS SDK has been moved to the same IDF approach as the ESP32. Long term that's a really nice thing, but short term it means that existing RTOS applications have had to have some pretty extensive mods before they run in the new RTOS SDK.

So what that means is that it's not going to be a simple job to move from NonOS to RTOS.

[nathanpc]

Will there be any migration guide for existing NonOS code to be ported to the RTOS SDK? I believe this is important since a lot of people will be porting their code soon.

[zl3ag]

Hi,
Could you use release/v3.0.0 branch? With our plan, we will gradually stop the maintenance of NonOS versions, and move to RTOS SDK. Maybe release/v3.0.0 is our last release branch, of course, there may also be some sub versions to fix bugs, for example 3.0.1, 3.0.2.
If possible or new projects, please use RTOS SDK.

Is it release branch 3.0.0 or 3.0 ?

[xcguang]

@MaJerle We plan to release it in the second quarter of 2019. And the project will be synchronized to GitHub in Q1.

[MaJerle]

Thank you @xcguang. Are there any plans to improve AT commands flow, specially around connections and server features? These topics were discussed already many times.

[xcguang]

@nathanpc The APIs between RTOS and NonOS are too different, especially internal process.
About RTOS APIs, you can refer to https://docs.espressif.com/projects/esp-idf/en/latest/

[xcguang]

@MaJerle When new AT is ported to RTOS, we will aggregate all the feature about TCP, and evaluate them based on new RTOS SDK. If possible, we will update to you.

[nathanpc]

@xcguang That documentation is a lot better than the NonOS SDK one, it shouldn't be much trouble to port the code since it's so well documented.

Have all the IDF functions been ported to the ESP8266 RTOS SDK or are we going to find some are still under development?

[eriksl]

Personally I don't think the NON-OS sdk code is lacking much, so I can live with the halt of development.

On the other hand, the documentation is really lacking some important things. If the documentation would be just as thorough as e.g. ATmel makes it, for the hardware interface, all non-WLAN functionality could be implemented by ourselves, that is what I'd prefer - not being forced to use FreeTOS which adds nothing for me, and only gets me further away from the hardware.

Expressif keeps saying they can't release more information due to the WLAN implementation must remain "secret". I can live with that last fact and I understand it, but most of the documentation we're missing isn't at all about the WLAN interface or even related. A good example is the I2S interface which is really NOT documented. Only a piece of example code that doesn't even work without modifications. Nothing explains the registers and constants that are used. The same goes for the PDM (sigma-delta) interface and I also see people struggling with hardware SPI on a daily basis, exactly for the same reason.

Also it's ridiculous someone like Richard Burton had to severly reverse engineer the system to implement an alternative boot loader. The mechanism for booting should also simply be documented.

Never an answer to my question how much stack space can be used, which I think is quite important.

And that way I could go on and on.

[Misiu]

@xcguang I'd like to ask about what are Espressif plans for NonOS SDK?
Many people are wondering what will happen to it because many awesome projects depend on it, I think about Arduino Core for ESP8266.
There is a discussion started by @devyte about the future of this awesome project.
There is a question asked by @TD-er:

If Espressif is actually putting NonOS to EOL, is there still any reason for them to keep their core libraries closed?

I'd like to ask @igrr @kedars @me-no-dev @projectgus and @Spritetm (because You buys are listed in People section on Github) about Your thoughts about opening those closed libraries.

If NonOS will be discontinued at some point why don't allow other projects (NodeMCU and Arduino Core) to be able to still function without a mass code rewrite.

Projects like Arduino Core and NodeMCU and countless others are the reason why ESP8266 is so popular.
People (at least this was my case) don't choose chip because it looks nice and has feature x, but because there is a great community around it, there are tons of examples and libraries and there are people that spend their free time to make those projects, examples and are dedicated to helping newbies like me.

As @devyte mentioned in this issue one of the option to still maintain Arduino Core is to stick with NonOS and reverse engineer the closed libs. If Espressif would open those libs then that mass effort could be spent on creating new features or fixing bugs instead of recreating parts that already work.

[eriksl]

The official rationale for not disclosing the source of the libraries is that they contain RF related code, which, if one would change, would result in non-compliant RF emission (by the usual standards and regulatory committees) and therefore illegal.

This argument only holds partly, because much of the code has nothing to do with the WiFi interface. It looks more that they're trying to protect some IP, maybe not even their own, may from Cadence etc. And that is a shame because many aspects of the hardware, unrelated to RF, remain unaccessible this way, as Espressif has a way of not disclosing many hardware details.

[MaBecker]

If NonOS will be discontinued at some point why don't allow other projects (NodeMCU and Arduino Core) to be able to still function without a mass code rewrite.

Espruino is another great project that will be effected by EOL.

[MaJerle]

Hi @MaJerle,
Yes, ESP8266 AT will be moved to the latest RTOS SDK, in the future, the command sets, ESP8266 can support, will be the same as ESP32.
Now We just fix bugs in NonOS, and not going to add feature to NonOS SDK and NonOS AT.

@xcguang does this mean that we will loose (for example) +LINK_CONN message on ESP8266 for new commands? Or AT+SYSMSG command too? This would be very pity if this is the case.

[davydnorris]

Latest commits have been made to the 3.0.0 release branch again instead of first to master and then to release. Could the commit strategy be changed to push to mater first and then stable master pushed to release?

Most of us track master and so we don't see these changes easily. Right now rel 3.0.0 branch is 116 commits ahead of master :-(

[xcguang]

Hi,
The bugfixes and features on branch release/v3.0.0 and release/v2.2.x, is cherry-picked from branch master.
Latest commits on branch release/v3.0.0, changes SDK version 3.0.1 and AT version 1.7.1(The last decimal point represents patch version), and recompile AT release bin. These modify is different from master branch, the version of master is 3.1.0-dev.

[davydnorris]

Thanks @xcguang - but then why is branch 3.0.0 116 commits ahead of master? Shouldn't it always be behind if you are cherry picking from master?

Can you guarantee that if we pull and build from master we will always have all fixes, even if 3.0.0 is ahead? As long as master has all the latest library builds and fixes then that's OK because many of us have forks of master and we need to merge changes

[xcguang]

116 commits ahead of master is because we cherry-pick them in library project, and then compile library and create a new commit to push library on ESP8266_NONOS_SDK. It looks the different branch at the GitHub goes the different route some months ago.
If the bugs fixed on branch 3.0.0 and 2.2.x, they should have been fixed on the master.

[davydnorris]

ok thank you