00:02 <GitHub143> [smoltcp] whitequark commented on pull request #42 8502574: `mod ref`, `use self::ref::Ref` and then reexport as a prefixed name; that's how everything else is done here. https://git.io/v5DbL

00:02 <GitHub20> [smoltcp] whitequark commented on pull request #42 8502574: It would be more elegant to use `.iter_mut().enumerate()` here. https://git.io/v5Dbt

00:02 <GitHub169> [smoltcp] whitequark commented on pull request #42 8502574: I believe dispatching over the socket type is the rare case (it only happens inside smoltcp and in OS/firmware code that's generic over the socket, e.g. fd handling), so let's have a panicking .get() and a non-panicking get_opt(), seems cleaner than unwrapping everywhere. https://git.io/v5DbI

00:02 <GitHub179> [smoltcp] whitequark commented on pull request #42 8502574: We don't need Deref for SocketRef since all useful methods on sockets use &mut self anyway. It seems like this would lead to people thinking they can do something with &XxxSocket. https://git.io/v5Dbq

00:02 <GitHub199> [smoltcp] whitequark commented on pull request #42 8502574: *squint* what... is this thing https://git.io/v5Dbk

00:02 <GitHub22> [smoltcp] whitequark commented on pull request #42 8502574: We don't (and can't, Rust enums are not extensible) support new socket types defined in external crates, so the entire SocketSession logic can simply be folded into the SocketRef Drop impl. https://git.io/v5DbY

00:02 <GitHub28> [smoltcp] whitequark commented on pull request #42 8502574: `downcast_socket` maybe? `from_socket` is not really indicative of what this does. https://git.io/v5DbO

00:02 <GitHub196> [smoltcp] whitequark commented on pull request #42 8502574: `Option<&mut T>` maybe? If I understand correctly, this Option would be deconstructed exactly three times, one in constructor, one in destructor and one in deref, so the one added jump is basically nothing. Then just take the option.... https://git.io/v5Dbm

00:02 <GitHub90> [smoltcp] whitequark commented on pull request #42 8502574: Worth mentioning SocketSet here and that they're probably looking for `socket_set.get::<TcpSocket>(tcp_handle)` instead https://git.io/v5Db3

00:41 <GitHub88> [artiq] sbourdeauducq commented on issue #829: I thought you already tested it and had a problem ... https://github.com/m-labs/artiq/issues/829#issuecomment-329024196

01:51 <GitHub110> [sinara] marmeladapk pushed 1 new commit to master: https://github.com/m-labs/sinara/commit/773f740dc0a5daee8ea385ad3d12e5ee32a8f2ca

01:51 <GitHub110> sinara/master 773f740 Paweł K: Kasli fixes...

05:02 <GitHub175> [artiq] sbourdeauducq commented on issue #778: I have an idea to spread the events among the FIFOs without requiring complex, slow, large or high-latency logic. Do what @jordens proposes (switch to the next FIFO if the timestamp is not strictly increasing), but also switch to the next FIFO if the current one had been full.... https://github.com/m-labs/artiq/issues/778#issuecomment-329059663

07:22 <rjo> sb0: what's the error description then? just "fifo contention"?

07:34 <GitHub134> [smoltcp] batonius commented on pull request #42 8502574: `DerefMut` requires `Deref`. https://git.io/v5y3M

07:37 <GitHub110> [smoltcp] batonius commented on pull request #42 8502574: This is what I did initially, but `std::iter::Enumerate` requires `std`, so I have to do it manually. https://git.io/v5y3A

08:25 <GitHub98> [artiq] hartytp commented on issue #778: @sbourdeauducq I'd be fine with that. https://github.com/m-labs/artiq/issues/778#issuecomment-329095719

08:42 <GitHub62> [smoltcp] batonius commented on pull request #42 8502574: Looks like I've got carried away a little. https://git.io/v5yCf

08:47 <GitHub199> [smoltcp] batonius commented on pull request #42 8502574: `SocketRef` is generic over socket type, we can't put socket-specific cleanup code there. Besides, I'm going to extend `SocketSession` with an associated type that holds socket's state, something like https://github.com/batonius/smoltcp/blob/packet_dispatch/src/socket/tracker.rs#L11 . https://git.io/v5yC4

09:05 <GitHub93> [smoltcp] batonius commented on pull request #42 8502574: Apparently, I've missed `core::iter`. https://git.io/v5ylZ

09:57 <sb0> rjo, not sure. perhaps keep the old name "sequence error"

09:58 <sb0> both are sequences of events that the rtio core cannnot handle

10:00 <GitHub8> [artiq] sbourdeauducq pushed 2 new commits to rtio-sed: https://github.com/m-labs/artiq/compare/bdd96084c59b...feec6298a5e9

10:00 <GitHub8> artiq/rtio-sed c74abcc Sebastien Bourdeauducq: rtio/sed: lane distributor fixes

10:00 <GitHub8> artiq/rtio-sed feec629 Sebastien Bourdeauducq: rtio/sed: add lane distributor simulation unittest

10:09 <GitHub177> [smoltcp] batonius commented on pull request #42 8502574: `Option<&mut T>` in `SocketRef` would mean `DerefMut::deref_mut` could panic, and there's really no reason for it. I guess I live it as it is for now. https://git.io/v5y0s

14:48 <GitHub144> [artiq] sbourdeauducq pushed 3 new commits to rtio-sed: https://github.com/m-labs/artiq/compare/feec6298a5e9...1b61442bc339

14:48 <GitHub144> artiq/rtio-sed 8cfe2ec Sebastien Bourdeauducq: rtio/sed: fix sequence number width computation

14:48 <GitHub144> artiq/rtio-sed 1b61442 Sebastien Bourdeauducq: rtio/sed: fix lane spreading and enable by default

14:48 <GitHub144> artiq/rtio-sed a92a955 Sebastien Bourdeauducq: rtio/sed: use __all__

15:12 <GitHub6> [artiq] sbourdeauducq commented on issue #778: Key components are there (in the rtio-sed branch) with simulations/unit tests; needs gluing, adding a few relatively simple things like FIFOs and timestamp counter, and testing on the board. https://github.com/m-labs/artiq/issues/778#issuecomment-329199647

15:15 <GitHub4> [artiq] dhslichter commented on issue #778: I think this sounds fine, provided that the number of FIFOs is perhaps 2-3x a "typical" number of timeline rewinds. I know this is a hard number to pin down, but maybe for now a reasonable first pass would be roughly 8 TTLs per FIFO? Will things need to be substantially more aggressive to achieve the resource efficiencies we desire with SRTIO? https://github.com/m-labs/artiq/issues/778#issuecomment-32

15:16 <Arpit> Hello. I'm trying to connect to SPI bus on Zotino. The 4 pins of SPI are connected to KC705 via FMC to VDHCI, which uses LVDS_25. So each SPI pin is available to KC705 as a pair (since LVDS requires 2 pins). Now my question is, how can we define SPI bus in such that each of its 4 pin has "p" and "n" parts. Can I define Subsignal within Subsignal (nested Subsignal)? I want my definition to be compatible with SPIMaster class.

15:18 <GitHub148> [artiq] sbourdeauducq commented on issue #778: 8 TTLs per FIFO? https://github.com/m-labs/artiq/issues/778#issuecomment-329201417

15:18 <sb0> Arpit, isn't that vhdci card converting it to cmos?

15:21 <Arpit> On hardware level, it might be doing that. But on software level, I have 2 pins for each SPI pin (example LA02_P and LA02_N). But while specifying SPI bus in gateware, I can specify only one pin, example Subsignal("clk", Pins("LPC:LA02_P")),

15:23 <sb0> what fmc card do you have?

15:24 <rjo> Arpit: specify each EEM group as one top level compound "signal" with two subsignals io_p and io_n each holding eight lines.

15:25 <Arpit> Okay, if I were to specify SPI pin separately, I would do it like this: ("spi_clk", 0, Subsignal("p", Pins("LPC:LA02_P")), Subsignal("n", Pins("LPC:LA02_N")), IOStandard("LVDS_25"), Misc("DIFF_TERM=TRUE") ) And I can define 4 such pins. Then can I use these 4 things to specify a SPI bus?

15:25 <rjo> then add a shim module that wraps and reorganizes them so that it is digestible by spi. you will have to adapt to the fact that the SPI master uses tristates.

15:25 <rjo> sb0: it doesn't.

15:26 <rjo> Arpit: please double check whether you want diff term on output pins as well.

15:27 <GitHub139> [artiq] dhslichter commented on issue #778: I should perhaps say 8 RTIO channels (not necessarily TTLs) per FIFO. Basically this would be an 8x reduction in the number of FIFOs relative to the current design. They would potentially need to be made deeper, but not 8x as deep. ... https://github.com/m-labs/artiq/issues/778#issuecomment-329204359

15:27 <rjo> Arpit: no. that's not what i said. look at how "pmod" signals are usually defined. they also have differential naming.

15:28 <Arpit> If we view from KC705's point of view, each SPI pin is LVDS_25. Then LVDS<->LVCMOS converter on Zotino will convert it before giving to DAC.

15:33 <GitHub137> [artiq] dhslichter commented on issue #778: I should perhaps say 8 RTIO channels (not necessarily TTLs) per FIFO. Basically this would be an 8x reduction in the number of FIFOs relative to the current design. They would potentially need to be made deeper, but not 8x as deep. ... https://github.com/m-labs/artiq/issues/778#issuecomment-329204359

15:33 <sb0> hmm the card is AC-coupling the LVDS signals by default too, it seems

15:34 <sb0> R243/R246 are marked DNP

15:51 <rjo> they seem to be placed on joes photos.

15:51 <GitHub46> [artiq] dhslichter commented on issue #778: I should perhaps say 8 RTIO channels (not necessarily TTLs) per FIFO. Basically this would be an 8x reduction in the number of FIFOs relative to the current design. They would potentially need to be made deeper, but not 8x as deep. ... https://github.com/m-labs/artiq/issues/778#issuecomment-329204359

17:08 <Arpit> rjo: Okay. Thank you. An example of such shim module would help (even if it's written in between something else, not specifically SPIMaster class). The SPIMaster class is instantiating TSTriple and passing 4 pads of SPI bus to get_tristate function to get Tristate object. So I'm wondering how can a shim be written without modifying any code in any of these classes (I suppose I shouldn't have to modify SPIMaster class).

17:13 <rjo> Arpit: maybe the best way would be to implement a differential tristate.

17:30 <GitHub192> [artiq] amhankin commented on issue #829: I am currently upgrading from an old version of Influxdb (too outdated to work with the ARTIQ driver) and wanted to know whether or not the latest stable version is supported. Since we are making the change now and considering using it regularly, I would like to understand expectations regarding support for this feature in the future. https://github.com/m-labs/artiq/issues/829#issuecomment-329240102

17:44 <GitHub57> [artiq] r-srinivas opened issue #830: Modulo arithmetic with negative numbers on the kernel https://github.com/m-labs/artiq/issues/830

18:20 <Arpit> rjo: Okay, will try that on Friday. Thanks.

19:35 <GitHub26> [smoltcp] batonius commented on pull request #42 8502574: `ref` is a keyword, so I can't use `mod ref;`, I'll rename `socket_ref::SocketRef` to `socket_ref::Ref`. https://git.io/v5SV5

20:35 <GitHub173> [nu-servo] dtcallcock opened pull request #1: Fixed link to NovoUrukulServo page on Sinara Wiki (master...patch-1) https://github.com/m-labs/nu-servo/pull/1

20:47 <GitHub79> [nu-servo] jordens closed pull request #1: Fixed link to NovoUrukulServo page on Sinara Wiki (master...patch-1) https://github.com/m-labs/nu-servo/pull/1

20:47 <GitHub105> [nu-servo] jordens pushed 2 new commits to master: https://github.com/m-labs/nu-servo/compare/1814ba6691bd...0a32a3e6d3d0

20:47 <GitHub105> nu-servo/master 55dd477 David Allcock: Fixed link to NovoUrukulServo page on Sinara Wiki

20:47 <GitHub105> nu-servo/master 0a32a3e Robert Jördens: Merge pull request #1 from dtcallcock/patch-1...

21:00 <GitHub181> [smoltcp] batonius commented on pull request #42 8502574: `Option<&mut T>` in `SocketRef` would mean `DerefMut::deref_mut` could panic, and there's really no reason for it. I guess I leave it as it is for now. https://git.io/v5y0s