Improve Sound

[Apehaenger]

Think this is how it can be done.

This PR mainly:

• Switch to Makuna's DFMiniMp3 lib for a better support of DFPlayer clones
• Adds a couple of advert and background sounds
• Support volume control and language switch (English and German) via CoverUI (but will not save it at the moment)

SD-Card Structure Problem (old/new sound implementation):

I assumed that >90% of the installations in the wild, will have the original DFRobot DFPlayer with the old SD-Card-Structure installed.
Because DFRobot's DFPlayer has the quirk to auto-play the first sound in SD-Cards root, after a reset(), I detect an old SD-Card-Structure in that way, that if there's an auto-played sound with a specific length (shorter than the one of the new SD-Card-Structure) then it's identified as "old SD-Card-Structure". For sure, this works only for those who have an DFRobot DFPlayer.

This (shall) result in the following behavior (tested with a couple of DFPlayer and SD-Cards):

DFPlayer	SD-Card-Structure	Plays
DFRobot	old	"Hi", krk, "Hi, I'm Steve ...". No further sound output
DFRobot	new	"Ping" (3-5 times), "Hi I'm Steve ...". No further sound output

Overcurrent problem on 3.3V (Pico) line

All current OM installation (with sound) already play "Hi", krk, "Hi, I'm Steve ..." and we haven't heard of died Pico (VREG) till now.
So this sound PR also stop (by default) after "Hi, I'm Steve ...", except it got compiled with DFPIS5V (already added to CI firmware build)
For sure this doubles our firmware binaries :-/ But does it matter?

Warning
Of course, everybody is free to install a DFPIS5V firmware without changing his DFPlayer to 5V, but we should expect that he has read README-Sound, DFPIS5V.md before, and knows about the risk

firmware.zip

[Apehaenger]

Did a quick look to open_mower_ros for this sound + #84 PR integration.
Doesn't look very complicated.

1. I could add a ll_config struct with i.e. 'dfp_is_5v' as well as a 'language' member (ll_datatypes.h & mower_comms.cpp) and let him fire the packet i.e. once a second
2. Mod openmower FW in that way that
   1. a received ll_config member get stored in flash
   2. Emergency only get released once there's a valid config stored

But I've some questions/doubts:

1. Once LL FW has a valid config stored, it wouldn't wait for a ll_config packet again and play sound immediately (with the option that an ll_config get received which disabled sound again via dfp_is_5v=false
2. Wouldn't it be better if LL FW request HL for an ll_config packet instead of cyclic send by HL?

[Apehaenger]

Yes exactly, I thought about a configuration packet where we can set key/value pairs. LL board shall store the configuration and only allow to exit emergency once it has some valid configuration.

Just checked how to implement ClemensElflein/open_mower_ros#79 in LowLevel code.
Think we shouldn't lock in emergency due to our latest discussion about packet (backward) compatibility.
In addition my current ClemensElflein/open_mower_ros#79 implementation will be somehow fragile when i.e. flashing pico with a running open_mower_ros. In special if someone change to DFPIS5V=false and flashes Pico afterwards. He wouldn't get a config packet but would use the old flash-stored configuration probably with a previous DFPIS5V=true!

Think we either need a cyclic send (i.e. 1-10s) config packet from HL side, or a separate "getConfig" packet from LL which request HL to send the config packet.
I personally would prefer the cyclic send config packet, because it would give us easier possibility to change settings on the fly (some when)

[Apehaenger]

Merged all together now.
Did a couple of tests:

• All mower_config configurations
• Both languages
• Config storage into flash
• Config read from flash storage on reboot
• Validated nv_config's sector_erase as well as page_write's for not wear level flash

Look all fine and it's working on my desktop.
If weather is good on Sunday, I'll do some final practice tests.

Please take into account that the following PR is also needed: ClemensElflein/open_mower_ros#80

If interested in a quick test, binaries are already available in my fork: https://github.com/Apehaenger/OpenMower/releases/tag/latest

[Apehaenger]

Just started a real practice test on my SA type mower. All looks working as expected. Don't see any issues.

[ClemensElflein]

this doesn't work anymore

[Apehaenger]

Fixed/noticed in my readme.
Will check about the official docs (fully outdated regarding the official docs because I still use the first ones).
We probably also need to notice somewhere, that "save to flash" happen only once a minute?

[Apehaenger]

Took a while to get it running with Hugo. After I realized that docsys template is to old for recent Hugo versions, and downgraded to Hugo v0.110.0, all looks as expected (for me).

Integrated now all sound relevant infos to the official docs ClemensElflein/openmower.de#33.
Or do you notice anything wrong or missing?

[ClemensElflein]

before merging we should mention the "the player just plays everything"-issue somewhere (missing resistors in 0.13 kit); also if there is a guide somewhere we should mention those resistors.