RTOS SDK based Sming

[hreintke]

@ALL :
I have been working on a Proof of Concept of the RTOS SDK based Sming.
Reason is the move from Espressif towards RTOS SDK, also for the upcoming ESP32.
Result is in my https://github.com/hreintke/Sming_RTOS_POC.git repository.

• Based on Sming Develop of 26/11/2015
• Most of the Sming components included
• Only limited testing done
• No Framework/Application structure, just application
• I am running on Windows
  More details in the "README"

Have a look, test, feedback and start helping to get to an Alpha version.

Disclaimer :

• I am NOT planning to create a cloned Sming project -> this should become part of SmingHub repository.
• I have tried to get into contact with @anakod since december 8th without any success -> I have no access rights to add this to the SmingHub organzation.
• This should be resolved soon, in order not to get a "dead end". Any help appreciated.

[alonewolfx2]

@hreintke i will look it. where is task implementation

[hreintke]

Task implementation is "just plain" rtos.
In the POC I just start a task without any functionality.

As it is now Sming is running in main task and doesn't use any other.
To change that (if necessary) does also need more/further adaption to Sming to create thread/task safety.

Please focus first on porting current sming functionality before introducing new.

[alonewolfx2]

@hreintke second question is can we use app/framework things like main sming with nonos sdk? i think its important for adding new examples

[hreintke]

@alonewolfx2 :
Yes sure we can.
Just realize that this is a Proof of Concept done by me only.
Now opened up, the community should also take further action to test and extend.
So if app/framework is you prime concern, implement and PR.

[raburton]

No Framework/Application structure, just application

Maybe this is stupid question, but what do you mean by this?

[hreintke]

In sming you build framework -> libsming.a -> building application using lib -> flash
In here build sming/application as one -> flash

[raburton]

On right, that doesn't sound like a big problem. I'm away at the moment, then will be working all over Christmas :-( but I'll have a look when I get chance. Sounds interesting!

[hreintke]

No, not a big problem but just one of the things (makefiles etc) where I do not have much experience.
And.. not necessary for my initial working on this

[AutomationD]

@hreintke why not just create another RTOS branch and then implement selector which sdk to use?

[hreintke]

@kireevco : I have been thinking of that but
1/ It takes (a lot) of additional effort to get a Sming which supports both SDK's
2/ In my opinion, Sming (community) cannot support two SDK's alongside. It's one or the other.
3/ For applications there is little difference which SDK is used.

So if we want to move/support RTOS SDK. Let's take the step now in a one shot. If someone really wants to stick to NONOS SDK, he/she will keep current functionality but no further upgrades.

[ystrem]

+1
I think we should release "stable" Sming with NONOS SDK (we did) and now
use RTOS. Like hreintke said.

2015-12-22 8:48 GMT+01:00 hreintke notifications@github.com:

@kireevco https://github.com/kireevco : I have been thinking of that
but
1/ It takes (a lot) of additional effort to get a Sming which supports
both SDK's
2/ In my opinion, Sming (community) cannot support two SDK's alongside.
It's one or the other.

So if we want to move/support RTOS SDK. Let's take the step now in a one
shot. If someone really wants to stick to NONOS SDK, he/she will keep
current functionality but no further upgrades.

—
Reply to this email directly or view it on GitHub
#495 (comment).

[AutomationD]

I'm not sure if it is a safe step. I would keep both sdks until rtos will be confirmed stable.

That's my opinion.

Sent from my iPhone

On Dec 21, 2015, at 11:48 PM, hreintke notifications@github.com wrote:

@kireevco : I have been thinking of that but
1/ It takes (a lot) of additional effort to get a Sming which supports both SDK's
2/ In my opinion, Sming (community) cannot support two SDK's alongside. It's one or the other.

So if we want to move/support RTOS SDK. Let's take the step now in a one shot. If someone really wants to stick to NONOS SDK, he/she will keep current functionality but no further upgrades.

—
Reply to this email directly or view it on GitHub.

[alon24]

so this is only for windows right?
No HOWTO for mac?

On Tue, Dec 22, 2015 at 10:12 AM, Dmitry Kireev notifications@github.com
wrote:

I'm not sure if it is a safe step. I would keep both sdks until rtos will
be confirmed stable.

That's my opinion.

Sent from my iPhone

On Dec 21, 2015, at 11:48 PM, hreintke notifications@github.com wrote:

@kireevco : I have been thinking of that but
1/ It takes (a lot) of additional effort to get a Sming which supports
both SDK's
2/ In my opinion, Sming (community) cannot support two SDK's alongside.
It's one or the other.

So if we want to move/support RTOS SDK. Let's take the step now in a one
shot. If someone really wants to stick to NONOS SDK, he/she will keep
current functionality but no further upgrades.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#495 (comment).

[hreintke]

What is necesary is a "working development environment" for Sming. That is available for mac.
Set environment variable or update makefile for :

TOOLS_ROOT ?= c:/Espressif

# Base directory for the compiler
XTENSA_TOOLS_ROOT ?= c:/Espressif/xtensa-lx106-elf/bin

# base directory of the ESP8266 SDK package, absolute
SDK_BASE    ?= c:/Espressif/ESP8266_RTOS_SDK
SDK_TOOLS   ?= c:/Espressif/utils

# esptool path and port
ESPTOOL ?= $(SDK_TOOLS)/esptool.exe
ESPPORT ?= COM5
# Baud rate for programmer
BAUD ?= 256000

And you should be up and running

[hreintke]

@kireevco :
We do keep NONOS SDK and support for that in the current repo.
And if a new version comes from Espressif, we decide how to suppport.

My statement is : When Sming RTOS is stable, we should cease NONOS SDK support

[alonewolfx2]

i think too early for cease nonos sdk. espressif will support nonos sdk until last quaerter on 2016.

[robotiko]

@alonewolfx2 I'm with @hreintke.
If RTOS works and we have all Sming ported to it, it makes not much sense to support nonos.
Sming is an abstraction layer on top of it, so why to keep legacy system when not using it?
The are multiples advantages from RTOS and none from keeping nonos.. if everything is ported and working properly.
However it is still soon for this debate. RTOS version is not in place yet, it is just POC.

[AutomationD]

@hreintke let's use https://github.com/SmingHub/SmingRTOS if you will be using a separate repo.

But bear in mind, it's splitting efforts and we still need to find one to focus one, and if that would be RTOS, then ceasing support for NONOS would be the only way to continue with good quality code.

[hreintke]

@kireevco : Yes sure that is the idea but...
I also asked @anakod to open up the SmingHub organization.
Not only by creating silently a repository but by really open up to the community you will get enough momentum to keep Sming alive as a viable solution/framework.
As mentioned before I am waiting for a response from @anakod to read the plans on his involvement and ideas about future of Sming.

[hreintke]

Work in progress in https://github.com/hreintke/Sming_RTOS_POC.git

[anakod]

Related to #553

I think we should continue this discussion. Many changes in RTOS is a breaking changes. Will be right to make decisions about new arctitecture and choose optimal solutions.

Some most actual questions:

• Should we wrap RTOS API in Sming style API/classes or use it as it is?
• How splitting to threads should be organized (for core and user level)
• Did we plan to move from low-level NONOS LWIP to classiс sockets implementation?
• Default threads (on start). Delegates and threads.

RTOS threads provide many benifits and simplification for core and user code. When I worked on Smig core development, I have made vary many solutions which can be omitted in multithread environment. Now we should find the best compromise between new features with large rewriting and backwards compatibility.

[alonewolfx2]

@anakod

Should we wrap RTOS API in Sming style API/classes or use it as it is?

i think we should. But step by step. firstly stable code

Default threads (on start). Delegates and threads.

every delegates can work on new thread. so any delegates doesnt break any wifi or other operations

backwards compatibility.

Old libraries and codes almost full compatible with old nonos sdk. it needs a couple adding or deleting. so we can continue on rtos sdk. espressif will continue with rtos sdk and leave nonos sdk in 2016. so if we want to keep allive sming on esp32 (i want to it) we cant use nonos sdk anymore.
if we decide ro change all work with rtos, there is no "nonos" sdk backward compatibility.

[hreintke]

Work in progress in Sming_RTOS_POC