Date   

Re: nrf52840 + enc28j60 setup

Ravi kumar Veeramally
 

Hi Karol,

Thanks for the reply.

SPIM0_NRF52_GPIO_SCK_PIN
SPIM0_NRF52_GPIO_MOSI_PIN
SPIM0_NRF52_GPIO_MISO_PIN
SPIM0_NRF52_GPIO_SS_PIN_0
and for interrupt on gpio, what should I set?

I mean numbers associated with pins
for   e.g. P0.03 - SCK
CONFIG_SPIM0_NRF52_GPIO_SCK_PIN =  3  ?

- Ravi

On 03/29/2018 01:11 PM, Lasończyk, Karol wrote:
Hi,
Well, You can use for example:
P0.03 - SCK
P0.04 - SO
P0.28 - SI
P0.29 - CS
P0.30 - INT

SPI pins are settable in config menu.
To catch interrupt on P0.30 pin You can use gpio driver. I see that pin can be configured in gpio driver to generate interrupt on particular edge.
There are no dedicated pins for SPI in nRF devices. You can use any of available pins. Of course remember that LED or something else can be connected to the particular pin. Pins suggested by me are safe.
I advise to start with slower clock frequency like 1MHz and increase it when everything will work properly.

Karol


-----Original Message-----
From: Cufi, Carles
Sent: Thursday, March 29, 2018 10:45 AM
To: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>; zephyr-devel@lists.zephyrproject.org; Lasończyk, Karol <Karol.Lasonczyk@nordicsemi.no>; Głąbek, Andrzej <Andrzej.Glabek@nordicsemi.no>
Subject: Re: [Zephyr-devel] nrf52840 + enc28j60 setup

+ Karol and Andrzej in case they can help out with info.

On 29/03/2018, 10:24, "zephyr-devel-bounces@lists.zephyrproject.org on behalf of Ravi kumar Veeramally" <zephyr-devel-bounces@lists.zephyrproject.org on behalf of ravikumar.veeramally@linux.intel.com> wrote:

Hi,
I am experimenting nrf52840 + enc28j60 (ethernet controller). I am trying to
connect to some ports on board to provide spi functionality, need help in
enabling this setup.
Details about ENC28J60 board are here. I need pin numbers on nrf52 board
and SPI configuration setup.
================= ===================================
NRF52840 PCA10056 ENC28J60 (pin numbers on the board)
================= ===================================
PIN SCK (1)
PIN SO (3)
PIN SI (2)
PIN CS (7)
PIN INT (5)
VDD VCC (10)
GND GND (9)
================= ===================================
Which pins to use and how to configure them?
Thanks in advance,
Ravi.
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: nrf52840 + enc28j60 setup

Lasończyk, Karol <Karol.Lasonczyk@...>
 

Hi,
Well, You can use for example:
P0.03 - SCK
P0.04 - SO
P0.28 - SI
P0.29 - CS
P0.30 - INT

SPI pins are settable in config menu.
To catch interrupt on P0.30 pin You can use gpio driver. I see that pin can be configured in gpio driver to generate interrupt on particular edge.
There are no dedicated pins for SPI in nRF devices. You can use any of available pins. Of course remember that LED or something else can be connected to the particular pin. Pins suggested by me are safe.
I advise to start with slower clock frequency like 1MHz and increase it when everything will work properly.

Karol

-----Original Message-----
From: Cufi, Carles
Sent: Thursday, March 29, 2018 10:45 AM
To: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>; zephyr-devel@lists.zephyrproject.org; Lasończyk, Karol <Karol.Lasonczyk@nordicsemi.no>; Głąbek, Andrzej <Andrzej.Glabek@nordicsemi.no>
Subject: Re: [Zephyr-devel] nrf52840 + enc28j60 setup

+ Karol and Andrzej in case they can help out with info.

On 29/03/2018, 10:24, "zephyr-devel-bounces@lists.zephyrproject.org on behalf of Ravi kumar Veeramally" <zephyr-devel-bounces@lists.zephyrproject.org on behalf of ravikumar.veeramally@linux.intel.com> wrote:

Hi,

I am experimenting nrf52840 + enc28j60 (ethernet controller). I am trying to
connect to some ports on board to provide spi functionality, need help in
enabling this setup.

Details about ENC28J60 board are here. I need pin numbers on nrf52 board
and SPI configuration setup.

================= ===================================
NRF52840 PCA10056 ENC28J60 (pin numbers on the board)
================= ===================================
PIN SCK (1)
PIN SO (3)
PIN SI (2)
PIN CS (7)
PIN INT (5)
VDD VCC (10)
GND GND (9)
================= ===================================

Which pins to use and how to configure them?

Thanks in advance,

Ravi.

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


Re: nrf52840 + enc28j60 setup

Carles Cufi
 

+ Karol and Andrzej in case they can help out with info.

On 29/03/2018, 10:24, "zephyr-devel-bounces@lists.zephyrproject.org on behalf of Ravi kumar Veeramally" <zephyr-devel-bounces@lists.zephyrproject.org on behalf of ravikumar.veeramally@linux.intel.com> wrote:

Hi,

I am experimenting nrf52840 + enc28j60 (ethernet controller). I am trying to
connect to some ports on board to provide spi functionality, need help in
enabling this setup.

Details about ENC28J60 board are here. I need pin numbers on nrf52 board
and SPI configuration setup.

================= ===================================
NRF52840 PCA10056 ENC28J60 (pin numbers on the board)
================= ===================================
PIN SCK (1)
PIN SO (3)
PIN SI (2)
PIN CS (7)
PIN INT (5)
VDD VCC (10)
GND GND (9)
================= ===================================

Which pins to use and how to configure them?

Thanks in advance,

Ravi.

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


nrf52840 + enc28j60 setup

Ravi kumar Veeramally
 

Hi,

I am experimenting nrf52840 + enc28j60 (ethernet controller). I am trying to
connect to some ports on board to provide spi functionality, need help in
enabling this setup.

Details about ENC28J60 board are here. I need pin numbers on nrf52 board and SPI configuration setup.

=================    ===================================
NRF52840 PCA10056    ENC28J60 (pin numbers on the board)
=================    ===================================
PIN                                     SCK  (1)
PIN                                     SO   (3)
PIN                                     SI   (2)
PIN                                     CS   (7)
PIN                                     INT  (5)
VDD                                   VCC  (10)
GND                                   GND  (9)
=================    ===================================

Which pins to use and how to configure them?

Thanks in advance,

Ravi.


Re: Shave Zephyr boards with Occam's razor

Marti Bolivar
 



On Wed, Mar 28, 2018, 8:02 AM Erwan Gouriou <erwan.gouriou@...> wrote:


On 28 March 2018 at 13:41, Bøe, Sebastian <Sebastian.Boe@...> wrote:
Hi,

documented guidelines and standards would be great.

One comment:

"c) Enable board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )"

Board authors should not be speculating about what board components
will be used by an application. If they do this users will have to turn off
components that they never asked to be turned on in the first place[0].

Boards should be expressing:
"This is what this HW can do"

Applications should be expressing:
"This is what my application needs"


Agreed. Then we might turn this into:
"c) Configure board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )"


So that enabling (activation) is application responsibility.

With this modification, I think this list sounds great for users (and should make things more consistent and simple for developers and reviewers too).

Thanks a lot, Erwan, for driving this.

Marti


I'm not saying this is easy, and perhaps achieving it requires some plumbing
that is not present yet, but this is the direction we need to be moving.

[0] https://github.com/zephyrproject-rtos/zephyr/issues/5454
________________________________________
From: zephyr-devel-bounces@... <zephyr-devel-bounces@...> on behalf of Erwan Gouriou <erwan.gouriou@...>
Sent: Wednesday, 28 March 2018 11:54:44 AM
To: zephyr-devel
Subject: [Zephyr-devel] Shave Zephyr boards with Occam's razor

TL;DR: Numquam ponenda est pluralitas sine necessitate
           (approx: define guidelines for default board configuration)

Hi,

Most of the boards supported in Zephyr tree could be configured in quite multiple ways,
either for pins configuration, hardware interfaces, instances of these interfaces and
then configuration of the drivers for each of these entities.
When porting a board and pushing it upstream, one will either copy configuration from
a similar board, either configure the board according to his constraints or interesting
new ideas.
Outcome is a great heterogeneity of configurations and discussions during reviews.
Besides, these various configurations don't make things easy when one try to enable
tests/samples running on multiple boards.

I propose to shave away board configuration multiplicity and promote few guidelines
defining default (in tree) board configurations:

a) When a connector (arduino, 96board, ....) is present, configure pins to fit this connector
b) Configure ips matching these pins (For instance configure SPI instance for arduino SPI)
c) Enable board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )
d) Configure an output for console
e) Propose and configure a default network interface
f) Enable all GPIO ports
g) Provide device tree Zephyr aliases

These guidelines won't avoid discussions since some for these points will conflict for
some boards. Also, some points deserve clarification (configuration means configured
only or configured and enabled?).


g) introduces zephyr aliases and could be seen a separated topic:
Some are already used today, as a tacit rule, also known as LED0, SW0. I propose to
extend these to other components (SPI, I2C, .) and define them in board device tree file.
For instance:
       aliases {
                   zephyr,led0 = &green_led_1;
                   zephyr,sw0 = &user_button;
                   zephyr,spi = &spi3;
                   zephyr,serial = &uart2
       };
Using these aliases (and their generated #define) directly in samples/tests would help to
make tests generic without too much trouble. I've set this approach in practice in PR
#5381 [RFC] Add gpio nodes to stm32 based soc/boards [1]
I also have a short coming work using aliases and addressing:
#6017 Enable easy use of shields with overlays [2]

Best Regards
Erwan

[1] https://github.com/zephyrproject-rtos/zephyr/pull/5381
[2] https://github.com/zephyrproject-rtos/zephyr/issues/6017

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


Re: Shave Zephyr boards with Occam's razor

Erwan Gouriou
 



On 28 March 2018 at 13:41, Bøe, Sebastian <Sebastian.Boe@...> wrote:
Hi,

documented guidelines and standards would be great.

One comment:

"c) Enable board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )"

Board authors should not be speculating about what board components
will be used by an application. If they do this users will have to turn off
components that they never asked to be turned on in the first place[0].

Boards should be expressing:
"This is what this HW can do"

Applications should be expressing:
"This is what my application needs"


Agreed. Then we might turn this into:
"c) Configure board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )"


So that enabling (activation) is application responsibility.

I'm not saying this is easy, and perhaps achieving it requires some plumbing
that is not present yet, but this is the direction we need to be moving.

[0] https://github.com/zephyrproject-rtos/zephyr/issues/5454
________________________________________
From: zephyr-devel-bounces@lists.zephyrproject.org <zephyr-devel-bounces@lists.zephyrproject.org> on behalf of Erwan Gouriou <erwan.gouriou@...>
Sent: Wednesday, 28 March 2018 11:54:44 AM
To: zephyr-devel
Subject: [Zephyr-devel] Shave Zephyr boards with Occam's razor

TL;DR: Numquam ponenda est pluralitas sine necessitate
           (approx: define guidelines for default board configuration)

Hi,

Most of the boards supported in Zephyr tree could be configured in quite multiple ways,
either for pins configuration, hardware interfaces, instances of these interfaces and
then configuration of the drivers for each of these entities.
When porting a board and pushing it upstream, one will either copy configuration from
a similar board, either configure the board according to his constraints or interesting
new ideas.
Outcome is a great heterogeneity of configurations and discussions during reviews.
Besides, these various configurations don't make things easy when one try to enable
tests/samples running on multiple boards.

I propose to shave away board configuration multiplicity and promote few guidelines
defining default (in tree) board configurations:

a) When a connector (arduino, 96board, ....) is present, configure pins to fit this connector
b) Configure ips matching these pins (For instance configure SPI instance for arduino SPI)
c) Enable board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )
d) Configure an output for console
e) Propose and configure a default network interface
f) Enable all GPIO ports
g) Provide device tree Zephyr aliases

These guidelines won't avoid discussions since some for these points will conflict for
some boards. Also, some points deserve clarification (configuration means configured
only or configured and enabled?).


g) introduces zephyr aliases and could be seen a separated topic:
Some are already used today, as a tacit rule, also known as LED0, SW0. I propose to
extend these to other components (SPI, I2C, .) and define them in board device tree file.
For instance:
       aliases {
                   zephyr,led0 = &green_led_1;
                   zephyr,sw0 = &user_button;
                   zephyr,spi = &spi3;
                   zephyr,serial = &uart2
       };
Using these aliases (and their generated #define) directly in samples/tests would help to
make tests generic without too much trouble. I've set this approach in practice in PR
#5381 [RFC] Add gpio nodes to stm32 based soc/boards [1]
I also have a short coming work using aliases and addressing:
#6017 Enable easy use of shields with overlays [2]

Best Regards
Erwan

[1] https://github.com/zephyrproject-rtos/zephyr/pull/5381
[2] https://github.com/zephyrproject-rtos/zephyr/issues/6017


Re: Shave Zephyr boards with Occam's razor

Sebastian Boe
 

Hi,

documented guidelines and standards would be great.

One comment:

"c) Enable board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
Ethernet, VCP, )"

Board authors should not be speculating about what board components
will be used by an application. If they do this users will have to turn off
components that they never asked to be turned on in the first place[0].

Boards should be expressing:
"This is what this HW can do"

Applications should be expressing:
"This is what my application needs"

I'm not saying this is easy, and perhaps achieving it requires some plumbing
that is not present yet, but this is the direction we need to be moving.

[0] https://github.com/zephyrproject-rtos/zephyr/issues/5454
________________________________________
From: zephyr-devel-bounces@lists.zephyrproject.org <zephyr-devel-bounces@lists.zephyrproject.org> on behalf of Erwan Gouriou <erwan.gouriou@linaro.org>
Sent: Wednesday, 28 March 2018 11:54:44 AM
To: zephyr-devel
Subject: [Zephyr-devel] Shave Zephyr boards with Occam's razor

TL;DR: Numquam ponenda est pluralitas sine necessitate
(approx: define guidelines for default board configuration)

Hi,

Most of the boards supported in Zephyr tree could be configured in quite multiple ways,
either for pins configuration, hardware interfaces, instances of these interfaces and
then configuration of the drivers for each of these entities.
When porting a board and pushing it upstream, one will either copy configuration from
a similar board, either configure the board according to his constraints or interesting
new ideas.
Outcome is a great heterogeneity of configurations and discussions during reviews.
Besides, these various configurations don't make things easy when one try to enable
tests/samples running on multiple boards.

I propose to shave away board configuration multiplicity and promote few guidelines
defining default (in tree) board configurations:

a) When a connector (arduino, 96board, ....) is present, configure pins to fit this connector
b) Configure ips matching these pins (For instance configure SPI instance for arduino SPI)
c) Enable board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
Ethernet, VCP, )
d) Configure an output for console
e) Propose and configure a default network interface
f) Enable all GPIO ports
g) Provide device tree Zephyr aliases

These guidelines won't avoid discussions since some for these points will conflict for
some boards. Also, some points deserve clarification (configuration means configured
only or configured and enabled?).


g) introduces zephyr aliases and could be seen a separated topic:
Some are already used today, as a tacit rule, also known as LED0, SW0. I propose to
extend these to other components (SPI, I2C, .) and define them in board device tree file.
For instance:
aliases {
zephyr,led0 = &green_led_1;
zephyr,sw0 = &user_button;
zephyr,spi = &spi3;
zephyr,serial = &uart2
};
Using these aliases (and their generated #define) directly in samples/tests would help to
make tests generic without too much trouble. I've set this approach in practice in PR
#5381 [RFC] Add gpio nodes to stm32 based soc/boards [1]
I also have a short coming work using aliases and addressing:
#6017 Enable easy use of shields with overlays [2]

Best Regards
Erwan

[1] https://github.com/zephyrproject-rtos/zephyr/pull/5381
[2] https://github.com/zephyrproject-rtos/zephyr/issues/6017


Shave Zephyr boards with Occam's razor

Erwan Gouriou
 

TL;DR: Numquam ponenda est pluralitas sine necessitate
           (approx: define guidelines for default board configuration)

Hi,

Most of the boards supported in Zephyr tree could be configured in quite multiple ways,
either for pins configuration, hardware interfaces, instances of these interfaces and
then configuration of the drivers for each of these entities.
When porting a board and pushing it upstream, one will either copy configuration from
a similar board, either configure the board according to his constraints or interesting
new ideas.
Outcome is a great heterogeneity of configurations and discussions during reviews.
Besides, these various configurations don't make things easy when one try to enable
tests/samples running on multiple boards.

I propose to shave away board configuration multiplicity and promote few guidelines
defining default (in tree) board configurations:

a) When a connector (arduino, 96board, ....) is present, configure pins to fit this connector
b) Configure ips matching these pins (For instance configure SPI instance for arduino SPI)
c) Enable board valuable HW and connectors (Button, Led, Sensors, USB, BT chip, Wifi,
    Ethernet, VCP, )
d) Configure an output for console
e) Propose and configure a default network interface
f) Enable all GPIO ports
g) Provide device tree Zephyr aliases

These guidelines won't avoid discussions since some for these points will conflict for
some boards. Also, some points deserve clarification (configuration means configured
only or configured and enabled?).


g) introduces zephyr aliases and could be seen a separated topic:
Some are already used today, as a tacit rule, also known as LED0, SW0. I propose to
extend these to other components (SPI, I2C, .) and define them in board device tree file.
For instance:
       aliases {
                   zephyr,led0 = &green_led_1;
                   zephyr,sw0 = &user_button;
                   zephyr,spi = &spi3;
                   zephyr,serial = &uart2
       };
Using these aliases (and their generated #define) directly in samples/tests would help to
make tests generic without too much trouble. I've set this approach in practice in PR
#5381 [RFC] Add gpio nodes to stm32 based soc/boards [1]
I also have a short coming work using aliases and addressing:
#6017 Enable easy use of shields with overlays [2]

Best Regards


Re: Runtime "configuration" system naming

Carles Cufi
 

Thanks all for the feedback.

 

We seem to have a slim consensus on “settings” so I will go for that.

 

Regards,

 

Carles

 

From: Nashif, Anas <anas.nashif@...>
Sent: 27 March 2018 17:45
To: Cufi, Carles <Carles.Cufi@...>; Erwan Gouriou <erwan.gouriou@...>; Jukka Rissanen <jukka.rissanen@...>
Cc: devel@...
Subject: RE: [Zephyr-devel] Runtime "configuration" system naming

 

I like settings. Do not thing it is long, sett just makes it ugly.

 

Anas

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Cufi, Carles
Sent: Tuesday, March 27, 2018 11:41 AM
To: Erwan Gouriou <erwan.gouriou@...>; Jukka Rissanen <jukka.rissanen@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] Runtime "configuration" system naming

 

The advantage of “settings” is that it matches what other people mean by those:

 

https://support.apple.com/en-us/HT201274

 

The disadvantage is that it is a bit long J “sett_” perhaps as a prefix?

 

From: Erwan Gouriou <erwan.gouriou@...>
Sent: 27 March 2018 17:32
To: Jukka Rissanen <jukka.rissanen@...>
Cc: Cufi, Carles <Carles.Cufi@...>; devel@...
Subject: Re: [Zephyr-devel] Runtime "configuration" system naming

 

I actually like "settings",

I find it carries well the idea of run time configuration

 

On 27 March 2018 at 17:21, Jukka Rissanen <jukka.rissanen@...> wrote:

Hi Carles,

as this seems to be about configuration settings, why not

settings
cfgdb

or something like that. Why do we need to mention the serialization at
all in the function names, that sounds like implementation detail.


Cheers,
Jukka




On Tue, 2018-03-27 at 15:29 +0200, Erwan Gouriou wrote:
> Hi Carles,
>
> Serialization is also sometime called marshalling, so an alternative
> could be "marshal"/"cfg_marshal"/"rtcfg_marshal"
>
> Cheers
> Erwan
>
> On 27 March 2018 at 14:51, Cufi, Carles <Carles.Cufi@...>
> wrote:
> > Hi all,
> >
> > Andrzej from Nordic has just ported the *run-time* configuration
> > system from Mynewt into Zephyr [1].
> > This is essentially a system-wide way of loading and storing all
> > state from and to non-volatile memory (i.e. flash) in a completely
> > centralized way.
> >
> > Since it serializes the data before storing it (and deserializes it
> > after loading), and we already use the word "config" for *compile-
> > time* configuration, we have currently renamed it to "s11n" (for
> > serialization).
> >
> > But some people find this name confusing, so I am now addressing a
> > wider audience for feedback.
> >
> > The currently proposed names are:
> >
> > * s11n
> > * syscfg
> >
> > Any preferences or alternatives?
> >
> > Thanks,
> >
> > Carles
> >
> > [1] https://github.com/zephyrproject-rtos/zephyr/pull/6408
> >
> >
> > _______________________________________________
> > Zephyr-devel mailing list
> > Zephyr-devel@...
> > https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
>
> _______________________________________________
> Zephyr-devel mailing list
> Zephyr-devel@...
> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 


LittlevGL - Open-source Embedded GUI Library

Jan Van Winkel
 

Hi All,

A couple of hours ago I issued a pull request [1] introducing a new external library providing a framework to create GUIs.

While doing so I encountered some issues:

1) The library is licensed under a MIT license
     According to the contributing guidelines a README needs to be provided in the PR for review by TSC.
     This readme can be found ext/lib/gui/lvgl/README [2] and this the main reason for isueing the PR

2) The PR contains a lot of dependencies on other PRs and to make sure that the PR is functional I needed to include all of them + some additional fixes.
     What is the normal approach here send the PR with all dependencies included, only the changes of PR or wait until the other PRs make it to master?

3) The real question, should a library as this be included in Zephyr?
     The reason I toke up the work is that it was request in issue #6709 [3] and I could use it my self.
     Now if I look back at it there is no easy way to make a common interface for such a library.
     Any opinions on this?

Best Regards,
Jan


Re: Runtime "configuration" system naming

Nashif, Anas
 

I like settings. Do not thing it is long, sett just makes it ugly.

 

Anas

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Cufi, Carles
Sent: Tuesday, March 27, 2018 11:41 AM
To: Erwan Gouriou <erwan.gouriou@...>; Jukka Rissanen <jukka.rissanen@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] Runtime "configuration" system naming

 

The advantage of “settings” is that it matches what other people mean by those:

 

https://support.apple.com/en-us/HT201274

 

The disadvantage is that it is a bit long J “sett_” perhaps as a prefix?

 

From: Erwan Gouriou <erwan.gouriou@...>
Sent: 27 March 2018 17:32
To: Jukka Rissanen <jukka.rissanen@...>
Cc: Cufi, Carles <Carles.Cufi@...>; devel@...
Subject: Re: [Zephyr-devel] Runtime "configuration" system naming

 

I actually like "settings",

I find it carries well the idea of run time configuration

 

On 27 March 2018 at 17:21, Jukka Rissanen <jukka.rissanen@...> wrote:

Hi Carles,

as this seems to be about configuration settings, why not

settings
cfgdb

or something like that. Why do we need to mention the serialization at
all in the function names, that sounds like implementation detail.


Cheers,
Jukka




On Tue, 2018-03-27 at 15:29 +0200, Erwan Gouriou wrote:
> Hi Carles,
>
> Serialization is also sometime called marshalling, so an alternative
> could be "marshal"/"cfg_marshal"/"rtcfg_marshal"
>
> Cheers
> Erwan
>
> On 27 March 2018 at 14:51, Cufi, Carles <Carles.Cufi@...>
> wrote:
> > Hi all,
> >
> > Andrzej from Nordic has just ported the *run-time* configuration
> > system from Mynewt into Zephyr [1].
> > This is essentially a system-wide way of loading and storing all
> > state from and to non-volatile memory (i.e. flash) in a completely
> > centralized way.
> >
> > Since it serializes the data before storing it (and deserializes it
> > after loading), and we already use the word "config" for *compile-
> > time* configuration, we have currently renamed it to "s11n" (for
> > serialization).
> >
> > But some people find this name confusing, so I am now addressing a
> > wider audience for feedback.
> >
> > The currently proposed names are:
> >
> > * s11n
> > * syscfg
> >
> > Any preferences or alternatives?
> >
> > Thanks,
> >
> > Carles
> >
> > [1] https://github.com/zephyrproject-rtos/zephyr/pull/6408
> >
> >
> > _______________________________________________
> > Zephyr-devel mailing list
> > Zephyr-devel@...
> > https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
>
> _______________________________________________
> Zephyr-devel mailing list
> Zephyr-devel@...
> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 


Re: Runtime "configuration" system naming

Carles Cufi
 

The advantage of “settings” is that it matches what other people mean by those:

 

https://support.apple.com/en-us/HT201274

 

The disadvantage is that it is a bit long J “sett_” perhaps as a prefix?

 

From: Erwan Gouriou <erwan.gouriou@...>
Sent: 27 March 2018 17:32
To: Jukka Rissanen <jukka.rissanen@...>
Cc: Cufi, Carles <Carles.Cufi@...>; devel@...
Subject: Re: [Zephyr-devel] Runtime "configuration" system naming

 

I actually like "settings",

I find it carries well the idea of run time configuration

 

On 27 March 2018 at 17:21, Jukka Rissanen <jukka.rissanen@...> wrote:

Hi Carles,

as this seems to be about configuration settings, why not

settings
cfgdb

or something like that. Why do we need to mention the serialization at
all in the function names, that sounds like implementation detail.


Cheers,
Jukka




On Tue, 2018-03-27 at 15:29 +0200, Erwan Gouriou wrote:
> Hi Carles,
>
> Serialization is also sometime called marshalling, so an alternative
> could be "marshal"/"cfg_marshal"/"rtcfg_marshal"
>
> Cheers
> Erwan
>
> On 27 March 2018 at 14:51, Cufi, Carles <Carles.Cufi@...>
> wrote:
> > Hi all,
> >
> > Andrzej from Nordic has just ported the *run-time* configuration
> > system from Mynewt into Zephyr [1].
> > This is essentially a system-wide way of loading and storing all
> > state from and to non-volatile memory (i.e. flash) in a completely
> > centralized way.
> >
> > Since it serializes the data before storing it (and deserializes it
> > after loading), and we already use the word "config" for *compile-
> > time* configuration, we have currently renamed it to "s11n" (for
> > serialization).
> >
> > But some people find this name confusing, so I am now addressing a
> > wider audience for feedback.
> >
> > The currently proposed names are:
> >
> > * s11n
> > * syscfg
> >
> > Any preferences or alternatives?
> >
> > Thanks,
> >
> > Carles
> >
> > [1] https://github.com/zephyrproject-rtos/zephyr/pull/6408
> >
> >
> > _______________________________________________
> > Zephyr-devel mailing list
> > Zephyr-devel@...
> > https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
>
> _______________________________________________
> Zephyr-devel mailing list
> Zephyr-devel@...
> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 


Re: Runtime "configuration" system naming

Erwan Gouriou
 

I actually like "settings",
I find it carries well the idea of run time configuration

On 27 March 2018 at 17:21, Jukka Rissanen <jukka.rissanen@...> wrote:
Hi Carles,

as this seems to be about configuration settings, why not

settings
cfgdb

or something like that. Why do we need to mention the serialization at
all in the function names, that sounds like implementation detail.


Cheers,
Jukka



On Tue, 2018-03-27 at 15:29 +0200, Erwan Gouriou wrote:
> Hi Carles,
>
> Serialization is also sometime called marshalling, so an alternative
> could be "marshal"/"cfg_marshal"/"rtcfg_marshal"
>
> Cheers
> Erwan
>
> On 27 March 2018 at 14:51, Cufi, Carles <Carles.Cufi@...>
> wrote:
> > Hi all,
> >
> > Andrzej from Nordic has just ported the *run-time* configuration
> > system from Mynewt into Zephyr [1].
> > This is essentially a system-wide way of loading and storing all
> > state from and to non-volatile memory (i.e. flash) in a completely
> > centralized way.
> >
> > Since it serializes the data before storing it (and deserializes it
> > after loading), and we already use the word "config" for *compile-
> > time* configuration, we have currently renamed it to "s11n" (for
> > serialization).
> >
> > But some people find this name confusing, so I am now addressing a
> > wider audience for feedback.
> >
> > The currently proposed names are:
> >
> > * s11n
> > * syscfg
> >
> > Any preferences or alternatives?
> >
> > Thanks,
> >
> > Carles
> >
> > [1] https://github.com/zephyrproject-rtos/zephyr/pull/6408
> >
> >
> > _______________________________________________
> > Zephyr-devel mailing list
> > Zephyr-devel@lists.zephyrproject.org
> > 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: Runtime "configuration" system naming

Carles Cufi
 

Hi Sterling,

Thanks for the feedback.

-----Original Message-----
From: Sterling Hughes <sterling@runtime.io>
Sent: 27 March 2018 17:24
To: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Cc: Erwan Gouriou <erwan.gouriou@linaro.org>; Cufi, Carles
<Carles.Cufi@nordicsemi.no>; devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Runtime "configuration" system naming

I like syscfg mentioned below.
Me too actually, it's growing on me and it matches the original Mynewt name relatively closely as well as describing the functionality well.
The only drawback is that it contains "cfg" which stands for "configuration" and therefore somehow collides with our Kconfig as mentioned in my original email.

Regards,

Carles


Re: Runtime "configuration" system naming

Carles Cufi
 

Hi Jukka,

Thanks for the feedback.

-----Original Message-----
From: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Sent: 27 March 2018 17:22
To: Erwan Gouriou <erwan.gouriou@linaro.org>; Cufi, Carles
<Carles.Cufi@nordicsemi.no>
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Runtime "configuration" system naming

Hi Carles,

as this seems to be about configuration settings, why not

settings
cfgdb
I like cfgdb, even though there is no real "database" involved. Perhaps "syscfg" is a bit more neutral though in the sense that it's a "system-wide configuration" of the device without actually explicitly naming any storage backend (database) or mechanism (serialization).

Carles


Re: Runtime "configuration" system naming

Sterling Hughes <sterling@...>
 

I like syscfg mentioned below.

On 27 Mar 2018, at 8:21, Jukka Rissanen wrote:

Hi Carles,

as this seems to be about configuration settings, why not

settings
cfgdb

or something like that. Why do we need to mention the serialization at
all in the function names, that sounds like implementation detail.


Cheers,
Jukka



On Tue, 2018-03-27 at 15:29 +0200, Erwan Gouriou wrote:
Hi Carles,

Serialization is also sometime called marshalling, so an alternative
could be "marshal"/"cfg_marshal"/"rtcfg_marshal"

Cheers
Erwan

On 27 March 2018 at 14:51, Cufi, Carles <Carles.Cufi@nordicsemi.no>
wrote:
Hi all,

Andrzej from Nordic has just ported the *run-time* configuration
system from Mynewt into Zephyr [1].
This is essentially a system-wide way of loading and storing all
state from and to non-volatile memory (i.e. flash) in a completely
centralized way.

Since it serializes the data before storing it (and deserializes it
after loading), and we already use the word "config" for *compile-
time* configuration, we have currently renamed it to "s11n" (for
serialization).

But some people find this name confusing, so I am now addressing a
wider audience for feedback.

The currently proposed names are:

* s11n
* syscfg

Any preferences or alternatives?

Thanks,

Carles

[1] https://github.com/zephyrproject-rtos/zephyr/pull/6408


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


Re: Runtime "configuration" system naming

Carles Cufi
 

Hi Erwan,

 

Thanks for the feedback.

 

I did think about using “marshalling”, but I thought it was less common than “serialization” so I went for the “s11n” abbreviation.

I would really like to keep it short if possible J

 

Carles

 

From: Erwan Gouriou <erwan.gouriou@...>
Sent: 27 March 2018 15:30
To: Cufi, Carles <Carles.Cufi@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] Runtime "configuration" system naming

 

Hi Carles,

Serialization is also sometime called marshalling, so an alternative could be "marshal"/"cfg_marshal"/"rtcfg_marshal"

 

Cheers

Erwan

 

On 27 March 2018 at 14:51, Cufi, Carles <Carles.Cufi@...> wrote:

Hi all,

Andrzej from Nordic has just ported the *run-time* configuration system from Mynewt into Zephyr [1].
This is essentially a system-wide way of loading and storing all state from and to non-volatile memory (i.e. flash) in a completely centralized way.

Since it serializes the data before storing it (and deserializes it after loading), and we already use the word "config" for *compile-time* configuration, we have currently renamed it to "s11n" (for serialization).

But some people find this name confusing, so I am now addressing a wider audience for feedback.

The currently proposed names are:

* s11n
* syscfg

Any preferences or alternatives?

Thanks,

Carles

[1] https://github.com/zephyrproject-rtos/zephyr/pull/6408


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

 


Re: Runtime "configuration" system naming

Jukka Rissanen
 

Hi Carles,

as this seems to be about configuration settings, why not

settings
cfgdb

or something like that. Why do we need to mention the serialization at
all in the function names, that sounds like implementation detail.


Cheers,
Jukka

On Tue, 2018-03-27 at 15:29 +0200, Erwan Gouriou wrote:
Hi Carles,

Serialization is also sometime called marshalling, so an alternative
could be "marshal"/"cfg_marshal"/"rtcfg_marshal"

Cheers
Erwan

On 27 March 2018 at 14:51, Cufi, Carles <Carles.Cufi@nordicsemi.no>
wrote:
Hi all,

Andrzej from Nordic has just ported the *run-time* configuration
system from Mynewt into Zephyr [1].
This is essentially a system-wide way of loading and storing all
state from and to non-volatile memory (i.e. flash) in a completely
centralized way.

Since it serializes the data before storing it (and deserializes it
after loading), and we already use the word "config" for *compile-
time* configuration, we have currently renamed it to "s11n" (for
serialization).

But some people find this name confusing, so I am now addressing a
wider audience for feedback.

The currently proposed names are:

* s11n
* syscfg

Any preferences or alternatives?

Thanks,

Carles

[1] https://github.com/zephyrproject-rtos/zephyr/pull/6408


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
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: Runtime "configuration" system naming

Erwan Gouriou
 

Hi Carles,

Serialization is also sometime called marshalling, so an alternative could be "marshal"/"cfg_marshal"/"rtcfg_marshal"

Cheers
Erwan

On 27 March 2018 at 14:51, Cufi, Carles <Carles.Cufi@...> wrote:
Hi all,

Andrzej from Nordic has just ported the *run-time* configuration system from Mynewt into Zephyr [1].
This is essentially a system-wide way of loading and storing all state from and to non-volatile memory (i.e. flash) in a completely centralized way.

Since it serializes the data before storing it (and deserializes it after loading), and we already use the word "config" for *compile-time* configuration, we have currently renamed it to "s11n" (for serialization).

But some people find this name confusing, so I am now addressing a wider audience for feedback.

The currently proposed names are:

* s11n
* syscfg

Any preferences or alternatives?

Thanks,

Carles

[1] https://github.com/zephyrproject-rtos/zephyr/pull/6408


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


Runtime "configuration" system naming

Carles Cufi
 

Hi all,

Andrzej from Nordic has just ported the *run-time* configuration system from Mynewt into Zephyr [1].
This is essentially a system-wide way of loading and storing all state from and to non-volatile memory (i.e. flash) in a completely centralized way.

Since it serializes the data before storing it (and deserializes it after loading), and we already use the word "config" for *compile-time* configuration, we have currently renamed it to "s11n" (for serialization).

But some people find this name confusing, so I am now addressing a wider audience for feedback.

The currently proposed names are:

* s11n
* syscfg

Any preferences or alternatives?

Thanks,

Carles

[1] https://github.com/zephyrproject-rtos/zephyr/pull/6408

3681 - 3700 of 8041