Date   

Re: Reading Values From not supported sensors

Marti Bolivar <marti.bolivar@...>
 

Hi Kevin,

Temperature sensor support is working in Zephyr. You can search the samples/ directory for the string "SENSOR_CHAN_TEMP" to find example code which reads temperature sensors:

https://github.com/zephyrproject-rtos/zephyr/search?q=SENSOR_CHAN_TEMP&type=

Hope this helps,
Marti


On 16 May 2017 at 07:25, Kevin Stöckl <k_stoeckl@...> wrote:

Hello,

is it possible to read values from not supported sensors, like temperature senors. And how is this possible.


Thanks, Kevin


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



Reading Values From not supported sensors

Kevin Stöckl <k_stoeckl@...>
 

Hello,

is it possible to read values from not supported sensors, like temperature senors. And how is this possible.


Thanks, Kevin


Re: STM32F4: Correct translation from native to LL clock driver

Daniel Thompson <daniel.thompson@...>
 

On 15/05/17 10:19, Erwan Gouriou wrote:
Hi Daniel,
I think I spotted the bug, which is indeed in the commit you pointed.
It appears with current code (stm32_clock_control_on), you can't activate AHB2 clock on F4.
I've pushed following commit to solve the case:
https://github.com/zephyrproject-rtos/zephyr/pull/182
Please have a look and tell me if it solves the issue
I took a quick look at this. It didn't "just work" for me but I am pretty short of time today and a couple of other things didn't "just work" either (and they should have done).

I will get back to you as soon as I can!


Daniel.



On 13 May 2017 at 12:16, Daniel Thompson <daniel.thompson@... <mailto:daniel.thompson@...>> wrote:
Hi Erwan
I've taken another look at Christer Weinigel's patched for USB on
STM32F4 recently.
I'm having a problem with the new LL clock code.
I applied the following patch to Christer's work in order to bring
it up to date w.r.t. the LL clock driver:
diff --git a/drivers/usb/device/usb_dc_stm.c
b/drivers/usb/device/usb_dc_stm.c
index 070e6766bf67..49f7dbffd5c3 100644
--- a/drivers/usb/device/usb_dc_stm.c
+++ b/drivers/usb/device/usb_dc_stm.c
@@ -149,9 +149,9 @@ static void usb_dc_stm_isr(void *arg)
static int usb_dc_stm_clock_enable(void)
{
struct device *clk =
device_get_binding(STM32_CLOCK_CONTROL_NAME);
- struct stm32f4x_pclken pclken = {
- .bus = STM32F4X_CLOCK_BUS_AHB2,
- .enr = STM32F4X_CLOCK_ENABLE_OTGFS,
+ struct stm32_pclken pclken = {
+ .bus = STM32_CLOCK_BUS_AHB2,
+ .enr = LL_AHB2_GRP1_PERIPH_OTGFS,
};
clock_control_on(clk, (clock_control_subsys_t *)&pclken);
Unfortunately this change is not enough to get the USB code to work.
Have I done the translation correctly?
I think the problem is one of enable rather than USB clock rate
(there is no attempt to hotplug... if the USB clock rate were wrong
hotplug detect would work but there would be no comms).
Finally, just to double check my assumptions about, I did do a
bisect to try and chase thise problem down. bisect took me straight
to 80b7bec ("soc: stm32f4: Enable LL based clock control") so I know
this is strictly related to the clock driver change rather than any
other zephyr changes.
Can you offer any clues?
Daniel.


BSD Sockets like API: prototyping report #4

Paul Sokolovsky
 

Hello,

Given that initial prototyping was complete and issues were identified
and at least workarounds exist, I started process of refactoring the
code into the in-tree subsystem:
https://github.com/zephyrproject-rtos/zephyr/pull/153 . This is not
targeted for 1.8, but rather for 1.9 window, so feel free to skip for
now if you're busy with 1.8 release work.

I also posted instructions to build the prototype version in the
MicroPython codebase:
https://github.com/pfalcon/micropython/wiki/ZephyrSocket

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: STM32F4: Correct translation from native to LL clock driver

Erwan Gouriou
 

Hi Daniel,

I think I spotted the bug, which is indeed in the commit you pointed.
It appears with current code (stm32_clock_control_on), you can't activate AHB2 clock on F4.

I've pushed following commit to solve the case:
https://github.com/zephyrproject-rtos/zephyr/pull/182

Please have a look and tell me if it solves the issue

Erwan


On 13 May 2017 at 12:16, Daniel Thompson <daniel.thompson@...> wrote:
Hi Erwan

I've taken another look at Christer Weinigel's patched for USB on STM32F4 recently.

I'm having a problem with the new LL clock code.

I applied the following patch to Christer's work in order to bring it up to date w.r.t. the LL clock driver:

diff --git a/drivers/usb/device/usb_dc_stm.c b/drivers/usb/device/usb_dc_stm.c
index 070e6766bf67..49f7dbffd5c3 100644
--- a/drivers/usb/device/usb_dc_stm.c
+++ b/drivers/usb/device/usb_dc_stm.c
@@ -149,9 +149,9 @@ static void usb_dc_stm_isr(void *arg)
 static int usb_dc_stm_clock_enable(void)
 {
        struct device *clk = device_get_binding(STM32_CLOCK_CONTROL_NAME);
-       struct stm32f4x_pclken pclken = {
-               .bus = STM32F4X_CLOCK_BUS_AHB2,
-               .enr = STM32F4X_CLOCK_ENABLE_OTGFS,
+       struct stm32_pclken pclken = {
+               .bus = STM32_CLOCK_BUS_AHB2,
+               .enr = LL_AHB2_GRP1_PERIPH_OTGFS,
        };

        clock_control_on(clk, (clock_control_subsys_t *)&pclken);

Unfortunately this change is not enough to get the USB code to work. Have I done the translation correctly?

I think the problem is one of enable rather than USB clock rate (there is no attempt to hotplug... if the USB clock rate were wrong hotplug detect would work but there would be no comms).

Finally, just to double check my assumptions about, I did do a bisect to try and chase thise problem down. bisect took me straight to 80b7bec ("soc: stm32f4: Enable LL based clock control") so I know this is strictly related to the clock driver change rather than any other zephyr changes.

Can you offer any clues?


Daniel.


Re: Porting Zephyr to STM32F103C8T6 Minimum System Development Board

Erwan Gouriou
 

Hello Siddharth,

It seems your porting miss the pinmux configuration driver file, cf:
drivers/pinmux/stm32/pinmux_board_nucleo_f103rb.c

Then, you'll have to create a new CONFIG value "SOC_STM32F103X8". We need to identify stm32 SoC variants with the last letter in order to keep the Flash size information.
You'll use this value to fill flash/ram in in dts/arm/st/mem.h (please rebase if you don't see it).

Regarding upstream; yes, we'll be please to have this board supported!

Erwan




On 14 May 2017 at 23:20, Siddharth Chandrasekaran <siddharth@...> wrote:
Hello,

I am trying to port Zephyr into one of the cheap, breadboard friendly, "STM32F103C8T6 Minimum System Development Boards" (link not attached due to overwhelming results in Google) and I am facing some difficulty.

So far, with the other ported boards as a reference, I was able to setup a new board and get the blinky sample application to work. However, I am unable to get console logs to show up in UART_1 as expected. I have tried the hello_world and shell applications without much luck.

Digging a little deeper, I realised that the SOC support had STM32103XB and there isn't a STM32103X8 or a STM32103XX. Now I am beginning now wondering if there is a reason why the SOC was called STM32103XB and not STM32103XX, as the data sheet for the two of them is unified. I also verified that the peripheral register address map for UART 1 is in fact at the the same location as in the STM32103XB, which means at least UART 1 should work even if the SOCs aren't compatible.

Here is a patch to my work so far http://embedjournal.com/board_stm32_min_dev.patch. Do let me know If I am missing something. Also, is this a hardware that the upstream will be interested in? It's a pretty popular design although there are slight incistencies. I can raise a PR after successful validation if it means anything.

Thanks,
Sid.

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



Representing Sensor Values with Arduino DUE

Kevin Stöckl <k_stoeckl@...>
 

Hello,


I want to represent my sensor values which are collected with the Arduino DUE in the web over WiFi. For Example in thingsboard.io.
How is it possible to realize this?

Thanks in Advance

Kevin


Porting Zephyr to STM32F103C8T6 Minimum System Development Board

Siddharth Chandrasekaran <siddharth@...>
 

Hello,

I am trying to port Zephyr into one of the cheap, breadboard friendly, "STM32F103C8T6 Minimum System Development Boards" (link not attached due to overwhelming results in Google) and I am facing some difficulty.

So far, with the other ported boards as a reference, I was able to setup a new board and get the blinky sample application to work. However, I am unable to get console logs to show up in UART_1 as expected. I have tried the hello_world and shell applications without much luck.

Digging a little deeper, I realised that the SOC support had STM32103XB and there isn't a STM32103X8 or a STM32103XX. Now I am beginning now wondering if there is a reason why the SOC was called STM32103XB and not STM32103XX, as the data sheet for the two of them is unified. I also verified that the peripheral register address map for UART 1 is in fact at the the same location as in the STM32103XB, which means at least UART 1 should work even if the SOCs aren't compatible.

Here is a patch to my work so far http://embedjournal.com/board_stm32_min_dev.patch. Do let me know If I am missing something. Also, is this a hardware that the upstream will be interested in? It's a pretty popular design although there are slight incistencies. I can raise a PR after successful validation if it means anything.

Thanks,
Sid.


1.8 Merge window

Nashif, Anas
 

Hi,

Due to the late release of Zephyr  v1.7 and the infrastructure move to github, the TSC has decided to extend the merge window until May 19th. All major changes and feature submissions have to be submitted and reviewed by end of next week.

 

Once we tag RC1 we will only be accepting bug fixes, documentation and stabilization related changes. Please make sure you have submitted all changes and features ASAP to make it into the 1.8 release.

 

Thanks,

Anas

 


STM32F4: Correct translation from native to LL clock driver

Daniel Thompson <daniel.thompson@...>
 

Hi Erwan

I've taken another look at Christer Weinigel's patched for USB on STM32F4 recently.

I'm having a problem with the new LL clock code.

I applied the following patch to Christer's work in order to bring it up to date w.r.t. the LL clock driver:

diff --git a/drivers/usb/device/usb_dc_stm.c b/drivers/usb/device/usb_dc_stm.c
index 070e6766bf67..49f7dbffd5c3 100644
--- a/drivers/usb/device/usb_dc_stm.c
+++ b/drivers/usb/device/usb_dc_stm.c
@@ -149,9 +149,9 @@ static void usb_dc_stm_isr(void *arg)
static int usb_dc_stm_clock_enable(void)
{
struct device *clk = device_get_binding(STM32_CLOCK_CONTROL_NAME);
- struct stm32f4x_pclken pclken = {
- .bus = STM32F4X_CLOCK_BUS_AHB2,
- .enr = STM32F4X_CLOCK_ENABLE_OTGFS,
+ struct stm32_pclken pclken = {
+ .bus = STM32_CLOCK_BUS_AHB2,
+ .enr = LL_AHB2_GRP1_PERIPH_OTGFS,
};

clock_control_on(clk, (clock_control_subsys_t *)&pclken);

Unfortunately this change is not enough to get the USB code to work. Have I done the translation correctly?

I think the problem is one of enable rather than USB clock rate (there is no attempt to hotplug... if the USB clock rate were wrong hotplug detect would work but there would be no comms).

Finally, just to double check my assumptions about, I did do a bisect to try and chase thise problem down. bisect took me straight to 80b7bec ("soc: stm32f4: Enable LL based clock control") so I know this is strictly related to the clock driver change rather than any other zephyr changes.

Can you offer any clues?


Daniel.


Re: [RFC] Touchscreen driver API

Jon Medhurst (Tixy) <tixy@...>
 

On Tue, 2017-05-09 at 13:54 +0200, Tomasz Bursztyka wrote:
I don't know much about touchscreens myself but as a sensor, because it
basically is one,
is there any reason why you specifically did not make this with sensor API?

Some of the existing attributes and functions there seem really meant
for such usage.

If things are missing in sensor API, wouldn't it be worth improving that
API then?
So the sensor API (like most things in Zephyr) doesn't specify much in
the way dynamic behaviour, or implementation or usage constraints.
Specifically in this case, how often trigger handlers get called and
there interaction with calls to channel_get and sample_fetch.

So, for my driver, I've implementation so that the first call to
channel_get after a sample_fetch triggers a work item to enabled the
trigger callback for the next sample. Which means for suitably written
client code, we can guarantee to a) see all sample events and b) not
hang waiting for a callback.

This doesn't really help other people writing touchscreen drivers or
other users of my driver, as they won't know the usage semantics. But at
least my driver now uses an official Zephyr API, with the following
modification...

--- a/include/sensor.h
+++ b/include/sensor.h
@@ -110,6 +110,12 @@ enum sensor_channel {
        SENSOR_CHAN_GREEN,
        /** Altitude, in meters */
        SENSOR_CHAN_ALTITUDE,
+       /**
+        * Touchscreen X,Y and Z (pressure) samples, in device specific units.
+        * Higher pressure is lower Z values and the maximum Z integer value
+        * (0x7fffffff) indicates that the screen isn't being touched.
+        */
+       SENSOR_CHAN_TOUCHSCREEN_XYZ,
        /** All channels. */
        SENSOR_CHAN_ALL,
 };

--
Tixy


Re: I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Chuck Jordan <Chuck.Jordan@...>
 

Be sure to also get the data sheet for the device attached to SPI or I2C.
There are configurable options you must do correctly to communicate properly to the device on the other side.

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Bogdan Davidoaia
Sent: Thursday, May 11, 2017 1:00 AM
To: Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Hello,

Although they are not specific to ARC, you can look over most of the sensor drivers (in drivers/sensor/) for use of I2C and SPI.

Use of the I2C/SPI API is the same regardless of the platform, so it should be an ok starting point.

Regards,
Bogdan



On 11 May 2017 at 08:12, Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...> wrote:


Hi Team



Do you have any sample/example of Using I2C or SPI driver of ARC (
sensor
subsystem) in Quark_se ?



Thanks






_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.zephyrproje
ct.org_mailman_listinfo_zephyr-2Ddevel&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0
tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=nirrrHvTYPm_ezoRVKS
QRHEVyJyfsiT6yrNJC04V0C0&s=rW_84jfRfJ5BSA2GSTM_0-tJAVqNHs73iLJNKcJ0FtI
&e=
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.zephyrproject.org_mailman_listinfo_zephyr-2Ddevel&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=nirrrHvTYPm_ezoRVKSQRHEVyJyfsiT6yrNJC04V0C0&s=rW_84jfRfJ5BSA2GSTM_0-tJAVqNHs73iLJNKcJ0FtI&e=


Re: I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Dinh, Kien T
 

Have you looked at the gpio sample under samples/drivers/gpio?

 

It’s just “GPIO_0”, and it depends whether the app is built for ARC or x86.

For x86, it can be built with:

$ make BOARD=arduino_101

And for ARC, it can be built with

$ make BOARD=arduino_101_sss

 

Regards,

Kien

 

From: "Mahendravarman Rajarao (RBEI/EAA10)" <Mahendravarman.Rajarao@...>
Date: Thursday, May 11, 2017 18:35
To: Kien Dinh <kien.t.dinh@...>, "users@..." <users@...>, "devel@..." <devel@...>
Cc: Bogdan Davidoaia <bogdan.davidoaia@...>
Subject: RE: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

 

Hi

 

Iam using zephyr 1.6.0 downloaded from the site

 

If I need to toggle a simple GPIO on the Sensor subsystem, In the Kconfig file of the ARC

Config options given are GPIO_QMSI , GPIO_QMSI_SS & GPIO_QMSI_SS_0_NAME (default name is GPIO_SS_0)

 

So In device binding we need to give as device_get_binding(“GPIO_SS_0”);

If I give as device_get_binding(“GPIO_0”); then x86 gpio is toggling.

 

Can you confirm this ?

 

 

Do you have any example of gpio with sensor subsystem ?

 

 

 

Thanks


From: Dinh, Kien T [mailto:kien.t.dinh@...]
Sent: Thursday, May 11, 2017 2:41 PM
To: Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...>; users@...; devel@...
Subject: Re: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

 

Hi Mahendravarman,

 

You might try to look at the samples folder in the repository. The below examples are using I2C and SPI on ARC:

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/drivers/current_sensing

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/environmental_sensing

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/sensor/bme280

 

Regards,

Kien

 

 

From: <zephyr-devel-bounces@...> on behalf of "Mahendravarman Rajarao (RBEI/EAA10)" <Mahendravarman.Rajarao@...>
Date: Thursday, May 11, 2017 14:12
To: "
users@..." <users@...>, "devel@..." <devel@...>
Subject: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

 

 

Hi Team

 

Do you have any sample/example of Using I2C or SPI driver of ARC ( sensor subsystem) in Quark_se ?

 

Thanks

 

 


Re: I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...>
 

Hi

 

Iam using zephyr 1.6.0 downloaded from the site

 

If I need to toggle a simple GPIO on the Sensor subsystem, In the Kconfig file of the ARC

Config options given are GPIO_QMSI , GPIO_QMSI_SS & GPIO_QMSI_SS_0_NAME (default name is GPIO_SS_0)

 

So In device binding we need to give as device_get_binding(“GPIO_SS_0”);

If I give as device_get_binding(“GPIO_0”); then x86 gpio is toggling.

 

Can you confirm this ?

 

 

Do you have any example of gpio with sensor subsystem ?

 

 

 

Thanks

From: Dinh, Kien T [mailto:kien.t.dinh@...]
Sent: Thursday, May 11, 2017 2:41 PM
To: Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...>; users@...; devel@...
Subject: Re: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

 

Hi Mahendravarman,

 

You might try to look at the samples folder in the repository. The below examples are using I2C and SPI on ARC:

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/drivers/current_sensing

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/environmental_sensing

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/sensor/bme280

 

Regards,

Kien

 

 

From: <zephyr-devel-bounces@...> on behalf of "Mahendravarman Rajarao (RBEI/EAA10)" <Mahendravarman.Rajarao@...>
Date: Thursday, May 11, 2017 14:12
To: "
users@..." <users@...>, "devel@..." <devel@...>
Subject: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

 

 

Hi Team

 

Do you have any sample/example of Using I2C or SPI driver of ARC ( sensor subsystem) in Quark_se ?

 

Thanks

 

 


Re: I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Dinh, Kien T
 

Hi Mahendravarman,

 

You might try to look at the samples folder in the repository. The below examples are using I2C and SPI on ARC:

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/drivers/current_sensing

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/environmental_sensing

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/sensor/bme280

 

Regards,

Kien

 

 

From: <zephyr-devel-bounces@...> on behalf of "Mahendravarman Rajarao (RBEI/EAA10)" <Mahendravarman.Rajarao@...>
Date: Thursday, May 11, 2017 14:12
To: "users@..." <users@...>, "devel@..." <devel@...>
Subject: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

 

 

Hi Team

 

Do you have any sample/example of Using I2C or SPI driver of ARC ( sensor subsystem) in Quark_se ?

 

Thanks

 

 


Re: I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Bogdan Davidoaia
 

Hello,

Although they are not specific to ARC, you can look over most of the
sensor drivers (in drivers/sensor/) for use of I2C and SPI.

Use of the I2C/SPI API is the same regardless of the platform, so it
should be an ok starting point.

Regards,
Bogdan



On 11 May 2017 at 08:12, Mahendravarman Rajarao (RBEI/EAA10)
<Mahendravarman.Rajarao@...> wrote:


Hi Team



Do you have any sample/example of Using I2C or SPI driver of ARC ( sensor
subsystem) in Quark_se ?



Thanks






_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...>
 

 

Hi Team

 

Do you have any sample/example of Using I2C or SPI driver of ARC ( sensor subsystem) in Quark_se ?

 

Thanks

 

 


Re: nrf52 PWM and ADC support

Carles Cufi
 

Hi Steve,

 

We do have a plan to provide drivers for most of the nRF5x peripherals by reusing parts of the code that already exists in the standard Nordic SDK. The work has already started and I hope to start submitting the first PRs during the month of June.

For the 2 peripherals you mention however there happens to be drafts that were submitted to gerrit but we couldn’t get them merged in in time for the transition to GitHub:

 

https://gerrit.zephyrproject.org/r/#/c/10475/

https://gerrit.zephyrproject.org/r/#/c/11338/

 

If you are in a hurry and want to use those as a starting point for your project or want to submit them to GitHub as PRs we will review them.

 

Regards,

 

Carles

 

From: <zephyr-devel-bounces@...> on behalf of Steve Reed <steve@...>
Date: Wednesday, 10 May 2017 at 23:59
To: "zephyr-devel@..." <zephyr-devel@...>
Subject: [Zephyr-devel] nrf52 PWM and ADC support

 

Hi folks, 

I’m sorry if this gets asked a lot but I’m looking for info on the timeline for supporting nrf52 HW PWM and ADC.  I’ve started migrating a project over but thats going to be a roadblock soon.


nrf52 PWM and ADC support

Steve Reed <steve@...>
 

Hi folks, 
I’m sorry if this gets asked a lot but I’m looking for info on the timeline for supporting nrf52 HW PWM and ADC.  I’ve started migrating a project over but thats going to be a roadblock soon.


I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...>
 

Hi Team

 

Do you have any sample/example of Using I2C or SPI driver of ARC ( sensor subsystem) in Quark_se ?

 

Thanks

 

 

5781 - 5800 of 8700