Tidying

src/Application.cpp

@@ -426,7 +426,7 @@ namespace Bloom
         >();
 
         if (!tcStateChangeEvent.has_value() || tcStateChangeEvent->get()->getState() != ThreadState::READY) {
-            throw Exception("TargetController failed to startup.");
+            throw Exception("TargetController failed to start up");
         }
     }
 
@@ -465,7 +465,7 @@ namespace Bloom
         >();
 
         if (!dsStateChangeEvent.has_value() || dsStateChangeEvent->get()->getState() != ThreadState::READY) {
-            throw Exception("DebugServer failed to startup.");
+            throw Exception("DebugServer failed to start up");
         }
     }
 

src/Application.hpp

@@ -28,7 +28,7 @@ namespace Bloom
      * Bloom - a debug interface for embedded systems development on Linux.
      *
      * This is the main entry-point of execution for the Bloom program. The methods within will run on the main
-     * thread. If Insight is enabled, execution will be passed over to Insight::run() upon startup.
+     * thread. If Insight is enabled, execution will be passed over to Insight::run() upon start up.
      */
     class Application: public Thread
     {

src/DebugServer/README.md

@@ -10,7 +10,7 @@ connected AVR target, by implementing the
 [GDB Remote Serial Protocol](https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html), over a TCP/IP connection.
 Each server must implement the interface defined in the [`ServerInterface` class](./ServerInterface.hpp).
 
-At startup, the DebugServer will select the appropriate server implementation, based on the user's project 
+At start up, the DebugServer will select the appropriate server implementation, based on the user's project
 configuration (bloom.yaml - see [`DebugServerConfig`](../ProjectConfig.hpp)). Each server implementation is mapped to a 
 config name, which is to be used in the project configuration file. For the mapping, see 
 `DebugServerComponent::getAvailableServersByName()`. After initialising the server (via `ServerInterface::init()`), 
@@ -19,7 +19,7 @@ For more on this, see `DebugServerComponent::startup()` and `DebugServerComponen
 
 #### Servicing events
 
-During startup, the DebugServer will register event handlers for certain events. Once control of the DebugServer thread
+During star tup, the DebugServer will register event handlers for certain events. Once control of the DebugServer thread
 has been handed over to the selected server implementation, the server must ensure that any incoming events are 
 processed ASAP. How this is done is implementation-defined. A reference to the DebugServer's event listener 
 (`DebugServerComponent::eventListener`) can be passed to the server if need be (see 

src/DebugServer/ServerInterface.hpp

@@ -22,7 +22,7 @@ namespace Bloom::DebugServer
         [[nodiscard]] virtual std::string getName() const = 0;
 
         /**
-         * Called on startup of the DebugServerComponent. The server should implement any initialisation work here.
+         * Called on start up of the DebugServerComponent. The server should implement any initialisation work here.
          */
         virtual void init() = 0;
 

src/DebugToolDrivers/USB/HID/hidapi.hpp

@@ -33,7 +33,7 @@ struct hid_device_
     pthread_t thread;
     pthread_mutex_t mutex; // Protects input_reports
     pthread_cond_t condition;
-    pthread_barrier_t barrier; // Ensures correct startup sequence
+    pthread_barrier_t barrier; // Ensures correct start up sequence
     int shutdown_thread;
     int cancelled;
     struct libusb_transfer* transfer;

src/ProjectConfig.hpp

@@ -14,7 +14,7 @@ namespace Bloom
      * multiple debug environments, each environment must be assigned a unique name that can be used to identify the
      * environment. This is why the 'environments' parameter is a YAML map, with the key being the environment name.
      *
-     * On application startup, we extract the config from this YAML file and generate a ProjectConfig object.
+     * On application start up, we extract the config from this YAML file and generate a ProjectConfig object.
      * See Application::loadProjectConfiguration() for more on this.
      *
      * Some config parameters are specific to certain entities within Bloom, but have no significance across the
@@ -56,7 +56,7 @@ namespace Bloom
         /**
          * The name of the selected target variant.
          *
-         * Insight uses this to determine which variant to select on startup.
+         * Insight uses this to determine which variant to select on start up.
          */
         std::optional<std::string> variantName;
 

src/TargetController/TargetControllerComponent.cpp

@@ -95,7 +95,7 @@ namespace Bloom::TargetController
             }
 
         } catch (const TargetControllerStartupFailure& exception) {
-            Logger::error("TargetController failed to startup. See below for errors:");
+            Logger::error("TargetController failed to start up. See below for errors:");
             Logger::error(exception.getMessage());
 
         } catch (const Exception& exception) {

src/TargetController/TargetControllerComponent.hpp

@@ -108,7 +108,7 @@ namespace Bloom::TargetController
         static inline std::condition_variable responsesByCommandIdCv = std::condition_variable();
 
         /**
-         * The TC starts off in a suspended state. TargetControllerComponent::resume() is invoked from the startup
+         * The TC starts off in a suspended state. TargetControllerComponent::resume() is invoked from the start up
          * routine.
          */
         TargetControllerState state = TargetControllerState::SUSPENDED;

src/Targets/Target.hpp

@@ -129,7 +129,7 @@ namespace Bloom::Targets
          *
          * When a user is debugging an AVR8 target, they may not specify the exact name of the target in their project
          * configuration file. Instead, they may select the generic 'avr8' target (which maps to the generic Avr8 target
-         * class). In cases like this, the data we have on the target, at the point of startup, is very limited; all we
+         * class). In cases like this, the data we have on the target, at the point of start up, is very limited; all we
          * know about the target is that it's part of the AVR8 family. Nothing else. But this is ok, because, when we
          * begin the target configuration and activation process, we are able to learn a lot more about the target.
          * For AVR8 targets, we extract the target signature shortly after activation, and with that signature we find