Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

drivers: support for Microchip MCP47xx DAC devices added #10518

Merged
merged 4 commits into from
Feb 26, 2022

Conversation

gschorcht
Copy link
Contributor

@gschorcht gschorcht commented Nov 29, 2018

Contribution description

This PR adds a driver which supports different Microchip MCP47xx DAC variants. Multiple MCP47xx DAC devices and different variants can be used at the same time.

Expander Channels Resolution
MCP4706 1 8-bit
MCP4716 1 10-bit
MCP4725 1 12-bit
MCP4726 1 12-bit
MCP4728 4 12-bit

The following features of MCP47xx DAC devices are not supported at the moment:

  • configuring and reading address bits to/from EEPROM
  • writing DAC channel output values to the EEPROM
  • setting the UDAC bit and using the LDAC pin for MCP4728

The driver interface is kept as compatible as possible with the peripheral DAC interface. The only differences are that

  • functions have the prefix mcp47xx_ and
  • functions require an additional parameter, the pointer to the MCP47xx device of type #mcp47xx_t.

Testing procedure

Please refer the test application in tests/driver_mcp47xx for an example on how to use the driver

make -C tests/driver_mcp47xx BOARD=...

Issues/PRs references

@gschorcht gschorcht added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Area: drivers Area: Device drivers Area: SAUL Area: Sensor/Actuator Uber Layer Type: new feature The issue requests / The PR implemements a new feature for RIOT and removed Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation labels Nov 29, 2018
@stale
Copy link

stale bot commented Aug 10, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Aug 10, 2019
@gschorcht gschorcht added the State: waiting for other PR State: The PR requires another PR to be merged first label Aug 10, 2019
@stale stale bot removed the State: stale State: The issue / PR has no activity for >185 days label Aug 10, 2019
@stale
Copy link

stale bot commented Feb 11, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Feb 11, 2020
@gschorcht
Copy link
Contributor Author

Still waiting for another PR.

@stale stale bot removed the State: stale State: The issue / PR has no activity for >185 days label Feb 11, 2020
@stale
Copy link

stale bot commented Aug 14, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Aug 14, 2020
@gschorcht gschorcht removed the State: stale State: The issue / PR has no activity for >185 days label Aug 15, 2020
@stale
Copy link

stale bot commented Mar 19, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Mar 19, 2021
@gschorcht gschorcht removed the State: stale State: The issue / PR has no activity for >185 days label Mar 20, 2021
@MrKevinWeiss MrKevinWeiss added this to the Release 2021.07 milestone Jun 21, 2021
@MrKevinWeiss MrKevinWeiss removed this from the Release 2021.07 milestone Jul 15, 2021
@gschorcht gschorcht added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed State: waiting for other PR State: The PR requires another PR to be merged first labels Dec 6, 2021
@github-actions github-actions bot added Area: Kconfig Area: Kconfig integration Area: tests Area: tests and testing framework labels Dec 6, 2021
@gschorcht gschorcht force-pushed the drivers_mcp47xx branch 4 times, most recently from b248489 to 44f8486 Compare December 7, 2021 08:34
@benpicco benpicco self-requested a review December 7, 2021 12:46
Copy link
Contributor

@benpicco benpicco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Only a few clarifications:

*/
typedef struct {
mcp47xx_params_t params; /**< device configuration parameters */
uint16_t values[MCP47XX_CHN_NUM_MAX]; /**< contains the last values set */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
uint16_t values[MCP47XX_CHN_NUM_MAX]; /**< contains the last values set */
uint16_t values[MCP47XX_CHN_NUM_MAX]; /**< contains the last values set for persistence when device is powered off */

right?

Copy link
Contributor Author

@gschorcht gschorcht Dec 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, will change it. May I squash directly?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, squash

*
* @retval none
*/
void mcp47xx_dac_get(mcp47xx_t *dev, dac_t chn, uint16_t *value);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit surprised you implemented this when periph/dac API does not provide any dac_get().
Feel free to keep it though :)

typedef struct {
const char *name; /**< name of the MCP47xx device */
unsigned int dev; /**< index of the MCP47xx device */
dac_t channel; /**< channel of the MCP47xx device */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dac_t ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is the same as for the perhiph/dac. The goal was to keep it as compatible as possible with periph/dac and to handle channels in same way when we intended to introduced the DAC extension API with PR #10512.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But dac_t would refer to a unique DAC device, not a channel of a DAC.
Just using uint8_t here would be less confusing IMHO (there also is no saul_dac_params_t yet)

Copy link
Contributor Author

@gschorcht gschorcht Dec 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, dac_t refers a line, that is device + channel. It is also used in periph/dac to set a certain channel of a device. In this sense, it also makes sense to use it here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When we started to introduce the extension API, we used exactly the same types for extenders to refer devices and channels.

Copy link
Contributor Author

@gschorcht gschorcht Dec 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunatly, we had not much luck with the extension interfaces as suggested in PR #10512 til now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However, we can of course also use uint8_t, if there is an extension API at some point in future, the type dac_t can still be mapped to dev + chn.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can still change it later if we go forward with the extension API. 😉
To an unsuspecting user like me the dac_t type here just adds confusion.

@benpicco
Copy link
Contributor

benpicco commented Dec 7, 2021

Please squash!

@benpicco benpicco added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Dec 7, 2021
@benpicco benpicco added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Feb 26, 2022
@benpicco benpicco enabled auto-merge February 26, 2022 18:34
@benpicco benpicco added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Feb 26, 2022
@benpicco benpicco merged commit 6cfbec4 into RIOT-OS:master Feb 26, 2022
@OlegHahm OlegHahm added this to the Release 2022.04 milestone Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: drivers Area: Device drivers Area: Kconfig Area: Kconfig integration Area: SAUL Area: Sensor/Actuator Uber Layer Area: tests Area: tests and testing framework CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: new feature The issue requests / The PR implemements a new feature for RIOT
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants