AMiRo-OS

1.  Required Software

    1.  Git

    3.  System Kernel (ChibiOS)

    4.  Low-Level Drivers (AMiRo-LLD)

    5.  OpenOCD

2.  Recommended Software

    1.  gtkterm and hterm

    3.  Doxygen & Graphviz

    4.  QtCreator IDE

3.  Building and Flashing

from a command line.

according subfolder in the `./bootloader/` directory. Note that you will have to

adapt the makefiles and scripts, and probably the operating system as well.

`./kernel/` directory and adapt the scripts and operating system source code.

Any required low-level drivers for the AMiRo hardware are available in an

additional project: AMiRo-LLD. It is included as Git subodule and can be

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

The software tools named in this section are not essential for simply using or

2.1 gtkterm and hterm

For `hterm` you need to configure the tool analogously. With either tool the

robot can be reset by toggling the RTS signal on and off again, and you can

access the system shell of AMiRo-OS.  

not be available. In order to enable legacy support, replace the port value by

`/dev/ttyUSB0`.

2.2 PlantUML

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

In order to generate the documentation from the source code, Doxygen and

default versions for your system. Ubuntu users should simply run

    >$ sudo apt-get install doxygen graphviz

operating system. All other modules are powered off after reset so that only

these two offer a running bootloader, which is required for flashing.

4 Developer Guides

*   alldconf.h  

    Configuration header for the AMiRo-LLD project, which is part of AMiRo-OS.

    There are probably only very few configurations done here, since most

    unspecifically in the `./modules/aos_alldconf.h` file.

*   aosconf.h  

    Configuration header for the AMiRo-OS project. Existing cofiguration files

    are well documented and name all available settings.

*   board.h & board.c  

    well as initialization functions. These configurations highly depend on the

*   chconf.h  

    Configuration header for the ChibiOS/RT system kernel. There are probably

    only very few configurations done here, since most settings depend on the

be ignored since they are hints that something might be amiss and the program

will not act as intended).

folder. This folder contains module specific wrapper code for tests (e.g. for

hardware devices). Since tests are not essential but a more advanced feature,

a separate guide describes how to write a test in section 4.5.

arbitrary number of channels. Whilst only one of those channels can be selected

as input, each and all channels can be configured as output. As a result, if a

hardware module features multiple I/O interfaces, according configuration of the

If not disabled in the aosconf.h file, AMiRo-OS already runs a system shell in

a thread with minimum priority.

Depending on the configuration, several commands are registered to the system

shell by default (e.g. `kernel:test`, `module:info`), which are defined in the

defined in the module.h and module.c files. First you need to _declare_ the

shell command - an instance of the memory structure representing a command - in

the module.h file. Second, you have to _define_ that structure in the module.c

The callback function is typically defined right before the

`AOS_SHELL_COMMAND()` macro is called and should be a mere wrapper, calling

the shell thread and thus inherit its (typically very low) priority and there is

Finally, you have to register the command to a shell. This is very important and

known to it. Registration is done via the `aosShellAddCommand()` function,

preferably before the shell thread is started. Since test commands are the most

common use case, AMiRo-OS provides the hook `MODULE_INIT_TESTS()`, which is

**Summing up, you have to**

2.  implement a callback function.

3.  register the command to a shell.

hooks to be used. First of all, you need to configure and enable the interrupt

for the according GPIO. This can be done by implementing the

`MODULE_INIT_INTERRUPTS()` hook in the module.h file. For information how to use

Next, you have to explicitely whitelist the event flag for the main thread,

This is done via the optional `AMIROOS_CFG_MAIN_LOOP_GPIOEVENT_FLAGSMASK` macro,

which should be defined in the module.h file, for example:

project AMiRo-LLD, which is included in AMiRo-OS as Git submodule at

`./periphery-lld/AMiRo-LLD/` and acts similar to a static library. When adding a

new low-level driver to the framework, you first have to implement it of course.

`README.md` file in the AMiRo-LLD root directory.

Now that the new driver is available, it can be enbled by simply including the

Finally, you will probably want to validate your implementation via a test. How

this can be done is explained in detail in the next guide.

*   module_test_DEVICE1234.h

*   module_test_DEVICE1234.c

In order to be able to call such test function as a command via the AMiRo-OS

shell, you need to add an according shell command to the module.h and module.c

files. Whereas the command itself is typically very simple, just calling the

**Summing up, you have to**