Date   

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


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

3561 - 3580 of 7936