Quick Vent, LED updates

[nomakewan]

This PR does the following:

-Adds placeholder sounds for Slime Tether, Shock Blast, and Meson Collider -Adds ability for standalone wand to play additional Proton Stream impact SFX -Adds new unique Quick Vent function which is shorter than overheating fully -Adds sanity check to EEPROM read function that will reset the EEPROM to default if CRC does not match -Changes LED calls which were only on/off from analogWrite to digitalWrite -Cleans up 1984/1989 functionality on Hat Light 1 -Cleans up Proton Pack initialization process -Corrects default EEPROM values for various wand settings -Corrects EEPROM LED function name mismatch -Corrects Hat Light 2 functionality and adds 1984/1989 functionality -Corrects LED documentation in Neutrona Wand header file -Corrects misplaced steam SFX and N-Filter strobe when overheating in Slime Mode -Corrects Power Cell functionality on first Proton Pack boot-up -Corrects Power Cell functionality when hot-swapping wands -Corrects Power Cell timing when settings are loaded from EEPROM -Corrects switching firing modes or exiting menus causing unexpected Power Cell illumination -Corrects wand-side Proton Stream additional SFX not obeying user setting -Removes random impact effects from CTS firing -Switches several timer start calls to restart for efficiency

[nomakewan]

A few notes on this PR to hopefully clear up a few potential questions. First and foremost, while this PR does lay the groundwork for introducing alternate fire modes for the video game weapons, I have no intention of implementing said changes until after V5.0.0 is out the door and I have my hands on one of the new Frutto barrel LEDs. This is because they will definitely need some barrel effects work, and I'd rather be able to figure those out on my own rather than relying on others to fix them for me.

Likewise the new "quick vent" functionality lays the groundwork for a proper heat management system run by the Neutrona Wand. However, as implementing this system would also require creating a new "BARGRAPH_VIDEO_GAME" BARGRAPH_MODES feature to go along with it, this will not be something I'm going to be working on until after V5.0.0 is out the door. However I do look forward to working on it as Frutto is apparently working on some TVG electronics to go along with it.

The new hat light changes are as follows:

All Modes -Hat Light 1 no longer strobes with overheating -Hat Light 2 is now dedicated to overheating indication

1984/1989 -Hat Light 1 turns on while firing, and is off otherwise -Hat Light 2 strobes when starting to overheat, is on solid when overheating, and is off otherwise

Afterlife/Frozen Empire -Hat Light 1 turns on when ready to fire, and is off otherwise -Hat Light 2 strobes when starting to overheat, is off when overheating, and is on otherwise

Finally, the removed impact sounds from CTS were because CTS was already quite busy, and every time we see CTS used it isn't in a situation which had impact noises like the regular proton stream does. So to "declutter" the CTS firing, the proton impact sounds are disabled.

[nomakewan]

Latest push adds a sanity check to the function that reads from the EEPROM so that if the CRC does not match, the EEPROM will be cleared to default values.

The first time I loaded this firmware to my wand, the volume setting was incorrect due to a shift in where the address for the volume was stored. I resolved it already by just entering the EEPROM config menu and clearing the EEPROM, but hopefully by including this new sanity check the requirement to manually clear the EEPROM will be alleviated.

[nomakewan]

I moved the venting sequence out of the cyclotron control loop; hopefully that resolves the cyclotron going dark while venting as that was not intended behavior. Essentially while quick venting the pack and wand should remain fully functional but unable to fire again until the sequence completes, and the cyclotron speeds should revert to normal. At the moment this doesn't do anything because you'd have to stop firing to use Quick Vent (which already reverts the cyclotron speed to normal), but once there's a heat management system it will become more relevant.

[nomakewan]

Okay, I believe I've fixed the powercell issue now. packOffReset() was normally resetting the timer for the powercell 100% of the time because it was being called in an endless loop whenever the pack was off. This was corrected in the audio branch so that it's only called once, but the problem was that it was not called the very first time the Talentcell was powered on because the header file defined b_reset_start_led as true (which is what it should do, to be clear).

So I just took the missing timers from packOffReset() and added them to the pack's initialization process. Hopefully that resolves the issue.

[gpstar81]

Works good.

Also is it a new thing when power is first turned on for the system that the first LED in the powercell lights up and stays on?

[nomakewan]

Works good.

Also is it a new thing when power is first turned on for the system that the first LED in the powercell lights up and stays on?

It's probably new. While that's how some other kits work I'm pretty sure GPStar was always lights-off on initial startup. I'm sure it's just another variable that wasn't reset properly before the timer started, let me take another poke.

[nomakewan]

Yep, was just another missed call. Should be okay now.

[gpstar81]

Yep, was just another missed call. Should be okay now.

Working good.

[gpstar81]

actually did some more testing, it's still there.

[nomakewan]

That's odd; it should be setting all the LEDs to black before restarting the timer. Is it only happening when the Talentcell is first turned on, or have you found it happening at any other times? Like say, does it happen when you overheat due to firing and everything ramps down and shuts off before turning back on again?

[gpstar81]

When there is no wand, it seems to come on then off after two seconds.

Then when I connect a wand, it comes back on during the sync.

Though sometimes it doesn't come on during a power startup.

I wonder if it's something to do with the EEPROM loading and resetting something and something might be called at the same time while the fast led update is skipped leaving it on?

[gpstar81]

It is in sync with the wand. When the wand vent light goes out during the turn on phase and it syncs, the powercell led comes back on. I haven't checked the code yet to see if anything was added in that phase recently, I suspect something may have, to do with showing a sync status between the pack and wand?

[nomakewan]

I'm gonna rest on it a bit but I think you're onto something. There is indeed a call to reset some LEDs after reading the EEPROM so that could be part of it. I'm going to convert this PR to a draft for the moment until it can be resolved. If you get to it before me though, feel free to commit!

[nomakewan]

Okay, as a note I found the problem, and it is indeed part of the serial data handshake procedure. However, the reason why that is there is because at the moment there's no failsafe for yanking a wand while in the settings menu. I'll look into implementing that failsafe functionality and fix the handshake in a few hours once I'm back.

[gpstar81]

hmm, I thought the pack would return back to its previous mode or proton mode while in the setting menu and the wand get's disconnected?

[nomakewan]

Okay. After staring at how each of the four menus (Settings while on, Settings while off, EEPROM LED, EEPROM Config) work as well as how the various handshakes and reset vectors work, I believe the changes I've just pushed should put this one to bed once and for all. At least until it's time to clean up some more code, perhaps.

I've left commented out the ability for the pack to save any in-progress settings it had in an EEPROM menu if it was in the menu when a wand was hot-swapped. At the moment the pack actually has no clue whether it's in the EEPROM Config menu or not as that entire menu is handled by the wand, however, so to do this correctly a new variable would have to be introduced to let the pack keep track of whether it's in the menu or not. So like I said, for now, it's just commented out.

Please give this a test and see if it works as expected. Especially test:

1. Initial Talentcell power-on w/o wand.
2. Initial Talentcell power-on w/ wand.
3. After turning on Talentcell w/o wand, plug in wand.
4. Hotswap wand while pack is off.
5. Hotswap wand while pack is on.
6. Hotswap wand while in settings menu with wand and pack off.
7. Hotswap wand while in settings menu with wand and pack on.
8. Hotswap wand while in EEPROM LED Menu.
9. Hotswap wand while in EEPROM Config Menu.

Do note that the act of yanking out the wand isn't what triggers exiting menus; it's actually the act of connecting a new wand. So having the pack be "stuck" in the EEPROM LED menu after removing a wand, for example, is expected behavior.

[gpstar81]

1 through #9 all works correctly.

Just one odd thing I notice. When doing the first turn on of the pack (ion arm switch), the powercell automatically lights up the first and 2nd LED together at the same time before doing the regular ramping up. When shutting the pack down and turning back on (not talent cell, but the red ion arm switch), it is correct with the correct pause between the 1st and 2nd led during startup.

The rest seems good.

[nomakewan]

1 through #9 all works correctly.

Just one odd thing I notice. When doing the first turn on of the pack (ion arm switch), the powercell automatically lights up the first and 2nd LED together at the same time before doing the regular ramping up. When shutting the pack down and turning back on (not talent cell, but the red ion arm switch), it is correct with the correct pause between the 1st and 2nd led during startup.

The rest seems good.

Does that happen every single time you start the pack from the ion arm switch the first time, or only in certain pack/wand configurations?

[gpstar81]

Every time

[nomakewan]

New update rearranges the pack initialization process and fixes two checks elsewhere in the code that were looking at incorrect variables. This significantly cleans things up and make it a lot easier to follow what exactly is happening and why, but I am not confident that this cleanup alone will resolve that odd Power Cell behavior on first ion arm switch powerup. In fact, if the bug is actually somewhere in the reset function it could expand this bug to happen on every ion arm startup instead.