ns delay between gpio polls solves it
All checks were successful
EIVE/eive-obsw/pipeline/pr-develop This commit looks good
All checks were successful
EIVE/eive-obsw/pipeline/pr-develop This commit looks good
This commit is contained in:
@ -76,8 +76,8 @@ class PapbVcInterface : public VirtualChannelIF {
|
||||
*/
|
||||
static const int DATA_REG_OFFSET = 256;
|
||||
|
||||
static constexpr long int FIRST_NON_NULL_DELAY_NS = 1000;
|
||||
static constexpr long int MAX_DELAY_PAPB_POLLING_NS = 4000;
|
||||
static constexpr long int FIRST_NON_NULL_DELAY_NS = 10;
|
||||
static constexpr long int MAX_DELAY_PAPB_POLLING_NS = 40;
|
||||
|
||||
LinuxLibgpioIF* gpioComIF = nullptr;
|
||||
|
||||
@ -89,6 +89,7 @@ class PapbVcInterface : public VirtualChannelIF {
|
||||
std::string uioFile;
|
||||
int mapNum = 0;
|
||||
mutable struct timespec nextDelay = {.tv_sec = 0, .tv_nsec = 0};
|
||||
const struct timespec BETWEEN_POLL_DELAY = {.tv_sec = 0, .tv_nsec = 5};
|
||||
mutable struct timespec remDelay;
|
||||
|
||||
volatile uint32_t* vcBaseReg = nullptr;
|
||||
@ -116,7 +117,7 @@ class PapbVcInterface : public VirtualChannelIF {
|
||||
*
|
||||
* @return returnvalue::OK when ready to receive data else PAPB_BUSY.
|
||||
*/
|
||||
ReturnValue_t pollPapbBusySignal(uint32_t maxPollRetries) const;
|
||||
inline ReturnValue_t pollPapbBusySignal(uint32_t maxPollRetries) const;
|
||||
|
||||
/**
|
||||
* @brief This function can be used for debugging to check whether there are packets in
|
||||
|
Reference in New Issue
Block a user