Date   

The Zephyr Developer Summit Schedule is Live!

Maemalynn Meanor <maemalynn@...>
 

Members of the Zephyr Community: 

The schedule for the Zephyr Developer Summit, taking place on June 8-9 (with an intro to Zephyr Day on June 7) in Mountain View, California, is now live! Click here to learn more about the sessions and speakers. We are excited to see you in-person at the Computer History Museum or, if you’re attending virtually, we look forward to chatting with you after the live sessions on Discord. 

Here are a few links: 

Register for the event (early bird pricing ends April 1): https://events.linuxfoundation.org/zephyr-developer-summit/register/




Connect with us on social:  @ZephyrIoT & Zephyr LinkedIn
#ZephyrDevSummit
#ZephyrRTOS

Can’t wait to see you there!
Maemalynn

Maemalynn Meanor
Senior PR & Marketing Manager
The Linux Foundation 
ELISA, Open Mainframe Project, Zephyr Project
(602) 541-0356
@Maemalynn






Zephyr v3.1 release date moved 1 week earlier

Bolivar, Marti
 

Hi everyone,

During today's Zephyr TSC meeting, we voted to move the release date for
Zephyr v3.1 to 1 week earlier. This affects the feature freeze date as
well, by the same amount of time.

Updated dates are here:

https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management#actual-and-planned-milestone-dates

The main reason is to avoid overlap with Zephyr Developer's Summit 2022,
which conflicts with the previous release date.

Diff from the old dates is here:

https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management/_compare/261a7be2693a8e438a249616fe3e53486636b015...c4df6ea339e0d77c14a1ce8d23511667a42c066a

Thanks,
Marti and Carles
v3.1 release managers


Re: help with BLE HCI dual chip setup

Carles Cufi
 

Hi there,

 

On the board acting as a Host (i.e. the one that is running the app, not the on running hci_uart) you need to add a chosen node for  zephyr,bt-uart, like here:

 

https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm/hexiwear_k64/hexiwear_k64.dts#L29

 

More about zephyr chosen nodes here:

 

https://docs.zephyrproject.org/latest/reference/devicetree/api.html#id2

 

Carles

 

 

From: users@... <users@...> On Behalf Of Anis via lists.zephyrproject.org
Sent: 29 March 2022 23:04
To: users@...
Subject: [Zephyr-users] help with BLE HCI dual chip setup

 

Hello,
I am testing the dual chip configuration of the BLE.
I am using two nrf52dk boards and I would like to setup one as host and one as controller.
I am following the "96Boards Carbon nRF51" sample as a reference.
my goal is to use a uart for the connection between the two boards.
I was able to build the controller part of the code but failed on the host.
I am testing with the peripheral sample project.
in the boards folder I added a .conf and .overlay files for the nrf52dk.
my nrf52dk_nrf52832.overlay file is as follows

&uart0 {
    compatible = "nordic,nrf-uart";
    current-speed = <1000000>;
    status = "okay";
    hw-flow-control;
    tx-pin = <5>;
    rx-pin = <4>;
    rts-pin = <7>;
    cts-pin = <6>;
};

my nrf52dk_nrf52832.conf file is as follows

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n

 

CONFIG_SERIAL=y

CONFIG_UART_CONSOLE=n

CONFIG_USE_SEGGER_RTT=y

CONFIG_RTT_CONSOLE=y

CONFIG_LOG=y

CONFIG_LOG_DEFAULT_LEVEL=4

CONFIG_SPI_LOG_LEVEL_DBG=y

CONFIG_LOG_BACKEND_RTT=y

I added the following to prj.conf

# Incresed stack due to settings API usage

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

 

CONFIG_BT=y

CONFIG_BT_DEBUG_LOG=y

CONFIG_BT_SMP=y

CONFIG_BT_SIGNING=y

CONFIG_BT_PERIPHERAL=y

CONFIG_BT_DIS=y

CONFIG_BT_ATT_PREPARE_COUNT=5

CONFIG_BT_BAS=y

CONFIG_BT_HRS=y

CONFIG_BT_PRIVACY=y

CONFIG_BT_DEVICE_NAME="Zephyr Peripheral Sample Long Name"

CONFIG_BT_DEVICE_APPEARANCE=833

CONFIG_BT_DEVICE_NAME_DYNAMIC=y

CONFIG_BT_DEVICE_NAME_MAX=65

 

CONFIG_BT_KEYS_OVERWRITE_OLDEST=y

CONFIG_BT_SETTINGS=y

CONFIG_FLASH=y

CONFIG_FLASH_PAGE_LAYOUT=y

CONFIG_FLASH_MAP=y

CONFIG_NVS=y

CONFIG_SETTINGS=y

 

# added these to enable the BLE HCI config

CONFIG_GPIO=y

CONFIG_SERIAL=y

CONFIG_UART_INTERRUPT_DRIVEN=y

CONFIG_BT_HCI=y

CONFIG_BT_CTLR=n

the project doesn't build. it gives the following error

error: '__device_dts_ord_DT_CHOSEN_zephyr_bt_uart_ORD' undeclared (first use in this function)

 

any advice on how to fix this or how to get get a dual chip setup to work would be very appreciated.

Thanks


help with BLE HCI dual chip setup

Anis
 

Hello,
I am testing the dual chip configuration of the BLE.
I am using two nrf52dk boards and I would like to setup one as host and one as controller.
I am following the "96Boards Carbon nRF51" sample as a reference.
my goal is to use a uart for the connection between the two boards.
I was able to build the controller part of the code but failed on the host.
I am testing with the peripheral sample project.
in the boards folder I added a .conf and .overlay files for the nrf52dk.
my nrf52dk_nrf52832.overlay file is as follows

&uart0 {
    compatible = "nordic,nrf-uart";
    current-speed = <1000000>;
    status = "okay";
    hw-flow-control;
    tx-pin = <5>;
    rx-pin = <4>;
    rts-pin = <7>;
    cts-pin = <6>;
};

my nrf52dk_nrf52832.conf file is as follows

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n
CONFIG_SERIAL=y
CONFIG_UART_CONSOLE=n
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_LOG=y
CONFIG_LOG_DEFAULT_LEVEL=4
CONFIG_SPI_LOG_LEVEL_DBG=y
CONFIG_LOG_BACKEND_RTT=y

I added the following to prj.conf

# Incresed stack due to settings API usage
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048
CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_SMP=y
CONFIG_BT_SIGNING=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DIS=y
CONFIG_BT_ATT_PREPARE_COUNT=5
CONFIG_BT_BAS=y
CONFIG_BT_HRS=y
CONFIG_BT_PRIVACY=y
CONFIG_BT_DEVICE_NAME="Zephyr Peripheral Sample Long Name"
CONFIG_BT_DEVICE_APPEARANCE=833
CONFIG_BT_DEVICE_NAME_DYNAMIC=y
CONFIG_BT_DEVICE_NAME_MAX=65
CONFIG_BT_KEYS_OVERWRITE_OLDEST=y
CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y
# added these to enable the BLE HCI config
CONFIG_GPIO=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_BT_HCI=y
CONFIG_BT_CTLR=n

the project doesn't build. it gives the following error

error: '__device_dts_ord_DT_CHOSEN_zephyr_bt_uart_ORD' undeclared (first use in this function)


any advice on how to fix this or how to get get a dual chip setup to work would be very appreciated.

Thanks


Zephyr SDK 0.14.0 Release

Stephanos Ioannidis
 

Hi,

Zephyr SDK 0.14.0 has been released.

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.14.0

This is the first Zephyr SDK release to support all three major host
operating systems:

* general
* Added multi-platform toolchain support (Linux, macOS and Windows).
* Replaced self-extracting archive (SFX) distribution format with
conventional archive with a setup script that can be manually run
after extraction.
* Changed Xtensa target triplet names to include the target SoC name
(e.g. xtensa-sample_controller_zephyr-elf).

Please refer to the latest "Getting Started Guide" for the instructions on
how to install and use the multi-platform Zephyr SDK:

https://docs.zephyrproject.org/latest/getting_started/index.html#install-a-toolchain

Please try it out and report if you find any issues.

Thanks,

Stephanos


Stat system want to return integer #mcumgr

Vince Mulhollon
 

I have what's probably a very simple question about the stats system, and likely only need a tiny additional kick in the right direction.

What works:

I have stats working for telemetry purposes (counting missed sensor polls, interesting hardware events, that kind of thing).  I have multiple stats and I can clear them, increment them, set them to an arbitrary value.  I can view my stats by telnet into a shell.  I can view my stats by using mcumgr both over serial and over UDP network.  And it works great, and its simple, reliable, and easy to use.

What doesn't work:

There doesn't seem to be anything documented or example code or any terribly obvious getter function or macro to return a stat.  I'm gathering the missed sensor poll counts anyway; would be nice to output the same data in a MQTT packet or print to a LCD display.  The stat system does not do that out of the box, no problem I can send MQTT packets or do LCD stuff all day IF I have an int to output.  So where do I get that int?  Obviously I could replicate the stats system outside the stats system and everywhere I run a STATS_INC for mcumgr I could simultaneously run a some_var++; but that seems a waste to have two counters counting the same hardware event separately for multiple outputs.

/* I want to know the code that performs similar to this in very general concept */
uint32_t missed_sensor_poll_count = STATS_GETTER_UINT32(sensor_group, missed_poll_counts)

Maybe rephrased I'm saying I'm very familiar with the STATS_SET macro and it works great, now where is the STATS_GET macro?

Thanks for your time.  I fear I'm missing something terribly obvious and the harder I stare at the problem the harder it is to see, as it usually goes LOL.


Re: Unable to get GPIO controller handle from gpio node using DT_GPIO_CTLR

Bolivar, Marti
 

Hi Jason,

On Wed, Mar 16 2022, Jason Bens via lists zephyrproject org wrote:
I'd like to get the GPIO controller handle, and figured I could do it with something like the following:
static const struct device *gpio_dev =
DT_GPIO_CTLR(DT_NODELABEL(button_sel_role), gpios);
DT_GPIO_CTLR returns a node identifier:

https://docs.zephyrproject.org/latest/reference/devicetree/api.html#c.DT_GPIO_CTLR

And node identifiers are not values:

https://docs.zephyrproject.org/latest/guides/dts/api-usage.html#node-identifiers-are-not-values

You can't do anything useful with a node identifier at runtime -- the
devicetree has "vanished" at that point (see
https://www.youtube.com/watch?v=sWaxQyIgEBY for what I mean by
"vanished").

You need to convert the node identifier to a device pointer with
DEVICE_DT_GET:

static const struct device *gpio_dev =
DEVICE_DT_GET(DT_GPIO_CTLR(DT_NODELABEL(button_sel_role), gpios));

Hope this helps,
Martí


Re: Unable to get GPIO controller handle from gpio node using DT_GPIO_CTLR

Jason Bens <jason.bens@...>
 

Solved, and yes, it was a stupid question.  Given a closer read of the DT_GPIO_CTLR documentation, I noticed that it returns a node identifier, and not, as I expected a device handle.  The correct statement:

static const struct device *gpio_dev = DEVICE_DT_GET(DT_GPIO_CTLR(DT_NODELABEL(button_sel_role), gpios));

 

Thank you for everyone’s help,

 

  • Jason

 

From: users@... <users@...> On Behalf Of Jason Bens
Sent: March 16, 2022 7:27 PM
To: users@...
Subject: [Zephyr-users] Unable to get GPIO controller handle from gpio node using DT_GPIO_CTLR

 

External Email:

Hi,

 

I’m sure this is a very stupid question, but I haven’t been able to get to get this working.  I’ve got the following device tree fragment:

 

     gpio0: gpio@842500 {

           compatible = "nordic,nrf-gpio";

           gpio-controller;

           reg = < 0x842500 0x300 >;

           #gpio-cells = < 0x2 >;

           label = "GPIO_0";

           status = "okay";

           port = < 0x0 >;

          phandle = < 0x2 >;

     };

 

(and elsewhere…)

 

     buttons {

           compatible = "gpio-keys";

           button_sel_role: button_1 {

                gpios = < &gpio0 0x2 0x11 >;

                label = "Push button 1";

           };

     };

 

Button_sel_role is on different GPIO controllers on some of the devices I’m developing on.  I’d like to get the GPIO controller handle, and figured I could do it with something like the following:

     static const struct device *gpio_dev = DT_GPIO_CTLR(DT_NODELABEL(button_sel_role), gpios);

 

Unfortunately, this gives me a long chain of macro expansions, eventually terminating in

<build_dir>/zephyr/include/generated/devicetree_unfixed.h:656:52: error: 'DT_N_S_soc_S_peripheral_50000000_S_gpio_842500' undeclared (first use in this function); did you mean 'DT_N_S_soc_S_peripheral_50000000_S_gpio_842500_ORD'?

[build]   656 | #define DT_N_S_buttons_S_button_1_P_gpios_IDX_0_PH DT_N_S_soc_S_peripheral_50000000_S_gpio_842500

 

Using DT_PROP, I can access the label, so I don’t think the expansion of DT_NODELABEL is wrong.  I’m not really sure how to continue troubleshooting this.  Any advice?

 

Thanks,

 

  • Jason


Re: Using the posix BSP

Rob Meades
 

Aha, that's it, thank you!

Rob

-----Original Message-----
From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: 17 March 2022 15:45
To: Rob Meades <Rob.Meades@...>; users@...
Subject: RE: Using the posix BSP

*** This is an EXTERNAL email. It was sent from outside of u-blox. ***

Hi Rob,

I think you are referring to Zephyr's native_posix port, which we also call "Native port". It currently runs on Linux but Chris Friedt is working on porting it to macOS. You can find more information here:

https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.zephyrproject.org%2Flatest%2Fboards%2Fposix%2Fnative_posix%2Fdoc%2Findex.html&;data=04%7C01%7CRob.Meades%40u-blox.com%7C9b09109bdbcd4d55f50008da082d099a%7C80c4ffa675114bba9f03e5872a660c9b%7C0%7C0%7C637831286791556809%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=THJvIk%2FNFBtKO2IsgAopyG4YJ5cpEJomJuzTqNgx50Y%3D&amp;reserved=0

Carles

P.S.: Say hi to Adam!


-----Original Message-----
From: users@... <users@...> On
Behalf Of Rob Meades via lists.zephyrproject.org
Sent: 17 March 2022 16:31
To: users@...
Subject: [Zephyr-users] Using the posix BSP

Stoopid question time again I'm afraid: I would like to run Zephyr
with Linux as host, so using the posix BSP. I can find information
about running a posix application on top of Zephyr but not the other way up.

Can anyone point me at an example or some information concerning how I
go about running Zephyr with its posix BSP?

Rob




Re: Using the posix BSP

Carles Cufi
 

Hi Rob,

I think you are referring to Zephyr's native_posix port, which we also call "Native port". It currently runs on Linux but Chris Friedt is working on porting it to macOS. You can find more information here:

https://docs.zephyrproject.org/latest/boards/posix/native_posix/doc/index.html

Carles

P.S.: Say hi to Adam!

-----Original Message-----
From: users@... <users@...> On
Behalf Of Rob Meades via lists.zephyrproject.org
Sent: 17 March 2022 16:31
To: users@...
Subject: [Zephyr-users] Using the posix BSP

Stoopid question time again I'm afraid: I would like to run Zephyr with
Linux as host, so using the posix BSP. I can find information about
running a posix application on top of Zephyr but not the other way up.

Can anyone point me at an example or some information concerning how I go
about running Zephyr with its posix BSP?

Rob




Using the posix BSP

Rob Meades
 

Stoopid question time again I'm afraid: I would like to run Zephyr with Linux as host, so using the posix BSP. I can find information about running a posix application on top of Zephyr but not the other way up.

Can anyone point me at an example or some information concerning how I go about running Zephyr with its posix BSP?

Rob


Unable to get GPIO controller handle from gpio node using DT_GPIO_CTLR

Jason Bens <jason.bens@...>
 

Hi,

 

I’m sure this is a very stupid question, but I haven’t been able to get to get this working.  I’ve got the following device tree fragment:

 

     gpio0: gpio@842500 {

           compatible = "nordic,nrf-gpio";

           gpio-controller;

           reg = < 0x842500 0x300 >;

           #gpio-cells = < 0x2 >;

           label = "GPIO_0";

           status = "okay";

           port = < 0x0 >;

          phandle = < 0x2 >;

     };

 

(and elsewhere…)

 

     buttons {

           compatible = "gpio-keys";

           button_sel_role: button_1 {

                gpios = < &gpio0 0x2 0x11 >;

                label = "Push button 1";

           };

     };

 

Button_sel_role is on different GPIO controllers on some of the devices I’m developing on.  I’d like to get the GPIO controller handle, and figured I could do it with something like the following:

     static const struct device *gpio_dev = DT_GPIO_CTLR(DT_NODELABEL(button_sel_role), gpios);

 

Unfortunately, this gives me a long chain of macro expansions, eventually terminating in

<build_dir>/zephyr/include/generated/devicetree_unfixed.h:656:52: error: 'DT_N_S_soc_S_peripheral_50000000_S_gpio_842500' undeclared (first use in this function); did you mean 'DT_N_S_soc_S_peripheral_50000000_S_gpio_842500_ORD'?

[build]   656 | #define DT_N_S_buttons_S_button_1_P_gpios_IDX_0_PH DT_N_S_soc_S_peripheral_50000000_S_gpio_842500

 

Using DT_PROP, I can access the label, so I don’t think the expansion of DT_NODELABEL is wrong.  I’m not really sure how to continue troubleshooting this.  Any advice?

 

Thanks,

 

  • Jason


Re: Use of __attribute__((uncached)) using the ARC toolchain

Ruud Derwig
 

Hi Nikola,

 

It looks like a similar known issue, see https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/319

Thanks for reporting. In many cases other uncached accessor functions for IO read/writes are used instead of the uncached attribute, but let’s see if I can boost priority for fixing this with your report.

Your workaround should be fine for now, let me know if you need more help.

 

Regards,

 

Ruud.

From: users@... <users@...> On Behalf Of nikola.neskovic995@...
Sent: Friday, March 11, 2022 2:49 PM
To: users@...
Subject: [Zephyr-users] Use of __attribute__((uncached)) using the ARC toolchain

 

Hi, I am trying to make an array that would bypass cache. I declare it like this:
volatile __attribute__((aligned(64))) __attribute__((packed)) uint32_t __attribute__((uncached)) buffer[4] = {0}

After the declaration I fill my buffer in a simple for loop:
for(i = 0; i < size; i++) { buffer[i] = i; }

And after compilation for my for loop I get the following asm code:
mov_sr    0,0
mov_s    r14,<buffer_address>
add2    r1,r14,r0
st_s    r0,[r1,0]
add_s    r0,r0,1
brne_nt    r0,<size>,-14

From what I understand about the _uncached_ attribute instead of the st_s command, in my disassembly, I should get st.di.

I found a workaround using pointers, so if I just declare a pointer like this:
volatile uint32_t __attribute__((uncached)) *help = (volatile uint32_t *)(buffer)
and I use it in the for loop instead of the buffer I get the st.di commands correctly.

I am using the zephyr_sdk_0.12.4 version of ARC toolchain.
I don't know if this is the best place to ask this question, but if anyone has an answer for this of can direct me to another list I would very much appreciate that.

Thanks in advance :)


Sharing a Zephyr Shell with multiple peripherals or create new Shell instance?

BDesterBEC
 

Hello,

I am attempting to interface two UART devices with a Nucleo H743ZI so that they have access in some way or another to the Zephyr shell and their own custom commands. Currently, one of them has been assigned to the chosen node's zephyr,shell-uart property. It has been proposed that it may be possible for both devices to share the same shell, but I am unsure how to do this or if it is actually possible. I have been successful in creating an additional shell instance with its own thread, however going down that route I am unsure how to assign commands to it as the macros do not allow for specification of a shell instance.

If you have any insight into this please respond and it will be greatly appreciated.
Thanks,
Brandon


Re: Configure microphones on ST Discovery kit IoT node

Marco Cavallini
 

On 12/03/22 12:11, Daniele Bortoluzzi wrote:
Hi,
I also tried these configurations, according to .dts specs:
- *prj.conf*:
CONFIG_DMA=y
- *app.overlay*:
/ {
soc {
i2c4: i2c@40005800 {
compatible = "st,stm32-i2c-v2";
#address-cells = <1>;
#size-cells = <0>;
label= "I2C_4";
status = "okay";
pinctrl-names = "default";
clock-frequency = <I2C_BITRATE_FAST_PLUS>;
mp34dt01@0 {
compatible = "st,mpxxdtyy";
reg = <0>;
label = "MP34DT01";
};
};
};
i2c4_ck_pe9: i2c4_ck_pe9@0 {
pinmux = <STM32_PINMUX('E', 9, GPIO)>;
drive-open-drain;
};
i2c4_da_pe7: i2c4_da_pe7@0 {
pinmux = <STM32_PINMUX('E', 7, GPIO)>;
drive-open-drain;
};
};
&i2c4 {
pinctrl-names = "default";
pinctrl-0 = <&i2c4_ck_pe9 &i2c4_da_pe7>;
};
But it doesn't compile:
/Error: disco_l475_iot1.dts.pre.tmp:1939.55-56 syntax error
FATAL ERROR: Unable to parse input tree/

Hi Daniele,
'm not using Zephyr Project at the moment, however showing your DTS and a better description and excerpts would help to figure out the solution.

Just my two cents ;-)


Distinti Saluti / Best Regards
--
Marco Cavallini | KOAN sas
Bergamo - Italia
embedded software engineering
https://KoanSoftware.com


Re: Configure microphones on ST Discovery kit IoT node

Daniele Bortoluzzi <danieleb88@...>
 

Hi,
I also tried these configurations, according to .dts specs:

prj.conf:
CONFIG_DMA=y

app.overlay:
/ {
soc {
i2c4: i2c@40005800 {
compatible = "st,stm32-i2c-v2";
#address-cells = <1>;
#size-cells = <0>;
label= "I2C_4";

status = "okay";
pinctrl-names = "default";
clock-frequency = <I2C_BITRATE_FAST_PLUS>;

mp34dt01@0 {
compatible = "st,mpxxdtyy";
reg = <0>;
label = "MP34DT01";
};
};
};

i2c4_ck_pe9: i2c4_ck_pe9@0 {
pinmux = <STM32_PINMUX('E', 9, GPIO)>;
drive-open-drain;
};

i2c4_da_pe7: i2c4_da_pe7@0 {
pinmux = <STM32_PINMUX('E', 7, GPIO)>;
drive-open-drain;
};
};

&i2c4 {
pinctrl-names = "default";
pinctrl-0 = <&i2c4_ck_pe9 &i2c4_da_pe7>;
};

But it doesn't compile:
Error: disco_l475_iot1.dts.pre.tmp:1939.55-56 syntax error
FATAL ERROR: Unable to parse input tree



Il giorno mer 9 mar 2022 alle ore 09:48 Daniele Bortoluzzi <danieleb88@...> ha scritto:
Hi,
I'm Bortoluzzi Daniele, and I'm developing, for my master's thesis with University of Turin, a project using platformio and zephyr, helped by my thesis advisor and co-supervisor.

I would like to use the microphone (MP34DT01) of the B-L475E-IOT01A (ST Discovery kit IoT node) in a zephyr project. This mcu is supported by zephyr, but the .dts file doesn't configure the interface used by mic.

According with the hardware specs [1], I tried to start from zephyr example using st_mpxxdtyy driver [2] and configure:

prj.conf:

CONFIG_AUDIO=y
CONFIG_AUDIO_DMIC=y
CONFIG_AUDIO_MPXXDTYY=y


app.overlay:

&XXXX {
     status = "okay";
     pinctrl-0 = <&YYYY &ZZZZ>;
     pinctrl-names = "default";

     mp34dt01: mp34dt01@0 {
            compatible = "st,mpxxdtyy";
            reg = <0>;
            label = "MP34DT01";
     };
};


According with the specs [1] and analyzing the ST function pack FP-AI-SENSING1 [4], we think we should use:
- DFSDM1_CKOUT —» pin PE9
- DFSDM1_DATIN2 —» pin PE7
but we don't know how to write the DTS file.

In particular, about the app.overlay, we are not sure:
- which interface to use (XXXX field)
- which pin variables to use (YYYY, ZZZZ fields).

Could you please help us?

Thank you very much for your support.

Daniele

Some infos:


Security WG - meeting agenda, March 14

Flavio Ceolin
 

Hi everyone,

Following the proposed agenda for our next meeting:

- Kick off the group
- PSA crypto API adoption on Zephyr


p.s: I've broadcasted this email to several mailing lists just
because this is the first meeting for this group.

Regards,
Flavio Ceolin


Use of __attribute__((uncached)) using the ARC toolchain

nikola.neskovic995@...
 

Hi, I am trying to make an array that would bypass cache. I declare it like this:
volatile __attribute__((aligned(64))) __attribute__((packed)) uint32_t __attribute__((uncached)) buffer[4] = {0}

After the declaration I fill my buffer in a simple for loop:
for(i = 0; i < size; i++) { buffer[i] = i; }

And after compilation for my for loop I get the following asm code:
mov_sr    0,0
mov_s    r14,<buffer_address>
add2    r1,r14,r0
st_s    r0,[r1,0]
add_s    r0,r0,1
brne_nt    r0,<size>,-14

From what I understand about the _uncached_ attribute instead of the st_s command, in my disassembly, I should get st.di.

I found a workaround using pointers, so if I just declare a pointer like this:
volatile uint32_t __attribute__((uncached)) *help = (volatile uint32_t *)(buffer)
and I use it in the for loop instead of the buffer I get the st.di commands correctly.

I am using the zephyr_sdk_0.12.4 version of ARC toolchain.
I don't know if this is the best place to ask this question, but if anyone has an answer for this of can direct me to another list I would very much appreciate that.

Thanks in advance :)


Security Working Group invitation

Flavio Ceolin
 

Hi everyone,


I'd like to invite anyone to join the new working group dedicated to
security on Zephyr. Information about meetings and mailing list can
be found in:

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#security-working-group
https://lists.zephyrproject.org/g/security-wg



Regards,
Flavio Ceolin


Re: Zephyr Example Application cannot be built

Jonathan Hahn
 

Hey,

I did not try to build myself, but after quickly looking into your code, I have
a few ideas, you could give a try:

  • The dts/bindings filenames are missing your `x`.
  • You could use 
    const struct device *dev = DEVICE_DT_GET(LSM6DSOX_LABEL);
    instead of device_get_binding
    If sensor driver was not compiled, it should fail at compile time.
  • Your root/Kconfig and app/Kconfig seem to duplicate stuff.
  • drivers/sensor/CMakeLists.txt does not use add_subdirectory_ifdef, not sure whether the if clause does what it is intended to do.

Not very convinced that looking in any of those solves your issue. Hope it helps though.

Best regards

Jonathan

Am 10.03.22 um 11:26 schrieb lau kc:

Hi,
  I would like to develop an out-of-tree driver and there is an example provided in zephyrproject-rtos github(https://github.com/zephyrproject-rtos/example-application).

  I have followed the example and built a project with a sensor driver. The driver is a copy of lsm6dso and renamed to lsm6dsox for testing. There is no error message when building the project but I noticed that the drivers have not been imported. 

  If I move the out-of-tree driver to the root zephyr driver directory(driver and dts).
Everything is working fine and the driver can be correctly imported. But that is not the goal of an out-of-tree driver.

  Could anyone give me advice?

-yes.png is the sample project containing the .c file is built.
-no.png is the out-of-tree project that does not contain the .c file.
-copy_to_driver.png is the out-of-tree project that contains the .c file by copying the out-of-tree driver to the zephyr driver directory.
-.zip if the out-of-tree project for testing.

181 - 200 of 3086