-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
DACx3608 Driver Feature Support #73090
Comments
Hi @bbooher! We appreciate you submitting your first issue for our open-source project. 🌟 Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙 |
@bbooher I agree that the current DAC API is still more simple than the one for e.g. the ADC and we should think about a way to allow for channel synchronization (see also #74340). Do you already have an idea in mind how an API update for the channel sync could look like? |
Some thoughts on the DAC API:
For synchronization:
One idea is to break up the write_value API call into 2 separate functions: 1 which updates the DAC value to output and the other physically applies the output value. This is similar to the sensors |
@bbooher I like the idea of splitting the |
I believe the buffered flag is a hardware configuration setting to set output impedance and timing - not for synchronization purposes (a hardware buffer, not a software buffer). See https://forum.digikey.com/t/dacs-output-buffered-and-unbuffered/1565 I think the buffered flag is a bit odd in the API since it's hardware-specific and parts generally don't support both options.
This looks similar to my proposed idea - though I prefer swapping the intended use of write and update (better for backward compatibility, too). I'll use write and update in my preferred usage in the following. My concern with the approach is that if a latch pin is not configured, then we have different output behavior of the API. With no latch pin configured, Some pseudocode for this thought:
|
The additional consideration missing from my previous comment is multiple-channel storage.
|
@bbooher @martinjaeger I have made a few commits and marked them WIP for this new |
I can't seem to make comments on a branch alone. I'll make a few observations here:
[1] Proposed structure
This structure would be created in the driver based on the number of channels configured in DTS. The appropriate "macrobatics" need to be implemented to iterate and initialize this data.
Then the dac_write_value() function looks something like (pseudocode):
I understand this is a lot of code, lol, for not actually doing it. But I'd like more input before digging into things (and @emz229 seems to be making some strides in that direction already). @martinjaeger? |
Thanks! Already late here. Will comment tomorrow. |
Sorry @emz229 and @bbooher that it took me so long to react. I've looked at different DAC implementations (both on-chip and external via I2C/SPI) regarding synchronized write mechanisms. I think we should keep the current (simple) For implementing the synchronized writes of many DACs in parallel (as mostly found for multi-channel external DACs) we can extend the API. The term What about something like this (with t.b.d. /**
* @brief Update a sequence of DAC channel values for synchronous triggering
*
* This function will only update the registers, but not actually start the conversion.
*
* @param dev Pointer to the device structure for the driver instance.
* @param seq Pointer to the sequence of channel values.
*
* @retval 0 On success.
* @retval -ENOTSUP If synchronized output is not supported by the hardware.
* @retval -EINVAL If a parameter with an invalid value has been provided.
*/
int dac_update_values(const struct device *dev, struct dac_sequence *seq);
/**
* @brief Trigger DAC output based on previously updated values
*
* This function triggers a DAC to output of the values set using dac_update_values.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channels Flags to select which channels to trigger. For DACs with a single latch pin,
* all available channels must be set.
*
* @retval 0 On success.
* @retval -EINVAL If a parameter with an invalid value has been provided.
*/
int dac_trigger(const struct device *dev, uint32_t channels); P.S.: The current |
No problem! Release time is probably pretty hectic... I'm OK with extending the API and the The concern I have with this approach is the same as @emz229's initial take. If a trigger mechanism isn't configured or supported, then With my suggestion:
This is likely more difficult to enforce as drivers are added. I'll concede that I don't have an issue if others don't share this concern. =========================================================== |
I would suggest that We can also present both options to the Arch WG and see what other people think. I'm on vacation for the next 2-3 weeks, though, so we'd need to schedule this for end of August or beginning of Sept. |
Thanks for getting back. Returning an error sounds like the right thing to do. But since only 2-3 of us are looking at it, getting more eyes on the proposed API changes from the Arch WG is probably better. I'm also busy, and your time frame matches my availability nicely. |
@martinjaeger @emz229 Bumping this discussion |
Is your enhancement proposal related to a problem? Please describe.
The broadcast channel and low-power configuration features are not supported.
Describe the solution you'd like
Add support to send DAC write values to the Broadcast Register (channel 9?). Also, modify the channel setup implementation with the ability to return channels to power-down mode after initialization.
Describe alternatives you've considered
Custom out-of-driver I2C control is the only alternative.
Additional context
Please see the description of the register map (pg 30): https://datasheet.datasheetarchive.com/originals/distributors/Datasheets_SAMA/31e6133a56d84334c2130e2ecbea856a.pdf
Possible Future Enhancements
There are also missing line controls for DAC channel synchronization which should be tied to the driver, but the existing DAC interface doesn't account for something like that. The DAC interface, in general, should be brought in line with other peripherals like ADC.
The text was updated successfully, but these errors were encountered: