Date   

QEMU and bridged networking

David Brown
 

When I use qemu with Linux, one of the network configurations I can
use is bridged, which makes the emulated platform appear as its own
device on my network. This allows things such dhcpc to work as it
would on a standalone device on my network.

With Zephyr, since we're doing the networking through a slip interface
over a simulated uart, the automated qemu bridge networking doesn't
work.

Has anyone successfully enabled qemu_x86 with a network configuration
that bridged the device to the hosts network interface.

What I've tried so far is:

- Changed my systemd network configuration to create br0 as a bridge
interface.

- Set my ethernet devices to master to br0

- Run dhcp on br0 instead of the ethernet device (maybe this is an
error).

- After starting up loop-slip-tap.sh, set tap0 to master to br0.

Running the dhcpv4_client app doesn't ever find an address. I can
next try to hard-code an IP address and see if TCP will get through.

Thanks,
David


LLVM Support (Pre 1.12 PR)

jshafer4@...
 

All,

I am interested in analyzing Zephyr symbolically using KLEE, which requires LLVM bitcode.

Prior to the 1.12 PR, is this possible via undocumented support for LLVM/Clang in 1.11 PR, or some development branch?

Thanks.


Re: OpenThread support on Zephyr

Carles Cufi
 

Hi Marcio,

 

I recommend you start by building the echo_client and echo_server projects for the nrf52840_pca10056 board using prj_nrf52840_ot.conf.

That will get you an echo client and server that communicate over Thread.

 

The code for OpenThread will be pulled by CMake when you trigger the build.

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Marcio Montenegro
Sent: 05 April 2018 14:42
To: devel@...
Subject: [Zephyr-devel] OpenThread support on Zephyr

 

Hi all,
Please share technical details about this topic.
Thanks in advance

https://www.zephyrproject.org/zephyr-project-announces-openthread-first-thread-protocol-implementation-integrate-zephyr-rtos/


OpenThread support on Zephyr

Marcio Montenegro
 

Hi all,
Please share technical details about this topic.
Thanks in advance

https://www.zephyrproject.org/zephyr-project-announces-openthread-first-thread-protocol-implementation-integrate-zephyr-rtos/


mimxrt1050_EVK sdram support

Lukasz Grzymkowski
 

Hello,

 

I’m working on a project that uses Zephyr on mimxrt1050_evk with GUI on the LCD display. To allocate framebuffers I obviously need more memory than SRAM provides, and so I’ve added support for the external SDRAM.

 

I’m wondering if there is actually any on-going work to add SDRAM support for this board, so I don’t necessarily reinvent the wheel, or if there is actually any interest in adding support for it to Zephyr?

 

Best regards,

Lukasz

 


Re: Implement SPI on a STM32f7

Tomasz Bursztyka
 

Hi Clemence,

SPI is supported on stm32f4 SoCs, the doc is probably not up to date.

Maybe it's just not enabled on the board's dts file.
But on SoC level it is, see dts/arm/st/stm32f407.dtsi which includes
dts/arm/st/stm32f405.dtsi including itself: dts/arm/st/stm32f401.dtsi

Tomasz

Hello,

I am trying to implement SPI on the STM32f4 discovery (STM32f407).

On the doc of Zephyr, it is written the list of the hardware
features
supported by the board STM32f4 discovery (NVIC, UART, PINMUX, GPIO
aand
PWM) and SPI is not in this list.

I have already changed some files to add the SPI:

- $ENV{ZEPHYR_BASE}/boards/arm/pinmux.c

- $ENV{ZEPHYR_BASE}/boards/arm/stm32f4_disco.dts

- $ENV{ZEPHYR_BASE}/boards/arm/stm32f4_disco.yaml

- $ENV{ZEPHYR_BASE}/boards/arm/Kconfig.defconfig

- $ENV{ZEPHYR_BASE}/dts/arm/st/stm32f4-pinctrl.dtsi

- $ENV{ZEPHYR_BASE}/arch/arm/soc/st_stm32/stm32f4/soc.h

- prj.conf


I would like to know what I need to modify or add to implement SPI
for
the STM32f4 discovery please ?


Thanks,

Clemence


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


Re: NRF54280 coded phy

Carles Cufi
 

Hi there,

 

You can use coded phy today in connections, but not really during advertising and scanning because that requires Advertising Extensions to be implemented.

We are currently making architectural changes to the BLE Controller to, among other things, pave the way for Advertising Extensions. Those changes should come very soon to master, and later on we will consider implementing AE, but we can’t give you a fixed timeline for that. Once the architectural changes are merged you are more than welcome to contribute AE features.

 

Regards,

 

Carles

 

From: zephyr-devel-bounces@... <zephyr-devel-bounces@...> On Behalf Of deadpool code
Sent: 04 April 2018 05:20
To: zephyr-devel@...
Subject: [Zephyr-devel] NRF54280 coded phy

 

Hello

 

I would like to use coded phy both in sending the data and in broadcasting 

 

when is it expected to be supported?

 

thank you 


Implement SPI on a STM32f7

clemence
 

Hello,

I am trying to implement SPI on the STM32f4 discovery (STM32f407).

On the doc of Zephyr, it is written the list of the hardware features supported by the board STM32f4 discovery (NVIC, UART, PINMUX, GPIO aand PWM) and SPI is not in this list.

I have already changed some files to add the SPI:

- $ENV{ZEPHYR_BASE}/boards/arm/pinmux.c

- $ENV{ZEPHYR_BASE}/boards/arm/stm32f4_disco.dts

- $ENV{ZEPHYR_BASE}/boards/arm/stm32f4_disco.yaml

- $ENV{ZEPHYR_BASE}/boards/arm/Kconfig.defconfig

- $ENV{ZEPHYR_BASE}/dts/arm/st/stm32f4-pinctrl.dtsi

- $ENV{ZEPHYR_BASE}/arch/arm/soc/st_stm32/stm32f4/soc.h

- prj.conf


I would like to know what I need to modify or add to implement SPI for the STM32f4 discovery please ?


Thanks,

Clemence


Re: /zephyr/samples/drivers/i2c_fujitsu_fram not being compiled

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hi,

As I can see in the i2c_nrf5.c and Kconfig.nrf5, the configuration that needs to be done is still NRF5 and CONFIG_I2C_NRF5_0_GPIO_SDA_PIN. If Nordic fellows change nomenclature, they should have compiled their drivers at least once. Also, I'm using a stable commit of zephyr. 


--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


On Tue, Apr 3, 2018 at 12:13 PM, ashish.shukla@... <ashish.shukla@...> wrote:
Hello all,

I'm trying to compile /zephyr/samples/drivers/i2c_fujitsu_fram for interfacing an I2C device with nrf52840.

Edited prj.conf as following,

CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y

CONFIG_I2C=y

CONFIG_I2C_NRF5=y

CONFIG_I2C_0=y

CONFIG_I2C_NRF5_0_GPIO_SDA_PIN=26
CONFIG_I2C_NRF5_0_GPIO_SCL_PIN=27

now, it's producing a number of compilation errors. I'm attaching screen shot of the terminal for reference

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi



NRF54280 coded phy

deadpool code <deadpoolcode@...>
 

Hello

I would like to use coded phy both in sending the data and in broadcasting 

when is it expected to be supported?

thank you 


Re: ASSERT failure in USB HID

Johannes Hutter
 

I got hands on a nucleo-f411re and actually encounter the same issue. I also observed that the callback is set for the endpoints 0x00, 0x80 and 0x81 (the last one being the configured HID endpoint), but the enable function is only called for the first two. Does anyone have an idea what the issue is there?


On 29.03.2018 20:53, Yannis Damigos wrote:
Hi Joe,

I try USB HID sample on my 96b_carbon with ASSERTs enabled and it fails with a different error.

***** USAGE FAULT *****
  Executing thread ID (thread): 0x20000938
  Faulting instruction address:  0x8001e82
  Division by zero
Fatal fault in essential thread! Spinning...

I added developers mailing list to give greater visibility to the problem.

Yannis

On 03/29/2018 05:27 PM, Johannes Hutter wrote:
Hey Yannis,

first of all, thanks for the support on the Zephyr Mailing List the last weeks. I don't want to spam the list too much, that's why I'm writing you directly. If you prefer to keep the questions on the mailing list, I am happy to do that.


Now my question: The USB HID configuration works perfectly fine (I basically simulate a keyboard). But if I enable ASSERTs my program (and also the USB HID sample) fails during boot with following log:


[general] [DBG] HAL_PCD_ResetCallback:
[usb/hid] [DBG] hid_status_cb: USB device reset detected
[general] [DBG] HAL_PCD_SetupStageCallback:
[general] [DBG] usb_handle_control_transfer: usb_handle_control_transfer ep 0, status 0
[general] [DBG] usb_dc_ep_read_wait: ep 0x00, 8 bytes, 0+8, 0x20009bb4
[general] [DBG] usb_handle_request: ** 0 **
[usb/hid] [DBG] hid_custom_handle_req: Standard request: bRequest 0x6 bmRequestType 0x80 len 64
[general] [DBG] usb_handle_std_device_req: REQ_GET_DESCRIPTOR
[general] [DBG] usb_dc_ep_write: ep 0x80, len 18
[general] [DBG] usb_dc_ep_transfer: ep 0x80, len=18, in=1, sync=no
ASSERTION FAIL [!_IsInIsr()] @ /home/joe/code/proglove/embed/mark_one_s_firmware/lib/zephyr/kernel/sched.c:328:


Would you be so kind and try to run the sample on your boards with ASSERTs enabled? Just to find out whether the problem is on my custom board side or not.

Thanks a lot and best regards,

Joe


-- 

Johannes Hutter | Embedded Software Engineer
Mail: johannes@... <mailto:johannes@...>


	

Workaround GmbH (ProGlove)
Friedenstr. 4 | 81671 München

Managing Director: Thomas Kirchner
HRB: 216605 | AG München
USt.-IdNr.: DE298859320


    

--

Johannes Hutter | Embedded Software Engineer
Mail: johannes@...


Workaround GmbH (ProGlove)
Friedenstr. 4 | 81671 München

Managing Director: Thomas Kirchner
HRB: 216605 | AG München
USt.-IdNr.: DE298859320


Hardware PWM driver support for nrf52

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hello everyone,

There is software PWM driver for nrf52 series controllers, I need hardware PWM driver for the same.

Can I expect support for hardware PWM driver in upcoming time ? 

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


Re: /zephyr/samples/drivers/i2c_fujitsu_fram not being compiled

Serafin
 

Hi

Could be a lot of things but I assume the problem is that Nordic changed the naming scheme. It's now nrf and not nrf5 anymore. Pleayse make shure you are rebased obn a consistent commit either before that change (in that case you have a different problem). Or after that change than you have to change NRF5 to NRF.

Brest regards

Serafin


On 03/04/18 08:43, ashish.shukla@... wrote:
Hello all,

I'm trying to compile /zephyr/samples/drivers/i2c_fujitsu_fram for interfacing an I2C device with nrf52840.

Edited prj.conf as following,

CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y

CONFIG_I2C=y

CONFIG_I2C_NRF5=y

CONFIG_I2C_0=y

CONFIG_I2C_NRF5_0_GPIO_SDA_PIN=26
CONFIG_I2C_NRF5_0_GPIO_SCL_PIN=27

now, it's producing a number of compilation errors. I'm attaching screen shot of the terminal for reference

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi



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


/zephyr/samples/drivers/i2c_fujitsu_fram not being compiled

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hello all,

I'm trying to compile /zephyr/samples/drivers/i2c_fujitsu_fram for interfacing an I2C device with nrf52840.

Edited prj.conf as following,

CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y

CONFIG_I2C=y

CONFIG_I2C_NRF5=y

CONFIG_I2C_0=y

CONFIG_I2C_NRF5_0_GPIO_SDA_PIN=26
CONFIG_I2C_NRF5_0_GPIO_SCL_PIN=27

now, it's producing a number of compilation errors. I'm attaching screen shot of the terminal for reference

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


Struct data is erased for no apparent reason

christian tavares
 

Hello, 

I'm developing a http_client zephyr application where the server sends a json, that json is stored in a structure. 

But when I'm going to make a new request to the server, the struct data is erased .. for no apparent reason. 

Does anyone know how to solve it?


Re: #BluetoothMesh URI provisioning #bluetoothmesh

Johan Hedberg
 

Hi Vikrant,

On Fri, Mar 30, 2018, Vikrant More wrote:
Is Zephyr going to introduce feature so that beacon will broadcast URI for
unprovisioned #BluetoothMesh DEVICEs ?
This is already supported using the "const char *uri" member of struct
bt_mesh_prov.

Johan


#BluetoothMesh URI provisioning #bluetoothmesh

Vikrant More <vikrant8051@...>
 

Hi, 

Is Zephyr going to introduce feature so that beacon will broadcast URI for unprovisioned #BluetoothMesh DEVICEs ?

Or it is simply replacing DEVICE_NAME (means Zephyr ) to something like mentioned in #BluetoothMesh specification at 8.4.2 ( Beacon : 0070cf7c9732a345b691494810d2e9cbf44020d97478b3 ) ?

-------------------------------------------------------------------------------------------------------------
As per my understanding,

URI beacon = DEVICE's UUID + some part of Hash which is generated from "URI data" which is stored at URL 

URI data = ECDH public key of DEVICE ( which is common to all DEVICEs under particular category)

Am I right ?

--------------------------------------------------------------------------------------

Please throw some light on URI beacon based secure provisioning.

Thank You !!


Re: ASSERT failure in USB HID

Yannis Damigos
 

Hi Joe,

I try USB HID sample on my 96b_carbon with ASSERTs enabled and it fails with a different error.

***** USAGE FAULT *****
Executing thread ID (thread): 0x20000938
Faulting instruction address: 0x8001e82
Division by zero
Fatal fault in essential thread! Spinning...

I added developers mailing list to give greater visibility to the problem.

Yannis

On 03/29/2018 05:27 PM, Johannes Hutter wrote:
Hey Yannis,

first of all, thanks for the support on the Zephyr Mailing List the last weeks. I don't want to spam the list too much, that's why I'm writing you directly. If you prefer to keep the questions on the mailing list, I am happy to do that.


Now my question: The USB HID configuration works perfectly fine (I basically simulate a keyboard). But if I enable ASSERTs my program (and also the USB HID sample) fails during boot with following log:


[general] [DBG] HAL_PCD_ResetCallback:
[usb/hid] [DBG] hid_status_cb: USB device reset detected
[general] [DBG] HAL_PCD_SetupStageCallback:
[general] [DBG] usb_handle_control_transfer: usb_handle_control_transfer ep 0, status 0
[general] [DBG] usb_dc_ep_read_wait: ep 0x00, 8 bytes, 0+8, 0x20009bb4
[general] [DBG] usb_handle_request: ** 0 **
[usb/hid] [DBG] hid_custom_handle_req: Standard request: bRequest 0x6 bmRequestType 0x80 len 64
[general] [DBG] usb_handle_std_device_req: REQ_GET_DESCRIPTOR
[general] [DBG] usb_dc_ep_write: ep 0x80, len 18
[general] [DBG] usb_dc_ep_transfer: ep 0x80, len=18, in=1, sync=no
ASSERTION FAIL [!_IsInIsr()] @ /home/joe/code/proglove/embed/mark_one_s_firmware/lib/zephyr/kernel/sched.c:328:


Would you be so kind and try to run the sample on your boards with ASSERTs enabled? Just to find out whether the problem is on my custom board side or not.

Thanks a lot and best regards,

Joe


--

Johannes Hutter | Embedded Software Engineer
Mail: johannes@proglove.de <mailto:johannes@proglove.de>




Workaround GmbH (ProGlove)
Friedenstr. 4 | 81671 München

Managing Director: Thomas Kirchner
HRB: 216605 | AG München
USt.-IdNr.: DE298859320


Re: Shave Zephyr boards with Occam's razor

Erwan Gouriou
 

For those interested in board shaving: https://github.com/zephyrproject-rtos/zephyr/issues/6858

On 29 March 2018 at 17:04, Erwan Gouriou <erwan.gouriou@...> wrote:
Thanks for the feedbacks, I'll fill a GH Issue and try to get this progress

On 28 March 2018 at 14:13, Marti Bolivar <marti@...> wrote:


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@...hyrproject.org <zephyr-devel-bounces@...phyrproject.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

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



Re: Shave Zephyr boards with Occam's razor

Erwan Gouriou
 

Thanks for the feedbacks, I'll fill a GH Issue and try to get this progress

On 28 March 2018 at 14:13, Marti Bolivar <marti@...> wrote:


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@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

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

3661 - 3680 of 8041