Allow more control of compiled sensors and displays and features

[Links2004]

This Helps to get the size down e.g. for usage with atmega328p.

[Links2004]

the builds fail e.g. with:

/usr/lib/gcc/avr/5.4.0/../../../avr/bin/ld: address 0x800945 of out/klipper.elf section `.bss' is not within region `data'
/usr/lib/gcc/avr/5.4.0/../../../avr/bin/ld: address 0x800945 of out/klipper.elf section `.bss' is not within region `data'
collect2: error: ld returned 1 exit status
make: *** [Makefile:73: out/klipper.elf] Error 1

Context:

I use a atmega328p + st7920 (Full Graphic Smart Controller) as a display and its imposible to build the current master with out size reduction for this setup.
with the changes here its possible to build with out error.

[JamesH1978]

Thank you for submitting a PR, please be aware that you need to sign off to accept the developer certificate of origin, please see point 3 in https://github.com/Klipper3d/klipper/blob/master/docs/CONTRIBUTING.md#what-to-expect-in-a-review

Thanks
James

[Links2004]

added Signed-off-by to commit

[KevinOConnor]

Thanks. In general it seems fine to me. There were some recent changes to the Kconfig file (doing something similar) so this PR will need to be rebased to the latest code.

Also, at a quick glance it seems this patch misses the conversion of HAVE_GPIO_I2C to WANT_GPIO_I2C in a few places. I'm not sure why the conversion was made for WANT_GPIO_SPI but not WANT_GPIO_I2C.

Cheers,
-Kevin

[Links2004]

rebased and reworked the selection, new menu:

[KevinOConnor]

Thanks. In general it seems fine. However, I don't think we should organize the menu by "support for i2c" and "support for spi". I think we should keep the accelerometers together, the high speed adcs together, the displays together, etc. . That is, I think most users will find an orientation by chip type (not chip interface) to be more convenient.

Also, it looks like you introduce a duplicate WANT_HX71X.

Also, it doesn't make sense to add CONFIG_WANT_xxx=y definitions to atmega328p.config as these already default to 'y' - it only makes sense to add explicit 'n' definitions.

Cheers,
-Kevin

[Links2004]

the problme with this is that the chips require I2C / SPI which basicly forces you to decide on that first.
but I dont think that there will be and problem finding the chips since the default for I2C / SPI is y (if the platform / MCU supports it), which result in the full visable list of chips.

if we sort it diffently its hard to under stand why options are simingly randomly there and not.

[github-actions]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review
   If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[KevinOConnor]

Thanks. I agree that sorting by sensor type could be confusing when spi/i2c are disabled. However, I think sorting by spi/i2c could also cause confusion. I think I'd prefer to keep the current sorting by sensor type.

-Kevin