Date   

Re: SDK migration 0.9.5 -> 0.10.0 increase CPU usage

Nashif, Anas
 

Nicolas,

Which architecture? I did not see any issues.

 

Anas

 

From: devel@... [mailto:devel@...] On Behalf Of nicolas lantz
Sent: Wednesday, March 27, 2019 9:37 AM
To: devel@...
Subject: [Zephyr-devel] SDK migration 0.9.5 -> 0.10.0 increase CPU usage

 

Hi all,

I just migrate from SDK 0.9.5 to SDK 0.10.0 on my projet and i have between 40% to 90% of additional CPU usage with the new toolchain on the audio compression and decompression tasks (using opus codec).

This over cpu consumption append both with build optimisation configured in debug and speed mode.

Does anyone have some any info or explanation ?

Thanks

-- 
Nicolas
 
Nicolas LANTZ
M : +33 (0)6 19 07 43 43
T : +33 (0)9 52 96 81 86
www.ubicore.net


SDK migration 0.9.5 -> 0.10.0 increase CPU usage

nicolas lantz
 

Hi all,

I just migrate from SDK 0.9.5 to SDK 0.10.0 on my projet and i have between 40% to 90% of additional CPU usage with the new toolchain on the audio compression and decompression tasks (using opus codec).

This over cpu consumption append both with build optimisation configured in debug and speed mode.

Does anyone have some any info or explanation ?

Thanks
-- 
Nicolas

Nicolas LANTZ
M : +33 (0)6 19 07 43 43
T : +33 (0)9 52 96 81 86
www.ubicore.net


Re: v1.14.0-rc3 release

Kumar Gala
 

Doc updates will still be acceptable, but please tag them with v1.14 milestone & doc label.

- k

On Mar 27, 2019, at 2:37 AM, Erwan Gouriou <erwan.gouriou@linaro.org> wrote:

Hi Kumar,

What about doc PRs?

Thanks
Erwan


On Tue, 26 Mar 2019 at 20:17, Kumar Gala <kumar.gala@linaro.org> wrote:
All,

I plan on making a -rc3 release at the end of the day on Thursday (Mar 28). After which only Bug fix PRs that have an associated GitHub issue will be merged.

Again, please tag any PRs with the v1.14 milestone and with ‘bug’ label.

thanks

- k


Fix Bugs, Win Boards

Thea Aldrich
 

Hi Zephyr Community,
I wanted to signal boost the bug fixing contest we launched yesterday on the Zephyr website. 

"To show our appreciation, the Zephyr Project will be sending the 5 contributors with the most bugs fixed in Zephyr OS 1.14 an i.MX RT1050 from our Platinum member NXPTo be eligible to win one of the i.MX RT1050 please send a list of all your closed bugs and issues to info@.... Be sure to include your name and links to the bugs you are responsible for fixing between October 2018 and the release of Zephyr OS 1.14 in mid April 2019. Zephyr Project TSC members are not eligible for this contest. Non-TSC members from Zephyr Project member companies are welcome and encouraged to participate."

A huge thank you goes out to the team at NXP for providing these boards to the community. Thanks to their donation we will have additional boards available to give out to the most active community contributors throughout the summer! Stay tuned to the Zephyr blog and this list for more information about those contests. 

Please let me know if you have any questions about this contest or need assistance with your entry.
Best,
Thea


Re: v1.14.0-rc3 release

Erwan Gouriou
 

Hi Kumar,

What about doc PRs?

Thanks
Erwan


On Tue, 26 Mar 2019 at 20:17, Kumar Gala <kumar.gala@...> wrote:
All,

I plan on making a -rc3 release at the end of the day on Thursday (Mar 28).  After which only Bug fix PRs that have an associated GitHub issue will be merged.

Again, please tag any PRs with the v1.14 milestone and with ‘bug’ label.

thanks

- k



v1.14.0-rc3 release

Kumar Gala
 

All,

I plan on making a -rc3 release at the end of the day on Thursday (Mar 28). After which only Bug fix PRs that have an associated GitHub issue will be merged.

Again, please tag any PRs with the v1.14 milestone and with ‘bug’ label.

thanks

- k


Re: How to enable DMA transfers for UART?

Li, Jun R
 

Hi Stefan and Erwan,

I’m rebasing my previous implementations to the latest master branch and you can find it here: https://github.com/zephyrproject-rtos/zephyr/pull/14916

I’m still working on it since it is still lacking a couple of things and there are some bugs affecting RX. But the basic idea is to use UART IDLE to define the end of a RX DMA transaction.

 

If you think it is worth keeping going, let’s work together to make it happen.

 

Best Regards,

Jun

 

 

 

 

 

From: Erwan Gouriou <erwan.gouriou@...>
Date: Tuesday, March 26, 2019 at 08:10
To: Stefan Jaritz <stefan@...>
Cc: Paul Sokolovsky <paul.sokolovsky@...>, devel <devel@...>, John J Li <jun.r.li@...>
Subject: Re: [Zephyr-devel] How to enable DMA transfers for UART?

 

Hi Stefan,

 

On Tue, 26 Mar 2019 at 13:01, Stefan Jaritz <stefan@...> wrote:

Hey

I done a demo driver implementation:

https://github.com/StefJar/zephyr_stm32_uart3_dma_driver

Some problems I was facing:

- DMA API: the current one doesn't support ring buffer setups

- UART API: the current API is not mapping the IDLE event.

- UART API: no callbacks possible for event driven rx

With the current design of the UART and DMA API it seems to be
challenging to get a nice fusion.

So I was implementing a simple API for the demo, making block writes
possible and calling a callback when data is received. I didn't used the
UART and DMA API because it would became a dirty hack, while calling
functions form that API & overwriting/patching the ISRs. So I decided
for a lean straight forward implementation.

Thanks for sharing code and experience, this is useful!

 

In my case I am interested into SPI + DMA and USB ACM + DMA. From an
energy perspective it is much better to use DMA transfers for the
peripheral IOs (We can put the MCU to sleep).

Indeed, we should have a proper DMA driver that could be called from other drivers.

 

Maybe it is worth to put a thought on using DMA for peripherals by
default and only the special case is doing polling or RX/TX handling via
uart etc. ISRs.

While I agree DMA has numerous benefits, I don't think this should be the only configuration,

nor the default one. Main issue is initial complexity and configuration needs.

People should be able to use the async API first and then enable DMA once they feel comfortable

with the API.

 

 Erwan

 

Stefan

On 20/03/2019 15:37, Paul Sokolovsky wrote:
> Hello Stefan,
>
> On Tue, 19 Mar 2019 15:18:02 +0000
> "Stefan Jaritz" <stefan@...> wrote:
>
>> Hey,
>>
>> I am currently experimenting with ZephyrOS on different tasks. My
>> base is an own dev board which has a stm32f4xx MCU that connects
>> different ICs etc. via UART, I2C, SPI & GPIOs.
>>
>> Currently the UART ISR is too slow to catch all chars at a rx burst.
>> Usually I am using UART + DMA transfers to relieve the MCU and save
>> energy.
>>
> []
>
>> So I am asking for help or some example how to do an UART & DMA.
>>
>> Think having an ringbuffer for rx and an intr firing after n Bytes
>> received via DMA. Also doing the tx via DMA would be perfect. Any
>> ideas to setup the Zephyr drivers to do so?
> Recently, a new "async" UART API was added to Zephyr, whose
> implementation could leverage DMA support (that was one of usecases for
> this API). There's an open ticket to implement it for STM32:
> https://github.com/zephyrproject-rtos/zephyr/issues/13955
>
> You're welcome to cooperate with the STM32 maintainers on implementing
> it.
>
> []
>


Re: How to enable DMA transfers for UART?

Erwan Gouriou
 

Hi Stefan,

On Tue, 26 Mar 2019 at 13:01, Stefan Jaritz <stefan@...> wrote:
Hey

I done a demo driver implementation:

https://github.com/StefJar/zephyr_stm32_uart3_dma_driver

Some problems I was facing:

- DMA API: the current one doesn't support ring buffer setups

- UART API: the current API is not mapping the IDLE event.

- UART API: no callbacks possible for event driven rx

With the current design of the UART and DMA API it seems to be
challenging to get a nice fusion.

So I was implementing a simple API for the demo, making block writes
possible and calling a callback when data is received. I didn't used the
UART and DMA API because it would became a dirty hack, while calling
functions form that API & overwriting/patching the ISRs. So I decided
for a lean straight forward implementation.

Thanks for sharing code and experience, this is useful!
 
In my case I am interested into SPI + DMA and USB ACM + DMA. From an
energy perspective it is much better to use DMA transfers for the
peripheral IOs (We can put the MCU to sleep).

Indeed, we should have a proper DMA driver that could be called from other drivers.

Maybe it is worth to put a thought on using DMA for peripherals by
default and only the special case is doing polling or RX/TX handling via
uart etc. ISRs.

While I agree DMA has numerous benefits, I don't think this should be the only configuration,
nor the default one. Main issue is initial complexity and configuration needs.
People should be able to use the async API first and then enable DMA once they feel comfortable
with the API.

 Erwan

Stefan

On 20/03/2019 15:37, Paul Sokolovsky wrote:
> Hello Stefan,
>
> On Tue, 19 Mar 2019 15:18:02 +0000
> "Stefan Jaritz" <stefan@...> wrote:
>
>> Hey,
>>
>> I am currently experimenting with ZephyrOS on different tasks. My
>> base is an own dev board which has a stm32f4xx MCU that connects
>> different ICs etc. via UART, I2C, SPI & GPIOs.
>>
>> Currently the UART ISR is too slow to catch all chars at a rx burst.
>> Usually I am using UART + DMA transfers to relieve the MCU and save
>> energy.
>>
> []
>
>> So I am asking for help or some example how to do an UART & DMA.
>>
>> Think having an ringbuffer for rx and an intr firing after n Bytes
>> received via DMA. Also doing the tx via DMA would be perfect. Any
>> ideas to setup the Zephyr drivers to do so?
> Recently, a new "async" UART API was added to Zephyr, whose
> implementation could leverage DMA support (that was one of usecases for
> this API). There's an open ticket to implement it for STM32:
> https://github.com/zephyrproject-rtos/zephyr/issues/13955
>
> You're welcome to cooperate with the STM32 maintainers on implementing
> it.
>
> []
>




SPI slave on nRF52840-PCA10059 #nrf52480

Riccardo
 

Hi all,

I’m trying to get a simple SPI slave application running on nRF52840-PCA10059 dongle. So far, no success. I tried a couple of things that all lead to compilation error of the kind “symbol undeclared…”. Here’s how to reproduce:

riccardo@debian:~/zephyr_builds$ cp -r /media/sf_zephyr/samples/bluetooth/hci_spi/ .
riccardo@debian:~/zephyr_builds/hci_spi$ mkdir b
riccardo@debian:~/zephyr_builds/hci_spi$ cd b
riccardo@debian:~/zephyr_builds/hci_spi/b$ cmake -GNinja -DBOARD=nrf52840_pca10059 ..
riccardo@debian:~/zephyr_builds/hci_spi/b$ ninja

see error_hci_spi.txt (attached) for the errors.

I also tried to start from a blinky application, and enable SPI in menuconfig. If I enable

Device Drivers → SPI hardware bus support → nRF SPI nrfx drivers → SPI Port 1 Driver type → nRF SPIM 1, everything is cool. If I enable
Device Drivers → SPI hardware bus support → nRF SPI nrfx drivers → SPI Port 1 Driver type → nRF SPIS 1, I got errors as attached in error_spi_slave.txt

The symbols it mentioned are defined in an autogenerated .h, that seems to be ignored somehow.

Do you know what's going on?

Regards,
Riccardo


SPI slave on nRF52840-PCA10059 #nrf52480

Cavallari, Riccardo <riccardo.cavallari@...>
 

Hi all,

I’m trying to get a simple SPI slave application running on nRF52840-PCA10059 dongle. So far, no success. I tried a couple of things that all lead to compilation error of the kind “symbol undeclared…”. Here’s how to reproduce:

riccardo@debian:~/zephyr_builds$ cp -r /media/sf_zephyr/samples/bluetooth/hci_spi/ .
riccardo@debian:~/zephyr_builds/hci_spi$ mkdir b
riccardo@debian:~/zephyr_builds/hci_spi$ cd b
riccardo@debian:~/zephyr_builds/hci_spi/b$ cmake -GNinja -DBOARD=nrf52840_pca10059 ..
riccardo@debian:~/zephyr_builds/hci_spi/b$ ninja

see error_hci_spi.txt (attached) for the errors.

I also tried to start from a blinky application, and enable SPI in menuconfig. If I enable

Device Drivers → SPI hardware bus support → nRF SPI nrfx drivers → SPI Port 1 Driver type → nRF SPIM 1, everything is cool. If I enable
Device Drivers → SPI hardware bus support → nRF SPI nrfx drivers → SPI Port 1 Driver type → nRF SPIS 1, I got errors as attached in error_spi_slave.txt

The symbols it mentioned are defined in an autogenerated .h, that seems to be ignored somehow.

Do you know what's going on?

Regards,
Riccardo


Re: How to enable DMA transfers for UART?

Stefan Jaritz
 

Hey

I done a demo driver implementation:

https://github.com/StefJar/zephyr_stm32_uart3_dma_driver

Some problems I was facing:

- DMA API: the current one doesn't support ring buffer setups

- UART API: the current API is not mapping the IDLE event.

- UART API: no callbacks possible for event driven rx

With the current design of the UART and DMA API it seems to be challenging to get a nice fusion.

So I was implementing a simple API for the demo, making block writes possible and calling a callback when data is received. I didn't used the UART and DMA API because it would became a dirty hack, while calling functions form that API & overwriting/patching the ISRs. So I decided for a lean straight forward implementation.

In my case I am interested into SPI + DMA and USB ACM + DMA. From an energy perspective it is much better to use DMA transfers for the peripheral IOs (We can put the MCU to sleep).

Maybe it is worth to put a thought on using DMA for peripherals by default and only the special case is doing polling or RX/TX handling via uart etc. ISRs.

Stefan

On 20/03/2019 15:37, Paul Sokolovsky wrote:
Hello Stefan,

On Tue, 19 Mar 2019 15:18:02 +0000
"Stefan Jaritz" <stefan@kokoontech.com> wrote:

Hey,

I am currently experimenting with ZephyrOS on different tasks. My
base is an own dev board which has a stm32f4xx MCU that connects
different ICs etc. via UART, I2C, SPI & GPIOs.

Currently the UART ISR is too slow to catch all chars at a rx burst.
Usually I am using UART + DMA transfers to relieve the MCU and save
energy.
[]

So I am asking for help or some example how to do an UART & DMA.

Think having an ringbuffer for rx and an intr firing after n Bytes
received via DMA. Also doing the tx via DMA would be perfect. Any
ideas to setup the Zephyr drivers to do so?
Recently, a new "async" UART API was added to Zephyr, whose
implementation could leverage DMA support (that was one of usecases for
this API). There's an open ticket to implement it for STM32:
https://github.com/zephyrproject-rtos/zephyr/issues/13955

You're welcome to cooperate with the STM32 maintainers on implementing
it.

[]


Particle Xenon SPI ports

Marcio Montenegro
 

Hi all,
I am developing a new project using Particle Xenon and SPI port 1.
According docs Xenon has 3 dtsi files and  SPI1 is selectable with overlay (SPI).

mesh_feather_spi_spi1.dtsi exposes SPI1 on labeled Feather SPI pins
mesh_feather_spi_spi3.dtsi exposes SPI3 on labeled Feather SPI pins
mesh_feather_spi1_spi3.dtsi exposes SPI3 on labeled Feather SPI1 pins

I'm confused about which pins I should use.The Xenon datasheet shows SPI and SPI3 and not SPI1 .Best regards,

Marcio



Re: One-for-all overlay file for each sensor

Jukka Rissanen
 

Hi Aaron,

I have similar needs for networking overlay config files which are
typically the same. I created enhancement req in
https://github.com/zephyrproject-rtos/zephyr/issues/14740 for tracking
this. Please comment there if needed.


Cheers,
Jukka

On Tue, 2019-03-26 at 10:45 +0800, Aaron Xu wrote:
Hi,

For evaluating sensor samples, I need to add overlay file for every
board into every sample. But the content of the overlay file is
almost the same, for example :
'''
&i2c0 {
hts221@5f {
compatible = "st,hts221";
reg = <0x5f>;
label = "HTS221";
};
};
'''
Only different is the overlay file's name, and need to adapt i2c
interface for different boards sometimes. After that we can fetch
data in polling mode at least.

As most of those sensors support i2c interface or SPI or both, I
think we can simplify this process with the standard interface name,
like arduino_i2c/arduino_spi. And save user's time for creating such
kind of overlay files.

Can I have a one-for-all overlay file for each sensor, which I don't
need to specify the board's name?


One-for-all overlay file for each sensor

Aaron Xu
 

Hi,

For evaluating sensor samples, I need to add overlay file for every board into every sample. But the content of the overlay file is almost the same, for example :
'''
&i2c0 {
hts221@5f {
        compatible = "st,hts221";
        reg = <0x5f>;
        label = "HTS221";
    };
};
'''
Only different is the overlay file's name, and need to adapt i2c interface for different boards sometimes. After that we can fetch data in polling mode at least.

As most of those sensors support i2c interface or SPI or both, I think we can simplify this process with the standard interface name, like arduino_i2c/arduino_spi. And save user's time for creating such kind of overlay files.

Can I have a one-for-all overlay file for each sensor, which I don't need to specify the board's name?


Re: the defect of memory pool bitmap

Nashif, Anas
 

Can you please post a PR or a bug with more information about the proposed changes below?

 

Thanks,

Anas

 

From: devel@... [mailto:devel@...] On Behalf Of ??
Sent: Monday, March 25, 2019 10:05 AM
To: devel@...
Subject: [Zephyr-devel] the defect of memory pool bitmap

 

My opinion is as follows

 


the defect of memory pool bitmap

吴升 <wusheng@...>
 

My opinion is as follows

 


Re: Get BT MAC addr in zephyr

Johan Hedberg
 

Hi Tommy,

On 25 Mar 2019, at 6.10, Tommy Lin (林志聰) <Tommy.Lin@quantatw.com> wrote:
We use Nordic 51824 with Zephyr 1.13 version.
By default, the Nordic BLE address is derived from the NRF_FICR->DEVICEADDR[] register.
We use “bluetoothctl show” and can get a random mac address.
1.I don’t know if the random mac address is from NRF_FICR->DEVICEADDR[] register ?
2.Every time , the mac address will be different value , if I delete /var/lib/Bluetooth/static-xx:xx:xx:xx:xx:xx folder and then reboot device.
I expect the random mac address from NRF_FICR->DEVICEADDR[] register should be fixed , am I right ?
It’s always the responsibility of the host to set the random address. When you do a combined build of Zephyr (both controller and host) the FICR address will be used. However, if you’re running BlueZ as the host, it’s the responsibility of BlueZ to set the random address. There’s no standard HCI command to read the FICR value from the controller. Zephyr does have HCI vendor commands for that, but if I remember right BlueZ does not support those yet. If you don’t care about the FICR address specifically, but just want a fixed static random address, then any recent bluetoothd version (>= 5.44) will generate this for you automatically (that’s the /var/lib/bluetooth/static- file that you referred to).

Johan


Get BT MAC addr in zephyr

Tommy Lin (林志聰) <Tommy.Lin@...>
 

Hi Zephyr,

We use Nordic 51824 with Zephyr 1.13 version.

By default, the Nordic BLE address is derived from the NRF_FICR->DEVICEADDR[] register.

We use “bluetoothctl show” and can get a random mac address.

1.I don’t know if the random mac address is from NRF_FICR->DEVICEADDR[] register ?

2.Every time , the mac address will be different value , if I delete /var/lib/Bluetooth/static-xx:xx:xx:xx:xx:xx folder and then reboot device.

 I expect the random mac address from NRF_FICR->DEVICEADDR[] register should be fixed , am I right ?

 

 

 

Thanks

Tommy


Use GH labels, save time

alpi@...
 

Hi,

Lots of GitHub issues and PRs are being created daily.

To help us manage them we have “labels”: to classify them by area, type, priority, or to mark them in need of attention.

 

When creating a GitHub issue or pull request, remember to add the appropriate labels.

It takes a couple of seconds.

If you are reviewing a PR, and there is missing or incorrect labels, fix it *

This will save us all time when searching,

reduce the chances of your PR/issue being forgotten,

speed up reviewing,

reduce the changes of duplicates, etc.

 

Best regards,

Alberto Escolar Piedras

 

*(1st time contributors cannot add labels)


Re: [Bluetooth Mesh] How is the correct way to make a self provision #bluetoothmesh #zephyrbluetoothmesh

Johan Hedberg
 

Hi Lucas,

(added zephyr-devel back to CC since this info may benefit others as well)

On 21 Mar 2019, at 21.29, Lucas Peixoto <lucaspeixotoac@gmail.com> wrote:
Interesting, I was using this CONFIG_BT_SETTINGS because I got it on other project. I did what you said and the errors were gone, thank you, apparently is working. One more thing, this messages "<wrn> bt_mesh_cfg_cli: Unexpected App Key Status message" are normal or is missing something?
No, that’s normal. It means you used the configuration client API without requesting it to wait for the response messages from the (local) configuration server. In that case the client code considers the responses unexpected since it didn't saved any context for the pending request.

Johan

2101 - 2120 of 7936