<_whitenotifier-3>
[Glasgow] marcan created branch wip-applet.video.ws2812_output - https://git.io/fhhGp
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] marcan pushed 1 commit to wip-applet.video.ws2812_output [+1/-0/±1] https://git.io/fj1O5
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] marcan b573cee - applet.video.ws2812_output: new applet
<marcan>
whitequark: feel free to take a look if you're bored. it's pretty dumb (there's no framing, it just assumes you're sending proper sized RGB blobs and that you're sending them fast enough for the LEDs not to time out)
<marcan>
(data frequency is 100kB/s per string or so, up to 16 strings, so 1.6MB/s max, which should be easy to saturate at the source if your software isn't terribad)
<marcan>
POV image player: while true; do for i in $(seq 0 34); do convert kiriya.png -brightness-contrast -60x-30 -crop 28x1+0+$i rgb:-; sleep 0.005; done ; done | nc -U /tmp/s
<marcan>
(lol)
<whitequark>
marcan: that looks basically okay tbh
<whitequark>
i'm currently not feeling well and doing other things, so i'll take a closer look later, i think
<marcan>
I'm annoyed by the len(pads) == 1 special case
<marcan>
kk
<whitequark>
but feel free to ping me until i merge
<marcan>
yeah, zero rush
<marcan>
I just needed to get this done for next week (and the week after, I'm killing two birds with one stone :p)
<whitequark>
hm, that special case, mmm
<marcan>
also I'm thinking on giving a talk about glasgow, or kicad, or both at Euskal Encounter next week
<marcan>
(mostly to fill slots in our free software talk area, we can always use more stuff)
<whitequark>
:D sounds awesome
<marcan>
I assume that means you're okay with it :>
<whitequark>
yeah
<whitequark>
of course
<marcan>
cool :D
<whitequark>
regarding the special case, i think i found a bug
<whitequark>
consider non power of 2 len(pads)
<whitequark>
word_ctr will eventually go into an invalid value, since max is rounded up to the next POT
<whitequark>
in Signal(max=...)
<marcan>
NextValue(self.word_ctr, 0), in the RESET and SEND-WORD states
<whitequark>
ohhh yeah
<whitequark>
derp
<whitequark>
so why can't you just remove that conditional then?
<gruetzkopf>
*money-at-jlcpcb-throw-noise* now i have time for stuff again until boards show up
<marcan>
whitequark: it explodes, I'm not entirely sure why
<whitequark>
how does it explode? any symptoms?
<marcan>
I get a strange warning and the output is borked
<marcan>
let me try
<marcan>
for one I needed self.word_ctr = Signal(max=max(2, len(pads))) because otherwise it's a zero-bit counter and that doesn't work
<marcan>
but I thought otherwise it would work
<whitequark>
yes, that max invocation is correct
<whitequark>
it's somewhat unfortunate
<marcan>
top.v:1096: Warning: Range select out of bounds on signal `\videows2812outputapplet_videows2812outputsubtarget_word': Setting 1 MSB bits to undef.
<marcan>
so I get that
<whitequark>
ohhhh
<whitequark>
that's a migen bug basically
<whitequark>
can you try um
<marcan>
though the output seems correct-ish this time? I'm not sure
<marcan>
ah not it isn't
<whitequark>
replacing `self.word[24:]` with `self.word[24:] if len(pads) > 1 else Cat()` or something like that
<marcan>
(and of course you can wrap around a single LED string, physical topology is irrelevant)
<whitequark>
i've honestly never considered the case of 1d video in my life before
<whitequark>
like the only time i've thought about 1d pixel data is in the case of spectrometers
<marcan>
hah
<whitequark>
and those don't exactly record time series data
<whitequark>
but yeah i guess wrapping does that
<kc8apf>
Flatbed scanners are just 1D video recorders
<marcan>
heh
<whitequark>
kc8apf:
<kc8apf>
I'm just here to make poor observations
<whitequark>
btw in case y'all wondering what am i doing, well, i'm annoyed by yosys' synthesis very much
<whitequark>
so i am making it better
<whitequark>
i want debug information. i want BDDs in decision tree to mux conversion. i want timing driven synthesis. i want whitebox optimizations during lut mapping
<whitequark>
preferably at the same time
<kc8apf>
Yes please
<whitequark>
ironically most of these things are far easier if you don't touch abc
<marcan>
whitequark: I think I have a flow control issue though. I think the current implementation just greedily reads from the socket and buffers locally indefinitely?
<marcan>
I need it to have some fixed-sized buffer and stop reading from the socket when full
gsuberland has joined #glasgow
<whitequark>
marcan: ohhh
<whitequark>
marcan: right, you want backpressure
<whitequark>
i'm not totally sure the best way to implement that, feel free to suggest a change you think is good
m4ssi has quit [Remote host closed the connection]
<marcan>
whitequark: I didn't realize this was a problem until 20GB later my computer crashed :p
<marcan>
will think about this later, packing for a flight now
<marcan>
aside: I just tested the ws2812 thing on a revB, works fine too
<marcan>
(will probably use the revB for the actual project, since I might give a talk and show off the revCs
<tnt>
marcan: one way is to explicitely wait for some feedback from the hw, this way you can control the latency 'end to end'.
<marcan>
tnt: true, but there's plenty of use cases for "blast data out" where implicit flow control is useful
<marcan>
and the FIFO already has that, there's no reason for the python side not to implement backpressure
<marcan>
glasgow is about making writing applets simple, I shouldn't have to write my own flow control layer
<tnt>
point taken
<whitequark>
I absolutely agree the FIFO should do backpressure
<whitequark>
this is an omission caused by my relative inexperience with distsys
<Ultrasauce>
marcan are you taking these pictures by swinging your camera around
<Ultrasauce>
i wonder if you could get the latency down enough on an eyeball tracking vision system to do POV with saccades
<Ultrasauce>
maybe EMG would be a better approach
uberushaximus has quit [Remote host closed the connection]