jasonpeacock / led-bargraph Goto Github PK

The original idea was to daemonize with a given command, but that's overkill. The desired feature is really run some command automatically & frequently and update the bargraph with those values.

This can be achieved more simply (following the unix philosophy) by taking the value to display from STDIN, so that it can be included as part of a piped command, and then other unix tools (like watch, cron, etc) can be used to run the data-gathering command and send the result to led-bargraph.

An example using cron looks like this:

# Use the output of `my-command` to set the value in the bargraph within a range of 24
* * * * * my-command | led-bargraph set --range 24

Note The current cmdline doesn't have a --range option, the API will need to be rethought to better support such automated use cases more cleanly.

Failure: https://travis-ci.org/jasonpeacock/led-bargraph/jobs/459210422

2 issues:

• The script ran even though there was no TRAVIS_TAG env var set and the YAML has tags: true set. Something is wrong with the configuration.
• The script ran even though the TRAVIS_TAG env var is empty - the -o nounset option should have failed it early?

Exit Criteria:

• .travis.yml updated to correctly configure builds to only attempt release when tags are present.
• The script validates its inputs better. Switch to use cmdline args instead of env vars?

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

Currently the display blinks when a the value is greater than range (over-full). Add a similar mode where the display blinks when below a given threshold, like a low-fuel warning gauge.

Exit criteria: The display blinks when the value is below a threshold.

The display blink is currently automatic and not configurable, based on built-in logic.

Exit criteria: New command line options to support direct control of the display blinking.

There's a bunch of Todo items in the README.md, let's convert them to github issues so they can be managed.

To support development, virtual devices, remote LED displays, etc, add a --show option that will display the current LED bargraph on the commandline using ASCII art, with appropriate terminal colors and blinking (where possible).

The --show option should work with all current options, including no options - in which case it will read the LED display and show the current values. If the LED display is a virtual device, or missing, it will show an empty (blank) LED display (same as what you would see after sending the clear command).

• Add --show cmdline option, pass through from binary to bargraph library.
• Display ASCII representation of LED bargraph display, dynamically resizing to fit the configured display.
• Retrieve current display value from the LED device (requires new support from the ht16k33 library).
• Update the ASCII display with the retrieved values.

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

Early versions of led-bargraph had a --steps N option to configure the resolution (# of bars) available in the bargraph display.

This was removed when the library & application was refactored to support #12 and hardcoded to be 24 (the resolution of the Adafruit bargraph).

Exit Criteria: A --resolution N option to configure the the # of bars available in the display, with error handling/validation to ensure the value is reasonable (e.g. positive) and the right thing happens when the range > resolution.

With issue #1 the source path of the binary changed from src/main.rs to the more correct src/bin/led-bargraph.rs, which also changes the name of the binary from led_bargraph to led-bargraph.

This is good, and ideally enables document generation to also work now as there's no more conflict between the library and binary names.

Exit Criteria: Release a new version of led-bargraph to crates.io, as v0.1.1.

Currently the bargraph is always displayed in the same orientation. But what if you need to hang it upside down?!

Need a cmdline option to reverse the bargraph direction.

We want to support customers using led-bargraph with different LED drivers, not just ht16k33, need to define an interface for interaction.

Does the embedded-hal project apply here?

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

Also, the ht16k33 project is switching to the embedded-hal interface, and this needs to be updated to use the latest changes:

• jasonpeacock/ht16k33#4