2020-12-26 14:12:05 -08:00
|
|
|
// Copyright (c) FIRST and other WPILib contributors.
|
|
|
|
|
// Open Source Software; you can modify and/or share it under the terms of
|
|
|
|
|
// the WPILib BSD license file in the root directory of this project.
|
2016-01-02 03:02:34 -08:00
|
|
|
|
2025-11-07 19:55:43 -05:00
|
|
|
package org.wpilib.system;
|
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
|
|
|
|
2025-11-07 19:55:43 -05:00
|
|
|
import static org.wpilib.units.Units.Seconds;
|
|
|
|
|
import static org.wpilib.util.ErrorMessages.requireNonNullParam;
|
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
|
|
|
|
2025-11-07 19:57:21 -05:00
|
|
|
import java.util.concurrent.atomic.AtomicInteger;
|
|
|
|
|
import java.util.concurrent.locks.ReentrantLock;
|
2025-11-07 19:56:29 -05:00
|
|
|
import org.wpilib.driverstation.DriverStation;
|
2025-11-07 19:55:43 -05:00
|
|
|
import org.wpilib.hardware.hal.NotifierJNI;
|
|
|
|
|
import org.wpilib.units.measure.Frequency;
|
|
|
|
|
import org.wpilib.units.measure.Time;
|
2025-11-29 11:00:18 -08:00
|
|
|
import org.wpilib.util.WPIUtilJNI;
|
2019-07-15 21:20:11 -04:00
|
|
|
|
2022-07-01 06:45:00 -07:00
|
|
|
/**
|
2023-09-15 19:59:03 -07:00
|
|
|
* Notifiers run a user-provided callback function on a separate thread.
|
2022-07-01 06:45:00 -07:00
|
|
|
*
|
|
|
|
|
* <p>If startSingle() is used, the callback will run once. If startPeriodic() is used, the callback
|
|
|
|
|
* will run repeatedly with the given period until stop() is called.
|
|
|
|
|
*/
|
2018-05-24 16:56:29 -07:00
|
|
|
public class Notifier implements AutoCloseable {
|
2017-11-19 17:58:40 -08:00
|
|
|
// The thread waiting on the HAL alarm.
|
2018-05-24 16:56:29 -07:00
|
|
|
private Thread m_thread;
|
2023-09-15 19:59:03 -07:00
|
|
|
|
|
|
|
|
// The lock held while updating process information.
|
2017-11-19 17:58:40 -08:00
|
|
|
private final ReentrantLock m_processLock = new ReentrantLock();
|
2023-09-15 19:59:03 -07:00
|
|
|
|
|
|
|
|
// HAL handle passed to the JNI bindings (atomic for proper destruction).
|
2017-11-19 17:58:40 -08:00
|
|
|
private final AtomicInteger m_notifier = new AtomicInteger();
|
2023-09-15 19:59:03 -07:00
|
|
|
|
|
|
|
|
// The user-provided callback.
|
|
|
|
|
private Runnable m_callback;
|
|
|
|
|
|
2018-05-24 16:56:29 -07:00
|
|
|
@Override
|
|
|
|
|
public void close() {
|
2017-11-19 17:58:40 -08:00
|
|
|
int handle = m_notifier.getAndSet(0);
|
2018-05-24 16:56:29 -07:00
|
|
|
if (handle == 0) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2025-11-29 11:00:18 -08:00
|
|
|
NotifierJNI.destroyNotifier(handle);
|
2023-09-15 19:59:03 -07:00
|
|
|
// Join the thread to ensure the callback has exited.
|
2017-11-19 17:58:40 -08:00
|
|
|
if (m_thread.isAlive()) {
|
|
|
|
|
try {
|
|
|
|
|
m_thread.interrupt();
|
|
|
|
|
m_thread.join();
|
|
|
|
|
} catch (InterruptedException ex) {
|
|
|
|
|
Thread.currentThread().interrupt();
|
2015-12-17 16:19:44 -08:00
|
|
|
}
|
|
|
|
|
}
|
2018-05-24 16:56:29 -07:00
|
|
|
m_thread = null;
|
2017-11-19 17:58:40 -08:00
|
|
|
}
|
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
|
|
|
|
|
|
|
|
/**
|
2023-09-15 19:59:03 -07:00
|
|
|
* Create a Notifier with the given callback.
|
|
|
|
|
*
|
|
|
|
|
* <p>Configure when the callback runs with startSingle() or startPeriodic().
|
2015-12-17 16:19:44 -08:00
|
|
|
*
|
2023-09-15 19:59:03 -07:00
|
|
|
* @param callback The callback to run.
|
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
|
|
|
*/
|
2023-09-15 19:59:03 -07:00
|
|
|
public Notifier(Runnable callback) {
|
|
|
|
|
requireNonNullParam(callback, "callback", "Notifier");
|
2019-07-15 21:20:11 -04:00
|
|
|
|
2023-09-15 19:59:03 -07:00
|
|
|
m_callback = callback;
|
2025-11-29 11:00:18 -08:00
|
|
|
m_notifier.set(NotifierJNI.createNotifier());
|
2017-11-19 17:58:40 -08:00
|
|
|
|
2020-12-29 22:45:16 -08:00
|
|
|
m_thread =
|
|
|
|
|
new Thread(
|
|
|
|
|
() -> {
|
|
|
|
|
while (!Thread.interrupted()) {
|
|
|
|
|
int notifier = m_notifier.get();
|
|
|
|
|
if (notifier == 0) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
2025-11-29 11:00:18 -08:00
|
|
|
try {
|
|
|
|
|
WPIUtilJNI.waitForObject(notifier);
|
|
|
|
|
} catch (InterruptedException ex) {
|
|
|
|
|
Thread.currentThread().interrupt();
|
2020-12-29 22:45:16 -08:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-15 19:59:03 -07:00
|
|
|
Runnable threadHandler;
|
2020-12-29 22:45:16 -08:00
|
|
|
m_processLock.lock();
|
|
|
|
|
try {
|
2023-09-15 19:59:03 -07:00
|
|
|
threadHandler = m_callback;
|
2020-12-29 22:45:16 -08:00
|
|
|
} finally {
|
|
|
|
|
m_processLock.unlock();
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-15 19:59:03 -07:00
|
|
|
// Call callback
|
|
|
|
|
if (threadHandler != null) {
|
|
|
|
|
threadHandler.run();
|
2020-12-29 22:45:16 -08:00
|
|
|
}
|
2025-11-29 11:00:18 -08:00
|
|
|
|
|
|
|
|
// Acknowledge the alarm
|
|
|
|
|
NotifierJNI.acknowledgeNotifierAlarm(notifier);
|
2020-12-29 22:45:16 -08:00
|
|
|
}
|
|
|
|
|
});
|
2018-05-24 16:56:29 -07:00
|
|
|
m_thread.setName("Notifier");
|
2017-11-19 17:58:40 -08:00
|
|
|
m_thread.setDaemon(true);
|
2020-12-29 22:45:16 -08:00
|
|
|
m_thread.setUncaughtExceptionHandler(
|
|
|
|
|
(thread, error) -> {
|
|
|
|
|
Throwable cause = error.getCause();
|
|
|
|
|
if (cause != null) {
|
|
|
|
|
error = cause;
|
|
|
|
|
}
|
|
|
|
|
DriverStation.reportError(
|
2023-12-03 16:21:32 -08:00
|
|
|
"Unhandled exception in Notifier thread: " + error, error.getStackTrace());
|
2020-12-29 22:45:16 -08:00
|
|
|
DriverStation.reportError(
|
2022-12-12 01:42:22 -05:00
|
|
|
"The Runnable for this Notifier (or methods called by it) should have handled "
|
|
|
|
|
+ "the exception above.\n"
|
|
|
|
|
+ " The above stacktrace can help determine where the error occurred.\n"
|
|
|
|
|
+ " See https://wpilib.org/stacktrace for more information.",
|
2020-12-29 22:45:16 -08:00
|
|
|
false);
|
|
|
|
|
});
|
2017-11-19 17:58:40 -08:00
|
|
|
m_thread.start();
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-09 11:41:58 -08:00
|
|
|
/**
|
2020-12-29 22:45:16 -08:00
|
|
|
* Sets the name of the notifier. Used for debugging purposes only.
|
2019-11-09 11:41:58 -08:00
|
|
|
*
|
|
|
|
|
* @param name Name
|
|
|
|
|
*/
|
|
|
|
|
public void setName(String name) {
|
|
|
|
|
m_thread.setName(name);
|
|
|
|
|
NotifierJNI.setNotifierName(m_notifier.get(), name);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
/**
|
2023-09-15 19:59:03 -07:00
|
|
|
* Change the callback function.
|
2015-12-17 16:19:44 -08:00
|
|
|
*
|
2023-09-15 19:59:03 -07:00
|
|
|
* @param callback The callback function.
|
|
|
|
|
*/
|
|
|
|
|
public void setCallback(Runnable callback) {
|
|
|
|
|
m_processLock.lock();
|
|
|
|
|
try {
|
|
|
|
|
m_callback = callback;
|
|
|
|
|
} finally {
|
|
|
|
|
m_processLock.unlock();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Run the callback once after the given delay.
|
|
|
|
|
*
|
2025-02-10 07:23:04 -08:00
|
|
|
* @param delay Time in seconds to wait before the callback is called.
|
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
|
|
|
*/
|
2025-02-10 07:23:04 -08:00
|
|
|
public void startSingle(double delay) {
|
2025-11-29 11:00:18 -08:00
|
|
|
NotifierJNI.setNotifierAlarm(m_notifier.get(), (long) (delay * 1e6), 0, false);
|
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
|
|
|
}
|
|
|
|
|
|
2025-10-29 03:18:55 +00:00
|
|
|
/**
|
|
|
|
|
* Run the callback once after the given delay.
|
|
|
|
|
*
|
|
|
|
|
* @param delay Time to wait before the callback is called.
|
|
|
|
|
*/
|
|
|
|
|
public void startSingle(Time delay) {
|
|
|
|
|
startSingle(delay.in(Seconds));
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
/**
|
2023-09-15 19:59:03 -07:00
|
|
|
* Run the callback periodically with the given period.
|
2015-12-17 16:19:44 -08:00
|
|
|
*
|
2023-09-15 19:59:03 -07:00
|
|
|
* <p>The user-provided callback should be written so that it completes before the next time it's
|
|
|
|
|
* scheduled to run.
|
2022-07-01 06:45:00 -07:00
|
|
|
*
|
2025-06-30 20:21:11 -07:00
|
|
|
* @param period Period in seconds after which to call the callback starting one period after the
|
|
|
|
|
* call to this method.
|
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
|
|
|
*/
|
2025-02-10 07:23:04 -08:00
|
|
|
public void startPeriodic(double period) {
|
2025-11-29 11:00:18 -08:00
|
|
|
long periodMicroS = (long) (period * 1e6);
|
|
|
|
|
NotifierJNI.setNotifierAlarm(m_notifier.get(), periodMicroS, periodMicroS, false);
|
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
|
|
|
}
|
|
|
|
|
|
2025-10-29 03:18:55 +00:00
|
|
|
/**
|
|
|
|
|
* Run the callback periodically with the given period.
|
|
|
|
|
*
|
|
|
|
|
* <p>The user-provided callback should be written so that it completes before the next time it's
|
|
|
|
|
* scheduled to run.
|
|
|
|
|
*
|
|
|
|
|
* @param period Period after which to call the callback starting one period after the call to
|
|
|
|
|
* this method.
|
|
|
|
|
*/
|
|
|
|
|
public void startPeriodic(Time period) {
|
|
|
|
|
startPeriodic(period.in(Seconds));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Run the callback periodically with the given frequency.
|
|
|
|
|
*
|
|
|
|
|
* <p>The user-provided callback should be written so that it completes before the next time it's
|
|
|
|
|
* scheduled to run.
|
|
|
|
|
*
|
|
|
|
|
* @param frequency Frequency at which to call the callback, starting one period after the call to
|
|
|
|
|
* this method.
|
|
|
|
|
*/
|
|
|
|
|
public void startPeriodic(Frequency frequency) {
|
|
|
|
|
startPeriodic(frequency.asPeriod());
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
/**
|
2023-09-15 19:59:03 -07:00
|
|
|
* Stop further callback invocations.
|
|
|
|
|
*
|
|
|
|
|
* <p>No further periodic callbacks will occur. Single invocations will also be cancelled if they
|
|
|
|
|
* haven't yet occurred.
|
|
|
|
|
*
|
|
|
|
|
* <p>If a callback invocation is in progress, this function will block until the callback is
|
|
|
|
|
* complete.
|
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
|
|
|
*/
|
|
|
|
|
public void stop() {
|
2025-11-29 11:00:18 -08:00
|
|
|
NotifierJNI.cancelNotifierAlarm(m_notifier.get());
|
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
|
|
|
}
|
2021-02-28 22:05:26 -08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Sets the HAL notifier thread priority.
|
|
|
|
|
*
|
|
|
|
|
* <p>The HAL notifier thread is responsible for managing the FPGA's notifier interrupt and waking
|
|
|
|
|
* up user's Notifiers when it's their time to run. Giving the HAL notifier thread real-time
|
|
|
|
|
* priority helps ensure the user's real-time Notifiers, if any, are notified to run in a timely
|
|
|
|
|
* manner.
|
|
|
|
|
*
|
|
|
|
|
* @param realTime Set to true to set a real-time priority, false for standard priority.
|
|
|
|
|
* @param priority Priority to set the thread to. For real-time, this is 1-99 with 99 being
|
|
|
|
|
* highest. For non-real-time, this is forced to 0. See "man 7 sched" for more details.
|
|
|
|
|
* @return True on success.
|
|
|
|
|
*/
|
|
|
|
|
public static boolean setHALThreadPriority(boolean realTime, int priority) {
|
|
|
|
|
return NotifierJNI.setHALThreadPriority(realTime, priority);
|
|
|
|
|
}
|
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
|
|
|
}
|