TM1637 7-segment display driver #21112
Conversation
KSKNico
requested review from
leandrolanzieri,
aabadie and
MichelRottleuthner
as code owners
github-actions
bot
added
Area: doc
There was a problem hiding this comment.
thx, this looks quite good to me.
The CI has a few comments (check in the code view here):
- One line is longer than 100 chars, please add a line break
- A few files have no terminating newline. (Btw: What editor are you using? Maybe we can add a config to our repo that your editor will pick up. IMO it is better to automate such tedious style things and concentrate.)
Btw: I think negative numbers and leading zeros will result in the minus sign to be overwritten by a zero, or did I read the code incorrectly?
There was a problem hiding this comment.
Thanks, great code quality! I have mostly nits below.
You've rightfully already mentioned #20981. IIRC, the idea was there to provide a unified driver for different kinds of 7-segment displays. How does yours differ and could it be integrated somehow? Otherwise, we should rename the driver in the other PR back to something more specific.
| * @brief Brightness level enum for the display | ||
| * | ||
| * @note The brightness is defined as a fraction of | ||
| * the pulse width and must be on of the given values. |
There was a problem hiding this comment.
| * the pulse width and must be on of the given values. | |
| * the pulse width and must be one of the given values. |
There was a problem hiding this comment.
also, I don't fully understand the sentence here. The brightness being a fraction of the pulse width is an implementation detail not really interesting to the user, right?
| * | ||
| * @note The integer can't be bigger than 9999 or smaller than | ||
| * -999 as only 4 digits can be displayed at a time. | ||
| * With the leading zeros enabled, the display is padded with zeros. |
There was a problem hiding this comment.
| * With the leading zeros enabled, the display is padded with zeros. | |
| * When leading zeros are enabled, the display is padded with zeros. |
| * @param[out] dev device descriptor of the display | ||
| * @param[in] params configuration parameters | ||
| * @return 0 on success, error otherwise |
There was a problem hiding this comment.
would be slightly easier to read if the params are aligned, as in
| * @param[out] dev device descriptor of the display | |
| * @param[in] params configuration parameters | |
| * @return 0 on success, error otherwise | |
| * @param[out] dev device descriptor of the display | |
| * @param[in] params configuration parameters | |
| * @return 0 on success, error otherwise |
It is apparently not explicitly mandated by the coding convention, but that's how I've seen it everywhere across RIOT until now.
There was a problem hiding this comment.
same for the rest of this file, obviously :)
| * and the number. | ||
| * | ||
| * @param[in] dev device descriptor of the display | ||
| * @param[in] number number to write, in the range of 9999 to -999 |
There was a problem hiding this comment.
| * @param[in] number number to write, in the range of 9999 to -999 | |
| * @param[in] number number to write, in the range of -999 to 9999 |
feels a bit more natural to me
drivers/tm1637/Makefile
Outdated
| USEMODULE += ztimer | ||
| USEMODULE += ztimer_msec | ||
| USEMODULE += periph_gpio | ||
|
|
There was a problem hiding this comment.
| USEMODULE += ztimer | |
| USEMODULE += ztimer_msec | |
| USEMODULE += periph_gpio |
those should go (and mostly are already) in Makefile.dep. Specifying periph_gpio in FEATURES_REQUIRED should also be enough, I think.
| * | ||
| * @param[in,out] segments segments to enable the colon on | ||
| */ | ||
| static void enable_colon(uint8_t *segments) |
There was a problem hiding this comment.
| static void enable_colon(uint8_t *segments) | |
| inline static void enable_colon(uint8_t *segments) |
| void tm1637_clear(const tm1637_t *dev) | ||
| { | ||
| uint8_t segments[DIGIT_COUNT] = { 0, 0, 0, 0 }; | ||
| transmit_segments(dev, segments, TM1637_PW_1_16); |
There was a problem hiding this comment.
why this specific brightness?
| assert(number <= 9999); | ||
| assert(number >= -999); | ||
|
|
||
| uint8_t segments[DIGIT_COUNT] = { 0, 0, 0, 0 }; |
There was a problem hiding this comment.
| uint8_t segments[DIGIT_COUNT] = { 0, 0, 0, 0 }; | |
| uint8_t segments[DIGIT_COUNT] = { 0 }; |
does the same, and doesn't hard-code DIGIT_COUNT ;-)
| if (leading_zeros) { | ||
| for (int i = 0; i < DIGIT_COUNT; ++i) { | ||
| if (segments[i] == 0) { | ||
| segments[i] = segments_array[0]; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
wouldn't this overwrite the minus sign set above in line 251?
| if (number != 0) { | ||
| segments[DIGIT_COUNT - 1 - i] = segments_array[number % 10]; | ||
| number /= 10; | ||
| } |
There was a problem hiding this comment.
Since this is an exact copy of lines 242-245, you could consolidate and reduce the levels of indentation :)
mguetschow
added
the
CI: ready for build
Contribution description
This is a 4 digit display driver for the TM1637 7-segment display. It can display base 10 integers on a range from 9999 to -999, with or without leading zeros and variable brightness. The display can be cleared, too.
The driver was implemented according to a subset of all functionality and adheres to the specification .
Testing procedure
A test can be found in tests/drivers/tm1637/. The test covers all possible configurations for the driver and contains default pin configuration in tm1637_params.h.
Issues/PRs references
A similar display driver is still in review at PR #20981, but isn't compatible with this 4 pin display.
Images