Date   

API meeting: Agenda

Carles Cufi
 

Hi all,

This week we will focus on a new RFC and GPIO.

- RFC: New counter_get_value() API call
- https://github.com/zephyrproject-rtos/zephyr/issues/21846

- GPIO: Update on progress
- Proposal from Peter Bigot: Port remaining users without testing them on hardware (accepted)
- Look at the PRs with driver conversion (https://github.com/zephyrproject-rtos/zephyr/issues/18530)
- Check users of GPIO APIs: https://github.com/zephyrproject-rtos/zephyr/issues/20017
- Tips for converting users can be found here: https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497 (thanks Peter!)
- Any additional outstanding PRs to topic-gpio

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Re: NXP RT1064 board and JLink Debugging

langrind@...
 

For what it's worth 8 months later, I was able to use PyOCD and the the built-in debugger on RT1064-EVK board to flash the Zephyr blinky program using MCUXpresso's flash programmer. Thus avoiding (for now) the need to buy a J-link probe. I didn't need to change much of anything.

What I did was use the MCUX option to save the flash command it uses to a file, and then tweaked the file so it's a script I can pass in whatever elf file I want:

MCUX_WORKSPACE_LOC=$HOME/Documents/MCUXpresso_11.0.1_2563/workspace
MCUX_FLASH_DIR0=/usr/local/mcuxpressoide-11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.bin.linux_11.0.1.201908271452/binaries/Flash
MCUX_FLASH_DIR1=$HOME/Documents/MCUXpresso_11.0.1_2563/workspace/.mcuxpressoide_packages_support/MIMXRT1064xxxxA_support/Flash
MCUX_IDE_BIN=/usr/local/mcuxpressoide-11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.bin.linux_11.0.1.201908271452/binaries/

$MCUX_IDE_BIN/crt_emu_cm_redlink --flash-load-exec $1 -p MIMXRT1064xxxxA --flash-driver MIMXRT1064.cfx -x $HOME/bin --flash-dir $MCUX_FLASH_DIR0 --flash-dir $MCUX_FLASH_DIR1

(some of that stuff may be unnecessary)

I copied MIMXRT1064xxxxA_part.xml  and MIMXRT1064xxxxA.xml from an MCUX project directory into ~/bin (hence the -x $HOME/bin in the command above)

The script will flash the build/zephyr/zephyr.elf no problem. I didn't have to change any jumpers on the RT1064-EVK other than to set SW7 to boot from internal flash. I didn't have to change anything about how the zephyr sample program is built.


Upgrade pyocd requested version to 0.24.0

Erwan Gouriou
 

Hi Zephyr users,

In order to benefit from a wider range of user options [1], I'm proposing in PR 21791 to upgrade requirement for pyocd to version 0.24.0.
Change should not have impact for most users, but if you have any comments, don't hesitate to let me know (in PR discussion)

Cheers
Erwan




Re: DHCPV4 and CONFIG_NET_SOCKETS_SOCKOPT_TLS

Jukka Rissanen
 

Hi,

the DHCPv4 code does not really timeout, there is exponential backoff so the system will try to get the IP address as long as needed.

For the socket TLS error, you need to enable also mbedTLS as that is used to implement the actual TLS support.

Cheers,
Jukka


On Tue, 2020-01-07 at 17:15 +0100, Denv E wrote:
Hi,

using zephyr-v2.1.0

I have build the mqtt_publisher sample application for the stm32f746g_disco and it works fine.

I have build the dhcpv4_client sample application for the stm32f746g_disco and it works fine.

When I want to combine both, mqtts and dhcpv4, the dhcpv4 is always timing out.

I have tried step by step.

Using dhcpv4_client sample:

add to prj.conf

# Enable Sockets support
CONFIG_NET_SOCKETS=y
CONFIG_NET_SOCKETS_SOCKOPT_TLS=y

Then the application is no longer compiling:

zephyr/subsys/net/lib/sockets/sockets_tls.c:1735:45: error: 'struct tls_context' has no member named 'ssl'

Does sock_opt_tls is depending on mbedtls? In the guiconfig there is no dependency mentioned between CONFIG_NET_SOCKETS_SOCKOPT_TLS and CONFIG_MBEDTLS.
The sockets_tls uses different mbedtls defines.

What is the correct solution for this problem?

kr,

Wim



Re: I2C on nRF5340 Issues #i2c #driver #nrf5340

Marciano
 

After further testing, I found that if I step through each instruction with the debugger the individual messages send correctly, but not if I let the program run regularly. In neither case does the i2c_transfer(…) function return. What might cause the differences in behavior between slow stepping and running the program?


PassiveLogic, Inc.
Main 801-394-3344
Mobile 801-800-1184
marciano@...

This e-mail and any files transmitted with it may contain confidential or legally privileged information of PassiveLogic and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.



On Jan 7, 2020, at 3:07 PM, marciano@... wrote:

I am attempting to write a basic I2C program using Zephyr, but I am currently unable to sent a single byte over I2C. The program hangs after the first clock falling & rising edge.

I'm using external 1K pullups, and have a BME680 device on the other end. I observe the same behavior on the bus with or without the BME680 device.

Am I doing something wrong?

 

prj.conf

CONFIG_NEWLIB_LIBC=y

CONFIG_PRINTK=y

CONFIG_HAS_SEGGER_RTT=y

CONFIG_USE_SEGGER_RTT=y

CONFIG_RTT_CONSOLE=y

CONFIG_UART_CONSOLE=n



# nRF5340 board config

CONFIG_TRUSTED_EXECUTION_SECURE=y



CONFIG_BT=n

CONFIG_TIMESLICING=n

CONFIG_DEVICE_POWER_MANAGEMENT=y

CONFIG_SYS_POWER_MANAGEMENT=y

CONFIG_SYS_POWER_DEEP_SLEEP_STATES=y

CONFIG_DEVICE_POWER_MANAGEMENT=y



CONFIG_I2C=y

CONFIG_I2C_1=y

main.c

#include 
#include 
#include <sys/printk.h>
#include <drivers/i2c.h>

/* Application main Thread */
int main(void)
{
  struct device *p_i2c = device_get_binding("I2C_1");
  u32_t dev_config = I2C_SPEED_SET(I2C_SPEED_STANDARD) | I2C_MODE_MASTER;
  int res = i2c_configure(p_i2c, dev_config);
  if (res)
  {
    return res;
  }
  struct i2c_msg msgs[2];
  u8_t data[2][2];
  data[0][0] = 0x01; // register address
  data[0][1] = 0x00;
  msgs[0].buf = data[0];
  msgs[0].len = 2U;
  msgs[0].flags = I2C_MSG_WRITE | I2C_MSG_STOP;

  data[1][0] = 0x4;
  data[1][1] = 0xff;
  msgs[1].buf = data[1];
  msgs[1].len = 2U;
  msgs[1].flags = I2C_MSG_WRITE | I2C_MSG_STOP;

  int i = i2c_transfer(p_i2c, &msgs[0], 2, 0x77);
  if  (i)
    printk("transfer failed");
  return 0;
}
<Screen Shot 2020-01-06 at 2.53.05 PM.png>


I2C on nRF5340 Issues #i2c #driver #nrf5340

Marciano
 

I am attempting to write a basic I2C program using Zephyr, but I am currently unable to sent a single byte over I2C. The program hangs after the first clock falling & rising edge.

I'm using external 1K pullups, and have a BME680 device on the other end. I observe the same behavior on the bus with or without the BME680 device.

Am I doing something wrong?

 


prj.conf

CONFIG_NEWLIB_LIBC=y

CONFIG_PRINTK=y

CONFIG_HAS_SEGGER_RTT=y

CONFIG_USE_SEGGER_RTT=y

CONFIG_RTT_CONSOLE=y

CONFIG_UART_CONSOLE=n



# nRF5340 board config

CONFIG_TRUSTED_EXECUTION_SECURE=y



CONFIG_BT=n

CONFIG_TIMESLICING=n

CONFIG_DEVICE_POWER_MANAGEMENT=y

CONFIG_SYS_POWER_MANAGEMENT=y

CONFIG_SYS_POWER_DEEP_SLEEP_STATES=y

CONFIG_DEVICE_POWER_MANAGEMENT=y



CONFIG_I2C=y

CONFIG_I2C_1=y

main.c

#include 
#include 
#include <sys/printk.h>
#include <drivers/i2c.h>

/* Application main Thread */
int main(void)
{
  struct device *p_i2c = device_get_binding("I2C_1");
  u32_t dev_config = I2C_SPEED_SET(I2C_SPEED_STANDARD) | I2C_MODE_MASTER;
  int res = i2c_configure(p_i2c, dev_config);
  if (res)
  {
    return res;
  }
  struct i2c_msg msgs[2];
  u8_t data[2][2];
  data[0][0] = 0x01; // register address
  data[0][1] = 0x00;
  msgs[0].buf = data[0];
  msgs[0].len = 2U;
  msgs[0].flags = I2C_MSG_WRITE | I2C_MSG_STOP;

  data[1][0] = 0x4;
  data[1][1] = 0xff;
  msgs[1].buf = data[1];
  msgs[1].len = 2U;
  msgs[1].flags = I2C_MSG_WRITE | I2C_MSG_STOP;

  int i = i2c_transfer(p_i2c, &msgs[0], 2, 0x77);
  if  (i)
    printk("transfer failed");
  return 0;
}


DHCPV4 and CONFIG_NET_SOCKETS_SOCKOPT_TLS

Denv E
 

Hi,

using zephyr-v2.1.0

I have build the mqtt_publisher sample application for the stm32f746g_disco and it works fine.

I have build the dhcpv4_client sample application for the stm32f746g_disco and it works fine.

When I want to combine both, mqtts and dhcpv4, the dhcpv4 is always timing out.

I have tried step by step.

Using dhcpv4_client sample:

add to prj.conf

# Enable Sockets support
CONFIG_NET_SOCKETS=y
CONFIG_NET_SOCKETS_SOCKOPT_TLS=y

Then the application is no longer compiling:

zephyr/subsys/net/lib/sockets/sockets_tls.c:1735:45: error: 'struct tls_context' has no member named 'ssl'

Does sock_opt_tls is depending on mbedtls? In the guiconfig there is no dependency mentioned between CONFIG_NET_SOCKETS_SOCKOPT_TLS and CONFIG_MBEDTLS.
The sockets_tls uses different mbedtls defines.

What is the correct solution for this problem?

kr,

Wim



API meeting: agenda

Carles Cufi
 

Hi all,

This week we will focus on RFCs and GPIO:

- RFC: API Change: PWM: add support for inverted PWM signals. We will try to close on this today.
- https://github.com/zephyrproject-rtos/zephyr/issues/21384

- RFC: asynchronous i2c and spi API
- https://github.com/zephyrproject-rtos/zephyr/issues/21538

- RFC: Asynchronous sensor API
- https://github.com/zephyrproject-rtos/zephyr/issues/21515

- GPIO: Update on progress
- Look at the PRs with driver conversion (https://github.com/zephyrproject-rtos/zephyr/issues/18530)
- Check users of GPIO APIs: https://github.com/zephyrproject-rtos/zephyr/issues/20017
- Tips for converting users can be found here: https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497 (thanks Peter!)
- Any additional outstanding PRs to topic-gpio

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Re: NRF52 and timing - actual state and what functions to use? #nrf52-pca10040

Chruściński, Krzysztof
 

Hi Martin,

Nrf52832 has 3 RTC's. RTC0 is used for Bluetooth, RTC1 for system clock and RTC2 is usually available for application. You can use RTC2 with counter driver API (see counter.h). Then you can schedule absolute alarms at tick precision.

Regards,
Krzysztof

-----Original Message-----
From: users@lists.zephyrproject.org <users@lists.zephyrproject.org> On Behalf Of Martin Kozusky [newsgroups] via Lists.Zephyrproject.Org
Sent: Sunday, January 5, 2020 9:59 AM
To: users@lists.zephyrproject.org
Cc: users@lists.zephyrproject.org
Subject: [Zephyr-users] NRF52 and timing - actual state and what functions to use?

Hi,
I understand that there are some problems because of 32768Hz RTC (I am now using NRF52-DK and want to use NRF52832 in my new HW) as referenced
here: https://github.com/zephyrproject-rtos/zephyr/issues/9904   there are some already merged PRs (like
https://github.com/zephyrproject-rtos/zephyr/pull/16782 )  and some waiting to merge.

I want to ask:

 1 - what is the best solution to call my function every 1ms (or will it be 1.007ms?), is it ok just to use k_timer? Is "next expiration time"
calculated just by adding period to current time (that would make a big time diff after many calls)  or does it use k_uptime_get*number of expirations to calculate next expiration time?

 2 -  what is the best solution for most precise long-term time keeping?  Let's say i don't want more that 1 minute diff in 20 days. Can I just use k_uptime_get? I would like to make my HW design without aditional external RTC, which can be almost as expensive as another
NRF52832 - is it even possible somehow? Or do you have any tip for some cheap low-power RTC?

 3 - would using external 16MHz/32MHz (or another frequency) oscilator solve anything?

 4 - as someone already wrote here:
https://lists.zephyrproject.org/g/users/topic/28021125  would it be possible to use timer peripheral (with external osc.) to generate better timing (as I would normaly do on bare-metal)?


Thanks.


Re: NRF 802.15.4 driver without networking?

Lubos, Robert
 

Hi Axel,

 

I've found the following configuration to be the minimal needed to use the Zephyr ieee802154 radio driver w/o the networking stack:

    CONFIG_IEEE802154=y

    CONFIG_NETWORKING=y

    CONFIG_IEEE802154_RAW_MODE=y

 

I've tested it with nrf52840_pca10056, this configuration builds:

   * nRF 802.15.4 radio driver (https://github.com/zephyrproject-rtos/hal_nordic/tree/master/drivers/nrf_radio_802154),

   * Zephyr's shim layer for nRF5 radio driver, implementing Zephyr's ieee802154 radio API (https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/ieee802154/ieee802154_nrf5.c),

    * net_pkt/net_buf support from the networking stack (these are unavoidable as Zephyr's ieee802154 radio API depends on it)

 

Note, that when using `CONFIG_IEEE802154_RAW_MODE`, it's expected to implement the following function to collect the packets received:

    int net_recv_data(struct net_if *iface, struct net_pkt *pkt)

 

This configuration is used in samples like `wpanusb` or `wpan_serial`, you can check more about it here: https://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_IEEE802154_RAW_MODE.html

 

 

If your intention is to use the nRF 802.15.4 radio driver directly and omit the Zephyr shim layer, I'm afraid that's not something we support right now. It should be doable of course, but it would require some custom CMake/Kconfig files, it's not something that could be achieved with the existing configuration. I'd recommend though to stick to the Zephyr API, and to propose improvements, if it does not fit your needs for any reason.

 

Regards,

Robert

 

 

From: users@... [mailto:users@...] On Behalf Of Axel Schlueter via Lists.Zephyrproject.Org
Sent: Friday, January 3, 2020 01:40
To: users@...
Cc: users@...
Subject: [Zephyr-users] NRF 802.15.4 driver without networking?

 

Hi,

I should probably start by saying that I’m brand new to Zephyr and that I’m pretty sure I’m missing something obvious or just overlooked parts of the (great!) documentation.

I’m trying to configure my project to use the NRF 802.15.4 radio driver coming with Zephyr (in the modules/hal/nordic/drivers/nrf_radio_802154) without any of the other Zephyr networking support, but I can’t figure out a project config that would help me achieve this. I played with various configs, and the most promising seems to be

CONFIG_NETWORKING=n
CONFIG_IEEE802154=y
CONFIG_IEEE802154_NRF5=y
CONFIG_IEEE802154_RAW_MODE=n
CONFIG_HAS_NORDIC_DRIVERS=y

but Kconfig won’t let me set CONFIG_HAS_NORDIC_DRIVERS manually (which is required to include the drivers subfolder, see modules/hal/nordic/CMakeLists.txt).

As a desperate measure I tried to set every CONFIG_IEEE802154_xxx config flag to no and instead include the driver as an extra module via

set(ZEPHYR_EXTRA_MODULES [some_directory]/modules/hal/nordic/drivers/nrf_radio_802154)

but no luck either.

Any ideas what else I could try?

Thanks,
Axel


Re: #i2c How to configure Atmel samd21 to use sercom3 #i2c

Robin Callender <robin@...>
 

I forgot to include the overlay file…here it is.



On Jan 6, 2020, at 4:16 PM, Robin Callender <robin@...> wrote:

We are trying to understand how to configure sercom3 to allow I2C support.
The I2C device is the adafruit_oled_featherwing.
I believe I have the I2C, SSD1306, framebuffer (cfg), and display.  
Below is the relevant portions of the prj.conf file

Our app builds with these setting, but doesn't seem to conduct I2C traffic.
We going though the SAMD21 datasheet, but it is very confusing.
We don't understand how the pinmux is being driven to set the pad to I2C mode.

Are there any examples showing how to configure I2C for the adafruit_feather_m0_basic board or any other samd21 type board?

CONFIG_HEAP_MEM_POOL_SIZE=4096
CONFIG_HEAP_MEM_POOL_MIN_SIZE=64
 
CONFIG_HAS_DTS_I2C=y
CONFIG_I2C=y
CONFIG_I2C_SAM0=y
CONFIG_I2C_INIT_PRIORITY=60
CONFIG_I2C_0=y
 
CONFIG_DISPLAY=y
CONFIG_SSD1306=y
 
CONFIG_CHARACTER_FRAMEBUFFER=y
CONFIG_CHARACTER_FRAMEBUFFER_USE_DEFAULT_FONTS=y



#i2c How to configure Atmel samd21 to use sercom3 #i2c

Robin Callender <robin@...>
 

We are trying to understand how to configure sercom3 to allow I2C support.
The I2C device is the adafruit_oled_featherwing.
I believe I have the I2C, SSD1306, framebuffer (cfg), and display.  
Below is the relevant portions of the prj.conf file

Our app builds with these setting, but doesn't seem to conduct I2C traffic.
We going though the SAMD21 datasheet, but it is very confusing.
We don't understand how the pinmux is being driven to set the pad to I2C mode.

Are there any examples showing how to configure I2C for the adafruit_feather_m0_basic board or any other samd21 type board?

CONFIG_HEAP_MEM_POOL_SIZE=4096
CONFIG_HEAP_MEM_POOL_MIN_SIZE=64
 
CONFIG_HAS_DTS_I2C=y
CONFIG_I2C=y
CONFIG_I2C_SAM0=y
CONFIG_I2C_INIT_PRIORITY=60
CONFIG_I2C_0=y
 
CONFIG_DISPLAY=y
CONFIG_SSD1306=y
 
CONFIG_CHARACTER_FRAMEBUFFER=y
CONFIG_CHARACTER_FRAMEBUFFER_USE_DEFAULT_FONTS=y


Re: NRF52 and timing - actual state and what functions to use? #nrf52-pca10040

Martin Kozusky
 

Dne 06.01.2020 v 18:31 Andy Ross napsal(a):
On 1/5/20 4:30 AM, Martin Kozusky [newsgroups] wrote:
1 - what is the best solution to call my function every 1ms (or will
it be 1.007ms?), is it ok just to use k_timer? Is "next expiration
time" calculated just by adding period to current time (that would
make a big time diff after many calls) or does it use
k_uptime_get*number of expirations to calculate next expiration
time?
Periodic k_timer's do not work in fractional ticks, no. If you
schedule a 1000ms timeout it will be rounded up internally to exactly
33 hardware cycles, and that process will repeat each cycle.  So you
would see the ~993 Hz tick rate you calculated.  If you want to work
in fractional ticks, the application needs to do that math itself.
is it 1000ms timeout = 33 cycles, or 1ms timeout = 33 cycles? This is acceptable for short-term timeouts.

2 - what is the best solution for most precise long-term time
keeping?  Let's say i don't want more that 1 minute diff in 20
days. Can I just use k_uptime_get?
Long term time is kept as a 64 bit count of ticks, so it's not subject
to the kind of round-off errors that periodic timers are.  As long as
your app isn't dropping or delaying the counter interrupts, the uptime
value should be as accurate as your crystal is.

If you want to get 1 callback per second as a long term average, you
can (with care) compute your timeout as an offset from system start or
some other time reference instead of "now" (i.e. the Nth timeout will
happen at "N * 1000ms", plus a little precision slop due to the clock
mismatch).  There's actually an API change which will make this kind
of code significantly easier, see
https://github.com/zephyrproject-rtos/zephyr/issues/21305
When this gets into 2.2, can I use "k_uptime_ticks() / 32768" to get the exact time in seconds?

As far as using a different oscillator to drive the timer, that's
possible but requires some driver fiddling.  I'll let the Nordic folks
speak to that.  One option might be to use the generic ARM SysTick
driver, which doesn't have the rate mismatch issues of the 32kHz
timer, but doesn't have the low power idle characteristics.
On another project, I would like to be sleeping most of the time to save power and want to be woken by pin interrupt or 1 sec timeout, so it is good idea to have clock in low-power.

BTW: When I enter to sleep by k_sleep(), is there  any change in power consumption besides thread being put to sleep? Or do I have to call device_set_power_state(DEVICE_PM_LOW_POWER_STATE) to enter low-power mode? Will I be automaticaly put to DEVICE_PM_ACTIVE_STATE when there is an pin interrupt and is there any way how to get number of ticks I've been in low-power mode since I was woken by pin interrupt? (are ticks also incremented in low-power mode?) (on bare-metal I would set RTC modulo to wake after 1 second, go to low-power and if I got woken earlier by pin interrupt, I would read RTC counter to get the exact time I was sleeping or if I got woken by RTC INT, I would know it was exactly 1 sec, then do some stuff, again setup RTC, go to sleep  ... is this even possible with Zephyr and NRF52832? )

Andy
Thanks,
Martin


Re: NRF52 and timing - actual state and what functions to use? #nrf52-pca10040

Andy Ross
 

On 1/5/20 4:30 AM, Martin Kozusky [newsgroups] wrote:
1 - what is the best solution to call my function every 1ms (or will
it be 1.007ms?), is it ok just to use k_timer? Is "next expiration
time" calculated just by adding period to current time (that would
make a big time diff after many calls) or does it use
k_uptime_get*number of expirations to calculate next expiration
time?
Periodic k_timer's do not work in fractional ticks, no. If you
schedule a 1000ms timeout it will be rounded up internally to exactly
33 hardware cycles, and that process will repeat each cycle. So you
would see the ~993 Hz tick rate you calculated. If you want to work
in fractional ticks, the application needs to do that math itself.

2 - what is the best solution for most precise long-term time
keeping? Let's say i don't want more that 1 minute diff in 20
days. Can I just use k_uptime_get?
Long term time is kept as a 64 bit count of ticks, so it's not subject
to the kind of round-off errors that periodic timers are. As long as
your app isn't dropping or delaying the counter interrupts, the uptime
value should be as accurate as your crystal is.

If you want to get 1 callback per second as a long term average, you
can (with care) compute your timeout as an offset from system start or
some other time reference instead of "now" (i.e. the Nth timeout will
happen at "N * 1000ms", plus a little precision slop due to the clock
mismatch). There's actually an API change which will make this kind
of code significantly easier, see
https://github.com/zephyrproject-rtos/zephyr/issues/21305

As far as using a different oscillator to drive the timer, that's
possible but requires some driver fiddling. I'll let the Nordic folks
speak to that. One option might be to use the generic ARM SysTick
driver, which doesn't have the rate mismatch issues of the 32kHz
timer, but doesn't have the low power idle characteristics.

Andy


NRF52 and timing - actual state and what functions to use? #nrf52-pca10040

Martin Kozusky
 

Hi,
I understand that there are some problems because of 32768Hz RTC (I am now using NRF52-DK and want to use NRF52832 in my new HW) as referenced here: https://github.com/zephyrproject-rtos/zephyr/issues/9904   there are some already merged PRs (like https://github.com/zephyrproject-rtos/zephyr/pull/16782 )  and some waiting to merge.

I want to ask:

 1 - what is the best solution to call my function every 1ms (or will it be 1.007ms?), is it ok just to use k_timer? Is "next expiration time" calculated just by adding period to current time (that would make a big time diff after many calls)  or does it use k_uptime_get*number of expirations to calculate next expiration time?

 2 -  what is the best solution for most precise long-term time keeping?  Let's say i don't want more that 1 minute diff in 20 days. Can I just use k_uptime_get? I would like to make my HW design without aditional external RTC, which can be almost as expensive as another NRF52832 - is it even possible somehow? Or do you have any tip for some cheap low-power RTC?

 3 - would using external 16MHz/32MHz (or another frequency) oscilator solve anything?

 4 - as someone already wrote here: https://lists.zephyrproject.org/g/users/topic/28021125  would it be possible to use timer peripheral (with external osc.) to generate better timing (as I would normaly do on bare-metal)?


Thanks.


NRF52 and timing - actual state and what functions to use? #nrf52-pca10040

Martin Kozusky
 

Hi,
I understand that there are some problems because of 32768Hz RTC with NRF52832 as referenced here: https://github.com/zephyrproject-rtos/zephyr/issues/9904  , there are some already merged PRs (like https://github.com/zephyrproject-rtos/zephyr/pull/16782 )  and some waiting to merge, so what is the actual state at 2.1.0?

I want to ask:

 1 - what is the best solution to call my function every 1ms (or will it be 1.007ms?), is it ok just to use k_timer? Is "next expiration time" calculated just by adding period to current time (that would make a big time diff after many calls)  or does it use k_uptime_get*number of expirations to calculate next expiration time?

 2 -  what is the best solution for most precise long-term time keeping?  Let's say i don't want more that 1 minute diff in 20 days. Can I just use k_uptime_get? I would like to make my HW design without aditional external RTC, which can be almost as expensive as another NRF52832 - is it even possible somehow? Or do you have any tip for some cheap low-power RTC?

 3 - would using external 16MHz/32MHz (or another frequency) oscilator solve anything?

 4 - as someone already wrote here: https://lists.zephyrproject.org/g/users/topic/28021125  would it be possible to use timer peripheral (with external osc.) to generate better timing (as I would normaly do with bare-metal sources)?


Thanks.


Re: Failure of CMD0 sending using STM32F769 + SPI2 for [samples/subsys/fs/fat_fs] #spi #fatfs

@yasokada
 

Instead of adding k_usleep(30),
I changed the SPI clock from 210kHz to 406kHz for STM32F769.

Then, the problems of A and B are gone.
Still I have the problem of C.
I receive 0x07 instead of 0x01.



From what I read throught the internet, the CRC for CMD is 0x95. But in Zephyr, the CRC is 0x94.
I wonder whether this difference cause some problem. However, for STM32L476, this works.

I will check further on this. 


Re: Failure of CMD0 sending using STM32F769 + SPI2 for [samples/subsys/fs/fat_fs] #spi #fatfs

@yasokada
 

From what I checked:

- A. 74 clocks stop with a change in CS without sufficient delay
- B. CMD0 (0x40 0x00 0x00 0x00 0x00 0x94) fails to send 0x40... (instead send 0x20...)
- C. CMD0 fails to receive 0x01

I added `k_usleep(30); // usec` before sdhc_spi_set_cs(data, 0); in sdhc_spi_go_idle() of disk_access_spi_sdhc.c.
Then, the above A and B are solved.
However, I still have the problem of C.
This may be caused without sufficient delay after sending 0x94. I am checking how to add delay after 0x94.

I also checked the clock frequency.
- STM32L476: 312kHz
- STM32F768: 210kHz

I am not sure whether this difference in the frequency makes the failure and success of the process.


Re: "in-tree" builds > its meaning

@yasokada
 

Dear Marti

Thank you very much for your reply.
I can understand the difference now.

Best regards

Yasuhiko Okada


NRF 802.15.4 driver without networking?

axel+zephyr@...
 

Hi,

I should probably start by saying that I’m brand new to Zephyr and that I’m pretty sure I’m missing something obvious or just overlooked parts of the (great!) documentation.

I’m trying to configure my project to use the NRF 802.15.4 radio driver coming with Zephyr (in the modules/hal/nordic/drivers/nrf_radio_802154) without any of the other Zephyr networking support, but I can’t figure out a project config that would help me achieve this. I played with various configs, and the most promising seems to be

CONFIG_NETWORKING=n
CONFIG_IEEE802154=y
CONFIG_IEEE802154_NRF5=y
CONFIG_IEEE802154_RAW_MODE=n
CONFIG_HAS_NORDIC_DRIVERS=y

but Kconfig won’t let me set CONFIG_HAS_NORDIC_DRIVERS manually (which is required to include the drivers subfolder, see modules/hal/nordic/CMakeLists.txt).

As a desperate measure I tried to set every CONFIG_IEEE802154_xxx config flag to no and instead include the driver as an extra module via

set(ZEPHYR_EXTRA_MODULES [some_directory]/modules/hal/nordic/drivers/nrf_radio_802154)

but no luck either.

Any ideas what else I could try?

Thanks,
Axel

861 - 880 of 2705