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

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.

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.