Date   

Re: Pinmux override

Stefan Jaritz
 

Morning,

As Erwan was telling, IMHO the pinmux variant is a good solution. For example if you doing power saving, you might power down parts of you pcb. Just image the case that you have a peripheral communicating via USART. If it is powered down down you should also configure your stm UART pins, to prevent that you stm is powering the IC via the RX, TX lanes. So you need to do this pinmux stuff not only at boot time.

If you image the board startup as just one use case of pin config, because your firmware will have different ones (like production, self test, operational, error state) you can imagine that the generating a static config via dts is not working in most of the cases. For my stm32f4 platform you can perfectly handle pinconfig with the stm32 pinmux port.

for example:

static void uart3_dma_gpio(bool on) {
   const struct pin_config pin_on[] = {
        {STM32_PIN_PC5, STM32F4_PINMUX_FUNC_PC5_USART3_RX},
        {STM32_PIN_PB10, STM32F4_PINMUX_FUNC_PB10_USART3_TX},
        {STM32_PIN_PB13, (STM32_PINMUX_ALT_FUNC_8 | STM32_PUPDR_NO_PULL | STM32_OSPEEDR_LOW_SPEED)},
        {STM32_PIN_PB14, (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL | STM32_OSPEEDR_LOW_SPEED)},
    };

    const struct pin_config pin_off[] = {
        {STM32_PIN_PC5, STM32_MODER_ANALOG_MODE},
        {STM32_PIN_PB10, STM32_MODER_ANALOG_MODE},
        {STM32_PIN_PB13, (STM32_MODER_ANALOG_MODE)},
        {STM32_PIN_PB14, (STM32_MODER_ANALOG_MODE)},
    };
    if (true == on) {
        stm32_setup_pins(pin_on, ARRAY_SIZE(pin_on));
    } else {
        stm32_setup_pins(pin_off, ARRAY_SIZE(pin_off));
    }
}

Stefan

On 11/01/2020 22:17, Marc Herbert wrote:

On 11 Jan 2020, at 12:52, Vincent - VLoTech via Lists.Zephyrproject.Org <vincent=vlotech.nl@lists.zephyrproject.org> wrote:

Hi all,

Device trees are used during compile time within Zephyr.
But what if you want to support several hardware revisions in the same binary?
(E.g. based on stored hw id or so)
To minimize the amount of binaries to distribute when you need to do an update over one or two years.

How should that be managed within zephyr? As most drivers use the provided DT output...
Looks like https://lists.zephyrproject.org/g/devel/topic/61321118



Re: Pinmux override

Marc Herbert
 

On 11 Jan 2020, at 12:52, Vincent - VLoTech via Lists.Zephyrproject.Org <vincent=vlotech.nl@lists.zephyrproject.org> wrote:

Hi all,

Device trees are used during compile time within Zephyr.
But what if you want to support several hardware revisions in the same binary?
(E.g. based on stored hw id or so)
To minimize the amount of binaries to distribute when you need to do an update over one or two years.

How should that be managed within zephyr? As most drivers use the provided DT output...
Looks like https://lists.zephyrproject.org/g/devel/topic/61321118


Re: Pinmux override

Vincent - VLoTech
 

Hi all,

Device trees are used during compile time within Zephyr. 
But what if you want to support several hardware revisions in the same binary? 
(E.g. based on stored hw id or so)
To minimize the amount of binaries to distribute when you need to do an update over one or two years. 

How should that be managed within zephyr? As most drivers use the provided DT output...

Vincent van der Locht

Op 11 jan. 2020 om 16:35 heeft Erwan Gouriou <erwan.gouriou@...> het volgende geschreven:


Hi Allen,

Pinmuxing is one of the remaining areas where device tree is not in use (except for socs with specific pin management such as nrf).
So we still rely on the c definition for this.

Cheers


Le sam. 11 janv. 2020 à 00:28, Allen Curtis <allen@...> a écrit :
I am obviously showing my ignorance here but I thought Zephyr was using device tree for this stuff. 

On Fri, Jan 10, 2020 at 2:28 AM Erwan Gouriou <erwan.gouriou@...> wrote:
Hi,

Modifying board pinmux.c  (along with boards .dst nd Kconfig.defconfig) is indeed the way to enable the device. It cannot be done otherwise.
Once this is done (and tested ok) you can submit the work  in github so we can get it merged in main zephyr tree.

Cheers
Erwan

On Fri, 10 Jan 2020 at 10:51, Joris Offouga <offougajoris@...> wrote:
Hi all,

I am using the stm32f4_disco board and I am trying to use the i2c ports,
but it is not defined in pinmux.c and I must thzn modify this file to
add the I2C configuration. Is there a better way to do this without
modifying the original file?

Best regards,

Joris



--
Best Regards,

Joris Offouga



--
Allen Curtis
Medical Device Architect
Critical Software Solutions, LLC


RFC: API: Counter: counter_read() has no way of indicating failure

Henrik Brix Andersen
 

Hi all,

Our current counter API has a function for reading the current counter value (counter_read()) which does not allow indicating read failure in a standard way.
I have submitted an RFC for introducing a new API function to resolve this and deprecate counter_read().

See https://github.com/zephyrproject-rtos/zephyr/issues/21846 for further details. Please comment on the RFC issue if you have any input on this.

The counter API is currently marked as an unstable API (see https://github.com/zephyrproject-rtos/zephyr/projects/15).

Best regards,
Brix
--
Henrik Brix Andersen


Re: Pinmux override

Erwan Gouriou
 

Hi Allen,

Pinmuxing is one of the remaining areas where device tree is not in use (except for socs with specific pin management such as nrf).
So we still rely on the c definition for this.

Cheers


Le sam. 11 janv. 2020 à 00:28, Allen Curtis <allen@...> a écrit :
I am obviously showing my ignorance here but I thought Zephyr was using device tree for this stuff. 

On Fri, Jan 10, 2020 at 2:28 AM Erwan Gouriou <erwan.gouriou@...> wrote:
Hi,

Modifying board pinmux.c  (along with boards .dst nd Kconfig.defconfig) is indeed the way to enable the device. It cannot be done otherwise.
Once this is done (and tested ok) you can submit the work  in github so we can get it merged in main zephyr tree.

Cheers
Erwan

On Fri, 10 Jan 2020 at 10:51, Joris Offouga <offougajoris@...> wrote:
Hi all,

I am using the stm32f4_disco board and I am trying to use the i2c ports,
but it is not defined in pinmux.c and I must thzn modify this file to
add the I2C configuration. Is there a better way to do this without
modifying the original file?

Best regards,

Joris



--
Best Regards,

Joris Offouga



--
Allen Curtis
Medical Device Architect
Critical Software Solutions, LLC


Re: Pinmux override

Allen Curtis
 

I am obviously showing my ignorance here but I thought Zephyr was using device tree for this stuff. 

On Fri, Jan 10, 2020 at 2:28 AM Erwan Gouriou <erwan.gouriou@...> wrote:
Hi,

Modifying board pinmux.c  (along with boards .dst nd Kconfig.defconfig) is indeed the way to enable the device. It cannot be done otherwise.
Once this is done (and tested ok) you can submit the work  in github so we can get it merged in main zephyr tree.

Cheers
Erwan

On Fri, 10 Jan 2020 at 10:51, Joris Offouga <offougajoris@...> wrote:
Hi all,

I am using the stm32f4_disco board and I am trying to use the i2c ports,
but it is not defined in pinmux.c and I must thzn modify this file to
add the I2C configuration. Is there a better way to do this without
modifying the original file?

Best regards,

Joris



--
Best Regards,

Joris Offouga



--
Allen Curtis
Medical Device Architect
Critical Software Solutions, LLC


Re: Pinmux override

Erwan Gouriou
 

Hi,

Modifying board pinmux.c  (along with boards .dst nd Kconfig.defconfig) is indeed the way to enable the device. It cannot be done otherwise.
Once this is done (and tested ok) you can submit the work  in github so we can get it merged in main zephyr tree.

Cheers
Erwan


On Fri, 10 Jan 2020 at 10:51, Joris Offouga <offougajoris@...> wrote:
Hi all,

I am using the stm32f4_disco board and I am trying to use the i2c ports,
but it is not defined in pinmux.c and I must thzn modify this file to
add the I2C configuration. Is there a better way to do this without
modifying the original file?

Best regards,

Joris



--
Best Regards,

Joris Offouga




Pinmux override

Joris Offouga
 

Hi all,

I am using the stm32f4_disco board and I am trying to use the i2c ports, but it is not defined in pinmux.c and I must thzn modify this file to add the I2C configuration. Is there a better way to do this without modifying the original file?

Best regards,

Joris



--
Best Regards,

Joris Offouga


Upcoming Event: Zephyr Project: Dev Meeting - Thu, 01/09/2020 8:00am-9:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 9 January 2020, 8:00am to 9:00am, (GMT-08:00) America/Los Angeles

Where:https://zoom.us/j/993312203

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf


Dev-Review Meeting Agenda (Jan 9)

Kumar Gala
 

Here’s the agenda topics for this week:

* drivers: allow to retrieve device structure by the name prefix:
[ https://github.com/zephyrproject-rtos/zephyr/pull/21709 ]
* dt topics

If there’s anything else to add please let me know.

Thanks

- k


Re: [MQTT/SARAR4] Issue during MQTT publish

Guillaume Paquet
 

Hi Jukka,

 

Thanks for your answer.

I created issue here

https://github.com/zephyrproject-rtos/zephyr/issues/21764

 

I don’t assign it.

 

Rgds,

 

Guillaume

 

De : Jukka Rissanen <jukka.rissanen@...>
Envoyé : mercredi 8 janvier 2020 14:13
À : Guillaume Paquet <guillaume.paquet@...>; William.fish@...; devel@...
Objet : Re: [Zephyr-devel] [MQTT/SARAR4] Issue during MQTT publish

 

Hi Guillaume,

 

it sounds like sara modem driver has a regression. Could you create a bug report for this at

 

 

On Wed, 2020-01-08 at 12:43 +0000, Guillaume Paquet wrote:

Hello William,

 

Thanks for your feedback.

Yes please find below output in my console:

 

 

For your information, I achieved to make it works with previous revision of SARA R4 driver.
It does not work after the following commit : https://github.com/zephyrproject-rtos/zephyr/commit/ebf6520d8713aae9809eb1ef6bee7211cf9b4caa#diff-cb3c7d77935fa5df6ccb74a1c5e050ba

 

 

Can you please let me know if SARA R4 is tested on MQTT or just on LWM2M example ? (I did not try this last one because I have not any LWM2M server available).

 

I suspect that only LWM2M example was used for testing sara-r4 modem.

 

 

Cheers,

Jukka

 


Re: [MQTT/SARAR4] Issue during MQTT publish

Jukka Rissanen
 

Hi Guillaume,

it sounds like sara modem driver has a regression. Could you create a bug report for this at


On Wed, 2020-01-08 at 12:43 +0000, Guillaume Paquet wrote:

Hello William,

 

Thanks for your feedback.

Yes please find below output in my console:

 

 

For your information, I achieved to make it works with previous revision of SARA R4 driver.
It does not work after the following commit : https://github.com/zephyrproject-rtos/zephyr/commit/ebf6520d8713aae9809eb1ef6bee7211cf9b4caa#diff-cb3c7d77935fa5df6ccb74a1c5e050ba

 

 

Can you please let me know if SARA R4 is tested on MQTT or just on LWM2M example ? (I did not try this last one because I have not any LWM2M server available).


I suspect that only LWM2M example was used for testing sara-r4 modem.


Cheers,
Jukka


Re: [MQTT/SARAR4] Issue during MQTT publish

Guillaume Paquet
 

Hello William,

 

Thanks for your feedback.

Yes please find below output in my console:

 

SEGGER J-Link V6.48 - Real time terminal output

J-Link OB-SAM3U128-V2-NordicSemi compiled Jan  7 2019 14:07:15 V1.0, SN=682005484

Process: JLinkExe

[00:00:00.677,947] <inf> modem_ublox_sara_r4: Setting Modem Pins

[00:00:10.878,143] <inf> modem_ublox_sara_r4: ... Done!

[00:00:10.878,173] <inf> modem_ublox_sara_r4: Waiting for modem to respond

[00:00:25.453,521] <inf> modem_ublox_sara_r4: Manufacturer: AT+CGMI

[00:00:25.454,284] <inf> modem_ublox_sara_r4: Manufacturer: u-blox

[00:00:25.510,009] <inf> modem_ublox_sara_r4: Model: AT+CGMM

[00:00:25.511,474] <inf> modem_ublox_sara_r4: Model: SARA-R412M-02B

[00:00:25.567,169] <inf> modem_ublox_sara_r4: Revision: <log_strdup alloc failed>

[00:00:25.570,129] <inf> modem_ublox_sara_r4: Revision: <log_strdup alloc failed>

[00:00:25.625,823] <inf> modem_ublox_sara_r4: IMEI: <log_strdup alloc failed>

[00:00:25.627,380] <inf> modem_ublox_sara_r4: IMEI: <log_strdup alloc failed>

[00:00:25.776,062] <inf> modem_ublox_sara_r4: Waiting for network

[00:00:27.782,928] <inf> modem_ublox_sara_r4: RSRP: -1000

[00:00:29.790,222] <inf> modem_ublox_sara_r4: RSRP: -1000

[00:00:31.797,546] <inf> modem_ublox_sara_r4: RSRP: -88

[00:00:33.798,065] <inf> modem_ublox_sara_r4: Network is ready.

[00:00:33.798,248] <err> modem_ublox_sara_r4: NET_SOCKET_OFFLOAD must be configured for this driver

[00:00:33.798,248] <wrn> net_dns_resolve: Cannot initialize DNS resolver (-134)

***** Booting Zephyr OS build zephyr-v2.0.0-41-g94019097bb8c *****

[00:00:34.842,803] <inf> net_config: Initializing network

[00:00:34.842,864] <inf> net_config: IPv4 address: 83.166.154.87

attempting to connect: socket_id:0 left_bytes:4 err: 4

MQTT connect failed -111

socket_id:1 left_bytes:4 err: 4

 

I can see that Network connection is ok MQTT server is not reachable.

 

For your information, I achieved to make it works with previous revision of SARA R4 driver.
It does not work after the following commit : https://github.com/zephyrproject-rtos/zephyr/commit/ebf6520d8713aae9809eb1ef6bee7211cf9b4caa#diff-cb3c7d77935fa5df6ccb74a1c5e050ba

 

I also made some debug on UART bus and I saw something strange on +UUSORD unsolicited answer management

 

 

This section is working

AT+USOCR=6,47069

+USOCR: 1

OK

 

AT+USOCO=1,"83.166.154.87",1883

OK

 

AT+USOWR=1,30

@

+USOWR: 1,30

OK

+UUSORD: 1,4

 

AT+USORD=1,4

+USORD: 1,4,"20020000"

OK

 

AT+USOWR=1,2

@

+USOWR: 1,2

OK

+UUSORD: 1,2

AT+USORD=1,2

+USORD: 1,2,"D000"

OK

 

….

 

 

This section is not working and we can see that +UUSORD does not come at the good moment.

AT+USOCR=6

+USOCR: 0

 

OK

AT+USOCO=0,"83.166.154.87",1883

OK

AT+USOWR=0,30

@

+USOWR: 0,30

 

OK

AT+USOWR=0,30

@

+USOWR: 0,30

 

OK

AT+USOWR=0,30

@

+USOWR: 0,30

 

OK

 

+UUSORD: 0,4

AT+USOWR=0,30

@

+CME ERROR: 3

 

 

Can you please let me know if SARA R4 is tested on MQTT or just on LWM2M example ? (I did not try this last one because I have not any LWM2M server available).

 

I hope my mail is clear enough (I know it is a bit long 😊)

 

Really thanks for your help

 

Rgds

 

Guillaume

 

De : devel@... <devel@...> De la part de William Fish via Lists.Zephyrproject.Org
Envoyé : mercredi 8 janvier 2020 12:06
À : devel@...
Cc : devel@...
Objet : Re: [Zephyr-devel] [MQTT/SARAR4] Issue during MQTT publish

 

Hi Guillaume,
Do you have the debug output showing

  • The R4 connection to network?
  • Connection to MQTT server?

At first glance it appears that you aren't connected (Err 111: Connection refused).

This could be caused by a number of things. You may find that there have been some configuration changes in the SARA driver which could be effecting your connection.

Billy..


Re: [MQTT/SARAR4] Issue during MQTT publish

William Fish
 

Hi Guillaume,
Do you have the debug output showing
  • The R4 connection to network?
  • Connection to MQTT server?
At first glance it appears that you aren't connected (Err 111: Connection refused).

This could be caused by a number of things. You may find that there have been some configuration changes in the SARA driver which could be effecting your connection.

Billy..


Upcoming Event: Zephyr Project: APIs - Tue, 01/07/2020 9:00am-10:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 7 January 2020, 9:00am to 10:00am, (GMT-08:00) America/Los Angeles

Where:https://zoom.us/j/177647878

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY


 Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing


[MQTT/SARAR4] Issue during MQTT publish

Guillaume Paquet
 

Hello Zephyr Community,

 

I am trying to use example in samples/net/mqtt_publisher.

I am on zephyr 2.0 release and I use SARA R4 driver to try this example.

I just changed prj.conf to use MQTT (not secured) on my own mosquito broker (on infomaniak server).

 

I don’t achieve to connect to MQTT broker and I always have following error message:

MQTT connect failed -111

 

Moreover, I tried to see what is send to SARA-R4 module (and what is its answer).

 

I can see that it loops several times on same command whereas command is ok and well understood by my SARA R4 module

AT+USOWR=0,30

@

101c00044d5154540402003c00107a65706879725f7075626c6973686572

+USOWR: 0,30

 

OK

 

Do you have any idea on what can happen ?

For your information, it works when I use zephyr 1.14.1 with 1st SARA R4 driver revision.

 

Thanks in advance for your help

 

Don’t hesitate if you need more information

 

Rgds,

 

Guillaume

   www.stimio.fr

Guillaume  PAQUET – IoT Engineer

guillaume.paquet@...  -  02 40 18 50 91

1 Avenue Professeur Jean Rouxel – ZAC Fleuriaye

44470 CARQUEFOU – FRANCE                

 


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: shell doesn't accept input – Arduino Due

Adam Feuer <adam@...>
 

I can output characters on the UART0 just fine using printk(). The shell also seems to be able to do output since I see a prompt. I know I can build working software since I built a posix version of the shell examples and they work.

When I send a character to the Arduino Due using Picocom, the UART0 interrupt fires. But when I try to read from the UART0 UART_RHR, I get zero. And if I check the uart->UART_SR, it shows UART_SR_FRAME – a framing error.

The Arduino Due board can read characters just fine from the Arduino software, if I flash an Arduino sketch; or from NuttX RTOS if I build that and flash it onto the board. So the hardware is good. It seems to be something related to how Zephyr configures the board. I've been reading the uart init code and board init code to see what's wrong with it, but can't find a problem.

I have a Segger J-Link debugger and cable I can use with the Arduino Due, but not sure what to look for.

If anyone has ideas on how to debug this, I would love to know them!.

cheers
adam


On Sat, Jan 4, 2020 at 10:38 PM Adam Feuer <adam@...> wrote:
Hi,

Zephyr newbie here. I am trying to get a shell running on the Arduino Due. I can compile and flash samples/subsys/shell/shell_module on my Arduino Due. I am using Ubuntu Linux.

Connected to the Due's Programming Port using picocom, I can see output and the shell prompt. However, when I try to type something, the shell appears hung– it doesn't accept any input. It appears the UART is not accepting input.

Is this sample known to work on the Arduino Due?

I tried to do some printk() debugging– the Arduino seems to know it's getting characters, but the actual character is not supplied to the shell...

Does anyone have any ideas on how to get this working?

cheers
adam
--
Adam Feuer <adam@...>


--
Adam Feuer <adam@...>


shell doesn't accept input – Arduino Due

adam@...
 

Hi,

Zephyr newbie here. I am trying to get a shell running on the Arduino Due. I can compile and flash samples/subsys/shell/shell_module on my Arduino Due. I am using Ubuntu Linux.

Connected to the Due's Programming Port using picocom, I can see output and the shell prompt. However, when I try to type something, the shell appears hung– it doesn't accept any input. It appears the UART is not accepting input.

Is this sample known to work on the Arduino Due?

I tried to do some printk() debugging– the Arduino seems to know it's getting characters, but the actual character is not supplied to the shell...

Does anyone have any ideas on how to get this working?

cheers
adam
--
Adam Feuer <adam@...>


Sensor Driver - Synchronous calls to sensor_sample_fetch() and sensor_channel_get()

Lawrence King
 

Dear All:

 

I have finally gotten around to writing a driver for the lsm9ds1 sensor. Boy have I learned a lot about the core of the Zephyr kernel and sensor sub-system, and in general I really like it.

 

As I look through the sensor driver examples, both the drivers, and the sample user land code I see a pattern. Sensors can be used asynchronously (no interrupts) or synchronously (with interrupts indicating when data or other info is available). In this email I will only discuss Synchronous (with interrupts) challenges.

 

The lsm9ds1 chip has (up to) 4 interrupt pins, two are typically used as data ready interrupts, and two are usually used to signal other conditions (such as buffer overflow, or acceleration exceeding a pre-programmed threshold, i.e. a collision), but they could also be used to indicate data rady. Each one of these 4 pins need to be configured and each one can generate interrupts for multiple reasons. Some of the reasons can be signaled on either of the interrupt and data ready pins, or both. All of the possible configurations are mind boggling. Some configuration information can be described in the device tree (specifically which of the interrupt pins are connected to the processor, as well as which bus the device is attached to). The rest of the config information can be described in the Kconfig. Just to add to the challenge there is also a data enable output from the processor back to the sensor (total 5 gpios in addition to the SPI or I2C bus).

 

 

In general when an interrupt comes in from the device the call back in user land calls sensor_sample_fetch() and then may also call sensor_channel_get(). sensor_sample_fetch() transfers the raw data over the interconnect (i2c or spi) to storage in the driver, and then sensor_channel_get() converts the data stored in the driver storage from raw sensor values to engineering units and passes the sensor data back to the user program.

 

My question is about the need for the user to call sensor_sample_fetch() in the interrupt handler callback.

 

On one hand I can see that the bus traffic *could* be reduced if the user decides that he doesn’t really need the data at this time (although I didn’t find any sample code where sensor_sample_fetch() was not called in the user callback interrupt handler). On the other hand, in every case I looked at, sensor_sample_fetch() *MUST* be called to clear the interrupt.

 

It seems to me that if a driver has an interrupt handler, the driver should be responsible for calling sensor_sample_fetch() which then collects the data into driver storage, and more importantly, clears the interrupt. Having the user program responsible for calling sensor_sample_fetch() creates the possibility of the user hanging Zephyr completely (because the interrupt was not cleared), and is a unnecessary level of indirection. [I only know this because I managed to hang Zephyr while I was developing the driver]

 

Who should I discuss this kernel design decision with? I know how it is currently done, and I can work with this, but is this the right way to do it?

 

 

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.

 

 

 

1421 - 1440 of 8046