Typeclass for monads that support I2C (and SPI) communication

[dmcclean]

Would you support splitting out into a separate package:

class MonadI2C m where
  writeI2C :: Address -> ByteString -> m ()
  readI2C :: Address -> Int -> m ByteString
  writeReadI2C :: Address -> ByteString -> Int -> m ByteString

(Or possibly similar types that provide a bit more feedback in the case of errors?)

If that package existed (I can write it up and put it on hackage) and this package provided an instance of it for raspberry pi, then device drivers for I2C slaves could be written without taking a direct dependency on the HPi package but could still be used with it.

(There could be another similar monad for SPI communications.)

[WJWH]

While I like your idea of being able to write I2C drivers without regard to the host platform, I am a bit hesitant to implement it in the way you stated. In my opinion, there are two main problems with it

• I think that setting GPIO pins and using the I2C bus should be in IO. After all, few things can be more IO related than actually writing values to pins. Introducing a typeclass for this will mainly serve to confuse type signatures.
• I'm not sure what a complete set of functions for the class should look like. For example, setting the bus speed is not currently in the class. On the other hand, the "writeReadI2C" function is based on the bcm2835_i2c_write_read_rs function from the underlying C library, which seems to be a hack to work around a shortcoming in the Raspberry Pi's I2C functionality (ie, it enables a repeated start command without an intervening stop command). Other hardware platforms may not have this shortcoming and so would not require this.

I feel that a complete interface for I2C communications should be defined before any generic typeclasses are defined. However, wheter the hardware platforms are similar enough remains to be seen.

[dmcclean]

You raise some interesting points.

I'm not sure I understand the first objection about it being in IO. Granted, the only monads that will be able to be useful instances will be some sort of wrapper around IO, but a typeclass for it is still useful because it allows restriction of what other IO activities the functions are allowed to use, if any. Thus we can be assured that the driver doesn't do any other monkey business.

As to the second objection: I agree that setting the bus speed shouldn't be in there, but I see that as a good thing. The driver for an individual slave shouldn't be setting the speed for the entire bus, which in general impacts all slaves. So continuing to require the bus settings to be specified in a platform-dependent way doesn't seem like an impediment to platform independent slave drivers.

We can provide a default implementation of writeReadI2C in terms of writeI2C and readI2C to deal with platforms that don't support repeated start in the same way. I have seen several RTOSs that use a similar approach to bcm2835_i2c_write_read_rs so that the interrupts can be setup to handle the repeated start at full bus speed without requiring driver interaction, so I think that is actually a quite common pattern.

The only thing that it seems difficult to provide support for is variable length reads, where the master decides how many bytes to ACK based on the content of the ones it has seen so far. But the bcm2835 library doesn't support this, and neither do most of the others I've seen. I also can't really recall having come across a slave device protocol where this would be especially useful and the performance cost of simulating it with multiple read transactions would have been too high.

[WJWH]

Sorry for the late comment, life got in the way a bit. I'm not against a generalized interface for I2C.

I have always been of the opinion that writing restricted IO monads only seems a good idea when writing higher level interfaces for the users of a library or something. If you can't trust driver writers not to do too much monkey business, who can you trust? Anyway, it should be a moot point since they can always take IO as a base monad again if they want.

Regards the variable length reads, I think we should err on the "YAGNI" side. As you say, it is very rare when just simulating it with multiple read transactions is not sufficient. And let's be honest, if you really are writing super high performance (and possibly hard real time) I2C drivers, Haskell on a Raspberry Pi is a wring choice of platform anyway. So let's just keep the small interface you initially proposed and add things if they become necessary?

Can you write the package with the class and put it up? I will then add the instance for the Raspberry Pi to this package.

[dmcclean]

Sounds good. I will aim to tackle this this weekend.