|
STM32: Moving devices pin configuration to device tree
Erwan Gouriou
TL;DR: - Upcoming device tree based pin configuration for STM32 based boards - Script generated, SoC package specific *-pinctrl.dtsi files are available in hal_stm32 modules - Each *.pcintrl.dtsi file provides a complete set of valid pin configurations for targeted STM32 package - Generation script is provided and can be used to generate new pin configuration variants (low power, ...) - One driver (STM32 serial) and two boards converted today as proof of concept - Contributions are welcome to achieve deprecation of existing pinmux.c files within V2.5.0 merge window To all STM32 users and developers, We're in the final step of reviewing PR #25996 "stm32: devices signals configuration from dt pinctrl nodes": https://github.com/zephyrproject-rtos/zephyr/pull/25996 This PR introduces the required material to enable device pin configuration using device tree. With this method, device pin configuration should no longer be done in pinmux.c board file, but in .dts file. For instance, to enable PB6 as TX and PB7 as RX on USART1, the following lines should be added in .dts board file, in usart1 node: &usart1 { current-speed = <115200>;+ pinctrl-0 = <&usart1_tx_pb6 &usart1_rx_pb7>; + pinctrl-names = "default"; status = "okay"; }; As a consequence, pin configuration can now be done at device driver level, opening the way to dynamic pin configuration, which could be useful in various fields such as low power management. Also, it provides flexibility in application configuration as pin configurations could then be modified in using overlays. Pin control nodes are defined using Linux pinctrl bindings. For instance, usart1_tx_pb6 is defined as +usart1_tx_pb6: usart1_tx_pb6 { + pinmux = <STM32_PINMUX('B', 6, AF7)>; + bias-pull-up; +}; Definition of nodes usart1_tx_pb6 and usart1_rx_pb7 could be provided manually but to assist in board configuration, SoC variant package specific -pinctrl.dtsi files are provided and should be included in the board dts files. For instance, for board disco_l475_iot1: #include <st/l4/stm32l475Xg.dtsi> +#include <st/l4/stm32l475r(c-e-g)tx-pinctrl.dtsi> #include "arduino_r3_connector.dtsi" *-pinctrl.dtsi files provide known working pin configurations which could be overwritten at board level to fit a specific need. These files are hosted in hal_stm32 module (under dts/st/), one for each STM32 SoC package. These files are generated from STM32 .xml description files (currently delivered in ST STM32CubeMx tool). Using the appropriate -pinctrl.dtsi file allows benefiting from the full list of valid pinctrl nodes for a SoC package that is used on a board, reducing the risk of pin misconfiguration. The -pinctrl.dtsi generation script is also provided and could be used to add or modify pinctrl node variants, or to provide a new set of -pinctrl.dtsi files if a new STM32 SoC shows up. This new method could coexist with current pinmux.c configuration (beware of the pin conflicts as usual, though). For now, PR #25996 only provides the tooling for dts based pin configuration. Only one driver (STM32 serial) and 2 boards have been modified as proof of concept (cf PR for more details). Next step is to extend its usage to existing STM32 boards and drivers. Target is to get rid of in tree pinmux.c files for V2.5.0, so their usage could be deprecated. I invite STM32 codeowners and contributors to help us in this task. Out of tree users are also encouraged to perform this change on their respective boards. Big thanks to Gerard Marull-Paretas (@gmarull) who helped me with this PR and provided the pinctrl.dtsi files generation script. Cheers Erwan
|
||||
|
|
||||
|
RFC: API Change: k_work
Peter A. Bigot
In accordance with policy
your attention is drawn to #28794
which summarizes and outlines the motivation for a change to the
k_work infrastructure, specifically with how k_delayed_work
functions behave. These changes are motivated by #27356.
Please raise high level concerns in that issue, and the specific changes in #28589. Peter
|
||||
|
|
||||
|
Zephyr Project: APIs - Tue, 09/29/2020 4:00pm-5:00pm, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: APIs When: Tuesday, 29 September 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: 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
________________________________________________________________________________
|
||||
|
|
||||
|
Enabling LE Periodic Advertising for nRF8240-dongle
Anupam Roy
Hello Zephyr Developers, I am trying to enable BT 5.0 features - 2MPHY & CODED PHY, LE Extended Advertising & Periodic Advertising features for my nRF52840 USB dongle with Linux Host (Bluez) In order to enable EXT & Periodic Advertising, I modified my prj.conf file in following way
After establishing connection, following is the HCI trace for "LE Remote feature Read" request Even though, CSA#2 & Extended Advertising ae enabled, somehow Periodic Advertising feature is missing. Please suggest if I am missing something. Thank You
BR, -Anupam Roy
|
||||
|
|
||||
|
API meeting agenda: 2020-09-29
Peter A. Bigot
Carles has asked me to stand in for him in coordinating this
week's API telecon.
Topics include: - Triage #28220 - Highlight #28579 and discuss whether this needs to follow the "incompatible API change" process. - Renewed call for reviews of #27360 - Review of To Do and In Progress items in API project to see what might make 2.5 - Anything else added to the Triage column of the API Project - Anything else raised in the slack #api channel or at the meeting Teams link: https://teams.microsoft.com/l/meetup-join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion https://github.com/zephyrproject-rtos/zephyr/projects/18 https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit
|
||||
|
|
||||
|
arnaud.durand@...
Given this Kconfig:
config MY_STRThe directive #if defined(CONFIG_MY_STR) will eval to true for the default empty string. How to check if CONFIG_MY_STR is an empty string at compile time? Is it a better practice to use a second boolean value (e.g. CONFIG_USE_MY_STR) like the following? config MY_STR
|
||||
|
|
||||
|
Zephyr v2.4.0 released
Maureen Helm
Hi everyone, We are pleased to announce the release of Zephyr RTOS version 2.4.0!
Major enhancements with this release include:
During this release cycle we also:
The detailed release notes can be found here: https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v2.4.0
The next release, v2.5.0, is scheduled for January 29th, 2021. We’ll select a release manager in the next few days. The merge window is now open!
Thank you to everyone that contributed features, documentation, testing, infrastructure, and bug fixes!
Maureen
|
||||
|
|
||||
|
Re: Zephyr v2.4.0-rc3 tagged
Chettimada, Vinayak Kariappa
Hi Maureen,
> The final release remains scheduled for 25 Sep.
I see that one of my PR has not been merged, because there was a merge conflict introduced due to another PR that was merged.
PR: https://github.com/zephyrproject-rtos/zephyr/pull/28089
This PR was submitted 19 days ago, covering a bug reported by a user. It has since not got reviews after repeated reminders to reviewers until “it's a big change that fixes one low priority bug. do we really need it? “ and “it is this late in the release cycle…” decision being taken. (Discussions in #release slack channel)
There are 142 low priority bugs still open as mentioned in this email chain. A bug is a bug, an assignee works on a fix during the release stabilization period. Fix PR could be submitted by assignee before the next Release Candidate, these PR shall be merged else there is no point in classifying medium and low priority if the fixes are not merged because release criteria of < 150 low priority bugs is already met because of other PRs being closed.
There should be a RC4 considering that all medium and low priority bugs having a submitted PR that is passing CI gets reviews/approvals. These PRs can be omitted if there are pending change requests and it is decided to be removed from v2.4 milestone.
Regards, Vinayak
From: devel@... <devel@...>
On Behalf Of Maureen Helm via lists.zephyrproject.org
Sent: 25 September 2020 01:19 To: announce@...; devel@... Subject: [Zephyr-devel] Zephyr v2.4.0-rc3 tagged
Hi everyone, The third release candidate for Zephyr v2.4.0 has been tagged (v2.4.0-rc3). The full release log can be found here: https://github.com/zephyrproject-rtos/zephyr/releases/tag/v2.4.0-rc3
This is hopefully the last release candidate before we finalize the v2.4.0 release. We have satisfied release quality criteria [1] with the exception of one high priority bug. Current bug counts are: High: 1 Medium: 18 Low: 142
The outstanding high priority bug is to deprecate and remove old k_mem_pool/sys_mem_pool APIs [2]. The TSC decided this week that the PR fixing this bug [3] is too extensive to merge at this late stage of the release cycle. We have documented the mem_pool APIs as deprecated [4], but will wait until after the v2.4.0 release to tag them with the __deprecated attribute and fix in-tree uses, then remove the APIs completely in v2.6.0 LTS.
The purpose of this release candidate is to do one last round of QA testing and finalize release notes. I don’t plan to merge anything other than documentation unless QA testing reveals new bugs that cause us to no longer satisfy release quality criteria.
The final release remains scheduled for 25 Sep.
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!
[2] https://github.com/zephyrproject-rtos/zephyr/issues/24358 [3] https://github.com/zephyrproject-rtos/zephyr/pull/28611 [4] https://github.com/zephyrproject-rtos/zephyr/pull/28646
Maureen
|
||||
|
|
||||
|
Zephyr v2.4.0-rc3 tagged
Maureen Helm
Hi everyone, The third release candidate for Zephyr v2.4.0 has been tagged (v2.4.0-rc3). The full release log can be found here: https://github.com/zephyrproject-rtos/zephyr/releases/tag/v2.4.0-rc3
This is hopefully the last release candidate before we finalize the v2.4.0 release. We have satisfied release quality criteria [1] with the exception of one high priority bug. Current bug counts are: High: 1 Medium: 18 Low: 142
The outstanding high priority bug is to deprecate and remove old k_mem_pool/sys_mem_pool APIs [2]. The TSC decided this week that the PR fixing this bug [3] is too extensive to merge at this late stage of the release cycle. We have documented the mem_pool APIs as deprecated [4], but will wait until after the v2.4.0 release to tag them with the __deprecated attribute and fix in-tree uses, then remove the APIs completely in v2.6.0 LTS.
The purpose of this release candidate is to do one last round of QA testing and finalize release notes. I don’t plan to merge anything other than documentation unless QA testing reveals new bugs that cause us to no longer satisfy release quality criteria.
The final release remains scheduled for 25 Sep.
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!
[2] https://github.com/zephyrproject-rtos/zephyr/issues/24358 [3] https://github.com/zephyrproject-rtos/zephyr/pull/28611 [4] https://github.com/zephyrproject-rtos/zephyr/pull/28646
Maureen
|
||||
|
|
||||
|
Zephyr: Toolchain Working Group - Thu, 09/24/2020
#cal-notice
devel@lists.zephyrproject.org Calendar <noreply@...>
Zephyr: Toolchain Working Group When: Where: Description: Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r
________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
________________________________________________________________________________
|
||||
|
|
||||
|
Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 24 September 2020
#cal-cancelled
devel@lists.zephyrproject.org Calendar <devel@...>
Cancelled: Zephyr Project: Dev Meeting This event has been cancelled. When: Where: 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: Toolchain Working Group - Thu, 09/24/2020 2:00pm-3:00pm, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr: Toolchain Working Group When: Thursday, 24 September 2020, 2:00pm to 3:00pm, (GMT+00:00) UTC Where:Microsoft Teams Meeting An RSVP is requested. Click here to RSVP Organizer: Maureen Helm Description: Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r
________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
________________________________________________________________________________
|
||||
|
|
||||
|
Zephyr Toolchain Working Group Meeting – 24 September 2020
Rasmussen, Torsten
Call for today’s Toolchain WG.
Agenda
Feel free to send a mail, if you would like additional topics to be discussed.
Best regards
Torsten T. Rasmussen
Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r ________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll) Conference ID: 682 738 030# Local numbers | Reset PIN | Learn more about Teams | Meeting options
________________________________________________________________________________
|
||||
|
|
||||
|
Re: Memory protection and picolibc global state
Boie, Andrew P
Hi Keith,
toggle quoted messageShow quoted text
Sorry, just saw this. There are some k_mem_partitions defined which can help with this, z_malloc_partition and z_libc_partition. z_malloc_partition is for the malloc() arena, which is global. z_libc_partition is for any other globals associated with the libc. These are defined in include/sys/libc-hooks.h along with the further comments. This situation is not ideal. We would eventually like separate libc library globals and malloc arenas on a per memory domain basis (not per thread). This is, to put it mildly, tricky to do when all you have is an MPU. There's a issue here about it: https://github.com/zephyrproject-rtos/zephyr/issues/25891 the last comment has my current thinking on this problem. HTH, Andrew
-----Original Message-----
|
||||
|
|
||||
|
Re: Memory protection and picolibc global state
On Sat, Sep 19, 2020 at 02:06:02PM -0700, Keith Packard via lists.zephyrproject.org wrote:
I'm continuing to develop picolibc (https://github.com/picolibc) supportI wonder how this works with the newlib implementation. We have several variants a malloc-like code that can end up in Zephyr, unfortunately, sometimes at the same time. There is a simplistic allocator that is part of the Zephyr kernel. It is given a fixed region of memory to use as a heap. There is also an allocate that comes in when newlib is enabled (which comes from the SDK). This will use the space between the end of the image's SRAM usage and the end of SRAM (which doesn't show up in the image size reports). I believe these both work with the MPU enabled, although the kernel heap may only be used from kernel side. What might be worth investigating why malloc from newlib works. Perhaps there is something special about how newlib's libc is linked in. I think it looks like picolib and newlib share code for the allocator, so hopefully this is just a configuration issue. I supposed it would also be a good idea just to make sure that using newlib's malloc actually does work if the MPU is enabled. David
|
||||
|
|
||||
|
API meeting cancelled today
Carles Cufi
Hi all,
In order to focus on the release itself I have cancelled the API meeting today. Next week it will take place as usual. Regards, Carles
|
||||
|
|
||||
|
Cancelled Event: Zephyr Project: APIs - Tuesday, 22 September 2020
#cal-cancelled
devel@lists.zephyrproject.org Calendar <devel@...>
Cancelled: Zephyr Project: APIs This event has been cancelled. When: Where: 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
________________________________________________________________________________
|
||||
|
|
||||
|
Hello Zephyr Development Community I am currently working on implementing the Nordic NRFX PDM driver into Zephyr. However with this driver, I am not quite sure how to properly gain access to the device struct for the driver, in a function called from the wrong context. I'll elaborate: Just for now, to get it working, I have a global pointer to the device struct, which I obviously would like to avoid, but is working since there can only be one instance of the driver. I took a look at some other nrfx drivers: So my question is - which would be the correct way of accessing this device structure from a different context?
|
||||
|
|
||||
|
Memory protection and picolibc global state
Keith Packard
I'm continuing to develop picolibc (https://github.com/picolibc) support
for Zephyr under this PR: https://github.com/zephyrproject-rtos/zephyr/pull/26545 I'm running the sanity checks under qemu on mps2_an521 which uses the ARM MPU. On this board, the default memory protection configuration seems to place all libc globals in a region which is protected against application access. That includes globals used in managing the malloc heap, and so application calls to malloc end up generating a MPU fault. I can fix this in at least a couple of possible ways: 1) Create per-thread malloc heaps and track malloc per-thread. 2) Figure out how to change protection for libc globals 3) Replace the picolibc malloc implementation with a Zephyr custom implementation. -- -keith
|
||||
|
|
||||
|
Zephyr v2.4.0-rc2 tagged
Maureen Helm
Hi everyone, The second release candidate for Zephyr v2.4.0 has been tagged (v2.4.0-rc2).
The merge window for features and enhancements remains closed until v2.4.0 is released. During the stabilization period only bug-fix, documentation, and stabilization-related patches may be merged to master. Additional features or enhancements for the v2.4.0 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. Current bug counts are: High: 0 Medium: 25 Low: 145
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-rc2
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 remains 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 v2.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
|
||||
|
|
