02:59 <sb0> rjo, are dds phase modes supported on urukul? http://m-labs.hk/artiq/manual-master/core_drivers_reference.html#artiq.coredevice.dds.DDSChannel.set_phase_mode

02:59 <sb0> also the urukul drivers and the ad9914 drivers are inconsistently named

03:14 <sb0> well not just inconsistently named, the structure is also inconsistent. a bit like sawg vs. wavesynth...

03:23 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #747: @jordens What are the current plans for this? https://github.com/m-labs/artiq/issues/747#issuecomment-373890730

03:51 <GitHub33> [smoltcp] dlrobertson opened pull request #180: Add Packet support for NDISC packet types (master...ndisc) https://github.com/m-labs/smoltcp/pull/180

11:39 <GitHub-m-labs> [artiq] hartytp opened pull request #962: Fix AD5360 after migration to SPI2 (master...ad5360) https://github.com/m-labs/artiq/pull/962

12:06 <GitHub-m-labs> [artiq] whitequark commented on issue #957: I've did some investigation. Reinitializing Si5324 in a loop never results in stuck SDA. Neither does rebooting the board in a loop when done at safe points, i.e. when there is no I2C communication. As far as I can tell, what's happening is, when the I2C bus is not properly reset, such as if abruptly resetting the core device, the slave doesn't see any SCL pulses and

12:12 <GitHub-m-labs> [artiq] jordens commented on issue #957: Try doing a bunch of SCL cycles (with SDA deasserted) as initialization. Unless there is a hardware issue pulling SDA/SCL this will recover it. https://github.com/m-labs/artiq/issues/957#issuecomment-373915573

12:18 <GitHub-m-labs> [artiq] jordens commented on pull request #962 c1439bf: Right.... https://github.com/m-labs/artiq/pull/962#discussion_r175256444

12:22 <GitHub-m-labs> [artiq] whitequark commented on issue #957: @jordens that's the obvious workaround (I haven't tried it yet), but I think PCA9548 reset should still be wired to the FPGA in the next revision... https://github.com/m-labs/artiq/issues/957#issuecomment-373916093

12:37 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #957: We have those boards out there right now, so whatever technique is implemented has to work without the hardware reset. Are there any ill effects from using SCL pulses when SDA is stuck instead of a dedicated reset anyway? We are initializing the I2C switches and resetting the Si5324 afterwards. https://github.com/m-labs/artiq/issues/957#issuecomment-373916979

12:49 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #957: The dedicated hardware reset would also be partial anyway unless we connect a reset line to every I2C slave. https://github.com/m-labs/artiq/issues/957#issuecomment-373917716

12:59 <GitHub-m-labs> [artiq] whitequark commented on issue #957: That's a good point, there's no room on the extension connectors for that anyway. https://github.com/m-labs/artiq/issues/957#issuecomment-373918261

13:31 <GitHub-m-labs> [artiq] gkasprow commented on issue #957: There are pin-compatible MAXIM [chips](https://www.maximintegrated.com/en/products/analog/analog-switches-multiplexers/MAX7358.html) that have bus stuck detection which causes disconnection of problematic branch https://github.com/m-labs/artiq/issues/957#issuecomment-373920334

13:31 <GitHub-m-labs> [artiq] gkasprow commented on issue #957: There are pin-compatible MAXIM [chips](https://www.maximintegrated.com/en/products/analog/analog-switches-multiplexers/MAX7358.html) that have bus lock-up detection which causes disconnection of problematic branch https://github.com/m-labs/artiq/issues/957#issuecomment-373920334

15:45 <GitHub-m-labs> [artiq] jordens commented on issue #747: No plans yet. https://github.com/m-labs/artiq/issues/747#issuecomment-373929929

16:19 <hartytp> rjo sb0: why are the dividers so large for the Zotino example?

16:19 <hartytp> https://github.com/m-labs/artiq/blob/c4bfc83b3831a90e9eeca3410a5e407ec2a783eb/artiq/examples/master/device_db.py#L194

16:20 <hartytp> Wouldn't the ad5360 defaults work?

16:21 <hartytp> Also the interface for the ad5630 isn't consistent with novogorny

16:22 <hartytp> E.g.novogorny uses _mu suffixes where the dac class doesnt

16:22 <hartytp> Novogorny also provides functions that work in si units which is nice

16:23 <hartytp> I prefer the novogorny interface

17:32 <GitHub137> [sinara] gkasprow pushed 1 new commit to master: https://git.io/vxOs8

17:32 <GitHub137> sinara/master 2bbf0cb Greg: added PSU to the BOM for Kasli and VHDCI carrier

17:48 <GitHub-m-labs> [artiq] jordens closed pull request #962: Fix AD5360 after migration to SPI2 (master...ad5360) https://github.com/m-labs/artiq/pull/962

17:48 <GitHub-m-labs> [artiq] jordens commented on issue #962: Merged and tweaked. Thanks! https://github.com/m-labs/artiq/pull/962#issuecomment-373939313

17:51 <GitHub-m-labs> [artiq] jordens pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/f39b7b33e8d0e5fb67dd768556341f868042d8e7

17:51 <GitHub-m-labs> artiq/master f39b7b3 Robert Jordens: ad5360: whitespace [nfc]

17:57 <rjo> hartytp: i think that was being catious because the first implementation and the example was targetting a eval board at nist over unknown spi wiring

18:24 <bb-m-labs> build #1355 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1355

18:49 <bb-m-labs> build #784 of artiq-win64-test is complete: Warnings [warnings python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/784 blamelist: Robert J?rdens <rj@quartiq.de>, ion <thomas.harty@physics.ox.ac.uk>

18:53 <bb-m-labs> build #2190 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2190

19:27 <bb-m-labs> build #1356 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1356

19:53 <bb-m-labs> build #785 of artiq-win64-test is complete: Warnings [warnings python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/785 blamelist: Robert Jordens <rj@m-labs.hk>

19:56 <bb-m-labs> build #2191 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2191

20:03 <GitHub-m-labs> [artiq] hartytp commented on issue #962: Thanks for fixing the formatting. https://github.com/m-labs/artiq/pull/962#issuecomment-373948647

21:57 <hartytp> rjo: am I being daft here?

21:57 <hartytp> https://hastebin.com/pusebesude.py

21:58 <hartytp> looking at the Zotino driver

21:58 <hartytp> using the above, I expect to see a 32-bit write to the LED SR, with the last 16 bits HIGH. I only see the last 4 bits high

21:58 <hartytp> what am I missing?

22:01 <hartytp> If I set the write length to 8 bits using set_config_mu, and write 0xf I see all 0s written to the bus

22:11 <rjo> hartytp: 0xf is just four bits high

22:12 <rjo> hartytp: and the tranfer is msb first: when doing an 8-bit transfer you want to write(data << 24)

22:19 <hartytp> yes, I just realized that

22:20 <hartytp> it's late and I can't count in binary any more

22:20 <hartytp> :(

22:22 <hartytp> still, one question, if 1 use set_config_mu to set the write length to 8 and write 0x1, I don't see any high bits on the bus

22:23 <hartytp> it does work if I set it to 32 and write 1 << 24

22:26 <hartytp> ok got it

22:26 <hartytp> so the write is 8 bits, but we still write the 8 MSB

22:26 <hartytp> makes sense

22:26 <hartytp> so 8 bit write requires 1 << 24

22:26 <hartytp> thanks

23:10 <hartytp> (i.e. the RTIO register is always 32 bits regardless of the SPI write length, so the data needs to be shifted for shorter writes)

23:20 <rjo> yes