The configurator should support control via a second controller.

The joystick axis range remapping can only be calibrated while remapping is disabled; otherwise, calibration would be inaccurate as it interprets the already-remapped joystick values as raw values. To fix, the configurator should disable configurations when calibration begins and re-enable them once calibration completes.

Note: the disable/enable command is all-or-nothing, so things like button remapping will be paused as well during calibration. May not be an issue, but something to be aware of.

I'm testing ps2plus on my portable & noticed the configurater is not outputting progressive video. I took a quick look at the code and it seems like you're trying to force 720p. I guess 480p would be sufficient, but idk how to correctly detect the current/max. video output anyways.

• Bootloader + Firmware (HEX file)
• Firmware (HEX file)
• Configurator (ELF application)

In addition to the artifacts being built, they should be named so that they contain the information about firmware version and microcontroller platform. Only tagged commits should have versioned releases -- we don't want to upload possibly corrupted artifacts.

Flesh out unit tests by implementing them against the "native" platform, which simulates a PS2+ controller on the compiler's platform. It obviously can't communicate with a real console, but it should be able to simulate enough of the device to test it's logic.

Also, it may be worthwhile to create unit tests that can run on-device. This would help to determine that platform abstractions are functioning properly.

Analog button currently doesn’t do anything. The firmware currently acts as just an indicator of whether the controller is in analog lock mode. The logic for the analog button should be:

• If in analog mode lock, do nothing
• Otherwise, toggle analog mode on button-up

I's very hard hitting a specific item in the configurator using the d-pad. it's nearly impossible to navigate & it's a matter of luck if you are going to hit the wanted button.

Scrolling doesn't seem to work, too.

Goals for a better versioning scheme:

• Support a more human-readable identifier (like SemVer)
  • Currently using a uint16_t as a flat number for the version number
  • Consider changing to something like uint64_t, with a byte pattern such as:
    • Major: 1 byte
    • Minor: 2 bytes
    • Patch: 4 bytes
    • Metadata: 1 byte (for example, dev for local builds, latest for automatic builds)
• Automatically bump patch version with every commit (?)
• Automatically create versioned and latest GitHub releases on commits
  • Use ps2link's GitHub Actions workflow as an example
  • Briefly:
    • For all commits, create a latest release that is tagged as prerelease
    • For commits which are tagged

Not sure what the best strategy is for making sure the versions in the application and in Git stay in sync. Maybe keep major/minor in code, and patch and metadata passed in from the environment. Patch number might be "number of commits since last tag", and tags will always be "<major>.<minor>.0". This could be problematic if the commit history isn't linear -- need to think about that.

I think there are some options missing in the configurator. IIRC they showed up when i stared the app for the first time, but now they are just gone.

The missing options are for the analog stick calibration & axis reset

The ability to remap the digital buttons and the joysticks axes could lead a user to being stuck in an unusable configuration state — for example, they may have forgotten to map a button to X, preventing them from opening the configurator. A button combo should be added that can be input/held down at any time to reset the configuration.

Maybe Triangle + L1 + L2 + R1 + R2 for 5 seconds?

In my setup all stick axes are inverted. currently there is no option to fix that in software. IMHO this should be able to fix using calibration

Firmware currently supports the rumble motor commands, but doesn’t output the rumble values to the pins.

Mimic the behavior of a real DualShock controller — after some amount of time with no communication from the console, the controller should automatically reset its state in preparation for a new, future connection.

As it is currently, disconnecting the controller would leave the controller in its current state which may be confusing for the console (or any games) which are expecting a new controller connection to start in plain digital mode.

The Curious Inventor documentation says:

Some controllers have a watch-dog timer that reverts back into digital mode if a command is not received within a second or so.

Doing containerized builds of the firmware/bootloader on Microchip hardware (i.e. the only current platform) requires installing XC8 and MPLAB X, running the prjMakefilesGenerator script, and then running Make. Replacing this with custom Makefiles that invoke XC8 directly would have some benefits:

• Eases ports to other Microchip hardware without inflating the MPLAB X project with additional configurations
• Eases ports to non-Microchip hardware as compiling must occur outside of MPLAB X anyway
• Allows development in any C editor or IDE (VS Code and CLion would be ideal)
• Significantly slimlines the build container image

Downside of this is potentially losing the ability to do on-device debugging.

All configurator code currently assumes the PS2+ is found on port 1. It should be able to manage one in any port, and switch between if there are multiple.

Also maybe part of this issue: allow standard controllers to navigate the UI, including while a PS2+ controller is being managed in another port. Maybe not a common use case, but could be another solution to flashing the firmware of a corrupted PS2+.

I currently have the problem that my analog sticks [switch analogs] are working at first, but suddenly stop working after a few seconds. It happens at the same time for both sticks and they never come back "alive". After reboot they are working again for a few seconds...

My original plan for the bootloader was to allow it to be used as a fallback digital controller in case the firmware was known to be corrupted. This would allow the user to at least be able to enter the configurator to attempt another firmware update.

Because of bootloader space constraints (self-imposed), I took out that functionality but would like to put it back in before calling this shippable, so that nobody is stuck with a bricked controller. Once I take out the strings from the source, there will probably be enough space; otherwise, I’ll have to change the space constraints on the bootloader and firmware.

Digital button inputs are currently read immediately and instead should be debounced slightly to account for any fluctuations (or should they?). The original PS2+ used a 3-frame debounce, but I don’t know how that would translate to wall clock time.