mirror of
https://github.com/wpilibsuite/allwpilib
synced 2026-06-19 00:41:43 +00:00
534ea134a4
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
78 lines
3.0 KiB
C++
78 lines
3.0 KiB
C++
/*----------------------------------------------------------------------------*/
|
|
/* Copyright (c) FIRST 2008. 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 $(WIND_BASE)/WPILib. */
|
|
/*----------------------------------------------------------------------------*/
|
|
#pragma once
|
|
|
|
#include "DigitalSource.h"
|
|
|
|
class AnalogTrigger;
|
|
|
|
/**
|
|
* Class to represent a specific output from an analog trigger.
|
|
* This class is used to get the current output value and also as a
|
|
* DigitalSource
|
|
* to provide routing of an output to digital subsystems on the FPGA such as
|
|
* Counter, Encoder, and Interrupt.
|
|
*
|
|
* The TriggerState output indicates the primary output value of the trigger.
|
|
* If the analog
|
|
* signal is less than the lower limit, the output is false. If the analog
|
|
* value is greater
|
|
* than the upper limit, then the output is true. If the analog value is in
|
|
* between, then
|
|
* the trigger output state maintains its most recent value.
|
|
*
|
|
* The InWindow output indicates whether or not the analog signal is inside the
|
|
* range defined
|
|
* by the limits.
|
|
*
|
|
* The RisingPulse and FallingPulse outputs detect an instantaneous transition
|
|
* from above the
|
|
* upper limit to below the lower limit, and vise versa. These pulses represent
|
|
* a rollover
|
|
* condition of a sensor and can be routed to an up / down couter or to
|
|
* interrupts. Because
|
|
* the outputs generate a pulse, they cannot be read directly. To help ensure
|
|
* that a rollover
|
|
* condition is not missed, there is an average rejection filter available that
|
|
* operates on the
|
|
* upper 8 bits of a 12 bit number and selects the nearest outlyer of 3 samples.
|
|
* This will reject
|
|
* a sample that is (due to averaging or sampling) errantly between the two
|
|
* limits. This filter
|
|
* will fail if more than one sample in a row is errantly in between the two
|
|
* limits. You may see
|
|
* this problem if attempting to use this feature with a mechanical rollover
|
|
* sensor, such as a
|
|
* 360 degree no-stop potentiometer without signal conditioning, because the
|
|
* rollover transition
|
|
* is not sharp / clean enough. Using the averaging engine may help with this,
|
|
* but rotational speeds of
|
|
* the sensor will then be limited.
|
|
*/
|
|
class AnalogTriggerOutput : public DigitalSource {
|
|
friend class AnalogTrigger;
|
|
|
|
public:
|
|
virtual ~AnalogTriggerOutput();
|
|
bool Get() const;
|
|
|
|
// DigitalSource interface
|
|
virtual uint32_t GetChannelForRouting() const override;
|
|
virtual uint32_t GetModuleForRouting() const override;
|
|
virtual bool GetAnalogTriggerForRouting() const override;
|
|
|
|
protected:
|
|
AnalogTriggerOutput(const AnalogTrigger &trigger, AnalogTriggerType outputType);
|
|
|
|
private:
|
|
// Uses reference rather than smart pointer because a user can not construct
|
|
// an AnalogTriggerOutput themselves and because the AnalogTriggerOutput
|
|
// should always be in scope at the same time as an AnalogTrigger.
|
|
const AnalogTrigger &m_trigger;
|
|
AnalogTriggerType m_outputType;
|
|
};
|