<sb0>
rjo, for the opticlock piezo motor, why do people want tcp/ip? there are some modules with step/direction signals that should be straightforward to hook up to artiq ttls
<sb0>
well. idk about 4-axis. I only ever used a simple linear one
<rjo>
much less cabling, no need for realtime, and less workload (compile/rpc load) on the core device would be a few reasons.
<rjo>
btw: as long as there is this underlying fear that the experiment is core device CPU bound (whether this is true or not and whether this can be fixed or not) people will be catious and try to keep stuff away from it.
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 268 seconds]
<sb0>
yeah, that's why we should have our own ion traps.
<rjo>
would we have a different CPU/different ARTIQ?
<rjo>
or just to show that it's not cpu bound?
<rjo>
we'll do the latter with opticlock. we own that thing control-wise.
<sb0>
different CPU, well, depends what we do
<sb0>
for relatively simple things, which opticlock is AFAICT, most probably not
<sb0>
different ARTIQ... I think a text editor and submit-by-content would be nice in the GUI
<rjo>
no. the opticlock algorithms won't be simple. i think you are underestimating this. all the ~10 calibration algorithms probably need to be baked in with negligible dead time between the diferent cycle types.
_whitelogger has joined #m-labs
acathla` has joined #m-labs
acathla has quit [Ping timeout: 240 seconds]
_whitelogger_ has quit [Remote host closed the connection]
<GitHub79>
pdq/master 2880b59 Robert Jordens: doc: correctly mock kernel() and portable()
<sb0>
rjo, it is not possible to read more than 32 contiguous bit from the SPI core, is it?
<sb0>
rjo, maybe we can have multi-core with message passing.
rohitksingh_wor1 has quit [Quit: Leaving.]
<rjo>
sb0: not in one rtio transaction. but that's what chaning is for. just submit the next xfer before the current one is complete.
<rjo>
*chaining.
<sb0>
rjo, that doesn't work because you need to submit a transaction in between to read the data register
<sb0>
it's fine for writes, but with reads there is a problem
<rjo>
the sequence of events should be X0,X1, R0,X2, R1,X3... with X being xfers and R being reads (from the read buffer).
<rjo>
you have enough time between two xfers to issue the read.
<rjo>
but we should add a flag that makes the read (buffer register to input RTIO submission) automatic.
<rjo>
maybe just "len_read > 0"
<sb0>
hm, that's a bit tricky
<sb0>
maybe there should be a method that does N reads and returns a list?
<sb0>
or rather - fills a list, since we can't return lists
<rjo>
why is that tricky?
acathla` is now known as acathla
acathla has quit [Changing host]
acathla has joined #m-labs
<sb0>
it's not straightforward; lots of mucking around with the timeline
<sb0>
easy to get things wrong and produce spurious CS pulses. or underflows/sequence errors.
sb0 has quit [Quit: Leaving]
rooi-oog has joined #m-labs
rooi-oog has left #m-labs [#m-labs]
rooi-oog has joined #m-labs
sb0 has joined #m-labs
<sb0>
also this relies on subtle buffering in the core
<sb0>
and yes, one can figure this out by reading the docs carefully. but I think if we really want to support long reads, a function or a clear explanation would be good.
<sb0>
also dynamically sized transfers (e.g. keep reading until a status byte has some certain value, which is used in SD) cannot be done
<rjo>
sb0: yes. but there are two different issues. the chaining of multiple xfers should be simplified by just dropping the double buffer and leaving "the line open" when an xfer length is less than 32 bits.
<rjo>
the other problem is simplifying reads.
<sb0>
I've never been a big fan of this automatic CS design
<rjo>
there i think just submitting the read (fragment) when it is done is the right thing to do.
<sb0>
it also makes the core difficult to use with a non-realtime WB master
<rjo>
you are aware that you can just ignore the cs line
<rjo>
right?
<rjo>
drive it yourself if you don't want to.
<rjo>
but it saves you two rtio accesses per xfer.
<sb0>
you mean connect it to a TTL? yes. but CS is an integral part of the SPI standard, and one would expect a SPI core to handle it.
<rjo>
leaving the line open when the xfer is not "done" would work fine with non-rtio wb masters.
<rjo>
that just means "automatic CS" to me.
<sb0>
maybe there can just be an option in the write() method to release CS keep it asserted for the next transaction?
<sb0>
to avoid slowing things down, there can be write() and write_and_chain(), and this can be implemented with two different RTIO addresses
<rjo>
yes. keep it asserted if there is remaining xfer_len after a fragment xfer
<rjo>
but you always need to specify the xfer length.
<sb0>
it also makes the intent clear, unlike the current solution that uses the timeline and the buffer in subtle ways
<rjo>
i.e. just allow xfer_len > 32 and proceed accordingly.
<sb0>
this won't allow dynamically-sized transfers, unlike write()/write_and_chain()
<sb0>
if you just want to deassert CS after a write_and_chain(), you could do a zero-length transaction
<rjo>
or xfer_len (<= 32), eop flag, and we flag
<rjo>
that parametrization is fine imho as it breaks up a mixed xfer naturally.
rohitksingh has joined #m-labs
<rjo>
i.e. a read from a 32 bit register (8 bit command) would be (8, 0, 1), (32, 1, 0)
<rjo>
if anybody wants to re-jigger the current misoc core or the artiq layer on top of it, that re-jiggering should also transition to this new engine.