Skip to content

Output Clock gate configuration #426

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

Open
bparks13 opened this issue Mar 14, 2025 · 2 comments · May be fixed by #438
Open

Output Clock gate configuration #426

bparks13 opened this issue Mar 14, 2025 · 2 comments · May be fixed by #438
Assignees
Labels
question Further information is requested
Milestone

Comments

@bparks13
Copy link
Member

Is the configuration for the OutputClock incomplete? In the register definitions, there is a CLOCK_GATE which enables/disables the output gate, but there is also a GATE_RUN register which "sets the gate using run status. Bit 0 = 0: Clock runs whenever CLOCK_GATE(0) is 1. Bit 0 = 1: Clock runs only when acquisition is in RUNNING state."

Currently, only CLOCK_GATE is written to. If the GATE_RUN register is always set to 0, this would be correct, but from the datasheet it appears that the POR value for GATE_RUN is 1, indicating that CLOCK_GATE might not have any effect right now.

@bparks13 bparks13 added the question Further information is requested label Mar 14, 2025
@bparks13
Copy link
Member Author

gate.SubscribeSafe(observer, value => device.WriteRegister(OutputClock.CLOCK_GATE, value ? 1u : 0u)),

@aacuevas
Copy link
Collaborator

CLOCK_GATE is a global enable for this device. If it's 0 there will not be an output, no matter what. If it's 1 there might be an output
GATE_RUN means that, when '0' the clock is free-running (always tied to CLOCK_GATE master enable, of course) and when '1' the clock will only run when acquisition is active.

Since in a Bonsai onix1 workflow there is no situation in which the workflow is running but acquisition is not, the GATE_RUN option is meaningless here, since acquisition is always running. Externalizing it will do nothing.

However, we should configure it to '1', even if it's the default value, in case it were modified externally somehow. A good practice for this lib should be to always initialize all registers.

@aacuevas aacuevas added this to the 0.5.0 milestone Mar 17, 2025
@jonnew jonnew assigned jonnew and unassigned bparks13 Apr 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants