Closed nilscript closed 3 years ago
I am comparing this library to that of https://github.com/pimoroni/fourletter-phat written in python.
Why would you only want to set one led at a time?
I have been sketching on a solution. I have added 2 new methods to the HT16K33 object, namely update_row_mask(..) and set_row_mask(..) alongside some minor re-factorization. Tests and documentations are not done. Would these additions be of any use to the driver?
//lib.rs
impl HT16K33 {
//...
pub fn update_row_mask(&mut self, row: DisplayDataAddress, mask: DisplayData) {
// TODO Validate `address` parameter.
self.buffer[row.bits() as usize] = mask;
}
///...
pub fn set_row_mask(&mut self, row: DisplayDataAddress, mask: DisplayData) -> Result<(), E> {
self.update_row_mask(row, mask);
self.i2c.write(
self.address,
&[row.bits(), self.buffer[row.bits() as usize].bits()],
)
}
//...
}
This would allow me to build higher level functions elsewhere in the project if such functions are welcome here.
I'm done sketching and added docs and tests. I have created a pull request. #16
I should probably also mention @jasonpeacock the maintainer, as I've been talking to myself. Well it's summer. Maybe you're on vacation :)
Correct, ht16k33
is a low-level library that implements the HT16K33 interfaces 1-1, and thus provides no additional methods. The chip doesn't know how your LEDs are arranged, they could be a seven-segment display or a multi-color bargraph. There should be a higher-level library specific to your HW arrangement which provides the convenience methods to easily write characters or plot bargraph values.
For example, I wrote led-bargraph
which implements the Adafruit LED Bargraph using the ht16k33
library, and it provides the knowledge of how the LEDs are arranged on the Bargraph display.
The update_display_buffer
function only takes a single LED location because that's how the actual HT16K33 chip works. Either this library, or the user, would need to provide an outer loop to update all the LEDs values before calling write_display_buffer
to update all the LEDs at once. I did not provide that loop because not all HW has an arrangement of LEDs that can be predictably iterated over in a way that makes sense - the LED bargraph uses the multiplexing to address the different Red, Yellow, Green LEDs in each bar of the graph.
But, with all that said, I don't see a reason to not provide such a mask method as you describe, as it can be useful for some people without adding a lot of support burden or assumptions to the API. I'll take a look at your PR.
With further investigation and usage of the library I would also like to request a (probably) final method. Raw mutable access to the display_buffer
. As I understand it, the buffer does not have illegal states as the ht16k33 also does not have illegal buffer states (I think). Then raw access should be exposed.
I am a bit busy this week and can't create a pull request for the time being. But thanks for you're collaboration and feedback so far. I hope I wasn't to intrusive making pull request without feedback, but I had my project at a stand still so I made changes anyway and rolled with them. The changes has been tested on real hardware, although not much of testing has been made.
I've been thinking, why can't the display buffer just be a buffer of u8? Any way I look at it display_data type is just a subset of u8.
I can't find the way of printing letters and numbers to the display. Are those methods not present at all? Or are they low level functions? I can't find any examples in the documentation.