1 # Context Hub Runtime Environment (CHRE) 2 3 ## Build Instructions 4 5 Build targets are arranged in the form of a variant triple consisting of: 6 7 ``vendor_arch_variant`` 8 9 The vendor is the provider of the CHRE implementation (ex: google, qcom). The 10 arch is the CPU architecture (ie: hexagonv60, x86, cm4). The variant is the 11 target platform (ie: slpi, nanohub, linux, googletest). 12 13 ### Linux 14 15 CHRE is compatible with Linux as a simulator. 16 17 #### Linux Build/Run 18 19 The build target for x86 linux is ``google_x86_linux``. You can build/run the 20 simulator with the following command: 21 22 ./run_sim.sh 23 24 #### Linux Unit Tests 25 26 You can run all unit tests with the following command. Pass arguments to this 27 script and they are passed to the gtest framework. (example: 28 ``--gtest_filter=DynamicVector.*``) 29 30 ./run_tests.sh 31 32 ### SLPI Hexagon 33 34 First, setup paths to the Hexagon Tools (v8.x.x), SDK (v3.0), and SLPI source 35 tree, for example: 36 37 export HEXAGON_TOOLS_PREFIX=~/Qualcomm/HEXAGON_Tools/8.0 38 export HEXAGON_SDK_PREFIX=~/Qualcomm/Hexagon_SDK/3.0 39 export SLPI_PREFIX=~/Qualcomm/msm8998/slpi_proc 40 41 Then use the provided Makefiles to build: 42 43 make google_hexagonv62_slpi -j 44 45 ## Directory Structure 46 47 The CHRE project is organized as follows: 48 49 - ``chre_api`` 50 - The stable API exposed to nanoapps 51 - ``core`` 52 - Common code that applies to all CHRE platforms, most notably event 53 management. 54 - ``pal`` 55 - An abstraction layer that implementers must supply to access 56 device-specific functionality (such as GPS and Wi-Fi). The PAL is a C API 57 which allows it to be implemented using a vendor-supplied library. 58 - ``platform`` 59 - Contains the system interface that all plaforms must implement, along with 60 implementations for individual platforms. This includes the implementation 61 of the CHRE API. 62 - ``platform/shared`` 63 - Contains code that will apply to multiple platforms, but not 64 necessarily all. 65 - ``platform/linux`` 66 - This directory contains the canonical example for running CHRE on 67 desktop machines, primarily for simulation and testing. 68 - ``apps`` 69 - A small number of sample applications are provided. These are intended to 70 guide developers of new applications and help implementers test basic 71 functionality quickly. 72 - This is reference code and is not required for the CHRE to function. 73 - ``util`` 74 - Contains data structures used throughout CHRE and common utility code. 75 76 Within each of these directories, you may find a ``tests`` subdirectory 77 containing tests written against the googletest framework. 78 79 ## Supplied Nanoapps 80 81 This project includes a number of nanoapps that serve as both examples of how to 82 use CHRE, debugging tools and can perform some useful function. 83 84 All nanoapps in the ``apps`` directory are placed in a namespace when built 85 statically with this CHRE implementation. When compiled as standalone nanoapps, 86 there is no outer namespace on their entry points. This allows testing various 87 CHRE subsystems without requiring dynamic loading and allows these nanoapps to 88 coexist within a CHRE binary. Refer to ``apps/hello_world/hello_world.cc`` for 89 a minimal example. 90 91 ### FeatureWorld 92 93 Any of the nanoapps that end with the term World are intended to test some 94 feature of the system. The HelloWorld nanoapp simply exercises logging 95 functionality, TimerWorld exercises timers and WifiWorld uses wifi, for example. 96 These nanoapps log all results via chreLog which makes them effective tools when 97 bringing up a new CHRE implementation. 98 99 ### ImuCal 100 101 This nanoapp implements IMU calibration. 102 103 ## Porting CHRE 104 105 This codebase is intended to be ported to a variety of operating systems. If you 106 wish to port CHRE to a new OS, refer to the ``platform`` directory. An example of 107 the Linux port is provided under ``platform/linux``. 108 109 There are notes regarding initialization under 110 ``platform/include/chre/platform/init.h`` that will also be helpful. 111 112 ## Coding conventions 113 114 There are many well-established coding standards within Google. The official 115 C++ style guide is used with the exception of Android naming conventions for 116 methods and variables. This means 2 space indents, camelCase method names, an 117 mPrefix on class members and so on. Style rules that are not specified in the 118 Android style guide are inherited from Google. 119 120 * [Google C++ Style][1] 121 122 [1]: https://google.github.io/styleguide/cppguide.html 123 124 ### Use of C++ 125 126 This project uses C++11, but with two main caveats: 127 128 1. General considerations for using C++ in an embedded environment apply. This 129 means avoiding language features that can impose runtime overhead should 130 be avoided, due to the relative scarcity of memory and CPU resources, and 131 power considerations. Examples include RTTI, exceptions, overuse of dynamic 132 memory allocation, etc. Refer to existing literature on this topic 133 including this [Technical Report on C++ Performance][1] and so on. 134 2. Support of C++ standard libraries are not generally expected to be 135 extensive or widespread in the embedded environments where this code will 136 run. That means that things like <thread> and <mutex> should not be used, 137 in favor of simple platform abstractions that can be implemented directly 138 with less effort (potentially using those libraries if they are known to be 139 available). 140 141 [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf 142