This is one of the calls with the delayed IPC. In the past, teams have
called an IsMode function so much that their code would start lagging.
This adds a cache, so the data is updated either when new data arrives
and we are notified of it, or after 50ms has passes since the last time
the cache was checked and updated.
* Converted enumerated constants in wpilibj to enums and made their implementation more consistent
* Reflowed text in JNI calls and updated JNI signatures
* Switches HAL to fixed length signed integers, and adds our own HAL_Bool type
* Replaces HAL Floats with Doubles
Doubles are just as fast as floats with optimizations turned on, so
switches to all doubles. All made doubles for consistency.
* Prepends HAL/ to HAL include files. Also fixes some range errors
Also added scripts for EOF newline management and for removing trailing whitespace. configure.bat was rewritten to use CRLF line endings. Documentation for the existing scripts was also improved.
HAL Port is using a special handle, where the module and pin are bit
shifted straight into the handle. This is one of the few special cases
we have, but for the way port is used it is much cleaner and uses much
less memory. Plus it is generic and not specific to one type.
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.
In case of Spontaneous wake ups, we should be checking a condition
variable as well.
Note that we can not use the existing m_newControlData, as that has a
possible race condition with existing user code that it does not look
like we could work around.
CANJaguar is the only motor controller using sync groups, so that feature doesn't belong in an interface used by all motor controllers. If teams want to use sync groups, they should cast to the appropriate motor controller type themselves.
First part of the HAL changes. Returns -1 to 1 for joysticks instead of
-128 to 127. Implemented by replacing the old structure with a new
structure that uses floats instead of shorts.
Currently, about 5ms of every 20ms loop the DS thread would hold
the mutex, while grabbing data. During this time, and call to grab
joystick data would be blocked. This change grabs the joystick data
to a cache, and then grabs the mutex and moves the data references
around. This is much more efficient then the old code, and gives
teams more of their teleop loop time back for use.
Another major change this does is use preallocated arrays when entering
the JNI. Previously every JNI DS call would allocate an entire new array.
With a GC'd language where those arrays go on the heap, thats a problem,
and creates tons of garbage. That garbage is no longer created anymore,
as all arrays and byte buffers sent to JNI in the DS are preallocated.
In addition, GetJoystickName was always returning joystick 0 data, which
this fixes.
There was a lot of duplicated code between all 7 PWM speed controllers.
This moves all the duplicated code down to a base class, that will make
it easier to add speed controllers in future years if needed again. Also
if we need to add a method to all speed controllers, we only have to do
it in 1 place, and not 7.
Change-Id: I25eb1d097c0f5f7dbd7656db2f4a30d006d50f98
Ensure the POR, PWR, and CST error bits are not set when reading the sample.
Reported by: Jared Russell, Austin Schuh
Change-Id: Ib38178d6b51880480aee86e13c16f9ba89a80693
Java was using integer division for calulating Timer values, which
was causing Timer values to be concatinated, and only accurate
to the nearest millisecond. This changes it to use double division,
which matches C++ and makes timing much more accurate
Change-Id: I61b893f4ad5791bf4dfdd767ee4346c1ed4ea418
In the Java implementation, "result" is an instance variable (to avoid
needing to perform a memory allocation on each call to getAngle). However,
this means that calls to getAngle() from multiple threads can step on each
other. Synchronize the method to avoid this issue.
Reported by: Jackson Gray (http://www.chiefdelphi.com/forums/showthread.php?threadid=145124)
Note this does not synchronize accesses between configuration methods such
as calibrate() and accessor methods such as getAngle().
Change-Id: I9ecc962d4fba66f6134fd801cfd607f155b41fe5
