Also, the pressure switch test is wired correctly now,
so it should be working again in Java as well.
Change-Id: I066bc969c2e946d79df7c967cd000acfe840dd04
The constructor sets m_channel to UINT32_MAX and reports an error if the
channel index is out of range (or CheckDigitalChannel fails for some other
reason). A Get() following this would result in a crash because it wasn't
checking StatusIsFatal().
The new behavior now checks StatusIsFatal() and simply returns false.
Change-Id: I15529401294e4ccd1e09df834e02cca367fab67c
This is a poor man's version of the multi-instance Notifier support in
the higher level languages. It's intended primarily so that notifiers
can be created internal to the HAL.
One benefit of this change is that the current FPGA timestamp is passed
as the first parameter to the ProcessQueue function (rather than the
useless interrupt mask).
Caution for other languages wrapping the HAL: this adds a parameter to
initializeNotifier().
An atexit hook is used for safe cleanup at program termination.
Change-Id: I782b3a74c10215588ae9b7191906fb4186a81028
- Add an atexit hook to set global and watchdog to nullptr.
- Add checks to HAL functions for these nullptrs (also good checks if they
are called prior to HALInitialize).
Change-Id: I138657e8279ed9289648a91c91091ea6a1eb5dcc
Checking the status code in the macro before "context" is used avoids
significant overhead (string processing) in the common case when the code
is zero.
Change-Id: I69b8b220187ac1ab905cdf56dde5c4b6c61101b7
All the Error and assert calls were using const ::std::string & arguments.
When provided with a char*, the compiler was creating a temporary string
object to pass in. This was triggering mallocs everywhere, even in the
fast paths.
Change-Id: Ie0ad1f240334de677618086bddd64113c56aae6e
Implement GetAllSolenoids in the HAL so that SolenoidBase doesn't have to
read each solenoid individually.
Change-Id: I85559565949f7a7119ead410187235636a63f0ed
Having the HAL take a NATIVE_MULTIWAIT_ID without any way to get that
structure from extern "C" code is a problem. This makes it so it just
takes a MULTIWAIT_ID, and then grabs the native handle inside the HAL.
Change-Id: I06da18ba34adcea2f16e4e53da672f38be79e28e
Signed-off-by: Dustin Spicuzza <dustin@virtualroadside.com>
In the current HAL, once the port structures were created, there was no
way to free the structures. The way the C++ libraries were written this
wasn't a problem, since it grabbed a copy of each and stored them in an
array on bootup. However java does not do this, and grabs new ports
every time an object is created. This causes memory leaks if an object
is ever disposed in java. The same thing looks to be happening in
python, and C# does it too currently, but that would change if this gets
merged.
Adds java memory management fixes
Adds memory management to AnalogInput and Analog Output C++
SolenoidPorts and Digital Ports are all hold static arrays with their
port pointers (although solenoid overwrites them if a new solenoid on
the same module is created), however analog always grabbed new pointers.
I would fix the solenoid one, but I don't know what the ideal way to do
it would be.
Silently ignores free(null) calls by checking passed parameter is non-null.
Change-Id: Id32993b57b53f896e46e55c97541d3bd90b52648
For the previous couple of months, the PID tests have been hanging.
The reason that the tests have been hanging lies with the Notifier,
not the PID controller. Basically, a deadlock was occuring during
Notifier destruction when the notifier destructor was called while
the notifier interrupt handler was being called. Because the low-level
interrupt manager waits for the interrupt handler to finish executing before
disabling itself, the notifier destructor would not exit until the
ProcessQueue function finished. However, at the same time, the handler
was attempting to lock the queueMutex before continuing; the Notifier
destructor had locked the queueMutex while wrapping things up, meaning
that the last run of the handler would not complete until the destructor
did, resulting in a deadlock.
In order to repair this, I reduced the scope of the lock on the queueMutex
in the destructor so that it only locks when absolutely necessary. This
should work now.
This bug was likely introduced over the summer when we updated to stl
mutexes and locks, which may have messed up the original lock structure.
This likely did not affect any teams, as it can only occur if you are actively
destroying every* Notifier object present and if the destructor happens to be
called while the handler is being run.
*Note: the component of the destructor causing issues only ran if the last
Notifier object is being destroyed.
Change-Id: I38ba4e60816a2a8d523e927c25378390a0755444
New functions were added to CanTalonSRX in the HAL, however they were
not added to the C side of the library.
Change-Id: I15197e5dce5db0f5ff207d1318c21be485c90741
All other HAL functions have status as the last parameter, only PDP did not.
This changes makes the PDP parameter order consistent with the rest of the HAL.
Change-Id: I725e33f75deab34e6a83b7048b2d6c365fa56a21
