AMiRo-OS issueshttps://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-OS/-/issues2022-05-17T14:41:34+02:00https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-OS/-/issues/26Dedicated HW timer for time synchronization2022-05-17T14:41:34+02:00Thomas SchöppingDedicated HW timer for time synchronizationDuring operation, AMiRo-OS system time can be synchronized via a GPIO signal (cf. SSSP).
Currently, the master module, driving that signal, relies on standard ChibiOS API to trigger the logic that toggles the GPIO output.
Even though Chi...During operation, AMiRo-OS system time can be synchronized via a GPIO signal (cf. SSSP).
Currently, the master module, driving that signal, relies on standard ChibiOS API to trigger the logic that toggles the GPIO output.
Even though ChibiOS utilizes an hardware timer, only a single timer is used for everything, which may entangles additional overhead, resulting in increased latency and jitter.
As an alternative, a dedicated hardware timer could be used for just that purpose, so time synchronization timing consistent as possible.
The feature should be optional (keep fallback to ChibiOS timer API) in case no further hadrware timer is available.
A challenge might be to ensure that the local time representation of the master module is always in sync with that signal.
Potentially, the master module itself needs to monitor the GPIO and synchronize its internal time representation to the timer like any slave module.https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-OS/-/issues/25Major update v3.02022-04-05T09:40:42+02:00Thomas SchöppingMajor update v3.0Rework of the AMiRo-OS project structure and configuration:
- [ ] structure
- [x] Include ChibiOS-Contrib project (community extensions to ChibiOS) as Git submodule.
- [ ] Include SSSP project as Git submodule and replace AMiRo-OS i...Rework of the AMiRo-OS project structure and configuration:
- [ ] structure
- [x] Include ChibiOS-Contrib project (community extensions to ChibiOS) as Git submodule.
- [ ] Include SSSP project as Git submodule and replace AMiRo-OS implementation of the protocol by the reference implementation (cf. https://gitlab.ub.uni-bielefeld.de/AMiRo/sssp/-/issues/1).
- [ ] configuration
- [x] Improve distinction between module and AMiRo-OS configuration.<br>
Module configuration: Entirely defined by module (within AMiRo-OS project); not overridable.<br>
AMiRo-OS configuration: Default values defined by module (within AMiRo-OS project), but overridable by application layer.
- [ ] Introduce dedicated configuration file for SSSP (ssspconf.h) and remove according settings from existing configurations.
- [x] Enable ChibiOS-Contrib via Makefile.
- [x] Set bootloader via Makefile, not per config header.
- [ ] Enable SSSP via Makefile
- [x] Simplify hooks by removing optional argument settings.
- [x] Remove OS_CFG_X settings but make AMIROOS_CFG_X settings overridable.
- [ ] Provide templates for all configuration files (use MIT license):
- [x] module.h
- [x] aosconf.h
- [ ] ssspconf.h
- [x] MakefileThomas SchöppingThomas Schöppinghttps://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-OS/-/issues/23streamline SSSP implementation2022-03-03T17:17:35+01:00Thomas Schöppingstreamline SSSP implementationThe SSSP module utilizes several event sources and listeners, which could be replaced by simple thread signaling:
- Event source and listener in the `timeout` part of struct `aos_ssspmsidata_t` could be avoided.
- The global objects `_d...The SSSP module utilizes several event sources and listeners, which could be replaced by simple thread signaling:
- Event source and listener in the `timeout` part of struct `aos_ssspmsidata_t` could be avoided.
- The global objects `_delayEventSource` and `_delayEventListener` could be avoided as well.
However, it will be required to pass the thread pointer as well as the event mask to callback functions, which requires a new "complex" type.https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-OS/-/issues/15Shell: readline() API function2022-03-17T10:14:13+01:00Thomas SchöppingShell: readline() API functionThis issue requires #13 to be implemented.
Introduce a `readline()` function for user interaction from within a shell command.
The footprint of the function should probably look like
```c
unsigned int readline(BaseSequentialStream* str...This issue requires #13 to be implemented.
Introduce a `readline()` function for user interaction from within a shell command.
The footprint of the function should probably look like
```c
unsigned int readline(BaseSequentialStream* stream, char* buffer, size_t n, char* prompt);
```
Where `stream` is the input stream (known by the individual shell commands via argument), `buffer` is a buffer to store the input to with maximum size `n` and `prompt` is an optional prompt string (may be `NULL`).
The function shall read characters until a newline character is detected and return the number of characters read (equal to `strlen(buffer)`).
The exact behavior of the function in case the user input exceeds `n` needs yet to be defined.https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-OS/-/issues/14Shell: multiple worker threads2022-03-17T10:14:27+01:00Thomas SchöppingShell: multiple worker threadsThis issue requires #13 to be implemented.
Introduce an additional configuration flag (e.g. `AMIROOS_CFG_SHELL_WORKERS`) to define the number of worker threads, which can execute commands in a concurrently manner.
This feature requires...This issue requires #13 to be implemented.
Introduce an additional configuration flag (e.g. `AMIROOS_CFG_SHELL_WORKERS`) to define the number of worker threads, which can execute commands in a concurrently manner.
This feature requires multiple changes to the overall command handling:
- output control:\
The user must be enabled to suppress and reactivate output for individual commands.
- priority control:\
The user should have the ability to modify the priority of worker threads.
- system and user commands:\
The user must be able to execute certain system commands (e.g. priority control) even if no further worker threads are available.
Therefore a distinction between system and user commands is required so that system commands can be executed within the shell dispatch thread.
The overall handling of concurrent commands should be similar to Linux, even though some aspects will most probably differ.https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-OS/-/issues/13Shell: split into dispatcher and worker thread2022-03-17T10:14:31+01:00Thomas SchöppingShell: split into dispatcher and worker threadSplit the shell logic into two threads: While very most of the current logic would be done by the _dispatcher_ thread, commands shall be executed in a separate _worker_ thread (child thread of the dispatcher).
This approach would allow ...Split the shell logic into two threads: While very most of the current logic would be done by the _dispatcher_ thread, commands shall be executed in a separate _worker_ thread (child thread of the dispatcher).
This approach would allow the worker to easily listen to individual events such as user input (which is not possible right now).
On the other hand, system stalling due to bad command implementations (i.e. waiting for an event but not taking system core events into account) can be prevented by the dispatch thread killing the worker thread by force on shutdown.
Stacks should be configured as small as possible for the dispatcher thread and configurable (via the `AMIROOS_CFG_SHELL_STACKSIZE` macro) for the worker thread.https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-OS/-/issues/11Remote shell returning back multiple times2022-03-17T10:14:50+01:00Thomas SchöppingRemote shell returning back multiple timesWhen _a_ connecting to a remote shell (via `--connect`) and then _b_ connecting back to the original shell (again via `--connect`) the remote connection seems not be closed completely.
After performing _a_ and _b_, the shell promts a "we...When _a_ connecting to a remote shell (via `--connect`) and then _b_ connecting back to the original shell (again via `--connect`) the remote connection seems not be closed completely.
After performing _a_ and _b_, the shell promts a "welcome back" message, but when issuing another `--connect` command _c_, this message is printed once more and no remote connection is established.
However, _c_ seems to fix any internal inconsitencies such that another attempt _d_ to issue a `--connect` command is successfull.
To this extend, infinite loops of _a_, _b_, _c_ are possible (the repeated _a_ corresponds to _d_ as descrbed above.)https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-OS/-/issues/7Flush output on shutdown2022-12-02T09:25:41+01:00Thomas SchöppingFlush output on shutdownWhen the system shuts down, it prints several according status messages.
Most of the time, however, the system powers off before all data was actually transmitted (= all text printed printed).
It should be evaluated if and how flushing ...When the system shuts down, it prints several according status messages.
Most of the time, however, the system powers off before all data was actually transmitted (= all text printed printed).
It should be evaluated if and how flushing can be realized, so that final shutdown is postponed until all streams have been flushed.
Since AMiRo-OS uses the generic BaseSequentialStream interface, the solution must be valid with this level of abstraction.
Exploitation of the underlying hardware interfaces (e.g. UART) is no valid solution.Christian KlarhorstChristian Klarhorsthttps://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-OS/-/issues/5Port AMiRo-OS to the BI-Vital platform2022-03-17T10:16:10+01:00Thomas SchöppingPort AMiRo-OS to the BI-Vital platformSince the BI-Vital is another embedded device developed at the same group as AMiRo, the AMiRo-OS software stack should be enabled for this platform as well.
Expected challenges for this port are:
- Correct configuration of all board fi...Since the BI-Vital is another embedded device developed at the same group as AMiRo, the AMiRo-OS software stack should be enabled for this platform as well.
Expected challenges for this port are:
- Correct configuration of all board files.
Especially since BI-Vital is a very energy-sensitive platform the CPU clock should be lowered (cf. current BI-Vital software).
- In contrast to all other modules supported by AMiRo-OS so far, BI-Vital does not feature a "trivial" serial interface.
Instead, the USB connection must be used for this.
While ChibiOS features a `SERIAL_USB` subsystem, there are no experiences how to use this, yet.
Implementation may thus be anything from trivial to very challenging.
- Some of the periphery found on BI-Vital is not yet supported by [AMiRo-LLD](https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-LLD).
Required drivers, interfaces and tests need to be implemented in AMiRo-OS as well as AMiRo-LLD.
This can be moved to another issue, though, if complexity turns out to be too high.https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-OS/-/issues/3high-precision time representation2022-03-17T10:16:46+01:00Thomas Schöppinghigh-precision time representationCurrently time in AMiRo-OS is represented at microsecond precision by definition.
For very time sensitive use cases, however, this resolution might turn out to be too coarse.
The proposed solution would be to introduce another compile t...Currently time in AMiRo-OS is represented at microsecond precision by definition.
For very time sensitive use cases, however, this resolution might turn out to be too coarse.
The proposed solution would be to introduce another compile time switch, to select at which resolution time is represented.
This can be either a completely individual value (e.g. 1000000 for microsecond precision) or just a selection between predefined settings (e.g. µs or ns).
While the benefit of such enhancement would be limited to very few use cases (but crucial for those), it may cause code incompatibilities.
As resolution scales, the data types `aos_timestamp_t`, `aos_interval_t` and `aos_longinterval_t` can represent different time scales.
Especially the rather efficient `aos_interval_t` type may cause issues.https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-OS/-/issues/1Automated test script2022-03-17T10:15:29+01:00Aleks StierAutomated test scriptThis issue was originally created by @tschoepp.
Introduce a test script, that sweeps compile parameters (e.g. AMIROOS_CFG_DBG), compiles all modules with these settings and evaluates compilation results (success, failure, warning) to ma...This issue was originally created by @tschoepp.
Introduce a test script, that sweeps compile parameters (e.g. AMIROOS_CFG_DBG), compiles all modules with these settings and evaluates compilation results (success, failure, warning) to match the expected output.
Since such a thorough compilation test will probably take quite some time, this should not be executed automatically by some CI tool but only on demand.
Preferably, this script will be included in the ./setup.sh bash script environment.
## Sub-Goals
* [ ] Extract compile parameters
* [ ] Edit Makefiles to disable or enable specific flags
* [ ] Generate different configurations for modules (test all parameters in different variations for each module)
* [ ] Automate compilations process
* [ ] Analyze build (Do results match expected output?)
* [ ] Enable configuration and visualization