Introducing SAUL, the [S]ensor [A]ctuator [U]ber [L]ayer by haukepetersen · Pull Request #3538 · RIOT-OS/RIOT

haukepetersen · 2015-07-31T23:34:04Z

~~Let me introduce to you RASI - the all new generic [R]IOT [A]ctuator [S]ensor [I]nterface.~~
EDIT Let me introduce to you SAUL - the all new generic [S]ensor [A]ctuator [U]ber [L]ayer.
I had a nice idea for making all sensors and actuator in a system available via a unified API, and here are the results.

The concepts are very similar to (grnc) netdev and netif - every actuator and sensor is accessible through the same API (read and write for now) with one single data structure used of parameter passing -> phydat_t. All devices register at a central location and can then be listed, queried, searched and accessed. By specifying unique classes of devices, one could search for: "give me all sensors, that read pressure values" or similar.

This data structure phydat_t is made for carrying up to 3 dimensions of physical values, e.g. values read by sensor or set values for actuators. It takes only ~8 byte and contains additional to the data the physical unit and a scaling factor.

Also I included the sensors for auto-initialization, exactly in the same way we do it for network interfaces: In the board or in the application you just define a set of parameters for a device, and auto-init takes care of the rest.

Testing this PR is best done on the iot-lab_M3, as I included all 4 sensors and 3 LED (actuators) into this PR. A little comparison:

Code size of the default example before:

   text    data     bss     dec     hex
  28592     168    7304   36064    8ce0

and after:

   text    data     bss     dec     hex
  27648     168    7408   35224    8998

We save ~900 byte of flash and lose ~100byte of RAM. The saved flash is mainly due to one unified shell command (instead of one for each sensor before). The lost RAM is spend on the RASI registry, in this setup there are 8 devices in it (5 sensor entries, 3 LEDs) and one entry is 12 byte...

EDIT
~~The amount of touched files looks worse than it is - this PR is based on #3535 and #3420.~~
Removed all dependencies

miri64 · 2015-08-01T11:53:30Z

You might want to overthink that name ;-)

haukepetersen · 2015-08-01T12:25:38Z

possibly... Any better ideas?

miri64 · 2015-08-01T13:45:00Z

(U)ASAPI [(unified) actuator sensor API]?

miri64 · 2015-08-01T13:49:53Z

sys/include/phydat.h

Why no typedef for that? phydat_unit_t e.g.

As an ex-chemist I see a worrying lack of UNIT_MOL ;-P

(or as a more practical approach UNIT_PERCENT, UNIT_PERMIL, and UNIT_PPM)

As stated in the comment, extend the list when you need anything...

haukepetersen · 2015-08-03T11:41:48Z

Thought about the name, how about arcade? just not sure about the meaning, maybe something like Awesome RIOT Control/Acquisition Device Extension? Ideas?

kaspar030 · 2015-08-03T12:15:04Z

Nice work!

I think we should try to get away with a static (compile-time)registry., though. Similar to how we did it for shell commands.

OlegHahm · 2015-08-03T15:40:42Z

I think we should try to get away with a static (compile-time)registry., though. Similar to how we did it for shell commands.

👍 - and once again I'm not in favor of introducing more function pointers. I find them super annoying for debugging.

haukepetersen · 2015-08-04T13:29:06Z

Actually I am against the static approach, as this does not allow for hot-plugging - and that is a feature that I see as quite interesting and more-then-nice-to-have for the future!

haukepetersen · 2015-08-12T16:14:19Z

Renamed the interface, now i's all good man :-)

Also I separated the actual interface (drivers/saul) from the device registry (sys/saul_reg). For the registry, I switched from a pre-allocated array to a linked list. Although the lookups are slightly less efficient, the memory handling is way easier. Also the lookup mostly only has to be done once and afterwards a module can interact with a device directly (exception are shell commands, but for these performance is not the top-most concern...).

@kaspar030, care to take a look?

haukepetersen · 2015-08-24T13:34:32Z

rebased

OlegHahm · 2015-11-30T19:12:23Z

sys/include/saul_reg.h

what is the difference to saul_reg_t::name?

no same name (both point to the same text most likely), saul_reg_t is located in RAM for holding a saul reg entry, saul_reg_info_t is used for defining additional information about a device, e.g. used by auto-init

At some point we probably may decide to either get rid of this type and use a string directly or to let saul_reg_t point to this, dependent if there will be more information (fields) that is added to sauL_reg_info_t

OlegHahm · 2015-11-30T19:30:35Z

Reviewed the latest commits fixing my minor remarks. Please squash.

- isl29020 - l3g4200d - lps331ap - lsm303dlhc

haukepetersen · 2015-11-30T19:34:09Z

squashed

haukepetersen · 2015-12-01T09:47:54Z

Travis is happy - @kaspar030: do you ack?

kaspar030 · 2015-12-01T10:01:06Z

Yep. go!

Introducing SAUL, the [S]ensor [A]ctuator [U]ber [L]ayer

OlegHahm · 2015-12-01T11:09:02Z

Congrats!

sgso · 2015-12-01T11:18:04Z

Is this suitable to replace the awful LED-Macros some tests depend on? Instead of relying on LED_RED and other stuff to be defined (even if there aren't any red ones ;) use the 1st, 2nd, etc. actuator of type led?

OlegHahm · 2015-12-01T11:20:46Z

For LEDs I think there's no way around macros, because there are often inevitable for debugging where any overhead is not tolerable. I wouldn't object renaming to something like LED_DEBUG1 or the like, though.

daniel-k · 2015-12-01T11:32:12Z

sys/include/phydat.h

s/express/expressed/

Sorry for being that late, I waited with reading the docs until now that SAUL is merged.

haukepetersen · 2015-12-01T13:35:36Z

good catches -> fixed in #4369

haukepetersen assigned kaspar030 Jul 31, 2015

haukepetersen added this to the Release 2015.06 milestone Jul 31, 2015

miri64 reviewed Aug 1, 2015
View reviewed changes

PeterKietzmann mentioned this pull request Aug 3, 2015

make: enable selection of periph drivers via USEMODULE #3420

Closed

haukepetersen mentioned this pull request Aug 4, 2015

cpu/stm32f1: modernized peripheral GPIO driver #3535

Merged

haukepetersen force-pushed the add_sensif_actif branch from fab7700 to 6a140d2 Compare August 12, 2015 16:09

haukepetersen changed the title ~~Introducing RASI, the [R]IOT [A]ctuator [S]ensor [I]nterface~~ Introducing SAUL, the [S]ensor [A]ctuator [U]ber [L]ayer Aug 12, 2015

haukepetersen force-pushed the add_sensif_actif branch from 6a140d2 to df5c6ef Compare August 24, 2015 13:34

OlegHahm modified the milestones: Release 2015.09, Release NEXT MAJOR Sep 2, 2015

OlegHahm reviewed Nov 30, 2015
View reviewed changes

haukepetersen and others added 14 commits November 30, 2015 20:33

sys: added module for handling physical data

786895a

drivers: added S(ensor) A(ctuator) U(ber) L(ayer)

0390561

sys: added SAUL registry

6d14d42

sys/shell: added shell command for SAUL

9d5a39c

sys/auto_init: added auto init for SAUL devices

4950650

drivers/isl29020: added SAUL integration

1836163

drivers/l3g4200d: added SAUL integration

7a4d622

drivers/lps331ap: added SAUL integration

5274c4e

drivers/lsm303dlhc: added SAUL integration

84a094d

sys/shell: removed shell cmds for SAULified sensors

7accaa7

- isl29020 - l3g4200d - lps331ap - lsm303dlhc

boards/iotlab-m3: added SAUL config for sensors

16f0474

boards/fox: added SAUL configaration for sensors

f6dc6d0

examples/default: use SAUL

02f5024

boards/samr21: add SAUL led parameters

28e800d

haukepetersen force-pushed the add_sensif_actif branch from f18ebb5 to 28e800d Compare November 30, 2015 19:34

kaspar030 added a commit that referenced this pull request Dec 1, 2015

Merge pull request #3538 from haukepetersen/add_sensif_actif

e53dc6f

Introducing SAUL, the [S]ensor [A]ctuator [U]ber [L]ayer

kaspar030 merged commit e53dc6f into RIOT-OS:master Dec 1, 2015

daniel-k reviewed Dec 1, 2015
View reviewed changes

haukepetersen deleted the add_sensif_actif branch December 1, 2015 13:29

haukepetersen mentioned this pull request Dec 1, 2015

sys/phydat: fixed typos in documentation #4369

Merged

Conversation

haukepetersen commented Jul 31, 2015

Uh oh!

miri64 commented Aug 1, 2015

Uh oh!

haukepetersen commented Aug 1, 2015

Uh oh!

miri64 commented Aug 1, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

haukepetersen commented Aug 3, 2015

Uh oh!

kaspar030 commented Aug 3, 2015

Uh oh!

OlegHahm commented Aug 3, 2015

Uh oh!

haukepetersen commented Aug 4, 2015

Uh oh!

haukepetersen commented Aug 12, 2015

Uh oh!

haukepetersen commented Aug 24, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

OlegHahm commented Nov 30, 2015

Uh oh!

haukepetersen commented Nov 30, 2015

Uh oh!

haukepetersen commented Dec 1, 2015

Uh oh!

kaspar030 commented Dec 1, 2015

Uh oh!

OlegHahm commented Dec 1, 2015

Uh oh!

sgso commented Dec 1, 2015

Uh oh!

OlegHahm commented Dec 1, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

haukepetersen commented Dec 1, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants