Date   

Removing an item from the Device tree

Lawrence King
 

I have a little problem with the device tree

 

In zephyrproject/zephyr/boards/arm/nrf52840_mdk/nrf52840_mdk.dts the uart is defined as:

 

&uart0 {

        compatible = "nordic,nrf-uart";

        current-speed = <115200>;

        status = "okay";

        tx-pin = <20>;

        rx-pin = <19>;

       rts-pin = <5>;

        cts-pin = <7>;

};

 

Which works just fine. However I am not using the RTS and CTS pin features of the UART, and I need to use the pins for other things. I can simply go into the DTS file and comment out the two pins:

 

&uart0 {

        compatible = "nordic,nrf-uart";

        current-speed = <115200>;

        status = "okay";

        tx-pin = <20>;

        rx-pin = <19>;

/*      rts-pin = <5>;  */

/*      cts-pin = <7>;  */

};

 

And all is good. However I would prefer to use an overlay in my local working directory instead of making changes to the zephyr tree. I did try redefining uart0 in the local overlay, but RTS and CTS are still there.

 

What is the right way to remove RTS and CTS?

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 


Re: NVS on flash with erase page size 64k or larger #nvs

Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
 

NVS on flash with erase page size 64k or larger #nvs

 Marco

Jan 2   

 

  • Hi there

    > In my application I try to use NVS on an external SPI flash (M25P16) which has an erase page size of 64k.

    > As I realised, NVS seems to have some limit on its maximum sector size of just below those 64k, since the variable storing it is an u16_t.

    > Is there any workaround to get this combination to work anyway, or is even an enhancement planned, to overcome this limit?
    > Since there are still quite a few memories on the market with page sizes exceeding those 64k it might be interesting generally.

    > Thanks and regards.

 

Hi.

 

64k sector is known limitation – it is not planed by us to support more right now. Although a patch witch configurable extension will be accepted.

(a I know the code, it shouldn’t be hard to add such extension).

AndrzejR

 


Re: Feedback requested on west manifest imports

Jørn Villesen Christensen <jvc@...>
 

On 14/01/2020 19:33, Bolivar, Marti wrote:
Hello Zephyr users and developers,

We've just uploaded a pre-release version of west to PyPI with a new
feature: manifest imports. We would like your feedback!

Please let us know what you think. We'd like to get feedback before
the west 0.7 release, as making big changes after that time will be
harder to do.
Just had a read through your documentation; it looks nice. Have not
tested the code, but judging from the documentation, it looks useful.

Thank you :-)

~Jørn


DTS/Binding Issue migrating from 2.0.0 to 2.1.0 #nrf52832

matt@...
 

Hello Zephyr Users,

I have inherited a Zephyr project using nRF52832 from another developer and am having an issue migrating from 2.0.0 to 2.1.0. Its probably something simple but I'm fairly new to the devicetree system and can't seem to wrap my head around whats wrong here.

In my custom board .dts file I have the following i2c configuration (note that the lis3dh is a zephyr-supported sensor driver and I have custom drivers/bindings for tca6507 and mcp47cvb12):

&i2c0 {
        status = "okay";
        sda-pin = <7>;
        scl-pin = <5>;
        clock-frequency = <I2C_BITRATE_FAST>;
 
        lis3dh@19 {
                compatible = "st,lis2dh", "st,lis3dh";
                reg = <0x19>;
                irq-gpios = <&gpio0 19 0>;
                label = "LIS3DH";
        };
 
        tca6507@45 {
                compatible = "ti,tca6507";
                reg = <0x45>;
                enable-gpios = <&gpio0 26 GPIO_DIR_OUT>;
                label = "TCA6507";
        };
 
        mcp47cvb12@60 {
                compatible = "mcp,mcp47cvb12";
                reg = <0x60>;
                label = "MCP47CVB12";
        };
};
Using OS v2.0.0 this built properly. After upgrading the OS to v2.1.0, I get the following error from `zephyr/scripts/dts/extract_dts_includes.py` on build: 

Exception: /soc/i2c@40003000/lis3dh@19 defines parent /soc/i2c@40003000 as bus master, but /soc/i2c@40003000 is not configured as bus master in binding
By changing `compatible = "st,lis2dh", "st,lis3dh";` to `compatible = "st,lis2dh-i2c", "st,lis3dh-i2c";` in the .dts file this gets rid of the error for the lis3dh, but i get a similar error for `mcp47cvb12` and `tca6507`. For completeness, here are my .yaml files for these two bindings:

mcp,mcp47cvb12.yaml:
title: Microchip MCP47CVB12 Driver
 
description: Microchip MCP47CVB12 DAC binding
 
compatible: "mcp,mcp47cvb12"
 
include: i2c-device.yaml
ti,tca6507.yaml:
title: TI TCA6507 LED Driver
 
description: TI TCA6507 LED binding
 
compatible: "ti,tca6507"
 
include: i2c-device.yaml
 
properties:
    enable-gpios:
      type: compound
      required: true
Alright so onto direct questions:

  1. What does the error message `but /soc/i2c@40003000 is not configured as bus master in binding` mean? It seems to me that `i2c-device.yaml` correctly sets `parent-bus: i2c`
  2. Why does adding the `-i2c` to the .dts file `compatible` field for the lis3dh fix this error? I never had to add this in the past.
  3. What do I need to change, if anything, in my custom device bindings to fix this error?
Thank you for your help,

Matt


Feedback requested on west manifest imports

Bolivar, Marti
 

Hello Zephyr users and developers,

We've just uploaded a pre-release version of west to PyPI with a new
feature: manifest imports. We would like your feedback!

For a short README you can follow to try it out, see:

https://github.com/mbolivar/my-zephyr-app

This new feature lets you import projects from a west.yml file
somewhere else (like zephyr/west.yml) into your own "downstream"
west.yml file.

The import gives you the zephyr repository and all its modules "for
free": you do not have to copy/paste projects from zephyr/west.yml into
your custom file and manually track changes. You can also add your own
repositories or override individual modules if you've got your own
forks, etc. See the README for links to more information.

Please let us know what you think. We'd like to get feedback before
the west 0.7 release, as making big changes after that time will be
harder to do.

Thanks!
Marti


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.

701 - 720 of 2550