Date   

Re: using low level sensor drivers directly, without sensor API

Martin Schröder
 

Hi Rudolph, 

If you want to configure FIFO it would make the most sense to do so in the adxl driver. So just modify the driver, perhaps add a boolean dts option for the functionality and then create a pull request to get that functionality accepted into and managed by the main project. 

On Mon, 10 May 2021 at 15:12, Rudolph Aschmoneit <rudolph.aschmoneit@...> wrote:
Hey all,

I'm quite new to Zephyr, and I have definitely not yet understood all the concepts in their full depth. So please excuse me if my question seems a little bit stupid. Is it possible to use the functions of low level sensor drivers directly, without using the sensor API? About the background: I want to use the ADXL372 Sensor in Instant On mode. There is no Kconfig Macro for this. I also do not see any possibility to set the sensor to this mode or configure his FIFO accordingly using the Sensor API. But I found the functions I need in the driver implementation of the sensor (adxl372.c) But I can not use them (they’re definitions are not mentioned in adxl372.h and when I try to add it there, removing the static attribute in their adxl372.c declaration and adding them in the .h file everything becomes very unstable.) So it seems to me, that it is not intended by Zephyr to use this functions in my Applications. And of course I don’t want to write something into the original driver files, this was just for a short test.

I am very grateful for any kind of advice or suggestion!

Thank you a lot in Advance

Best Regards
Rudolph



--
Best regards,

Martin Schröder
Consultant


Review of concept of changing UART flow control from Kconfig to DTS config

lairdjm
 

Hi,

I only noticed today that the Kconfig option for enabling hardware flow control on UARTs, which used to be an optional Kconfig option, was removed and replaced with a DTS boards file configuration option instead, as per https://github.com/zephyrproject-rtos/zephyr/pull/25999

I find this to be a bit of a step backwards for application development, we have many boards in zephyr that we and customers use, these boards might be used for something simple like a sensor or might be used alongside a PC for doing some heavy processing and message passing over Bluetooth, so with a sensor, the log system might be active but it won’t have anything connected to it most of the time unless there’s an issue, so flow control is not required here, if it’s enabled then it’s going to cause an issue once the UART buffer gets full. However, on a PC communications module, that would be using the UART constantly, and need data integrity so needs flow control – in the old system, the boards file would have the flow control pins and it would be disabled by default, a project could enable it with a Kconfig option, this was great. However with the new system, it seems that we need to force flow control on all our boards, and then in instances where it’s not needed, have an overlay for that specific board (and we have many boards) to delete the hardware flow control part. This means that to enable hardware flow control, we need to update our boards file then add an overlay to almost every sample application in zephyr for most of our boards to disable flow control. This seems a bit chaotic to me so I would like to revisit this concept of having flow control configurable as a Kconfig option, the pins should be defined in the DTS file which hasn’t changed but if flow control is needed or not should be controlled on a project basis, opt in not opt out.

 

Are there any thoughts on this subject and how to get this working, focused on ease of being able to set this for ours and customer’s reuse?

Thanks,

Jamie


Re: using low level sensor drivers directly, without sensor API

William Fish
 

Rudolph,
With the Zephyr project being open source, if you would find it useful for someone in the future to access this functionality you should raise either a RFC or PR in the GitHub.

You should find the community fairly helpful in appraising and assisting with making changes.

Billy..


Zephyr Project: APIs - Tue, 05/11/2021 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: APIs

When: Tuesday, 11 May 2021, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

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
 
 
________________________________________________________________________________


API meeting: agenda

Carles Cufi
 


Zephyr Memory Footprint - biweekly discussion - Mon, 05/10/2021 3:00pm-4:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Memory Footprint - biweekly discussion

When: Monday, 10 May 2021, 3:00pm to 4:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Working doc: https://docs.google.com/document/d/1bnQLJKVhgI3zkk3MsSXun8onEsA8z1Rf5ohdbCHASmU/edit#heading=h.x36xe8bnwr9r

________________________________________________________________________________
Microsoft Teams meeting
Join on your computer or mobile app
Click here to join the meeting
Or call in (audio only)
+1 321-558-6518,,546018126# United States, Orlando
Phone Conference ID: 546 018 126#
 
 
________________________________________________________________________________


using low level sensor drivers directly, without sensor API

Rudolph Aschmoneit <rudolph.aschmoneit@...>
 

Hey all,

I'm quite new to Zephyr, and I have definitely not yet understood all the concepts in their full depth. So please excuse me if my question seems a little bit stupid. Is it possible to use the functions of low level sensor drivers directly, without using the sensor API? About the background: I want to use the ADXL372 Sensor in Instant On mode. There is no Kconfig Macro for this. I also do not see any possibility to set the sensor to this mode or configure his FIFO accordingly using the Sensor API. But I found the functions I need in the driver implementation of the sensor (adxl372.c) But I can not use them (they’re definitions are not mentioned in adxl372.h and when I try to add it there, removing the static attribute in their adxl372.c declaration and adding them in the .h file everything becomes very unstable.) So it seems to me, that it is not intended by Zephyr to use this functions in my Applications. And of course I don’t want to write something into the original driver files, this was just for a short test.

I am very grateful for any kind of advice or suggestion!

Thank you a lot in Advance

Best Regards
Rudolph


Zephyr 2.6.0-rc1 tagged

Kumar Gala
 

Hi all,

The first release candidate for Zephyr 2.6.0 has been tagged (v2.6.0-rc1).

The merge window for features and enhancements is now closed for this release, and it will remain closed until 2.6.0 is released; the stabilization period is now open. During the stabilization period only bug-fix, documentation, and stabilization-related patches may be merged to master. Additional features or enhancements for the 2.6.0 release require approval by the TSC.

We currently have the following bug counts:

* High - 5
* Medium - 41
* Low - 152

The goal for release is to be at:
* High - 0
* Medium < 20
* Low < 50

We have a long way to go on lows!

As we need to reduce bug counts for the release, you are all encouraged to submit PRs that close existing bug reports, and to help reviewing such PRs submitted by other contributors or maintainers. You can follow the bug numbers with the thresholds for each bug category here:

https://testing.zephyrproject.org/issues/zephyrproject-rtos/zephyr/index.html

Testing Zephyr master branch during the stabilization period is also requested; please test the code base and file bug reports so they can be addressed before the release deadline. Everyone is encouraged, especially hardware vendors, to test on hardware available to them. Use twister to run tests from the Zephyr tree on the boards you have using the device testing features.

The full release log can be found here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/v2.6.0-rc1

We plan to release weekly candidates (2.6.0-rcx) leading to the final release (2.6.0) which is tentatively scheduled for 28 May.

You may continue to submit pull requests for new features in order to gather feedback early or collaborate with others, but the release team would like to encourage everyone to focus on bugfixes and documentation improvements to the largest extent possible, so that we can release 2.6.0 on time and in the best shape possible.

A big Thank You to everyone that contributed to this release so far, be it with code, reviews, documentation or any other type of contribution!

Kumar


API: Remove support for `GPIO_INT_*` flags in `gpio_pin_configure()` function

Piotr Mienkowski
 

Hi all,

This is to let you know that we are going to remove support for passing `GPIO_INT_*` flags to `gpio_pin_configure()` function. The feature has been deprecated in the Zephyr 2.2 release. The interrupt flags will be accepted by `gpio_pin_interrupt_configure()` function only.

Regards,
Piotr


SAMC21 support and subscribe to zephyr development lists.

Romin Gajjar <rominzephyr@...>
 

Hello Zephyr Development Team,

1) I want to subscribe to the  devel@ mailing list.

2) My Colleague and I are working on development of SAMC21 port for Zephyr. Like I have seen D21, D20, E54 etx files in zephyr which I got working with their respective evaluation boards (D21 Xplained )

I would be highly obliged if anybody has any leads on any existing on-going activities  for SAMC21 microcontroller. I have been trying to integrate things but there are many hiccups to build the code considering the clocking style is different for SAMC21 compared to D21 or E54. I have already integrated the ASF files from Microchip studio utilities/cmsis.

Thank you in advance for any slightest piece of information or help for this topic. Even if you could connect me with any on-going development team in the community that shall be greatly appreciated. 

I am really looking forward to some direction or experienced help from your community as I am not an expert at this point.

Yours sincerely,
Romin


Re: REMINDER - merge window closes this Friday - May 7th, 2021.

lairdjm
 

Hi,
We have the following pull requests, two of which are reviewed and need merging and one that needs the testing to finish, can you review/merge these please?
https://github.com/zephyrproject-rtos/zephyr/pull/34519
https://github.com/zephyrproject-rtos/zephyr/pull/34833
https://github.com/zephyrproject-rtos/zephyr/pull/33738
These don't have 2.6 labels/milestones as I can't see a way to add them from the PR pages.
Thanks,
Jamie

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On Behalf Of Kumar Gala via lists.zephyrproject.org
Sent: 03 May 2021 14:27
To: devel <devel@lists.zephyrproject.org>
Subject: [Zephyr-devel] REMINDER - merge window closes this Friday - May 7th, 2021.

EXTERNAL EMAIL: Be careful with attachments and links.

Hi,

This is a reminder that the v2.6.0 merge window for new features closes this Friday, 7th of May. After that, only bug fixes and documentation will be merged until the final release is tagged, which is targeted for Friday, May 28th. Exceptions require TSC approval. New feature PRs may still be submitted while the merge window is closed, but please keep in mind that maintainers will have less time to review them during the release stabilization period.

Please add the v2.6.0 milestone to PRs that need to be included in the release, and do not wait until Friday, May 7th to submit them.

https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management
https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+milestone%3Av2.6.0

Please try to help fix bugs, test release candidates, and write release notes to minimize the time the merge window is closed so we can all quickly get back to adding fun new things to Zephyr!

Thank you for your contributions!

- k


Zephyr Project: Dev Meeting - Thu, 05/06/2021 3:00pm-4:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 6 May 2021, 3:00pm to 4: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
 
 
________________________________________________________________________________


Dev-Review Meeting Agenda May 5th

Kumar Gala
 

The agenda will focus on reviewing all PRs with a v2.6.0 milestone tag:

https://github.com/zephyrproject-rtos/zephyr/pulls?page=2&q=is%3Aopen+is%3Apr+milestone%3Av2.6.0

- k


SDK 0.13.0-alpha-1 Release

Kumar Gala
 

Hi all,

Just wanted to let people be aware few have an alpha release of the v0.13.0 SDK. The main focus of this alpha release is to enable ARC64 support in the toolchain.

Additionally we’ve updated gcc to be based on the GCC 10.3.0 release and pulled in QEMU 6.0.0.

I expect we will update OpenOCD to be based on a snapshot post the v0.11.0 release. Also, there’s expectation that ESP32 support will be added as well.

The SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.13.0-alpha-1

general:
Added support for ARC64. NOTE: GDB isn't currently supported
for ARC64.

qemu:
Updated to QEMU 6.0.0
Added arc64 support. NOTE: this update ARC support replaces
the machine (-M simhs) with (-M virt). This change will require
updates to boards/arc/qemu_arc/board.cmake in Zephyr to match.

gcc:
Update to gcc 10.3 release
Added support for ARC64

binutils:
Updated to add support for ARC64

newlib:
Updated to add support for ARC64

crosstool-ng:
sync with upstream. Upstream now supports newlib-nano so we drop
our Zephyr specific updates. This also pulls in gcc-10.3 and
initial support for ARC64.

yocto:
Update to yocto 3.2.3 baseline. This is in prep to support building
qemu-6.0.0

Thanks to all that contributed fixes and enhancements to this version of the SDK.

- k


RFC: API Change: USB HID remove get_protocol/set_protocol/get_idle/set_idle callbacks

Johann Fischer
 

Problem description:

The USB HID class API offers the possibility to register callbacks
for Get/SetIdle, Get/SetProtocol to the application.
Rules for these callbacks are neither obvious nor documented.

The Get/SetProtocol callbacks are redundant and do not provide any
additional value since the way to inform the application
about the change of the protocol exists via the callback
hid_protocol_cb_t protocol_change.

The core provides implementation to handle Get/SetIdle requests and
on idle reports. If this is not suitable in any way then the application
should implement everything itself.

Also the possibility to call unknown application code while processing
control requests should also be avoided or reduced to a minimum.

Example that it can be used all wrong:
https://github.com/zephyrproject-rtos/zephyr/pull/34400/files

The probability that someone will be affected by this change is very low, since
the usage is neither necessary nor obvious.

Github Issue for this API change:
https://github.com/zephyrproject-rtos/zephyr/issues/34426

Github PR:
https://github.com/zephyrproject-rtos/zephyr/pull/33659


Johann Fischer


Re: Zephyr x nRF52 Inquiry

David Rances <david@...>
 

Hi Jamie,

One of our team members came to the same conclusion as well. We'll need to check out memory usage and see if it's even possible for our situation. Assuming we can even attempt it, we'll test it out and experiment with it a bit.
I appreciate your help with this.

Thanks,
David


On Wed, May 5, 2021 at 3:13 AM Jamie Mccrae <Jamie.Mccrae@...> wrote:

Hi David,

You can package them up using nrfutil so that they can update over the old Nordic SDK bootloader, you would just need to adjust the kernel load offset to after the softdevice and you wouldn’t be able to erase the softdevice, and would then use nrfutil like you would packaging a Nordic SDK application. The issue you have is that you’re using an nRF52832 with 512 or 256KB of flash and the current S132 softdevice uses 152KB of flash, the bootloader was 48KB or so if I remember rightly so that’s 200KB of 256/512KB flash used, to which you want to add a zephyr application with it’s own Bluetooth stack… Depending on the application and if you have any non-volatile data, you might find there is insufficient space for it to fit.

Thanks,

Jamie

 

From: David Rances <david@...>
Sent: 03 May 2021 14:30
To: Jamie Mccrae <Jamie.Mccrae@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] Zephyr x nRF52 Inquiry

 

Hi Jamie,

 

Thanks for the response.

 

Does that mean that if I have devices out in the field running firmware built on older Nordic code (SoftDevice and nRF52 SDK), the only way to get firmware built on Zephyr onto those devices would be to bring them in and physically erase/flash them? Since any existing methods to update the bootloader/application would be dependent on tools from Nordic that utilize the SoftDevice (OTA DFU) or their serial DFU using SLIP.

 

Best,

David

 

On Fri, Apr 30, 2021 at 4:51 PM Jamie Mccrae <Jamie.Mccrae@...> wrote:

Hi David,

Zephyr does not use the Nordic SDK softdevice, it comes with its own Bluetooth stack which gets compiled into your application hex file. You would get rid of the code on your module and flash just the zephyr hex file, or you could also flash mcuboot if you want a boot loader.

If you are using the nRF connect SDK which uses zephyr then the ‘softdevice’ mentioned there has no relation to the Nordic SDK softdevice, it is Nordic’s proprietary lower link layer Bluetooth stack but similar to if using the one in zephyr, it gets statically linked to your output application and so you do not need the Nordic SDK softdevice

Thanks,

Jamie

 


From: devel@... <devel@...> on behalf of David Rances via lists.zephyrproject.org <david=strongarmtech.com@...>
Sent: Friday, April 30, 2021 8:54 pm
To: devel@...
Subject: [Zephyr-devel] Zephyr x nRF52 Inquiry

 

Hi,

 

I've got a question regarding Zephyr for nRF52 devices. I have an nRF52832 device with an old application firmware and bootloader that is utilizing an older version of SoftDevice (v5) and SDKv14.2 from Nordic. I'm currently building an application with Zephyr right now to target the same hardware. Would I need to update the SoftDevice version on the device first in order for my Zephyr application to run? What SoftDevice version is the current Zephyr running?

 

Thanks,

David

 

--

________________________

David Rances   |   Embedded Engineer

Email: david@...

Cell: +1 917 476 3696


NOTICE: This email and its contents/attachments may be confidential and are intended solely for the individual to whom it is addressed. If you are not the named addressee or if this email is otherwise received in error, please immediately notify the sender without reading it; do not take any action based on its contents or otherwise copy or disclose it to anyone, and note that any review, reliance or dissemination of this communication is expressly prohibited.  Any opinions or views expressed in this transmission are solely of the author and do not necessarily represent those of StrongArm Technologies Inc. or its affiliates.

THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.


 

--

________________________

David Rances   |   Embedded Engineer

Email: david@...

Cell: +1 917 476 3696


NOTICE: This email and its contents/attachments may be confidential and are intended solely for the individual to whom it is addressed. If you are not the named addressee or if this email is otherwise received in error, please immediately notify the sender without reading it; do not take any action based on its contents or otherwise copy or disclose it to anyone, and note that any review, reliance or dissemination of this communication is expressly prohibited.  Any opinions or views expressed in this transmission are solely of the author and do not necessarily represent those of StrongArm Technologies Inc. or its affiliates.



--

________________________
David Rances   |   Embedded Engineer
Email: david@...
Cell: +1 917 476 3696

NOTICE: This email and its contents/attachments may be confidential and are intended solely for the individual to whom it is addressed. If you are not the named addressee or if this email is otherwise received in error, please immediately notify the sender without reading it; do not take any action based on its contents or otherwise copy or disclose it to anyone, and note that any review, reliance or dissemination of this communication is expressly prohibited.  Any opinions or views expressed in this transmission are solely of the author and do not necessarily represent those of StrongArm Technologies Inc. or its affiliates.


Re: Zephyr x nRF52 Inquiry

lairdjm
 

Hi David,

You can package them up using nrfutil so that they can update over the old Nordic SDK bootloader, you would just need to adjust the kernel load offset to after the softdevice and you wouldn’t be able to erase the softdevice, and would then use nrfutil like you would packaging a Nordic SDK application. The issue you have is that you’re using an nRF52832 with 512 or 256KB of flash and the current S132 softdevice uses 152KB of flash, the bootloader was 48KB or so if I remember rightly so that’s 200KB of 256/512KB flash used, to which you want to add a zephyr application with it’s own Bluetooth stack… Depending on the application and if you have any non-volatile data, you might find there is insufficient space for it to fit.

Thanks,

Jamie

 

From: David Rances <david@...>
Sent: 03 May 2021 14:30
To: Jamie Mccrae <Jamie.Mccrae@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] Zephyr x nRF52 Inquiry

 

Hi Jamie,

 

Thanks for the response.

 

Does that mean that if I have devices out in the field running firmware built on older Nordic code (SoftDevice and nRF52 SDK), the only way to get firmware built on Zephyr onto those devices would be to bring them in and physically erase/flash them? Since any existing methods to update the bootloader/application would be dependent on tools from Nordic that utilize the SoftDevice (OTA DFU) or their serial DFU using SLIP.

 

Best,

David

 

On Fri, Apr 30, 2021 at 4:51 PM Jamie Mccrae <Jamie.Mccrae@...> wrote:

Hi David,

Zephyr does not use the Nordic SDK softdevice, it comes with its own Bluetooth stack which gets compiled into your application hex file. You would get rid of the code on your module and flash just the zephyr hex file, or you could also flash mcuboot if you want a boot loader.

If you are using the nRF connect SDK which uses zephyr then the ‘softdevice’ mentioned there has no relation to the Nordic SDK softdevice, it is Nordic’s proprietary lower link layer Bluetooth stack but similar to if using the one in zephyr, it gets statically linked to your output application and so you do not need the Nordic SDK softdevice

Thanks,

Jamie

 


From: devel@... <devel@...> on behalf of David Rances via lists.zephyrproject.org <david=strongarmtech.com@...>
Sent: Friday, April 30, 2021 8:54 pm
To: devel@...
Subject: [Zephyr-devel] Zephyr x nRF52 Inquiry

 

Hi,

 

I've got a question regarding Zephyr for nRF52 devices. I have an nRF52832 device with an old application firmware and bootloader that is utilizing an older version of SoftDevice (v5) and SDKv14.2 from Nordic. I'm currently building an application with Zephyr right now to target the same hardware. Would I need to update the SoftDevice version on the device first in order for my Zephyr application to run? What SoftDevice version is the current Zephyr running?

 

Thanks,

David

 

--

________________________

David Rances   |   Embedded Engineer

Email: david@...

Cell: +1 917 476 3696


NOTICE: This email and its contents/attachments may be confidential and are intended solely for the individual to whom it is addressed. If you are not the named addressee or if this email is otherwise received in error, please immediately notify the sender without reading it; do not take any action based on its contents or otherwise copy or disclose it to anyone, and note that any review, reliance or dissemination of this communication is expressly prohibited.  Any opinions or views expressed in this transmission are solely of the author and do not necessarily represent those of StrongArm Technologies Inc. or its affiliates.

THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.


 

--

________________________

David Rances   |   Embedded Engineer

Email: david@...

Cell: +1 917 476 3696


NOTICE: This email and its contents/attachments may be confidential and are intended solely for the individual to whom it is addressed. If you are not the named addressee or if this email is otherwise received in error, please immediately notify the sender without reading it; do not take any action based on its contents or otherwise copy or disclose it to anyone, and note that any review, reliance or dissemination of this communication is expressly prohibited.  Any opinions or views expressed in this transmission are solely of the author and do not necessarily represent those of StrongArm Technologies Inc. or its affiliates.


Re: Zephyr x nRF52 Inquiry

Eric Mohlenhoff
 

If you take a look at the supported board documentation for the nRF52840 Dongle (PCA10059), there is a section that describes loading/using a Zephyr application with the Nordic bootloader. I don't know if this is the same bootloader as the one you are using from the Nordic SDK, but it might be worth checking out as a starting place to see what might be possible for your situation.

--Eric


Zephyr Project: APIs - Tue, 05/04/2021 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: APIs

When: Tuesday, 4 May 2021, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

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
 
 
________________________________________________________________________________


Zephyr: Networking Forum - Tue, 05/04/2021 3:00pm-4:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr: Networking Forum

When: Tuesday, 4 May 2021, 3:00pm to 4:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: tsc@...

Description:


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

301 - 320 of 8043