Skip to content

Commit c845ebc

Browse files
FaHaGitFaHaGit
authored
Merge pull request #32 from chargebyte/everest/charge_som-introdurce_generic_chapters
Charge SOM: Introduce generic chapters
2 parents b6df6c9 + 0e26f5a commit c845ebc

20 files changed

+745
-0
lines changed

‎docs/source/cb_energy.rst

+12
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
.. _cb_energy.rst:
2+
3+
**********************
4+
CB energy
5+
**********************
6+
7+
.. note::
8+
CB Energy is currently intended only for connecting an EVerest AC charger. In the future, bi-directional
9+
charging and service operations are planned, which can also be used specifically for DC chargers.
10+
Feel free to contact us (:ref:`contact`) if we have sparked your interest in using CB Energy for your DC solution.
11+
12+
.. include:: ../../includes/cb_energy.inc

‎docs/source/development.rst

+111
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,111 @@
1+
.. _development.rst:
2+
3+
.. include:: ../../includes/development.inc
4+
5+
.. _cross_compiling:
6+
7+
Cross-compiling for Charge SOM
8+
==============================
9+
10+
Another way to integrate custom applications into the firmware image is to cross-compile the application
11+
for Charge SOM and include it in the image. A pre-requisite for this is to have the latest firmware image
12+
as a developer build. Always keep in mind, if you want to build a new EVerest module it must be
13+
compatible to the EVerest release within the firmware. Please have a look at the official
14+
`EVerest documentation <https://everest.github.io/nightly/dev_tools/edm.html#setting-up-and-updating-a-workspace>`_,
15+
how to checkout a dedicated EVerest release.
16+
17+
#. On an Ubuntu or Debian-based Linux distribution, install the cross-compilers for Charge SOM.
18+
19+
.. code-block:: console
20+
21+
sudo apt install build-essential libc6-arm64-cross gcc-aarch64-linux-gnu binutils-arm-linux-gnueabihf gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf
22+
23+
#. Download chargebyte's `digital certificate <https://chargebyte.com/controllers-and-modules/evse-controllers/charge-control-c#downloads>`_
24+
and use it to extract the root filesystem from the firmware image. The digital certificate is the same between Charge SOM and Charge Control C.
25+
26+
.. code-block:: console
27+
28+
rauc extract --keyring=<chargebyte_certificate>.crt <shipped_firmware>.image bundle-staging
29+
30+
.. note::
31+
Alternatively, if the above command does not work, you can use the following command:
32+
.. code-block:: console
33+
34+
unsquashfs -d bundle-staging <shipped_firmware>.image
35+
36+
But this will not verify the signature of the firmware image.
37+
38+
#. Mount the ext4 root filesystem image as a loop device.
39+
40+
.. code-block:: console
41+
42+
sudo mkdir -p /mnt/rootfs
43+
sudo mount bundle-staging/core-image-minimal-chargesom.ext4 /mnt/rootfs
44+
45+
#. Create a new directory in the folder where the new module was created (my-module) and create a new
46+
file called :code:`toolchain.cmake`. This file is used to set the toolchain for the cross-compilation.
47+
48+
.. code-block:: console
49+
50+
cd my-module
51+
mkdir toolchain
52+
cd toolchain
53+
touch toolchain.cmake
54+
55+
56+
#. Store the following lines in the :code:`toolchain.cmake` file:
57+
58+
.. literalinclude:: ../../includes/_static/files/toolchain.cmake
59+
60+
#. Create a new :code:`build` directory in "my-module" and navigate to it.
61+
62+
.. code-block:: console
63+
64+
mkdir build
65+
cd build
66+
67+
#. Run the following command inside to configure the build.
68+
69+
.. code-block:: console
70+
71+
cmake -DCMAKE_TOOLCHAIN_FILE=../toolchain/toolchain.cmake -DCMAKE_SYSROOT=/mnt/rootfs ..
72+
73+
#. When this ends successfully, start cross-compiling using :code:`make`:
74+
75+
.. code-block:: console
76+
77+
make install -j$(nproc)
78+
79+
#. Test that the resulting binaries are compiled for Charge SOM as a target:
80+
81+
.. code-block:: console
82+
83+
file dist/libexec/everest/modules/MyModule/MyModule
84+
85+
The output should be something like:
86+
87+
.. code-block:: console
88+
89+
dist/libexec/everest/modules/MyModule/MyModule: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV),
90+
dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=ad2342fdd3b8fb1949fc3e13b77382d3da72f28a, for GNU/Linux 3.7.0, stripped
91+
92+
#. The resulting binary and manifest file can be copied to the previously mounted root filesystem.
93+
94+
.. code-block:: console
95+
96+
cp dist/libexec/everest/modules/MyModule /mnt/rootfs/usr/libexec/everest/modules/
97+
98+
#. umount the loop device.
99+
100+
.. code-block:: console
101+
102+
sudo umount /mnt/rootfs
103+
104+
#. Make sure that the customized filesystem is in a clean state.
105+
106+
.. code-block:: console
107+
108+
fsck.ext4 -f bundle-staging/core-image-minimal-chargesom.ext4
109+
110+
#. Follow the steps under the section :ref:`firmware_customization` to install your PKI certificate, pack
111+
the modified root filesystem image again into the firmware update image, and test the new firmware image.

‎docs/source/everest_charging_stack.rst

+39
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,39 @@
1+
.. _everest_charging_stack.rst:
2+
3+
**********************
4+
EVerest charging stack
5+
**********************
6+
7+
.. include:: ../../includes/everest_introduction_to_everest.inc
8+
9+
.. include:: ../../includes/everest_basic_configuration.inc
10+
11+
Below is an example configuration file provided by chargebyte in its images:
12+
13+
.. literalinclude:: _static/files/bsp-only-dc.yaml
14+
15+
The use case described in this configuration file includes the following:
16+
17+
* DC charging mode
18+
* No TLS (Transport Layer Security) enabled for HLC (High Level Communication)
19+
* 3 phase, 16A fuse limit
20+
* Simulation of the IMD (Insulation Monitoring Device)
21+
* Simulation of the DC Supply Device
22+
23+
An overview of the EVerest modules is shown in the next section.
24+
25+
.. include:: ../../includes/everest_overview_of_everest_modules.inc
26+
27+
**DCSupplySimulator** (`view on GitHub <https://github.com/EVerest/everest-core/blob/main/modules/simulation/DCSupplySimulator/manifest.yaml>`__)
28+
29+
This module simulates a DC power supply device.
30+
31+
**CbChargeSOMDriver** (`view on GitHub <https://github.com/chargebyte/everest-chargebyte/tree/main/modules/CbChargeSOMDriver>`__)
32+
33+
This is the Hardware Abstraction Layer (HAL) for Charge SOM in EVerest. It implements
34+
the `evse_board_support <https://github.com/EVerest/everest-core/blob/main/interfaces/evse_board_support.yaml>`_
35+
interface, enabling communication with the :code:`EvseManager` and control of the board. The EVerest community
36+
often refers to these HAL modules as BSPs, such as MicroMegaWattBSP and PhyVersoBSP. This module is
37+
essential for controlling the Charge SOM.
38+
39+
.. include:: ../../includes/everest_further_reading.inc

‎docs/source/index.rst

+4
Original file line numberDiff line numberDiff line change
@@ -20,3 +20,7 @@ Charge SOM Evaluation Kit.
2020
:caption: Contents:
2121

2222
getting_started
23+
everest_charging_stack
24+
cb_energy
25+
development
26+
troubleshooting

‎docs/source/troubleshooting.rst

+103
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,103 @@
1+
.. _troubleshooting.rst:
2+
3+
Troubleshooting
4+
===============
5+
6+
Frequently Asked Questions
7+
--------------------------
8+
9+
.. contents::
10+
:local:
11+
12+
13+
Is it possible to use the Charge SOM as an EV simulator?
14+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
15+
16+
No, the Control Pilot interface on Charge SOM is not able to operate as an EV. Please look at
17+
our `website <https://www.chargebyte.com/>`_ for more suitable products.
18+
19+
20+
I want to control EVerest via CAN, how can I achieve this?
21+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
22+
23+
Currently there is no such EVerest module available, you will need to implement it on your own. But
24+
at least there is a `module <https://github.com/EVerest/everest-core/tree/main/modules/DPM1000>`_
25+
and a `library <https://github.com/EVerest/everest-core/tree/main/lib/staging/can_dpm1000>`_,
26+
which uses the CAN interface.
27+
28+
29+
How can I access the EVerest admin panel on Charge SOM?
30+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
31+
32+
The Charge SOM doesn't have an `EVerest admin panel <https://github.com/EVerest/everest-admin-panel>`_
33+
because of its limited resources. Please use your development environment to set up your configuration
34+
file or just use a plain text editor.
35+
36+
37+
Does EVerest on Charge SOM support ISO 15118-20 yet?
38+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
39+
40+
The required module for ISO 15118-20 has been included in the image since the chargebyte EVerest 0.2.0 release.
41+
Please note that the implementation is still under development.
42+
43+
44+
How do I set up OCPP 2.0.1 on Charge SOM with EVerest?
45+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
46+
47+
To support OCPP 2.0.1, the EVerest OCPP201 module must be integrated into the EVerest configuration.
48+
This module uses the `libocpp library <https://github.com/EVerest/libocpp>`_ to implement the OCPP 2.0.1
49+
protocol.
50+
The `OCPP201 module documentation <https://github.com/EVerest/everest-core/blob/main/modules/OCPP201/doc.rst>`_
51+
already contains some information about the module parameters, the provided and required interfaces,
52+
and the initial creation of the OCPP 2.0.1 database.
53+
54+
The most important points are summarised here:
55+
56+
1. The OCPP201 module must be included in your EVerest configuration.
57+
2. The CbSystem module can be used to fulfill the requirement of the system interface.
58+
3. While configuring the OCPP 2.0.1 module, ensure that you are using OCPP configuration and database
59+
paths which are covered by the update mechanism. The following paths are recommended:
60+
61+
- `CoreDatabasePath`: /var/lib/everest/ocpp201
62+
- `DeviceModelDatabasePath`: /var/lib/everest/ocpp201/device_model_storage.db
63+
- `DeviceModelConfigPath`: /var/lib/everest/ocpp201/component_config
64+
65+
Otherwise, if you don't want to use a persistent storage, you can also deploy those files in your
66+
RAUC image.
67+
4. The `CoreDatabasePath` is used, among other things, to store OCPP transaction data.
68+
5. The OCPP 2.0.1 device model initialization is done automatically by the OCPP201 module after the
69+
first start of EVerest. The database is stored the `DeviceModelDatabasePath`.
70+
6. The component config files are stored in the `DeviceModelConfigPath`. Component config files are
71+
used to initialize or update the device model database. To update a component config file, just the
72+
place a `component config file <https://github.com/EVerest/libocpp/tree/v0.16.2/config/v201/component_config>`_
73+
in the same directory structure in the DeviceModelConfigPath and change the values accordingly.
74+
Important keys of the component config files are:
75+
76+
- `standardized/InternalCtrlr.json: ChargePointId`: In "attributes" adapt the "value" key to configure the ChargePointId. Used to identify the Charging Station.
77+
- `standardized/InternalCtrlr.json: NetworkConnectionProfiles`: In "attributes" adapt the "ocppCsmsUrl" key. The URL in "ocppCsmsUrl" is used to connect to the CSMS.
78+
- `standardized/SecurityCtrlr.json: SecurityCtrlrIdentity`: In "attributes" adapt the "value" key to configure the SecurityCtrlrIdentity. It is the Charging Station identity.
79+
80+
For further information about the device model initialization, please refer to the
81+
`libocpp documentation <https://github.com/EVerest/libocpp/blob/main/doc/v2/ocpp_201_device_model_initialization.md>`_.
82+
83+
I tried to compile chargebyte's Hardware EVerest Modules, but it fails to build. How can it fix this?
84+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
85+
86+
The EVerest mainline development is very dynamic and doesn't guarantee any
87+
stable API along the EVerest modules. So after almost every EVerest release,
88+
chargebyte needs to adapt their modules to the latest API changes.
89+
90+
Please have a look at the `compatibility matrix <https://github.com/chargebyte/everest-chargebyte/blob/main/README.md>`_
91+
to see which EVerest release works with which chargebyte EVerest Modules release.
92+
93+
94+
I would like to implement a custom Modbus device in EVerest. Where should I start?
95+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
96+
97+
EVerest already has a module which takes care of Modbus communication. Please have a look at
98+
`SerialCommHub <https://everest.github.io/nightly/_generated/modules/SerialCommHub.html>`_,
99+
and let your module interact with this module via the `serial_communication_hub` interface.
100+
101+
.. _contact:
102+
103+
.. include:: ../../includes/troubleshooting_contact.inc

‎includes/_static/files/toolchain.cmake

+52
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
set(CMAKE_SYSTEM_NAME Linux)
2+
3+
if(EXISTS ${CMAKE_SYSROOT} AND IS_DIRECTORY ${CMAKE_SYSROOT})
4+
execute_process(COMMAND file ${CMAKE_SYSROOT}/bin/bash.bash
5+
OUTPUT_VARIABLE TARGET_BASH_OUTPUT)
6+
if(TARGET_BASH_OUTPUT MATCHES aarch64)
7+
message(STATUS "Setting architecture to aarch64")
8+
set(CMAKE_SYSTEM_PROCESSOR aarch64)
9+
set(CMAKE_C_COMPILER /usr/bin/aarch64-linux-gnu-gcc)
10+
set(CMAKE_CXX_COMPILER /usr/bin/aarch64-linux-gnu-g++)
11+
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} " CACHE STRING "" FORCE )
12+
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} " CACHE STRING "" FORCE )
13+
else()
14+
message(STATUS "Setting architecture to arm")
15+
set(CMAKE_SYSTEM_PROCESSOR arm)
16+
set(CMAKE_C_COMPILER /usr/bin/arm-linux-gnueabihf-gcc)
17+
set(CMAKE_CXX_COMPILER /usr/bin/arm-linux-gnueabihf-g++)
18+
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-psabi" CACHE STRING "" FORCE )
19+
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-psabi" CACHE STRING "" FORCE )
20+
endif()
21+
else()
22+
message(FATAL_ERROR "ERROR: SYSROOT '${CMAKE_SYSROOT}' not found!!!")
23+
endif()
24+
25+
if(CMAKE_BUILD_TYPE MATCHES Debug)
26+
# Debug flags
27+
message("Enabling Debug build")
28+
set(CMAKE_CXX_FLAGS_DEBUG "-g")
29+
else()
30+
# Enable compiler optimization flags
31+
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Os")
32+
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Os")
33+
34+
# Strip debug symbols
35+
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -s")
36+
endif()
37+
38+
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -L${CMAKE_SYSROOT}/usr/lib")
39+
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -L${CMAKE_SYSROOT}/usr/lib")
40+
41+
set(ENV{PKG_CONFIG_PATH} "${CMAKE_SYSROOT}/usr/lib/pkgconfig:$ENV{PKG_CONFIG_PATH}")
42+
43+
set(CMAKE_CXX_STANDARD_LIBRARIES "${CMAKE_SYSROOT}/usr/lib/libstdc++.so")
44+
45+
set(NODEJS_INCLUDE_DIR /usr/include/node) # make sure that nodejs is installed. If not, sudo apt-get install nodejs-dev
46+
47+
set(PYTHON_INCLUDE_DIRS "${CMAKE_SYSROOT}/usr/include/python3.10")
48+
set(PYTHON_LIBRARIES "${CMAKE_SYSROOT}/usr/lib/libpython3.10.so")
49+
50+
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
51+
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
52+
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

‎docs/source/_static/images/cbenergy/discover.png ‎includes/_static/images/cbenergy/discover.png

File renamed without changes.

‎docs/source/_static/images/cbenergy/home.png ‎includes/_static/images/cbenergy/home.png

File renamed without changes.

‎docs/source/_static/images/cbenergy/manual.png ‎includes/_static/images/cbenergy/manual.png

File renamed without changes.

‎docs/source/_static/images/cbenergy/setup-final.png ‎includes/_static/images/cbenergy/setup-final.png

File renamed without changes.

‎docs/source/_static/images/cbenergy/setup-skip.png ‎includes/_static/images/cbenergy/setup-skip.png

File renamed without changes.

‎docs/source/_static/images/cbenergy/setup.png ‎includes/_static/images/cbenergy/setup.png

File renamed without changes.

‎docs/source/_static/images/cbenergy/user.png ‎includes/_static/images/cbenergy/user.png

File renamed without changes.

0 commit comments

Comments
 (0)