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.
|
2017-08-18 21:35:53 -07:00
|
|
|
|
2024-09-20 17:43:39 -07:00
|
|
|
#include <string>
|
|
|
|
|
|
2017-08-18 21:35:53 -07:00
|
|
|
#include "RoboRioDataInternal.h"
|
|
|
|
|
|
|
|
|
|
using namespace hal;
|
|
|
|
|
|
2020-12-28 01:19:59 -08:00
|
|
|
namespace hal::init {
|
2017-12-10 19:38:53 -08:00
|
|
|
void InitializeRoboRioData() {
|
2020-07-04 00:44:56 -07:00
|
|
|
static RoboRioData srrd;
|
|
|
|
|
::hal::SimRoboRioData = &srrd;
|
2017-12-10 19:38:53 -08:00
|
|
|
}
|
2020-12-28 01:19:59 -08:00
|
|
|
} // namespace hal::init
|
2017-12-10 19:38:53 -08:00
|
|
|
|
|
|
|
|
RoboRioData* hal::SimRoboRioData;
|
2017-08-18 21:35:53 -07:00
|
|
|
void RoboRioData::ResetData() {
|
2018-09-03 16:08:07 -07:00
|
|
|
fpgaButton.Reset(false);
|
2020-01-04 15:07:47 -08:00
|
|
|
vInVoltage.Reset(12.0);
|
2018-09-03 16:08:07 -07:00
|
|
|
vInCurrent.Reset(0.0);
|
|
|
|
|
userVoltage6V.Reset(6.0);
|
|
|
|
|
userCurrent6V.Reset(0.0);
|
2020-01-04 15:07:47 -08:00
|
|
|
userActive6V.Reset(true);
|
2018-09-03 16:08:07 -07:00
|
|
|
userVoltage5V.Reset(5.0);
|
|
|
|
|
userCurrent5V.Reset(0.0);
|
2020-01-04 15:07:47 -08:00
|
|
|
userActive5V.Reset(true);
|
2018-09-03 16:08:07 -07:00
|
|
|
userVoltage3V3.Reset(3.3);
|
|
|
|
|
userCurrent3V3.Reset(0.0);
|
2020-01-04 15:07:47 -08:00
|
|
|
userActive3V3.Reset(true);
|
2018-09-03 16:08:07 -07:00
|
|
|
userFaults6V.Reset(0);
|
|
|
|
|
userFaults5V.Reset(0);
|
|
|
|
|
userFaults3V3.Reset(0);
|
2021-10-13 19:14:27 -07:00
|
|
|
brownoutVoltage.Reset(6.75);
|
2023-08-31 14:51:57 -04:00
|
|
|
cpuTemp.Reset(45.0);
|
2023-09-02 02:34:18 -04:00
|
|
|
teamNumber.Reset(0);
|
2022-12-09 00:58:55 -05:00
|
|
|
m_serialNumber = "";
|
2022-12-26 14:39:51 -05:00
|
|
|
m_comments = "";
|
2022-12-09 00:58:55 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int32_t RoboRioData::RegisterSerialNumberCallback(
|
|
|
|
|
HAL_RoboRioStringCallback callback, void* param, HAL_Bool initialNotify) {
|
|
|
|
|
std::scoped_lock lock(m_serialNumberMutex);
|
|
|
|
|
int32_t uid = m_serialNumberCallbacks.Register(callback, param);
|
|
|
|
|
if (initialNotify) {
|
|
|
|
|
callback(GetSerialNumberName(), param, m_serialNumber.c_str(),
|
|
|
|
|
m_serialNumber.size());
|
|
|
|
|
}
|
|
|
|
|
return uid;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void RoboRioData::CancelSerialNumberCallback(int32_t uid) {
|
|
|
|
|
m_serialNumberCallbacks.Cancel(uid);
|
|
|
|
|
}
|
|
|
|
|
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
void RoboRioData::GetSerialNumber(struct WPI_String* serialNumber) {
|
2022-12-09 00:58:55 -05:00
|
|
|
std::scoped_lock lock(m_serialNumberMutex);
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
auto write = WPI_AllocateString(serialNumber, m_serialNumber.size());
|
|
|
|
|
m_serialNumber.copy(write, m_serialNumber.size());
|
2022-12-09 00:58:55 -05:00
|
|
|
}
|
|
|
|
|
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
void RoboRioData::SetSerialNumber(std::string_view serialNumber) {
|
2022-12-09 00:58:55 -05:00
|
|
|
// Limit serial number to 8 characters internally- serialnum environment
|
|
|
|
|
// variable is always 8 characters
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
if (serialNumber.size() > 8) {
|
|
|
|
|
serialNumber = serialNumber.substr(0, 8);
|
2022-12-09 00:58:55 -05:00
|
|
|
}
|
|
|
|
|
std::scoped_lock lock(m_serialNumberMutex);
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
m_serialNumber = std::string(serialNumber);
|
2022-12-09 00:58:55 -05:00
|
|
|
m_serialNumberCallbacks(m_serialNumber.c_str(), m_serialNumber.size());
|
2017-08-18 21:35:53 -07:00
|
|
|
}
|
|
|
|
|
|
2022-12-26 14:39:51 -05:00
|
|
|
int32_t RoboRioData::RegisterCommentsCallback(
|
|
|
|
|
HAL_RoboRioStringCallback callback, void* param, HAL_Bool initialNotify) {
|
|
|
|
|
std::scoped_lock lock(m_commentsMutex);
|
|
|
|
|
int32_t uid = m_commentsCallbacks.Register(callback, param);
|
|
|
|
|
if (initialNotify) {
|
|
|
|
|
callback(GetCommentsName(), param, m_comments.c_str(),
|
|
|
|
|
m_serialNumber.size());
|
|
|
|
|
}
|
|
|
|
|
return uid;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void RoboRioData::CancelCommentsCallback(int32_t uid) {
|
|
|
|
|
m_commentsCallbacks.Cancel(uid);
|
|
|
|
|
}
|
|
|
|
|
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
void RoboRioData::GetComments(struct WPI_String* comments) {
|
2022-12-26 14:39:51 -05:00
|
|
|
std::scoped_lock lock(m_commentsMutex);
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
auto write = WPI_AllocateString(comments, m_comments.size());
|
|
|
|
|
m_comments.copy(write, m_comments.size());
|
2022-12-26 14:39:51 -05:00
|
|
|
}
|
|
|
|
|
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
void RoboRioData::SetComments(std::string_view comments) {
|
|
|
|
|
if (comments.size() > 64) {
|
|
|
|
|
comments = comments.substr(0, 64);
|
2022-12-26 14:39:51 -05:00
|
|
|
}
|
|
|
|
|
std::scoped_lock lock(m_commentsMutex);
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
m_comments = std::string(comments);
|
2022-12-26 14:39:51 -05:00
|
|
|
m_commentsCallbacks(m_comments.c_str(), m_comments.size());
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-18 21:35:53 -07:00
|
|
|
extern "C" {
|
2020-12-28 12:58:06 -08:00
|
|
|
void HALSIM_ResetRoboRioData(void) {
|
|
|
|
|
SimRoboRioData->ResetData();
|
|
|
|
|
}
|
2017-08-18 21:35:53 -07:00
|
|
|
|
2020-07-04 00:44:56 -07:00
|
|
|
#define DEFINE_CAPI(TYPE, CAPINAME, LOWERNAME) \
|
|
|
|
|
HAL_SIMDATAVALUE_DEFINE_CAPI_NOINDEX(TYPE, HALSIM, RoboRio##CAPINAME, \
|
|
|
|
|
SimRoboRioData, LOWERNAME)
|
2018-09-03 16:08:07 -07:00
|
|
|
|
|
|
|
|
DEFINE_CAPI(HAL_Bool, FPGAButton, fpgaButton)
|
|
|
|
|
DEFINE_CAPI(double, VInVoltage, vInVoltage)
|
|
|
|
|
DEFINE_CAPI(double, VInCurrent, vInCurrent)
|
|
|
|
|
DEFINE_CAPI(double, UserVoltage6V, userVoltage6V)
|
|
|
|
|
DEFINE_CAPI(double, UserCurrent6V, userCurrent6V)
|
|
|
|
|
DEFINE_CAPI(HAL_Bool, UserActive6V, userActive6V)
|
|
|
|
|
DEFINE_CAPI(double, UserVoltage5V, userVoltage5V)
|
|
|
|
|
DEFINE_CAPI(double, UserCurrent5V, userCurrent5V)
|
|
|
|
|
DEFINE_CAPI(HAL_Bool, UserActive5V, userActive5V)
|
|
|
|
|
DEFINE_CAPI(double, UserVoltage3V3, userVoltage3V3)
|
|
|
|
|
DEFINE_CAPI(double, UserCurrent3V3, userCurrent3V3)
|
|
|
|
|
DEFINE_CAPI(HAL_Bool, UserActive3V3, userActive3V3)
|
|
|
|
|
DEFINE_CAPI(int32_t, UserFaults6V, userFaults6V)
|
|
|
|
|
DEFINE_CAPI(int32_t, UserFaults5V, userFaults5V)
|
|
|
|
|
DEFINE_CAPI(int32_t, UserFaults3V3, userFaults3V3)
|
2021-10-13 19:14:27 -07:00
|
|
|
DEFINE_CAPI(double, BrownoutVoltage, brownoutVoltage)
|
2023-08-31 14:51:57 -04:00
|
|
|
DEFINE_CAPI(double, CPUTemp, cpuTemp)
|
2023-09-02 02:34:18 -04:00
|
|
|
DEFINE_CAPI(int32_t, TeamNumber, teamNumber)
|
2023-12-22 13:57:52 -05:00
|
|
|
DEFINE_CAPI(HAL_RadioLEDState, RadioLEDState, radioLedState)
|
2018-09-03 16:08:07 -07:00
|
|
|
|
2022-12-09 00:58:55 -05:00
|
|
|
int32_t HALSIM_RegisterRoboRioSerialNumberCallback(
|
|
|
|
|
HAL_RoboRioStringCallback callback, void* param, HAL_Bool initialNotify) {
|
|
|
|
|
return SimRoboRioData->RegisterSerialNumberCallback(callback, param,
|
|
|
|
|
initialNotify);
|
|
|
|
|
}
|
|
|
|
|
void HALSIM_CancelRoboRioSerialNumberCallback(int32_t uid) {
|
|
|
|
|
return SimRoboRioData->CancelSerialNumberCallback(uid);
|
|
|
|
|
}
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
void HALSIM_GetRoboRioSerialNumber(struct WPI_String* serialNumber) {
|
|
|
|
|
SimRoboRioData->GetSerialNumber(serialNumber);
|
2022-12-09 00:58:55 -05:00
|
|
|
}
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
void HALSIM_SetRoboRioSerialNumber(const struct WPI_String* serialNumber) {
|
|
|
|
|
SimRoboRioData->SetSerialNumber(wpi::to_string_view(serialNumber));
|
2022-12-09 00:58:55 -05:00
|
|
|
}
|
|
|
|
|
|
2022-12-26 14:39:51 -05:00
|
|
|
int32_t HALSIM_RegisterRoboRioCommentsCallback(
|
|
|
|
|
HAL_RoboRioStringCallback callback, void* param, HAL_Bool initialNotify) {
|
|
|
|
|
return SimRoboRioData->RegisterCommentsCallback(callback, param,
|
|
|
|
|
initialNotify);
|
|
|
|
|
}
|
|
|
|
|
void HALSIM_CancelRoboRioCommentsCallback(int32_t uid) {
|
|
|
|
|
SimRoboRioData->CancelCommentsCallback(uid);
|
|
|
|
|
}
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
void HALSIM_GetRoboRioComments(struct WPI_String* comments) {
|
|
|
|
|
SimRoboRioData->GetComments(comments);
|
2022-12-26 14:39:51 -05:00
|
|
|
}
|
Change C APIs to a unified string implementation (#6299)
Currently in the entire C API of WPILib we have ~8 different ways of handling strings. The C API actually isn't built for pure C callers (We don't actually have any of those). Instead, they're built for interop between languages like LabVIEW and C# which can talk to C API's directly.
For output parameters, the choice was fairly obvious. An output struct containing a const string pointer and a length makes the most sense. Its easy to use these from most other languages, and doesn't require special null termination handling. Freeing these is also easy, as if you ever receive one of these string structures, theres just a single function call to free it.
Input parameters are a bit more complex. To be used from pure C, and from LabVIEW, a null terminated string is the best in most cases. However, null terminated strings in general have a lot of downsides. Additionally, from LabVIEW there are other considerations around encoding that having a wrapper struct helps make a bit easier. From a language like C#, a wrapper struct is by far the easiest, as custom marshalling can make it trivial to marshal both UTF8 and UTF16 strings down.
The final consideration is its nice to have an identical concept for both input and output. It makes the rules fairly easy to understand.
WPILib will not have any APIs that manipulate a string allocated externally. This means WPI_String can be const, as across the boundary it is always const.
If a WPILib API takes a const WPI_String*, WPILib will not manipulate or attempt to free that string, and that string is treated as an input. It is up to the caller to handle that memory, WPILib will never hold onto that memory longer than the call.
If a WPILib API takes a WPI_String*, that string is an output. WPILib will allocate that API with WPI_AllocateString(), fill in the string, and return to the caller. When the caller is done with the string, they must free it with WPI_FreeString().
If an output struct contains a WPI_String member, that member is considered read only, and should not be explicitly freed. The caller should call the free function for that struct.
If an array of WPI_Strings are returned, each individual string is considered read only, and should not be explicitly freed. The free function for that array should be called by the caller.
If an input struct containing a WPI_String, or an input array of WPI_Strings is passed to WPILib, the individual strings will not be manipulated or freed by WPILib, and the caller owns and should free that memory.
Callbacks also follow these rules. The most common is a callback either getting passed a const WPI_String* or a struct containing a WPI_String. In both of these cases, the callback target should consider these strings read only, and not attempt to free them or manipulate them.
2024-05-13 05:35:14 -07:00
|
|
|
void HALSIM_SetRoboRioComments(const struct WPI_String* comments) {
|
|
|
|
|
SimRoboRioData->SetComments(wpi::to_string_view(comments));
|
2022-12-26 14:39:51 -05:00
|
|
|
}
|
|
|
|
|
|
2022-12-09 00:58:55 -05:00
|
|
|
void HALSIM_RegisterRoboRioAllCallbacks(HAL_NotifyCallback callback,
|
|
|
|
|
void* param, HAL_Bool initialNotify);
|
|
|
|
|
|
2018-09-03 16:08:07 -07:00
|
|
|
#define REGISTER(NAME) \
|
2020-07-04 00:44:56 -07:00
|
|
|
SimRoboRioData->NAME.RegisterCallback(callback, param, initialNotify)
|
2017-10-22 01:45:41 -04:00
|
|
|
|
2020-07-04 00:44:56 -07:00
|
|
|
void HALSIM_RegisterRoboRioAllCallbacks(HAL_NotifyCallback callback,
|
2017-10-22 01:45:41 -04:00
|
|
|
void* param, HAL_Bool initialNotify) {
|
2018-09-03 16:08:07 -07:00
|
|
|
REGISTER(fpgaButton);
|
|
|
|
|
REGISTER(vInVoltage);
|
|
|
|
|
REGISTER(vInCurrent);
|
|
|
|
|
REGISTER(userVoltage6V);
|
|
|
|
|
REGISTER(userCurrent6V);
|
|
|
|
|
REGISTER(userActive6V);
|
|
|
|
|
REGISTER(userVoltage5V);
|
|
|
|
|
REGISTER(userCurrent5V);
|
|
|
|
|
REGISTER(userActive5V);
|
|
|
|
|
REGISTER(userVoltage3V3);
|
|
|
|
|
REGISTER(userCurrent3V3);
|
|
|
|
|
REGISTER(userActive3V3);
|
|
|
|
|
REGISTER(userFaults6V);
|
|
|
|
|
REGISTER(userFaults5V);
|
|
|
|
|
REGISTER(userFaults3V3);
|
2021-10-13 19:14:27 -07:00
|
|
|
REGISTER(brownoutVoltage);
|
2023-08-04 02:48:29 -04:00
|
|
|
REGISTER(cpuTemp);
|
2023-12-22 13:57:52 -05:00
|
|
|
REGISTER(radioLedState);
|
2017-10-22 01:45:41 -04:00
|
|
|
}
|
2017-10-16 19:56:08 -07:00
|
|
|
} // extern "C"
|