Hi Jett,

It should certainly be possible to do this, where you implement driver logic as just code which makes other system calls at a lower-level bus abstraction to interact with the hardware. It would be hard to get this to play along with Zephyr's current driver abstraction infrastructure though.

However, a current limitation of the driver subsystems in Zephyr is that they unconditionally implement system calls at the subsystem level. And there is also the question on how to manage access to any global data associated with the higher-level driver, as the contents of data structures like `struct device` are considered private kernel data.

So using EEPROM as an example, you could in principle implement eeprom_read(), eeprom_write() etc as just some library code which makes system calls into the underlying SPI subsystem code to talk to the hardware. What currently happens right now is that the system call boundary is at the EEPROM subsystem level, and the implementation of the EEPROM APIs will call into the SPI driver already in supervisor mode. From a performance perspective the infrastructure is smart enough to skip all the syscall overhead when it calls into SPI from the EEPROM driver code, but from a least privilege standpoint it's not ideal.

The challenges are, as I see it:

• struct device and supporting data structures are currently considered private kernel data, can't really provide a 'struct device' at the EEPROM level, just SPI
• Callers into a user mode driver, if the driver code used any read-write global data, would have to also have access to this data otherwise you'd get a fault when making an API call
• The subsystem code would need some idea of what devices are user mode and what aren't, and how to manage access to data that is kernel-private (like API vtables)

However, if you wanted to do this outside of the Zephyr driver abstraction model, it shouldn't be too bad. Write everything in terms of SPI driver calls, add a memory partition for any globals it has to manage, and enforce that any callers have both permissions on the underlying SPI device and also the memory partition active in the caller's memory domain.

Devicetree is AFAIK just our ontology of hardware characteristics so I wouldn't see a problem with getting HW values and stuff out of DTS regardless of what mode it runs in.

HTH,

Andrew

Hi everyone,

The first release candidate for Zephyr 2.4.0 has been tagged (v2.4.0-rc1).

The merge window for features and enhancements is now closed for this release, and it will remain closed until 2.4.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.4 release require approval by the TSC.

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.

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.

The full release log can be found here:

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

More details about Zephyr releases can found on the pages below:

https://docs.zephyrproject.org/latest/development_process/release_process.html

https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

The final release is tentatively scheduled for 25 Sep.

Note 1: You may continue to send 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.4.0 on time and in the best shape possible.

Note 2: If you have a feature or enhancement you would like to submit to the TSC, please tag the Pull Request with the "TSC" label, make sure it is approved and passing CI, and attend the next TSC meeting.

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!

Maureen

Hello,

I am using the default Zephyr BLE stack while using the NCS SDK with nrf52840 development board by Nordic.

My setup is as follows

Board1 – Running a Peripheral_Uart demo code which is advertising.

Board2 – Running a Central_Uart demo code which is scanning.

When the scan starts on board 2, I am filling the advertising address of the devices which are advertising, in a buffer. When I started the printing the buffer, the addresses repeat at a certain time period. For example, if I see 01:01:01:01:01:01 address at time X sec, I see the same address at X + (120-180)sec again. So I am wondering if the data coming from the callback is getting refreshed at a certain time interval? If so, which parameters are controlling this refresh rate? Is it possible to change this time which is 120-180 sec approximately right now to whatever value I want?

Thanks

Raj Lavingia I Embedded Software Engineer

Shure Incoporated

5800 W. Touhy Avenue

Niles, Illinois 60714-4608 USA

T +1.847.600.6276

shure.com

Hi everyone,

This is a reminder that the v2.4.0 merge window for new features closes this Friday, 4 September. After that, only bug fixes and documentation will be merged until the final release is tagged, which is targeted for 25 September. 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.4.0 milestone to PRs that need to be included in the release, and do not wait until Friday to submit them.

https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+milestone%3Av2.4.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!

Your v2.4.0 release manager,

Maureen

Hi Deepa,

From your question it seems you are using the nRF Connect SDK, and not vanilla Zephyr.

You should therefore direct your question to the Nordic DevZone instead:

https://devzone.nordicsemi.com/

Regards,

Carles

Hello team,

Greetings From Deepa. I need an manual  installation procedure and building, compiling and Running the zephyr -OS with my laptop for learning purpose. I browsed and compiled via cmd prompt, but still I need an Editor support for running this OS with nrf9160 controller. In addition to that, I  tried running with web browser as well. I also willing to run with an IDE(any IDE which supports for NC sdk) for creating my own projects and running with NC sdk.

Please, suggest some options along with sample projects running procedure at the earliest.

Thanks & Regards,

Deepa.R

+91-9486308286/ 8072608604

Sent from Mail for Windows 10