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

[fschrempf]

Note: This is basically a follow-up for #1201 which is already merged to dev.

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 contains follow-up patches for #1201 to remove duplicated board code for boards that were added at the same time as the PR and therefore were missed.

This PR also adds OTA support for the T1000E as only remaining board config that hasn'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.

[fschrempf]

@fdlamotte This is basically a follow-up of the refactoring you have merged in #1201. It also enables the DC/DC regulator for all NRF52 boards that are known to be able to use it. If you feel like this is appropriate, please consider merging it. Thanks for your time!

[IoTThinks]

Looking to have everything to merge into NRF52Board in main.
E.g: To retire NRF52BoardDCDC and NRF52BoardOTA.

All boards have the same MCU NRF52480 so they should support the same feature.
For OTA, except RAK which may use a different bootloader, all other boards is the same.

[fschrempf]

All boards have the same MCU NRF52480 so they should support the same feature.

This statement doesn't make sense from a purely logical viewpoint. We have the MCU-level and we have the board-level. Some features depend on the wiring and peripherals on the board-level. Therefore it is wrong to say that all boards with the same MCU have the same features.

For OTA, except RAK which may use a different bootloader, all other boards is the same.

We can't control what bootloader is used and as far as I know the OTA integrated in the firmware which we have control over is independent of the bootloader. I agree that OTA for NRF52 doesn't really depend on the board-level which is why this PR removes NRF52BoardOTA and includes OTA support for all NRF52 boards in the base class.

On the other hand the availability of the DCDC regulator does depend on the board level which is why NRF52BoardDCDC makes sense. We could implement the same in the base class, but that's purely a matter of taste. Sticking to an OOP pattern makes sense IMHO.

[fschrempf]

@fdlamotte @ripplebiz @liamcottle Would you mind taking a quick look at this PR? I know it's a boring one 😉, but it would be really good if we can get it merged. Thanks!

[fdlamotte]

Hi, will try to catch up ... but I'm not using OTA so I'd need people to validate the behavior is ok ;)

[fschrempf]

Hi, will try to catch up ... but I'm not using OTA so I'd need people to validate the behavior is ok ;)

Sure, thanks! Just keep in mind that this is almost purely refactoring. So no changes in behavior for OTA to expect.