Date   

Re: STM32L Errors Building samples/drivers/spi_fujitsu_fram with Ninja

@kiwironnie
 

Thanks Erwan, brilliant, solved!

When the board alias "spi-1 = &spi1;" was added the executable built ok, no errors!

Note that an underscore in "spi_1 = &spi1;" threw an error: dtlib.DTError: /aliases: alias property name 'spi_1' should include only characters from [0-9a-z-]

But then it's clear from the documentation that dashes in the .dts become underscores in the source.

Am not bothered about the actual hardware at this stage, as the idea is to be able to use an example that builds ok as a template to be modified.

Cheers

Ron


Re: Problem with LPTIM on Zephyr

Raz <raziebe@...>
 

I tried to compile LPTIM in the kernel but Zephyr fails. 
Is there an example for LPTIM in an app ?


On Tue, Feb 16, 2021 at 12:30 PM Erwan Gouriou <erwan.gouriou@...> wrote:
Hi Raz,


Did you checked that the clocks are correctly enabled?
In any case, I'd suggest to minimize the use of Cube functions to the timer related functions.
Zephyr provides most of things you need for MSP and board init.

Cheers
Erwan

On Fri, 12 Feb 2021 at 14:59, Raz <raziebe@...> wrote:
hello.
I am trying to use the LPTIM for the nucleos 476  by integrating it from CUBE. I ported the code below to Zephyr:

 HAL_Init();

  SystemClock_Config();

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_LPTIM1_Init();
  for (;i<2;i++) {
 HAL_GPIO_TogglePin (GPIOA, GPIO_PIN_5);
 HAL_Delay(1000);
  }
  /*
   * LSE Input freq is 32768 hz.
   *  32768/64 = 512hz
   * */
  int secs = 3;
  if (HAL_LPTIM_Counter_Start_IT(&hlptim1, 512* secs + 1) != HAL_OK) {
     Error_Handler();
  }
  HAL_PWREx_EnterSTOP2Mode(PWR_STOPENTRY_WFI);
  while (1)
  {
 HAL_PWREx_EnterSTOP2Mode(PWR_STOPENTRY_WFI);
  }
  /* USER C

However, the timer does not start. Anyone is familiar with this problem ?

Kind regards


Re: Port for STM32F101RF #stm32

Erwan Gouriou
 

Hi Thomas,

There is no STM32F101 port indeed.
Though there are others variants of STM32F1 series available.
So I don't expect too much trouble when adding STM32F101 support.

You could find below a recent example of STM32 SoC porting:

Cheers
Erwan

On Tue, 16 Feb 2021 at 14:59, <arve@...> wrote:
Ciao a tutti

At the moment I am busy with a project which was built on a rather old STM32F101RF. Is there a Zephyr port available for it? I could not find anything in the sources. But I may have overlooked something.

Many thanks in advance
Thomas


Port for STM32F101RF #stm32

arve@...
 

Ciao a tutti

At the moment I am busy with a project which was built on a rather old STM32F101RF. Is there a Zephyr port available for it? I could not find anything in the sources. But I may have overlooked something.

Many thanks in advance
Thomas


SMP server on HCI USB composite device #nrf52480 #mcumgr #hci #usb

Martin Roesch
 

Hi,

I am trying to figure out how to make a HCI USB Bluetooth host adapter with device management on a nRF52840 Dongle.

My approach is to make a USB composite device consisting of the Bluetooth device (CONFIG_USB_DEVICE_BLUETOOTH) and a CDC ACM UART (CONFIG_USB_CDC_ACM) which is used as backend for the MCU Manager Support (CONFIG_MCUMGR_SMP_UART).

When the nRF52840 Dongle is plugged into a USB port on a Linux machine, the serial device /dev/ttyACM0 is available and the SMP server is able to communicate with the mcumgr application.
But the no Bluetooth adapter is detected.

Listing the device with lsusb shows that there is a Interface available that provides the Bluetooth protocol:

Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x2fe3 NordicSemiconductor
  idProduct          0x000b 
  bcdDevice            2.05
  iManufacturer           1 Manufacturer
  iProduct                2 Product
  iSerial                 3 41EE42283B95248A
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0069
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         0
      bInterfaceCount         2
      bFunctionClass          2 Communications
      bFunctionSubClass       2 Abstract (modem)
      bFunctionProtocol       0 
      iFunction               0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      0 
      iInterface              0 
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x02
          use DataInterface
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x02
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval              10
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       224 Wireless
      bInterfaceSubClass      1 Radio Frequency
      bInterfaceProtocol      1 Bluetooth
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1

Am I missing something in the Zephyr kernel configuration? Or on the Linux host side?
Is the approach with the composite USB device even feasible for what I want to achieve?
Should I use another backend for the SMP server, e.g. udp?

Any suggestions or insights are appreciated, as I am by not very experienced with USB.


Re: SMT32F103 - RCC_CFGR_PLLXTPRE not set correctly?

Erwan Gouriou
 

Hi Naro,

Have you tried to revert the faulty commit and see if this fixes the issue in your case ?
(To make it work, you might have to remove #ifdefery around `SOC_STM32F10X_DENSITY_DEVICE`.

Cheers
Erwan




On Thu, 11 Feb 2021 at 18:25, immanuel narodoslawsky <narodo.imm@...> wrote:
Hi everyone,

I have troubles getting my custom board to work. I think the problem is that the RCC_CFGR_PLLXTPRE bit is not handled properly. I am using an STM32F103C8 (same as on the bluebill board) with an external 16MHz quartz. I am trying to run the system on 72MHz by dividing the input clock by 2.
Currently I am on Zephyr 2.4.0, but as far as I can see this is still the same for the latest version.

I saw that this config option was removed in commit 6b72fbae7c  since the HAL layer is supposed to handle this, but I can't quite see how.

If I follow the calls I end up in the LL_PLL_ConfigSystemClock_HSE HAL function that passes the "prediv" value from the PLL init struct to LL_RCC_PLL_ConfigDomain_SYS. As far as I can see it does not handle the shifting to the right position or any parsing of the "prediv" value.

But since this config option was removed on purpose I am wondering if I am doing something wrong here. What is the intended way of configuring this option?

Can you please let me know if anyone got this working?

Thanks a lot for your help!


Best regards,
Naro




Re: Problem with LPTIM on Zephyr

Erwan Gouriou
 

Hi Raz,


Did you checked that the clocks are correctly enabled?
In any case, I'd suggest to minimize the use of Cube functions to the timer related functions.
Zephyr provides most of things you need for MSP and board init.

Cheers
Erwan

On Fri, 12 Feb 2021 at 14:59, Raz <raziebe@...> wrote:
hello.
I am trying to use the LPTIM for the nucleos 476  by integrating it from CUBE. I ported the code below to Zephyr:

 HAL_Init();

  SystemClock_Config();

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_LPTIM1_Init();
  for (;i<2;i++) {
 HAL_GPIO_TogglePin (GPIOA, GPIO_PIN_5);
 HAL_Delay(1000);
  }
  /*
   * LSE Input freq is 32768 hz.
   *  32768/64 = 512hz
   * */
  int secs = 3;
  if (HAL_LPTIM_Counter_Start_IT(&hlptim1, 512* secs + 1) != HAL_OK) {
     Error_Handler();
  }
  HAL_PWREx_EnterSTOP2Mode(PWR_STOPENTRY_WFI);
  while (1)
  {
 HAL_PWREx_EnterSTOP2Mode(PWR_STOPENTRY_WFI);
  }
  /* USER C

However, the timer does not start. Anyone is familiar with this problem ?

Kind regards


Re: STM32L Errors Building samples/drivers/spi_fujitsu_fram with Ninja

Erwan Gouriou
 

Hi Ron,

First question: do you have the matching FRAM that is described on  the sample ?

If  yes, I'd suggest adding "spi_1 = &spi1;" in your board aliases, and hopefully this should work.

BR

Erwan


On Mon, 15 Feb 2021 at 18:39, <ron@...> wrote:
New to Zephyr, no problem with building and running the hello world example for an STM32L433, nucleo_l433rc_p board
Trying to build samples/drivers/spi_fujitsu_fram as an example of SPI use. From a created build directly cmake -GNinja -DBOARD=nucleo_l433rc_p .. runs through ok, but Ninja fails with:

/media/fred/zephyrdev/stm-testbed/zephyr/include/devicetree.h:208:32: error: 'DT_N_ALIAS_spi_1_P_label' undeclared (first use in this function)
  208 | #define DT_ALIAS(alias) DT_CAT(DT_N_ALIAS_, alias)
      |                                ^~~~~~~~~~~
/media/fred/zephyrdev/stm-testbed/zephyr/include/devicetree.h:2176:24: note: in definition of macro 'DT_CAT'
 2176 | #define DT_CAT(a1, a2) a1 ## a2
      |                        ^~
/media/fred/zephyrdev/stm-testbed/zephyr/include/devicetree.h:584:27: note: in expansion of macro 'DT_PROP'
  584 | #define DT_LABEL(node_id) DT_PROP(node_id, label)
      |                           ^~~~~~~
../src/main.c:148:27: note: in expansion of macro 'DT_LABEL'
  148 |  spi = device_get_binding(DT_LABEL(DT_ALIAS(spi_1)));
      |                           ^~~~~~~~

and other similar errors.
Have checked that SPI1 is enabled for the board in the .dts file.  Also tried building for other STM32 boards but getting similar errors running Ninja.
Some guidance would be appreciated.


STM32L Errors Building samples/drivers/spi_fujitsu_fram with Ninja

@kiwironnie
 

New to Zephyr, no problem with building and running the hello world example for an STM32L433, nucleo_l433rc_p board
Trying to build samples/drivers/spi_fujitsu_fram as an example of SPI use. From a created build directly cmake -GNinja -DBOARD=nucleo_l433rc_p .. runs through ok, but Ninja fails with:

/media/fred/zephyrdev/stm-testbed/zephyr/include/devicetree.h:208:32: error: 'DT_N_ALIAS_spi_1_P_label' undeclared (first use in this function)
  208 | #define DT_ALIAS(alias) DT_CAT(DT_N_ALIAS_, alias)
      |                                ^~~~~~~~~~~
/media/fred/zephyrdev/stm-testbed/zephyr/include/devicetree.h:2176:24: note: in definition of macro 'DT_CAT'
 2176 | #define DT_CAT(a1, a2) a1 ## a2
      |                        ^~
/media/fred/zephyrdev/stm-testbed/zephyr/include/devicetree.h:584:27: note: in expansion of macro 'DT_PROP'
  584 | #define DT_LABEL(node_id) DT_PROP(node_id, label)
      |                           ^~~~~~~
../src/main.c:148:27: note: in expansion of macro 'DT_LABEL'
  148 |  spi = device_get_binding(DT_LABEL(DT_ALIAS(spi_1)));
      |                           ^~~~~~~~

and other similar errors.
Have checked that SPI1 is enabled for the board in the .dts file.  Also tried building for other STM32 boards but getting similar errors running Ninja.
Some guidance would be appreciated.


Adafruit Feather Sense on Zephyr

Dimitrios Kosyvas <kosyvas14828@...>
 

Hello
I want to use Zephyr to build an audio recognition application  for my thesis and then flash it via a external debugger to Adafruit Feather Sense .In the list of supported boards there is
Adafruit Feather nrf52840 Express and i was wondering  if i can use  that to build for the Sense board ,since both boards have the save processor and just different peripherals .

Dimitris







Problem with LPTIM on Zephyr

Raz <raziebe@...>
 

hello.
I am trying to use the LPTIM for the nucleos 476  by integrating it from CUBE. I ported the code below to Zephyr:

 HAL_Init();

  SystemClock_Config();

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_LPTIM1_Init();
  for (;i<2;i++) {
 HAL_GPIO_TogglePin (GPIOA, GPIO_PIN_5);
 HAL_Delay(1000);
  }
  /*
   * LSE Input freq is 32768 hz.
   *  32768/64 = 512hz
   * */
  int secs = 3;
  if (HAL_LPTIM_Counter_Start_IT(&hlptim1, 512* secs + 1) != HAL_OK) {
     Error_Handler();
  }
  HAL_PWREx_EnterSTOP2Mode(PWR_STOPENTRY_WFI);
  while (1)
  {
 HAL_PWREx_EnterSTOP2Mode(PWR_STOPENTRY_WFI);
  }
  /* USER C

However, the timer does not start. Anyone is familiar with this problem ?

Kind regards


SMT32F103 - RCC_CFGR_PLLXTPRE not set correctly?

immanuel narodoslawsky
 

Hi everyone,

I have troubles getting my custom board to work. I think the problem is that the RCC_CFGR_PLLXTPRE bit is not handled properly. I am using an STM32F103C8 (same as on the bluebill board) with an external 16MHz quartz. I am trying to run the system on 72MHz by dividing the input clock by 2.
Currently I am on Zephyr 2.4.0, but as far as I can see this is still the same for the latest version.

I saw that this config option was removed in commit 6b72fbae7c  since the HAL layer is supposed to handle this, but I can't quite see how.

If I follow the calls I end up in the LL_PLL_ConfigSystemClock_HSE HAL function that passes the "prediv" value from the PLL init struct to LL_RCC_PLL_ConfigDomain_SYS. As far as I can see it does not handle the shifting to the right position or any parsing of the "prediv" value.

But since this config option was removed on purpose I am wondering if I am doing something wrong here. What is the intended way of configuring this option?

Can you please let me know if anyone got this working?

Thanks a lot for your help!


Best regards,
Naro




Re: Cross compiling for AR71xx

Kumar Gala
 

On Feb 10, 2021, at 5:07 AM, Piotr Barszczewski <piotr@1am.pl> wrote:

Hello,

I am wondering that since among others Zephyr supports Intel x86 (32- and 64-bit) would it be theoretically possible to cross compile it to AR71xx architecture, quite popular as OpenWRT host? I’ve done that with other C/C++ projects and even golang library with ENV CGO_ENABLED=1 and CC= pointing to my mips-openwrt-linux-musl-gcc toolchain.
I would want to try it out but the amount of potential problems to overcome is quite significant so wanted I to ask if anyone has tried that before or knows where one could find more information about such an experiment?
The reason for that is that it could potentially unify my development stack consisting of nRF528xx chips for BLE running on Zephyr <-> gateway devices (this is where Zephyr on AR71xx comes in) <-> desktop apps which again can be written in Zephyr.
While technically possible there isn’t a port of Zephyr in the upstream code base for MIPS. There are some PRs for this but they haven’t gotten to a mergeable state.

In addition, as Zephyr is a RTOS it requires porting to the hardware you’re interested in running it on.

I suggest search for MIPS in the GitHub PR and issues for more details.

- k


Cross compiling for AR71xx

Piotr Barszczewski <piotr@...>
 

Hello,

I am wondering that since among others Zephyr supports Intel x86 (32- and 64-bit) would it be theoretically possible to cross compile it to AR71xx architecture, quite popular as OpenWRT host? I’ve done that with other C/C++ projects and even golang library with ENV CGO_ENABLED=1 and CC= pointing to my mips-openwrt-linux-musl-gcc toolchain.
I would want to try it out but the amount of potential problems to overcome is quite significant so wanted I to ask if anyone has tried that before or knows where one could find more information about such an experiment?
The reason for that is that it could potentially unify my development stack consisting of nRF528xx chips for BLE running on Zephyr <-> gateway devices (this is where Zephyr on AR71xx comes in) <-> desktop apps which again can be written in Zephyr. 

Best regards,
PB


Re: undefined reference to `__bswapdi2' when trying to link tinycbor for RISC-V

Kumar Gala
 

On Feb 8, 2021, at 1:16 PM, Stefan Hristozov <stefan.hristozov@aisec.fraunhofer.de> wrote:

Hi
I am using Zephyr version: 2.3.99 with West version: v0.7.2.

How to provide -Wl,--start-group …. -Wl,—end-group linker flags to my Zephyr project?
Try something like:

/opt/zephyr-sdk-0.11.3/riscv64-zephyr-elf/bin/riscv64-zephyr-elf-gcc … -Wl,--start-group zephyr/kernel/libkernel.a zephyr/CMakeFiles/offsets.dir/arch/riscv/core/offsets/offsets.c.obj -L"/opt/zephyr-sdk-0.11.3/riscv64-zephyr-elf/bin/../lib/gcc/riscv64-zephyr-elf/9.2.0" -L/home/stefan/workspaces/oscore-edhoc/test/build/zephyr -lgcc -Wl,—end-group …

- k


Re: undefined reference to `__bswapdi2' when trying to link tinycbor for RISC-V

Stefan Hristozov
 

Hi
I am using Zephyr version: 2.3.99 with West version: v0.7.2.

How to provide -Wl,--start-group …. -Wl,—end-group linker flags to my Zephyr project?

Br,
Stefan


Re: Drift through k_sleep or k_msleep #api

Chruściński, Krzysztof
 

Hi,

One thing to consider is that k_timeout_t structure used for k_sleep and kernel timeouts can hold absolute value. Check out K_TIMEOUT_ABS_MS() for setting timeout in uptime milliseconds.

Regards,
Krzysztof

-----Original Message-----
From: users@lists.zephyrproject.org <users@lists.zephyrproject.org> On Behalf Of Nikolaus Huber via lists.zephyrproject.org
Sent: Wednesday, February 3, 2021 9:48 PM
To: users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Drift through k_sleep or k_msleep #api

Thank you all for your answers!

I was kind of assuming that I could achieve this by using a timer. I think that that might be the nicest solution for my use case.
I was just wondering if Zephyr maybe has an API similar to FreeRTOS with a dedicated delay command that eliminates drifts. But I guess using a timer actually makes it a bit more explicit.

Thank you very much :)

/Nick








När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uu.se%2Fom-uu%2Fdataskydd-personuppgifter%2F&;data=04%7C01%7Ckrzysztof.chruscinski%40nordicsemi.no%7C08dd3554ffe7423bee6008d8c8850e8a%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637479821084758635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=oxxw9PeN6d36zfphV4A%2BLfiDszb8EIsfI3grkUvoSI4%3D&amp;reserved=0

E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uu.se%2Fen%2Fabout-uu%2Fdata-protection-policy&;data=04%7C01%7Ckrzysztof.chruscinski%40nordicsemi.no%7C08dd3554ffe7423bee6008d8c8850e8a%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637479821084758635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=NUC%2B45wN6BAFk1jM%2B9tA6bXx8fHZLt7%2FNNp%2BTh%2FIQz4%3D&amp;reserved=0


Re: Drift through k_sleep or k_msleep #api

Nikolaus Huber
 

Thank you all for your answers!

I was kind of assuming that I could achieve this by using a timer. I think that that might be the nicest solution for my use case.
I was just wondering if Zephyr maybe has an API similar to FreeRTOS with a dedicated delay command that eliminates drifts. But I guess using a timer actually makes it a bit more explicit.

Thank you very much :)

/Nick








När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/

E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/en/about-uu/data-protection-policy


Re: Drift through k_sleep or k_msleep #api

Erik Englund
 

I guess the internals of this uses a semaphore aswell to get realtime performance.

If you control the semaphore yourself as per my example, you can check the status of the semaphore in the end of the function to see if the timer has expired while the work was running, if so, you have a realtime problem.
We use this technique in Zephyr within a few PLC-type controller products, using 1000 ticks/second rate and cycletime of 10ms.

Med vänlig hälsning
Erik Englund

Innoware Development AB
Hyttvägen 13
73338 SALA


Org.nr. 556790-2977
www.innoware.se


Den ons 3 feb. 2021 kl 21:10 skrev Michael Rosen <michael.r.rosen@...>:

Nick,

 

The design pattern Ive seen for this kind of thing uses the Timer API instead of sleep:

 

struct k_timer timer;

k_timer_init(&timer, NULL, NULL);

k_timer_start(&timer, 0, K_MSEC(1000));

while (1) {

  k_timer_status_sync(&timer);

  …

}

 

This lets the body of the main loop run only when the timer expires, and the periodic timer avoid drift from resetting the timer at the top of each loop.

 

Mike

 

From: users@... <users@...> On Behalf Of Erik Englund
Sent: Wednesday, February 3, 2021 2:38 PM
To: Nikolaus Huber <nikolaus.huber@...>
Cc: users@...
Subject: Re: [Zephyr-users] Drift through k_sleep or k_msleep #api

 

One possible solution is to create a periodic timer and post to a semaphore in the timer callback.

A thread could simply wait on the semaphore in an endless loop.

 

Linux clock_nanosleep (mostly used togheter with Preempt-rt patch) would be a nice addition to Zephyr, that would solve these kinds of tasks.


Med vänlig hälsning

Erik Englund


Innoware Development AB
Hyttvägen 13
73338 SALA


Org.nr. 556790-2977
www.innoware.se

 

 

Den ons 3 feb. 2021 kl 20:31 skrev Nikolaus Huber <nikolaus.huber@...>:

Hi all, 

I was recently wondering about the correct usage of k_sleep or k_msleep for implementing periodic tasks. In FreeRTOS for example there is a function vTaskDelayUntil which takes a timestamp and a number of ticks to delay. By taking the timestamp at the beginning of the execution of a task we can then make sure that its release time does not slowly drift. So far I have not seen anything similar in Zephyr. Am I missing something, or do I have to somehow create a similar mechanism on my own by measuring the uptime at the release of a periodic task and then again just before using any sleep function to calculate the exact sleep time I want?

Thank you very much in advance,
Nick


Re: Drift through k_sleep or k_msleep #api

Michael Rosen
 

Nick,

 

The design pattern Ive seen for this kind of thing uses the Timer API instead of sleep:

 

struct k_timer timer;

k_timer_init(&timer, NULL, NULL);

k_timer_start(&timer, 0, K_MSEC(1000));

while (1) {

  k_timer_status_sync(&timer);

  …

}

 

This lets the body of the main loop run only when the timer expires, and the periodic timer avoid drift from resetting the timer at the top of each loop.

 

Mike

 

From: users@... <users@...> On Behalf Of Erik Englund
Sent: Wednesday, February 3, 2021 2:38 PM
To: Nikolaus Huber <nikolaus.huber@...>
Cc: users@...
Subject: Re: [Zephyr-users] Drift through k_sleep or k_msleep #api

 

One possible solution is to create a periodic timer and post to a semaphore in the timer callback.

A thread could simply wait on the semaphore in an endless loop.

 

Linux clock_nanosleep (mostly used togheter with Preempt-rt patch) would be a nice addition to Zephyr, that would solve these kinds of tasks.


Med vänlig hälsning

Erik Englund


Innoware Development AB
Hyttvägen 13
73338 SALA


Org.nr. 556790-2977
www.innoware.se

 

 

Den ons 3 feb. 2021 kl 20:31 skrev Nikolaus Huber <nikolaus.huber@...>:

Hi all, 

I was recently wondering about the correct usage of k_sleep or k_msleep for implementing periodic tasks. In FreeRTOS for example there is a function vTaskDelayUntil which takes a timestamp and a number of ticks to delay. By taking the timestamp at the beginning of the execution of a task we can then make sure that its release time does not slowly drift. So far I have not seen anything similar in Zephyr. Am I missing something, or do I have to somehow create a similar mechanism on my own by measuring the uptime at the release of a periodic task and then again just before using any sleep function to calculate the exact sleep time I want?

Thank you very much in advance,
Nick

261 - 280 of 2705