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
0babbf317cc4b1d8fd144a1b0b052b109b31adfc
allwpilib/hal/src/main/native/cpp/jni/NotifierJNI.cpp

148 lines
4.6 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
/*----------------------------------------------------------------------------*/
/* Copyright (c) FIRST 2016. All Rights Reserved. */
/* 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. */
/*----------------------------------------------------------------------------*/
Renames all our .hpp HAL files to .h (#44) Adds consistency, as the HAL was .hpp however all other code was .h.
2016-05-22 21:41:22 -07:00
#include "HAL/Notifier.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
#include <assert.h>
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>
#include <stdio.h>
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
#include "HALUtil.h"
Moves HAL cpp headers from root to HAL directory (#174) Could not include the ctre and NetComm folders, as those would require changing ctre dependancies. Also removes a duplicated FRCComm header that was not needed.
2016-07-14 00:17:29 -07:00
#include "HAL/cpp/Log.h"
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 "edu_wpi_first_wpilibj_hal_NotifierJNI.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 \
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
/*
* Class: edu_wpi_first_wpilibj_hal_NotifierJNI
* 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
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
Java_edu_wpi_first_wpilibj_hal_NotifierJNI_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
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)) {
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 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
/*
* Class: edu_wpi_first_wpilibj_hal_NotifierJNI
* Method: stopNotifier
* Signature: (I)V
*/
JNIEXPORT void JNICALL
Java_edu_wpi_first_wpilibj_hal_NotifierJNI_stopNotifier(
JNIEnv *env, jclass cls, jint notifierHandle) {
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
/*
* Class: edu_wpi_first_wpilibj_hal_NotifierJNI
* 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
*/
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 Java_edu_wpi_first_wpilibj_hal_NotifierJNI_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
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
}
/*
* Class: edu_wpi_first_wpilibj_hal_NotifierJNI
* 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
Java_edu_wpi_first_wpilibj_hal_NotifierJNI_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
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;
Prepends all HAL functions with HAL_ (#146)
2016-07-09 00:24:26 -07:00
HAL_UpdateNotifierAlarm((HAL_NotifierHandle)notifierHandle, (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);
}
/*
* Class: edu_wpi_first_wpilibj_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
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
Java_edu_wpi_first_wpilibj_hal_NotifierJNI_cancelNotifierAlarm(
JNIEnv *env, jclass cls, jint notifierHandle) {
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);
}
/*
* Class: edu_wpi_first_wpilibj_hal_NotifierJNI
* Method: waitForNotifierAlarm
* Signature: (I)J
*/
JNIEXPORT jlong JNICALL
Java_edu_wpi_first_wpilibj_hal_NotifierJNI_waitForNotifierAlarm(
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
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