Setting to disable DFU and FS access
This PR adds setting to disable firmware update and Bluetooth file transfer. This is 2. part for https://github.com/InfiniTimeOrg/InfiniTime/issues/1814#issuecomment-1763740314
Build checks have not completed. Possible reasons for this are:
- The checks need to be approved by a maintainer
- The branch has conflicts
- The firmware build has failed
Both issues discovered by the workflows should now be fixed.
- I have force-pushed fix for the formatting error in
SettingOTA.cpp. - For InfiniSim I have created https://github.com/InfiniTimeOrg/InfiniSim/pull/125 Building this PR with InfiniSim PR should fix the InfiniSim build issue.
The build-simulator step is expected to fail, because it needs https://github.com/InfiniTimeOrg/InfiniSim/pull/125
Made two improvements:
- Added branch prediction hints, to minimize performance impact during real data transfer
- Return
BLE_ATT_ERR_INSUFFICIENT_RESwhen access is not allowed
Could it be possible to review this PR?
Rebased as well.
Is this PR (and the other PR described in https://github.com/InfiniTimeOrg/InfiniTime/issues/1814#issuecomment-1763740314 ) welcome? If I will rebase and adjust this PR to work with the latest changes, will it be merged? @JF002, @FintasticMan, @Avamander Any feedback from project maintainers would be appreciated.
Rebased (against main) and adjusted this PR. And done a few tests on my PineTime.
If there are questions about b2e2690adfbc13cbf4e0778a428baa6b11b35fba please see branch https://github.com/DavisNT/InfiniTime/tree/otaset-oom - this branch has the memory saving as the last commit (trying to build otaset-oom without last commit should cause the build to fail with /opt/gcc-arm-none-eabi-10.3-2021.10/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: region RAM overflowed with stack).
Regarding https://github.com/InfiniTimeOrg/InfiniTime/pull/1891/commits/b2e2690adfbc13cbf4e0778a428baa6b11b35fba So one option is to decrease the heap size a notch so more RAM is free for static alloc. This is going to happen soon anyway as there are very few bytes free I'm not 100% sure why the original approach was taken, really @JF002 would have to chime in on this. I suspect that it's to ensure that classes only have access to certain controllers etc? The memory savings look good though