AMiRo-OS

AMiRo-LLD is a compilation of low-level hardware drivers for the base version of

the Autonomous Mini Robot (AMiRo) [1]. It provides directional interfaces for an

operating system to access the drivers and for the drivers to access the

communication infrastructure via the operating system.

Copyright (C) 2016..2019  Thomas Schöpping et al.

(a complete list of all authors is given below)

This program is free software: you can redistribute it and/or modify

it under the terms of the GNU Lesser General Public License as published by

the Free Software Foundation, either version 3 of the License, or (at

your option) any later version.

This program is distributed in the hope that it will be useful, but

WITHOUT ANY WARRANTY; without even the implied warranty of

MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU

Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License

along with this program.  If not, see <http://www.gnu.org/licenses/>.

This research/work was supported by the Cluster of Excellence

Cognitive Interaction Technology 'CITEC' (EXC 277) at Bielefeld

University, which is funded by the German Research Foundation (DFG).

Authors:

 - Thomas Schöpping          <tschoepp[at]cit-ec.uni-bielefeld.de>

 - Marc Rothmann

References:

 [1] S. Herbrechtsmeier, T. Korthals, T. Schopping and U. Rückert, "AMiRo: A

     modular & customizable open-source mini robot platform," 2016 20th

     International Conference on System Theory, Control and Computing (ICSTCC),

     Sinaia, 2016, pp. 687-692.

################################################################################

#                                                                              #

#        RRRRRRRR   EEEEEEEE     AAA     DDDDDDDD   MM     MM  EEEEEEEE        #

#        RR     RR  EE          AA AA    DD     DD  MMM   MMM  EE              #

#        RR     RR  EE         AA   AA   DD     DD  MMMM MMMM  EE              #

#        RRRRRRRR   EEEEEE    AA     AA  DD     DD  MM MMM MM  EEEEEE          #

#        RR   RR    EE        AAAAAAAAA  DD     DD  MM     MM  EE              #

#        RR    RR   EE        AA     AA  DD     DD  MM     MM  EE              #

#        RR     RR  EEEEEEEE  AA     AA  DDDDDDDD   MM     MM  EEEEEEEE        #

#                                                                              #

################################################################################

This file provides information about the purpose of this project, the file

structure and some helpful guides for development of code.

================================================================================

CONTENTS:

  1  About the Project

  2  File Structure

  3  Developer Guides

    3.1  Adding a Device

    3.2  Implementing a Driver

================================================================================

1 - ABOUT THE PROJECT

=====================

AMiRo-LLD is a compilation of low-level hardware drivers, originally developed

for the Autonomous Mini Robot (AMiRo) [1]. It provides a modular design, so that

each driver can be activated individually as required. Interface functions allow

for bidirectional comunication with an operating system. On the one hand drivers

access according hardware interfaces via defined interface functions (which need

to be implemented by the operating system) and any applications (or the

operating system itself) can take advantage of the drivers by their individual

interfaces. The abstraction layer of the hardware interfaces is called

"periphAL", which is defined by this project. In order to configure which

drivers should be used in which version, the project expects an according file

"alldconf.h" to be found in the include paths.

Although this compilation was originally designed to be used in combination with

the AMiRo operating system (AMiRo-OS; cf. https://opensource.cit-ec.de/projects/amiro-os/),

it is not limited to this use case. The included drivers may be used for any

purpose and contributions of further drivers, even if the according hardware is

not present on the AMiRo platform, are highly appreciated.

2 - FILE STRUCTURE

==================

The files are structured as follows:

./

│ The project root directory contains this file, a license.html file as well as

│ a Makefile that allows to easily integrate the project. Furthermore, two

│ interface headers are provided: amiro-lld.h and periphALtypes.h. These are

│ entry points for any utilizing superproject, so it is not required (and not

│ recommended) to include each driver individually.

│

├── include/

│     For each supported hardware device, there is exactly one directory in this

│     folder. Further subfolders may contain various versions of a driver (e.g.

│     'v1/', 'v2/', etc.). By convention the root directory of a driver is named

│     by the form

│     "<product_name>/"

│     <product_name> is a placeholder for the exact name of the according

│     hardware, or the product familiy, if the driver is compatible with all

│     parts.

│     The root header consequently follows the naming scheme

│     "alld_<product_name>.h"

│     and header files within the version folders shall be named like

│     "alld<product_name>_<driver_version>.h"

│

├── source/

│     Any source files are placed in this directory. Naming conventions for

│     folders and files are the same as described before for the include

│     directory, as is the file structure. There is a dedicated folder for each

│     device and further subfolders for multiple driver versions. Source files

│     should only be put in these version folders.

│

└── templates/

      AMiRo-LLD requires an implementation of the defined interface and an

      configuration header to be accessible in the include paths at compile

      time. Template files for both can be found in this folder. It is

      recommended to place according implementations of these templated not in

      the AMiRo-LLD project, but the superproject which includes AMiRo-LLD.

3 - DEVELOPER GUIDES

====================

In order to keep all code within this project as homogeneous as possible, the

guides of these chapters should help developers to achieve functional and clean

results, which are portable and maintainable for future use. Whereas the textual

descriptions of the guides provide additional information about the underlying

concepts and mechanisms, a short summary is provided at the end of each chapter.

3.1  Adding a Device

--------------------

When adding new device to the project, the very first step is to create the

according folders in the include/ and source/ directories. For this guide, we

will add the fictional DEVICE1234. For this example the folders to be created

are "include/DEVICE1234/" and "source/DEVICE1234/".

The first file should be the root header: "include/DEVICE1234/alld_DEVICE1234.h"

Have a look at existing drivers and use one of those as template. This header

should introduce a new configuration to be set in the alldconf.h file and check

it using the preprocessor. Eventually, another header is included, pointing to

the selected driver version/implementation.

Such implementations are to be put in further subfolders, e.g.

"include/DEVICE1234/v1/" and "source/DEVICE1234/v1/". The header and C-source

files in those folders do not follow a strict scheme, although there are some

conventions to consider (i.e. naming conventions, cf. chapter 2).

Summing up, you have to

1) create device folders.

2) add a root header.

3) add further subfolders and implement the driver there.

3.2  Implementing a Driver

--------------------------

Implementation of a new driver usually is very straight-forward. You most

probably have a comprehensive datasheet of the device, or the manufacturer even

provides a reference driver implementation.

For the former case, you should first write a comprehensive header, containing

all information like constants, register maps, etc. and according abstract

access functions (e.g. for reading and writing registers, and convenient access

to common functionalities). Only the you implement those functions, using

periphAL to interface any hardware interfaces (e.g. I2C, SPI, etc.).

For the latter case, the reference implementation will specify some interface

functions to interact with the hardware (e.g. I2C, SPI etc.). Even though all

functionality should be covered by the reference driver, you still need to

implement those interface functions.

Since AMiRo-LLD does not rely on specific hardware or operating system, the only

valid way to interact with both is through periphAL. Under no circumstances you

must use any function of your operating system and directly or indirectly access

the hardware of your platform. For your driver, there is no knowledge about the

world beyond periphAL! If periphAL does not provide the function you need, you

can do the following: 1) Think again if you really need that funcionality or

whether it can be replicated by existing functions. 2) File a feature request

to extend periphAL. 3) Write a custom patch that modifies periphAL to meet your

requirements.

Summing up, you have to

1) Get and read the datasheet of the device (A) or

   acquire a copy of the reference implementation (B).

2) Case A: define constants, register map and access functions in a header file.

   Case B: identify the interface functions of the reference implementation.

3) Implement the missing functions using periphAL.

================================================================================