Date   

Re: AFH issue

Chettimada, Vinayak Kariappa
 

Hi Ali,

Comments inline.

On 27 Jun 2017, at 23:07, Ali Nikookar <nikookar7@...> wrote:

Hi

The Nordic company referred me to your website so I may get my answer here.
My question is that I need to implement my own channel mapping based on a
different scenario.
You can use the HCI LE_Set_Host_Channel_Classification to select you own channel mapping for connections.
This is available in controller only binary (sample/bluetooth/hci_uart), or you can add your own API that your application could use.

For example, in the list of bad channels and good
channels which use RSSI or PER.
What is PER?

I want to increase the BER for good channels
in a certain time period. Another example can be rescheduling the channel
list based on different timing or clustering.
I was wondering if your stack could kindly provide me with a solution.
Currently, there is no software support to profiling BER in the stack.
But, stack does use CRC check on reception to accept valid packets.
You can use the received packet, Rx-ed channel and CRC status to profile.
Grep for “crc_ok” in subsys/bluetooth/controller/ll_sw/ctrl.c.
Interesting function is isr_rx_conn, both RSSI and CRC status are available in that function for use.


Regards
Ali
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Problems with MQTT on FRDM-K64F

aska.wu
 

For the problem of address already in use, it seems that mosquitto is already running,
If you see there's a mosquitto process in "ps aux |grep mosquit", try to stop the existing one by "sudo service mosquitto stop".

Aska Wu


On Tue, 27 Jun 2017 at 21:05 Kevin Stöckl <k_stoeckl@...> wrote:

Hello,

I try to run the sample mqtt publisher on the frdm-k64f.

First I changed the IP-adress on the linux host machine to 192.168.0.75.

Then i type make BOARD=frdm_k64f and then I try to run mosquitto with sudo mosquitto -v -p 1883.

There I got the error message Address already in use and nothing happens.


In the config.h File I changed the Server Address to 192.168.0.75


What could be the problem?

How can I change the IP-adress of the board? And is this necessary?



Thanks in advance

Kevin

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


Zephyr Help

Tamra Oyama <tamrako@...>
 

Hello Zephyr Team,

In the zephyr folder, I am trying to compile the beacon file in the zephyr folder (CODK/zephyr/samples/bluetooth/beacon). It compiles when I write the command, "make", however I am unable to upload it to my Curie on the Arduino 101 using  the "make run SERIAL_PORT=/dev/ttyUSB0 command." This results in the following errors:

make[1]: Entering directory '/home/tamrako/CODK/zephyr/zephyr-project'

make[2]: Entering directory '/home/tamrako/CODK/zephyr/zephyr-project/samples/bluetooth/scan_adv/outdir/qemu_x86'

make[2]: *** No rule to make target 'upload'.  Stop.

make[2]: Leaving directory '/home/tamrako/CODK/zephyr/zephyr-project/samples/bluetooth/scan_adv/outdir/qemu_x86'

Makefile:177: recipe for target 'sub-make' failed

make[1]: *** [sub-make] Error 2

make[1]: Leaving directory '/home/tamrako/CODK/zephyr/zephyr-project'

/home/tamrako/CODK/zephyr/zephyr-project/Makefile.inc:136: recipe for target 'upload' failed

make: *** [upload] Error 2

Do you know the appropriate command to do this? I have looked at the hello world example previously for zephyr and was able to compile it just fine. In that example, nothing is uploaded to the board. I can run hello world without connecting the Arduino 101 at all. I was wondering what the specific command was to upload to the board in zephyr. I know I am able to use cutecom for the M and Z tree. Do you think cutecom would still be appropriate for zephyr and if so do you know what the upload command is using USB for the serial port?

Thank you,

Tamra


AFH issue

Ali Nikookar <nikookar7@...>
 

Hi

The Nordic company referred me to your website so I may get my answer here.
My question is that I need to implement my own channel mapping based on a
different scenario.  For example, in the list of bad channels and good
channels which use RSSI or PER.  I want to increase the BER for good channels
in a certain time period. Another example can be rescheduling the channel
list based on different timing or clustering.
I was wondering if your stack could kindly provide me with a solution.

Regards
Ali


Problems with MQTT on FRDM-K64F

Kevin Stöckl <k_stoeckl@...>
 

Hello,

I try to run the sample mqtt publisher on the frdm-k64f.

First I changed the IP-adress on the linux host machine to 192.168.0.75.

Then i type make BOARD=frdm_k64f and then I try to run mosquitto with sudo mosquitto -v -p 1883.

There I got the error message Address already in use and nothing happens.


In the config.h File I changed the Server Address to 192.168.0.75


What could be the problem?

How can I change the IP-adress of the board? And is this necessary?



Thanks in advance

Kevin


Re: Zephyr: IRC for Bluetooth discussion

Carles Cufi
 

Hi Bjarne,

 

As Justin said, for Bluetooth-related questions feel free to join us on #zephyr-bt. If you’re interested in the BLE controller (LL), and particularly when running on nRF5x hardware, myself (carlesc) and Vinayak (vich) are often around.

 

Carles

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Justin Watson
Sent: 21 June 2017 20:09
To: Brett Preston <bpreston@...>; Bjarne Kielsholm-Ribalaygua <bjki@...>; devel@...
Subject: Re: [Zephyr-devel] Zephyr: IRC for Bluetooth discussion

 

The OS is discussed in the general channel #zephyrproject. The Bluetooth stack for Zephyr is discussed in the channel #zephyr-bt.

 

On Wed, Jun 21, 2017 at 11:02 AM Brett Preston <bpreston@...> wrote:

Hi Bjarne,

 

+ Adding the Developers mail list who will best be able to point you in the right direction

 

Thanks!

 

 

Brett

 

On Wed, Jun 21, 2017 at 11:00 AM, Bjarne Kielsholm-Ribalaygua <bjki@...> wrote:

Hi Brett

 

I understand that there are various IRC channels where the different tracks of Zephyr are discussed between contributors. Can you help me with how to get access to these? I am especially interested in OS and Bluetooth.

 

BR,

Bjarne

_______________________________

 

Bjarne Kielsholm-Ribalaygua (M.Sc., eMBA)

 

Head of Chipset FW - Silicon Engines

 

Oticon A/S

Kongebakken 9

DK - 2765 Smørum

Mobile:           +45 20 81 25 37

Mail:               bjki@...

WWW:            www.oticon.com

 



 

--

Brett Preston

The Linux Foundation

 

Google Talk: bpreston@...

Skype: bprestoncf

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


Re: [RFC] Network application API

Jukka Rissanen
 

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


Changes to testcases and sanitychecks

Nashif, Anas
 

Hi,

We have just merged a series of commits that change the behavior of sanitycheck script and the syntax of the testcase definition file. While the syntax stays mostly the same, it was changed from ini to yaml. Please see the documentation of sanitycheck and the syntax here:

 

https://www.zephyrproject.org/doc/subsystems/test/sanitycheck.html

 

 

This change was done to allow for better and fast filtering of testcases and to allow for increasing the coverage of build and emulation tests we run on every PR. One major issue we had in the past was the fact that we did not test-build some architectures (Cortex-M0) by default which resulted in many issues and broken code in master. In this new environment we have introduced a new board metadata file that helps with filtering test-cases correctly without having to dig into Kconfig, this for example includes definition of RAM/ROM sizes right now and will be expanded to expose additional features that can be tested with testcases that will support those features.

 

If you have some work in progress or a PR already in the tree with new testcase.ini or a modified one, please update it to use the new syntax and file format. There is a rather simple and  straightforward script that can do this for you, for example:

 

./scripts/ini2yaml.py samples/hello_world/testcase.ini sample  # for samples

 

./scripts/ini2yaml.py tests/kernel/pipe/pipe_api/testcase.ini testcase # for tests

 

The difference between samples and tests is just some additional placeholder keywords for samples, the test structure stays the same for both.

 

 

Note that the number of testcases that are now run when you execute sanitucheck has increased by at least 100, which is due to the increased coverage.

 

This topic was covered in the TSC meeting on May 10th.

 

Thanks,

Anas

 

 


Re: Zephyr: IRC for Bluetooth discussion

Brian Jones
 

Hi,


For Zephyr there’s #zephyrproject

For ZJS (Javascript runtime for Zephyr OS) there’s #zjs

 

There may be more but those are the ones I’m aware of.  Both are on Freenode.

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Brett Preston
Sent: Wednesday, June 21, 2017 11:02 AM
To: Bjarne Kielsholm-Ribalaygua <bjki@...>; devel@...
Subject: Re: [Zephyr-devel] Zephyr: IRC for Bluetooth discussion

 

Hi Bjarne,

 

+ Adding the Developers mail list who will best be able to point you in the right direction

 

Thanks!

 

 

Brett

 

On Wed, Jun 21, 2017 at 11:00 AM, Bjarne Kielsholm-Ribalaygua <bjki@...> wrote:

Hi Brett

 

I understand that there are various IRC channels where the different tracks of Zephyr are discussed between contributors. Can you help me with how to get access to these? I am especially interested in OS and Bluetooth.

 

BR,

Bjarne

_______________________________

 

Bjarne Kielsholm-Ribalaygua (M.Sc., eMBA)

 

Head of Chipset FW - Silicon Engines

 

Oticon A/S

Kongebakken 9

DK - 2765 Smørum

Mobile:           +45 20 81 25 37

Mail:               bjki@...

WWW:            www.oticon.com

 



 

--

Brett Preston

The Linux Foundation

+1 (971) 303-9030
bpreston@...

 

Google Talk: bpreston@...

Skype: bprestoncf


Re: Zephyr: IRC for Bluetooth discussion

Justin
 

The OS is discussed in the general channel #zephyrproject. The Bluetooth stack for Zephyr is discussed in the channel #zephyr-bt.


On Wed, Jun 21, 2017 at 11:02 AM Brett Preston <bpreston@...> wrote:
Hi Bjarne,

+ Adding the Developers mail list who will best be able to point you in the right direction

Thanks!


Brett

On Wed, Jun 21, 2017 at 11:00 AM, Bjarne Kielsholm-Ribalaygua <bjki@...> wrote:

Hi Brett

 

I understand that there are various IRC channels where the different tracks of Zephyr are discussed between contributors. Can you help me with how to get access to these? I am especially interested in OS and Bluetooth.

 

BR,

Bjarne

_______________________________

 

Bjarne Kielsholm-Ribalaygua (M.Sc., eMBA)

 

Head of Chipset FW - Silicon Engines

 

Oticon A/S

Kongebakken 9

DK - 2765 Smørum

Mobile:           +45 20 81 25 37

Mail:               bjki@...

WWW:            www.oticon.com

 




--
Brett Preston
The Linux Foundation

Google Talk: bpreston@...
Skype: bprestoncf
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Zephyr: IRC for Bluetooth discussion

Brett Preston
 

Hi Bjarne,

+ Adding the Developers mail list who will best be able to point you in the right direction

Thanks!


Brett

On Wed, Jun 21, 2017 at 11:00 AM, Bjarne Kielsholm-Ribalaygua <bjki@...> wrote:

Hi Brett

 

I understand that there are various IRC channels where the different tracks of Zephyr are discussed between contributors. Can you help me with how to get access to these? I am especially interested in OS and Bluetooth.

 

BR,

Bjarne

_______________________________

 

Bjarne Kielsholm-Ribalaygua (M.Sc., eMBA)

 

Head of Chipset FW - Silicon Engines

 

Oticon A/S

Kongebakken 9

DK - 2765 Smørum

Mobile:           +45 20 81 25 37

Mail:               bjki@...

WWW:            www.oticon.com

 




--
Brett Preston
The Linux Foundation
+1 (971) 303-9030
bpreston@...

Google Talk: bpreston@...
Skype: bprestoncf


Re: CAN drivers/infrastructure

Kumar Gala
 

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


Re: [RFC] Network application API

Tomasz Bursztyka
 

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


Re: [RFC] Network application API

Paul Sokolovsky
 

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


Re: False positive on Shippable ?

David Brown
 

I didn't change anything. You did eliminate the error, leaving only warnings, so perhaps that is why it passed.

David

On Sun, Jun 18, 2017 at 12:07 PM, Erwin Rol <mailinglists@...> wrote:
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


On 18-6-2017 18:08, David Brown wrote:
> Looking
> at https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/1619/1/tests
> there are two different errors here, both coming from checkpatch.
>
> The first is a trailing whitespace error. This is real, and needs to be
> fixed:
>
> -:340: ERROR:TRAILING_WHITESPACE: trailing whitespace
> #340: FILE: drivers/ethernet/eth_stm32_hal.c:91:
> +^I * Transmit Poll Demand to resume transmission $
>
>
> The other errors are checkpatch being confused by the __IO marker before
> the variable declarations. Given that checkpatch is just wrong here, I'm
> not sure what the correct action is. Maybe it is just a warning, and it
> will allow the change in, once the whitespace error is fixed.
>
> David
>
> On Sun, Jun 18, 2017 at 9:19 AM, Erwin Rol <mailinglists@...
> <mailto:mailinglists@erwinrol.com>> wrote:
>
>     Hey all,
>
>     Could someone tell me why shippable is complaining here?
>
>     https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/1619/consolidateTests
>     <https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/1619/consolidateTests>
>
>     - Erwin
>     _______________________________________________
>     Zephyr-devel mailing list
>     Zephyr-devel@lists.zephyrproject.org
>     <mailto:Zephyr-devel@lists.zephyrproject.org>
>     https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
>     <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>
>
>

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


Re: [USB] Nordic NRF52 USB support

Chettimada, Vinayak Kariappa
 

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

On 19 Jun 2017, at 17:46, Richard Peters <mail@...> wrote:

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
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


[USB] Nordic NRF52 USB support

Richard Peters <mail@...>
 

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


[RFC] Network application API

Jukka Rissanen
 

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


Re: False positive on Shippable ?

Erwin Rol
 

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

On 18-6-2017 18:08, David Brown wrote:
Looking
at https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/1619/1/tests
there are two different errors here, both coming from checkpatch.

The first is a trailing whitespace error. This is real, and needs to be
fixed:

-:340: ERROR:TRAILING_WHITESPACE: trailing whitespace
#340: FILE: drivers/ethernet/eth_stm32_hal.c:91:
+^I * Transmit Poll Demand to resume transmission $


The other errors are checkpatch being confused by the __IO marker before
the variable declarations. Given that checkpatch is just wrong here, I'm
not sure what the correct action is. Maybe it is just a warning, and it
will allow the change in, once the whitespace error is fixed.

David

On Sun, Jun 18, 2017 at 9:19 AM, Erwin Rol <mailinglists@...
<mailto:mailinglists@...>> wrote:

Hey all,

Could someone tell me why shippable is complaining here?

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

- Erwin
_______________________________________________
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>


False positive on Shippable ?

Erwin Rol
 

Hey all,

Could someone tell me why shippable is complaining here?

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

- Erwin

5641 - 5660 of 8700