Comments (4)
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.
from hpi.
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.
from hpi.
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.
from hpi.
Sounds good. I will aim to tackle this this weekend.
from hpi.
Related Issues (4)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hpi.