Date   

Upcoming Event: Zephyr: Toolchain Working Group - Thu, 06/25/2020 2:00pm-3:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr: Toolchain Working Group

When: Thursday, 25 June 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:

________________________________________________________________________________
+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 – 25 June 2020

Rasmussen, Torsten
 


Agenda

  • Updates:
  • Short term goals, way forward
    • Dedicated toolchain test cases.
    • Label PR for automatic execution of CI Toolchain test cases

 

 

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

________________________________________________________________________________

 

Join Microsoft Teams Meeting

+1 321-558-6518 United States, Orlando (Toll)

Conference ID: 682 738 030#

Local numbers | Reset PIN | Learn more about Teams | Meeting options

 

________________________________________________________________________________

 

           

 


Re: Zephyr HCI Mesh Support

Johan Hedberg
 

Hi Vivek,

On 23. Jun 2020, at 20.32, Vivek Rajpara via lists.zephyrproject.org <vivek.rajpara=volansystech.com@...> wrote:
We are looking for the solution where we need to use Meshctl on Linux host and control the Zephyr based BT with it, can you please let us know if this support is enabled in Zephyr or not?
Looking forward to hearing from you as it is a crucial design factor for us.

Below is our setup
nrf52840(as BT HCI controller) + Arm processor with Linux (we are using bluez 5.50 meshctl tool)

I can see BT_HCI_MESH_EXT config, but it can't be enabled from menuconfig, I tried to enable it in project configuration but still, I can't send any command from meshctl to zephyr yet.
As far as I know, the BT_HCI_MESH_EXT option is for HCI vendor extensions which haven’t been implemented yet. However, BlueZ doesn’t require or even support them, so this should be a non-issue, meaning you should be able to use BlueZ (and its mesh stack) just fine with the Zephyr controller.

Johan


Re: Bluetooth mesh and Central role simultaneously #bluetoothmesh #bluetooth

Johan Hedberg
 

Hi Andreas,

On 11. Jun 2020, at 11.37, Andreas <andreas.schmidt@...> wrote:
So my question: is the scenario to run Bluetooth mesh and Central GAP role simultaneously supported by Bluetooth Low Energy standard?
If so, is such scenario also supported by the Zephyr Bluetooth stack?

There’s nothing in the standard that prohibits it, but it will reduce the efficiency of the mesh network. The mesh advertising bearer is designed in such a way that assumes the nodes to be scanning as close as possible to 100% duty cycle (LPN nodes are an exception). Any connections that you do will reduce the time the controller can spend scanning, and hence reduce the duty cycle.

Currently the Zephyr mesh stack is designed so that it assumes ownership of the advertising and scanning operations, which is why you’ll easily get conflicts and errors if you try to do those yourself. We do have plans to improve this co-existence with the help of multiple advertising instances, but we don’t yet have support for this in the native Zephyr controller (AFAIK). That still wouldn’t help with the central role though, and for that we have plans to introduce HCI-extensions so that the controller would be aware of Mesh-specific scanning and legacy scanning. However, I don’t think there’s any timeline or commitment to getting it done.

To implement what you need with the current stack, and without compromising the efficiency of the mesh network, I’d suggest to consider a HW setup where you have two controllers: one dedicated for mesh and another for the central role.

Johan


Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 25 June 2020 #cal-cancelled

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

Cancelled: Zephyr Project: Dev Meeting

This event has been cancelled.

When:
Thursday, 25 June 2020
3:00pm to 4: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
 
 
________________________________________________________________________________


coverarage

novello
 

sanitycheck --coverage -p native_posix -T tests/bluetooth
Doesen't work with this error.
why ?


Zephyr HCI Mesh Support

Vivek Rajpara <vivek.rajpara@...>
 

Hello,

We are looking for the solution where we need to use Meshctl on Linux host and control the Zephyr based BT with it, can you please let us know if this support is enabled in Zephyr or not?
Looking forward to hearing from you as it is a crucial design factor for us.

Below is our setup
nrf52840(as BT HCI controller)  + Arm processor with Linux (we are using bluez 5.50 meshctl tool)

I can see BT_HCI_MESH_EXT config, but it can't be enabled from menuconfig, I tried to enable it in project configuration but still, I can't send any command from meshctl to zephyr yet.

Thanks in advance.
Regards,
Vivek Rajpara
Volansys Technologies Pvt. Ltd.
ISO 9001:2015 Certified
volansys technologies pvt. ltd.
www.volansys.com


This message contains confidential information and is for the intended recipients. If you are not intended recipients you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender or VOLANSYS (www.volansys.com) therefore does not accept liability for any errors or omissions in the contents of this message.


Upcoming Event: Zephyr Project: APIs - Tue, 06/23/2020 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: APIs

When: Tuesday, 23 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
 
 
________________________________________________________________________________


API meeting: agenda

Carles Cufi
 


Re: stm32h7xx REQUIRES_FULL_LIBC

Jan Pohanka
 

Hello Andy,
Thank you for your investigation. In that case REQUIRES_FULL_LIBC
really does not make sense for STM32H7xx SOC. Actually I do not need
the RTC driver so good for me :)

best regards
Jan

čt 18. 6. 2020 v 14:50 odesílatel Andy Ross <andrew.j.ross@...> napsal:


That sounded curious, so I checked. It looks like the STM32 RTC driver you found is an old-style y/m/d/h/m/s device with separate fields, and the driver is using mktime() to convert those to a linear value for use by the rest of the system. Zephyr's minimal libc doesn't have mktime().

But mktime() is pretty small and simple on its own, even with leap day handling (if the device does that). Dealing with timezones gets crazy, but I don't see any zone management in the driver and am guessing the device doesn't bother to store one (i.e. the value isn't "real" anyway, it just presents a number relative to some consistent zero). It seems like it would be very feasible for someone to add that logic to the driver, or even contribute a generic GMT-based mktime() to Zephyr.

Andy

On 6/18/2020 5:14 AM, Jan Pohanka wrote:
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




Upcoming Event: Zephyr Project: Dev Meeting - Thu, 06/18/2020 3:00pm-4:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 18 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
 
 
________________________________________________________________________________


Zephyr: Toolchain Working Group - Thu, 06/18/2020 #cal-notice

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

Zephyr: Toolchain Working Group

When:
Thursday, 18 June 2020
2:00pm to 3:00pm
(GMT+00:00) UTC

Where:
Microsoft Teams Meeting

Description:

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


Upcoming Event: Zephyr: Toolchain Working Group - Thu, 06/18/2020 2:00pm-3:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr: Toolchain Working Group

When: Thursday, 18 June 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:

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


Re: stm32h7xx REQUIRES_FULL_LIBC

Andy Ross
 

That sounded curious, so I checked.   It looks like the STM32 RTC driver you found is an old-style y/m/d/h/m/s device with separate fields, and the driver is using mktime() to convert those to a linear value for use by the rest of the system.  Zephyr's minimal libc doesn't have mktime().

But mktime() is pretty small and simple on its own, even with leap day handling (if the device does that).  Dealing with timezones gets crazy, but I don't see any zone management in the driver and am guessing the device doesn't bother to store one (i.e. the value isn't "real" anyway, it just presents a number relative to some consistent zero).  It seems like it would be very feasible for someone to add that logic to the driver, or even contribute a generic GMT-based mktime() to Zephyr.

Andy

On 6/18/2020 5:14 AM, Jan Pohanka wrote:
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



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
 


Agenda

  • Updates:
  • Short term goals, way forward
    • Dedicated toolchain test cases.
    • Label PR for automatic execution of CI Toolchain test cases

 

 

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

________________________________________________________________________________

 

Join Microsoft Teams Meeting

+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: Adding support for Nordic PDM Driver in Devicetree #pdm #driver #nrf52832

Bolivar, Marti
 

Hi there; responses inline.

"Frederik David Damsgaard Popp via lists.zephyrproject.org"
<frdm=demant.com@...> writes:

As I understand it, I need to do at least the following things:

* Create the generic api as well as the api struct, located in
zephyr/include/drivers.
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 implementation
Additionally, setup the config variables in the *Kconfig* file in the same directory, as well as connecting the source code using *CMakeLists.txt*
* Create a YAML driver binding in zephyr/dts/bindings.
* Bind the driver in the *nrf52832.dtsi* file, in order to make the SoC compatible with this driver.
* Enable the driver in the *nrf52_pca20020.dts* file, in order to make
the board able to use the driver.
Strictly 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.


This is how far I have gotten yet, and was wondering if I have missed anything?
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 the
right forum), if there is any possibility that this is pushed to the
official upstream, if I succeed?
Patches 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 the
guidelines, so that others may also use it.
If 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 ....

Lawrence King
 

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