2020-12-26 14:12:05 -08:00
|
|
|
// Copyright (c) FIRST and other WPILib contributors.
|
|
|
|
|
// Open Source Software; you can modify and/or share it under the terms of
|
|
|
|
|
// the WPILib BSD license file in the root directory of this project.
|
2016-05-25 20:23:37 -07:00
|
|
|
|
2025-11-07 19:56:21 -05:00
|
|
|
#include "wpi/hal/DriverStation.h"
|
2017-08-18 21:35:53 -07:00
|
|
|
|
2017-08-19 23:12:24 -07:00
|
|
|
#ifdef __APPLE__
|
|
|
|
|
#include <pthread.h>
|
|
|
|
|
#endif
|
|
|
|
|
|
2022-11-30 02:19:15 -05:00
|
|
|
#include <atomic>
|
2017-08-19 22:56:39 -07:00
|
|
|
#include <cstdio>
|
|
|
|
|
#include <cstdlib>
|
2017-11-01 21:58:44 -07:00
|
|
|
#include <cstring>
|
2017-08-19 22:56:39 -07:00
|
|
|
#include <string>
|
|
|
|
|
|
2021-06-06 16:13:58 -07:00
|
|
|
#include <fmt/format.h>
|
2017-11-13 09:51:48 -08:00
|
|
|
|
2026-01-04 00:41:53 -08:00
|
|
|
#include "HALInitializer.hpp"
|
|
|
|
|
#include "mockdata/DriverStationDataInternal.hpp"
|
2025-12-12 21:25:57 -07:00
|
|
|
#include "wpi/hal/DriverStationTypes.h"
|
2025-11-07 19:56:21 -05:00
|
|
|
#include "wpi/hal/Errors.h"
|
2026-06-06 12:15:17 -07:00
|
|
|
#include "wpi/hal/cpp/MrcLibDs.hpp"
|
2026-03-15 15:08:41 -07:00
|
|
|
#include "wpi/hal/monotonic_clock.hpp"
|
2025-11-07 19:56:21 -05:00
|
|
|
#include "wpi/hal/simulation/MockHooks.h"
|
2025-11-07 19:57:55 -05:00
|
|
|
#include "wpi/util/EventVector.hpp"
|
|
|
|
|
#include "wpi/util/mutex.hpp"
|
2026-06-06 12:15:17 -07:00
|
|
|
#include "wpi/util/string.hpp"
|
2016-07-17 19:42:33 -07:00
|
|
|
|
2025-11-07 20:00:05 -05:00
|
|
|
using namespace wpi::hal;
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
|
|
|
|
|
static constexpr int kJoystickPorts = 6;
|
|
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
struct JoystickDataCache {
|
|
|
|
|
JoystickDataCache() { std::memset(this, 0, sizeof(*this)); }
|
|
|
|
|
void Update();
|
|
|
|
|
|
|
|
|
|
HAL_JoystickAxes axes[kJoystickPorts];
|
|
|
|
|
HAL_JoystickPOVs povs[kJoystickPorts];
|
|
|
|
|
HAL_JoystickButtons buttons[kJoystickPorts];
|
2025-11-21 13:57:11 -08:00
|
|
|
HAL_JoystickTouchpads touchpads[kJoystickPorts];
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
HAL_AllianceStationID allianceStation;
|
|
|
|
|
double matchTime;
|
2024-02-18 14:30:40 -08:00
|
|
|
HAL_ControlWord controlWord;
|
2026-02-06 21:38:15 -08:00
|
|
|
HAL_GameData gameData;
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
};
|
|
|
|
|
static_assert(std::is_standard_layout_v<JoystickDataCache>);
|
|
|
|
|
// static_assert(std::is_trivial_v<JoystickDataCache>);
|
|
|
|
|
|
|
|
|
|
static std::atomic_bool gShutdown{false};
|
|
|
|
|
} // namespace
|
|
|
|
|
|
|
|
|
|
void JoystickDataCache::Update() {
|
|
|
|
|
for (int i = 0; i < kJoystickPorts; i++) {
|
|
|
|
|
SimDriverStationData->GetJoystickAxes(i, &axes[i]);
|
|
|
|
|
SimDriverStationData->GetJoystickPOVs(i, &povs[i]);
|
|
|
|
|
SimDriverStationData->GetJoystickButtons(i, &buttons[i]);
|
2025-11-21 13:57:11 -08:00
|
|
|
SimDriverStationData->GetJoystickTouchpads(i, &touchpads[i]);
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
}
|
|
|
|
|
allianceStation = SimDriverStationData->allianceStationId;
|
|
|
|
|
matchTime = SimDriverStationData->matchTime;
|
2024-02-18 14:30:40 -08:00
|
|
|
|
2025-12-12 21:25:57 -07:00
|
|
|
controlWord = HAL_MakeControlWord(
|
|
|
|
|
SimDriverStationData->opMode, SimDriverStationData->robotMode,
|
|
|
|
|
SimDriverStationData->enabled, SimDriverStationData->eStop,
|
|
|
|
|
SimDriverStationData->fmsAttached, SimDriverStationData->dsAttached);
|
2026-02-06 21:38:15 -08:00
|
|
|
SimDriverStationData->GetGameData(&gameData);
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#define CHECK_JOYSTICK_NUMBER(stickNum) \
|
2026-03-13 01:04:29 -07:00
|
|
|
if ((stickNum) < 0 || (stickNum) >= HAL_MAX_JOYSTICKS) \
|
2026-04-19 16:12:18 -07:00
|
|
|
return HAL_PARAMETER_OUT_OF_RANGE;
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
|
2024-11-19 04:56:32 +00:00
|
|
|
namespace {
|
|
|
|
|
struct TcpCache {
|
|
|
|
|
TcpCache() { std::memset(this, 0, sizeof(*this)); }
|
|
|
|
|
void Update();
|
|
|
|
|
void CloneTo(TcpCache* other) { std::memcpy(other, this, sizeof(*this)); }
|
|
|
|
|
|
|
|
|
|
HAL_MatchInfo matchInfo;
|
2026-03-13 01:04:29 -07:00
|
|
|
HAL_JoystickDescriptor descriptors[HAL_MAX_JOYSTICKS];
|
2024-11-19 04:56:32 +00:00
|
|
|
};
|
|
|
|
|
static_assert(std::is_standard_layout_v<TcpCache>);
|
|
|
|
|
} // namespace
|
|
|
|
|
|
|
|
|
|
void TcpCache::Update() {
|
|
|
|
|
SimDriverStationData->GetMatchInfo(&matchInfo);
|
|
|
|
|
|
2026-03-13 01:04:29 -07:00
|
|
|
for (int i = 0; i < HAL_MAX_JOYSTICKS; i++) {
|
2024-11-19 04:56:32 +00:00
|
|
|
SimDriverStationData->GetJoystickDescriptor(i, &descriptors[i]);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
class MrcLibDsSimImpl : public MrcLibDs {
|
|
|
|
|
public:
|
|
|
|
|
MrcLibDsSimImpl();
|
|
|
|
|
~MrcLibDsSimImpl() override { gShutdown = true; }
|
|
|
|
|
int32_t sendError(bool isError, int32_t errorCode,
|
|
|
|
|
const struct WPI_String* details,
|
|
|
|
|
const struct WPI_String* location,
|
|
|
|
|
const struct WPI_String* callStack, bool printMsg) override;
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t sendConsoleLine(const struct WPI_String* line) override;
|
2017-12-10 19:38:53 -08:00
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t sendProgramCrash(const struct WPI_String* details,
|
|
|
|
|
const struct WPI_String* location,
|
|
|
|
|
const struct WPI_String* callStack) override;
|
|
|
|
|
|
|
|
|
|
int32_t getControlWord(HAL_ControlWord* controlWord) override;
|
|
|
|
|
|
|
|
|
|
int32_t getUncachedControlWord(HAL_ControlWord* controlWord) override;
|
|
|
|
|
|
|
|
|
|
int32_t setOpModeOptions(const struct HAL_OpModeOption* options,
|
|
|
|
|
int32_t count) override;
|
|
|
|
|
|
|
|
|
|
int32_t getAllianceStation(HAL_AllianceStationID* allianceStation) override;
|
|
|
|
|
|
|
|
|
|
int32_t getJoystickAxes(int32_t joystickNum, HAL_JoystickAxes* axes) override;
|
|
|
|
|
|
|
|
|
|
int32_t getJoystickPOVs(int32_t joystickNum, HAL_JoystickPOVs* povs) override;
|
|
|
|
|
|
|
|
|
|
int32_t getJoystickButtons(int32_t joystickNum,
|
|
|
|
|
HAL_JoystickButtons* buttons) override;
|
|
|
|
|
|
|
|
|
|
int32_t getJoystickTouchpads(int32_t joystickNum,
|
|
|
|
|
HAL_JoystickTouchpads* touchpads) override;
|
|
|
|
|
|
|
|
|
|
int32_t getAllJoystickData(int32_t joystickNum, HAL_JoystickAxes* axes,
|
|
|
|
|
HAL_JoystickPOVs* povs,
|
|
|
|
|
HAL_JoystickButtons* buttons,
|
|
|
|
|
HAL_JoystickTouchpads* touchpads) override;
|
|
|
|
|
|
|
|
|
|
int32_t getJoystickDescriptor(int32_t joystickNum,
|
|
|
|
|
HAL_JoystickDescriptor* desc) override;
|
|
|
|
|
|
|
|
|
|
int32_t getGameData(HAL_GameData* gameData) override;
|
|
|
|
|
|
|
|
|
|
int32_t setJoystickRumble(int32_t joystickNum, int32_t leftRumble,
|
|
|
|
|
int32_t rightRumble, int32_t leftTriggerRumble,
|
|
|
|
|
int32_t rightTriggerRumble) override;
|
|
|
|
|
|
|
|
|
|
int32_t setJoystickLeds(int32_t joystickNum, int32_t leds) override;
|
|
|
|
|
|
|
|
|
|
int32_t getMatchTime(double* matchTime) override;
|
|
|
|
|
|
|
|
|
|
int32_t getMatchInfo(HAL_MatchInfo* info) override;
|
|
|
|
|
|
|
|
|
|
int32_t getOutputsEnabled(bool* outputsEnabled) override;
|
|
|
|
|
|
|
|
|
|
int32_t refreshDSData(bool* wasRefreshed) override;
|
|
|
|
|
|
|
|
|
|
void provideNewDataEventHandle(WPI_EventHandle handle) override;
|
|
|
|
|
|
|
|
|
|
void removeNewDataEventHandle(WPI_EventHandle handle) override;
|
|
|
|
|
|
|
|
|
|
int32_t observeUserProgramStarting() override;
|
|
|
|
|
|
|
|
|
|
int32_t observeUserProgram(HAL_ControlWord controlWord) override;
|
|
|
|
|
|
|
|
|
|
int32_t getSystemTimeValid(bool* systemTimeValid) override;
|
|
|
|
|
|
|
|
|
|
wpi::util::EventVector newDataEvents;
|
|
|
|
|
|
|
|
|
|
void NewDriverStationData();
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
int32_t BackendPrintFunctionImpl(bool isError, int32_t errorCode,
|
|
|
|
|
const struct WPI_String* details,
|
|
|
|
|
const struct WPI_String* location,
|
|
|
|
|
const struct WPI_String* callStack,
|
|
|
|
|
bool* forcePrintMsg);
|
|
|
|
|
wpi::util::mutex cacheMutex;
|
|
|
|
|
wpi::util::mutex tcpCacheMutex;
|
|
|
|
|
|
|
|
|
|
BackendPrintFunction backendPrintFunc;
|
|
|
|
|
|
|
|
|
|
HAL_ControlWord newestControlWord;
|
|
|
|
|
JoystickDataCache caches[3];
|
|
|
|
|
JoystickDataCache* currentRead = &caches[0];
|
|
|
|
|
JoystickDataCache* currentReadLocal = &caches[0];
|
|
|
|
|
std::atomic<JoystickDataCache*> currentCache{nullptr};
|
|
|
|
|
JoystickDataCache* lastGiven = &caches[1];
|
|
|
|
|
JoystickDataCache* cacheToUpdate = &caches[2];
|
|
|
|
|
|
|
|
|
|
TcpCache tcpCache;
|
|
|
|
|
TcpCache tcpCurrent;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
MrcLibDsSimImpl::MrcLibDsSimImpl() {
|
|
|
|
|
newestControlWord.value = 0;
|
|
|
|
|
backendPrintFunc =
|
|
|
|
|
[this](bool isError, int32_t errorCode, const struct WPI_String* details,
|
|
|
|
|
const struct WPI_String* location,
|
|
|
|
|
const struct WPI_String* callStack, bool* forcePrintMsg) {
|
|
|
|
|
return BackendPrintFunctionImpl(isError, errorCode, details, location,
|
|
|
|
|
callStack, forcePrintMsg);
|
|
|
|
|
};
|
2022-11-30 02:19:15 -05:00
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
static std::atomic<HALSIM_SendErrorHandler> sendErrorHandler{nullptr};
|
|
|
|
|
static std::atomic<HALSIM_SendConsoleLineHandler> sendConsoleLineHandler{
|
|
|
|
|
nullptr};
|
2022-11-30 02:19:15 -05:00
|
|
|
|
2015-11-26 00:08:32 -08:00
|
|
|
extern "C" {
|
2019-07-23 23:55:51 -07:00
|
|
|
|
|
|
|
|
void HALSIM_SetSendError(HALSIM_SendErrorHandler handler) {
|
|
|
|
|
sendErrorHandler.store(handler);
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-18 20:44:40 -08:00
|
|
|
void HALSIM_SetSendConsoleLine(HALSIM_SendConsoleLineHandler handler) {
|
|
|
|
|
sendConsoleLineHandler.store(handler);
|
|
|
|
|
}
|
2026-06-06 12:15:17 -07:00
|
|
|
} // extern "C"
|
|
|
|
|
|
|
|
|
|
int32_t MrcLibDsSimImpl::BackendPrintFunctionImpl(
|
|
|
|
|
bool isError, int32_t errorCode, const struct WPI_String* details,
|
|
|
|
|
const struct WPI_String* location, const struct WPI_String* callStack,
|
|
|
|
|
bool* forcePrintMsg) {
|
|
|
|
|
// This will defer to the caller, which needs to force print to true.
|
|
|
|
|
*forcePrintMsg = true;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2020-02-18 20:44:40 -08:00
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::sendError(bool isError, int32_t errorCode,
|
|
|
|
|
const struct WPI_String* details,
|
|
|
|
|
const struct WPI_String* location,
|
|
|
|
|
const struct WPI_String* callStack,
|
|
|
|
|
bool printMsg) {
|
2019-07-23 23:55:51 -07:00
|
|
|
auto errorHandler = sendErrorHandler.load();
|
2020-12-28 12:58:06 -08:00
|
|
|
if (errorHandler) {
|
2026-06-06 12:15:17 -07:00
|
|
|
return errorHandler(isError, errorCode, details, location, callStack,
|
|
|
|
|
printMsg);
|
2016-07-17 19:42:33 -07:00
|
|
|
}
|
2026-06-06 12:15:17 -07:00
|
|
|
return DefaultSendErrorImpl(isError, errorCode, details, location, callStack,
|
|
|
|
|
printMsg, backendPrintFunc);
|
2016-07-17 19:42:33 -07:00
|
|
|
}
|
2015-11-26 00:08:32 -08:00
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::sendConsoleLine(const struct WPI_String* line) {
|
2020-02-18 20:44:40 -08:00
|
|
|
auto handler = sendConsoleLineHandler.load();
|
|
|
|
|
if (handler) {
|
|
|
|
|
return handler(line);
|
|
|
|
|
}
|
2026-06-06 12:15:17 -07:00
|
|
|
fmt::print("{}\n", wpi::util::to_string_view(line));
|
2021-06-06 16:13:58 -07:00
|
|
|
std::fflush(stdout);
|
2020-02-18 20:44:40 -08:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::sendProgramCrash(const struct WPI_String* details,
|
|
|
|
|
const struct WPI_String* location,
|
|
|
|
|
const struct WPI_String* callStack) {
|
|
|
|
|
fmt::print(stderr, "Program Crash: {}\nLocation: {}\nCall Stack:\n{}\n",
|
|
|
|
|
wpi::util::to_string_view(details),
|
|
|
|
|
wpi::util::to_string_view(location),
|
|
|
|
|
wpi::util::to_string_view(callStack));
|
|
|
|
|
std::fflush(stderr);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int32_t MrcLibDsSimImpl::getControlWord(HAL_ControlWord* controlWord) {
|
2022-10-23 21:59:04 -07:00
|
|
|
if (gShutdown) {
|
2025-12-12 21:25:57 -07:00
|
|
|
controlWord->value = 0;
|
2026-04-19 16:12:18 -07:00
|
|
|
return HAL_INCOMPATIBLE_STATE;
|
2022-10-23 21:59:04 -07:00
|
|
|
}
|
2026-06-06 12:15:17 -07:00
|
|
|
std::scoped_lock lock{cacheMutex};
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
*controlWord = newestControlWord;
|
2017-08-18 21:35:53 -07:00
|
|
|
return 0;
|
2015-08-19 11:12:54 -04:00
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::getUncachedControlWord(HAL_ControlWord* controlWord) {
|
2025-12-12 21:25:57 -07:00
|
|
|
if (gShutdown) {
|
|
|
|
|
controlWord->value = 0;
|
2026-04-19 16:12:18 -07:00
|
|
|
return HAL_INCOMPATIBLE_STATE;
|
2025-12-12 21:25:57 -07:00
|
|
|
}
|
|
|
|
|
bool dsAttached = SimDriverStationData->dsAttached;
|
|
|
|
|
if (dsAttached) {
|
|
|
|
|
*controlWord = HAL_MakeControlWord(
|
|
|
|
|
SimDriverStationData->opMode, SimDriverStationData->robotMode,
|
|
|
|
|
SimDriverStationData->enabled, SimDriverStationData->eStop,
|
|
|
|
|
SimDriverStationData->fmsAttached, SimDriverStationData->dsAttached);
|
|
|
|
|
} else {
|
|
|
|
|
controlWord->value = 0;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::setOpModeOptions(
|
|
|
|
|
const struct HAL_OpModeOption* options, int32_t count) {
|
2025-12-12 21:25:57 -07:00
|
|
|
if (gShutdown) {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
if (count < 0 || count > 1000 || (count != 0 && !options)) {
|
2026-04-19 16:12:18 -07:00
|
|
|
return HAL_PARAMETER_OUT_OF_RANGE;
|
2025-12-12 21:25:57 -07:00
|
|
|
}
|
2026-06-06 12:15:17 -07:00
|
|
|
if (count == 0) {
|
|
|
|
|
SimDriverStationData->SetOpModeOptions({});
|
|
|
|
|
} else {
|
|
|
|
|
SimDriverStationData->SetOpModeOptions({options, options + count});
|
|
|
|
|
}
|
2025-12-12 21:25:57 -07:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::getAllianceStation(
|
|
|
|
|
HAL_AllianceStationID* allianceStation) {
|
2022-10-23 21:59:04 -07:00
|
|
|
if (gShutdown) {
|
2026-06-06 12:15:17 -07:00
|
|
|
*allianceStation = HAL_ALLIANCE_STATION_UNKNOWN;
|
|
|
|
|
return HAL_INCOMPATIBLE_STATE;
|
2022-10-23 21:59:04 -07:00
|
|
|
}
|
2026-06-06 12:15:17 -07:00
|
|
|
std::scoped_lock lock{cacheMutex};
|
|
|
|
|
*allianceStation = currentRead->allianceStation;
|
|
|
|
|
return 0;
|
2015-08-19 11:12:54 -04:00
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::getJoystickAxes(int32_t joystickNum,
|
|
|
|
|
HAL_JoystickAxes* axes) {
|
2022-10-23 21:59:04 -07:00
|
|
|
if (gShutdown) {
|
2026-04-19 16:12:18 -07:00
|
|
|
return HAL_INCOMPATIBLE_STATE;
|
2022-10-23 21:59:04 -07:00
|
|
|
}
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
CHECK_JOYSTICK_NUMBER(joystickNum);
|
2026-06-06 12:15:17 -07:00
|
|
|
std::scoped_lock lock{cacheMutex};
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
*axes = currentRead->axes[joystickNum];
|
2017-08-18 21:35:53 -07:00
|
|
|
return 0;
|
2015-08-19 11:12:54 -04:00
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::getJoystickPOVs(int32_t joystickNum,
|
|
|
|
|
HAL_JoystickPOVs* povs) {
|
2022-10-23 21:59:04 -07:00
|
|
|
if (gShutdown) {
|
2026-04-19 16:12:18 -07:00
|
|
|
return HAL_INCOMPATIBLE_STATE;
|
2022-10-23 21:59:04 -07:00
|
|
|
}
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
CHECK_JOYSTICK_NUMBER(joystickNum);
|
2026-06-06 12:15:17 -07:00
|
|
|
std::scoped_lock lock{cacheMutex};
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
*povs = currentRead->povs[joystickNum];
|
2017-08-18 21:35:53 -07:00
|
|
|
return 0;
|
2015-08-19 11:12:54 -04:00
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::getJoystickButtons(int32_t joystickNum,
|
|
|
|
|
HAL_JoystickButtons* buttons) {
|
2022-10-23 21:59:04 -07:00
|
|
|
if (gShutdown) {
|
2026-04-19 16:12:18 -07:00
|
|
|
return HAL_INCOMPATIBLE_STATE;
|
2022-10-23 21:59:04 -07:00
|
|
|
}
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
CHECK_JOYSTICK_NUMBER(joystickNum);
|
2026-06-06 12:15:17 -07:00
|
|
|
std::scoped_lock lock{cacheMutex};
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
*buttons = currentRead->buttons[joystickNum];
|
2017-08-18 21:35:53 -07:00
|
|
|
return 0;
|
2015-08-19 11:12:54 -04:00
|
|
|
}
|
2018-05-31 20:47:15 -07:00
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::getJoystickTouchpads(
|
|
|
|
|
int32_t joystickNum, HAL_JoystickTouchpads* touchpads) {
|
2025-11-21 13:57:11 -08:00
|
|
|
if (gShutdown) {
|
2026-04-19 16:12:18 -07:00
|
|
|
return HAL_INCOMPATIBLE_STATE;
|
2025-11-21 13:57:11 -08:00
|
|
|
}
|
|
|
|
|
CHECK_JOYSTICK_NUMBER(joystickNum);
|
2026-06-06 12:15:17 -07:00
|
|
|
std::scoped_lock lock{cacheMutex};
|
2025-11-21 13:57:11 -08:00
|
|
|
*touchpads = currentRead->touchpads[joystickNum];
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::getAllJoystickData(int32_t joystickNum,
|
|
|
|
|
HAL_JoystickAxes* axes,
|
|
|
|
|
HAL_JoystickPOVs* povs,
|
|
|
|
|
HAL_JoystickButtons* buttons,
|
|
|
|
|
HAL_JoystickTouchpads* touchpads) {
|
2022-10-23 21:59:04 -07:00
|
|
|
if (gShutdown) {
|
2026-06-06 12:15:17 -07:00
|
|
|
return HAL_INCOMPATIBLE_STATE;
|
2022-10-23 21:59:04 -07:00
|
|
|
}
|
2026-06-06 12:15:17 -07:00
|
|
|
std::scoped_lock lock{cacheMutex};
|
2025-10-25 23:03:50 -07:00
|
|
|
*axes = currentRead->axes[joystickNum];
|
|
|
|
|
*povs = currentRead->povs[joystickNum];
|
|
|
|
|
*buttons = currentRead->buttons[joystickNum];
|
2025-11-21 13:57:11 -08:00
|
|
|
*touchpads = currentRead->touchpads[joystickNum];
|
2026-06-06 12:15:17 -07:00
|
|
|
return 0;
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::getJoystickDescriptor(int32_t joystickNum,
|
|
|
|
|
HAL_JoystickDescriptor* desc) {
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
CHECK_JOYSTICK_NUMBER(joystickNum);
|
2026-06-06 12:15:17 -07:00
|
|
|
std::scoped_lock lock{tcpCacheMutex};
|
2024-11-19 04:56:32 +00:00
|
|
|
*desc = tcpCurrent.descriptors[joystickNum];
|
2017-08-18 21:35:53 -07:00
|
|
|
return 0;
|
2016-05-20 17:30:37 -07:00
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::getGameData(HAL_GameData* gameData) {
|
2026-02-06 21:38:15 -08:00
|
|
|
if (gShutdown) {
|
2026-04-19 16:12:18 -07:00
|
|
|
return HAL_INCOMPATIBLE_STATE;
|
2026-02-06 21:38:15 -08:00
|
|
|
}
|
2026-06-06 12:15:17 -07:00
|
|
|
std::scoped_lock lock{cacheMutex};
|
2026-02-06 21:38:15 -08:00
|
|
|
*gameData = currentRead->gameData;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::setJoystickRumble(int32_t joystickNum,
|
|
|
|
|
int32_t leftRumble,
|
|
|
|
|
int32_t rightRumble,
|
|
|
|
|
int32_t leftTriggerRumble,
|
|
|
|
|
int32_t rightTriggerRumble) {
|
2025-11-17 14:36:14 -08:00
|
|
|
SimDriverStationData->SetJoystickRumbles(joystickNum, leftRumble, rightRumble,
|
|
|
|
|
leftTriggerRumble,
|
|
|
|
|
rightTriggerRumble);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::setJoystickLeds(int32_t joystickNum, int32_t leds) {
|
2025-11-17 14:36:14 -08:00
|
|
|
SimDriverStationData->SetJoystickLeds(joystickNum, leds);
|
2017-08-18 21:35:53 -07:00
|
|
|
return 0;
|
2016-05-20 17:30:37 -07:00
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::getMatchTime(double* matchTime) {
|
2022-10-23 21:59:04 -07:00
|
|
|
if (gShutdown) {
|
2026-06-06 12:15:17 -07:00
|
|
|
*matchTime = 0;
|
|
|
|
|
return HAL_INCOMPATIBLE_STATE;
|
2022-10-23 21:59:04 -07:00
|
|
|
}
|
2026-06-06 12:15:17 -07:00
|
|
|
std::scoped_lock lock{cacheMutex};
|
|
|
|
|
*matchTime = currentRead->matchTime;
|
|
|
|
|
return 0;
|
2016-05-20 17:30:37 -07:00
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::getMatchInfo(HAL_MatchInfo* info) {
|
|
|
|
|
std::scoped_lock lock{tcpCacheMutex};
|
2024-11-19 04:56:32 +00:00
|
|
|
*info = tcpCurrent.matchInfo;
|
2017-11-01 21:58:44 -07:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::observeUserProgramStarting(void) {
|
2025-11-29 10:10:01 -08:00
|
|
|
HALSIM_SetProgramStarted(true);
|
2026-06-06 12:15:17 -07:00
|
|
|
return 0;
|
2020-12-28 12:58:06 -08:00
|
|
|
}
|
2016-05-20 17:30:37 -07:00
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::observeUserProgram(HAL_ControlWord word) {
|
2025-12-12 21:25:57 -07:00
|
|
|
HALSIM_SetProgramState(word);
|
2026-06-06 12:15:17 -07:00
|
|
|
return 0;
|
2015-08-19 11:12:54 -04:00
|
|
|
}
|
2015-11-26 00:08:32 -08:00
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::refreshDSData(bool* wasRefreshed) {
|
2022-10-23 21:59:04 -07:00
|
|
|
if (gShutdown) {
|
2026-06-06 12:15:17 -07:00
|
|
|
*wasRefreshed = false;
|
|
|
|
|
return HAL_INCOMPATIBLE_STATE;
|
2022-10-23 21:59:04 -07:00
|
|
|
}
|
2024-02-18 14:30:40 -08:00
|
|
|
bool dsAttached = SimDriverStationData->dsAttached;
|
2024-11-19 04:56:32 +00:00
|
|
|
JoystickDataCache* prev;
|
|
|
|
|
{
|
2026-06-06 12:15:17 -07:00
|
|
|
std::scoped_lock lock{cacheMutex};
|
2024-11-19 04:56:32 +00:00
|
|
|
prev = currentCache.exchange(nullptr);
|
|
|
|
|
if (prev != nullptr) {
|
|
|
|
|
currentRead = prev;
|
|
|
|
|
}
|
|
|
|
|
// If newest state shows we have a DS attached, just use the
|
|
|
|
|
// control word out of the cache, As it will be the one in sync
|
|
|
|
|
// with the data. If no data has been updated, at this point,
|
|
|
|
|
// and a DS wasn't attached previously, this will still return
|
|
|
|
|
// a zeroed out control word, with is the correct state for
|
|
|
|
|
// no new data.
|
|
|
|
|
if (!dsAttached) {
|
|
|
|
|
// If the DS is not attached, we need to zero out the control word.
|
|
|
|
|
// This is because HAL_RefreshDSData is called asynchronously from
|
|
|
|
|
// the DS data. The dsAttached variable comes directly from netcomm
|
|
|
|
|
// and could be updated before the caches are. If that happens,
|
|
|
|
|
// we would end up returning the previous cached control word,
|
|
|
|
|
// which is out of sync with the current control word and could
|
|
|
|
|
// break invariants such as which alliance station is in used.
|
|
|
|
|
// Also, when the DS has never been connected the rest of the fields
|
|
|
|
|
// in control word are garbage, so we also need to zero out in that
|
|
|
|
|
// case too
|
2025-12-12 21:25:57 -07:00
|
|
|
currentRead->controlWord.value = 0;
|
2024-11-19 04:56:32 +00:00
|
|
|
}
|
|
|
|
|
newestControlWord = currentRead->controlWord;
|
2020-12-28 12:58:06 -08:00
|
|
|
}
|
2024-11-19 04:56:32 +00:00
|
|
|
|
|
|
|
|
{
|
|
|
|
|
tcpCache.Update();
|
2026-06-06 12:15:17 -07:00
|
|
|
std::scoped_lock tcpLock(tcpCacheMutex);
|
2024-11-19 04:56:32 +00:00
|
|
|
tcpCache.CloneTo(&tcpCurrent);
|
2024-02-18 14:30:40 -08:00
|
|
|
}
|
2024-11-19 04:56:32 +00:00
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
*wasRefreshed = prev != nullptr;
|
|
|
|
|
return 0;
|
2017-05-08 20:21:47 -07:00
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
void MrcLibDsSimImpl::provideNewDataEventHandle(WPI_EventHandle handle) {
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
if (gShutdown) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2025-11-07 20:00:05 -05:00
|
|
|
wpi::hal::init::CheckInit();
|
2026-06-06 12:15:17 -07:00
|
|
|
newDataEvents.Add(handle);
|
2020-12-28 12:58:06 -08:00
|
|
|
}
|
2017-05-08 20:21:47 -07:00
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
void MrcLibDsSimImpl::removeNewDataEventHandle(WPI_EventHandle handle) {
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
if (gShutdown) {
|
|
|
|
|
return;
|
2020-07-13 21:57:54 -07:00
|
|
|
}
|
2026-06-06 12:15:17 -07:00
|
|
|
newDataEvents.Remove(handle);
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
}
|
2020-07-13 21:57:54 -07:00
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::getOutputsEnabled(bool* outputsEnabled) {
|
2022-10-23 21:59:04 -07:00
|
|
|
if (gShutdown) {
|
2026-06-06 12:15:17 -07:00
|
|
|
*outputsEnabled = false;
|
|
|
|
|
return HAL_INCOMPATIBLE_STATE;
|
2022-10-23 21:59:04 -07:00
|
|
|
}
|
2026-06-06 12:15:17 -07:00
|
|
|
std::scoped_lock lock{cacheMutex};
|
|
|
|
|
*outputsEnabled = HAL_ControlWord_IsEnabled(newestControlWord) &&
|
|
|
|
|
HAL_ControlWord_IsDSAttached(newestControlWord);
|
|
|
|
|
return 0;
|
2016-07-17 19:42:33 -07:00
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
int32_t MrcLibDsSimImpl::getSystemTimeValid(bool* systemTimeValid) {
|
|
|
|
|
*systemTimeValid = true;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2017-05-08 20:21:47 -07:00
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
void MrcLibDsSimImpl::NewDriverStationData() {
|
2024-02-18 14:30:40 -08:00
|
|
|
SimDriverStationData->dsAttached = true;
|
[hal, wpilib] New DS thread model and implementation (#3787)
The current DS thread model has some pretty major issues. It makes it difficult to know if all data is from the same remote packet, and if the data changes while the robot loop is running. Additionally, the DS thread is used for a few other things (MotorSafety and State Tracking for EducationalRobot). This also makes sim difficult, as user code has to wait for the thread to know it has new data.
This change completely rethinks how threading works in the driver station model.
First, the DS HAL system receives a new data callback, either from Netcomm or DriverStationSim. Inside the context of this callback, all the low latency data is read and put into a cache. Doing some investigation on the robot side, this is perfectly safe to do, and also ensures a ds packet will not be parsed before we finish reading the current packet data.
After all data is read, the cache is swapped with a 2nd buffer. This buffer just stores the data, none of the HAL DS calls read from this buffer. An event is then fired, stating there is new data ready to go.
Robot code calls HAL_UpdateDSData(). This swaps the 2nd buffer with a 3rd buffer, which always contains the current data. This data will not be updated until HAL_UpdateDSData is called again. Which solves the state problem.
The high level driver station classes have. an updateData() call, which calls HAL_UpdateDSData, and then update button state variables, then data log and update the NT FMS data table (Java also caches across the JNI boundary here, but that could trivially be removed). An extra event provider is provided, allowing other threads to know when this call has been completed.
IterativeRobotBase calls DS.updateData() at the beginning of each loop, and only once per loop. This means all commands will always have the same state.
All of this means there is no longer a DS thread. Everything happens synchronously. This means Sim and testing is easier, as you can just call DriverStationSim.NotifyNewData(), and then DriverStation.UpdateData(), and you can guarantee that all the DriverStation.*** data is up to date.
As for Motor Safety and Educational Robot State Handling, those can all be handled by their own threads. The Educational Thread only needs to run under EducationalRobot, and MotorSafety will only be started if there is a motor safety object enabled.
2022-10-21 22:01:55 -07:00
|
|
|
cacheToUpdate->Update();
|
2022-12-15 18:27:52 -08:00
|
|
|
|
|
|
|
|
JoystickDataCache* given = cacheToUpdate;
|
|
|
|
|
JoystickDataCache* prev = currentCache.exchange(cacheToUpdate);
|
|
|
|
|
if (prev == nullptr) {
|
|
|
|
|
cacheToUpdate = currentReadLocal;
|
|
|
|
|
currentReadLocal = lastGiven;
|
|
|
|
|
} else {
|
|
|
|
|
// Current read local does not update
|
|
|
|
|
cacheToUpdate = prev;
|
2020-12-28 12:58:06 -08:00
|
|
|
}
|
2022-12-15 18:27:52 -08:00
|
|
|
lastGiven = given;
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
newDataEvents.Wakeup();
|
2020-08-14 22:14:07 -07:00
|
|
|
SimDriverStationData->CallNewDataCallbacks();
|
2017-05-08 20:21:47 -07:00
|
|
|
}
|
|
|
|
|
|
2026-06-06 12:15:17 -07:00
|
|
|
namespace wpi::hal {
|
|
|
|
|
void NewDriverStationData() {
|
|
|
|
|
if (gShutdown) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
MrcLibDsSimImpl* defaultImpl =
|
|
|
|
|
static_cast<MrcLibDsSimImpl*>(GetDefaultDriverStationImpl());
|
|
|
|
|
defaultImpl->NewDriverStationData();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
MrcLibDs* GetDefaultDriverStationImpl() {
|
|
|
|
|
static MrcLibDsSimImpl impl;
|
|
|
|
|
return &impl;
|
2016-07-17 19:42:33 -07:00
|
|
|
}
|
2026-06-06 12:15:17 -07:00
|
|
|
|
2025-11-07 20:00:05 -05:00
|
|
|
} // namespace wpi::hal
|