Date   

Cancelled Event: Zephyr Project: APIs - Tuesday, 22 December 2020 #cal-cancelled

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Cancelled: Zephyr Project: APIs

This event has been cancelled.

When:
Tuesday, 22 December 2020
5:00pm to 6:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Re: Canopen node nRF52832

Alexander Wachter
 

Hi Cristian,

Macros prefixed with CONFIG_ come from Kconfig.
Never try to set them in your application.
CONFIG_CAN_MAX_FILTER=13 goes to your mcp2515.conf
The CAN_MAX_FILTER is used in the MCP2515 driver,
and if you set it in some of your files, it won't end up in the driver.

As Marti already mentioned, you also need to allow MPU flash writes.

Cheers,

Alex

On 09.12.20 11:54, Cristian Anceschi wrote:
Hi all
I'm quite new on Zephyr and on CAN BUS so my question might have an easy or obvious answer.
I'm on Ubuntu and I'm using an nRF52DK nRF52832 (PCA10040) wired to a custom board equipped with a MCP2515 and a MCP2551 devices.
Is the samples\subsys\canbus\canopen suitable for an hardware like the one I'm using?
If so, any hints on how make this sample working?
1)
I can compile it  from command line with
west build -b nrf52dk_nrf52832 samples\subsys\canbus\canopen -DSHIELD=dfrobot_can_bus_v2_0 -DCONF_FILE=prj.mcp2515.conf
declaring in subsys\canbus\canopen\CO_driver.c (even though I thought it wasn't really need to declare this here)
#define CONFIG_CAN_MAX_FILTER 13
and prj.mcp2515.conf as attachment
Executing the project, I get the attached log file with a series of error messages and this stucks me here for this moment.
2)
Just to give some more info, I'd like to say that I did compile the samples/drivers/can from command line launching this
west build -b nrf52dk_nrf52832 samples/drivers/can/ -DSHIELD=dfrobot_can_bus_v2_0 -DCONF_FILE=prj.mcp2515.conf
and everything works as expected (tested using a CAN sniffer).
But it is not clear to me how to add in this project the CANOpen stack library.
Thanks in advance for the support
Kind regards
Crisian
--
Ing Cristian Anceschi
Galileo Engineering s.r.l.
Via Cavallotti 16
IT - 42122 Reggio Emilia
Phone +39 0522 920496 / +39 0522 516244
Fax     +39 0522 920496 / +39 0522 516244
Privacy - Le informazioni contenute nel presente messaggio di posta elettronica ed in ogni allegato sono da ritenersi informazioni riservate. Chi ricevesse il presente messaggio senza esserne l'effettivo destinatario è rigorosamente tenuto a evitarne ogni divulgazione, diffusione o riproduzione, ai sensi del D.Lgs n.196/2003. Qualora abbiate ricevuto la presente comunicazione per errore siete pregati di distruggerla e di segnalarlo al mittente. Grazie.
Privacy - The information contained in this e-mail message and any attached files are considered private information. If you have received this message without being the intended recipient, prevent any dissemination or reproduction. If you are not the addressee, please contact the sender and destroy all copies of the original message. Thanks.


Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 31 December 2020 #cal-cancelled

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Cancelled: Zephyr Project: Dev Meeting

This event has been cancelled.

When:
Thursday, 31 December 2020
4:00pm to 5:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 24 December 2020 #cal-cancelled

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Cancelled: Zephyr Project: Dev Meeting

This event has been cancelled.

When:
Thursday, 24 December 2020
4:00pm to 5:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 10 December 2020 #cal-cancelled

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Cancelled: Zephyr Project: Dev Meeting

This event has been cancelled.

When:
Thursday, 10 December 2020
4:00pm to 5:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Re: Canopen node nRF52832

Nick Ward
 

Hi Cristian,

I'm not sure if the MCP1525 is a good match for Canopen but you may need to increase this kconfig symbol CONFIG_CAN_MCP2515_INT_THREAD_STACK_SIZE

Nick


On Thu, 10 Dec 2020, 2:38 am Bolivar, Marti, <marti.bolivar@...> wrote:
Hi,

The MPU fault may be due to a missing CONFIG_MPU_ALLOW_FLASH_WRITE=y.

I don't know anything about CAN, though :).

Martí

"Cristian Anceschi via lists.zephyrproject.org"
<cristian.anceschi=galileo.engineering@...> writes:

> Hi all
>
> I'm quite new on Zephyr and on CAN BUS so my question might have an easy or
> obvious answer.
>
> I'm on Ubuntu and I'm using an nRF52DK nRF52832 (PCA10040) wired to a
> custom board equipped with a MCP2515 and a MCP2551 devices.
>
> Is the samples\subsys\canbus\canopen suitable for an hardware like the one
> I'm using?
> If so, any hints on how make this sample working?
>
> 1)
> I can compile it  from command line with
> west build -b nrf52dk_nrf52832 samples\subsys\canbus\canopen
> -DSHIELD=dfrobot_can_bus_v2_0 -DCONF_FILE=prj.mcp2515.conf
>
> declaring in  subsys\canbus\canopen\CO_driver.c (even though I thought it
> wasn't really need to declare this here)
> #define CONFIG_CAN_MAX_FILTER 13
>
> and prj.mcp2515.conf as attachment
>
> Executing the project, I get the attached log file with a series of error
> messages and this stucks me here for this moment.
>
> 2)
> Just to give some more info, I'd like to say that I did compile the
> samples/drivers/can from command line launching this
>
> west build -b nrf52dk_nrf52832 samples/drivers/can/
> -DSHIELD=dfrobot_can_bus_v2_0 -DCONF_FILE=prj.mcp2515.conf
>
> and everything works as expected (tested using a CAN sniffer).
> But it is not clear to me how to add in this project the CANOpen stack
> library.
>
> Thanks in advance for the support
>
> Kind regards
> Crisian
>
>
>
> --
> Ing Cristian Anceschi
> Galileo Engineering s.r.l.
> Via Cavallotti 16
> IT - 42122 Reggio Emilia
> Phone +39 0522 920496 / +39 0522 516244
> Fax     +39 0522 920496 / +39 0522 516244
>
> Privacy - Le informazioni contenute nel presente messaggio di posta
> elettronica ed in ogni allegato sono da ritenersi informazioni riservate.
> Chi ricevesse il presente messaggio senza esserne l'effettivo destinatario
> è rigorosamente tenuto a evitarne ogni divulgazione, diffusione o
> riproduzione, ai sensi del D.Lgs n.196/2003. Qualora abbiate ricevuto la
> presente comunicazione per errore siete pregati di distruggerla e di
> segnalarlo al mittente. Grazie.
>
> Privacy - The information contained in this e-mail message and any attached
> files are considered private information. If you have received this message
> without being the intended recipient, prevent any dissemination or
> reproduction. If you are not the addressee, please contact the sender and
> destroy all copies of the original message. Thanks.
>
>
>
>
>
> # Alternate conf file required for building the CAN sample for the
> # MCP2515 stand alone CAN controller
>
> CONFIG_GPIO=y
>
> CONFIG_CAN=y
> CONFIG_CAN_INIT_PRIORITY=80
> CONFIG_CAN_MCP2515_MAX_FILTER=5
>
> CONFIG_SHELL=y
> CONFIG_CAN_SHELL=y
> CONFIG_DEVICE_SHELL=y
>
>
> CONFIG_LOG=y
> CONFIG_PRINTK=y
> CONFIG_CONSOLE=y
> #CONFIG_LOG_PRINTK=y
> CONFIG_RTT_CONSOLE=y
> #CONFIG_HAS_SEGGER_RTT=y
> CONFIG_USE_SEGGER_RTT=y
>
> #
>
> CONFIG_LOG=y
> CONFIG_CANOPEN_LOG_LEVEL_DBG=y
>
> CONFIG_CAN=y
> CONFIG_CAN_INIT_PRIORITY=80
> CONFIG_CAN_MCP2515=y
> CONFIG_CAN_MAX_FILTER=13
>
>
> CONFIG_FLASH=y
> CONFIG_FLASH_MAP=y
> CONFIG_NVS=y
> CONFIG_SETTINGS=y
> CONFIG_SETTINGS_NVS=y
>
> CONFIG_CANOPEN=y
> CONFIG_CANOPEN_SYNC_THREAD=y
> CONFIG_CANOPEN_STORAGE=y
> CONFIG_CANOPEN_LEDS=y
>
> CONFIG_REBOOT=y
> canstat=0
> new mode value : 0
> init mode 0
> *** Booting Zephyr OS version 2.4.99  ***
> [00:00:00.413,665] <inf> fs_nvs: 6 Sectors of 4096 bytes
> [00:00:00.413,665] <inf> fs_nvs: alloc wra: 0, ff0
> [00:00:00.413,665] <inf> fs_nvs: data wra: 0, 0
> [00:00:00.413,726] <dbg> canopen_driver.CO_CANmodule_init: rxSize = 13, txSize = 9
> canstat=0
> new mode value : 0
> [00:00:00.414,978] <err> canopen_driver: failed to attach CAN rx isr, no free filter
> [00:00:00.415,039] <err> canopen_driver: failed to attach CAN rx isr, no free filter
> [00:00:00.415,069] <err> canopen_driver: failed to attach CAN rx isr, no free filter
> [00:00:00.415,130] <inf> app: CANopen stack initialized
> [00:00:00.415,527] <err> os: ***** MPU FAULT *****
> [00:00:00.415,527] <err> os:   Data Access Violation
> [00:00:00.415,527] <err> os:   MMFAR Address: 0x7a000
> [00:00:00.415,557] <err> os: r0/a1:  0x0007a000  r1/a2:  0x00000055  r2/a





Re: Canopen node nRF52832

Bolivar, Marti
 

Hi,

The MPU fault may be due to a missing CONFIG_MPU_ALLOW_FLASH_WRITE=y.

I don't know anything about CAN, though :).

Martí

"Cristian Anceschi via lists.zephyrproject.org"
<cristian.anceschi=galileo.engineering@lists.zephyrproject.org> writes:

Hi all

I'm quite new on Zephyr and on CAN BUS so my question might have an easy or
obvious answer.

I'm on Ubuntu and I'm using an nRF52DK nRF52832 (PCA10040) wired to a
custom board equipped with a MCP2515 and a MCP2551 devices.

Is the samples\subsys\canbus\canopen suitable for an hardware like the one
I'm using?
If so, any hints on how make this sample working?

1)
I can compile it from command line with
west build -b nrf52dk_nrf52832 samples\subsys\canbus\canopen
-DSHIELD=dfrobot_can_bus_v2_0 -DCONF_FILE=prj.mcp2515.conf

declaring in subsys\canbus\canopen\CO_driver.c (even though I thought it
wasn't really need to declare this here)
#define CONFIG_CAN_MAX_FILTER 13

and prj.mcp2515.conf as attachment

Executing the project, I get the attached log file with a series of error
messages and this stucks me here for this moment.

2)
Just to give some more info, I'd like to say that I did compile the
samples/drivers/can from command line launching this

west build -b nrf52dk_nrf52832 samples/drivers/can/
-DSHIELD=dfrobot_can_bus_v2_0 -DCONF_FILE=prj.mcp2515.conf

and everything works as expected (tested using a CAN sniffer).
But it is not clear to me how to add in this project the CANOpen stack
library.

Thanks in advance for the support

Kind regards
Crisian



--
Ing Cristian Anceschi
Galileo Engineering s.r.l.
Via Cavallotti 16
IT - 42122 Reggio Emilia
Phone +39 0522 920496 / +39 0522 516244
Fax +39 0522 920496 / +39 0522 516244

Privacy - Le informazioni contenute nel presente messaggio di posta
elettronica ed in ogni allegato sono da ritenersi informazioni riservate.
Chi ricevesse il presente messaggio senza esserne l'effettivo destinatario
è rigorosamente tenuto a evitarne ogni divulgazione, diffusione o
riproduzione, ai sensi del D.Lgs n.196/2003. Qualora abbiate ricevuto la
presente comunicazione per errore siete pregati di distruggerla e di
segnalarlo al mittente. Grazie.

Privacy - The information contained in this e-mail message and any attached
files are considered private information. If you have received this message
without being the intended recipient, prevent any dissemination or
reproduction. If you are not the addressee, please contact the sender and
destroy all copies of the original message. Thanks.





# Alternate conf file required for building the CAN sample for the
# MCP2515 stand alone CAN controller

CONFIG_GPIO=y

CONFIG_CAN=y
CONFIG_CAN_INIT_PRIORITY=80
CONFIG_CAN_MCP2515_MAX_FILTER=5

CONFIG_SHELL=y
CONFIG_CAN_SHELL=y
CONFIG_DEVICE_SHELL=y


CONFIG_LOG=y
CONFIG_PRINTK=y
CONFIG_CONSOLE=y
#CONFIG_LOG_PRINTK=y
CONFIG_RTT_CONSOLE=y
#CONFIG_HAS_SEGGER_RTT=y
CONFIG_USE_SEGGER_RTT=y

#

CONFIG_LOG=y
CONFIG_CANOPEN_LOG_LEVEL_DBG=y

CONFIG_CAN=y
CONFIG_CAN_INIT_PRIORITY=80
CONFIG_CAN_MCP2515=y
CONFIG_CAN_MAX_FILTER=13


CONFIG_FLASH=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y
CONFIG_SETTINGS_NVS=y

CONFIG_CANOPEN=y
CONFIG_CANOPEN_SYNC_THREAD=y
CONFIG_CANOPEN_STORAGE=y
CONFIG_CANOPEN_LEDS=y

CONFIG_REBOOT=y
canstat=0
new mode value : 0
init mode 0
*** Booting Zephyr OS version 2.4.99 ***
[00:00:00.413,665] <inf> fs_nvs: 6 Sectors of 4096 bytes
[00:00:00.413,665] <inf> fs_nvs: alloc wra: 0, ff0
[00:00:00.413,665] <inf> fs_nvs: data wra: 0, 0
[00:00:00.413,726] <dbg> canopen_driver.CO_CANmodule_init: rxSize = 13, txSize = 9
canstat=0
new mode value : 0
[00:00:00.414,978] <err> canopen_driver: failed to attach CAN rx isr, no free filter
[00:00:00.415,039] <err> canopen_driver: failed to attach CAN rx isr, no free filter
[00:00:00.415,069] <err> canopen_driver: failed to attach CAN rx isr, no free filter
[00:00:00.415,130] <inf> app: CANopen stack initialized
[00:00:00.415,527] <err> os: ***** MPU FAULT *****
[00:00:00.415,527] <err> os: Data Access Violation
[00:00:00.415,527] <err> os: MMFAR Address: 0x7a000
[00:00:00.415,557] <err> os: r0/a1: 0x0007a000 r1/a2: 0x00000055 r2/a


Canopen node nRF52832

Cristian Anceschi <cristian.anceschi@...>
 

Hi all

I'm quite new on Zephyr and on CAN BUS so my question might have an easy or obvious answer.

I'm on Ubuntu and I'm using an nRF52DK nRF52832 (PCA10040) wired to a custom board equipped with a MCP2515 and a MCP2551 devices.

Is the samples\subsys\canbus\canopen suitable for an hardware like the one I'm using?
If so, any hints on how make this sample working?

1)
I can compile it  from command line with
west build -b nrf52dk_nrf52832 samples\subsys\canbus\canopen -DSHIELD=dfrobot_can_bus_v2_0 -DCONF_FILE=prj.mcp2515.conf 

declaring in  subsys\canbus\canopen\CO_driver.c (even though I thought it wasn't really need to declare this here)
#define CONFIG_CAN_MAX_FILTER 13

and prj.mcp2515.conf as attachment

Executing the project, I get the attached log file with a series of error messages and this stucks me here for this moment. 

2)
Just to give some more info, I'd like to say that I did compile the samples/drivers/can from command line launching this

west build -b nrf52dk_nrf52832 samples/drivers/can/ -DSHIELD=dfrobot_can_bus_v2_0 -DCONF_FILE=prj.mcp2515.conf

and everything works as expected (tested using a CAN sniffer).
But it is not clear to me how to add in this project the CANOpen stack library.

Thanks in advance for the support 

Kind regards
Crisian



--
Ing Cristian Anceschi
Galileo Engineering s.r.l.
Via Cavallotti 16
IT - 42122 Reggio Emilia
Phone +39 0522 920496 / +39 0522 516244
Fax     +39 0522 920496 / +39 0522 516244

Privacy - Le informazioni contenute nel presente messaggio di posta elettronica ed in ogni allegato sono da ritenersi informazioni riservate. Chi ricevesse il presente messaggio senza esserne l'effettivo destinatario è rigorosamente tenuto a evitarne ogni divulgazione, diffusione o riproduzione, ai sensi del D.Lgs n.196/2003. Qualora abbiate ricevuto la presente comunicazione per errore siete pregati di distruggerla e di segnalarlo al mittente. Grazie. 

Privacy - The information contained in this e-mail message and any attached files are considered private information. If you have received this message without being the intended recipient, prevent any dissemination or reproduction. If you are not the addressee, please contact the sender and destroy all copies of the original message. Thanks.


Re: [Zephyr-users] Query regarding Bluetooth Controller Porting

Carles Cufi
 

+ devel list

Pankaj,

If you are using a dual-chip solution, then as long as you controller complies with standard HCI there is no "porting" to do whatsoever.
In order to better understand what you need, can you let us know which transport do you plan on using (UART/H4, 3-wire/H3 or SPI) and whether it is a single-mode or dual-mode controller?

Unless your controllers has special requirements it should all be a matter of configuring the right Kconfig options and Devicetree nodes.

Carles

-----Original Message-----
From: users@lists.zephyrproject.org <users@lists.zephyrproject.org> On
Behalf Of Kumar Gala via lists.zephyrproject.org
Sent: 08 December 2020 15:08
To: Pankaj Singh <PANKAJ.SINGH@onsemi.com>
Cc: users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Query regarding Bluetooth Controller Porting

You may want to ask this question on the devel list.
(devel@lists.zephyrproject.org)

- k

On Dec 8, 2020, at 12:02 AM, Pankaj Singh <PANKAJ.SINGH@onsemi.com>
wrote:

Hi,

We want to port our custom Bluetooth controller to run on Zephyr RTOS
(not using the default zephyr ble controller support). I went through the
Bluetooth documentation
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.zep
hyrproject.org%2Flatest%2Fguides%2Fbluetooth%2Findex.html&amp;data=04%7C01
%7Ccarles.cufi%40nordicsemi.no%7Cc35438a7065845415d0708d89b82c771%7C28e5af
a2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637430333288501659%7CUnknown%7CTWFpbG
Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
C1000&amp;sdata=6J8jWeiNRxk3NPbnu1uQq0g01EaUG8wCYsQK58AFk6w%3D&amp;reserve
d=0
,https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.ze
phyrproject.org%2Flatest%2Fguides%2Fbluetooth%2Fbluetooth-
arch.html&amp;data=04%7C01%7Ccarles.cufi%40nordicsemi.no%7Cc35438a70658454
15d0708d89b82c771%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C63743033328
8501659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=pzOa7iuR0SSOR59u4s5VE3LgNF5MeoXR
ku7XtLCnOWo%3D&amp;reserved=0. The link’s talks about Bluetooth host in
detail and it was helpful. We want to use Dual Chip configuration mode
(use Zephyr Bluetooth host + custom Bluetooth controller support) .

From link it talks about various host only build configuration
o CONFIG_BT =y
o CONFIG_BT_HCI =y
o CONFIG_BT_CTLR =n


My query is in order to port custom controller what steps, build
configuration we need to take care of. If there is a link/document that
helps to describe porting of custom Bluetooth controller to Zephyr it will
be helpful.

-thanks




IoT Long Term support Linux - Opening to the community of Redpesk@SEA the open source "Marine Grade Linux" by IoT.bzh.

Dominig ar Foll (Intel Open Source) <dominig.arfoll@...>
 

Hello,
As Marine requirement is very very close of any IoT (very) long term Linux requirement with high level of security and application isolation, I thought that this webinar from the Linux Fundation might be of interest to some of you...

The Marine Grade Linux project by IoT.bzh addresses smart ship provides a customized flavor of AGL that addresses marine specific requirements. For signaling, NMEA2000, CanOpen, Ethercat and Modbus were added. Cloud connectivity is designed to handle random connectivity with a balance of 4/5G and satellite data link. Some core marine services as nautical charts, safe routing, or radar are still under development and should be added in the near future. Last but not least, a 30 years old ship is pretty common and maintenance/update on 15 years is required.

This presentation exposes the outcome of the three marine projects IoT.bzh is currently developing for this industry. It starts exposing gaps in business models, then exposes some of the technical specificities (signaling, SOTA, LTS, …). Finally it introduces redpesk@sea the ready-to-use “Marine Grade Linux” version that IoT.bzh will propose as Christmas gift to the maritime open-source community.

-- 
Dominig ar Foll
Senior Software Architect


Cancelled Event: Zephyr Project: APIs - Tuesday, 8 December 2020 #cal-cancelled

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Cancelled: Zephyr Project: APIs

This event has been cancelled.

When:
Tuesday, 8 December 2020
5:00pm to 6:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Re: Contribution

Alexander Wachter
 

Hi Tejas,

contributing to the Zephyr project works by sending pull-requests to one
of our repositories at GitHub [1]. There you can also file issues.
Helping hands are always welcome :-)
The easiest way to reach out to the community is via Slack.
You can join the slack channels with the invitation link [2].

[1] https://github.com/zephyrproject-rtos
[2] https://tinyurl.com/y5glwylp

--
Cheers,

Alex

On 06.12.20 14:00, Tejas Upadhyay wrote:
Hi,
I am Tejas Upadhyay with 12 years of embedded linux experience. Currently  I work with Intel for its i915 Opensource driver upstreaming.
I would be interested in contributing to zephyrproject Open-source contribution.
Thanks,
Tejas


Contribution

Tejas Upadhyay <upadhyay61@...>
 

Hi,

I am Tejas Upadhyay with 12 years of embedded linux experience. Currently  I work with Intel for its i915 Opensource driver upstreaming.

I would be interested in contributing to zephyrproject Open-source contribution. 

Thanks,
Tejas


CAN configuration API and zcan_frame change

Alexander Wachter <alexander.wachter@...>
 

Dear Zephyr CANbus users and devs,

We are reworking the CANbus configuration API and the zcan_frame.
If you are using CANbus in your products, please verify the changes.
Please leave comments on the RP [1] if you face any issues or in case of any doubts. Reviews are also much appreciated.

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

--
Sincerely, your CANbus Maintainer

Alex


Zephyr Project: Dev Meeting - Thu, 12/03/2020 4:00pm-5:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 3 December 2020, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Zephyr SDK 0.12.0-beta-3 available for testing

Kumar Gala
 

Hi,

Latest version of the SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.12.0-beta-3

Please download and try things out and report any issues. Please report issues here:

https://github.com/zephyrproject-rtos/sdk-ng/issues

Known issues (these are on the Zephyr side):

* some xtensa platforms may need updating w/regards to Zephyr & Xtensa HAL
[ https://github.com/zephyrproject-rtos/zephyr/pull/23142 ]

* known issue with arm64 and linking C++ & newlib:
[ https://github.com/zephyrproject-rtos/zephyr/issues/28650 ]

Changes since the last release (beta-2):

• Fixed bug with ARM libgcc builds & CMSE
• Built newlib optimized

Current plan is to release SDK 0.12.0 towards the middle of next week.

- k


Dev-Review Meeting Agenda Dec 3

Kumar Gala
 

Here’s the agenda topics for this week:

* eth: stm32h7: use SRAM3 / MPU configuration
- https://github.com/zephyrproject-rtos/zephyr/pull/30403

* STM32H745 SRAM Sections Definition
- https://github.com/zephyrproject-rtos/zephyr/pull/29282

* Any PR/issues w/dev-review tag

https://github.com/zephyrproject-rtos/zephyr/labels/dev-review

* Any topics anyone else has.

- k


Re: What is expected behavior of watchdog with WDT_FLAG_RESET_SOC?

Katsuhiro Suzuki
 

Hello Carles,

Indeed, thanks for your positive opinion.
I'll continue to try to check (and also study :) ) existing issues or PRs.

Best Regards,
Katsuhiro Suzuki

On 2020/12/03 1:49, Cufi, Carles wrote:
Hi Katsuhiro,

Thank you for reply. I understand situation.
I will try to add myself as collaborator of watchdog.
Thank you, that will certainly help.

But it seems that Zephyr project rules need two or more reviewers to
proceed pull requests. And of course, I cannot review my patch.
Maybe it does not help to merge or review my patch even if I will be as
collaborator. RISC-V area is also in same situation...
Of course, but there are things to consider here:
- If you indeed end up becoming a maintainer, you will be able to take certain decisions over questions or issues that show up in Pull Requests, effectively helping to move progress forward.
- As a consequence of that, if a Pull Request comes from the maintainer, then the requirement for two approvals stands, but the approvals are obviously automatically assumed to come from non-maintainers, so that means you don't need to wait for a maintainer that is non-existent if there are disagreements
In general, it is my opinion that having a maintainer or at least a collaborator will help in getting things merged, regardless of whether the patches come from that maintainer or anybody else.
Carles


Best Regards,
Katsuhiro Suzuki

On 2020/12/01 4:50, Carles Cufi wrote:
Hi Katsuhiro,

The whole watchdog subsystem is orphaned in fact.
We need maintainers for it, so if anyone wants to volunteer that would
be much appreciated.

Regards,

Carles


-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org>
On Behalf Of Katsuhiro Suzuki via lists.zephyrproject.org
Sent: 30 November 2020 18:14
To: zephyr-devel <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] What is expected behavior of watchdog
with WDT_FLAG_RESET_SOC?

Hello,

It seems that watchdog driver is orphaned.
I would be appreciate it if anyone inform about that...

Best Regards,
Katsuhiro Suzuki


On 2020/11/28 20:35, Katsuhiro Suzuki wrote:
Hello All,

I'm implementing Watchdog driver for HiFive1 Rev.b.
This watchdog can reset SoC immediately when counter is reaching
timeout. It's suitable feature of WDT_FLAG_RESET_SOC.

But tests/drivers/watchdog/wdt_basic_api/ expected to be calling
back the function 'wdt_int_cb0' even if with WDT_FLAG_RESET_SOC.
I think we cannot do that because SoC reset from watchdog is
immediate and not raise interrupt.

Do other boards pass this watchdog test? If so, I have to add
emulated SoC reset codes in interrupt handler of watchdog.

Best Regards,
Katsuhiro Suzuki















Re: What is expected behavior of watchdog with WDT_FLAG_RESET_SOC?

Carles Cufi
 

Hi Katsuhiro,

Thank you for reply. I understand situation.
I will try to add myself as collaborator of watchdog.
Thank you, that will certainly help.

But it seems that Zephyr project rules need two or more reviewers to
proceed pull requests. And of course, I cannot review my patch.
Maybe it does not help to merge or review my patch even if I will be as
collaborator. RISC-V area is also in same situation...
Of course, but there are things to consider here:

- If you indeed end up becoming a maintainer, you will be able to take certain decisions over questions or issues that show up in Pull Requests, effectively helping to move progress forward.
- As a consequence of that, if a Pull Request comes from the maintainer, then the requirement for two approvals stands, but the approvals are obviously automatically assumed to come from non-maintainers, so that means you don't need to wait for a maintainer that is non-existent if there are disagreements

In general, it is my opinion that having a maintainer or at least a collaborator will help in getting things merged, regardless of whether the patches come from that maintainer or anybody else.

Carles



Best Regards,
Katsuhiro Suzuki

On 2020/12/01 4:50, Carles Cufi wrote:
Hi Katsuhiro,

The whole watchdog subsystem is orphaned in fact.
We need maintainers for it, so if anyone wants to volunteer that would
be much appreciated.

Regards,

Carles


-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org>
On Behalf Of Katsuhiro Suzuki via lists.zephyrproject.org
Sent: 30 November 2020 18:14
To: zephyr-devel <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] What is expected behavior of watchdog
with WDT_FLAG_RESET_SOC?

Hello,

It seems that watchdog driver is orphaned.
I would be appreciate it if anyone inform about that...

Best Regards,
Katsuhiro Suzuki


On 2020/11/28 20:35, Katsuhiro Suzuki wrote:
Hello All,

I'm implementing Watchdog driver for HiFive1 Rev.b.
This watchdog can reset SoC immediately when counter is reaching
timeout. It's suitable feature of WDT_FLAG_RESET_SOC.

But tests/drivers/watchdog/wdt_basic_api/ expected to be calling
back the function 'wdt_int_cb0' even if with WDT_FLAG_RESET_SOC.
I think we cannot do that because SoC reset from watchdog is
immediate and not raise interrupt.

Do other boards pass this watchdog test? If so, I have to add
emulated SoC reset codes in interrupt handler of watchdog.

Best Regards,
Katsuhiro Suzuki
















Re: What is expected behavior of watchdog with WDT_FLAG_RESET_SOC?

Katsuhiro Suzuki
 

Hello Carles,

Thank you for reply. I understand situation.
I will try to add myself as collaborator of watchdog.

But it seems that Zephyr project rules need two or more reviewers
to proceed pull requests. And of course, I cannot review my patch.
Maybe it does not help to merge or review my patch even if I will
be as collaborator. RISC-V area is also in same situation...

Best Regards,
Katsuhiro Suzuki

On 2020/12/01 4:50, Carles Cufi wrote:
Hi Katsuhiro,
The whole watchdog subsystem is orphaned in fact.
We need maintainers for it, so if anyone wants to volunteer that would be much appreciated.
Regards,
Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Katsuhiro Suzuki via lists.zephyrproject.org
Sent: 30 November 2020 18:14
To: zephyr-devel <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] What is expected behavior of watchdog with
WDT_FLAG_RESET_SOC?

Hello,

It seems that watchdog driver is orphaned.
I would be appreciate it if anyone inform about that...

Best Regards,
Katsuhiro Suzuki


On 2020/11/28 20:35, Katsuhiro Suzuki wrote:
Hello All,

I'm implementing Watchdog driver for HiFive1 Rev.b.
This watchdog can reset SoC immediately when counter is reaching
timeout. It's suitable feature of WDT_FLAG_RESET_SOC.

But tests/drivers/watchdog/wdt_basic_api/ expected to be calling back
the function 'wdt_int_cb0' even if with WDT_FLAG_RESET_SOC.
I think we cannot do that because SoC reset from watchdog is immediate
and not raise interrupt.

Do other boards pass this watchdog test? If so, I have to add emulated
SoC reset codes in interrupt handler of watchdog.

Best Regards,
Katsuhiro Suzuki







561 - 580 of 8050