OO Digital Pin class: single class or separate in and out classes

Single class : ) Also it makes it easier to configure up loads of GPIO from an array etc. I would prefer it instead of DigitalOut and DigitalIn style. Usually it's very clear from the object name whether it is an input or output anyway (e.g. LED, Button). Input or output mode becomes only an incidental footnote kind of thing with single class approach, pushing more complexity into the class. I don't know if this is good or bad from software purist point of view!

Take a look at WiringPi,  as an example how the single class API can be structured: http://wiringpi.com/reference/

I like how it can abstract MCU GPIO and IO expanders under the same API.

if you need bite-wide read/write, it does it too.

On the basis of your points above, what you are essentially describing is a variable: you can set a value and you can read a value.  I don't think that would benefit from being encapsulated by a class and methods (note however, that in Smalltalk everything is a class, and, for example, the number 9 is an instance of class Integer.  That was a great language but of course you can do a lot more than just represent numbers in Integers.)  Notwithstanding...

Once you get into a situation of "If pinIsSettable Then setValue else throw exception" within method code, you've stepped outside OO paradigm (broken encapsulation) which is the situation with your single class. Thus separate classes work but a writable pin is a specialisation of a readable pin and thus WriteablePin could be considered to inherit from ReadablePin rather than be viewed as a sibling of some abstract superclass (a WriteablePin is also a ReadablePin and works for polymorphic purposes.)  Whether an abstract superclass for ReadablePin is required is debatable (alongside a debate for creating classes for simple pins you describe in the first place.) 

As a mind exercise, purely for the purposes of your question, that is how I would do it.

Taking it further though, I would say that there has to be a better reason for encapsulating MCU pins in classes:

1. do you want to abstract a specific MCU implementation behind a "genericised" framework to be applicable across multiple MCUs?  ("genericised" isn't an English word by the way but you get the point I hope!)  So that your framework and code that interacts with it needs to nothing about the MCU itself, which is hidden in the framework through Configuration code/data.
2. do you want to encapsulate an MCU named pin, e.g. RA0, behind something with a more domain friendly name, e.g. new IntermediateSenseLight(RA0).  In this case, IntermediateSenseLight might inherit from WriteablePin and could have domain specific code associated with it.  Having something like ReadablePin intermediateSenseLight = new ReadablePin(RA0) seems a bit daft to me: feels like a lot of work when you could just #define intermediateSenseLight RA0 and refer to the friendly name throughout your code. 
3. perhaps there is more functionality associated with a pin that you want to encapsulate?  E.g. a Pin could be configured to have these characteristics in any non-mutually exclusive combination: Input, Output, Digital, Analog, Pull up, input level control, slew rate control, open drain, a read variant (e.g. RA0), a write variant (e.g. LATA0) [I've been working with PICs recently!!] Things get complicated to genericise that little lot and could well be a lot of code overhead for restricted RAM!
4. It may be that Pins could be referenced as a set (Shabaz hints at this): e.g. again with PIC, pins are grouped and can be referenced through registers, e.g. PORTA, LATA, WPUA etc.  Thus, it is possible to write TRISA = 0b01100100 which would set pins RA0, RA1,RA3,RA4,RA7 as input and RA2,RA5,RA6 as outputs all in one operation. Doing something similar you could then collect instances of pins in Vectors or Dictionaries and operate on them as a group via helper classes/methods.

I suspect the MCU you're thinking of (a Rensas MCU by any chance??) is not at all like a PIC I used as an example and you've thought of some specific reasons why it might be worth doing this.  TBH, I think it needs to be more than just setting and reading but it's an interesting discussion topic if you want to expand further.

I've tried it with a single class, as suggested by shabaz and ggabe .

You'd use it like this:

#include <IO.h>

io::IO led(GPIO_PORT_H_PIN_2);  // initialise the output pin for the LED.
io::IO button(GPIO_PORT_2_PIN_7); // push button

int main(void) {

	int i;
    while(1) {
    	led = button;

    	// silly wait
    	for (i = 0; i < 100000; i++) {nop();};
    }

Header (API):

namespace io {

typedef gpio_port_pin_t pin_t;
typedef gpio_dir_t dir_t;

class IO {
public:
	IO(pin_t pin);
	virtual ~IO();
    IO &operator!= (IO &rhs); // take over the inverted state of rhs
	IO &operator= (IO &rhs); // take over the  state of rhs
	IO &operator= (bool high);
	operator bool() const;
	void setDirection(dir_t dir);
protected:
	pin_t pin;
private:
};

The button behaves like a button, the led as a led. 
For the programmer/user, they act as variables.

Andrew J said:

On the basis of your points above, what you are essentially describing is a variable: you can set a value and you can read a value.  I don't think that would benefit from being encapsulated by a class and methods

I'm not trying to encapsulate a variable. I'm trying to make GPIO pins act as if they are a variable.

You can set state by setting the value:

drive LED pin high:

led = true;

You can get current state (both out and in), by reading the value:

read LED or button pin:

state = led;

state = button;

led != led; // toggle led

led = button; // adapt led to the state of the button

While they act as variables, in the background they call the microcontroller APIs and write / read different registers.

Examples of the implementation of the "set" and "get":

IO &IO::operator= (bool high) {
	R_GPIO_PinWrite(this->pin, (gpio_level_t)high);
	return *this;
}

IO &IO::operator!= (IO &rhs) {
	R_GPIO_PinWrite(this->pin, (gpio_level_t)!((bool)rhs));
	return *this;
}

IO::operator bool() const {
	gpio_level_t l = R_GPIO_PinRead(this->pin);
	return (bool) l;
}

In essence, I abstracted gpio pins, that are controlled via several registers, into a single boolean "variable".

Andrew J said:

... Thus separate classes work but a writable pin is a specialisation of a readable pin and thus WriteablePin could be considered to inherit from ReadablePin rather than be viewed as a sibling of some abstract superclass (a WriteablePin is also a ReadablePin and works for polymorphic purposes.)

MBED has taken one of your suggested approaches. Both In and Out are different classes, with no superclass.

Andrew J said:

Once you get into a situation of "If pinIsSettable Then setValue else throw exception" within method code, you've stepped outside OO paradigm (broken encapsulation) which is the situation with your single class.

That, I think is debatable. And a reason for creating this forum post :). 
What I have done for now, is: accept a write to an input pin. It will not change its status, but when you switch it from an input to an output pin, it will output that value.

Andrew J said:

I suspect the MCU you're thinking of (a Rensas MCU by any chance??) is not at all like a PIC

I am working with a Renesas - but it could be any controller that has resource bandwidth for the c++ footprint.

In the pic world microchip provides helper structs defining each pin as a bit field

#define LATA LATA
extern volatile uint16_t LATA __attribute__((__sfr__));
typedef struct tagLATABITS {
  uint16_t LATA0:1;
  uint16_t LATA1:1;
  uint16_t LATA2:1;
  uint16_t LATA3:1;
  uint16_t LATA4:1;
} LATABITS;
extern volatile LATABITS LATAbits __attribute__((__sfr__));


#define led LATAbits.LATA0

led = 1;
led ~= led; // etc....

Not c++, but simple.

That's what I'm working with - and where my examples came from!  These could be OO-ified (I'm full of new English words today.)

The controller I'm using does the same:

Setting a bit: PORTH.PODR.BIT.B2 = 0

(the construct is a set of structs and unions that 'll get you up to bit level. Same as the microchip.)

The thing is that it has different paths for reading and writing 

Reading a bit: PORTH.PIDR.BIT.B2 

I could solve this by setting:

#define led_read = PORTH.PIDR.BIT.B2 
#define led_write = PORTH.PODR.BIT.B2 

led_write = 1;
led_write ~= led_read; // etc

scottiebabe said:

Not c++, but simple.

I took this (maybe most) simple example explicitly, because it's constrained enough to get a brainstorm going.