Revision development chapters #54
Conversation
…guide Signed-off-by: Fabian Hartung <[email protected]>
Signed-off-by: Fabian Hartung <[email protected]>
Signed-off-by: Fabian Hartung <[email protected]>
Signed-off-by: Fabian Hartung <[email protected]>
Signed-off-by: Fabian Hartung <[email protected]>
Signed-off-by: Fabian Hartung <[email protected]>
Signed-off-by: Fabian Hartung <[email protected]>
…Partition" for clarity Signed-off-by: Fabian Hartung <[email protected]>
This section is now part of the Development chapter. Signed-off-by: Fabian Hartung <[email protected]>
Signed-off-by: Fabian Hartung <[email protected]>
Signed-off-by: Fabian Hartung <[email protected]>
| If you start your project from scratch, have a look at libraries which are already required by the EVerest | ||
| stack and/or Linux distribution. Reuse these libraries to keep the overall firmware footprint small. |
There was a problem hiding this comment.
The intention of this sentence isn't completely clear.
Perhaps something like:
If you are starting your program from scratch, and are considering using extra libraries to aid with certain functionality, have a look at libraries which are already required by the EVerest and/or are provided by the firmware's Linux distribution.
| your software as an EVerest module and use one of the EVerest interfaces for interaction. Alternatively, | ||
| you can utilize the simple MQTT-based API provided by the EVerest | ||
| `API <https://github.com/EVerest/everest-core/tree/main/modules/API>`_ module, which gives you access | ||
| to the EVerest stack internals. |
There was a problem hiding this comment.
which gives you some control over the EVerest stack and insight into its internals.
| EVerest module can be integrated into your firmware image. | ||
|
|
||
| In general, there are two ways to create customized firmware images. Either you create a complete Yocto | ||
| image based on the layer provided by chargebyte. Or, as already described in the Cross-compilation of |
There was a problem hiding this comment.
rather "layers" than "layer"
Link to the cross-compile section?
| do_install() { | ||
| install -d ${D}${bindir} | ||
| install -m 0755 ${B}/my-module ${D}${bindir} | ||
| } |
There was a problem hiding this comment.
Will this recipe really work out-of-the-box?
There was a problem hiding this comment.
To be honest I have not tested it. It was already part of the user guide, just moved it to a new location.
There was a problem hiding this comment.
We should check this later.
development.inc
Outdated
| #. Keep in mind that if you want to build a new EVerest module, it must be compatible with the EVerest | ||
| release used in the firmware. Please have a look at the official `EVerest documentation <https://everest.github.io/nightly/dev_tools/edm.html#setting-up-and-updating-a-workspace>`_ | ||
| to learn how to check out a dedicated EVerest release. The everest-core version used by the firmware | ||
| can be found in the release notes of the firmware image. |
There was a problem hiding this comment.
Please add a link to the Github repository
development.inc
Outdated
| release used in the firmware. Please have a look at the official `EVerest documentation <https://everest.github.io/nightly/dev_tools/edm.html#setting-up-and-updating-a-workspace>`_ | ||
| to learn how to check out a dedicated EVerest release. The everest-core version used by the firmware | ||
| can be found in the release notes of the firmware image. | ||
| #. Please note that before you can start with this chapter, the EVerest development environment should be set |
There was a problem hiding this comment.
The chapter is called "Checklist before starting", so it's a little bit to vague for me. So either we change the chapter name to be more specific or make this more precise.
development.inc
Outdated
| up on the local machine. To check that everything is installed correctly, EVerest should be compiled once | ||
| natively for your system. | ||
|
|
||
| A native installation of EVerest is also recommended, as EVerest has some simulation examples installed, |
There was a problem hiding this comment.
With "native" do you mean "compiled for the host system"?
| @@ -1,6 +1,23 @@ | |||
| Creation of customized firmware images | |||
| ====================================== | |||
|
|
|||
| The charge controller is based on the Yocto Project, which is a Linux Foundation project that provides | |||
There was a problem hiding this comment.
Please add a link to the Yocto project
| integrate them into a already existing mounted root file system and create an installable rauc image. | ||
|
|
||
| The first option is the recommended way to create customized firmware images. It is more complex to set up | ||
| the Yocto build environment, but it is the most flexible way to create customized firmware images. |
There was a problem hiding this comment.
I think it would be helpful to give examples which option is intended for whom. The first option is more for testers, while the second is more developer.
| 'chargebyte-bsp' repository to build a firmware image based on the hardware platform specific board support package (BSP). | ||
| Currently supported are the hardware platforms Tarragon (Charge Control C) and Charge SOM. | ||
|
|
||
| This will include EVerest and chargebyte's hardware abstraction layer (HAL). |
There was a problem hiding this comment.
On the one side we talk about board support package and on the other about hardware abstraction layer. But there is no explanation what's the difference.
No description provided.