drivers: auxdisplay: Add driver for common 7-segment display

[xingrz]

This PR introduces a new driver for a common GPIO-driven 7-segment display. supporting both common anode and common cathode configurations.

It also includes a new sample demonstrates counting from 0 to 1000, with an interval of 100ms between each increment.

[thedjnK]

For the other drivers, this always writes from the last position, whilst for a 7-segment display you might want (or expect) that, it deviates from the API:

 * @brief	Write data to auxiliary display screen at current position

What are your thoughts on adding position get/set and having write update the current character and advancing the position (also thinking this can be used on hex segment displays also)?

[xingrz]

This is actually a consideration for handling decimal points. For example, if you want to display 10.3, the decimal point is the third character in the data. However, on a 7-segment display, it is part of the second digit (0). Therefore, I need to do some processing in the write function, so that when the current character is identified as '.', the decimal point of the previous digit is lit.

[thedjnK]

Would be good if this sample adapted to the number of characters in the display

[thedjnK]

This does not check that a dot segment is present

[xingrz]

It's okay here since it's just setting the buffer bits and not actually updating the GPIOs directly. The DP bit will be ignored if only 7 GPIOs are present, as handled in the auxdisplay_gpio_7seg_timer_expiry_fn function below.

[xingrz]

Oh, wow! I have a new idea. Maybe I should separate this into an LED strip (or LED controller) driver, probably named "common-electrode-leds", and build the segment display driver on top of it. So, in theory, we could then drive any any-segment display with any form of multi-channel LED controller.

[thedjnK]

Oh, wow! I have a new idea. Maybe I should separate this into an LED strip (or LED controller) driver, probably named "common-electrode-leds", and build the segment display driver on top of it. So, in theory, we could then drive any any-segment display with any form of multi-channel LED controller.

It's an option. For LED displays they are usually numeric, alphanumeric or hex, so auxdisplay can work with all of those.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[cfriedt]

@xingrz - is there any chance that this could be reopened? I guess that this fell off the radar during the last release cycle.

I would be happy to re-review 😄

[xingrz]

@cfriedt Well, I’m not sure. I’m uncertain if this idea is fully developed. I’ve noticed that in actual projects, people often use dedicated LED driver ICs or GPIO expanders instead of the MCU’s GPIOs to drive the 7-segment displays. This approach provides enough driving power and minimizes IO usage. I think we should consider these scenarios, but I don’t have any concrete ideas yet. Let’s keep this PR closed for now. Perhaps in the future, someone interested might discover it and offer some new insights.

[thedjnK]

Port expanders are natively supported in zephyr through the GPIO interface so should be fine

[cfriedt]

I have a board in front of me that just uses GPIO as well without a driver. Depending on the brightness level required, I think it's reasonable in some circumstances.

[thedjnK]

Wasn't aware this got updated, minor change request for the binding compatible then looks good to go!

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[cfriedt]

This is so close to being done @xingrz

[xingrz]

Hi @cfriedt . No rush to merge right now. I didn't realize the Linux binding existed before, and I’m thinking about how to handle compatibility. Once merged, it might be harder to deal with that.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[decsny]

Hi @cfriedt . No rush to merge right now. I didn't realize the Linux binding existed before, and I’m thinking about how to handle compatibility. Once merged, it might be harder to deal with that.

My point was that the binding seemed almost exactly the same as the linux one, so all that should need to be done is to remove the zephyr, prefix from the compatible string. I am not even sure why it had the zephyr, prefix because it's not a zephyr specific binding, that prefix is only for things where we break the "rule" of having no project specific software description in DT. Not sure why the PR became stalled for half a year over this.

[cfriedt]

I agree about maintaining binding compatibility.

PR's grow stale for lots of reasons, but a common one is that contributors are doing the work in spare time, which.. has some costs.

@xingrz - would you agree to allowing a maintainer to update this PR on your behalf, or perhaps fork it and add the needed changes?

[xingrz]

@cfriedt @decsny

Sorry for the long silence and thanks a lot for your patience. I’ll address the immediate issue first — I agree with removing the zephyr, prefix to align with the Linux binding, and I’ll make that change shortly to get things moving.

As for the extra digit control logic in my implementation (where additional GPIOs and timer-based refreshing are used to select which digit is active), I think it would make sense to make that optional — so if digit-gpios and refresh-period-ms properties are omitted from DTS, the driver will simply drive segment outputs directly without any refresh logic. This could be considered as a future improvement to make the driver closer to the Linux model while still supporting advanced setups.