NRF52 boards: Enable internal DC/DC regulator to reduce power consumption and enable OTA support for all boards

[fschrempf]

After checking the schematics of several boards, it seems like all those have the necessary components available to use the internal DC/DC regulator. Therefore enable it to reduce the power consumption on all those boards.

The only boards I'm not totally sure (but likely also have the LC circuit) are the "Nano G2 Ultra" and the "Thinknode M1". Therefore they remain unchanged for now until someone can test or confirm that they can use the DC/DC regulator.

This PR also adds OTA support for the three remaining board configs that haven't had it enabled and the moves the OTA-specific code to the Nrf52Board base class.

Please note that I have none of the boards available and these changes are untested.

[IoTThinks]

Now we have NRF52Board, NRF52BoardDCDC and NRF52BoardOTA.
Things start to get complex.

[fschrempf]

Now we have NRF52Board, NRF52BoardDCDC and NRF52BoardOTA.
Things start to get complex.

No they don't. Look at the code and you will see that it is not complex at all. The additional subclasses are simple wrappers that can be used to select the characteristics of the board by inheriting from them. If you think a different approach is better than I'm open for discussing it. But please stop making such comments without any reasoning and explanations of what you mean. It doesn't help. Thanks!

[IoTThinks]

If we have a new NRF52 board, how will we know which parent classes to extend from?

[fschrempf]

@IoTThinks If you don't like the style with the additional subclasses, ok. Maybe it would be better to have a single class and some properties to select the behavior. I don't have strong opinions here and if we find a better way we can go for it. But maybe you could try to be more constructive with your feedback (same in my other PR) instead of just telling me that things are too complex in your opinion. Thanks!

[fschrempf]

If we have a new NRF52 board, how will we know which parent classes to extend from?

Currently you won't know unless you read the existing code of other boards. But that's the same, no matter how the different board features are implemented (subclasses, properties, methods), right? And before my rework in #1201 it was even more difficult to understand and everyone just kept copying some others board's code without understanding which parts are needed and which not.

Maybe the Nrf52BoardDCDC class even can be removed once we find out that all boards can use this feature.

[IoTThinks]

I mean no offense.
I'm just saying things get complex.

I feel if we have a new NRF52 board, I don't know which parent to extend from.
Is there anyway we can detect if a board supports DC/DC or OTA?
Except RAK, I believe most NRF52 boards are similar?

[fschrempf]

Is there anyway we can detect if a board supports DC/DC or OTA?

No we can't detect it, but we can probably make DCDC and OTA the default in the future for all boards. I was just doing refactoring and keeping the current state of each board to not cause any regressions. All boards NRF should be capable of OTA so we can integrate that into the base class.

[IoTThinks]

No we can't detect it, but we can probably make DCDC and OTA the default in the future for all boards. I was just doing refactoring and keeping the current state of each board to not cause any regressions. All boards NRF should be capable of OTA so we can integrate that into the base class.

DCDC works for my RAK4631 and Lilygo T-echo lite.
True, we may need another round to optimize the parent class after your refactoring.
Go ahead.

BTW, for "Nano G2 Ultra" and the "Thinknode M1", I guess you can put a uf2 file for them here.
Hope someone with these boards can test the DCDC.

[fschrempf]

I mean no offense.
I'm just saying things get complex.

Ok, no worries. The complexity you are talking about was there before my changes. My changes only made it more visible. Before we had a lot of redundant code where nobody even was able to grasp the board features without extensive research in the code.

[fschrempf]

DCDC works for my RAK4631 and Lilygo T-echo lite.

Ok, good to know. The thing is that even if a board should not have the components for the DCDC available, I think it doesn't hurt to try enabling the DCDC. It will fail, but do no harm. At least that's what I would expect. So maybe we should just go ahead and move it to the base class.

[fschrempf]

@IoTThinks I now added two further commits in this PR that enable OTA for all boards and remove the Nrf52BoardOTA class. For enabling the DCDC for all boards I will leave that open for now. Maybe we can find out more about it.

[IoTThinks]

Yes, love to have all NRF52 boards to behave consistently.