How To Write A Driver For Accelerometer LIS3DSH In Zephyr?

1
2/23/23, 1221 AM
How to Write A Driver for Accelerometer LIS3DSH
in Zephyr?
Home(h ps//oxeltech.de/en/)
Oxel tech
Electronics (h ps//oxeltech.de/en/category/elect
ronics/)Embedded Systems
(h ps//oxeltech.de/en/category/electronics/embe
dded-systems/)RTOS ? (h ps//oxeltech.de/en/categ
ory/electronics/rtos/)Zephyr (h
ps//oxeltech.de/en/category/electronics/zephyr/)
How to Write A Driver for Accelerometer (h
ps//oxeltech.de/en/how-to-write-a-driver-for- ? L
IS3DSH in Zephyr? accelerometer-lis3dsh-in-zephyr/
) How To Write A Driver For Accelerometer
LIS3DSH In Zephyr?
Share

• In our previous Zephyr blog (h ps//oxeltech.de/en
  /using-zephyr-os-for-interfacing-an-imu-
  sensor-with-nrf52-over-spi/), we looked at how to
  interface a simple IMU Accelerometer sensor
  with Zephyr RTOS running on NRF52832. Knowing how
  to interface sensors over SPI protocol allows
  user to communicate with sensors register and
  get values for acceleration. We saw how we can
  create our own library for the sensor, in terms
  of simple header and C implementation le. This
  allowed us to hide functionality and separate the
  application code from the interfacing process,
  allowing user easy access to sensors
  functionality. This worked simply by declaring a
  single instance of the SPI bus and using the bus
  con gurations hardcoded in the library le
• LIS3DSH.c).
• We can further leverage the power of Zephyrs OS
  by adding driver support for your sensor. This
  allows user to not only use multiple instances of
  same sensors, but also provides a generic
  implementation of its functionality so that user
  can then decide on run-time which con guration
  of the bus to use (e.g., SPIs instance, bus
  frequency, pins etc.) but also to use multiple
  instances of the same sensor under di erent bus
  con gurations. Along with this, by writing
  drivers and interfacing them with Zephyrs APIs
  we begin to develop standardized implementation
  for sensors that can easily be integrated in
  projects that have previously used similar
  Zephyrs drivers and APIs.
• In this article, we ll see how we can add
  out-of-tree drivers in zephyr. Working in an
  Out-of-Tree
• OOT context means we will develop driver code
  independent of the central Zephyr repository, so
  no upstream changes are required. For Out-of-Tree
  driver development, Zephyr provides a generic
  example-application that can be cloned from their
  GitHub repository
• (h ps//github.com/zephyrproject-rtos/example-appl
  ication). This repo serves as a reference on how
  to structure Zephyr based applications.
• Table of Content
• Zephyrs Device Driver Model
• Sensors API
• Con guration Structure
• Se ing up the Drivers
• Main Application Code
• Links to our Resources
• References

2
How to Write A Driver for Accelerometer LIS3DSH
in Zephyr? section in initialization level order.
These speci c device Driver initialization APIs
such as Device_De ne() and Device_Declare() are
intended to declare instances of device and not
to be used in application side code. Oxel
tech The device initialization macros populate
some data structures at build time which are
split into read-only and runtime-mutable parts.
More information about the Device driver model in
Zephyr can be found in its documentation (h
ps//docs.zephyrproject.org/3.1.0/kernel/drivers/i
ndex.html).
2/23/23, 1221 AM
Share
Similarly, the code we wrote in our last blog for
the library had individual variables declared
with a global scope. We therefore begin by
encapsulating our code along with the data
structures that contain the Device Data and
Device Con guration se ings. By encapsulating the
data structures and code, it allows the drivers
to instantiate itself at runtime via Device
Driver Macro calls and allows data and con
guration se ings to act independently for each
instance of sensors drivers. Therefore in our
code, we de ne data structure and con guration
structure to hold pointers and variables that
code the data for that instance of
sensor. struct lis3dsh_data uint8_t spi_tx_buf
SPI_BUFSIZE // SPI Tx bu er uint8_t spi_rx_buf
SPI_INSTANCE // SPI Rx bu er const struct
device bus int x,y,z //values of acceleration
in x,y z union lis3dsh_bus_cfg struct
spi_dt_spec spi struct lis3dsh_con g int
(bus_init)(const struct device dev) const
union lis3dsh_bus_cfg bus_cfg We also
encapsulate our implementation functions code by
passing an argument of device type pointer and
copying the data and con g se ings in each of the
function from this device type pointer. This
pointer is initialized at the run-time. Functions
for our driver implementation would then look
like this static int get_acceleration( const
struct device dev) struct lis3dsh_data dta
dev data const struct lis3dsh_con g cfg dev
con g //Further implementation
3
How to Write A Driver for Accelerometer LIS3DSH
in Zephyr? And similarly, we use instance-based
Macros to initialize these device-tree structures
that we have used. We de ne these macros at the
end of our implementation le (lis3dh.c).
2/23/23, 1221 AM
//Register a node in the deviceTreeOx el
tech if DT_NUM_INST_STATUS_OKAY DT_DRV_COMPAT
0
Share
warning LIS3DSH driver enabled without any
devices endif de ne LIS3DSH_DEVICE_INIT(inst)
DEVICE_DT_INST_DEFINE (inst, lis3dsh_init,
NULL, lis3dsh_data_inst, lis3dsh_con
g_inst, POST_KERNEL, CONFIG_SENSOR_INIT_PRIORITY
, lis3dsh_driver_api) de ne
LIS3DSH_CONFIG_SPI(inst) .bus_init
SPI_init, .bus_cfg .spi SPI_DT_SPEC_INST_GE
T(inst, SPI_WORD_SET 8 SPI_OP_MODE_MASTER
SPI_MODE_CPOL SPI_MODE_CPHA, 0 , de ne
LIS3DSH_DEFINE_SPI(inst) static struct
lis3dsh_data lis3dsh_data_inst static const
struct lis3dsh_con g lis3dsh_con g_inst
LIS3DSH_CONFIG_SPI(inst) LIS3DSH_DEVICE_INIT(ins
t) DT_INST_FOREACH_STATUS_OKAY
LIS3DSH_DEFINE_SPI Sensors A PI To use the
drivers and make them interact with our
application code, we use Sensors APIs. In the
zephyr/include/drivers directory, you can nd all
the API level code for every conceivable driver
in Zephyr. In some cases, the API for your device
may be there. In other cases, it may not be. The
Sensors API in our case matches our needs. You
can read up about the Sensors API (h
ps//docs.zephyrproject.org/3.0.0/reference/periph
erals/sensor.html) on the o icial documentation
site. When you use a higher-level API, you write
static functions that match the API youre
working with. You pass the functions into an API
struct. These APIs streamline the way your
driver communicates with the application
code. For our drivers, we de ne a generic
function that communicates with our sensors
register to copy its values (accelerations in
all 3-axis) to the drivers data structure. We
then de ne our logic in code so that by
selecting di erent channels from the API call, we
can return speci c values corresponding to those
channels, e.g. for SENSOR_CHAN_ACCEL_X we return
acceleration value in x-axis . We then provide
reference of these functions to our sensors API
in the following way static const struct
sensor_driver_api lis3dsh_driver_api
.channel_get lis3dsh_channel_get,
4
How to Write A Driver for Accelerometer LIS3DSH
in Zephyr? .sample_fetch get_acceleration
2/23/23, 1221 AM

Oxel tech Con guration Structure
Knowing how to arrange your les in a way that it
can be interpreted by Zephyrs build system, is
critical for drivers development. Each Kcon g
and CMakeLists le should point to the next one in
the hierarchy structure so that all les and
DeviceTree bindings are linked together. The
main les that describe drivers apart from the .c
and .h les are the Kcon g, CMakeLists.txt and
module.yaml les.
Share
CMakeLists.txt is a Make le of sorts that you use
to add source les and include folders to a
project. The neat thing about CMake is that its
recursive and arranged in a hierarchy. This means
a higher level CMakeLists.txt le spells out
what, if anything, can be found in
sub-directories. You make the changes you need
closest to the code thats a ected.Kcon g allows
you to create project-based con guration
parameters.Like CMakeLists.txt, Kcon g les allow
you to keep the con guration as close to your
code. In this example, only the innermost
CMakelists.txt and Kcon g le pairs contain actual
build or con guration instructions. Working from
the innermost directories back to the example-
application/ directory, these le pairs act as
signposts, directing the build tools to nd the
innermost build and con guration
instructions. The second most important les for
the drivers con guration are the DeviceTree
bindings le (.YAML le) and the corresponding
Overlay le. As discussed earlier, Zephyrs
hardware structure is based in the form of a
DeviceTree. Here Device tree bindings le is used
to specify the format and meaning of the device
tree data for a particular device or component.
And a device tree overlay is a separate le that
contains additional device tree data that can be
overlaid on top of the main device tree at
runtime. This allows for dynamic modi cation of
the device tree nodes, such as adding or
removing devices or changing pin assignments for
device communication buses, without recompiling
the entire device tree. The sensor YAML le will
declare properties that may or may not need to be
initialized by the target-speci c overlay le for
correct driver operation. The properties declared
within the YAML le will have a key called
required, which may be true or false. If
propertyrequired is false, then it does not
need to be speci ed in the overlay le. If it is
true, then it must be speci ed in the overlay
le, or the project will not build. Setting Up
The Drivers There are three categorical topics to
understand when adding and interacting with a
driver. These are . Get the build system to
nd the driver . Have the target-speci c overlay
le in place that aligns with the sensor yaml le
. Understand the Zephyr generalized sensor
interaction functions Ge ing the build system to
nd your driver and incorporate it involves one
manifest le and a series of CMakeLists.txt and
Kcon g les. We begin by cloning the
example-application (h ps//github.com/zephyrproje
ct-rtos/example-application) from the Zephyr-RTOS
directory. You ll nd example-application inside
the created my-workspace. Within my-workspace
you ll nd your example-application, where you
ll nd the necessary les that you ll edit. Our le
structure within the Example-Application is as
follows.
5
2/23/23, 1221 AM
How to Write A Driver for Accelerometer LIS3DSH
in Zephyr?
Oxel tech
Share
File Structure in Example Application Looking
into our Example-Application folder we ll notice
our own created folder inside the drivers
directory. We ll see some changes made to the
Kcon g and CMakeLists.txt le at every level of
this hierarchy. To change the required con
guration les, Navigate to our Git-repository (h
ps//github.com/muhammadadeelzahid/LIS3DSH
Drivers-Zephyr-RTOS.git) for LIS3DSH sensor
drivers. Simply downloading this
example-application and replacing this one with
your own would unfortunately wont work as
build, and other setup folders need to be
initialized by west init manually so they are
correctly referenced from your zephyrs sdk.
Instead of replacing the whole folder, we ll
initialize the example-application as mentioned
on the GitHub page of Zephyr-RTOS Example
Application (h ps//github.com/zephyrproject-rtos/
example-application) and after that we ll
create and modify the following les, . Download
the drivers folder from our GitHub
repository (h ps//github.com/muhammadadeelzahid/L
IS3DSH Drivers-Zephyr-RTOS.git). Copy and
replace this folder inside example-application/
. Add the st,lis3dsh.yaml le from our GitHub
repository to the dts/bindings/sensor directory
in the example-application project . Add the
nrf52dk_nrf52832.overlay le to
example-application/app/boards directory. . Add
samples/sensor/lis3dsh/prj.conf from our GitHub
repository to example- application/app/ .
Overwrite the main.c source code from our GitHub
repository to the main.c le in the
example-application/app/src folder. Thats it
for le addition. Our nal directory structure
should look like as shown below. The extra les
that we created or modi ed are in red box.
Zephyr Driver Directory
Main A pplication Code Using device Drivers means
our sensors implementation lives inside the
deviceTree and so the process of initializing
the sensor would be similar to initializing a
built-in zephyr peripheral like I2C/SPI bus or
GPIO or LEDs. const struct device sensor
DEVICE_DT_GET DT_INST 0,st_lis3dsh)) Since
were using Sensors API to bridge the gap between
DeviceTree implementation and User application
code, we ll simply declare a variables of
sensor_value type which is understood by the
Sensors API, and using its API calls to fetch a
sample and extract the values of samples from the
6
2/23/23, 1221 AM
How to Write A Driver for Accelerometer LIS3DSH
in Zephyr?
Sensors Data structures. sensor_sample_fetch(sen
sor) Oxel tech sensor_channel_get(sensor,SENSOR_C
HAN_ACCEL_X,acc_x)
sensor_channel_get(sensor,SENSOR_CHAN_ACCEL_Y
,acc_y)
Share
sensor_channel_get(sensor,SENSOR_CHAN_ACCEL_Z
,acc_z) We can see our output on a COMM port
as follows
COM Port Output For more information on how to
write drivers for your sensors within the zephyr
ecosystem, feel free to reach out to the
Oxeltech. Link s To Our Resources . Blog
Post on interfacing LIS3DSH with Zephyr (h
ps//www.oxeltech.de/en/blogs/using-zephyr-os-for-
interfacing-an-imu-sensor- with-nrf52-over-spi)
. GIT repository for driver implementation of
LIS3DSH (h ps//github.com/muhammadadeelzahid/LIS
3DSH Drivers-Zephyr-RTOS.git) References . h
ps//zephyrproject.org/ (h ps//zephyrproject.org/
) . h ps//docs.zephyrproject.org/3.1.0/kernel/dr
ivers/index.html (h ps//docs.zephyrproject.org/3
.1.0/kernel/drivers/index.html) . h
ps//docs.zephyrproject.org/3.0.0/reference/periph
erals/sensor.html (h ps//docs.zephyrproject.org/
3.0.0/reference/peripherals/sensor.html) . h
ps//github.com/zephyrproject-rtos/example-applica
tion (h ps//github.com/zephyrproject-rtos/exampl
e-application) . h ps//github.com/zephyrproject-
rtos/zephyr (h ps//github.com/zephyrproject-
rtos/zephyr) . h ps//interrupt.memfault.com/blog
/building-drivers-on-zephyr (h
ps//interrupt.memfault.com/blog/building-drivers-
on-zephyr) . h ps//blog.golioth.io/adding-an-out
-of-tree-sensor-driver-to-zephyr/ (h
ps//blog.golioth.io/adding-an-out-of-tree-sensor-
driver-to-zephyr/) Team Oxeltech January 16,
2023(h ps//oxeltech.de/en/2023/01/16/) 549 pm
No Comme(h ps//oxeltech.de/en/how-to-write-a-driv
er-for-
accelerometer-lis3dsh-in-zephyr/respond)
nts
Did You Enjoy This Article?
7
2/23/23, 1221 AM
How to Write A Driver for Accelerometer LIS3DSH
in Zephyr?
Join Oxeltech community and get updated every
week We have a lot more just for you! Lets join
us now
Oxel tech
Email
Share
Subscribe Now
No charge
Unsubscribe anytime
Leave A Reply Your email address will not be
published. Required elds are marked Comment
Name
Email
Website Recent Post How To Write A Driver For
Accelerometer LIS3DSH In ndZweebsphityer?in
t(Hhitstbprsow/s/eOrxfoerlttheche
ne.Dxtet/imEne/I Hcoomwm-eTnot.-Write-A- Driver-Fo
r-Accelerometer-Lis3dsh-In-Zephyr/) January 16,
2023
Save my name, email, a Post Comment
(h ps//oxeltech.de/en/how- to-write-a-driver-for
- accelerometer-lis3dsh- in-zephyr/) SoC Vs SoM
System On Chip Vs System On Module
(Https//Oxeltech.De/En/System-On-Chip-Soc-Vs-
System-On-Module-Som/) December 23, 2022
(h ps//oxeltech.de/en/system-
on-chip-soc-vs-system-
8
2/23/23, 1221 AM
How to Write A Driver for Accelerometer LIS3DSH
in Zephyr?
ESD Best Practices (Https//Oxeltech.De/En/Esd-Bes
t- Practices/) DecembOer 6x, 2e02l2tech
Share
(h ps//oxeltech.de/en/esd- best-practices/) How
To Choose Between Microcontroller And FPGA For
Your Embedded Application? (Https//Oxeltech.De/E
n/Fpga-Vs-Microcontroller/) December 6, 2022
(h ps//oxeltech.de/en/fpga- vs-microcontroller/)
Hold-Up Capacitor Calculations And Uses
(Https//Oxeltech.De/En/Hold-Up-Capacitor-
Calculations-And-Use/) November 6, 2022
(h ps//oxeltech.de/en/hold- up-capacitor- calcul
ations-and-use/) MTBF Concept And Application
(Https//Oxeltech.De/En/Mtbf-Concept-And-
Application/) October 6, 2022
(h ps//oxeltech.de/en/mtbf- concept-and- applica
tion/) All About LiDAR Technology Complete
Guide (Https//Oxeltech.De/En/Lidar-Technology/)
September 6, 2022
(h ps//oxeltech.de/en/lidar- technology/) How
To Choose The Right Flash Memory For Your
Embedded Application. (Https//Oxeltech.De/En/Flas
h- Memory-In-Embedded-System/) August 6, 2022
(h ps//oxeltech.de/en/ ash- memory-in-embedded-
8/13
9
2/23/23, 1221 AM
How to Write A Driver for Accelerometer LIS3DSH
in Zephyr?
system/)
Altiums PCB Designer Tools Guide (Https//Oxeltec
h.De/En/Altium-Pcb-Designer-Tools- Guide/O) xel
tech July 6, 2022
Share
(h ps//oxeltech.de/en/altium-
pcb-designer-tools- guide/) Altiums Amazing
Features Project Management Tools
(Https//Oxeltech.De/En/Altium-Project-Management/
) June 6, 2022
(h ps//oxeltech.de/en/altium-
project-management/) Ceramic Capacitors Which
Aspects To Consider When Using Them In Your
Design? (Https//Oxeltech.De/En/Ceramic-Capacitor
-Uses/) May 8, 2022
(h ps//oxeltech.de/en/ceramic-
capacitor-uses/) How To Control DC Servo Motors?
(Https//Oxeltech.De/En/Dc-Servo-Motor-Controller/
) April 21, 2022
(h ps//oxeltech.de/en/dc- servo-motor-controller
/) Your Ultimate Guide To Designing Analog
Filters (Https//Oxeltech.De/En/Analog-Filters-De
sign-Guide/) April 9, 2022
(h ps//oxeltech.de/en/analog-
lters-design-guide/) Consumer Electronics,
Industrial Electronics And Industrial Standards
(Https//Oxeltech.De/En/Consumer-
And-Industrial-Electronics-Standards/) April 1,
2022
(h ps//oxeltech.de/en/consumer-
and-industrial- electronics-standards/)
10
2/23/23, 1221 AM
How to Write A Driver for Accelerometer LIS3DSH
in Zephyr?
Design Guide On USB-C PD Charge-Through Feature
With Data Role Swap (Https//Oxeltech.De/En/Usb-C-
Design-Guide/) March 2O3, 2x02e2 l tech
Share
(h ps//oxeltech.de/en/usb- c-design-guide/) Alti
ums Team Collaboration Features In PCB Design
(Https//Oxeltech.De/En/Altium-365-Team-
Collaboration/) March 6, 2022
(h ps//oxeltech.de/en/altium-
365-team- collaboration/) Using Zephyr OS For
Interfacing An IMU Sensor With NRF52 Over SPI
(Https//Oxeltech.De/En/Using-Zephyr-
Os-For-Interfacing-An-Imu-Sensor-With-Nrf52-Over-
Spi/) July 25, 2021
(h ps//oxeltech.de/en/using- zephyr-os-for- inte
rfacing-an-imu- sensor-with-nrf52-over-
spi/) Use Of Grounding Techniques In PCB Design
To Prevent Electromagnetic Interference (EMI)
(Https//Oxeltech.De/En/Pcb-Grounding-Techniques/)
June 29, 2021
(h ps//oxeltech.de/en/pcb- grounding-techniques/
) PCB Design Guidelines For Reduced
Electromagnetic Interference (EMI)
(Https//Oxeltech.De/En/Reduce-Emi-
In-Pcb-Layout/) May 5, 2021
(h ps//oxeltech.de/en/reduce-
emi-in-pcb-layout/) EMC Vs EMI Compatibility,
Principles Mechanism Comparisons
(Https//Oxeltech.De/En/Emc-And-Emi/) April 18,
2021
11
2/23/23, 1221 AM
How to Write A Driver for Accelerometer LIS3DSH
in Zephyr?
(h ps//oxeltech.de/en/emc- Oxel tech
Share
Continue Reading
(h ps//oxeltech.de/en/how-to-write-a-driver-for-
accelerometer-lis3dsh-in-zephyr/) How To Write A
Driver For Accelerometer LIS3DSH In Zephyr?
(Https//Oxeltech.De/En/How-To-Write-A-Driver-For-
Accelerometer- Lis3dsh-In-Zephyr/) Team Oxeltech
January 16, 2023 In our previous Zephyr blog,
we looked at how to interface a simple IMU
Accelerometer sensor with Zephyr RTOS running on
NRF52832. Knowing how Read More (H
ps//Oxeltech.De/En/How-To-Write-A
Driver-For-Accelerometer-Lis3dsh-In- Zephyr/)
(h ps//oxeltech.de/en/system-on-chip-soc-vs-syst
em-on-module-som/) SoC Vs SoM System On Chip
Vs System On Module (Https//Oxeltech.De/En/Syste
m-On-Chip-Soc-Vs-System-On-
12
2/23/23, 1221 AM
How to Write A Driver for Accelerometer LIS3DSH
in Zephyr?
Module-Som/) Team Oxeltech December 23,
2022 What is System on Chip, SoC? A SysOtemxoen
lCthiep ocr ShoC is a key component in Embedded
Systems today. An SoC refers to a Read More (H
ps//Oxeltech.De/En/System-On-Chip-Soc-Vs-System-O
n-Module-Som/)
Share
Would You Like Some Info?
Name Name Email Email Message Message
Send
Lets Discuss
Contact Us for any Queries
info_at_oxeltech.de (mailtoinfo_at_oxeltech.de)
(mailtoinfo_at_oxeltech.de)
49176 64738476 (Tel[phone])
(h p s//w
(tel[phone]
ww.li
nkedi n.co m/co mpan y/oxe ltech /)
Hardware Design Simulation(h ps//oxeltech.de/en
/hardware-design-simulation/)
PCB Layout Assembly(h ps//oxeltech.de/en/pcb-la
yout-assembly/) Firmware Development(h
ps//oxeltech.de/en/ rmware-development/)
Imprint(h ps//oxeltech.de/en/imprint/)
Contact Us(h ps//oxeltech.de/en/contact-us/)
Blog(h ps//oxeltech.de/en/blog/) Member Of IHK
(Https//Www.Ihk.De/)
13
2/23/23, 1221 AM
How to Write A Driver for Accelerometer LIS3DSH
in Zephyr?
Oxel tech
Share