Update ArduinoHal.h to make spi and friends protected

[jp-bennett]

Most of the "override" functions here can't actually be overridden in a useful way when spi, spiSettings, and everything else is marked private. If everything is override, then nothing should be private.

[HeadBoffin]

What about the God Mode option?

[jp-bennett]

What about the God Mode option?

Yes, that's how we'll manage this for now, but seems like a sub-par solution. Has too many side-effects, and isn't designed for a long term solution.

[jgromes]

I'm not sure I understand why this is necessary. Methods of ArduinoHal are not supposed to be overriden themselves, they are overriding the virtual methods from RadioLibHal, which is the base class of ArduinoHal. Though perhaps I'm missing something in your use-case.

[HeadBoffin]

What about the God Mode option?

Yes, that's how we'll manage this for now, but seems like a sub-par solution. Has too many side-effects, and isn't designed for a long term solution.

I mean't will God Mode continue to be available if this is merged?

[jp-bennett]

I'm not sure I understand why this is necessary. Methods of ArduinoHal are not supposed to be overriden themselves, they are overriding the virtual methods from RadioLibHal, which is the base class of ArduinoHal. Though perhaps I'm missing something in your use-case.

We already use ArduinoHal as a parent class, and override spiBeginTransaction and spiEndTransaction to do some extra locking. It would be very useful to override spiTransfer to make use of the multi-byte transfer() methods available on some platforms.

Edit to clarify, this usage is from the Meshtastic project. The exact problem I'm seeing is that the single-byte writes bounces the chip select line for each write, when Linux itself is controlling the CS.

I mean't will God Mode continue to be available if this is merged?

Yes, should continue to work the exact same way. This change would just make these objects accessible for inherited classes, when god mode is turned off.

[jgromes]

@jp-bennett thank you for the extra context, that makes the request quite clear. I think we can have the members protected to allow easier customization of the HAL.