Date   

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


Re: Next supported boards on Zephyr - STM32L0 ?

Neil Armstrong
 

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>


Is possible move to CMake and crosstools-ng in 1.9

jack ma
 

Hi,
I am looking forward to that zephyr wil move to crosstools-ng and cmake 
just want to know if there are detailed plans for these great work in the next release?

Thanks


Re: Zephyr help

Geoffroy Van Cutsem
 

Hi Tamra,

 

I do not know much about the Z-tree myself but assuming this is equivalent to the Zephyr kernel running on Arduino 101, you could get a lot of info directly from the Zephyr Project website:

* All documentation: https://www.zephyrproject.org/doc/

* Arduino/Genuino 101 documentation: https://www.zephyrproject.org/doc/boards/x86/arduino_101/doc/board.html

 

HTH,

Geoffroy

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Tamra Oyama
Sent: Friday, June 16, 2017 8:46 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] Zephyr help

 

Hello Zephyr Team,

I am using the Arduino 101 Curie Open Developer Kit Z-tree.
Link: https://software.intel.com/en-us/node/675544

When I try to compile a file in Zephyr using make config, there are a bunch of choices I need to pick. Is there a standard or default way to set up the zephyr compiler in the Z-tree?

I want to set up the Zephyr OS so I can compile C++ files, how would I go about doing this? In the github below, there are various bluetooth files about controlling bluetooth. I am interested in gaining control of the curie Bluetooth so I can write and compile my own programs. Do you have any suggestions?

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/bluetooth

Thank you,
Tamra


Re: Next supported boards on Zephyr - STM32L0 ?

Erwan Gouriou
 

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).

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 :-)).

Erwan


On 16 June 2017 at 11:11, Felix Levitre <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@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Zephyr 1.8.0 Released

Erwin Rol
 

Thanks for including my Olimex BSP.

- Erwin

On 16-6-2017 5:37, Nashif, Anas wrote:
Hi,



We are pleased to announce the release of Zephyr kernel version 1.8.0.



Major enhancements with this release include:



* Tickless kernel

* IP Stack improvements

* Bluetooth 5.0 features

* Ecosystem: Tracing, debugging support through third-party tools (openocd,

Segger Systemview)

* Improved build support on Mac and Windows development environments

* Xtensa GCC support

* Initial implementation of MMU/MPU support

* Expanded device support



More details can be found here:
https://github.com/zephyrproject-rtos/zephyr/releases





Many thanks to all of you who made this release happen. Thank you for
the contribution and participation.



Regards,

Anas



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


Next supported boards on Zephyr - STM32L0 ?

Felix Levitre <Felix.Levitre@...>
 

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 help

Tamra Oyama <tamrako@...>
 

Hello Zephyr Team,

I am using the Arduino 101 Curie Open Developer Kit Z-tree.
Link: https://software.intel.com/en-us/node/675544

When I try to compile a file in Zephyr using make config, there are a bunch of choices I need to pick. Is there a standard or default way to set up the zephyr compiler in the Z-tree?

I want to set up the Zephyr OS so I can compile C++ files, how would I go about doing this? In the github below, there are various bluetooth files about controlling bluetooth. I am interested in gaining control of the curie Bluetooth so I can write and compile my own programs. Do you have any suggestions?

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/bluetooth

Thank you,
Tamra


Zephyr 1.8.0 Released

Nashif, Anas
 

Hi,

 

We are pleased to announce the release of Zephyr kernel version 1.8.0.

 

Major enhancements with this release include:

 

* Tickless kernel

* IP Stack improvements

* Bluetooth 5.0 features

* Ecosystem: Tracing, debugging support through third-party tools (openocd,

  Segger Systemview)

* Improved build support on Mac and Windows development environments

* Xtensa GCC support

* Initial implementation of MMU/MPU support

* Expanded device support

 

More details can be found here: https://github.com/zephyrproject-rtos/zephyr/releases

 

 

Many thanks to all of you who made this release happen. Thank you for the contribution and participation.

 

Regards,

Anas


CAN drivers/infrastructure

Erwin Rol
 

Hey all,

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

- Erwin

5661 - 5680 of 8711