<whitequark>
it's doing some weird escaping bullshit
<whitequark>
also I think that just uses IP?
<sb0>
yes
<whitequark>
it seems somewhat pointless to use SLIP, bypass half of the stack, probably get bugs from unusual configuration
<whitequark>
and it might not even be enabled in kernels anymore anyway
<cr1901>
SLIP is the precursor to PPP anyway, correct?
kyak_ is now known as kyak
cr1901 has quit [Ping timeout: 245 seconds]
rohitksingh has joined #m-labs
cr1901 has joined #m-labs
_whitelogger has joined #m-labs
<sb0>
this escaping is actually a pretty good idea, with a more naive protocol the endpoints would permanently lose sync if any garbage is inserted in the stream
<sb0>
fwiw my arch linux kernel supports slip.
<whitequark>
ok...
<sb0>
i'd be fine with either slip or dropping pipistrello.
<sb0>
debian stable also supports slip
rohitksingh has quit [Ping timeout: 250 seconds]
<sb0>
bb-m-labs, force build --branch=release-2 artiq
<bb-m-labs>
build #1158 forced
<bb-m-labs>
I'll give a shout when the build finishes
<GitHub128>
[artiq] jordens commented on issue #615: @cr1901 please read again what I said. This is not just adding another register.... https://git.io/v1o0m
rohitksingh has quit [Ping timeout: 250 seconds]
<GitHub185>
[artiq] cr1901 commented on issue #615: >please read again what I said. This is not just adding another register.... https://git.io/v1ouQ
<GitHub21>
[artiq] cr1901 commented on issue #615: >please read again what I said. This is not just adding another register.... https://git.io/v1ouQ
<cr1901>
I would love it if I could write a comment properly the first time, even with preview
<rjo>
cr1901: since MOSI is tied to the register, the sequence starts with the the first bit output on MOSI, _then_ samples MISO etc. Depending on the definition of "shift" there is either no first shift or it is implicit. And there should definitely be no shift after the last sample. independent of terminology.
<cr1901>
rjo: All timing diagrams I've ever seen for SPI slaves show there being a shift after the last sample before before de-asserting cs_n. However, your solution that you linked to indeed wouldn't require the last shift (at least for the master).
<rjo>
why would there be a shift (change in mosi) after the last sample? there is no data there.
<cr1901>
B/c I suspect the sample is sent to a temporary register before being shifted into the slave's data port.
<cr1901>
E.g. if the slave's data port is "n" bits, it has "n+1" bit shift register, and MOSI is latched during the sample into the LSB of the shift register. When cs_n is deasserted, the slave latches everything but the first bit into its data port
<cr1901>
the first bit being "the previously registered MOSI"
<cr1901>
rjo: Wrt MISO, your solution, minus the last shift, works too. But I do wonder why all slaves want "n" samples and "n-1" shifts.
<rjo>
that's an implementation choice. i.e. you can either have miso tied to the register and the shifts with the sample clock (then mosi would need to lead) or you can have mosi tied to the register, shifts being with the "output" edges and miso lagging half a clock cycle. i chose the latter. and in that approach there are no shifts after the last sample.
<cr1901>
damnit it... "n" shifts*
<rjo>
wanting "n" shifts assumes that you count the first bit output as a "shift" (which is usually just the loading of the register)
<cr1901>
rjo: "shifts being with the "output" edges and miso lagging half a clock cycle" Can you elaborate?
<cr1901>
"output" edges of what, exactly?
<rjo>
clk
<rjo>
the first mosi bit is "there" available by asserting cs. then you sample the first miso bit, then you shift the register and the second mosi bit is there, ... until at last, you shift the register once more making the last mosi bit availabe, and then sample the last miso bit.
<cr1901_modern>
rjo: That would mean that there are slaves which "ignore" the final clock edge corresponding to the shift after the the "last miso bit" was sampled? All timing diagrams I've seen want "n" samples followed by "n" shifts
* cr1901_modern
was driving
<rjo>
we are only talking about masters here. what the slave does is it's problem.
rohitksingh has joined #m-labs
rohitksingh has quit [Client Quit]
<cr1901_modern>
rjo: Okay, I understand. I'll just do a sanity check to make sure your solution doesn't cause any problems (it shouldn't), and then update the patch w/ your solution. I agree your solution is simpler, considering the way you implemented the master.
<rjo>
cr1901_modern: i think the need for a N+1 long shift register could have been derived from first principles as well: durint the half cycle after sampleing the first miso bit and before emitting the second mosi bit, there are N+1 bits around.
<rjo>
during
<rjo>
sampling
<cr1901_modern>
rjo: I agree. I think we just differ on implementation :P.
<cr1901_modern>
rjo: I *suspected* something was wrong when I was updating the test suite, but I chalked it up to a "side effect of the impl combined with feeding the output back into the input". Should've dug deeper...
calle_ has joined #m-labs
<calle_>
hi
<rjo>
hello
calle_ has quit [Ping timeout: 265 seconds]
calle_ has joined #m-labs
calle_ has quit [Quit: Leaving]
cr1901 has quit [Ping timeout: 240 seconds]
cr1901 has joined #m-labs
mumptai has joined #m-labs
<GitHub37>
[artiq] dleibrandt opened issue #640: experiments submitted with Flush=True cannot interrupt other experiments https://git.io/v1ob7