Hi,

On Tue, 2017-06-20 at 14:22 +0200, Tomasz Bursztyka wrote:

Hi Paul,

There has been discussion and complaints that the current
net_context
API that applications can use is too low level and requires lot
of
effort from application developer to create a bug free
application.
Many networking operations that various applications do, are very
similar and can be provided by a library. In order to address
these
issues I created a higher level API that applications can use.

Thanks for posting this RFC. It touches some issue I also wanted to
post RFC about: with (1st stage of) BSD Sockets work nearing
completion
https://github.com/zephyrproject-rtos/zephyr/pull/498 , it would be
nice if all think about "responsibilities division" between 2 APIs.
The initial idea would be:

1. Native Zephyr API has the smallest code size and minimal
overhead.
2. Sockets API is familiar to large audience.

Perhaps, thinking about it in these terms would help to design and
develop APIs further. For example, Sockets API is by definition
takes more code size than native API as it's implemented on top of
it.
But if native API keeps growing, that undermines one of it
benefits.
Likewise, native API is more memory efficient as it minimizes
copies.
But it also cumbersome to use. But if we try to work that around by
another API layer, still adhoc, then perhaps just using Sockets API
is
a viable alternative for such usecases?

Looks like to me that net_app proposal is not growing the native
API. 
It's fully optional.

Indeed, the net_app is just a bunch of helpers that make creating
networking applications a bit easier. This is not replacing any
existing api (expect the semi private net_sample API). The most helpful
thing that net_app API could bring is the transparent support for TLS
and DTLS. I have already implemented server support using TLS, and
finalizing client support.

Socket API and net_app are quite distinct. In fact, many application 
oriented API are
made on top of socket API (like in python for instance).
It's just that, imo, net_app brings some low level bits from
net_context 
that could be avoided.

Afaik net_app will not affect socket api layer at all.

However, as I commented on the rfc PR, net_context could gain of
some 
changes,
which in turn would affect socket API (and bring the possibility to 
emulate select())

It might be quite tricky to change net_context in this respect, but
lets see how it works out.

Tomasz

Cheers,
Jukka

--

On Jun 15, 2017, at 4:52 PM, Erwin Rol <mailinglists@...> wrote:

Hey all,

is there anybody working on CAN drivers and/or higher level CAN stacks
like CANOpen ?

Not aware of any, always open to contribution :)

- k

Hi Paul,

There has been discussion and complaints that the current net_context
API that applications can use is too low level and requires lot of
effort from application developer to create a bug free application.
Many networking operations that various applications do, are very
similar and can be provided by a library. In order to address these
issues I created a higher level API that applications can use.

Thanks for posting this RFC. It touches some issue I also wanted to
post RFC about: with (1st stage of) BSD Sockets work nearing completion
https://github.com/zephyrproject-rtos/zephyr/pull/498 , it would be
nice if all think about "responsibilities division" between 2 APIs.
The initial idea would be:

1. Native Zephyr API has the smallest code size and minimal overhead.
2. Sockets API is familiar to large audience.

Perhaps, thinking about it in these terms would help to design and
develop APIs further. For example, Sockets API is by definition
takes more code size than native API as it's implemented on top of it.
But if native API keeps growing, that undermines one of it benefits.
Likewise, native API is more memory efficient as it minimizes copies.
But it also cumbersome to use. But if we try to work that around by
another API layer, still adhoc, then perhaps just using Sockets API is
a viable alternative for such usecases?

Looks like to me that net_app proposal is not growing the native API. It's fully optional.
Socket API and net_app are quite distinct. In fact, many application oriented API are
made on top of socket API (like in python for instance).
It's just that, imo, net_app brings some low level bits from net_context that could be avoided.

Afaik net_app will not affect socket api layer at all.

However, as I commented on the rfc PR, net_context could gain of some changes,
which in turn would affect socket API (and bring the possibility to emulate select())


Tomasz

Hello Jukka,

On Mon, 19 Jun 2017 14:39:33 +0300
Jukka Rissanen <jukka.rissanen@...> wrote:

Hi all,

There has been discussion and complaints that the current net_context
API that applications can use is too low level and requires lot of
effort from application developer to create a bug free application.
Many networking operations that various applications do, are very
similar and can be provided by a library. In order to address these
issues I created a higher level API that applications can use.

Thanks for posting this RFC. It touches some issue I also wanted to
post RFC about: with (1st stage of) BSD Sockets work nearing completion
https://github.com/zephyrproject-rtos/zephyr/pull/498 , it would be
nice if all think about "responsibilities division" between 2 APIs.
The initial idea would be:

1. Native Zephyr API has the smallest code size and minimal overhead.
2. Sockets API is familiar to large audience.

Perhaps, thinking about it in these terms would help to design and
develop APIs further. For example, Sockets API is by definition
takes more code size than native API as it's implemented on top of it.
But if native API keeps growing, that undermines one of it benefits.
Likewise, native API is more memory efficient as it minimizes copies.
But it also cumbersome to use. But if we try to work that around by
another API layer, still adhoc, then perhaps just using Sockets API is
a viable alternative for such usecases?

Note that this doesn't have to be a deciding factor for your current
proposal, but it would be nice if we started to look at these matters
from this perspective - that instead of scope-creeping existing
API/featureset, accept that we have 2 APIs with orthogonal features
with their weaknesses and strengths, and maintain them as such.

This API can be found
in https://github.com/zephyrproject-rtos/zephyr/p ull/540 and you can
either give comments there, or here if you wish.

The API consists of two parts:

1. Application initialization support.
* The net_app_init() makes sure that we have IP address, routes etc.

Giving an example of the application of the ideas above, with my "BSD
Sockets" hat on, for writing "fully portable" BSD Sockets/Zephyr apps,
I'd think how to make this configuration completely declarative, using
CONFIG_* options, to not require patching code in the Zephyr case with
this net_app_init() call.

Questions: do you think this would make sense at all, and would be
acceptable? Then, would we need this explicit net_app_init() call in
addition to declarative config? If so, how to make declarative and
imperative config to blend well together, e.g. declarative to be built
on top of net_app_init(), instead of e.g. having 2 separate code
modules?

[]

This net_app API will replace the internal net_sample_app API that was
used by some of the network sample applications found under
samples/net directory.

Ok, so if this new API is further evolution of net_sample_app, I'm
definitely +1 on it. But would like to know whether the API evolution
leads us at all, and how to make this API to cover BSD Sockets usecases,
like declarative config.


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

Hi Richard,

nRF52832 in pca10040 does not support USB. Only nRF52840 in pca10056 has USB support.

That said, there is no USB driver as of yet for nRF52840 in Zephyr. Only planned work is to open source Nordic's low level HAL implementations which could simplify having a Zephyr USB driver.

If you are interested in contributing and need assistance please free to ask.

Cheers,
Vinayak

Hi Zephyr Developers,

first of all ... great work! I really love the software design of zephyr!

Is there some work in progress to support the USB driver in the
nrf52-pca10040 board?

I took a look into the low level USB driver in the Nordic SDK
http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v13.0.0%2Findex.html

This API from Nordic looks similar to the API in zephyr.
Is this driver implementation planned for the next zephyr-versions?

Thanks,
Richard

Hi all,

There has been discussion and complaints that the current net_context
API that applications can use is too low level and requires lot of
effort from application developer to create a bug free application.
Many networking operations that various applications do, are very
similar and can be provided by a library. In order to address these
issues I created a higher level API that applications can use.

This API can be found in https://github.com/zephyrproject-rtos/zephyr/p
ull/540 and you can either give comments there, or here if you wish.

The API consists of two parts:

1. Application initialization support.
* The net_app_init() makes sure that we have IP address, routes etc.
configured and the IP stack is ready to serve before continuing. User
can supply a timeout to the function call, and also give a hint what
kind of support it needs from the IP stack. It is possible to use only
the net_app_init() without the connectivity support if needed.

2. Connectivity support
* Developer can create a simple TCP/UDP server or client application
with only few function calls.

Example for the TCP server:

net_app_init_server(&tcp, SOCK_STREAM, IPPROTO_TCP, NULL,
  MY_PORT, NULL, NULL, NULL);
net_app_set_cb(&tcp, NULL, tcp_received, NULL, NULL);
net_app_wait_connection(&tcp);


Example for UDP server:

net_app_init_server(&udp, SOCK_DGRAM, IPPROTO_UDP, NULL,
  MY_PORT, NULL, NULL, NULL);
net_app_set_cb(&udp, NULL, udp_received, pkt_sent, NULL);
net_app_wait_connection(&udp);


Example TCP client:

net_app_init_client(ctx, SOCK_STREAM, IPPROTO_TCP, NULL,
NULL, peer, PEER_PORT, WAIT_TIME,
  NULL, NULL, user_data);
net_app_set_cb(ctx, tcp_connected, tcp_received, NULL, NULL);
net_app_connect(ctx, CONNECT_TIME);


Example UDP client:

net_app_init_client(ctx, SOCK_DGRAM, IPPROTO_UDP, NULL,
  NULL, peer, PEER_PORT, WAIT_TIME,
NULL, NULL, user_data);
net_app_set_cb(ctx, udp_connected, udp_received, NULL, NULL);
net_app_connect(ctx, CONNECT_TIME);


So the developer needs to setup the proper callbacks that will be
called in various stages of the connection flow.

I created a TLS support for TCP server in this initial pull request.
The TLS support is transparent to the application, all the encryption
and decryption happens inside the net_app API. Only thing the
application needs to do is to setup the TLS, and prepare the
certificates for mbedtls library. With this transparent TLS support, it
is possible to create for example MQTT over TLS support quite easily.

In order to try the TLS support, the net-tools project have this
https://github.com/zephyrproject-rtos/net-tools/pull/8
PR that provides stunnel configuration so that echo-client can be run
in Linux side and it can communicate with zephyr echo-server sample
over TLS.

This net_app API will replace the internal net_sample_app API that was
used by some of the network sample applications found under samples/net
directory.

The current patchset contains these patches:
* net_app core functions
* conversion of echo-client and echo-server samples to use this new API
* base TLS support
* setting up the echo-server to use the TLS if configured so

Future plans:
* create TLS TCP client support
* create DTLS UDP client and server support
* convert existing network samples to use this API

Any comments?

Cheers,
Jukka

Hey David,

yes that one white-space thing I over looked. And now I fixed it the
other errors are gone to, which kind of surprises me.

Did you or someone else change anything between the two runs ?

- Erwin

Hey all,

Could someone tell me why shippable is complaining here?

https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/1619/consolidateTests

- Erwin

Hi Felix,

On 06/16/2017 02:26 PM, Erwan Gouriou wrote:

Hi Felix,


From what I'm aware of, there is no such plan. Though, I know Neil as some L0
port working on his own (though on SoC STM32L053). I'm not sure what are his
plans on that, but maybe you could check with him what is missing to get it
upstreamed (might just be time).

Indeed, it's planned but I still need to debug the base port.

In any case, your help would be welcomed to get the board you need supported.
With some help, you could get it working in few hours and upstreamed in couple
of weeks (so you don't have to wait for next Zephyr release :-)).

If you want to give a try, here is my base branch :
https://github.com/superna9999/zephyr/commits/stm32l0x

I'll be happy to cooperate and get this merged when working !
Having STM32L073 working won't be hard if 053 is working.

Neil

Erwan


On 16 June 2017 at 11:11, Felix Levitre <Felix.Levitre@... <mailto:Felix.Levitre@...>> wrote:

Hi,

I would like to know if the Nucleo STM32L0xx boards from ST (for example STM32L073 with Cortex ARM M0+) will be part of the supported board in the next release of Zephyr ?

If it's not the case, is there a plan to port this board in the future ? (And when ? )

Thanks,

Félix Levitre

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@... <mailto:Zephyr-devel@...>
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>