way of writing something to display about ht16k33 HOT 7 CLOSED

I am comparing this library to that of https://github.com/pimoroni/fourletter-phat written in python.

from ht16k33.

Why would you only want to set one led at a time?

from ht16k33.

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.

from ht16k33.

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 :)

from ht16k33.

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.

from ht16k33.

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.

from ht16k33.

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.

from ht16k33.