Add LTC294X Driver #359
Add LTC294X Driver #359
Conversation
| LTC294X { | ||
| i2c: i2c, | ||
| interrupt_pin: interrupt_pin, | ||
| model: Cell::new(ChipModel::LTC2941), |
There was a problem hiding this comment.
Is the 2941 a strict subset of the 42 and 43? (Or should there be a "NoChip" default in place before users call set_model?)
There was a problem hiding this comment.
Sort of? Everything that you can do to the 41 won't fail on the 42/43, but some of the bit fields have different meanings. Seems fine to just default to the simple one.
|
|
||
| fn done(&self) { | ||
| self.callback.get().map(|mut cb| { cb.schedule(3, 0, 0); }); | ||
| } |
There was a problem hiding this comment.
Could maybe re-order these functions so the callback #'s are in order?
| case 4096: M = 7; break; | ||
| default: M = 4; break; | ||
| } | ||
| } |
There was a problem hiding this comment.
Should this have an else { return ENOSUPPORT; } for a bad model here?
|
My biggest comment for all of these PRs (including #360 and #361) are that the capsule module could use much more commenting. What is this peripheral? What is it used for? How should I instantiate it? What is the high level system call interface? This is asking more than we have so far in most other capsules, but you know... constant improvement etc... I've updated the CRC driver with a structure of documentation I think starts to make more sense, so worth maybe copying a bit from there. I think these drivers will differ in more focus on describing the peripheral as well as documenting the non-system-call interface where it exists. |
The LTC294X is a series of coulumb counters for measuring energy use or battery state. The interface between the chips is similar but they do have different registers. This capsule tries to be general across the series of chips.
|
I think the changes I just made are getting closer to what you are looking for. While docs are good, what keeps me up at night was that I just put example code in the comment that could be invalid in the future, even if the code in the |
|
To that point, rust has a doctest mechansim that we could leverage to ensure that that code at a minimum remains compile-correct, right? |
|
@ppannuto in principle, yes, but we would need a way to compile and run (at least tests) on x86---we may not be that far from being able to do it though |
|
That, or we could look into integrating japaric's utest that runs tests
under qemu: https://github.com/japaric/utest
…On Thu, May 18, 2017 at 2:41 PM Amit Levy ***@***.***> wrote:
@ppannuto <https://github.com/ppannuto> in principle, yes, but we would
need a way to compile and run (at least tests) on x86---we may not be that
far from being able to do it though
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#359 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAUt3s8wLGeQ3a3W1eMvfxypuizOjIOSks5r7JD3gaJpZM4NFl1E>
.
|
The LTC294X is a line of coulomb counters we use on signpost.
The 2491/2/3 have slightly different register sets and the capsule tries to do the right thing based on which is on the board. The capsule defaults to the ltc2941, and lets the actual chip be set at runtime because it may not be known when the kernel is compiled (as is the case for signpost).