User manual content update

Author: TaddyHC

content/hardware/04.pro/carriers/portenta-hat-carrier/tutorials/user-manual/content.md

@@ -1806,7 +1806,16 @@ To configure the Ethernet settings, depending on the paired Portenta board, one
 #### Ethernet Interface With Linux
 <br></br>
 
-Using the Portenta X8 in combination with the Hat Carrier allows you to evaluate the Ethernet speed. First, make sure the Portenta X8 is mounted on the Hat Carrier, and then connect them using a RJ45 LAN cable. To measure the bandwidth, we will use the _iperf3_ tool, which is available [here](https://github.com/userdocs/iperf3-static).
+Using the Portenta X8 in combination with the Hat Carrier allows you to evaluate the Ethernet speed. First, ensure that the Portenta X8 is mounted on the Hat Carrier, and then connect them using an RJ45 LAN cable.
+
+Subsequently, open a terminal to access the shell of the Portenta X8 with admin (root) privileges.
+
+```bash
+adb shell
+sudo su -
+```
+
+When prompted, enter the password `fio`. To measure the bandwidth, we will use the _iperf3_ tool, which is available [here](https://github.com/userdocs/iperf3-static).
 
 To use the _iperf3_ tool, we will set the Portenta X8 and Hat Carrier as the Server and the controlling computer as the Client. The commands will measure the bandwidth between the Portenta Hat Carrier with Portenta X8 and the computer. For a deeper understanding of _iperf3_, refer to its [official documentation](https://iperf.fr/iperf-doc.php).
 
@@ -2330,7 +2339,7 @@ Next conditions will help you properly set the hardware to test GPIO controls:
 
 3. To prevent floating states and offer a consistent and predictable behavior, internal pull-ups are automatically enabled on all input pins. This default configuration means that, unless actively driven low, the pins will naturally read as high (or 3.3 V).
 
-When all conditions are set and in place, access the ADB shell on the Portenta X8 as follows:
+When all conditions are set and in place, access the Portenta X8's shell with admin (root) access as follows:
 
 ```bash
 adb shell
@@ -2573,29 +2582,29 @@ The pins used for the JTAG debug port on the Portenta Hat Carrier are the follow
 
 ## Understanding Device Tree Blobs (DTB) Overlays
 
-In the world of embedded systems, _U-boot_ and the _Linux kernel_ use a concept called __Device Tree Blobs (DTB)__ to describe a board's hardware configuration. This allows for a unified main source tree to be used across different board configurations, ensuring consistency.
+In the world of embedded systems, _U-boot_ and the _Linux kernel_ use a concept called __Device Tree Blobs (DTB)__ to describe a board's hardware configuration. This approach allows for a unified main source tree to be used across different board configurations, ensuring consistency.
 
-The boards, acting as carriers, allow various peripherals to be connected, such as temperature sensors or accelerometers. These carriers serve as expansion connectors. Users might want to connect various peripherals and be able to add or remove them easily.
+The boards, acting as carriers, allow various peripherals to be connected, such as temperature sensors or accelerometers. These carriers serve as expansion connectors. You might want to connect various peripherals and be able to add or remove them easily.
 
 The concept of modularity is applied to the _DTB_, resulting in __DTB overlays__. The hardware configuration is split into multiple small files, each representing a different peripheral or function.
 
-During the early boot stage, these overlays are merged together into a single DTB and loaded into RAM. This approach enables to select and change configurations with ease. However, it is important to note that changing the hardware configuration requires a system reboot to maintain system stability.
+During the early boot stage, these overlays are merged together into a single DTB and loaded into RAM. This approach enables users to select and change configurations with ease. However, it is important to note that changing the hardware configuration requires a system reboot to maintain system stability.
 
-The Device Tree Blob (DTB) overlays can be modified and maintained through a couple of methods. In builds that do not prioritize security, the file located at the following location can be edited.
+You can modify and maintain the Device Tree Blob (DTB) overlays through a couple of methods. In builds that do not prioritize security, you can edit the file located at the following location:
 
 ```
 /boot/devicetree/overlays.txt
 ```
 
 After making the desired changes, it is necessary to save and reboot the system to apply desired changes.
 
-On the other hand, the builds that prioritizes security, the *fw_setenv tool* accessible in user space must be used to apply according changes to the U-boot settings as follows:
+On the other hand, in builds that prioritize security, the *fw_setenv tool* accessible in user space must be used to apply the corresponding changes to the U-boot settings as follows:
 
 ```
 fw_setenv overlays=name_ov1 name_ov2
 ```
 
-While the current implementation does not allow passing parameters directly to the overlays, this functionality will be introduced in the future through enhancements to U-boot.
+Currently, parameters are passed indirectly to the overlays; however, upcoming enhancements to U-boot will introduce direct parameter passing functionality.
 
 U-boot can be configured to automatically load specific DTB overlays based on the carrier board it detects, in this case Portenta Hat Carrier, either by probing specific hardware or by reading an identification ID from an EEPROM.
 
@@ -2612,7 +2621,7 @@ fw_printenv is_on_carrier
 is_on_carrier=yes
 ```
 
-This information is written by U-boot during boot in a step referred to as _auto carrier detection_. The variables can be modified from user space, but after a reboot, it reverts to its default state unless the `carrier_custom` variable is set to `1`.
+This information is written by U-boot during boot in a step referred to as _auto carrier detection_. You can modify the variables from user space, but after a reboot, they revert to their default state unless the `carrier_custom` variable is set to `1`.
 
 ```bash
 fw_setenv carrier_custom 1
@@ -2627,9 +2636,9 @@ fw_setenv is_on_carrier yes
 fw_setenv overlays "ov_som_lbee5kl1dx ov_som_x8h7 ov_carrier_rasptenta_base ov_carrier_rasptenta_pwm_fan ov_carrier_rasptenta_ov5647_camera_mipi ov_rasptenta_iqaudio_codec" 
 ```
 
-The commands above enables functionalities such as a speed-controlled fan connector, an OV5647 based RPi v1.3 camera, and an IQ Audio Codec Zero audio HAT.
+The commands above enable functionalities such as a speed-controlled fan connector, an OV5647 based RPi v1.3 camera, and an IQ Audio Codec Zero audio HAT.
 
-Hardware configuration is divided into following layers:
+Hardware configuration is divided into the following layers:
 
 - __Layer 0__: System on Module (SoM), prefixed with `ov_som_`.
 - __Layer 1__: Carrier boards, prefixed with `ov_carrier_`.
@@ -2640,7 +2649,7 @@ EEPROMs, which store identification IDs, are typically defined on _Layer 1_ and
 Some overlays, such as:
 
 - `ov_som_lbee5kl1dx`: Adds Wi-Fi®
-- `ov_som_x8h7`: Adds the Portenta H7 external microcontroller
+- `ov_som_x8h7`: Adds the Portenta H7
 - `ov_carrier_rasptenta_base`: Base support for Portenta Hat Carrier
 
 add functionalities like Wi-Fi® and external microcontroller support. If no known carrier is detected, the first two overlays are applied by default if the Portenta X8 is mounted as the main board.
@@ -2967,7 +2976,7 @@ Please, refer to the [board pinout section](#pinout) of the user manual to find
 #### Using Linux
 <br></br>
 
-For Portenta X8, it is possible to use the following commands:
+With admin (root) access, you can use the following commands within the shell for the Portenta X8:
 
 ```
 sudo modprobe spidev
@@ -2984,7 +2993,7 @@ sudo systemctl reboot
 services:
     my_spi_service:
        devices:
-          - /dev/spi-1
+          - '/dev/spidev0.0'
 ```
 Following section configures a service named `my_spi_service` to use the SPI device available at `/dev/spi-1`.
 
@@ -3095,7 +3104,7 @@ Please, refer to the [pinout section](#pinout) of the user manual to find them o
 #### Using Linux
 <br></br>
 
-For Portenta X8, it is possible to use the following commands:
+For the Portenta X8, it is possible to use the following commands within the shell when you have admin (root) access:
 
 ```
 sudo modprobe i2c-dev
@@ -3114,7 +3123,7 @@ Following section configures a service named `my_i2c_service` to use the I2C dev
 services:
     my_i2c_service:
        devices:
-          - /dev/i2c-3
+          - `/dev/i2c-3`
 ```
 
 Within the Portenta X8 shell, you can use specific commands to quickly test I2C communication with compatible devices. The command below lists all the connected I2C devices:
@@ -3279,7 +3288,7 @@ Since the CAN bus pins are integrated within the High-Density connectors, they a
 #### Using Linux
 <br></br>
 
-For Portenta X8, the following instructions can help control CAN bus protocol. The CAN transceiver is enabled using the following command:
+For the Portenta X8, when you have admin (root) access, you can execute the following commands within the shell to control the CAN bus protocol. The CAN transceiver can be enabled using the following command
 
 ```
 echo 164 > /sys/class/gpio/export && echo out > /sys/class/gpio/gpio164/direction && echo 0 > /sys/class/gpio/gpio164/value
@@ -3593,14 +3602,14 @@ Please, refer to the board pinout section of the user manual to find them on the
 #### Using Linux
 <br></br>
 
-Within Portenta X8, the command `ls /dev/ttyUSB* /dev/ttyACM*` can be used to list available serial ports in Linux. Typically, USB serial devices appear as _/dev/ttyUSBx_ or _/dev/ttyACMx_.
+For the Portenta X8, when you have admin (root) access, you can execute the command `ls /dev/ttyUSB* /dev/ttyACM* /dev/ttymxc*` within the shell to list available serial ports in Linux. Typically, USB serial devices could appear as _/dev/ttyUSBx_, _/dev/ttyACMx_, or _/dev/ttymxcx_.
 
 ```
-ls /dev/ttyUSB* /dev/ttyACM*
-/dev/ttymxc1   // Something similar
+ls /dev/ttyUSB* /dev/ttyACM* /dev/ttymxc*
+/dev/ttymxc2   // Something similar
 ```
 
-The output _/dev/ttymxc1_ is an example of a potential serial device you might find on Portenta X8.
+The output _/dev/ttymxc2_ is an example of a potential serial device you might find on Portenta X8.
 
 Following Python® script uses the _pyserial_ library to communicate with devices over UART. It defines the `processData` function which prints the received data. You can modify this function based on your application's needs.
 
@@ -3613,7 +3622,7 @@ def processData(data):
     print("Received:", data)  # For now, just print the data. Modify as needed.
 
 # Set up the serial port
-ser = serial.Serial('/dev/ttymxc3', 9600)  # Use the appropriate port and baud rate for your device
+ser = serial.Serial('/dev/ttymxc2', 9600)  # Use the appropriate port and baud rate for your device
 
 incoming = ""
 
@@ -3636,7 +3645,7 @@ while True:
     time.sleep(0.002)  # Delay for data buffering, equivalent to Arduino's delay(2);
 ```
 
-The script sets up a serial connection on port _/dev/ttymxc1_ at a baud rate of _9600_. It then continuously checks for incoming data. When a newline character (`\n`) is detected, indicating the end of a message, the script processes the accumulated data and then resets the data string to be ready for the next incoming message.
+The script sets up a serial connection on port _/dev/ttymxc2_ at a baud rate of _9600_. It then continuously checks for incoming data. When a newline character (`\n`) is detected, indicating the end of a message, the script processes the accumulated data and then resets the data string to be ready for the next incoming message.
 
 The `time.sleep(0.002)` line adds a slight delay, ensuring data has enough time to buffer, similar to using `delay(2);` in Arduino.