Date   

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

 

 


Re: Help required on reading UART device and print on console

Erwan Gouriou
 

To answer your initial question, below example should work
 
   struct device *uartGPS;
   uartGPS = device_get_binding(CONFIG_UART_STM32_PORT_1_NAME);

    while (1) {
        unsigned char recvChar;
        while (uart_poll_in(uartGPS, &recvChar) < 0)
            ;
        printk("%c", recvChar);
    }

Besides, for the device tree issue, please see my answer in https://jira.zephyrproject.org/browse/ZEP-2125
Patch is provided, we'll see if we upstream it.

Erwan


On 9 May 2017 at 15:30, Erwan Gouriou <erwan.gouriou@...> wrote:
Hi Dhamu,

I saw the task you entered in Jira afterwards and now better understand your question.
Indeed, you might need additional settings to get these ports working:
One point is that you should activate them in dts files and nucleo_l476rg_defconfig.
Also, please check that GPIO ports are activated according to your pinmuxing.
I'll have a check and get back to you.

A sample test was present some time ago, but it has been moved to tests section and now is more adapted to extensive testing rather than simple (re-)use.
Re-instanciating a basic serial sample might indeed be a good idea.

Regards
Erwan


On 9 May 2017 at 15:12, Dhamodharan Krishnan <dhamukrish@...> wrote:
Thanks Erwan for your reply.

Basically, I was able to use UART2 without any issue. But I have GPS and GSM modules which are serial device and hence need UART1 and 3 apart from UART2 for fetching and processing the data.

Would be very helpful if any example or advise much appreciated.

Regards
Dhamu


On 09-May-2017, at 12:48 PM, Erwan Gouriou <erwan.gouriou@...> wrote:

Hi Digidhamu,


If you're trying to use default UART (through ST link USB port) on nucleo_l476rg, you should use UART_2.

Erwan






On 6 May 2017 at 09:53, Dhamodharan Krishnan <dhamukrish@...> wrote:
Hi,

I am a day old since I started in Zephyr and from Arduino background. Could you please help with an example how to read from UART ports which are from 

Here is the code I have tried but failed.

#include <zephyr.h>
#include <misc/printk.h>
#include <uart.h>

int main(void) {

struct device *uartGPS;
uartGPS = device_get_binding(UART_1);

while (1) {
unsigned char* msg;
uart_poll_in(uartGPS, msg);

printk("%s", msg);
}
}

Regards
digidhamu


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






Re: [RFC] Touchscreen driver API

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

On Tue, 2017-05-09 at 13:54 +0200, Tomasz Bursztyka wrote:
Hi Jon,

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?
The main reason is that I hadn't thought of doing so ;-)

Just had a look at the sensor APIs and they could possibly work.
Two immediate questions spring to mind.

1. How to handle screen touched/not-touched state.
2. What units would a touchscreen use for it's values?

For 1, we could decide a special Z value meant screen-not-touched. Or
have a new trigger type for screen-not-touched events. With the latter,
the user would have two different trigger functions (for not-touched and
for data available), requiring the driver and user to be careful not to
get in a mess with any concurrent access by these two sources.

For 2, if we returned display pixel coordinates, then the complicated
translation function for converting the touchscreen values to display
coordinates would have to always be done, which could be an unnecessary
overhead for some users. Also, the application or user wouldn't be able
to get at the raw values in order to calibrate the system for that
coordinate translation. Possibly we'd need to support both raw and
screen values?

If the sensor driver did the coordinates translation, the sensor API
needs to gain a possibly messy new function for setting some touchscreen
calibration method (of which there could be many). So I'd favour just
returning raw touchscreen sample values the hardware produces and make
the user use other methods to convert that into more relevant
information. Though that doesn't seem to fit with current sensor types
which return well defined SI unit values.

--
Tixy


Re: Help required on reading UART device and print on console

Erwan Gouriou
 

Hi Dhamu,

I saw the task you entered in Jira afterwards and now better understand your question.
Indeed, you might need additional settings to get these ports working:
One point is that you should activate them in dts files and nucleo_l476rg_defconfig.
Also, please check that GPIO ports are activated according to your pinmuxing.
I'll have a check and get back to you.

A sample test was present some time ago, but it has been moved to tests section and now is more adapted to extensive testing rather than simple (re-)use.
Re-instanciating a basic serial sample might indeed be a good idea.

Regards
Erwan


On 9 May 2017 at 15:12, Dhamodharan Krishnan <dhamukrish@...> wrote:
Thanks Erwan for your reply.

Basically, I was able to use UART2 without any issue. But I have GPS and GSM modules which are serial device and hence need UART1 and 3 apart from UART2 for fetching and processing the data.

Would be very helpful if any example or advise much appreciated.

Regards
Dhamu


On 09-May-2017, at 12:48 PM, Erwan Gouriou <erwan.gouriou@...> wrote:

Hi Digidhamu,


If you're trying to use default UART (through ST link USB port) on nucleo_l476rg, you should use UART_2.

Erwan






On 6 May 2017 at 09:53, Dhamodharan Krishnan <dhamukrish@...> wrote:
Hi,

I am a day old since I started in Zephyr and from Arduino background. Could you please help with an example how to read from UART ports which are from 

Here is the code I have tried but failed.

#include <zephyr.h>
#include <misc/printk.h>
#include <uart.h>

int main(void) {

struct device *uartGPS;
uartGPS = device_get_binding(UART_1);

while (1) {
unsigned char* msg;
uart_poll_in(uartGPS, msg);

printk("%s", msg);
}
}

Regards
digidhamu


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





Re: Help required on reading UART device and print on console

Dhamodharan Krishnan <dhamukrish@...>
 

Thanks Erwan for your reply.

Basically, I was able to use UART2 without any issue. But I have GPS and GSM modules which are serial device and hence need UART1 and 3 apart from UART2 for fetching and processing the data.

Would be very helpful if any example or advise much appreciated.

Regards
Dhamu

On 09-May-2017, at 12:48 PM, Erwan Gouriou <erwan.gouriou@...> wrote:

Hi Digidhamu,


If you're trying to use default UART (through ST link USB port) on nucleo_l476rg, you should use UART_2.

Erwan






On 6 May 2017 at 09:53, Dhamodharan Krishnan <dhamukrish@...> wrote:
Hi,

I am a day old since I started in Zephyr and from Arduino background. Could you please help with an example how to read from UART ports which are from 

Here is the code I have tried but failed.

#include <zephyr.h>
#include <misc/printk.h>
#include <uart.h>

int main(void) {

struct device *uartGPS;
uartGPS = device_get_binding(UART_1);

while (1) {
unsigned char* msg;
uart_poll_in(uartGPS, msg);

printk("%s", msg);
}
}

Regards
digidhamu


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




Re: [RFC] Touchscreen driver API

Tomasz Bursztyka
 

Hi Jon,

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?

Br,

Tomasz


[RFC] Touchscreen driver API

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

Hello all

Zephyr doesn't have any API defined for touchscreen devices so when
writing a driver for one I needed to design an API. Below is what I came
up with and I wanted to request comments about it, with the intent of it
becoming a generic API others could use.

The driver interface is basically 2 functions:
- touchscreen_set_callback() to register a callback for notification

when samples are available.
- touchscreen_get_sample() to get a sample
(X,Y,Z value).

I also wrote some helper functions to translate touchscreen coordinates
to display coordinates:
- touchscreen_set_calibration() initialise coordinate translation params
- touchscreen_translate() translate an X,Y point

The actual header file with the API...


/** A single sample of the touchscreen's state */
struct touchscreen_sample {
/** Sampled value for touchscreen X position */
u16_t x;
/** Sampled value for touchscreen Y position */
u16_t y;
/** Sampled value for touchscreen Z (pressure) position */
u16_t z;
/** Flags associated with this sample */
u16_t flags;
};

/* Following #defines are for flags in struct touchscreen_sample */

/** Touchscreen is being touched */
#define TOUCHSCREEN_TOUCHED (1 << 0)

/* API to be implemented by touchscreen drivers */
struct touchscreen_api {
/* Get the next sample of the touchscreen state */
int (*get_sample)(struct device *dev,
struct touchscreen_sample *sample);
/* Set the callback function to be called when a sample is available */
void (*set_callback)(struct device *dev,
void (*callback)(struct device *));
};

/**
* @brief Get a sample from the touchscreen.
*
* @param dev Pointer to the device structure for the driver instance.
* @param sample Pointer to the sample to update.
*
* @return 0 on success, -EAGAIN if no more samples available,
* otherwise negative error value.
*/
static inline int touchscreen_get_sample(struct device *dev,
struct touchscreen_sample *sample)
{
const struct touchscreen_api *api = dev->driver_api;

return api->get_sample(dev, sample);
}

/**
* @brief Set the callback function.
*
* The callback function will be called when one or more samples becomes
* available. It may be executed in any any context, e.g. ISR or thread context,
* or may be called during the execution of touchscreen_get_sample(). Therefore
* the function mustn't itself use touchscreen_get_sample() or make use of
* kernel services that aren't safe from interrupt context.
*
* A typical action for the callback is to simply signal a semaphore or trigger
* some work on a workqueue.
*
* The callback function won't be called again until all samples have been
* retrieved, i.e. until the call to touchscreen_get_sample() which returned
* -EAGAIN.
*
* @param dev Pointer to the device structure for the driver instance.
* @param callback Pointer to the callback function.
*/
static inline void touchscreen_set_callback(struct device *dev,
void (*callback)(struct device *))
{
const struct touchscreen_api *api = dev->driver_api;

api->set_callback(dev, callback);
}


#ifdef CONFIG_TOUCHSCREEN_HELPERS

/** X,Y coordinates for a point on the touchscreen or display. */
struct touchscreen_point {
u16_t x;
u16_t y;
};

/**
* @brief Touchscreen coordinate translation parameters
*
* These are initialised by calling touchscreen_set_calibration().
* Members should be considered private and not accessed directly.
*/
struct touchscreen_xlat {
s64_t A;
s64_t B;
s64_t C;
s64_t D;
s64_t E;
s64_t F;
};

/**
* @brief Initialise touchscreen coordinate translation parameters.
*
* This requires that three different and valid display/touchscreen coordinate
* pairs are known.
*
* @param xlat Translation parameters to be initialised.
* @param touchscreen Three touchscreen coordinates that correspond to the
* given display coordinates.
* @param display Three display coordinates that correspond to the given
* touchscreen coordinates.
*/
void touchscreen_set_calibration(struct touchscreen_xlat *xlat,
const struct touchscreen_point touchscreen[3],
const struct touchscreen_point display[3]);

/**
* @brief Translate touchscreen coordinates into screen coordinates.
*
* Convert a touchscreen X,Y sample into the corresponding display X,Y
* coordinates by using the previously initialised translation parameters.
*
* @param xlat Translation parameters.
* @param touch_x Touchscreen X sample
* @param touch_y Touchscreen Y sample
* @param dislpay_x Display X coordinate
* @param dislpay_x Display Y coordinate
*/
void touchscreen_translate(struct touchscreen_xlat *xlat,
int touch_x, int touch_y,
int *display_x, int *display_y);

#endif /* CONFIG_TOUCHSCREEN_HELPERS */

5781 - 5800 of 8694