HW Implementation Remaining

[Kevin-OConnor]

Giant list categorized into a couple big buckets of HW functionality left to implement:

Has HAL Method, not in SC NT - Do these exist as HW capabilities?

Power

• 3.3V Rail Voltage
• 3.3V Rail Current
• 3.3V Rail Active
• 3.3V Rail Current Faults
• Get/Set Brownout Voltage

Counter

• SetCounterEdgeConfiguration - Remove this?
• ResetCounter - Implement HAL side offset per discussion in UpDownCounter's .reset not currently resetting #129
• GetCounterPeriod - rateget updates in counter mode, periodget does not
• SetCounterMaxPeriod/GetCounterStopped - should we just implement this at HAL layer if we want to keep it?
• Class names at WPILib level are Tachometer and UpDownCounter (which no longer has ability to assign a down channel). Remove UpDownCounter?

DIO

• A whole bunch of PWM functions in here, axe these?
• A couple Pulse functions in here, axe these?

Serial Port

• There's no built in serial port. Axe these? Or is there a way to provide a friendly interface for devices that show up as USB Serial?

Has HAL Method, in SC NT, not in MRCLib

• Get CPU Temp

Has HAL Method, in SC NT, in MRCLib - just need to connect the dots

• Get Team Number

In SC NT, not in MRCLib or HAL - Do we want to expose any of these?

• CPU %
• ramAvail
• storage? (3 keys)
• faults subtable - what if anything here do we want to expose to user code?

Other

• GetAnalogValueToVolts/GetAnalogVoltsToValue - The math in these doesn't match what is in GetAnalogVoltage and these methods don't seem to be used? Can we get rid of them?

[bhjelstrom]

3.3V Rail Active (there's a duplicate of this in the list) and 3.3V Rail Current Faults are shared in that a fault means 3.3V is inactive. We have fault yes/no and a fault count, meaning number of frames in which a fault has been active. (updates at 500hz). These are in the faults and faultcounts tables, but it will be in a /sys/faults struct in upcoming releases

brownout:
/sys/vbrownout integer millivolts
/sys/vrecovery integer millivolts
This only affects pwm output. We don't turn off anything else on the system.

VBROWNOUT_DEFAULT = 6750;
VBROWNOUT_MIN = 5000;
VBROWNOUT_MAX = 8000;
VRECOVERY_DEFAULT = 7500;
VRECOVERY_MAX = 8500;

We force vrecovery to be at least 500mV above vBrownout

[ThadHouse]

I can pretty easily make the brownout affect the rest of the system. Is that set in NT anywhere, using the status from the RP2350 (I'm assuming the RP2350 actually handles it).

[bhjelstrom]

We will look into a fw update that lifts the brownout state out of the 2350. We might be able to fit the 3.3V rail current as well. 3.3V rail voltage is not available.

EDIT: Brownout is already available in the faults struct

[bhjelstrom]

• MC forwarding of enable,halt,disable
• 802.11w testing
• add usb IPs to display - done
• brownout - done (faults table)
• 3.3v rail current: done (/sys/current3v3)

[ThadHouse]

All the counter APIs in wpilibsuite/allwpilib#9230
All the brownout APIs in wpilibsuite/allwpilib#9238

[sciencewhiz]

• GetAnalogValueToVolts/GetAnalogVoltsToValue - The math in these doesn't match what is in GetAnalogVoltage and these methods don't seem to be used? Can we get rid of them?

I think so. I don't think they've been useful since the cRIO days (and even then only minimally useful)