Fix typos in documentation, doc comments and log messages

docs/building-and-flashing/build.md

@@ -4,15 +4,15 @@ page_id: build
 ---
 
 This project is a Zephyr app. If you already have all dependencies installed it can be compiled with `west build -b crazyradio2`.
-The rest of this page documents how setup your development environment.
+The rest of this page documents how to setup your development environment.
 
 This project uses [just](https://github.com/casey/just?tab=readme-ov-file#just) to simplify running commands. It can either be installed in your system or run with `uv run just`. Any commands can be run manually as well, look in the `justfile` at the root of the repository for the commands
 
 ## Host dependencies
 
 This project can be compiled on Linux and MacOS. Compiling on Windows is not supported at the moment.
 
-The minimum required tools are [uv](https://docs.astral.sh/uv/) and `git`. It can be installed either from UV's webpage or from your package manager. On Ubutu with:
+The minimum required tools are [uv](https://docs.astral.sh/uv/) and `git`. It can be installed either from UV's webpage or from your package manager. On Ubuntu with:
 ```
 apt install uv
 ```
@@ -22,20 +22,20 @@ and on MacOS with Brew:
 brew install uv
 ```
 
-The project also make use of `just` and `cmake` as native dependencies, they are part of the UV venv but they can also be installed on the host with the package manager (apt or brew)
+The project also makes use of `just` and `cmake` as native dependencies, they are part of the UV venv but they can also be installed on the host with the package manager (apt or brew)
 
 ## Entering build environment
 
-Zephyr is built with `west` which is a python tools and is using a lot of python dependencies. Hence it is advised to work in a python venv.
+Zephyr is built with `west` which is a Python tool and uses many Python dependencies. Hence it is advised to work in a python venv.
 
-To setup the venv and install build dependencies:
+To set up the venv and install build dependencies:
 ``` bash
 uv venv
 source ./.venv/bin/activate
 uv pip install .
 ```
 
-Each subsequent times, to enter the Venv, to work with the project:
+Each subsequent time, to enter the venv to work with the project:
 ``` bash
 source ./.venv/bin/activate
 ```
@@ -56,7 +56,7 @@ Before being able to build the project, Zephyr and its python dependencies must
 just fetch-zephyr
 ```
 
-### Builing, flashing
+### Building, flashing
 
 To build the firmware:
 ```bash

docs/building-and-flashing/flash.md

@@ -28,12 +28,12 @@ You may get an error message in your file browser as the Crazyradio 2.0 exited t
 Note: if you enter bootloader mode again the current firmware will always be named `CURRENT.UF2`, regardless of the
 name of the file you dropped when flashing.
 
-## Flasing with USB serial port
+## Flashing with USB serial port
 
 The bootloader also contains a (CDC) USB serial port interface. This allows to flash the firmware from command line
 or from a script which might be helpful during development.
 
-Fashing using the serial port interface requires the `adafruit-nrfutil` command line tool. This tool can be installed
+Flashing using the serial port interface requires the `adafruit-nrfutil` command line tool. This tool can be installed
 with `pip install adafruit-nrfutil`.
 
 Then, from within the firmware build folder, a package can be generated and flashed:

docs/development/cortex-debug.md

@@ -1,6 +1,6 @@
 ---
 title: Cortex debugging
-page_id: coretex_debugging
+page_id: cortex_debugging
 ---
 
 For VS code, follow the prerequisites of the [Crazyflie's STM debugging instructions](https://www.bitcraze.io/documentation/repository/crazyflie-firmware/master/development/openocd_gdb_debugging/).

docs/functional-areas/CBOR-RPC.md

@@ -1,6 +1,6 @@
 ---
 title: Crazyradio 2.0 CBOR RPC specification
-page_id: cbor_rpc_secification
+page_id: cbor_rpc_specification
 ---
 
 ## Abstract
@@ -18,7 +18,7 @@ The protocol defines 3 messages types:
  - Response
  - Notification
 
-Request and responses are used for procedure call. They both contains a message ID that allows to match a response with
+Request and responses are used for procedure calls. They both contain a message ID that allows to match a response with
 the corresponding response. Notifications are sent and received without any message ID, they are identified by a
 method name.
 
@@ -37,7 +37,7 @@ Methods name and errors starting with ".well-known" are reserved for the protoco
 
  - **type**: Unsigned integer of value 0 to denote a request
  - **msgid**: Unsigned integer of up to 64Bits precision. The *Response* message from the server will have the same *msgid*.
- - **method**: String representing or index the method to call
+ - **method**: String or index representing the method to call
  - **params**: Any CBOR element
 
 ### Response message
@@ -53,7 +53,7 @@ Methods name and errors starting with ".well-known" are reserved for the protoco
 
     [Type (2), method, param]
 
- - **type**: Unsigned integer of value 0 to denote a request
+ - **type**: Unsigned integer of value 2 to denote a notification
  - **method**: String or index representing the method that initiated or will receive the notification.
  - **params**: Any CBOR element
 
@@ -63,24 +63,24 @@ If a method is not found, the server answer with:
 
     [type (1), msgid, "well-known.NotFound", Null]
 
-This is a special case to indicate that the method does not exists.
+This is a special case to indicate that the method does not exist.
 
 ## Listing methods
 
 A special method exists to list the supported methods of a server:
 
-    [type (0), msgid, "well-known.methods, None]
+    [type (0), msgid, "well-known.methods", None]
 
 The response result contains a CBOR Map with as key string of the method name and as value an unsigned integer that can be
 used as method index.
 
 ## Method name compression
 
 Since the intention of the protocol is to be used in a context where the list of method is static, methods can be called
-by index instead of by name. This improves a lot the efficiently since it can instantly select the method on the server
+by index instead of by name. This greatly improves efficiency since it can instantly select the method on the server
 side instead of using a look-up table.
 
-The [method listing procedure](#listing-methods) returns the list of all the methods associated with there index, the
+The [method listing procedure](#listing-methods) returns the list of all the methods associated with their index, the
 index can then be used instead of the method name in Request and Notifications.
 
 [CBOR]: https://cbor.io/

docs/functional-areas/usb-api.md

@@ -23,7 +23,7 @@ Never returns an error and does not check the params.
 
 ## Radio mode switch
 
-Crazyradio 2.0 implement exclusives radio mode: only one mode can be enabled at
+Crazyradio 2.0 implements exclusive radio modes: only one mode can be enabled at
 any one time. The radioMode module is responsible for managing the modes.
 
 The currently supported modes are:
@@ -67,7 +67,7 @@ Can return the following error:
 ## ESB radio
 
 The "Enhanced ShortBurst" radio module implements a radio protocol compatible
-with the nRF24 line of radio tranceiver from Nordic semiconductor. The
+with the nRF24 line of radio transceivers from Nordic Semiconductor. The
 implementation only handles the PRX mode of ESB. This protocol is used to
 communicate with the Crazyradio 2.x bootloader as well as its firmware.
 
@@ -80,19 +80,19 @@ Send a packet, wait for the ack and returns the status and payload of the ack.
 
 Parameters:
  - **channel**: Radio channel to send/receive the packet to/from. Must be between 0 and 100. Channel 0 corresponds to 2400MHz and 100 to 2500MHz.
- - **address**: ESB link address as a byte string. The lenght of the address must be 5 bytes.
+ - **address**: ESB link address as a byte string. The length of the address must be 5 bytes.
  - **Payload**: Payload as a byte string. Length of the payload can be from 0 to 32 bytes.
 
 Result:
- - **acked**: True if an acknoledgement packet has been received.
- - **ackPayload**: Payload received in the ack packer, as a byte string.
+ - **acked**: True if an acknowledgement packet has been received.
+ - **ackPayload**: Payload received in the ack packet, as a byte string.
  - **rssi**: Receive power as a positive integer. 25 means -25dBm. Valid range from the measurement is -90 to -20 dBm (values from 20 to 90).
 
 Can return the following errors:
  - `"NotInitialized"`: ESB module not enabled in the [radio mode](#radio-mode-switch) module.
  - `"BadRequest"`: Wrong format of the request param. This includes wrong CBOR format as well as the following condition:
     - Channel is not between 0 and 100 inclusive
-    - Address is not 5 byte long
+    - Address is not 5 bytes long
     - Payload is more than 32 bytes long
 
 ## Continuous wave
@@ -128,7 +128,7 @@ Can return the following errors:
 
 ## Radio power measurement
 
-The `powerMeasurement` radio mode allows to measure the amount of radio power seen on one channe.
+The `powerMeasurement` radio mode allows measuring the amount of radio power seen on one channel.
 It needs to be enabled as a radio mode before being used.
 
 ### powerMeasurement.measure_channel
@@ -145,19 +145,19 @@ Result:
  - **rssi**: Receive power as reported by the radio hardware.
              Needs to be negated to get the rssi in dBm. 
              For example `48` represents `-48 dBm`.
-             The valid range of measurement is 20 to 90 (ie. -90 dBm to -20 bBm).
+             The valid range of measurement is 20 to 90 (i.e. -90 dBm to -20 dBm).
 
 Can return the following errors:
  - `"NotInitialized"`: powerMeasurement module not enabled in the [radio mode](#radio-mode-switch) module.
  - `"BadRequest"`: Wrong format of the request param. This includes wrong CBOR format as well as the following condition:
     - Channel is not between 0 and 100 inclusive
 
-**Known bugs**: Currently only one measurement can be carried. The radio mode has to be switched to `esb` and back to `powerMeasurement` in order to measure again otherwise a boggus value will be returned.
+**Known bugs**: Currently only one measurement can be carried out. The radio mode has to be switched to `esb` and back to `powerMeasurement` in order to measure again otherwise a bogus value will be returned.
 
 ## Led control
 
 The RGB LED state can be controlled from the USB API.
-The LED will also be controlled by the firmware so this is motly intended as a debug functinonality:
+The LED will also be controlled by the firmware so this is mostly intended as a debug functionality:
 depending of the radio state there is no guarantee the LED state set with this API will stay.
 
 ### led.set
@@ -177,7 +177,7 @@ Can return the following errors:
 
 ## Button control
 
-The button state can be read form the API.
+The button state can be read from the API.
 
 ### button.get
 

docs/functional-areas/usb-protocol.md

@@ -12,7 +12,7 @@ The interface has the following configuration in the USB descriptor:
 | bInterfaceSubClass | 0     |                       |
 | bInterfaceProtocol | 0     |                       |
 
-Note that there migh be more interface on the Crazyradio 2.0 so address of the enpoints should not be assumed,
+Note that there might be more interfaces on the Crazyradio 2.0 so addresses of the endpoints should not be assumed,
 they should be fetched from the descriptor.
 
 At low level the USB protocol is handled by one OUT and one IN endpoint.
@@ -29,7 +29,7 @@ The application packets are not necessarily aligned on USB packets (though they
 ## Protocol version
 
 The protocol, as described in this document, is the protocol version **0**.
-The version can be checked using the followind control transfer:
+The version can be checked using the following control transfer:
 
 | Field         | Value | Note                                    |
 |---------------|-------|-----------------------------------------|
@@ -54,7 +54,7 @@ Packets are transmitted one after each-other. First the size and then the data b
 
 If the stream does not fit in one 64 Bytes USB packet it continues in a subsequent packets.
 A non-full USB packet is only allowed at the end of a packet.
-The packet followind a non-full (less than 64 bytes long) packet must start with the length field of a new packet.
+The packet following a non-full (less than 64 bytes long) packet must start with the length field of a new packet.
 
 The Crazyradio will always send a non-full USB packet at the end of a stream. If the stream fits precisely in 64 bytes
 packets, an empty packet is sent after it.
@@ -66,6 +66,6 @@ stream to make sure the first bytes sent will be interpreted by the Crazyradio a
 a 0-length USB packet on the OUT endpoint. This should be done first by a USB driver before sending any application
 packets.
 
-The IN endpoint can be reset by receiving USB packet with a short timeout until either a timeout occures or a non-full
-packet (with a lenght bellow 64 bytes) is received. This guarantees that the next received USB packet will be
+The IN endpoint can be reset by receiving USB packets with a short timeout until either a timeout occurs or a non-full
+packet (with a length below 64 bytes) is received. This guarantees that the next received USB packet will be
 aligned with the length field.

justfile

@@ -35,7 +35,7 @@ fetch-python-dep:
 build:
     west build -b crazyradio2
 
-# Flash and resets Crazyradio to firmware mode using probe-rs
+# Flash and reset Crazyradio to firmware mode using probe-rs
 flash:
     west flash
     sleep 2

src/esb.c

@@ -255,7 +255,7 @@ bool esb_send_packet(struct esbPacket_s *packet, struct esbPacket_s * ack, uint8
     static int lossCounter = 0;
     static int ackLossCounter = 0;
 
-    // Drop packet ocasionally
+    // Drop packet occasionally
     if (CONFIG_ESB_PACKET_LOSS_PERCENT != 0 && (sys_rand32_get() % 100) < CONFIG_ESB_PACKET_LOSS_PERCENT) {
         lossCounter = 0;
 
@@ -306,7 +306,7 @@ bool esb_send_packet(struct esbPacket_s *packet, struct esbPacket_s * ack, uint8
         *rssi = nrf_radio_rssi_sample_get(NRF_RADIO);
         *retry = arc_counter - 1;
 
-        // Drop ack packet ocasionally
+        // Drop ack packet occasionally
         if (CONFIG_ESB_ACK_LOSS_PERCENT != 0 && (sys_rand32_get() % 100) < CONFIG_ESB_ACK_LOSS_PERCENT) {
             ackLossCounter = 0;
             k_mutex_unlock(&radio_busy);

src/esb.h

@@ -55,7 +55,7 @@ void esb_set_arc(int value);
 
 /**
  * @brief Set if an ack will be received or not
- * @param enabled True to receive an ack after sending a packer. False to just send.
+ * @param enabled True to receive an ack after sending a packet. False to just send.
  * 
  * Setting ack_enabled to false is usually done to send broadcast packets
  */
@@ -86,15 +86,15 @@ struct esbPacket_s {
 } __attribute__((packed));
 
 /**
- * Send a packet and wait for and received an acknoledgement
+ * Send a packet and wait for and receive an acknowledgement
  * 
  * @param packet ESB packet to send
  * @param ack Structure that will be filled up with the ESB ack packet
  * @param rssi Pointer to a u8 that will be filled up with the ACK RSSI
- * @param retry Number of retry required to received an ack
+ * @param retry Number of retries required to receive an ack
  * 
  * @return true if an ack has been properly received, false otherwise. the parameters
- *         ack and rssi are only filled up if an ack has been recievde.
+ *         ack and rssi are only filled up if an ack has been received.
  * 
  * @note This function will always return false if ack_enabled has been set to false.
 */

src/main.c

@@ -62,14 +62,14 @@ int main(void)
 	fem_init();
 
 	// Test the FEM
-	printk("Enaabling TX\n");
+	printk("Enabling TX\n");
 	fem_txen_set(true);
 	k_sleep(K_MSEC(10));
 	bool enabled = fem_is_pa_enabled();
 	printk("PA enabled: %d\n", enabled);
 	fem_txen_set(false);
 
-	printk("Enaabling RX\n");
+	printk("Enabling RX\n");
 	fem_rxen_set(true);
 	k_sleep(K_MSEC(10));
 	enabled = fem_is_lna_enabled();