AMiRo-OS: Issueshttps://opendata.cit-ec.de/https://opendata.cit-ec.de/favicon.ico?14265323552019-11-14T10:52:36ZResearch for Cognitive Interaction
Redmine Feature #596 (New): automated test scripthttps://opendata.cit-ec.de/issues/5962019-11-14T10:52:36ZThomas Schöppingtschoepp@techfak.uni-bielefeld.de
<p>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.<br />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.</p>
<p>Preferably, this script will be included in the ./setup.sh bash script environment.</p> Feature #594 (Resolved): Revise periphALhttps://opendata.cit-ec.de/issues/5942019-03-14T10:06:12ZThomas Schöppingtschoepp@techfak.uni-bielefeld.de
<p>The periphery abstraction layer (periphAL) should be revised and optimized:</p>
<ul>
<li>All <code>enum</code> should be replaced by a combination of <code>#define</code> and optimal fundamental types (e.g. <code>typedef uint16_t apalExitStatus_t</code>) for best code efficiency.</li>
<li><code>apalGpioActive_t</code> should be extended by two further states: <code>APAL_GPIO_ACTIVE_NONE</code> and <code>APAL_GPIO_ACTIVE_ANY</code></li>
<li><code>apalGpioEdge_t</code> documentation s´must clearly state that values refer to physical (not logical!) signal edges.</li>
<li><code>apalGpioMeta_t</code> needs to be updated accordingly (i.e. two bits for the <code>apalGpioActive_t</code> member).</li>
<li>The <code>edge</code> member of <code>apalGpioMeta_t</code> can also apply to output signals, so wherever this struct is used, comments must be updated accordingly (right now the definitions in all <code>module.c</code> files state it as "interrupt edge", which just one of many ways how the edge information can be interpreted).</li>
</ul> Feature #592 (Resolved): AMiRo-LLD configuration via Makefilehttps://opendata.cit-ec.de/issues/5922019-03-08T12:24:17ZThomas Schöppingtschoepp@techfak.uni-bielefeld.de
<p>Currently AMiRo-LLD drivers are activated via the alldconf.h file, which results in numerous files being compiled without providing any functionality. Furthermore, those useless files will be included in the QtCreator projects, since GCC evaluates them.<br />To tackle this issue, drivers should be enabled via the module Makefile, so only the required files and paths are included to the build process. The alldconf.h file can still be used to configure the drivers if they provide further settings.</p> Feature #591 (New): More generic QtCreator project setuphttps://opendata.cit-ec.de/issues/5912019-03-08T12:20:12ZThomas Schöppingtschoepp@techfak.uni-bielefeld.de
<p>Recently, the AMiRo-OS QtCreator project setup script has been enhanced to use the GCC output for generating according project files. This enhancement should be ported to AMiRo-BLT and enhanced, so also AMiRo-OS (as well as any further higher level projects) can take advantage of this script.</p> Feature #590 (Resolved): System (de)initialization with disabled bootloaderhttps://opendata.cit-ec.de/issues/5902019-03-08T12:16:04ZThomas Schöppingtschoepp@techfak.uni-bielefeld.de
<p>Introduce a possibility to configure AMiRo-OS to not use a bootloader, so that the OS will fully initialize the hardware, including SSSP related signal handling and synchronization (if SSSP is enabled).</p> Feature #589 (New): Enhanced I/O eventshttps://opendata.cit-ec.de/issues/5892019-03-08T12:13:28ZThomas Schöppingtschoepp@techfak.uni-bielefeld.de
<p>Currently I/O interrupts result in I/O events and propagate the causing EXTI line via event flags (e.g. EXTI <a href="https://opendata.cit-ec.de/issues/3" class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="fix colored output in installink target (Closed)">#3</a> propagates (1 << 3) = 0x00000008). Since EXTI lines can aggregate multiple I/O pins (e.g. PA3 and PC3) this method can result in ambiguous events, because only the EXTI line but not the actual pin is specified.</p>
<p>To solve this issue, I/O events should not propagate plain eventflags_t data, but a struct like<br /><pre>
struct {
uint32_t flags : 24; // alternatively 28
uint32_t pin : 8; // alternatively 4
};
</pre>Since there is no EXTI hardware so far which provides more than 24 lines this solution is feasible. Alternatively the ratio can be set to 28:4 assuming that there will not be more than 2^4-1 pins aggregated in a single EXTI line. The -1 is important here, since the value of <code>pin</code> = 0 must be reserved to indicate ambiguity. This was the new method is compatible to plain eventflags_t and there might be cases where the exact pin can not be determined.<br />The determination can be realized within the ISR, which is called by the EXTI driver.</p> Support #588 (In Progress): AMiRo-BLT overhaulhttps://opendata.cit-ec.de/issues/5882019-03-08T10:57:40ZThomas Schöppingtschoepp@techfak.uni-bielefeld.de
<p>Currently AMiRo-BLT is a highly modified fork of an quite old version of OpenBLT. For better maintainability it should rather use a current version of OpenBLT and apply any required modifications as patches (like AMiRo-OS does with ChibiOS). This way the tools will profit from the progress made by the OpenBLT developers and the overall software can be kept up to date much easier.</p>
<p>Whether the new version will be released as 1.2 or 2.0 needs to be discussed once the new software architecture is in place. If possible, the new bootloaders should be backwards compatible with the 1.x versions, though.</p> Feature #587 (New): Implement I2C bus clear functionhttps://opendata.cit-ec.de/issues/5872019-02-25T16:02:00ZThomas Schöppingtschoepp@techfak.uni-bielefeld.de
<p>Implement the I2C bus clear function as specified by the <a href="https://www.nxp.com/docs/en/user-guide/UM10204.pdf" class="external">I2C standard</a> (Rev. 6; section 3.1.16).<br />This function should also be made available as dedicated unit test command.</p>
<p>Such a procedure has already been implemented for <a href="https://opensource.cit-ec.de/projects/amiro-os/repository/revisions/1.0_stable/entry/boards/DiWheelDrive/board.c" class="external">AMiRo-OS v1</a> as well as a device specific reset for the AT24C01B EEPROM.</p> Feature #586 (New): Configurable shell historyhttps://opendata.cit-ec.de/issues/5862019-02-25T15:53:41ZThomas Schöppingtschoepp@techfak.uni-bielefeld.de
<p>Introduce a configurable buffer for the shell, which holds the N last commands.<br />With N set to 0, the behavior should be like now, with the input buffer acting as a <em>wannabe</em> 1-command history.<br />With N set to 1, the behavior would be very similar, but there would be a <em>true</em> 1-command history.</p> Feature #585 (Resolved): Investigate whether CAN can be an optional feature of AMiRo-OShttps://opendata.cit-ec.de/issues/5852019-02-25T15:50:11ZThomas Schöppingtschoepp@techfak.uni-bielefeld.de
<p>So far, having a CAN bus enabled is mandatory for AMiRo-OS to work.<br />The necessity for this should be investigated again and - if possible - this requirement should be removed.</p>