|
stm32h7xx REQUIRES_FULL_LIBC
Jan Pohanka
Hello,
current implementation for stm32h7 soc has REQUIRES_FULL_LIBC enabled in soc/arm/st_stm32/stm32h7/Kconfig.series. Can someone tell me a reason for this? I have found that it is also in drivers/counter/Kconfig.stm32_rtc so I expect that stm32 HAL (or LL) for counter depends on full libc? best regards Jan
|
||||
|
|
||||
|
Zephyr Toolchain Working Group Meeting – 18 June 2020
Rasmussen, Torsten
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 213-437-3346 United States, Los Angeles (Toll) Conference ID: 570 955 823# Local numbers | Reset PIN | Learn more about Teams | Meeting options ________________________________________________________________________________
|
||||
|
|
||||
|
Bolivar, Marti
Hi there; responses inline.
"Frederik David Damsgaard Popp via lists.zephyrproject.org" <frdm=demant.com@lists.zephyrproject.org> writes: As I understand it, I need to do at least the following things:I'm not an audio expert, but are you sure the existing audio codec API is not right? I.e. do you really need to create a new generic API in include/drivers/, not just implement API calls in drivers/audio/my_audio_driver.c or something like that? Maybe someone else can weigh in on this particular question. Either way, some details on devicetree are below. * Place the actual implementation in zephyr/drivers where the api struct is then connected to this implementationStrictly speaking, actual drivers -- as in drivers/subsystem/my_driver.c files -- are enabled using Kconfig, not devicetree. So CONFIG_MY_DRIVER=y in Kconfig means "enable my driver," which means something like "compile my_driver.c." There is a historical relationship between individual 'struct device' instances and Kconfig options which Zephyr is moving away from: https://docs.zephyrproject.org/latest/guides/kconfig/tips.html#what-not-to-turn-into-kconfig-options Please see discussion here for more details on where this is going: https://github.com/zephyrproject-rtos/zephyr/issues/10621#issuecomment-618689638 However, the "moving away" is still work in progress, so I will try to provide some more details from what I understand about the current consensus. Clarifications and corrections from others welcome. First, as you've read from the DT guide, a device driver should decide what 'struct device' instances to allocate using the devicetree. In particular, any devicetree node with the right compatible and status 'okay' should result in a struct device, *as long as the driver is enabled*. The driver being enabled (or not) depends on whether CONFIG_MY_DRIVER=y (or not). It's definitely nice to make CONFIG_MY_DRIVER default to y if any node with the right compatible has an "okay" status in the devicetree, so the build works properly by default just by setting up the right devicetree overlays which enable the relevant nodes. However, people still want to be able to set CONFIG_MY_DRIVER=n to disable a driver. There was another question on the list about substituting a different driver for the same hardware earlier this week which is a good use case for that ability. So in your case, since you are asking about PDM on nRF52832, if some node with compatible = "nordic,nrf-pdm" has status = "okay", *and* the driver is enabled with CONFIG_MY_AUDIO_DRIVER=y (for whatever you choose to call the Kconfig option), then you should create a struct device for the node so applications can get the struct device and interact with it using the right API. It looks like there is already a dts/bindings/audio/nordic,nrf-pdm.yaml file, though, so it doesn't seem like you need to define your own binding. I didn't find any drivers for it in the upstream tree, though. It's also totally OK, even recommended, to do something like this in the Kconfig file defining CONFIG_MY_AUDIO_DRIVER: # Workaround for not being able to have commas in macro arguments DT_COMPAT_NORDIC_NRF_PDM := nordic,nrf-pdm config MY_AUDIO_DRIVER bool default $(dt_compat_enabled,$(DT_COMPAT_NORDIC_NRF_PDM)) help Enable my audio driver. This uses the dt_compat_enabled() kconfigfunction to set the default value of MY_AUDIO_DRIVER depending on if any nodes with compatible "nordic,nrf-pdm" have status "okay" (i.e. if the compatible has any enabled nodes, hence the name). That way, as long as the right driver subsystem is enabled, your driver will be enabled by default whenever the devicetree says the hardware is there and enabled. In the driver subsystem CMakeLists.txt file, you should add something like this to compile my_audio_driver.c based on the value of CONFIG_MY_AUDIO_DRIVER: zephyr_library_sources_ifdef(CONFIG_MY_AUDIO_DRIVER my_audio_driver.c) See e.g. drivers/spi/CMakeLists.txt for an example; the right CMake extension function to use can depend on how the CMakeLists.txt is set up. Finally, the source file my_audio_driver.c itself should decide what struct devices to instantiate using the final devicetree, as you've read about in the devicetree guide. See drivers/pwm/pwm_nrfx.c for an nRF-based example that does the right thing in my opinion. To summarize: - The soc.dtsi file just declares that the chip has some hardware by defining a node or nodes for it; that's a question of hardware, not software, and drivers are software. The soc.dtsi file can set the compatible property on a node to say what kind of hardware it represents. In some cases on Nordic hardware, a node's compatible is left for the user to pick. This happens when one ID in the product specification's instantiation table can be used in multiple ways, see e.g. i2c0 in nrf52832.dtsi, which could be set to nordic,nrf-twi or nordic-nrf-twim depending on what the user wants. That's not the case with the PDM peripheral on nRF52832, though. - The BOARD.dts file has the option of setting the status property for some nodes if the board's maintainer wants to; setting status to "disabled" usually means software should ignore that hardware completely, even though it knows it's "there." But status = "okay" doesn't say what software driver to use for that hardware, because again DT is for describing hardware. - Only Kconfig can say "compile this driver for this hardware." It's good if Kconfig takes clues from the devicetree to decide when to do that by default, but the user must remain in control and able to override that default decision. I know the tree is not consistent in implementing the above "vision," but I hope the examples and links help. Please let me know if that's not clear. Additionally I would like to ask (and I don't know whether this is thePatches are generally welcome, just make sure you follow the contributing guide, and it can't hurt to ask around like you are doing here. You never know what other people might be doing. I would then make a small sample, and document in accordance with theIf you're planning on upstreaming this, I would make sure to figure out who the right maintainers are to decide the API that should be used or if a new API is really needed. Defining a new API is harder and takes more work and coordination than writing a driver for an existing API. The devel list is a good place to ask about this. You're doing the right thing (but I don't know the answer about what API to use). Thanks in advance!You're welcome, Martí
|
||||
|
|
||||
|
Re: problems building a BME680 app: zephyr_prebuilt.elf uses VFP register arguments ....
I experienced the same ABI issue linking an existing library when moving from Zephyr v2.2.0 to Zephyr v2.3.0.
In addition to the suggestions Charles made: CONFIG_FP_SOFTABI=y
or
CONFIG_FP_HARDABI=y
in your prj.conf.
I also had to add
CONFIG_FPU=y
to my prj.conf so that I could link an existing library to a newly compiled project.
|
||||
|
|
||||
|
Buildkite CI service transition
Kumar Gala
All,
We have been looking CI solutions due to some changes in the service we’ve been provided by shippable. One of the options we’ve been testing is Buildkite. As such you’ve probably seen a GitHub status for buildkite. We have setup things such that Shippable status is still considered required and the buildkite status is optional at this stage. One thing is that any PR that was submitted before the buildkite infrastructure was committed into the master needs to be rebased on master to get the buildkite files. You can tell if <ZEPHYROOT>/.buildkite/pipeline.yml exists for you. If you have any questions you can find me either via email or on slack on the #infrastructure channel. Thanks - k
|
||||
|
|
||||
|
Dev-Review Meeting Agenda Jun 18
Kumar Gala
Here’s the agenda topics for this week:
NOTE: Carles will be running this weeks meeting as I will not be able to attend to. * Continue (and hopefully closure) on constify of struct device: https://github.com/zephyrproject-rtos/zephyr/issues/22941 https://github.com/zephyrproject-rtos/zephyr/issues/26072 https://github.com/zephyrproject-rtos/zephyr/issues/26073 * Any PR/issues w/dev-review tag * Any topics anyone else has. - k
|
||||
|
|
||||
|
Hello Zephyr development community. For this, I will need to sample audio from a MEMS PDM microphone, on the same board. I have read the Device Tree guide on the official documentation, and I think I have a basic understanding for how this needs to be done. As I understand it, I need to do at least the following things:
This is how far I have gotten yet, and was wondering if I have missed anything? Additionally I would like to ask (and I don't know whether this is the right forum), if there is any possibility that this is pushed to the official upstream, if I succeed?
|
||||
|
|
||||
|
Upcoming Event: Zephyr Project: APIs - Tue, 06/16/2020 4:00pm-5:00pm, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: APIs When: Tuesday, 16 June 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
________________________________________________________________________________
|
||||
|
|
||||
|
Need help in configuring ip address from telnet or ssh#networking
giriprasad@...
Hi Team,
Following is my requirement, please go through and please suggest a possible method for me. I had PCA10056(NRF52840) board with me. It will be having a default IPV4 address when the device gets booted. My requirement is that the user should be able to set the ip_address of his preference to the board at run time. He can use telnet or ssh or any other protocol with an ethernet interface. Please suggest the possible solution for this requirement. Thanks & Regards, Giri Prasad N.
|
||||
|
|
||||
|
API meeting: agenda
Carles Cufi
Hi all,
Today's topics: - device struct and constness - Issue https://github.com/zephyrproject-rtos/zephyr/issues/22941 - PR https://github.com/zephyrproject-rtos/zephyr/pull/26127 - Extend the sensor API with function for getting the value of a sensor attribute - Issue https://github.com/zephyrproject-rtos/zephyr/issues/26167 - PR https://github.com/zephyrproject-rtos/zephyr/pull/26166 Additional items in the "Triage" column in the GitHub project may be discussed if time permits. If you want an item included in the meeting, please add it to the GitHub project. 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 Regards, Carles
|
||||
|
|
||||
|
Re: Contribution code for our platform
thanks for your reply.
We will offer more our chip's information in the furture, and we are preparing some documents for public release. Currently, we offer basic information (ex.support feature, hardwares, .... ) in the index.rst, and one board's photo. And excuese me, does the HAL means the driver porting under the driver folder? if it is. We have. We have already completed some feature such as interrupt, timer, uart.....and we will submit at the same time. License will follow zephyr ( Apache 2.0 license ) BR,
|
||||
|
|
||||
|
Re: Contribution code for our platform
Kumar Gala
On Jun 15, 2020, at 2:14 AM, cheryl.su@ite.com.tw wrote:There shouldn’t be an issue as long as you are willing to support the code associated with your SoC. Do you expect documentation to be public at some point? Are you able to share any specific details of the SoC like a block diagram? Do you guys have a HAL for drivers? If so what kinda of license are these drivers under? - k
|
||||
|
|
||||
|
Re: Contribution code for our platform
Henrik Brix Andersen
Hi Cheryl,
toggle quoted messageShow quoted text
That sounds very interesting. Looking forward to seeing your contribution! Best regards, Brix -- Henrik Brix Andersen
On 15 Jun 2020, at 09.14, cheryl.su@ite.com.tw wrote:
|
||||
|
|
||||
|
Contribution code for our platform
cheryl.su@...
Hi all,
We are ITE and we want to submit our chip support to the upstream. Our business partners have ever mentioned it in your weekly process meeting. He says you are compleatedly OK eventhough our chip hasn't been release yet. We appreciated for it! Our Chip platform is called "IT8XXX2_evb" and it's RISCV32 base. We will submit our code to zephyr git in this or next week. Thanks for your review! best regards, Cheryl Su ITE Tech. INC
|
||||
|
|
||||
|
Post 2.3.0 PR merging
Carles Cufi
Hi all,
We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2. Help reviewing those PRs is greatly appreciated: https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse Thanks, Carles
|
||||
|
|
||||
|
Upcoming Event: Zephyr Project: Dev Meeting - Thu, 06/11/2020 3:00pm-4:00pm, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: Dev Meeting When: Thursday, 11 June 2020, 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
________________________________________________________________________________
|
||||
|
|
||||
|
Re: Zephyr Toolchain Working Group Meeting – 11 June 2020 postponed to 18 June 2020
Carles Cufi
I see no toolchain meeting today but one next week, on the 18th, which is what Torsten intended:
From: devel@... <devel@...>
On Behalf Of Thomas Törnblom via lists.zephyrproject.org
Sent: 11 June 2020 15:56 To: devel@... Subject: Re: [Zephyr-devel] Zephyr Toolchain Working Group Meeting – 11 June 2020 postponed to 18 June 2020
I still see the old calendar entry and not the new one. Den 2020-06-11 kl. 15:45, skrev Danny Ørndrup (DAOR) via lists.zephyrproject.org:
--
|
||||
|
|
||||
|
Re: Zephyr Toolchain Working Group Meeting – 11 June 2020 postponed to 18 June 2020
Thomas Törnblom
I still see the old calendar entry and not the new one.
toggle quoted messageShow quoted text
Thomas Den 2020-06-11 kl. 15:45, skrev Danny
Ørndrup (DAOR) via lists.zephyrproject.org:
--
Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom@... Website: www.iar.com Twitter: www.twitter.com/iarsystems
|
||||
|
|
||||
|
Re: Zephyr Toolchain Working Group Meeting – 11 June 2020 postponed to 18 June 2020
Danny Ørndrup (DAOR)
Hi Carles,
Thanks.
Strange, that is not reflected in my calendar, which is linked to the zephyr calendar, but that must be a problem on my end though.
Regards, Danny
From: Cufi, Carles <Carles.Cufi@...>
Sent: 11. juni 2020 15:35 To: Danny Ørndrup (DAOR) <daor@...>; Rasmussen, Torsten <Torsten.Rasmussen@...>; devel@... Subject: RE: [Zephyr-devel] Zephyr Toolchain Working Group Meeting – 11 June 2020 postponed to 18 June 2020
Hi Danny,
The calendar was updated earlier today.
Carles
From:
devel@... <devel@...>
On Behalf Of Danny Ørndrup (DAOR) via lists.zephyrproject.org
Hi Torsten,
Could you update the calendar? If not already done. I believe that many will miss out, if the calendar does not reflect the rescheduling of the meeting.
Regards, Danny
Today’s meeting has been postponed to 18 June.
Sorry for the late notice.
See you all in a weeks’ time from now.
Best regards
Torsten T. Rasmussen
Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r ________________________________________________________________________________
+1 213-437-3346 United States, Los Angeles (Toll) Conference ID: 570 955 823# Local numbers | Reset PIN | Learn more about Teams | Meeting options ________________________________________________________________________________
|
||||
|
|
||||
|
Re: Zephyr Toolchain Working Group Meeting – 11 June 2020 postponed to 18 June 2020
Carles Cufi
Hi Danny,
The calendar was updated earlier today.
Carles
From: devel@... <devel@...>
On Behalf Of Danny Ørndrup (DAOR) via lists.zephyrproject.org
Sent: 11 June 2020 14:45 To: Rasmussen, Torsten <Torsten.Rasmussen@...>; devel@... Subject: Re: [Zephyr-devel] Zephyr Toolchain Working Group Meeting – 11 June 2020 postponed to 18 June 2020
Hi Torsten,
Could you update the calendar? If not already done. I believe that many will miss out, if the calendar does not reflect the rescheduling of the meeting.
Regards, Danny
Today’s meeting has been postponed to 18 June.
Sorry for the late notice.
See you all in a weeks’ time from now.
Best regards
Torsten T. Rasmussen
Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r ________________________________________________________________________________
+1 213-437-3346 United States, Los Angeles (Toll) Conference ID: 570 955 823# Local numbers | Reset PIN | Learn more about Teams | Meeting options ________________________________________________________________________________
|
||||
|
|
