docs: update checklist in README.md

.github/pull_request_template.md

@@ -19,12 +19,11 @@ write why  -->
 - [ ] My code follows the [style guidelines] as defined by IRNAS.
 - [ ] I have performed a self-review of my code.
 - [ ] My changes generate no new warnings.
-- [ ] I added/updated source code documentation for all newly added or changed
-      functions.
+- [ ] I added/updated source code documentation for all newly added or changed functions.
 - [ ] I updated all customer-facing technical documentation.
 
-Example strikeout: - [x] ~~I updated all customer-facing technical
-documentation.~~ - This PR introduced only internal facing changes.
+Example strikeout: - [x] ~~I updated all customer-facing technical documentation.~~ - This PR
+introduced only internal facing changes.
 
 ## After-review steps
 

README.md

@@ -6,34 +6,40 @@ of CI workflows for release automation.
 
 ## Checklist
 
-- [ ] Provide a concise and accurate description of your project in the GitHub
-      "description" field.
-- [ ] Provide a concise and accurate description of your project in this
-      `README.md` file, replace the title.
+### General GitHub setup
+
+- [ ] Provide a concise and accurate description of your project in the GitHub "description" field.
+- [ ] Provide a concise and accurate description of your project in this `README.md` file, replace
+      the title.
 - [ ] Ensure that your project follows [repository naming scheme].
-- [ ] Turn on `gitlint` tool by running `gitlint install-hook`. If you do not
-      have it yet, follow instructions
-      [here](https://github.com/IRNAS/irnas-guidelines-docs/tree/main/tools/gitlint).
-- [ ] Select the version of NCS in the `west.yaml` file, check the below section
-      for specifics.
-- [ ] Provide repository setup instructions, use template in _Setup_ section
-      below. Replace `<repo-name>`, `<board_name>`, and `<build_type>` as
-      appropriate for your project.
-- [ ] Set required [GitHub Actions secrets]. You can also **contact person in
-      charge for this** to do it for you.
-- [ ] Create a new project on the CodeChecker server. You can also **contact
-      person in charge** to do it for you.
-- [ ] (Optional) Include the `twister-rpi.yaml` GitHub Actions workflow for the
-      on-target testing. To do this copy the workflow from the [Twister RPi
-      workflow] into this project and see it's [README.md] in this repo for more
-      information on the requirements and setup.
-- [ ] Remove any files and folders that your project doesn't require. This avoid
-      possible multiple definition issues down the road and keeps your project
-      clean from redundant files.
-- [ ] Ensure that all rule targets provided in the example makefile work and are
-      relevant for your project. Change them or remove them, if you need to. If
-      you remove them make sure that they are not called from the enabled
-      workflows.
+
+### Tooling
+
+- [ ] Turn on `pre-commit` tool by running `pre-commit install`. If you do not have it yet, follow
+      instructions
+      [here](https://github.com/IRNAS/irnas-guidelines-docs/tree/main/tools/pre-commit).
+
+### Zephyr specifics
+
+- [ ] Select the version of NCS in the `west.yaml` file, check the below section for specifics.
+- [ ] Provide repository setup instructions, use template in _Setup_ section below. Replace
+      `<repo-name>`, `<board_name>`, and `<build_type>` as appropriate for your project.
+
+### GitHub Actions
+
+- [ ] Set required [GitHub Actions secrets].
+- [ ] Create a new project on the [CodeChecker server].
+- [ ] Ensure that all rule targets provided in the example makefile work and are relevant for your
+      project. Change them or remove them, if you need to. If you remove them make sure that they
+      are not called from the enabled workflows.
+- [ ] (Optional) Include the `twister-rpi.yaml` GitHub Actions workflow for the on-target testing.
+      To do this copy the workflow from the [Twister RPi workflow] into this project and see it's
+      [README.md] in this repo for more information on the requirements and setup.
+
+### Cleanup
+
+- [ ] Remove any files and folders that your project doesn't require. This avoid possible multiple
+      definition issues down the road and keeps your project clean from redundant files.
 - [ ] As a final step delete this checklist and commit changes.
 
 [repository naming scheme]:
@@ -43,6 +49,8 @@ of CI workflows for release automation.
 [README.md]: scripts/rpi-jlink-server/README.md
 [Twister RPi workflow]:
   https://github.com/IRNAS/irnas-workflows-software/tree/main/workflow-templates/rpi-twister-hil
+[CodeChecker server]:
+  https://github.com/IRNAS/irnas-codechecker-software?tab=readme-ov-file#creating-new-products---codechecker-integration-in-east
 
 ## Setup
 
@@ -66,6 +74,11 @@ east install toolchain
 east update
 ```
 
+### Setup `pre-commit`
+
+Turn on `pre-commit` tool by running `pre-commit install`. If you do not have it yet, follow
+instructions [here](https://github.com/IRNAS/irnas-guidelines-docs/tree/main/tools/pre-commit).
+
 ## Building and flashing
 
 To build the application firmware:
@@ -93,49 +106,42 @@ east util rtt
 
 ## west.yaml and name-allowlist
 
-The manifest file (`west.yaml`) that comes with this template by default only
-allows certain modules from Nordic's `sdk-nrf` and `sdk-zephyr` repositories,
-while ignoring/blocking others.
+The manifest file (`west.yaml`) that comes with this template by default only allows certain modules
+from Nordic's `sdk-nrf` and `sdk-zephyr` repositories, while ignoring/blocking others.
 
-This means that a setup on the new machine and in CI is faster as the
-`west update` command does not clone all modules from the mentioned repositories
-but only the ones that are needed.
+This means that a setup on the new machine and in CI is faster as the `west update` command does not
+clone all modules from the mentioned repositories but only the ones that are needed.
 
-Manifest file only allows modules that are commonly used by IRNAS, however this
-can be easily changed by uncommenting the required modules and running
-`west update`.
+Manifest file only allows modules that are commonly used by IRNAS, however this can be easily
+changed by uncommenting the required modules and running `west update`.
 
-**IMPORTANT:** Such improvements do not come with some tradeoffs, there are now
-two things that a developer must take note of.
+**IMPORTANT:** Such improvements do not come with some tradeoffs, there are now two things that a
+developer must take note of.
 
 ### Compile time errors cause of blocked/missing headers
 
-If the application source code includes some headers from blocked/missing
-modules or if included headers use blocked/missing modules you will get an error
-that will complain about missing header files. In that case, you have to go to
-manifest file, find commented module, run `west update`, return to the app
-folder, delete build folder and build again.
+If the application source code includes some headers from blocked/missing modules or if included
+headers use blocked/missing modules you will get an error that will complain about missing header
+files. In that case, you have to go to manifest file, find commented module, run `west update`,
+return to the app folder, delete build folder and build again.
 
 ### Updating `sdk-nrf` version
 
-Whenever you want to update the version of `sdk-nrf` (also know simply as `NCS`)
-you need to keep one general thing in mind: you need to manually keep revisions
-of `sdk-nrf` and `sdk-zephyr` projects, as well as their imports in sync.
-
-1. Open `west.yml` file in `sdk-nrf` repository
-   ([link](https://github.com/nrfconnect/sdk-nrf)). Make sure that you select
-   correct tag from selection from top-left dropdown menu.
-2. Check what repos are under `sdk-zepyhr` project's `name-allowlist`, those
-   should match the repos in `west.yaml` of your project (and this template),
-   under `sdk-zepyhr` project's `name-allowlist`. Most of the time they should
-   be commented out, but depends.
-3. Check what other repositories appear under `sdk-zepyhr` project as standalone
-   projects, they start appearing around line 100, after `NCS repositories`
-   comment. This projects should match the repos in `west.yaml` of your project
-   (and this template), under `sdk-nrf` project's `name-allowlist`. Most of the
-   time they should be commented out, but again, this depends.
-
-When a new `sdk-nrf` version is released, some new repos as `NCS repositories`
-might appear or be moved into `sdk-zephyr`.
+Whenever you want to update the version of `sdk-nrf` (also know simply as `NCS`) you need to keep
+one general thing in mind: you need to manually keep revisions of `sdk-nrf` and `sdk-zephyr`
+projects, as well as their imports in sync.
+
+1. Open `west.yml` file in `sdk-nrf` repository ([link](https://github.com/nrfconnect/sdk-nrf)).
+   Make sure that you select correct tag from selection from top-left dropdown menu.
+2. Check what repos are under `sdk-zepyhr` project's `name-allowlist`, those should match the repos
+   in `west.yaml` of your project (and this template), under `sdk-zepyhr` project's
+   `name-allowlist`. Most of the time they should be commented out, but depends.
+3. Check what other repositories appear under `sdk-zepyhr` project as standalone projects, they
+   start appearing around line 100, after `NCS repositories` comment. This projects should match the
+   repos in `west.yaml` of your project (and this template), under `sdk-nrf` project's
+   `name-allowlist`. Most of the time they should be commented out, but again, this depends.
+
+When a new `sdk-nrf` version is released, some new repos as `NCS repositories` might appear or be
+moved into `sdk-zephyr`.
 
 After any change to the `west.yaml` do not forget to run `west update`.

boards/arm/custom_nrf52840dk/README.md

@@ -1,8 +1,8 @@
 # Custom nRF52840 Board
 
-`custom_nrf52840` board is used to demonstrate how to create custom boards. It
-is in fact a simplified version of the nRF52840-DK board, so the `app` can be
-run on that development kit when using `custom_nrf52840dk`.
+`custom_nrf52840` board is used to demonstrate how to create custom boards. It is in fact a
+simplified version of the nRF52840-DK board, so the `app` can be run on that development kit when
+using `custom_nrf52840dk`.
 
-Only speciality is that the jlink runner is used by default when using
-`west flash`, this is set by `board.cmake` file.
+Only speciality is that the jlink runner is used by default when using `west flash`, this is set by
+`board.cmake` file.

samples/renode_example/README.md

@@ -1,26 +1,23 @@
 # Renode Example
 
-[Renode](https://renode.io/) is an open-source software development framework
-with commercial support from Antmicro that lets you develop, debug and test
-multi-node device systems reliably, scalably and effectively.
+[Renode](https://renode.io/) is an open-source software development framework with commercial
+support from Antmicro that lets you develop, debug and test multi-node device systems reliably,
+scalably and effectively.
 
-The goal of this sample is to review the Renode platform and how to use it with
-the nrf52840dk board.
+The goal of this sample is to review the Renode platform and how to use it with the nrf52840dk
+board.
 
-This sample contains a simple firmware for the nrf52840dk board, which does the
-following:
+This sample contains a simple firmware for the nrf52840dk board, which does the following:
 
 - On the press of Button 1 (on the nrf52840DK) it prints `GPIO Interrupt fired`.
 - It has enabled GPIO and Sensor shells.
-- It specifies in its device tree LIS2DW12 accelerometer and STTS751 temperature
-  sensors.
+- It specifies in its device tree LIS2DW12 accelerometer and STTS751 temperature sensors.
 
 ## Pre-Requisites
 
 ### Install Renode and Robot Framework
 
-To install Renode and all its required dependencies use the below installation
-script:
+To install Renode and all its required dependencies use the below installation script:
 
 ```shell
 cd <project root dir>
@@ -43,24 +40,20 @@ To run the built firmware in the Renode simulator just run:
 renode renode/nrf52840dk_example.resc
 ```
 
-The above command will open Renode GUI and load the provided script into it. At
-the same time it will open another terminal window with uart communication.
+The above command will open Renode GUI and load the provided script into it. At the same time it
+will open another terminal window with uart communication.
 
-Renode scripts [.resc] enable you to encapsulate repeatable elements of your
-project (like creating a machine and loading a binary) to conveniently execute
-them multiple times.
+Renode scripts [.resc] enable you to encapsulate repeatable elements of your project (like creating
+a machine and loading a binary) to conveniently execute them multiple times.
 
-[.resc]:
-  https://renode.readthedocs.io/en/latest/introduction/using.html#resc-scripts
+[.resc]: https://renode.readthedocs.io/en/latest/introduction/using.html#resc-scripts
 
 ## Robot Framework
 
-Renode greatly
-[integrates](https://renode.readthedocs.io/en/latest/introduction/testing.html)
-with the `Robot Framework` test automation framework. For this sample, we have
-created the `test-nrf52840dk.robot` file which will load the
-`nrf52840dk_nrf52840.repl` file, load the created sample `zephyr.elf` firmware
-file, start the machine and execute tests. The tests are defined in the
+Renode greatly [integrates](https://renode.readthedocs.io/en/latest/introduction/testing.html) with
+the `Robot Framework` test automation framework. For this sample, we have created the
+`test-nrf52840dk.robot` file which will load the `nrf52840dk_nrf52840.repl` file, load the created
+sample `zephyr.elf` firmware file, start the machine and execute tests. The tests are defined in the
 `test-nrf52840dk.robot` file.
 
 To run the tests:
@@ -71,19 +64,17 @@ renode-test test-nrf52840dk.robot
 
 ## Caveats
 
-We have implemented a simulated temperature driver in
-`renode/STTS751/STTS751.cs`. During development, we discovered that the same
-driver in the Zephyr kernel has a bug in the temperature conversion procedure
-(see `stts751_temp_convert` function in `drivers/sensor/stts751/stts751.c`).
+We have implemented a simulated temperature driver in `renode/STTS751/STTS751.cs`. During
+development, we discovered that the same driver in the Zephyr kernel has a bug in the temperature
+conversion procedure (see `stts751_temp_convert` function in `drivers/sensor/stts751/stts751.c`).
 
 This means that if we input the simulated temperature value with:
 
 ```shell
 sysbus.twi0.stts Temperature -5.5
 ```
 
-will not get the expected response if we send the below shell command to the
-firmware:
+will not get the expected response if we send the below shell command to the firmware:
 
 ```renode
 uart:~$ sensors get stts751@4a ambient_temp

samples/renode_example/renode/STTS751/README.md

@@ -1,7 +1,7 @@
 # STTS751
 
-This document outlines the steps required to implement a custom peripheral for
-Phenode. This chip is supported by Zephyr, but is not implemented in Renode.
+This document outlines the steps required to implement a custom peripheral for Phenode. This chip is
+supported by Zephyr, but is not implemented in Renode.
 
 Useful inks:
 
@@ -14,10 +14,8 @@ Observations during the implementation process:
 
 1. Add I2C device to .overlay file - driver must be supported in Zephyr
 2. Add sensor to `.repl` file, using the same address as in `.overlay` file
-3. Add Sensor implementation to `STTS751.cs` (this file). There are several ways
-   to implement the sensor. We have followed the example of `LIS2DW12.cs`.
-   Several methods must be implemented, this depends on the class the sensor
-   inherits from.
-4. Include the `STTS751.cs` sensor in the `.resc` file using the `include`
-   syntax
+3. Add Sensor implementation to `STTS751.cs` (this file). There are several ways to implement the
+   sensor. We have followed the example of `LIS2DW12.cs`. Several methods must be implemented, this
+   depends on the class the sensor inherits from.
+4. Include the `STTS751.cs` sensor in the `.resc` file using the `include` syntax
 5. Add a simple test to the `.robot` file

scripts/rpi-jlink-server/README.md

@@ -1,33 +1,32 @@
 # Raspberry Pi J-Link Server
 
-This directory contains two scripts that are used to run tests on a remote
-Raspberry Pi, which is connected to a J-Link debugger:
+This directory contains two scripts that are used to run tests on a remote Raspberry Pi, which is
+connected to a J-Link debugger:
 
-- The `request_resource.sh` script, which should be used inside a GitHub Action
-  Workflow before and after running tests on the device.
-- The `twister_pty.py` script, which is used with the `west/east twister`
-  command. This script receives and prints the outputs generated by the device.
+- The `request_resource.sh` script, which should be used inside a GitHub Action Workflow before and
+  after running tests on the device.
+- The `twister_pty.py` script, which is used with the `west/east twister` command. This script
+  receives and prints the outputs generated by the device.
 
 ## Remote Raspberry Pi
 
-Documentation on how to set up the Raspberry Pi and a detailed explanation of
-the functionality can be found
+Documentation on how to set up the Raspberry Pi and a detailed explanation of the functionality can
+be found
 [here](https://github.com/IRNAS/irnas-runners-software/blob/main/rpi-jlink-server/README.md).
 
 ## GitHub Actions Workflow
 
-The scripts mentioned are used by the `twister-rpi.yaml` GitHub Actions
-Workflow. The workflow is not included in this repository, as it is opt-in. To
-include it, you must copy the `twister-rpi.yaml` from the
+The scripts mentioned are used by the `twister-rpi.yaml` GitHub Actions Workflow. The workflow is
+not included in this repository, as it is opt-in. To include it, you must copy the
+`twister-rpi.yaml` from the
 [linked repository](https://github.com/IRNAS/irnas-workflows-software/blob/main/workflow-templates/rpi-twister-hil/.github/twister-rpi.yaml)
-into `.github/workflows` folder inside your repository and add the following
-GitHub secrets:
+into `.github/workflows` folder inside your repository and add the following GitHub secrets:
 
 - RPI_IP - IP address of the Raspberry Pi running the JLinkRemoteServer.
 
-The IP can be the local IP address of the Raspberry Pi, if the GitHub Action
-runner is running on the same network. Or it has to be the VPN IP address of the
-Raspberry Pi, if the GitHub Action runner is running on a different network.
+The IP can be the local IP address of the Raspberry Pi, if the GitHub Action runner is running on
+the same network. Or it has to be the VPN IP address of the Raspberry Pi, if the GitHub Action
+runner is running on a different network.
 
 The following make command has been added to the projects `makefile`:
 
@@ -36,15 +35,14 @@ test-remote:
     east twister -T tests -p nrf52840dk_nrf52840 --device-testing --device-serial-pty="scripts/twister_pty.py --host ${RPI_IP} --port 7777" --west-runner=jlink --west-flash="--tool-opt=ip ${RPI_IP}:7778"
 ```
 
-The command is used to run twister tests on the remote device. The
-`--device-serial-pty` and `--west-flash` options are used to connect to the
-remote device. The `twister_pty.py` script is used to print the output of the
-device to the GitHub Actions log. The `--west-runner` and `--west-flash` options
-are used to flash the device with the firmware and run the tests.
+The command is used to run twister tests on the remote device. The `--device-serial-pty` and
+`--west-flash` options are used to connect to the remote device. The `twister_pty.py` script is used
+to print the output of the device to the GitHub Actions log. The `--west-runner` and `--west-flash`
+options are used to flash the device with the firmware and run the tests.
 
 **IMPORTANT: The `testcase.yaml` has been modified as well to include the
 `- CONFIG_NULL_POINTER_EXCEPTION_DETECTION_NONE=y` `extra_configs` option.**
 
 This flag fixes the tests taking a minute longer, due to a timeout.
-[This related issue](https://github.com/zephyrproject-rtos/zephyr/issues/39216)
-describes the problem.
+[This related issue](https://github.com/zephyrproject-rtos/zephyr/issues/39216) describes the
+problem.