0

I'm writing a hardware driver for the raspberry pi 2 with C++.

The driver uses the SPI bus to talk to a radio chip. I made a class Radio and put all those functions that talks to the chip into that class. Some of those functions are writeToRegister, readFromRegister, setRadioPower, enterSleepMode readTxBuffer, readRxBuffer to name a few...

The issue here is that this class will be going to have only one object like Radio radio. There will be no need to be created more than one objects cause it's a class which contains functions that talks to the hardware and there's only one piece of hardware.

The question here is: What is the best way to deal with classes like that?

I don't want to do it with C, I want to learn more stuff about C++.

Improve this question
4
  • Singleton classes aren't inherently bad. It is still useful if you put all the functions related to this hardware into one class, for example to separate it from the bus connection used and the communication protocols being run over the radio link.
    – Hans-Martin Mosner
    Commented Jul 21, 2019 at 11:12
  • 1
    @MrBit "What is the best way to deal with classes like that?" My short answer [or terse, or closed form answer] to that is: "Deal with this using dependency injection. Same way as with non-unique dependencies."
    – Nick Alexeev
    Commented Jul 21, 2019 at 13:29
  • If you're writing drivers for public use, you can't necessarily assume there's going to be only one instance of this hardware in the system. If you know that your code is only going to be used for your particular scenario and is not intended to be made public, then feel free to use Singletons object.
    – Lie Ryan
    Commented Jul 22, 2019 at 3:59
  • @LieRyan, I'm not writing a library for public use. I'm making a service. It's only for personal use for now.
    – MrBit
    Commented Jul 22, 2019 at 17:21

1 Answer 1

Reset to default
3

You assume that you will have one radio. Obviously you might have zero radios, and there is no reason to believe that there could never be multiple radios.

To be future proof: Have a class that returns some kind of description for each available radio hardware. You'd probably return this information as an array. If there is no radio hardware, return an empty array. If there is more than one radio hardware, return an array with more than one item.

Then you have a class representing one radio hardware. The constructor takes one of these descriptions, and returns a class controlling that radio. You might want only one such object per available radio hardware, so the constructor would fail if the description is not valid, or the radio hardware is already in use (it would probably be good if this happened even if the radio hardware is in use by another application).

A user of your code will get the array of descriptions. If the array is empty, they can't create a radio object. Otherwise, if they don't care that there might be multiple radios, they create a radio object for the first descriptor. In the future there may be multiple descriptions, then they can update their software to pick the best radio, or use multiple radios.

Improve this answer
1
  • To add: In a context where dynamic creation of Radio objects is unwanted, or discovery is impossible, a similar scheme would be used with a hard-coded descriptor object being passed to the Radio object.
    – Bart van Ingen Schenau
    Commented Jul 22, 2019 at 7:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.