Tons of questions! See if I can answer them.
MarsWarrior:
I haven't used DS18B20's before, but if you are not using rom addresses, how can you tell which sensor is which (ie indoors, outdoors, basement) ??
The Cosa OWI interface allows several ways to handle the rom address but I guess that you are concerned with the rom address not being a parameter. The Cosa OWI has two parts; the OWI bus and the OWI device driver. The OWI bus knows about communication while the OWI device driver is a device on the bus. It holds its rom address. It can obtain the address as a parameter to the instance (typically from EEMEM) or by connecting to device using the search command. In this case an index is used. To use this you need to order the devices according to their rom addresses on the wire.
MarsWarrior:
So now I'm exploring your Pin design and have some questions:
- The base class is the Pin
- Then there is an InputPin and an OutputPin, but also an AnalogPin. Why is this AnalogPin not an InputPin?
- The AnalogPin does have an on_change() method, but the digital InputPin doesn't, why?
Hum, Pin is actually an input pin to avoid multiple inheritance. So AnalogPin can be used for digital input. And the Board pin definitions for analog pins is accepted for both InputPin and OutputPin.
The on_change() method has to do with the ISR-Event Handler and is not an observer pattern. If that is what you are asking for? There is an analog conversion completed interrupt. All pins cannot generate pin change interrupts (as I understand the hardware). And there are only a very limited number of pins for external interrupts.
The most important aspect of the Pin class hierarchy is actually performance and abstraction. The Wiring function library is a very slow design and implementation. And not very object-oriented. It is also very difficult to scale to larger designs. There is a lot of calculations and lookups that are done for every digitalRead/Write that are unnecessary. This can be cached on initialization or even better at compile time. There are a few attempts to use templates instead of instances for modeling the hardware resources. Basically code generating each pin instance. This give even higher performance.
I have used some of these techniques for the Cosa Queue, IOBuffer and Offscreen Canvas. Great performance improvements 
MarsWarrior:
And then some for the interrupt handling & use of those interrupts:
- The External and PinChange Interrupts are modelled as an InputPin. No problem with that, but why the difference between External and PinChange interrupts?
- The reason for the above one is this: I have boards that sometimes have the INT pin wired to a hardware int, and sometimes to another pin (ie pinchange). I would like my classes just to respond to an interrupt, regardless of the fact if it is hardware or pinchange...
The difference is in the hardware and how pin changes are detected in for instance power down. The next item I regard to be a configuration problem and in Cosa I see that as how you instantiate objects and inherit from classes. Actually from the application perspective it is an Interrupt Handler which is the common super class for both interrupt types (external/pin change). I see that as a modeling aspect. There are several approaches to this.
MarsWarrior:
And in line with the above:
You seem to make a difference between SPI/SoftSPI, TWI/SoftTWI. That is logical, but some of the devices seem to be hardwired to the SPI driver if I'm not mistaken, ie you can't just have the same sensor/device either (or both) talk over SoftSPI and SPI?? Or is it possible to pass the actual SPI device to the sensor/device?
SPI and TWI is work in progress as I would like to allow multiple SPI/TWI bus managers and both software and hardware at the same time. Right now these are singletons (global variable) and may be redefined depending on the application. Drivers only know about the "symbol". This is up to debate as there are other ways to model this relationship. Also allowing both software and hardware version would be nice given a common interface. SPI and TWI do not follow the delegation pattern that I have used in much of the design. They might evolve in this direction it would give a more flexible design.
BW, Cosa does not include a Soft TWI right now and the Soft SPI is MOSI only. Plenty of work to do in that area. But still the SPI and TWI handling with iovec is a quantum leap forward compare to what is in the Arduino IDE box. Writing drivers becomes so much easier
Cheers!