[RFC] Mezzanine/Hat/Extension/Shield board support


Neil Armstrong
 

Hi,

Most of the board supported by zephyr can use extension boards via the Arduino or ST Morpho connectors for example,
but there is no simple way to explicit support for these in the Zephyr codebase.

Would it be possible to add a boards/ext tree with Kconfig, docs and config parameters for each supported boards ?

For example for the X-NUCLEO-IKS01A1 board, it will concern all board with Arduino Uno R3 connector,
but a cfg for each supported board should be supplied :

boards/
ext/
x-nucleo-iks01a1/
Kconfig.ext
Kconfig.defconfig
ext.h
Makefile
x_nucleo_iks01a1.nucleo_f103rb_defconfig
x_nucleo_iks01a1.nucleo_f334r8_defconfig
x_nucleo_iks01a1.nucleo_f401re_defconfig
x_nucleo_iks01a1.nucleo_l476rg_defconfig
doc/
x_nucleo_iks01a1.rst


And for build options, a new options along BOARD= could be supplied, like SHIELD= or EXTBOARD=.

Waiting for some advices !

Neil
--
Neil Armstrong
Embedded Linux Software Engineer
BayLibre - At the Heart of Embedded Linux
www.baylibre.com


Nashif, Anas
 

Hi Neil,
I think this is a great idea to support another layer for shields and extensions on top of existing boards. This will also allow usage for custom test shields that can specified for testcases, i.e. to test IOs and peripherals. Not sure about the naming and structure yet and if it should go under boards, but you get a +1 from me on the general idea.

Thanks,
Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Neil Armstrong
Sent: Thursday, June 1, 2017 11:06 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] [RFC] Mezzanine/Hat/Extension/Shield board support

Hi,

Most of the board supported by zephyr can use extension boards via the Arduino or ST Morpho connectors for example, but there is no simple way to explicit support for these in the Zephyr codebase.

Would it be possible to add a boards/ext tree with Kconfig, docs and config parameters for each supported boards ?

For example for the X-NUCLEO-IKS01A1 board, it will concern all board with Arduino Uno R3 connector, but a cfg for each supported board should be supplied :

boards/
ext/
x-nucleo-iks01a1/
Kconfig.ext
Kconfig.defconfig
ext.h
Makefile
x_nucleo_iks01a1.nucleo_f103rb_defconfig
x_nucleo_iks01a1.nucleo_f334r8_defconfig
x_nucleo_iks01a1.nucleo_f401re_defconfig
x_nucleo_iks01a1.nucleo_l476rg_defconfig
doc/
x_nucleo_iks01a1.rst


And for build options, a new options along BOARD= could be supplied, like SHIELD= or EXTBOARD=.

Waiting for some advices !

Neil
--
Neil Armstrong
Embedded Linux Software Engineer
BayLibre - At the Heart of Embedded Linux www.baylibre.com _______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Erwan Gouriou
 

Hi Neil,

+1 for me too. This would really be handy in long range.

Obviously, one point to solve is how to deal with pinmuxing. I see at least 3 options:
a) Keep board independant pinmuxing, and up to each board to present pinmuxing(s)
compatible with required shield(s)
b) Define generic pinmuxing profiles(arduino_pinmux for instance). Then boards and
shields would include these profiles (when compatible)
c) Shield activation (with EXTBOARD=..) would configure board pinmux on the fly

In any case, boards should provide a "compatible" field at some point to document
the supported shields (or pinmux profiles).


Erwan

On 1 June 2017 at 22:41, Nashif, Anas <anas.nashif@...> wrote:
Hi Neil,
I think this is a great idea to support another layer for shields and extensions on top of existing boards. This will also allow usage for custom test shields that can specified for testcases, i.e. to test IOs and peripherals.  Not sure about the naming and structure yet and if it should go under boards, but you get a +1 from me on the general idea.

Thanks,
Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Neil Armstrong
Sent: Thursday, June 1, 2017 11:06 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] [RFC] Mezzanine/Hat/Extension/Shield board support

Hi,

Most of the board supported by zephyr can use extension boards via the Arduino or ST Morpho connectors for example, but there is no simple way to explicit support for these in the Zephyr codebase.

Would it be possible to add a boards/ext tree with Kconfig, docs and config parameters for each supported boards ?

For example for the X-NUCLEO-IKS01A1 board, it will concern all board with Arduino Uno R3 connector, but a cfg for each supported board should be supplied :

boards/
      ext/
         x-nucleo-iks01a1/
                          Kconfig.ext
                          Kconfig.defconfig
                          ext.h
                          Makefile
                          x_nucleo_iks01a1.nucleo_f103rb_defconfig
                          x_nucleo_iks01a1.nucleo_f334r8_defconfig
                          x_nucleo_iks01a1.nucleo_f401re_defconfig
                          x_nucleo_iks01a1.nucleo_l476rg_defconfig
                          doc/
                              x_nucleo_iks01a1.rst


And for build options, a new options along BOARD= could be supplied, like SHIELD= or EXTBOARD=.

Waiting for some advices !

Neil
--
Neil Armstrong
Embedded Linux Software Engineer
BayLibre - At the Heart of Embedded Linux www.baylibre.com _______________________________________________
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


Andy Gross
 

+1


On 2 June 2017 at 04:02, Erwan Gouriou <erwan.gouriou@linaro.org> wrote:
Hi Neil,

+1 for me too. This would really be handy in long range.

Obviously, one point to solve is how to deal with pinmuxing. I see at least
3 options:
a) Keep board independant pinmuxing, and up to each board to present
pinmuxing(s)
compatible with required shield(s)
b) Define generic pinmuxing profiles(arduino_pinmux for instance). Then
boards and
shields would include these profiles (when compatible)
c) Shield activation (with EXTBOARD=..) would configure board pinmux on the
fly
d) Use DTS overlays. If this requires multiple overlays, we can
extend that to provide the feature.


In any case, boards should provide a "compatible" field at some point to
document
the supported shields (or pinmux profiles).


Erwan

On 1 June 2017 at 22:41, Nashif, Anas <anas.nashif@intel.com> wrote:

Hi Neil,
I think this is a great idea to support another layer for shields and
extensions on top of existing boards. This will also allow usage for custom
test shields that can specified for testcases, i.e. to test IOs and
peripherals. Not sure about the naming and structure yet and if it should
go under boards, but you get a +1 from me on the general idea.

Thanks,
Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org
[mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Neil
Armstrong
Sent: Thursday, June 1, 2017 11:06 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] [RFC] Mezzanine/Hat/Extension/Shield board support

Hi,

Most of the board supported by zephyr can use extension boards via the
Arduino or ST Morpho connectors for example, but there is no simple way to
explicit support for these in the Zephyr codebase.

Would it be possible to add a boards/ext tree with Kconfig, docs and
config parameters for each supported boards ?

For example for the X-NUCLEO-IKS01A1 board, it will concern all board with
Arduino Uno R3 connector, but a cfg for each supported board should be
supplied :

boards/
ext/
x-nucleo-iks01a1/
Kconfig.ext
Kconfig.defconfig
ext.h
Makefile
x_nucleo_iks01a1.nucleo_f103rb_defconfig
x_nucleo_iks01a1.nucleo_f334r8_defconfig
x_nucleo_iks01a1.nucleo_f401re_defconfig
x_nucleo_iks01a1.nucleo_l476rg_defconfig
doc/
x_nucleo_iks01a1.rst


And for build options, a new options along BOARD= could be supplied, like
SHIELD= or EXTBOARD=.

Waiting for some advices !

Neil
--
Neil Armstrong
Embedded Linux Software Engineer
BayLibre - At the Heart of Embedded Linux www.baylibre.com
_______________________________________________
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


Neil Armstrong
 

Hi Andy, Erwan, Anas,
On 06/02/2017 03:00 PM, Andy Gross wrote:
+1


On 2 June 2017 at 04:02, Erwan Gouriou <erwan.gouriou@linaro.org> wrote:
Hi Neil,

+1 for me too. This would really be handy in long range.

Obviously, one point to solve is how to deal with pinmuxing. I see at least
3 options:
a) Keep board independant pinmuxing, and up to each board to present
pinmuxing(s)
compatible with required shield(s)
b) Define generic pinmuxing profiles(arduino_pinmux for instance). Then
boards and
shields would include these profiles (when compatible)
c) Shield activation (with EXTBOARD=..) would configure board pinmux on the
fly
d) Use DTS overlays. If this requires multiple overlays, we can
extend that to provide the feature.


In any case, boards should provide a "compatible" field at some point to
document
the supported shields (or pinmux profiles).


Erwan

On 1 June 2017 at 22:41, Nashif, Anas <anas.nashif@intel.com> wrote:

Hi Neil,
I think this is a great idea to support another layer for shields and
extensions on top of existing boards. This will also allow usage for custom
test shields that can specified for testcases, i.e. to test IOs and
peripherals. Not sure about the naming and structure yet and if it should
go under boards, but you get a +1 from me on the general idea.
I will send an RFC when I have some free time for it and thanks for the hints.

Neil


Thanks,
Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org
[mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Neil
Armstrong
Sent: Thursday, June 1, 2017 11:06 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] [RFC] Mezzanine/Hat/Extension/Shield board support

Hi,

Most of the board supported by zephyr can use extension boards via the
Arduino or ST Morpho connectors for example, but there is no simple way to
explicit support for these in the Zephyr codebase.

Would it be possible to add a boards/ext tree with Kconfig, docs and
config parameters for each supported boards ?

For example for the X-NUCLEO-IKS01A1 board, it will concern all board with
Arduino Uno R3 connector, but a cfg for each supported board should be
supplied :

boards/
ext/
x-nucleo-iks01a1/
Kconfig.ext
Kconfig.defconfig
ext.h
Makefile
x_nucleo_iks01a1.nucleo_f103rb_defconfig
x_nucleo_iks01a1.nucleo_f334r8_defconfig
x_nucleo_iks01a1.nucleo_f401re_defconfig
x_nucleo_iks01a1.nucleo_l476rg_defconfig
doc/
x_nucleo_iks01a1.rst


And for build options, a new options along BOARD= could be supplied, like
SHIELD= or EXTBOARD=.

Waiting for some advices !

Neil
--
Neil Armstrong
Embedded Linux Software Engineer
BayLibre - At the Heart of Embedded Linux www.baylibre.com
_______________________________________________
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
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel