<sb0>
cygwin, get that linux feeling on windows, i.e. edit files to fix compilation errors with sed, because everything else introduces \r characters that fuck up something else
<sb0>
what a piece of garbage
<sb0>
conda under cygwin is, of course, also broken all over the place due to \r issues
<GitHub15>
[artiq] sbourdeauducq commented on issue #813: That's not "trashing" it, as you can see in the commit it is simply commented out. People want to test the SAWG so master has to work, and disabling that core is fast and has currently no user impact. https://github.com/m-labs/artiq/issues/813#issuecomment-364011595
attie has quit [Remote host closed the connection]
attie has joined #m-labs
<GitHub164>
[smoltcp] whitequark commented on issue #156: The API you propose is a non-starter because it includes an alloc function. smoltcp never, ever, allocates anything. This is literally in the second paragraph of README. https://github.com/m-labs/smoltcp/issues/156#issuecomment-364027232
<GitHub26>
[smoltcp] whitequark commented on issue #156: (Also, why "my_embedded_system"? Embedded systems have heaps, and it makes perfect sense to not use an allocator in a high-throughput user-mode stack.) https://github.com/m-labs/smoltcp/issues/156#issuecomment-364032091
<GitHub68>
[smoltcp] canndrew commented on issue #156: > Have you actually tried to write this? The ownership doesn't work out. Consider what will happen if you will try to use that hypothetical `my_embedded_system_grab_n_bytes_from_ring_buffer` function to allocate both the backing storage for UdpPacket and for Ipv4Packet.... https://github.com/m-labs/smoltcp/issues/156#issuecomment-364032848
attie has quit [Ping timeout: 268 seconds]
attie has joined #m-labs
<GitHub179>
[smoltcp] canndrew commented on issue #156: Maybe the proposed API isn't ideal but do you at least see the problems that I'm gesturing at in the bug report? How the current API is cumbersome and bug-prone for some use-cases? https://github.com/m-labs/smoltcp/issues/156#issuecomment-364033762
futarisIRCcloud has quit [Ping timeout: 256 seconds]
<GitHub107>
[smoltcp] canndrew commented on issue #156: > You can't do this with safe code only because the alloc function returns a mutable pointer into the ring buffer. I'm not interested in adding APIs that require the use of unsafe code elsewhere.... https://github.com/m-labs/smoltcp/issues/156#issuecomment-364041070
<rjo>
sb0: ZFM-2-S+ would do. but sampling two channels at 500 MS/s for a few MS and mixing in software will be much easier. withequark's rigol can do that.
<rjo>
just output ~50 MHz sine on both channels and download the traces, do on each channel angle(decimate(lowpass(ch*exp(1j*2*pi*50e6*t)))) and compare. the decimation will give you enough precision on top of the 8 bits of the scope and the scope's jitter won't be an issue for the ~ns resolution you need.
<rjo>
sb0: in ~rj/ds1xxxx.py there is some nicer code to talk to the rigol.
<rjo>
sb0: i can also do the analysis for you if you acquire the data.
attie has quit [Ping timeout: 256 seconds]
attie has joined #m-labs
mumptai has quit [Remote host closed the connection]
<GitHub144>
[smoltcp] whitequark commented on issue #156: @LuoZijun For example, if you already have the payload in memory somewhere, you can use scatter-gather I/O to avoid the need to a copy to prepend headers to data. https://github.com/m-labs/smoltcp/issues/156#issuecomment-364078415
attie has quit [Ping timeout: 240 seconds]
attie has joined #m-labs
<GitHub117>
[artiq] marmeladapk commented on issue #908: @sbourdeauducq With latest commit (2d4a134) when I compile `python3 -m artiq.gateware.targets.sayma_amc --without-sawg` I still get memory test failed. https://github.com/m-labs/artiq/issues/908#issuecomment-364093590
<sb0>
rjo, I cannot find the lowpass function. should I use resample instead of decimate+lowpass?
<sb0>
well decimate already does the low-pass
<GitHub163>
[artiq] sbourdeauducq commented on issue #908: Those binaries are from ARTIQ 4.0.dev+521.g4c22d64e with the RTM loading gateware commented out. I tested that SDRAM works on the board when flashing them (and then booting from flash).... https://github.com/m-labs/artiq/issues/908#issuecomment-364132304
<sb0>
rjo, what about scipy.angle(sum(ch*scipy.exp(2j*scipy.pi*50e6*t))) ?
<sb0>
er, scratch that
<sb0>
that doesn't work when the frequency is a bit off
<GitHub24>
[smoltcp] whitequark commented on issue #159: Definitely path 2, I've already thought about it for ICMPv4 and decided on that. Did you know that you can add documentation to `impl` blocks? So you can have a separate `impl` block per message type. https://github.com/m-labs/smoltcp/issues/159#issuecomment-364139410
attie has quit [Ping timeout: 255 seconds]
attie has joined #m-labs
<GitHub55>
[artiq] whitequark commented on issue #908: @sbourdeauducq Since this bug is clearly not caused with my gateware based on this failure I'm not going to waste time rewriting this in some other way. https://github.com/m-labs/artiq/issues/908#issuecomment-364141532
<GitHub46>
[artiq] sbourdeauducq commented on issue #908: Whatever the path of least resistance is. If GPIO bit-banging works around the problem, it's easier than tracking down the original problem which is likely a Vivado bug or something equally obscure. https://github.com/m-labs/artiq/issues/908#issuecomment-364142094
<GitHub137>
[artiq] hartytp commented on issue #854: If we're going to give up on getting ethernet working on Sayma v1.0, then shall we revisit the idea of scrapping Sayma AMC as master and using Kasli as master instead? Work done on getting Sayma DRTIO working with Kasli seems like it will be more useful in the long run. https://github.com/m-labs/artiq/issues/854#issuecomment-364154306
<GitHub18>
[artiq] hartytp commented on issue #854: If we're going to give up on getting the ethernet chip on Sayma v1.0 working, then shall we revisit the idea of scrapping Sayma AMC as master and using Kasli as master instead? Work done on getting Sayma DRTIO working with Kasli seems like it will be more useful in the long run. https://github.com/m-labs/artiq/issues/854#issuecomment-364154306
<GitHub122>
[artiq] sbourdeauducq commented on issue #854: There is an issue with the Ethernet PHY, at least on my boards: the link is not detected, even though the FPGA is sending the 125MHz TX clock (which you verified). Other than that the MiSoC code is pretty much equivalent to the IPBUS code, but with different phases. Maybe the PHY is again in SGMII mode instead of 1000BASE-X, and my media converter cannot handle it but y
<GitHub96>
[artiq] gkasprow commented on issue #854: The media converter I shipped to you works in 1000base-x mode by default. To switch it to SGMII and enable operation in 10 and 100mbit mode, one needs to set its one of I2C registers. https://github.com/m-labs/artiq/issues/854#issuecomment-364168941
<GitHub100>
[artiq] whitequark commented on issue #902: I'll need the `or broadcast` capture since the panics are caused by malformed IP packets and those aren't in the core device communication. https://github.com/m-labs/artiq/issues/902#issuecomment-364176667
<GitHub15>
[artiq] whitequark commented on issue #902: I'll need the `or broadcast` capture since the panics are caused by malformed IP packets and those aren't in the core device communication. You can send it to my email `pz@m-labs.hk`. https://github.com/m-labs/artiq/issues/902#issuecomment-364176667
rohitksingh1 has quit [Ping timeout: 260 seconds]
rohitksingh has joined #m-labs
mumptai has joined #m-labs
<GitHub142>
[smoltcp] dlrobertson commented on issue #159: NDISC is an extension of ICMPv6. NDISC ([RFC 4861]) defines 5 new ICMPv6 types not defined in [RFC 4443] (the core ICMPv6 RFC). What I'm really referring to is the length difference between the headers for messages defined in [RFC 4443] and some in [RFC 4861]. For example the layout of the Router Advertisement is as follows.... https://github.com/m-labs/smoltcp/issu