14:48 <Eldra> On the urukul card, do we have access to the DRCTL and the DRHOLD pins ?

14:50 <airwoodix> Eldra: IIRC it depends on the hardware revision

14:51 <airwoodix> v1.3 no, v1.4 yes (but you can check on the schematics)

14:53 <airwoodix> v1.3 has AD9910's DRCTL and DRHOLD grounded

14:53 <Eldra> Hmm, I will check my revision then

14:54 <airwoodix> v1.4+ allows access from the CPLD but there's no (official) gateware support https://github.com/quartiq/urukul/

14:55 <airwoodix> If you have v1.3, you can ask rjo, he played with it in a sort of "degenerate" mode

14:55 <airwoodix> But it's probably not what you want

14:55 <Eldra> Yeah I saw that I wanted to use the DRG mode of the AD9910

15:02 <Eldra> The urukul revision is v1.4

15:37 <Eldra> airwoodix: Actually I am using the urukul card though a Kasli one. Do you know the way of set to 1 or 0 a single pin ?

16:02 <airwoodix> Kasli doesn't communicate directly with the DDS chips on Urukul. There's a CPLD proxying this on the Urukul board.

16:05 <airwoodix> With the current gateware, the CPLD ties DRHOLD and DRCTL down and doesn't expose them to Kasli so you can't toggle the DDS chip pins without reconfiguring the CPLD.

16:06 <airwoodix> For quick tests, you can probably tinker something with the configuration register (https://github.com/quartiq/urukul/blob/master/urukul.py#L68)

16:07 <airwoodix> rjo: are there plans for exposing these pins/functionality on the CPLD side (I guess this is part of quartiq/urukul#7)?

16:10 <airwoodix> Eldra: once this is done on the CPLD side, there's also work to integrate this in the coredevice driver (but that's relatively straightforward, provided the DRG works as expected)

16:11 <Eldra> So it means we can use the DIGITAL RAMP MODULATION MODE of the AD9910 ?

16:11 <Eldra> At least for now

16:11 <airwoodix> can or can't?

16:11 <Eldra> we can't

16:12 <airwoodix> You can't without (CPLD) gateware modifications.

16:12 <Eldra> Ok that is why I have difficulties to make it works ^^

16:14 <Eldra> Thank you for the answers :)

16:15 <airwoodix> No problem

16:41 <rjo> airwoodix: The plan is the issue you cite. It's waiting for interested parties to express interest.

16:41 <rjo> If we do it then I'd completely overhaul the protocol, give access to all DRG/profile/etc pins individually, split the attenuator chain, and make it as much Mirny-like as possible so that a single EEM connector is sufficient.

17:20 <mtrbot-ml> [mattermost] <hartytp> that would be a welcome improvement

23:36 <mtrbot-ml> [mattermost] <astro> @sb10q @sjm did someone swap the zc706 flash? the first flash chip is suddenly working for me!