Date   

Re: rs485 driver #stm32

Dave Nadler
 

Careful, while that may work in some cases,
we've always needed to implement fast control of xmit/receive switching in the driver
to avoid multiple devices sometimes trying to drive the bus.

Can any Zephyr users/developers provide further information about driver support for RS-485??

Thanks,
Best Regards, Dave

On 9/2/2021 10:03 AM, Rodrigo Peixoto wrote:
Hi Arsenii.
I have already used that with an external transceiver driving the RE/DE every time we would write to and disable it after that as a generic GPIO (output). We write the data using a regular UART driver. The RS485 part is performed by the transceiver. 

I hope it helps.
Best regards,
Rodrigo Peixoto. 

On Wed, Sep 1, 2021 at 8:35 AM Arsenii Soitu <seniasoitu@...> wrote:
Hello.
Is there any driver or may be some way to use rs485 on zephyr?
May be someone used zephyr for rs485 communication with RE/DE support?
Thank you
_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#2694) | Reply To Sender | Reply To Group | Mute This Topic | New Topic
Mute #stm32
Your Subscription | Contact Group Owner | Unsubscribe [drn@...]


-- 
Dave Nadler, USA East Coast voice (978) 263-0097, drn@..., Skype 
 Dave.Nadler1


Zephyr Question

Hulbert Zeng <hzeng012@...>
 

Dear Whom It May Concern,


I'm currently using Zephyr on a Nordic Thingy 52 to collect environment data and I was wondering how I might be able to lower the power consumption in between measurements?


Thank You,

Hulbert Zeng


Re: rs485 driver #stm32

Rodrigo Peixoto
 

Hi Arsenii.
I have already used that with an external transceiver driving the RE/DE every time we would write to and disable it after that as a generic GPIO (output). We write the data using a regular UART driver. The RS485 part is performed by the transceiver. 

I hope it helps.
Best regards,
Rodrigo Peixoto. 

On Wed, Sep 1, 2021 at 8:35 AM Arsenii Soitu <seniasoitu@...> wrote:
Hello.
Is there any driver or may be some way to use rs485 on zephyr? May be someone used zephyr for rs485 communication with RE/DE support?
Thank you


rs485 driver #stm32

Arsenii Soitu
 

Hello.
Is there any driver or may be some way to use rs485 on zephyr? May be someone used zephyr for rs485 communication with RE/DE support?
Thank you


Re: #stm32 build failure #stm32

alt.mcarter@...
 

I think I sent a private reply rather than to group. Let me try again ...
Which version of which toolchain are you using, and which version of zephyr?
Everything is a recent install.
zephyr-sdk-0.13.0

Version of zephyr I'm using:
commit fcfe597e5dadb96ecef5d6e8c82ffc99b5f4d59c (HEAD -> main, origin/main, origin/HEAD)
Author: Iuliana Prodan <iuliana.prodan@...>
Date:   Sat Aug 28 01:08:19 2021 +0300
OK, so now I checkout tag zephyr-v2.6.0.

Then I do
rm -rf build

mkdir build

cd build

cmake ..

I get
Including boilerplate (Zephyr base): /home/pi/zephyrproject/zephyr/cmake/app/boilerplate.cmake
CMake Deprecation Warning at /home/pi/zephyrproject/zephyr/cmake/app/boilerplate.cmake:37 (cmake_policy):
  The OLD behavior for policy CMP0079 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.

I had that before, though.

My errors are now:
Parsing /home/pi/zephyrproject/zephyr/Kconfig
/home/pi/zephyrproject/zephyr/scripts/kconfig/kconfig.py: /home/pi/zephyrproject/my_blinky/build/Kconfig/Kconfig.modules:2: Could not open '/home/pi/zephyrproject/zephyr/' (in 'osource "$(ZEPHYR_CANOPENNODE_KCONFIG)"') (EISDIR: Is a directory)
CMake Error at /home/pi/zephyrproject/zephyr/cmake/kconfig.cmake:264 (message):
  command failed with return code: 1
Call Stack (most recent call first):
  /home/pi/zephyrproject/zephyr/cmake/app/boilerplate.cmake:565 (include)
  /home/pi/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
  /home/pi/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:35 (include_boilerplate)
  CMakeLists.txt:4 (find_package)


-- Configuring incomplete, errors occurred!


Re: #stm32 build failure #stm32

Nick Stoughton
 

Which version of which toolchain are you using, and which version of zephyr?
-- 
Nick


On Tue, Aug 31, 2021 at 11:34 AM <alt.mcarter@...> wrote:
I'm trying to build a project. I'm getting:
 48%] Building ASM object zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/cpu_idle.S.obj
cc: warning: '-mcpu=' is deprecated; use '-mtune=' or '-march=' instead
cc: error: unrecognized argument in option '-mabi=aapcs'
cc: note: valid arguments to '-mabi=' are: ms sysv
cc: error: unrecognized command-line option '-mthumb'
gmake[2]: *** [zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/build.make:75: zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/cpu_idle.S.obj] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:2814: zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/all] Error 2
gmake: *** [Makefile:91: all] Error 2
FATAL ERROR: command exited with status 2: /home/pi/.local/bin/cmake --build /home/pi/zephyrproject/my_blinky/build
Here's my CMakeLists.txt file:
cmake_minimum_required(VERSION 3.20.0)
set(BOARD blackpill_f411ce)
#include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(zblinky)
target_sources(app PRIVATE main.c)
What is going wrong?


#stm32 build failure #stm32

alt.mcarter@...
 

I'm trying to build a project. I'm getting:
 48%] Building ASM object zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/cpu_idle.S.obj
cc: warning: '-mcpu=' is deprecated; use '-mtune=' or '-march=' instead
cc: error: unrecognized argument in option '-mabi=aapcs'
cc: note: valid arguments to '-mabi=' are: ms sysv
cc: error: unrecognized command-line option '-mthumb'
gmake[2]: *** [zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/build.make:75: zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/cpu_idle.S.obj] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:2814: zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/all] Error 2
gmake: *** [Makefile:91: all] Error 2
FATAL ERROR: command exited with status 2: /home/pi/.local/bin/cmake --build /home/pi/zephyrproject/my_blinky/build
Here's my CMakeLists.txt file:
cmake_minimum_required(VERSION 3.20.0)
set(BOARD blackpill_f411ce)
#include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(zblinky)
target_sources(app PRIVATE main.c)
What is going wrong?


Re: west installation error

Moiz Terem <moiz.terem@...>
 

Thanks for the answers,  yes disabling the Symantec solve the issue.

Best Regards,
Moiz


From: Bolivar, Marti <Marti.Bolivar@...>
Sent: Monday, August 23, 2021 9:09:57 PM
To: Moiz Terem <moiz.terem@...>; users@... <users@...>
Subject: Re: [Zephyr-users] west installation error
 
CAUTION: External Email.

Hi,

See inline.

"Moiz Terem via lists.zephyrproject.org"
<moiz.terem=inomize.com@...> writes:

> Can you also temporarily disable the Symantec ? to check if this is
> the issue?

I'm not sure what you are asking. PyPI doesn't have any relationship
with Symantec that I am aware of, if that's what you mean.

>
> Best Regards,
> Moiz Terem
>
> From: Moiz Terem
> Sent: Sunday, 22 August 2021 15:02
> To: users@...
> Subject: west installation error
>
> Hi,
>
> I am trying to install Zephyr for Windows. I followed your installation steps.
>
> When installing west, I am getting the following errors:
>
> Thanks for your help.
>
>
> [Window]

Looks like an SSL issue. Perhaps your computer doesn't have the
necessary certificate authorities configured? I don't think this is a
PyPI issue; it's rather more likely an issue with your local
environment.

Sorry I'm not more help, but maybe someone else more familiar with
Windows SSL issues like these can chime in.

Best,
Martí

>
>
> Best Regards,
> Moiz Terem
>
>
>
>


Re: west installation error

Bolivar, Marti
 

Hi,

See inline.

"Moiz Terem via lists.zephyrproject.org"
<moiz.terem=inomize.com@lists.zephyrproject.org> writes:

Can you also temporarily disable the Symantec ? to check if this is
the issue?
I'm not sure what you are asking. PyPI doesn't have any relationship
with Symantec that I am aware of, if that's what you mean.


Best Regards,
Moiz Terem

From: Moiz Terem
Sent: Sunday, 22 August 2021 15:02
To: users@lists.zephyrproject.org
Subject: west installation error

Hi,

I am trying to install Zephyr for Windows. I followed your installation steps.

When installing west, I am getting the following errors:

Thanks for your help.


[Window]
Looks like an SSL issue. Perhaps your computer doesn't have the
necessary certificate authorities configured? I don't think this is a
PyPI issue; it's rather more likely an issue with your local
environment.

Sorry I'm not more help, but maybe someone else more familiar with
Windows SSL issues like these can chime in.

Best,
Martí



Best Regards,
Moiz Terem




Re: west installation error

Moiz Terem <moiz.terem@...>
 

Can you also temporarily disable the Symantec ? to check if this is the issue?

 

Best Regards,

Moiz Terem

 

From: Moiz Terem
Sent: Sunday, 22 August 2021 15:02
To: users@...
Subject: west installation error

 

Hi,

 

I am trying to install Zephyr for Windows. I followed your installation steps.

 

When installing west, I am getting the following errors:

 

Thanks for your help.

 


Window

 

 

Best Regards,

Moiz Terem

 


west installation error

Moiz Terem <moiz.terem@...>
 

Hi,

 

I am trying to install Zephyr for Windows. I followed your installation steps.

 

When installing west, I am getting the following errors:

 

Thanks for your help.

 


Window

 

 

Best Regards,

Moiz Terem

 


Re: HCI SPI - how to use

Piotr Barszczewski <piotr@...>
 

Hi,

I’ll look into it and the board definitions. I think this was the part I’ve missed, that the project has 2 96b_carbon and 96b_carbon_nrf51 board configurations which are not part of the example but Zephyr boards definition. Thank you for pointing that out.

Best regards,
PB

On 14 August 2021 at 02:30:47, Bolivar, Marti (marti.bolivar@...) wrote:

Hi,

The hci_spi sample was originally upstreamed for use on the nRF51 chip
on the 96Boards Carbon board.

Please refer to the documentation for that board for more information.
You can refer to 96b_carbon and 96b_carbon_nrf51 board configurations as
a starting point for your own application.

Marti

"Piotr Barszczewski via lists.zephyrproject.org"
<piotr=1am.pl@...> writes:

> Hello,
>
> I’ve found that Zephyr HCI stack supports SPI as transport and there is an
> implementation available
> https://docs.zephyrproject.org/latest/samples/bluetooth/hci_spi/README.html
> I’m wondering how could this actually be tested - just by sending raw HCI
> bytes to the board flashed with
> https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/bluetooth/hci_spi
> ?
>
> My interest is in somehow making it possible for embedded Linux
> distribution be able to use SPI transport for HCI. With all the chip
> shortages of recent months and unsure about future I’m looking for a way to
> get rid of relying on USB. Uart would be good but is already used + I need
> more than 1, so besides USB I’ve only got SPI left but not sure how it’s
> supposed to be tested. Guess I’m missing what the host should do, with USB
> it’s clear.
>
> Is there anybody who has prior experience with running the HCI SPI
> implementation?
>
> Best regards
>
>
>


Re: HCI SPI - how to use

Bolivar, Marti
 

Hi,

The hci_spi sample was originally upstreamed for use on the nRF51 chip
on the 96Boards Carbon board.

Please refer to the documentation for that board for more information.
You can refer to 96b_carbon and 96b_carbon_nrf51 board configurations as
a starting point for your own application.

Marti

"Piotr Barszczewski via lists.zephyrproject.org"
<piotr=1am.pl@lists.zephyrproject.org> writes:

Hello,

I’ve found that Zephyr HCI stack supports SPI as transport and there is an
implementation available
https://docs.zephyrproject.org/latest/samples/bluetooth/hci_spi/README.html
I’m wondering how could this actually be tested - just by sending raw HCI
bytes to the board flashed with
https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/bluetooth/hci_spi
?

My interest is in somehow making it possible for embedded Linux
distribution be able to use SPI transport for HCI. With all the chip
shortages of recent months and unsure about future I’m looking for a way to
get rid of relying on USB. Uart would be good but is already used + I need
more than 1, so besides USB I’ve only got SPI left but not sure how it’s
supposed to be tested. Guess I’m missing what the host should do, with USB
it’s clear.

Is there anybody who has prior experience with running the HCI SPI
implementation?

Best regards



HCI SPI - how to use

Piotr Barszczewski <piotr@...>
 

Hello,

I’ve found that Zephyr HCI stack supports SPI as transport and there is an implementation available https://docs.zephyrproject.org/latest/samples/bluetooth/hci_spi/README.html 
I’m wondering how could this actually be tested - just by sending raw HCI bytes to the board flashed with https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/bluetooth/hci_spi ?

My interest is in somehow making it possible for embedded Linux distribution be able to use SPI transport for HCI. With all the chip shortages of recent months and unsure about future I’m looking for a way to get rid of relying on USB. Uart would be good but is already used + I need more than 1, so besides USB I’ve only got SPI left but not sure how it’s supposed to be tested. Guess I’m missing what the host should do, with USB it’s clear.

Is there anybody who has prior experience with running the HCI SPI implementation?

Best regards
 


Re: Edge connectors and pin numbers

Bolivar, Marti
 

Hi,

"Frank Duignan via lists.zephyrproject.org"
<frank.duignan=gmail.com@lists.zephyrproject.org> writes:

I'm working with the BBC Microbit V2 and can use the peripherals using the NRF port pin numbers etc.  These port pins are brought to an edge connector which numbers them completely differently.  There seems to be some support for this in the bbc_microbit_v2 dts file in the following form:
edge_connector: connector {
compatible = "microbit,edge-connector";
#gpio-cells = <2>;
gpio-map-mask = <0xffffffff 0xffffffc0>;
gpio-map-pass-thru = <0 0x3f>;
gpio-map = <0 0 &gpio0 2 0>, /* P0 */
<1 0 &gpio0 3 0>, /* P1 */
<2 0 &gpio0 4 0>, /* P2 */
<3 0 &gpio0 31 0>, /* P3 */
<4 0 &gpio0 28 0>, /* P4 */
<5 0 &gpio0 14 0>, /* P5 */
<6 0 &gpio1 5 0>, /* P6 */
<7 0 &gpio0 11 0>, /* P7 */
<8 0 &gpio0 10 0>, /* P8 */
<9 0 &gpio0 9 0>, /* P9 */
<10 0 &gpio0 30 0>, /* P10 */
<11 0 &gpio0 23 0>, /* P11 */
<12 0 &gpio0 12 0>, /* P12 */
<13 0 &gpio0 17 0>, /* P13 */
<14 0 &gpio0 1 0>, /* P14 */
<15 0 &gpio0 13 0>, /* P15 */
<16 0 &gpio1 2 0>, /* P16 */
<19 0 &gpio0 26 0>, /* P19 */
<20 0 &gpio1 0 0>; /* P20 */
};
};
Yes, this is a GPIO nexus node. For details on these, see "2.5 Nexus
Nodes and Specifier Mapping" in the DT spec v0.3:

https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3

Nexus nodes are weird and can be confusing to deal with at first.

I've been meaning to improve the documentation for these for a while,
but hopefully the following reply will help, with extra details for the
sake of the list archives.

My question is: how do I get a binding to one/all of these i/o pins.  I've tried many many combinations of DT_ macros.  The following returns a non null value for "edge" but I can't figure out how to access the pins on that edge connector using the connector pin  numbering scheme.
struct device *edge; edge=DEVICE_DT_GET(DT_NODELABEL(edge_connector));
Right, this doesn't work because there is no driver which allocates
struct devices for the "microbit,edge-connector" compatible.

I'm going to shamelessly keep plugging my recent talk which explains how
all this works in more detail:

https://www.youtube.com/watch?v=sWaxQyIgEBY

Since it's not a GPIO controller node, but a nexus node, there isn't a
single GPIO device in C which corresponds to it. All you can really do
with it is specify GPIOs in other properties, which will map to the
underlying GPIO controller/pin/flags/etc according to the gpio-map and
other properties.

I said it was confusing at first, right?

It's not a show stopper as I can revert to nordic pin numbering but it
would be nice if the numbers in the C code corresponded to the label
on the board.
Here is a simple example of how you can use this from C with
/zephyr,user and struct gpio_dt_spec, with error handling omitted for
brevity. (See the DT bindings guide for more on /zephyr,user.)

app.overlay:

/ {
zephyr,user {
/* P1, active high */
foo-gpios = <&edge_connector 1 GPIO_ACTIVE_HIGH>;
};
};

main.c:

#include <zephyr.h>
#include <sys/printk.h>
#include <devicetree.h>
#include <drivers/gpio.h>

static struct gpio_dt_spec foo =
GPIO_DT_SPEC_GET(DT_PATH(zephyr_user), foo_gpios);

void main(void)
{
printk("Using device %s pin %d\n",
foo.port->name, foo.pin);

gpio_pin_configure_dt(&foo, GPIO_OUTPUT);
while (1) {
gpio_pin_set_dt(&foo, 0);
k_msleep(10);
gpio_pin_set_dt(&foo, 1);
k_msleep(10);
}
}

This should print "Using device GPIO_0 pin 3", and toggle that GPIO
forever. I don't have your hardware, so I can't test, but something
similar works on nRF52-DK with the arduino_header nexus node.

Notice how a full specification of a pin requires GPIO flags in addition
to the controller/pin number. See include/dt-bindings/gpio/gpio.h for
other flags you can use besides GPIO_ACTIVE_HIGH.

This is another case of the devicetree "vanishing" like I described in
my talk -- the edge_connector node itself has no representation as a
device, but you can use it at compile time to find the "real" devices
(foo.port in this case) that are broken out onto the connector.

If you want to get fancy with multiple pins, you can do something like
this:

foo-gpios = <&edge_connector 0 GPIO_ACTIVE_HIGH>, /* P0 */
<&edge_connector 1 GPIO_ACTIVE_LOW>, /* P1, opposite polarity */
...;

and then:

#define GET_PIN_N(node_id, prop, n) GPIO_DT_SPEC_GET_BY_IDX(node_id, prop, n),

static struct gpio_dt_spec foos[] = {
DT_FOREACH_PROP_ELEM(DT_PATH(zephyr_user), foo_gpios, GET_PIN_N)
};

for (int i = 0; i < ARRAY_SIZE(foos); i++) {
printk("device %s pin %d\n", foos[i].port->name, foos[i].pin);
gpio_pin_configure_dt(&foos[i], GPIO_OUTPUT);
}

etc.

HTH,
Marti


Edge connectors and pin numbers

Frank Duignan
 

I'm working with the BBC Microbit V2 and can use the peripherals using the NRF port pin numbers etc.  These port pins are brought to an edge connector which numbers them completely differently.  There seems to be some support for this in the bbc_microbit_v2 dts file in the following form:
  edge_connector: connector {
compatible = "microbit,edge-connector";
#gpio-cells = <2>;
gpio-map-mask = <0xffffffff 0xffffffc0>;
gpio-map-pass-thru = <0 0x3f>;
gpio-map = <0 0 &gpio0 2 0>, /* P0 */
   <1 0 &gpio0 3 0>, /* P1 */
   <2 0 &gpio0 4 0>, /* P2 */
   <3 0 &gpio0 31 0>, /* P3 */
   <4 0 &gpio0 28 0>, /* P4 */
   <5 0 &gpio0 14 0>, /* P5 */
   <6 0 &gpio1 5 0>, /* P6 */
   <7 0 &gpio0 11 0>, /* P7 */
   <8 0 &gpio0 10 0>, /* P8 */
   <9 0 &gpio0 9 0>, /* P9 */
   <10 0 &gpio0 30 0>, /* P10 */
   <11 0 &gpio0 23 0>, /* P11 */
   <12 0 &gpio0 12 0>, /* P12 */
   <13 0 &gpio0 17 0>, /* P13 */
   <14 0 &gpio0 1 0>, /* P14 */
   <15 0 &gpio0 13 0>, /* P15 */
   <16 0 &gpio1 2 0>, /* P16 */
   <19 0 &gpio0 26 0>, /* P19 */
   <20 0 &gpio1 0 0>; /* P20 */
};
};

My question is: how do I get a binding to one/all of these i/o pins.  I've tried many many combinations of DT_ macros.  The following returns a non null value for "edge" but I can't figure out how to access the pins on that edge connector using the connector pin  numbering scheme.
struct device *edge; edge=DEVICE_DT_GET(DT_NODELABEL(edge_connector));
It's not a show stopper as I can revert to nordic pin numbering but it would be nice if the numbers in the C code corresponded to the label on the board.


Re: Problem running samples/sensor/sht3xd #driver #sensor

Bolivar, Marti
 

Hi again Ilkka,

"ilkka.virtanen via lists.zephyrproject.org"
<ilkka.virtanen=sensoan.com@lists.zephyrproject.org> writes:

Thank you Marti for the reply.

The problem was indeed in the connection between the nRF52840DK and the external sensor. I watched your video, it was very good and informative.
I'm glad; thanks!

As I learned that the device will be initialized before execution is in application code, I realize we will have a problem with the driver in our own product. Our own board will have a sht31 sensor but it is behind a TCA9548A I2C switch, which means a device tree configuration like this:
&i2c0 {
tca9548a@71 ( TCA9548A@71 ) {
sht3xd@44 {
};
};
};

Can I stack the drivers like this?
Yes, you can, you just need to make sure the initialization priorities
are managed correctly so the init functions run in the following order:

i2c0 -> tca9548a -> sht3xd

You can control the initialization priorities with Kconfig options, but
the defaults should be OK for your use case.

See CONFIG_I2C_INIT_PRIORITY and CONFIG_SENSOR_INIT_PRIORITY
respectively for i2c0 and sht3xd.

If yes, to be able to use the available device drivers for the sensors
that are behind the I2C switch, I will need to implement the tca9548a
functionality to a device driver to make this work. Do you know are
there any example to use as a starting point?
I recently reviewed a TCA9546A driver, which seems similar to your
TCA9548A.

https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/i2c/i2c_tca9546a.c

https://docs.zephyrproject.org/latest/reference/devicetree/bindings/i2c/ti%2Ctca9546a.html#dtbinding-ti-tca9546a

If the differences are superficial you may be able to extend the driver
to support "TCA954xA", i.e. both devices.

You may wish to contact the driver author if you want to collaborate.


Thanks again,
Ilkka
HTH,
Marti


Re: Problem running samples/sensor/sht3xd #driver #sensor

@Hidastelija
 

Thank you Marti for the reply.

The problem was indeed in the connection between the nRF52840DK and the external sensor. I watched your video, it was very good and informative.

As I learned that the device will be initialized before execution is in application code, I realize we will have a problem with the driver in our own product. Our own board will have a sht31 sensor but it is behind a TCA9548A I2C switch, which means a device tree configuration like this:
&i2c0 {
  tca9548a@71 {
    sht3xd@44 {
    };
  };
};

Can I stack the drivers like this? If yes, to be able to use the available device drivers for the sensors that are behind the I2C switch, I will need to implement the tca9548a functionality to a device driver to make this work. Do you know are there any example to use as a starting point?

Thanks again,
Ilkka


Re: Problem running samples/sensor/sht3xd #driver #sensor

Bolivar, Marti
 

Hi,

This email list is for upstream zephyr, not NCS, but since the sample is
available in upstream zephyr I will respond here.

"ilkka.virtanen via lists.zephyrproject.org"
<ilkka.virtanen=sensoan.com@lists.zephyrproject.org> writes:

Hi,

I've tried to run the sht3xd sample using nRF52840DK, which is one of the boards with sample configuration overlay file, but all I get out in the logs is this:
*** Booting Zephyr OS build v2.6.0-rc1-ncs1  ***
Could not get SHT3XD device

What I get from this log is that for some reason the system fails to
load the device driver for the sensor.
Be careful here. There is a difference between a device and a device
driver.

The device driver can be compiled into your binary correctly, but the
individual devices can fail to initialize, which is almost definitely
what is happening here.

In general, device_get_binding() returns NULL if the device
initialization function fails, or if there is no such device.


I'm relatively new to Zephyr
and I have trouble understanding how to debug the problem. Can anyone
give me pointers where to look?
Other than the driver model documentation and the driver source code,
I've been plugging my recent device model talk a lot lately:

https://www.youtube.com/watch?v=sWaxQyIgEBY

It may be useful. YMMV :)


I've built the sample using NordicConnectSDK 1.6.1 which uses Zephyr 2.6.0-rc1-ncs1
...NordicConnectSDK/1.6.1/zephyr/samples/sensor/sht3xd$ west build -b
nrf52840dk_nrf52840
Since, as you say, there is a devicetree overlay for the board you are
using here:

https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/sensor/sht3xd/boards/nrf52840dk_nrf52840.overlay

The device structure should be allocated. So I am assuming it just
failed to initialize correctly in your environment. Did you connect the
pins as described in the comments in the overlay file?

Try stepping through sht3xd_init() in your debugger to see where it
fails, or enable more verbose logs in the sensor driver using Kconfig to
see what went wrong.

Hope this helps,
Marti




Thanks.



Initialization and usage of device drivers in user code

akrckn
 

Hello everyone,

I'm pretty new to the Zephyr Project as we (our company) are evaluating it to use it as our base for the upcoming projects.

It didn't take long to get our own application running on our hardware, but a
s we are developing battery powered modules we just activate and use devices when they really are needed.

Is there a way to define devices (e.g. BME280 below) in the device tree file and trigger the initialization and start / stop in the application code and how can we do that?

I'm assuming there is a solution and I didn't get or find it, yet - could you please help me?

&i2c1 {
pinctrl-0 = <&i2c1_scl_pb8 &i2c1_sda_pb9>;
status = "okay";
clock-frequency = <I2C_BITRATE_FAST>;
bme280@77 {
compatible = "bosch,bme280";
status = "okay";
reg = <0x77>;
label = "BME280";
};
};

Thank you in advance and best regards!

101 - 120 of 2784