Team2890/allwpilib
4
0
Fork 0
mirror of https://github.com/wpilibsuite/allwpilib synced 2026-06-20 00:51:42 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
3e0f7d0995a37a30dba85e37cc5227499ceef174
allwpilib/hal/src/main/native/cpp/jni/NotifierJNI.cpp

158 lines
4.5 KiB
C++
Raw Normal View History

artf2612: Update license in source files. Years update, references to WIND_BASE were removed, and WPILib license was moved to the root directory of the project. If there was already a comment block, a year range through 2016 was created using the first year in the comment. If there was no comment block, a block with just the year 2016 was added. Comments were not added to files from external sources (NI, CTRE). Change-Id: Iff4f098ab908b90b8d929902dea903de2f596acc
2016-01-02 03:02:34 -08:00
/*----------------------------------------------------------------------------*/
Run wpiformat on merged repo (#1021)
2018-05-13 17:09:56 -07:00
/* Copyright (c) 2016-2018 FIRST. All Rights Reserved. */
artf2612: Update license in source files. Years update, references to WIND_BASE were removed, and WPILib license was moved to the root directory of the project. If there was already a comment block, a year range through 2016 was created using the first year in the comment. If there was no comment block, a block with just the year 2016 was added. Comments were not added to files from external sources (NI, CTRE). Change-Id: Iff4f098ab908b90b8d929902dea903de2f596acc
2016-01-02 03:02:34 -08:00
/* Open Source Software - may be modified and shared by FRC teams. The code */
/* must be accompanied by the FIRST BSD license file in the root directory of */
/* the project. */
/*----------------------------------------------------------------------------*/
Add format script which invokes clang-format on the C++ source code (#41) On Windows machines, clang-format.exe must be in the PATH environment variable.
2016-05-20 17:30:37 -07:00
#include <jni.h>
Run wpiformat on merged repo (#1021)
2018-05-13 17:09:56 -07:00
#include <cassert>
#include <cstdio>
#include "HALUtil.h"
Move HAL classes to their own base package (#1317) Needed for modularization.
2018-09-20 21:59:46 -07:00
#include "edu_wpi_first_hal_NotifierJNI.h"
Move CameraServer and WPILib headers into their own folder The old headers were moved into folders because doing so avoids polluting the system include directories. Folder names were also normalized to lowercase.
2018-07-20 00:03:45 -07:00
#include "hal/Notifier.h"
#include "hal/cpp/Log.h"
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
Moves JNI internal utility methods to frc namespace (#310)
2016-10-31 23:04:49 -07:00
using namespace frc;
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
// set the logging level
TLogLevel notifierJNILogLevel = logWARNING;
Add format script which invokes clang-format on the C++ source code (#41) On Windows machines, clang-format.exe must be in the PATH environment variable.
2016-05-20 17:30:37 -07:00
#define NOTIFIERJNI_LOG(level) \
if (level > notifierJNILogLevel) \
; \
else \
Run wpiformat on merged repo (#1021)
2018-05-13 17:09:56 -07:00
Log().Get(level)
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
Simplify JNI interfaces. These changes both simplify the Java code and improve performance across the JNI boundary. This also fixes the AnalogCrossConnectTest by adding delays to setInterruptHigh() and setInterruptLow() to ensure the change in voltage has time to propagate and extends the timeouts in AbstractInterruptTest. Detailed changes: Hoisted status checks to C. This avoids the need to create direct byte buffers (expensive) and significantly simplifies the Java code. The C code now directly generates the exception or reports the error to the DS. The JVM pointer is now a global across the JNI, initialized by the OnLoad function, avoiding the need for some of the class-specific initializers to get this pointer for callbacks. Opaque pointers (such as ports) are now passed as long values rather than with a ByteBuffer wrapper. Added extern "C" to source files. This allows earlier detection of JNI definition mismatches to the Java source headers. Changed JNI signatures to more closely match HAL signatures (in particular, boolean is now universally used instead of byte for HAL bool, which cleans up mapping back and forth to 1/0 from true/false). Change-Id: I4ea0032cabb0871cd74106a3a70d947258c29d2d
2015-11-01 09:11:52 -08:00
extern "C" {
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
/*
Move HAL classes to their own base package (#1317) Needed for modularization.
2018-09-20 21:59:46 -07:00
* Class: edu_wpi_first_hal_NotifierJNI
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
* Method: initializeNotifier
Change HAL notifier to polling. (#627) This moves the thread code to the WPILib layer, fixing various potential races and significantly simplifying the HAL implementation.
2017-11-19 17:58:40 -08:00
* Signature: ()I
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
*/
Moves Notifier over to handles (#97) Internally, the linked list now uses shared_ptrs instead of raw pointers. In addition, in the WPILib the notifier handle is now made atomic. Then before the class is destructed, the handle is now set to 0. This should help solve one of the existing race conditions. A 0 handle is correctly handled down at the HAL level.
2016-06-05 07:29:47 -07:00
JNIEXPORT jint JNICALL
Move HAL classes to their own base package (#1317) Needed for modularization.
2018-09-20 21:59:46 -07:00
Java_edu_wpi_first_hal_NotifierJNI_initializeNotifier
Run wpiformat on merged repo (#1021)
2018-05-13 17:09:56 -07:00
(JNIEnv* env, jclass)
{
Rewrite Java Notifier and update Interrupt JNI. Notifier takes advantage of the multi-notifier support now in HAL. Each Notifier is now handled by a separate thread at the JNI level, so one notifier taking longer to process (or being breakpointed) does not stop the other notifiers from running. These threads are configured as daemon threads. In both Notifier and Interrupt JNI, the JNI thread attachment no longer repeatedly calls AttachCurrentThread(). This improves performance but more importantly avoids impacting the Eclipse debugger, which attempts to track each call to AttachCurrentThread() as a separate Java thread. Note: There is currently no way to free an interrupt handler. Repeatedly calling attachInterruptHandler() will result in leaking previous handlers. Change-Id: Ib12e3df88943c03e0269d3906e5b153767139391
2015-12-17 16:19:44 -08:00
NOTIFIERJNI_LOG(logDEBUG) << "Calling NOTIFIERJNI initializeNotifier";
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
Rewrite Java Notifier and update Interrupt JNI. Notifier takes advantage of the multi-notifier support now in HAL. Each Notifier is now handled by a separate thread at the JNI level, so one notifier taking longer to process (or being breakpointed) does not stop the other notifiers from running. These threads are configured as daemon threads. In both Notifier and Interrupt JNI, the JNI thread attachment no longer repeatedly calls AttachCurrentThread(). This improves performance but more importantly avoids impacting the Eclipse debugger, which attempts to track each call to AttachCurrentThread() as a separate Java thread. Note: There is currently no way to free an interrupt handler. Repeatedly calling attachInterruptHandler() will result in leaking previous handlers. Change-Id: Ib12e3df88943c03e0269d3906e5b153767139391
2015-12-17 16:19:44 -08:00
int32_t status = 0;
Change HAL notifier to polling. (#627) This moves the thread code to the WPILib layer, fixing various potential races and significantly simplifying the HAL implementation.
2017-11-19 17:58:40 -08:00
HAL_NotifierHandle notifierHandle = HAL_InitializeNotifier(&status);
Rewrite Java Notifier and update Interrupt JNI. Notifier takes advantage of the multi-notifier support now in HAL. Each Notifier is now handled by a separate thread at the JNI level, so one notifier taking longer to process (or being breakpointed) does not stop the other notifiers from running. These threads are configured as daemon threads. In both Notifier and Interrupt JNI, the JNI thread attachment no longer repeatedly calls AttachCurrentThread(). This improves performance but more importantly avoids impacting the Eclipse debugger, which attempts to track each call to AttachCurrentThread() as a separate Java thread. Note: There is currently no way to free an interrupt handler. Repeatedly calling attachInterruptHandler() will result in leaking previous handlers. Change-Id: Ib12e3df88943c03e0269d3906e5b153767139391
2015-12-17 16:19:44 -08:00
Moves Notifier over to handles (#97) Internally, the linked list now uses shared_ptrs instead of raw pointers. In addition, in the WPILib the notifier handle is now made atomic. Then before the class is destructed, the handle is now set to 0. This should help solve one of the existing race conditions. A 0 handle is correctly handled down at the HAL level.
2016-06-05 07:29:47 -07:00
NOTIFIERJNI_LOG(logDEBUG) << "Notifier Handle = " << notifierHandle;
Rewrite Java Notifier and update Interrupt JNI. Notifier takes advantage of the multi-notifier support now in HAL. Each Notifier is now handled by a separate thread at the JNI level, so one notifier taking longer to process (or being breakpointed) does not stop the other notifiers from running. These threads are configured as daemon threads. In both Notifier and Interrupt JNI, the JNI thread attachment no longer repeatedly calls AttachCurrentThread(). This improves performance but more importantly avoids impacting the Eclipse debugger, which attempts to track each call to AttachCurrentThread() as a separate Java thread. Note: There is currently no way to free an interrupt handler. Repeatedly calling attachInterruptHandler() will result in leaking previous handlers. Change-Id: Ib12e3df88943c03e0269d3906e5b153767139391
2015-12-17 16:19:44 -08:00
NOTIFIERJNI_LOG(logDEBUG) << "Status = " << status;
Forces exceptions to throw on HAL handle creation functions (#209) Fixes #199
2016-09-29 20:18:40 -07:00
if (notifierHandle <= 0 || !CheckStatusForceThrow(env, status)) {
Run wpiformat on merged repo (#1021)
2018-05-13 17:09:56 -07:00
return 0; // something went wrong in HAL
Rewrite Java Notifier and update Interrupt JNI. Notifier takes advantage of the multi-notifier support now in HAL. Each Notifier is now handled by a separate thread at the JNI level, so one notifier taking longer to process (or being breakpointed) does not stop the other notifiers from running. These threads are configured as daemon threads. In both Notifier and Interrupt JNI, the JNI thread attachment no longer repeatedly calls AttachCurrentThread(). This improves performance but more importantly avoids impacting the Eclipse debugger, which attempts to track each call to AttachCurrentThread() as a separate Java thread. Note: There is currently no way to free an interrupt handler. Repeatedly calling attachInterruptHandler() will result in leaking previous handlers. Change-Id: Ib12e3df88943c03e0269d3906e5b153767139391
2015-12-17 16:19:44 -08:00
}
Moves Notifier over to handles (#97) Internally, the linked list now uses shared_ptrs instead of raw pointers. In addition, in the WPILib the notifier handle is now made atomic. Then before the class is destructed, the handle is now set to 0. This should help solve one of the existing race conditions. A 0 handle is correctly handled down at the HAL level.
2016-06-05 07:29:47 -07:00
return (jint)notifierHandle;
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
}
Change HAL notifier to polling. (#627) This moves the thread code to the WPILib layer, fixing various potential races and significantly simplifying the HAL implementation.
2017-11-19 17:58:40 -08:00
/*
Move HAL classes to their own base package (#1317) Needed for modularization.
2018-09-20 21:59:46 -07:00
* Class: edu_wpi_first_hal_NotifierJNI
Change HAL notifier to polling. (#627) This moves the thread code to the WPILib layer, fixing various potential races and significantly simplifying the HAL implementation.
2017-11-19 17:58:40 -08:00
* Method: stopNotifier
* Signature: (I)V
*/
JNIEXPORT void JNICALL
Move HAL classes to their own base package (#1317) Needed for modularization.
2018-09-20 21:59:46 -07:00
Java_edu_wpi_first_hal_NotifierJNI_stopNotifier
Run wpiformat on merged repo (#1021)
2018-05-13 17:09:56 -07:00
(JNIEnv* env, jclass cls, jint notifierHandle)
{
Change HAL notifier to polling. (#627) This moves the thread code to the WPILib layer, fixing various potential races and significantly simplifying the HAL implementation.
2017-11-19 17:58:40 -08:00
NOTIFIERJNI_LOG(logDEBUG) << "Calling NOTIFIERJNI stopNotifier";
NOTIFIERJNI_LOG(logDEBUG) << "Notifier Handle = " << notifierHandle;
int32_t status = 0;
HAL_StopNotifier((HAL_NotifierHandle)notifierHandle, &status);
NOTIFIERJNI_LOG(logDEBUG) << "Status = " << status;
CheckStatus(env, status);
}
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
/*
Move HAL classes to their own base package (#1317) Needed for modularization.
2018-09-20 21:59:46 -07:00
* Class: edu_wpi_first_hal_NotifierJNI
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
* Method: cleanNotifier
Moves Notifier over to handles (#97) Internally, the linked list now uses shared_ptrs instead of raw pointers. In addition, in the WPILib the notifier handle is now made atomic. Then before the class is destructed, the handle is now set to 0. This should help solve one of the existing race conditions. A 0 handle is correctly handled down at the HAL level.
2016-06-05 07:29:47 -07:00
* Signature: (I)V
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
*/
Run wpiformat on merged repo (#1021)
2018-05-13 17:09:56 -07:00
JNIEXPORT void JNICALL
Move HAL classes to their own base package (#1317) Needed for modularization.
2018-09-20 21:59:46 -07:00
Java_edu_wpi_first_hal_NotifierJNI_cleanNotifier
Run wpiformat on merged repo (#1021)
2018-05-13 17:09:56 -07:00
(JNIEnv* env, jclass, jint notifierHandle)
{
Rewrite Java Notifier and update Interrupt JNI. Notifier takes advantage of the multi-notifier support now in HAL. Each Notifier is now handled by a separate thread at the JNI level, so one notifier taking longer to process (or being breakpointed) does not stop the other notifiers from running. These threads are configured as daemon threads. In both Notifier and Interrupt JNI, the JNI thread attachment no longer repeatedly calls AttachCurrentThread(). This improves performance but more importantly avoids impacting the Eclipse debugger, which attempts to track each call to AttachCurrentThread() as a separate Java thread. Note: There is currently no way to free an interrupt handler. Repeatedly calling attachInterruptHandler() will result in leaking previous handlers. Change-Id: Ib12e3df88943c03e0269d3906e5b153767139391
2015-12-17 16:19:44 -08:00
NOTIFIERJNI_LOG(logDEBUG) << "Calling NOTIFIERJNI cleanNotifier";
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
Moves Notifier over to handles (#97) Internally, the linked list now uses shared_ptrs instead of raw pointers. In addition, in the WPILib the notifier handle is now made atomic. Then before the class is destructed, the handle is now set to 0. This should help solve one of the existing race conditions. A 0 handle is correctly handled down at the HAL level.
2016-06-05 07:29:47 -07:00
NOTIFIERJNI_LOG(logDEBUG) << "Notifier Handle = " << notifierHandle;
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
Simplify JNI interfaces. These changes both simplify the Java code and improve performance across the JNI boundary. This also fixes the AnalogCrossConnectTest by adding delays to setInterruptHigh() and setInterruptLow() to ensure the change in voltage has time to propagate and extends the timeouts in AbstractInterruptTest. Detailed changes: Hoisted status checks to C. This avoids the need to create direct byte buffers (expensive) and significantly simplifies the Java code. The C code now directly generates the exception or reports the error to the DS. The JVM pointer is now a global across the JNI, initialized by the OnLoad function, avoiding the need for some of the class-specific initializers to get this pointer for callbacks. Opaque pointers (such as ports) are now passed as long values rather than with a ByteBuffer wrapper. Added extern "C" to source files. This allows earlier detection of JNI definition mismatches to the Java source headers. Changed JNI signatures to more closely match HAL signatures (in particular, boolean is now universally used instead of byte for HAL bool, which cleans up mapping back and forth to 1/0 from true/false). Change-Id: I4ea0032cabb0871cd74106a3a70d947258c29d2d
2015-11-01 09:11:52 -08:00
int32_t status = 0;
Prepends all HAL functions with HAL_ (#146)
2016-07-09 00:24:26 -07:00
HAL_CleanNotifier((HAL_NotifierHandle)notifierHandle, &status);
Rewrite Java Notifier and update Interrupt JNI. Notifier takes advantage of the multi-notifier support now in HAL. Each Notifier is now handled by a separate thread at the JNI level, so one notifier taking longer to process (or being breakpointed) does not stop the other notifiers from running. These threads are configured as daemon threads. In both Notifier and Interrupt JNI, the JNI thread attachment no longer repeatedly calls AttachCurrentThread(). This improves performance but more importantly avoids impacting the Eclipse debugger, which attempts to track each call to AttachCurrentThread() as a separate Java thread. Note: There is currently no way to free an interrupt handler. Repeatedly calling attachInterruptHandler() will result in leaking previous handlers. Change-Id: Ib12e3df88943c03e0269d3906e5b153767139391
2015-12-17 16:19:44 -08:00
NOTIFIERJNI_LOG(logDEBUG) << "Status = " << status;
CheckStatus(env, status);
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
}
/*
Move HAL classes to their own base package (#1317) Needed for modularization.
2018-09-20 21:59:46 -07:00
* Class: edu_wpi_first_hal_NotifierJNI
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
* Method: updateNotifierAlarm
Moves Notifier over to handles (#97) Internally, the linked list now uses shared_ptrs instead of raw pointers. In addition, in the WPILib the notifier handle is now made atomic. Then before the class is destructed, the handle is now set to 0. This should help solve one of the existing race conditions. A 0 handle is correctly handled down at the HAL level.
2016-06-05 07:29:47 -07:00
* Signature: (IJ)V
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
*/
Add format script which invokes clang-format on the C++ source code (#41) On Windows machines, clang-format.exe must be in the PATH environment variable.
2016-05-20 17:30:37 -07:00
JNIEXPORT void JNICALL
Move HAL classes to their own base package (#1317) Needed for modularization.
2018-09-20 21:59:46 -07:00
Java_edu_wpi_first_hal_NotifierJNI_updateNotifierAlarm
Run wpiformat on merged repo (#1021)
2018-05-13 17:09:56 -07:00
(JNIEnv* env, jclass cls, jint notifierHandle, jlong triggerTime)
{
Rewrite Java Notifier and update Interrupt JNI. Notifier takes advantage of the multi-notifier support now in HAL. Each Notifier is now handled by a separate thread at the JNI level, so one notifier taking longer to process (or being breakpointed) does not stop the other notifiers from running. These threads are configured as daemon threads. In both Notifier and Interrupt JNI, the JNI thread attachment no longer repeatedly calls AttachCurrentThread(). This improves performance but more importantly avoids impacting the Eclipse debugger, which attempts to track each call to AttachCurrentThread() as a separate Java thread. Note: There is currently no way to free an interrupt handler. Repeatedly calling attachInterruptHandler() will result in leaking previous handlers. Change-Id: Ib12e3df88943c03e0269d3906e5b153767139391
2015-12-17 16:19:44 -08:00
NOTIFIERJNI_LOG(logDEBUG) << "Calling NOTIFIERJNI updateNotifierAlarm";
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
Moves Notifier over to handles (#97) Internally, the linked list now uses shared_ptrs instead of raw pointers. In addition, in the WPILib the notifier handle is now made atomic. Then before the class is destructed, the handle is now set to 0. This should help solve one of the existing race conditions. A 0 handle is correctly handled down at the HAL level.
2016-06-05 07:29:47 -07:00
NOTIFIERJNI_LOG(logDEBUG) << "Notifier Handle = " << notifierHandle;
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
Rewrite Java Notifier and update Interrupt JNI. Notifier takes advantage of the multi-notifier support now in HAL. Each Notifier is now handled by a separate thread at the JNI level, so one notifier taking longer to process (or being breakpointed) does not stop the other notifiers from running. These threads are configured as daemon threads. In both Notifier and Interrupt JNI, the JNI thread attachment no longer repeatedly calls AttachCurrentThread(). This improves performance but more importantly avoids impacting the Eclipse debugger, which attempts to track each call to AttachCurrentThread() as a separate Java thread. Note: There is currently no way to free an interrupt handler. Repeatedly calling attachInterruptHandler() will result in leaking previous handlers. Change-Id: Ib12e3df88943c03e0269d3906e5b153767139391
2015-12-17 16:19:44 -08:00
NOTIFIERJNI_LOG(logDEBUG) << "triggerTime = " << triggerTime;
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
Simplify JNI interfaces. These changes both simplify the Java code and improve performance across the JNI boundary. This also fixes the AnalogCrossConnectTest by adding delays to setInterruptHigh() and setInterruptLow() to ensure the change in voltage has time to propagate and extends the timeouts in AbstractInterruptTest. Detailed changes: Hoisted status checks to C. This avoids the need to create direct byte buffers (expensive) and significantly simplifies the Java code. The C code now directly generates the exception or reports the error to the DS. The JVM pointer is now a global across the JNI, initialized by the OnLoad function, avoiding the need for some of the class-specific initializers to get this pointer for callbacks. Opaque pointers (such as ports) are now passed as long values rather than with a ByteBuffer wrapper. Added extern "C" to source files. This allows earlier detection of JNI definition mismatches to the Java source headers. Changed JNI signatures to more closely match HAL signatures (in particular, boolean is now universally used instead of byte for HAL bool, which cleans up mapping back and forth to 1/0 from true/false). Change-Id: I4ea0032cabb0871cd74106a3a70d947258c29d2d
2015-11-01 09:11:52 -08:00
int32_t status = 0;
Run wpiformat on merged repo (#1021)
2018-05-13 17:09:56 -07:00
HAL_UpdateNotifierAlarm((HAL_NotifierHandle)notifierHandle,
static_cast<uint64_t>(triggerTime), &status);
Rewrite Java Notifier and update Interrupt JNI. Notifier takes advantage of the multi-notifier support now in HAL. Each Notifier is now handled by a separate thread at the JNI level, so one notifier taking longer to process (or being breakpointed) does not stop the other notifiers from running. These threads are configured as daemon threads. In both Notifier and Interrupt JNI, the JNI thread attachment no longer repeatedly calls AttachCurrentThread(). This improves performance but more importantly avoids impacting the Eclipse debugger, which attempts to track each call to AttachCurrentThread() as a separate Java thread. Note: There is currently no way to free an interrupt handler. Repeatedly calling attachInterruptHandler() will result in leaking previous handlers. Change-Id: Ib12e3df88943c03e0269d3906e5b153767139391
2015-12-17 16:19:44 -08:00
NOTIFIERJNI_LOG(logDEBUG) << "Status = " << status;
CheckStatus(env, status);
}
/*
Move HAL classes to their own base package (#1317) Needed for modularization.
2018-09-20 21:59:46 -07:00
* Class: edu_wpi_first_hal_NotifierJNI
Change HAL notifier to polling. (#627) This moves the thread code to the WPILib layer, fixing various potential races and significantly simplifying the HAL implementation.
2017-11-19 17:58:40 -08:00
* Method: cancelNotifierAlarm
Moves Notifier over to handles (#97) Internally, the linked list now uses shared_ptrs instead of raw pointers. In addition, in the WPILib the notifier handle is now made atomic. Then before the class is destructed, the handle is now set to 0. This should help solve one of the existing race conditions. A 0 handle is correctly handled down at the HAL level.
2016-06-05 07:29:47 -07:00
* Signature: (I)V
Rewrite Java Notifier and update Interrupt JNI. Notifier takes advantage of the multi-notifier support now in HAL. Each Notifier is now handled by a separate thread at the JNI level, so one notifier taking longer to process (or being breakpointed) does not stop the other notifiers from running. These threads are configured as daemon threads. In both Notifier and Interrupt JNI, the JNI thread attachment no longer repeatedly calls AttachCurrentThread(). This improves performance but more importantly avoids impacting the Eclipse debugger, which attempts to track each call to AttachCurrentThread() as a separate Java thread. Note: There is currently no way to free an interrupt handler. Repeatedly calling attachInterruptHandler() will result in leaking previous handlers. Change-Id: Ib12e3df88943c03e0269d3906e5b153767139391
2015-12-17 16:19:44 -08:00
*/
Add format script which invokes clang-format on the C++ source code (#41) On Windows machines, clang-format.exe must be in the PATH environment variable.
2016-05-20 17:30:37 -07:00
JNIEXPORT void JNICALL
Move HAL classes to their own base package (#1317) Needed for modularization.
2018-09-20 21:59:46 -07:00
Java_edu_wpi_first_hal_NotifierJNI_cancelNotifierAlarm
Run wpiformat on merged repo (#1021)
2018-05-13 17:09:56 -07:00
(JNIEnv* env, jclass cls, jint notifierHandle)
{
Change HAL notifier to polling. (#627) This moves the thread code to the WPILib layer, fixing various potential races and significantly simplifying the HAL implementation.
2017-11-19 17:58:40 -08:00
NOTIFIERJNI_LOG(logDEBUG) << "Calling NOTIFIERJNI cancelNotifierAlarm";
NOTIFIERJNI_LOG(logDEBUG) << "Notifier Handle = " << notifierHandle;
int32_t status = 0;
HAL_CancelNotifierAlarm((HAL_NotifierHandle)notifierHandle, &status);
NOTIFIERJNI_LOG(logDEBUG) << "Status = " << status;
CheckStatus(env, status);
}
/*
Move HAL classes to their own base package (#1317) Needed for modularization.
2018-09-20 21:59:46 -07:00
* Class: edu_wpi_first_hal_NotifierJNI
Change HAL notifier to polling. (#627) This moves the thread code to the WPILib layer, fixing various potential races and significantly simplifying the HAL implementation.
2017-11-19 17:58:40 -08:00
* Method: waitForNotifierAlarm
* Signature: (I)J
*/
JNIEXPORT jlong JNICALL
Move HAL classes to their own base package (#1317) Needed for modularization.
2018-09-20 21:59:46 -07:00
Java_edu_wpi_first_hal_NotifierJNI_waitForNotifierAlarm
Run wpiformat on merged repo (#1021)
2018-05-13 17:09:56 -07:00
(JNIEnv* env, jclass cls, jint notifierHandle)
{
Change HAL notifier to polling. (#627) This moves the thread code to the WPILib layer, fixing various potential races and significantly simplifying the HAL implementation.
2017-11-19 17:58:40 -08:00
NOTIFIERJNI_LOG(logDEBUG) << "Calling NOTIFIERJNI waitForNotifierAlarm";
Rewrite Java Notifier and update Interrupt JNI. Notifier takes advantage of the multi-notifier support now in HAL. Each Notifier is now handled by a separate thread at the JNI level, so one notifier taking longer to process (or being breakpointed) does not stop the other notifiers from running. These threads are configured as daemon threads. In both Notifier and Interrupt JNI, the JNI thread attachment no longer repeatedly calls AttachCurrentThread(). This improves performance but more importantly avoids impacting the Eclipse debugger, which attempts to track each call to AttachCurrentThread() as a separate Java thread. Note: There is currently no way to free an interrupt handler. Repeatedly calling attachInterruptHandler() will result in leaking previous handlers. Change-Id: Ib12e3df88943c03e0269d3906e5b153767139391
2015-12-17 16:19:44 -08:00
Moves Notifier over to handles (#97) Internally, the linked list now uses shared_ptrs instead of raw pointers. In addition, in the WPILib the notifier handle is now made atomic. Then before the class is destructed, the handle is now set to 0. This should help solve one of the existing race conditions. A 0 handle is correctly handled down at the HAL level.
2016-06-05 07:29:47 -07:00
NOTIFIERJNI_LOG(logDEBUG) << "Notifier Handle = " << notifierHandle;
Rewrite Java Notifier and update Interrupt JNI. Notifier takes advantage of the multi-notifier support now in HAL. Each Notifier is now handled by a separate thread at the JNI level, so one notifier taking longer to process (or being breakpointed) does not stop the other notifiers from running. These threads are configured as daemon threads. In both Notifier and Interrupt JNI, the JNI thread attachment no longer repeatedly calls AttachCurrentThread(). This improves performance but more importantly avoids impacting the Eclipse debugger, which attempts to track each call to AttachCurrentThread() as a separate Java thread. Note: There is currently no way to free an interrupt handler. Repeatedly calling attachInterruptHandler() will result in leaking previous handlers. Change-Id: Ib12e3df88943c03e0269d3906e5b153767139391
2015-12-17 16:19:44 -08:00
int32_t status = 0;
Change HAL notifier to polling. (#627) This moves the thread code to the WPILib layer, fixing various potential races and significantly simplifying the HAL implementation.
2017-11-19 17:58:40 -08:00
uint64_t time =
HAL_WaitForNotifierAlarm((HAL_NotifierHandle)notifierHandle, &status);
Rewrite Java Notifier and update Interrupt JNI. Notifier takes advantage of the multi-notifier support now in HAL. Each Notifier is now handled by a separate thread at the JNI level, so one notifier taking longer to process (or being breakpointed) does not stop the other notifiers from running. These threads are configured as daemon threads. In both Notifier and Interrupt JNI, the JNI thread attachment no longer repeatedly calls AttachCurrentThread(). This improves performance but more importantly avoids impacting the Eclipse debugger, which attempts to track each call to AttachCurrentThread() as a separate Java thread. Note: There is currently no way to free an interrupt handler. Repeatedly calling attachInterruptHandler() will result in leaking previous handlers. Change-Id: Ib12e3df88943c03e0269d3906e5b153767139391
2015-12-17 16:19:44 -08:00
NOTIFIERJNI_LOG(logDEBUG) << "Status = " << status;
Change HAL notifier to polling. (#627) This moves the thread code to the WPILib layer, fixing various potential races and significantly simplifying the HAL implementation.
2017-11-19 17:58:40 -08:00
NOTIFIERJNI_LOG(logDEBUG) << "Time = " << time;
Rewrite Java Notifier and update Interrupt JNI. Notifier takes advantage of the multi-notifier support now in HAL. Each Notifier is now handled by a separate thread at the JNI level, so one notifier taking longer to process (or being breakpointed) does not stop the other notifiers from running. These threads are configured as daemon threads. In both Notifier and Interrupt JNI, the JNI thread attachment no longer repeatedly calls AttachCurrentThread(). This improves performance but more importantly avoids impacting the Eclipse debugger, which attempts to track each call to AttachCurrentThread() as a separate Java thread. Note: There is currently no way to free an interrupt handler. Repeatedly calling attachInterruptHandler() will result in leaking previous handlers. Change-Id: Ib12e3df88943c03e0269d3906e5b153767139391
2015-12-17 16:19:44 -08:00
CheckStatus(env, status);
Change HAL notifier to polling. (#627) This moves the thread code to the WPILib layer, fixing various potential races and significantly simplifying the HAL implementation.
2017-11-19 17:58:40 -08:00
return (jlong)time;
This commit adds JNI bindings for the C++ Notifier. The bindings only wrap the HAL interface, rather than the entire C++ Notifier, as I ran into issues trying to wrap the whole Notifier (all the existing bindings only wrap HAL components, so wrapping stuff in :wpilibc is unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a re-implementation of the wpilibc/.../Notifier.cpp. The purpose of doing this bindings is to allow Java users a better option for running tasks which require good timing (such as control loops). The previous method used java.util.Timer to schedule a task, causing various issues. Although this update does improve things, Java loop timing is still substantially worse than that of C++, and, even worse, if Java decides to call the garbage collector at the wrong time then the loop can be delayed by multiple milliseconds and the next iteration will be shorter to account for it (although this particular behavior could be updated). A few notes on individual components: -the HAL Task.hpp and Task.cpp were modified due to compilation/linkage issues with the JNI bindings. Nothing substantive changed. -NotifierJNI was added to the build files for gradle. -HALUtil was modified to include a function for getting the length of a C pointer, rather than relying on it being 32-bit. Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
}
Simplify JNI interfaces. These changes both simplify the Java code and improve performance across the JNI boundary. This also fixes the AnalogCrossConnectTest by adding delays to setInterruptHigh() and setInterruptLow() to ensure the change in voltage has time to propagate and extends the timeouts in AbstractInterruptTest. Detailed changes: Hoisted status checks to C. This avoids the need to create direct byte buffers (expensive) and significantly simplifies the Java code. The C code now directly generates the exception or reports the error to the DS. The JVM pointer is now a global across the JNI, initialized by the OnLoad function, avoiding the need for some of the class-specific initializers to get this pointer for callbacks. Opaque pointers (such as ports) are now passed as long values rather than with a ByteBuffer wrapper. Added extern "C" to source files. This allows earlier detection of JNI definition mismatches to the Java source headers. Changed JNI signatures to more closely match HAL signatures (in particular, boolean is now universally used instead of byte for HAL bool, which cleans up mapping back and forth to 1/0 from true/false). Change-Id: I4ea0032cabb0871cd74106a3a70d947258c29d2d
2015-11-01 09:11:52 -08:00
} // extern "C"
Reference in New Issue Copy Permalink