Updated invalid code references that were still using the old Bloom namespace.

This commit is contained in:
Nav
2023-08-20 15:50:05 +01:00
parent 579b9a1f28
commit 9faab27ad7
2 changed files with 10 additions and 10 deletions

View File

@@ -27,14 +27,14 @@ appropriate address in program memory. The GDB server will action this command,
success or failure.
Commands and responses are delivered in packets. The
[`Bloom::DebugServer::Gdb::CommandPackets::CommandPacket`](./CommandPackets/CommandPacket.hpp) and
[`Bloom::DebugServer::Gdb::ResponsePackets::ResponsePacket`](./ResponsePackets/ResponsePacket.hpp) classes are base
[`DebugServer::Gdb::CommandPackets::CommandPacket`](./CommandPackets/CommandPacket.hpp) and
[`DebugServer::Gdb::ResponsePackets::ResponsePacket`](./ResponsePackets/ResponsePacket.hpp) classes are base
classes for these packets. For most GDB commands supported by this server implementation, there is a specific command
packet class that can be found in [/src/DebugServer/Gdb/CommandPackets](./CommandPackets). When the server receives a
command packet from the GDB client, the appropriate (`CommandPacket` derived) object is constructed, which encapsulates
all of the relevant information for the particular command.
Consider the [`Bloom::DebugServer::Gdb::CommandPackets::SetBreakpoint`](./CommandPackets/SetBreakpoint.hpp) command
Consider the [`DebugServer::Gdb::CommandPackets::SetBreakpoint`](./CommandPackets/SetBreakpoint.hpp) command
packet class:
```c++
@@ -119,8 +119,8 @@ functionality to be implemented in derived classes.
#### GDB target descriptor
The [`Bloom::DebugServer::Gdb::TargetDescriptor`](./TargetDescriptor.hpp) abstract class provides access to any
The [`DebugServer::Gdb::TargetDescriptor`](./TargetDescriptor.hpp) abstract class provides access to any
information that is specific to the target architecture and GDB. For example, the register mapping described above, for
AVR targets, is implemented in [`Bloom::DebugServer::Gdb::AvrGdb::TargetDescriptor`](./AvrGdb/TargetDescriptor.hpp).
AVR targets, is implemented in [`DebugServer::Gdb::AvrGdb::TargetDescriptor`](./AvrGdb/TargetDescriptor.hpp).
That class is derived from the abstract `TargetDescriptor` class. It implements the AVR specific concepts that the
server is expected to be aware of.

View File

@@ -13,20 +13,20 @@ the TargetController, and wait for a response. The TargetController will action
response.
All TargetController commands can be found in [src/TargetController/Commands](./Commands), and are derived from the
[`Bloom::TargetController::Commands::Command`](./Commands/Command.hpp) base class. Responses can be found in
[`TargetController::Commands::Command`](./Commands/Command.hpp) base class. Responses can be found in
[src/TargetController/Responses](./Responses), and are derived from the
[`Bloom::TargetController::Responses::Response`](./Responses/Response.hpp) base class.
[`TargetController::Responses::Response`](./Responses/Response.hpp) base class.
**NOTE:** Components within Bloom do not typically concern themselves with the TargetController command-response
mechanism. Instead, they use the `TargetControllerService` class, which encapsulates the command-response mechanism and
provides a simplified means for interaction with the connected hardware. For more, see
[The TargetControllerService class](#the-TargetControllerService-class) section below.
Commands can be sent to the TargetController via the [`Bloom::TargetController::CommandManager`](./CommandManager.hpp)
Commands can be sent to the TargetController via the [`TargetController::CommandManager`](./CommandManager.hpp)
class.
For example, to read memory from the connected target, we would send the
[`Bloom::TargetController::Commands::ReadTargetMemory`](./Commands/ReadTargetMemory.hpp) command:
[`TargetController::Commands::ReadTargetMemory`](./Commands/ReadTargetMemory.hpp) command:
```c++
auto tcCommandManager = TargetController::CommandManager();
@@ -86,7 +86,7 @@ The `TargetControllerService` class does not require any dependencies at constru
different threads and used freely to gain access to the connected hardware, from any component within Bloom.
All components within Bloom should use the `TargetControllerService` class to interact with the connected hardware. They
**should not** directly issue commands via the `Bloom::TargetController::CommandManager`, unless there is a very good
**should not** directly issue commands via the `TargetController::CommandManager`, unless there is a very good
reason to do so.
##### Atomic sessions with the TargetControllerService