EVerest ChargeSOM 0.9.0

docs/source/_static/css/cb_theme.css

@@ -30,8 +30,28 @@ body {
   line-height: 1.5 !important;
 }
 
-.document .bodywrapper .body p span.caption-text {
-  font-size: 30px !important;
+.document .bodywrapper .body p.caption,
+.document .bodywrapper .body caption,
+.document .bodywrapper .body span.caption-number,
+.document .bodywrapper .body span.caption-text {
+  font-size: 18px !important;
+  line-height: 1.5 !important;
+}
+
+.document .bodywrapper .body figure figcaption,
+.document .bodywrapper .body figure figcaption p,
+.document .bodywrapper .body div.figure p.caption {
+  text-align: center !important;
+}
+
+.document .bodywrapper .body figure figcaption,
+.document .bodywrapper .body div.figure p.caption {
+  padding-top: 0.1em !important;
+}
+
+.document .bodywrapper .body figure figcaption p,
+.document .bodywrapper .body div.figure p.caption {
+  margin-top: 0.1em !important;
 }
 
 .document .bodywrapper .body p strong,
@@ -63,14 +83,32 @@ body {
 }
 
 .document .sphinxsidebar .sphinxsidebarwrapper h4 {
-  font-size: 18px !important;
+  color: #fff !important;
+  font-size: 16px !important;
   font-family: "Open Sans", sans-serif !important;
+  font-weight: 700 !important;
+  margin: 16px 0 2px !important;
+  text-transform: capitalize !important;
+}
+
+.document .sphinxsidebar .sphinxsidebarwrapper h4::after {
+  content: ":" !important;
 }
 
 .document .sphinxsidebar .sphinxsidebarwrapper .topless a {
+  display: inline !important;
   font-size: 18px !important;
   font-family: "Open Sans", sans-serif !important;
   color: #fff !important;
+  line-height: 1.25 !important;
+  padding: 0 !important;
+  background-color: transparent !important;
+  text-decoration: none !important;
+  transition: color 0.15s ease !important;
+}
+
+.document .sphinxsidebar .sphinxsidebarwrapper .topless a:hover {
+  color: #ff8200 !important;
 }
 
 .document .sphinxsidebar .sphinxsidebarwrapper p {
@@ -102,7 +140,7 @@ body {
   font-size: 36px !important;
   font-family: "Open Sans", sans-serif !important;
   font-weight: 600 !important;
-  margin: 0 !important;
+  margin: 1.5em 0 0.5em !important;
   padding: 0 !important;
   border-bottom: none !important;
   background-color: #111827 !important;
@@ -113,7 +151,7 @@ body {
   font-size: 30px !important;
   font-family: "Open Sans", sans-serif !important;
   font-weight: 600 !important;
-  margin: 0 !important;
+  margin: 1.25em 0 0.45em !important;
   padding: 0 !important;
   background-color: #111827 !important;
   color: #fff !important;
@@ -124,13 +162,21 @@ body {
   font-size: 26px !important;
   font-family: "Open Sans", sans-serif !important;
   font-weight: 600 !important;
-  margin: 0 !important;
+  margin: 1em 0 0.4em !important;
   padding: 0 !important;
   background-color: #ff8200 !important;
   border-bottom: none !important;
   color: #fff !important;
 }
 
+.document .bodywrapper section>h2+section>h3 {
+  margin-top: 0.2em !important;
+}
+
+.document .bodywrapper section>h3+section>h4 {
+  margin-top: 0.2em !important;
+}
+
 .document .bodywrapper .highlight {
   background: #153659 !important;
 }
@@ -177,14 +223,17 @@ body {
 }
 
 .related ul li.right a {
+  display: inline-block;
   text-transform: capitalize;
   padding: 10px 15px;
   background-color: #ff8200;
   border-radius: 5px;
+  transition: background-color 0.15s ease, transform 0.15s ease;
 }
 
 .related ul li.right a:hover {
-  padding: 11px 17px;
+  background-color: #ff9a26;
+  transform: scale(1.05);
   text-decoration: none;
 }
 
@@ -202,6 +251,36 @@ dl.field-list>dt {
   background-color: #1c354f !important;
 }
 
+.document .bodywrapper table.docutils th p,
+.document .bodywrapper table.docutils td p {
+  text-align: left !important;
+}
+
+.document .bodywrapper .footnote:target {
+  background-color: transparent !important;
+}
+
+.document .bodywrapper .footnote-reference,
+.document .bodywrapper .footnote .label,
+.document .bodywrapper .footnote .label a,
+.document .bodywrapper .footnote .fn-bracket {
+  color: #ff8200 !important;
+}
+
+.document .bodywrapper .footnote,
+.document .bodywrapper .footnote p {
+  line-height: 1.2 !important;
+}
+
+.document .bodywrapper .footnote {
+  margin: 0.2em 0 !important;
+}
+
+.document .bodywrapper .footnote p {
+  margin-top: 0 !important;
+  margin-bottom: 0 !important;
+}
+
 .document .bodywrapper .note {
   background-color: #1c354f !important;
 }
@@ -254,8 +333,11 @@ dl.field-list>dt {
     font-size: 17px !important;
   }
 
-  .document .bodywrapper .body p span.caption-text {
-    font-size: 22px !important;
+  .document .bodywrapper .body p.caption,
+  .document .bodywrapper .body caption,
+  .document .bodywrapper .body span.caption-number,
+  .document .bodywrapper .body span.caption-text {
+    font-size: 14px !important;
   }
 
   .document .bodywrapper .body .toctree-wrapper.compound ul li.toctree-l1 a {

docs/source/_static/files/bsp-only-dc.yaml

@@ -20,9 +20,6 @@ active_modules:
       evse_manager:
         - module_id: connector
           implementation_id: evse
-      energy_listener:
-        - module_id: connector
-          implementation_id: energy_grid
       evse_energy_sink:
         - module_id: grid_connection_point
           implementation_id: external_limits
@@ -61,7 +58,7 @@ active_modules:
         - module_id: bsp
           implementation_id: evse_board_support
       slac:
-        - module_id: evse_slac
+        - module_id: slac
           implementation_id: main
       powersupply_DC:
         - module_id: powersupply_dc
@@ -110,7 +107,7 @@ active_modules:
     module: EvseSecurity
     config_module:
       private_key_password: "123456"
-  evse_slac:
+  slac:
     module: EvseSlac
     config_implementation:
       main:

docs/source/carrierboard_development.rst

@@ -116,9 +116,9 @@ thus can be loaded and used without damaging the system. The signature can be cr
 using e.g. ``openssl cms …`` and thus creating a *detached* signature of the binary DT overlay file.
 
 To keep the DT overlay signature small, the certificate could be *not* included in this signature (and thus not stored
-inside the EEPROM), but to verify this signature, accessing the signing certificate must then be possible (e.g. placed in
-and loaded from the root filesystem). This raises other topics, so chargebyte's start point is to include it as
-a complete X.509 signature in the EEPROM even if this requires a larger EEPROM type.
+inside the EEPROM), but to verify this signature, accessing the signing certificate must then be possible
+(e.g. placed in and loaded from the root filesystem). This raises other topics, so chargebyte's start point is
+to include it as a complete X.509 signature in the EEPROM even if this requires a larger EEPROM type.
 
 Such a signature can be created for example using the following command line:
 
@@ -129,12 +129,12 @@ Such a signature can be created for example using the following command line:
 It is possible to re-use an existing Public-Key Infrastructure which is already used for signing the firmware
 update files.
 
-Once a matching Device Tree overlay and the corresponding signature are available, the EEPROM content needs to be created
-using the helper tool ``cb-dt-eeprom`` which is included in
-chargebyte's Github space: https://github.com/chargebyte/cb-eeprom-utils
+Once a matching Device Tree overlay and the corresponding signature are available, the EEPROM content needs
+to be created using the helper tool ``cb-dt-eeprom`` which is included in chargebyte's Github space:
+https://github.com/chargebyte/cb-eeprom-utils
 
-An example invocation for the carrier board which is the base for chargebyte's Charge Control V looks for example like follows.
-The example uses the typical chargebyte board revision number and a chargebyte order code which was assigned to this carrier board type.
+An example invocation for the carrier board used as the base for chargebyte's Charge Control V is shown below.
+It uses the typical chargebyte board revision number and an order code assigned to this carrier board type.
 
 .. code-block:: shell
 
@@ -149,20 +149,20 @@ For a random customer, this might look like this (here with a randomly chosen ve
 During carrier board manufacturing, it is assumed that writing the EEPROM is done via an external programmer
 which is out-of-scope for this documentation.
 
-But during the development phase, it might be necessary to exchange the EEPROM content and/or rewrite it for testing purpose.
-Then using an external programmer is cumbersome. Better and simpler is to write the created binary EEPROM image file
-into the EEPROM directly from the Charge SOM hooked up to such a carrier board. The following command can be used
-via SSH and/or Debug UART:
+But during the development phase, it might be necessary to exchange the EEPROM content and/or rewrite it for
+testing purpose. Then using an external programmer is cumbersome. Better and simpler is to write the
+created binary EEPROM image file into the EEPROM directly from the Charge SOM hooked up to such a carrier
+board. The following command can be used via SSH and/or Debug UART:
 
 .. code-block:: shell
 
    dd if="dt-eeprom.bin" of=/sys/class/i2c-dev/i2c-0/device/0-0050/eeprom
 
 Even so, it's still a complex process and long round trip. So it is possible to directly place such Device Tree overlay
 files in the root filesystem of the firmware in the ``/boot`` directory.
-Loading of such files can be controlled with the U-Boot environment variable ``overlays``. This variable can hold a whitespace
-separated list of filenames (basename of the file, i.e. without ``/boot`` prefix) which are loaded and merged
-in order *after* the base Device Tree file (given via ``fdtfile`` environment variable) is loaded.
+Loading of such files can be controlled with the U-Boot environment variable ``overlays``. This variable can
+hold a whitespace separated list of filenames (basename of the file, i.e. without ``/boot`` prefix) which are
+loaded and merged in order *after* the base Device Tree file (given via ``fdtfile`` environment variable) is loaded.
 This approach can also be used for a custom carrier board when the EEPROM approach does not fit.
 
 Here is a summary of related U-Boot environment variables:

docs/source/conf.py

@@ -19,6 +19,12 @@
 exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
 
 numfig = True
+numfig_format = {
+    'figure': 'Fig. %s:',
+    'table': 'Table %s:',
+    'code-block': 'Listing %s',
+    'section': 'Section %s',
+}
 
 jinja2_contexts = {
   'target-info': {

docs/source/everest_bsp.rst

@@ -1,11 +1,11 @@
 .. _everest_bsp.rst:
 
 EVerest Board Support Package Module
 ------------------------------------
 
-chargebyte developed a comprehensive hardware abstraction module (HAL, or also called BSP module - board support package)
-for EVerest charging stack to support the Charge SOM platform. The module is called ``CbChargeSOMDriver`` and is
-available in chargebyte's public EVerest repository as open-source code:
+chargebyte developed a comprehensive hardware abstraction module (HAL, or also called BSP module - board
+support package) for EVerest charging stack to support the Charge SOM platform. The module is called
+``CbChargeSOMDriver`` and is available in chargebyte's public EVerest repository as open-source code:
 https://github.com/chargebyte/everest-chargebyte/tree/main/modules/CbChargeSOMDriver
 
 This module already implements the required communication protocol to interact with the safety controller.

docs/source/everest_charging_stack.rst

@@ -16,7 +16,7 @@ The use case described in this configuration file includes the following:
 
 * DC charging mode
 * No TLS (Transport Layer Security) enabled for HLC (High Level Communication)
-* 3 phase, 16A fuse limit
+* 3-phase, 16 A fuse limit
 * Simulation of the IMD (Insulation Monitoring Device)
 * Simulation of the DC Supply Device
 * Energy management via JSON-RPC API
@@ -25,14 +25,14 @@ An overview of the EVerest modules is shown in the next section.
 
 .. include:: ../../includes/everest_overview_of_everest_modules.inc
 
-**DCSupplySimulator** (`view on GitHub <https://github.com/EVerest/everest-core/blob/main/modules/Simulation/DCSupplySimulator/manifest.yaml>`__)
+**DCSupplySimulator** (`view on GitHub <https://github.com/EVerest/EVerest/blob/main/modules/Simulation/DCSupplySimulator/manifest.yaml>`__)
 
 This module simulates a DC power supply device.
 
 **CbChargeSOMDriver** (`view on GitHub <https://github.com/chargebyte/everest-chargebyte/tree/main/modules/CbChargeSOMDriver>`__)
 
-This is the Hardware Abstraction Layer (HAL) for Charge SOM in EVerest. It implements
-the `evse_board_support <https://github.com/EVerest/everest-core/blob/main/interfaces/evse_board_support.yaml>`_
+This is the Hardware Abstraction Layer (HAL) for the Charge SOM in EVerest. It implements
+the `evse_board_support <https://github.com/EVerest/EVerest/blob/main/interfaces/evse_board_support.yaml>`_
 interface, enabling communication with the :code:`EvseManager` and control of the board. The EVerest community
 often refers to these HAL modules as BSPs, such as MicroMegaWattBSP and PhyVersoBSP. This module is
 essential for controlling the Charge SOM.

docs/source/firmware.rst

@@ -6,7 +6,12 @@
 Partitioning
 ------------
 
-The internal eMMC storage of a chargebyte device is divided into several partitions to support two independent systems: system A and system B. This setup enables firmware updates to run in the background while the device continues normal charging operations. Once the update is complete, the system can switch to the updated version with a reboot of the device. Additionally, this approach supports a rollback mechanism in case of update failures. In other words, during a firmware update, the active root file system switches from A to B (or vice versa), leaving the other partition available for rollback if needed.
+The internal eMMC storage of a chargebyte device is divided into several partitions to support two independent
+systems: system A and system B. This setup enables firmware updates to run in the background while the device
+continues normal charging operations. Once the update is complete, the system can switch to the updated version
+with a reboot of the device. Additionally, this approach supports a rollback mechanism in case of update failures.
+In other words, during a firmware update, the active root file system switches from A to B (or vice versa),
+leaving the other partition available for rollback if needed.
 
 .. list-table:: eMMC Partitioning
    :header-rows: 1
@@ -34,15 +39,10 @@ The internal eMMC storage of a chargebyte device is divided into several partiti
      - 256 MB
      - Logging file system B (/var/log)
 
-.. image:: ../../includes/_static/images/mountpoints.svg
+.. figure:: ../../includes/_static/images/mountpoints.svg
    :alt: Filesystem-Mountpoints
    :align: center
 
-.. adding a center-aligned caption for the image
-.. raw:: html
-
-   <div style="text-align: center;">
-     Filesystem Mountpoints
-   </div>
+   Filesystem Mountpoints
 
 .. include:: ../../includes/firmware_programming.inc