Skip to content

Latest commit

 

History

History
276 lines (186 loc) · 6.7 KB

doc.adoc

File metadata and controls

276 lines (186 loc) · 6.7 KB

DisroopEmbeddedHipster

1. System Requirements

DisroopEmbeddedHipster works on Linux, Windows and macOS. You need Docker, Python 3 and pyinvoke preinstalled. All further installation can be done by command of the Project CLI.

2. Getting Started

To get started run

git clone https://github.com/disroop/DisroopEmbeddedHipster
code DisroopEmbeddedHipster
invoke vscode.open

This will clone the project and via the Project CLI open the project in VSCode.

Note
The command open_in_vscode will install all missing dependencies linke VSCode, the required extension, …​

3. Introduction

"Text relating to Overview from landing page"

  • Automation

  • Quality built in

  • CI

3.1. Compiler

We need two outputs. A host build (x86) for running the unit tests and a ARM build for the final firmware.

3.1.1. Host

3.1.1.1. clang

clang is our primare compiler for the unittest builds.

3.1.1.2. gcc → coming soon

→ feature coming soon

3.1.2. ARM

3.1.2.1. arm gcc
3.1.2.2. clang

feature coming soon

3.1.2.3. iar

feature coming soon

4. Infrastructure

Show an overview about

  • local development

  • Servers ( Artifactory, Build-Automation) For more informatino see Learn how to organize the document into Build Automation.

5. Debug on the HW

5.1. Segger

  • Segger for St-Link

5.2. OpenOcd

feature coming soon

6. Modular Architecture

DisroopEmbeddedHipster is build in a modular architecture. Modularity is the decomposition of the overall functionality into smaller pieces with standardized interfaces.

6.1. Conan Dependencies

As illustrated in blinky conan dependencies, the application blinky depends on the BSP (stm32_bsp_iot_node), a runtime (stm32_runtime_l475_vtg)a runtime (stm32_runtime_l475_vtg). Other modules

todo: explain gcc_arm_none_eabi or remove this dependecy.

blinky conan dependencies
link:conan_graph_blinky_debug.dot[role=include]

The conan dependency tree in case of creating and running unit tests looks different. There the only dependency used is gtest. cmake_vars is a helper dependency which exports environment variables and options from a conanfile.

utest conan dependencies
link:conan_graph_utest.dot[role=include]

6.2. Cmake Target Dependencies

blinky cmake target dependencies
link:../build/blinky-debug/cmake-target-graph.dot[role=include]
utest cmake target dependencies
link:../build/utest/cmake-target-graph.dot[role=include]

7. CI/CD

Note: Continuous Delivery is coming in the future

8. Build Automation

  • Project CLI

  • azure

  • travis

  • github actions

  • jenkins

9. Reproducibility

Was macht es reproduzierbar: Docker, Conan

10. Project CLI

10.1. What is a Project CLI

Warning
TODO: describe what a project cli is, what advantage it brings and how it is build

The Disroop Embeded Hipster Project is build with a Project CLI

advantage

  • executable documetnation. no need to read lond getting started instruction. just run

  • tab complete for project cli with source <(inv --print-completion-script bash)

git clone https://github.com/disroop/DisroopEmbeddedHipster
invoke setup
code DisroopEmbeddedHipster

The available command // use Font Awesome for admonition icons :icons: font

10.2. Commands

project commands
link:https://raw.githubusercontent.com/disroop/DisroopEmbeddedHipster/main/doc/project_commands.txt[role=include]
project commands
link:../doc/project_commands.txt[role=include]
vscode commands
link:../doc/vscode_commands.txt[role=include]
all command
link:../doc/all_commands.txt[role=include]

The only preconditions are, that Docker and Python are installed.

11. Quality-Built in

One of the important goals is to build quality in. This means a new developer does not need to read many pages of paper to get to know how some basic things like formatting the code, or what kind of coding rules exist. Instead, he should be guided as much as possible with an automated solution. This is the aim of quality built in.

We manly use code compiler warnings, code formatters and code analysis tools. Those tools are run in the automated build and if possible we use IDE integration to prevent failing build and assist the developer instantly while editing code.

11.1. Compiler Warnings

The compiler warnings are the fist source for code analysis and should be the most important tool to assure the code quality. We use -Werror to assure a minimal code quality must be maintained. A more strick approache could be to use even more restictive settings linke -Wextra.

todo investigate what we should recommend: -Wall -Wextra -Werror? https://sourcegraph.com/search?q=context:global+-Wall+-Wextra+-Werror&patternType=literal

11.2. ClangFormat

ClangFormat is a very popular code formatting tool with IDE integration in VSCode and CLion.
We use a simple well curated Google style.

.clang-format
link:../.clang-format[role=include]

11.3. Coverage Analysis

Warning
todo
  • in Build

  • IDE Integration

  • define coverage limits

11.4. Code Analysis

11.5. clang-tidy

Warning
todo

11.6. CPPCHECK

Warning
todo ==== include-what-you-use WARNING: todo include-what-you-use

11.7. Sonar

Warning
todo

11.8. Dependabot

Stay up to date WARNING: todo

11.9. Renovate

Renovate Stay up to date WARNING: todo

11.10. Conclusion

Obviously one can not back all rules in an automated solutions as we showed in this chapter. But for those wehre an automated solution exist is server a great benefit.

11.11. Inspections / Code Analysis

12. Unittests

13. Toolchain

13.1. Conan

13.2. Cmake

13.3. Unittest

13.4. Supported IDE

  • VSCode

  • CLion

13.5. Compiler

13.5.1. Host

13.5.1.1. clang
13.5.1.2. gcc

13.5.2. ARM

13.5.2.1. clang
13.5.2.2. arm gcc
13.5.2.3. iar

13.6. VsCode Conan Plugin