Files
allwpilib/hal
James Kuszmaul 534ea134a4 artf4154: Get rid of raw pointers in C++.
This deals with the majority of the user-facing code
in wpilibC++Devices and a substantial portion of it in
wpilibC++. wpilibC++Sim and wpilibC++IntegrationTests
are untouched except where it is necessary to make them
work with the rest of the libraries.

There is still a lot to do in the following areas:
-The HAL (which we may not want to touch at all).
-The I2C, Serial, and SPI interfaces in wpilibC++Devices,
  which I haven't gotten around to doing yet.
-Most wpilibC++Devices classes have void* pointers
  for interacting with the HAL.
-InterruptableSensorBase passes a void *params for
  the interrupt handler.
-I haven't converted all the const char* to std::strings.
-There are plenty of other cases of raw pointers still
  existing.
-This doesn't fall directly under raw pointer stuff,
  but move syntax and rvalue references could be introduced
  in many places.
-I haven't touched vision code.
-The Resource classes conflict (one is in the hal, the other
  in wpilibC++). Someone should figure out a more
  permanent fix (eg, just renaming them), then doing
  what I did (making a new namespace for one of them,
  essentially the same as renaming it).

A few other things:
-I created a NullDeleter class which is marked as deprecated.
  What this does is it can be passed as the deleter to a
  std::shared_ptr so that when you are converting raw pointers
  to shared_ptrs the shared_ptr doesn't do any deletion if
  someone else owns the raw pointer. This should only be
  used in making old raw pointer UIs.
-I had to alter the build.gradle so that it did not
  emit errors when deprecated functions called deprecated
  functions. Unfortunately, gradle doesn't appear to be
  actually printing out gcc warnigns for some reason.
  The best way I have found to fix this is to patch
  the toolchains (https://bitbucket.org/byteit101/toolchain-builder/pull-request/5/make-gcc-not-throw-warnings-for-nested/diff)
  so that a deprecated function calling a deprecated
  function is fine but a non-deprecated function calling
  a deprecated function will throw a warning (which we
  then elevate with -Werror). I believe that clang
  deals with this properly, although I have not
  tried it myself.

Change-Id: Ib8090c66893576fe73654f4e9d268f9d37be06a2
2015-07-20 13:18:29 -04:00
..
2015-05-20 16:22:17 -04:00

Purpose

The HAL is a hardware abstraction layer that provides a uniform interface that can be used to access a number of primarily I/O features in the underlying platform. The features include:

  • Analog input, accumulation and triggers
  • PWM, Relay and Solenoid output
  • Digital input and output
  • I2C and SPI communication
  • Encoders and counters
  • Interrupts and Notifiers

The initial goal is to allow a higher level like WPILib to support both the CRIO and the upcoming Athena platform only by changing which version of the HAL it's running on.

Editing

You can always use any text editor and then build with Maven. There are also eclipse project files so that it can be edited in the same eclipse environment that teams develop with. For the AthenaXX, this can be found in the root directory of this project. It imports as an FRC Robot C++ Eclipse project. The Windriver project can be imported from the src directory.

Building with Maven

There are multiple build targets that the HAL supports. Instructions for setting up the environment and building each of these is described below. Current targets are listed below:

  • All: All of the following targets.
  • include: The header files for the HAL.
  • Azalea: CRIO C++ build.
  • AthenaXX: Athena Dos Equis C++ build.
  • AthenaXXJava: Athena Dos Equis Java build with auto-generated JNA wrappers.

Output from each build target is placed in the directory target/<target-name>. So, the Azalea output is placed in target/Azalea.

All

Note: Windows only due to the Windriver requirement.

  1. Ensure that C:\WindRiver\gnu\3.4.4-vxworks-6.3\x86-win32\bin is on the system path so that ccppc and arppc can be accessed.
  2. Set the environment variable WIND_BASE to C:\WindRiver\vxworks-6.3.
  3. Ensure that $HOME/wpilib/toolchains/arm-none-linux-gnueabi-4.4.1/bin/ is on the system path so that arm-none-linux-gnueabi-g++ and arm-none-linux-gnueabi-ar can be accessed.
  4. Checkout and install the NI-Libraries from Github: https://github.com/first/NI-Libraries.
  5. Run the following maven command: mvn clean install
  6. Success

include

  1. cd into the include directory: cd include
  2. Run the following maven command: mvn clean install
  3. Success

Azalea

Note: Windows only.

  1. Ensure that C:\WindRiver\gnu\3.4.4-vxworks-6.3\x86-win32\bin is on the system path so that ccppc and arppc can be accessed.
  2. Set the environment variable WIND_BASE to C:\WindRiver\vxworks-6.3.
  3. cd into the AthenaXX directory: cd AthenaXX
  4. cd into the Azalea directory: cd Azalea
  5. Run the following maven command: mvn clean install
  6. Success

AthenaXX

  1. Ensure that $HOME/wpilib/toolchains/arm-none-linux-gnueabi-4.4.1/bin/ is on the system path so that arm-none-linux-gnueabi-g++ and arm-none-linux-gnueabi-ar can be accessed.
  2. Install the include target.
  3. cd into the AthenaXX directory: cd AthenaXX
  4. Run the following maven command: mvn clean install
  5. Success

AthenaXXJava

  1. Ensure that $HOME/wpilib/toolchains/arm-none-linux-gnueabi-4.4.1/bin/ is on the system path so that arm-none-linux-gnueabi-g++ and arm-none-linux-gnueabi-ar can be accessed.
  2. Checkout and install the NI-Libraries from Github: https://github.com/first/NI-Libraries.
  3. Install the include target.
  4. cd into the AthenaXXJava directory: cd AthenaXXJava
  5. Run the following maven command: mvn clean install
  6. Success