Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FAST 2nd-Gen Hardware: Support for V2 Controllers #1629

Merged
merged 104 commits into from
May 22, 2022

Conversation

avanwinkle
Copy link
Collaborator

FAST 2nd-Generation Hardware Support

This PR merges a branch that includes support for the second generation of FAST platform hardware, including both direct-drive controllers and Retro controllers. It contains numerous other improvements and upgrades as well.

All changes have been verified on both V2 hardware and V1 hardware (i.e. the Nano), so these changes are fully backwards-compatible on existing hardware setups with no configuration changes needed.

The future!

V2 Hardware Controllers

The base work of this PR is to support to the second generation controllers, which have a number of differences from the first generation. In the code, these "V2" controllers are considered the default and the "V1" controllers are identified as is_legacy.

  • All switches and drivers are considered "local" by default
    • The concept of "network" switches/drivers is reserved for V1 hardware
  • Controller ID: strings that don't explicitly include NET are assumed to be NET

Retro Hardware Controllers

One family of V2 hardware is a set of Retro controllers for drop-in replacement in older machines. Retro controllers are configured in one of three flavors: wpc95, wpc89, and sys11.

This PR refactors the deprecated FAST WPC configuration options and uses those old code paths as the basis for the Retro hardware integration. This PR also extends the FastHardwarePlatform to inherit from the System11OverlayPlatform, which enables System11 behaviors when the Retro board is type sys11. For all other controllers, the overlay has no effect.

Other changes related to the Retro controllers include:

  • Support for A/C relay-controlled drivers (Sys11)
  • Support for platform ticks behavior (Sys11)
  • Updated map of addresses (formerly the WPC-series of mappings)
  • Only one serial port is exposed, instead of four like the direct-drive controllers
  • A controller configuration command (CH:) is required at connection, to ensure compatibility and prevent possible damage if a machine configuration is connected to the wrong type of Retro board

BREAKING CHANGE: This PR removes support for the FAST WPC hardware. Only a handful of these controllers were ever manufactured and none were sold publicly. No such hardware is known to be in existence anymore, but if anybody is still using driverboards: wpc in their configuration, they cannot update to this version of MPF.

Other Changes

  • Port auto detection has moved to its own file and has been improved to detect all generations of controllers
  • The System11 overlay is now configurable to be ignored via config file, so other hardware platforms can similarly implement System11-compatible controllers on the same codebase as their other controllers
  • Per-controller port configuration (NET, DMD, RGB, etc)
  • Remove logging of Watchdog commands to reduce noise during debugging
  • Logging and error messaging has been improved throughout
  • Lots of tests

it's rad

avanwinkle and others added 30 commits November 26, 2020 12:39
# Conflicts:
#	mpf/platforms/fast/fast.py
# Conflicts:
#	mpf/platforms/fast/fast_serial_communicator.py
@avanwinkle
Copy link
Collaborator Author

@jabdoa2 I've updated the code per our conversation, to reduce the FAST-specific workarounds.

On the topic of the System11 Overlay, after further investigation I believe that the recursive loop would impact all platforms except virtual—even the SNUX sample configs rely on virtual, which itself has its own implementation of validate_coil_section and validate_switch_section. My research indicates that any platform that inherits from System11Overlay will have the recursion, so my solution was to move the recursion fix out of Fast and into the System11Overlay code itself. That way the mitigation is not specific to Fast, but universal to any System11 platform.

@sonarcloud
Copy link

sonarcloud bot commented Mar 14, 2022

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@toomanybrians toomanybrians self-assigned this May 20, 2022
@toomanybrians toomanybrians merged commit ab094f5 into missionpinball:dev May 22, 2022
@avanwinkle avanwinkle deleted the fast-retro branch December 4, 2023 23:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants