jasonpeacock / ht16k33 Goto Github PK

The ht16k33 library should be of high quality - review the API guidelines checklist and apply them.

This should be broken down into smaller issues for the major points of the API guidelines, otherwise it will live on forever....

Update the code and all dependencies to support no_std for embedded use.

Currently the DisplayDataAddress is implemented as a bitflags struct when it does not need to. It does not need to implement bitwise operations.

It would make more sense as to implement it as an c-like enum. If implemented with num_enum traits we would also gain the ability to convert from primitive numbers back and fourth to DisplayDataAddress with methods ::TryFrom(..) and syntax as row as u8.

With merge #12 , resolving #7 , we now have no_std support. Need to release a new version (0.4.0) to crates.io for consumption.

The i2c_mock implementation supports local development and simulates a basic HT16K33 device, but it does not persist values across invocations.

Add some sort of persistence - local /tmp files? TOML format?

Exit criteria: Values written to HT16K33 are able to be read back on later invocations when using the i2c_mock implementation.

Currently, only the setting of LEDs is supported, but the HT16K33 can do so much more...need to add support for keyscan to read button presses.

More info:

• http://www.holtek.com/productdetail/-/vg/HT16K33
• https://www.partsnotincluded.com/electronics/controlling-led-matrix-with-the-ht16k33/
• https://learn.adafruit.com/diy-3d-printed-handheld-pocket-game-tiny-tetris-snake

I have (re)discovered that you can write to a single address on the ht16k33 chip, but thought nothing of it until now. It would clearly be useful to have this feature, but I think that there is more to this. I have not checked if you can continue to write more than one buffer but I suspect its true. This technique is clearly used in the set_led method. The method signature would be some kind of range of buffer addresses and a return type of Result<(), E>. An example pub fn write_address(&mut self, address: Range) -> Result<(), E>

    pub fn set_led(&mut self, location: LedLocation, enabled: bool) -> Result<(), E> {
        // TODO Validate `address` parameter.
        self.update_display_buffer(location, enabled);

        self.i2c.write(
            self.address,
            &[
                location.row.bits(),
                self.buffer[location.row_as_index()].bits(),
            ],
        )?;

        Ok(())
    }

Currently, only support for write operations. Can we read from the chip what the current settings are? And then return those values?

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.

Follow the embedded-hal interface such that the ht16k33 is usable by other HAL projects, and such that other platforms beyond linux can easily be supported.

A travis-ci account has been created and linked with this repo, but no builds are running because there is no .travis.yml configuration.

Exit Criteria: A .travis.yml configuration is added that enables Rust CI best-practices & OSX support with Travis CI, and builds are passing.

Rust CI best-practices:

• https://docs.travis-ci.com/user/languages/rust/

For inspiration:

• https://github.com/sharkdp/hyperfine/blob/master/.travis.yml

The HT16K33 is available in different size SOP package types, each has a different number of pins available for ROW, COMMON, etc.

Currently, the library only supports the largest, the 28-pin SOP package.

Exit Criteria: Support all HT16K33 SOP package types.