<d1b2>
<Attie> @whitequark ... can you quantify "EEPROMs pretty much always work (for reads) without Vdd"?
<d1b2>
<Attie> does this mean that a given physical part will read fine 90% of the time... or does this mean that "eeproms you've tested seem to read fine without Vdd"
<whitequark>
latter
<whitequark>
well, let's see
<whitequark>
microchip's 24c02c has a read current of 5 µA
<d1b2>
<Attie> i makes me feel nervous - the possibility of introducing an incorrect read on something like an addon, that is arguably "critical"
<d1b2>
<Attie> *it makes me...
<whitequark>
nononono
<whitequark>
you misunderstood
<d1b2>
<Attie> but at the same time, if feels like it'd work quite nicely
<whitequark>
i'm not proposing to actually use them without vdd or without capacitance
<whitequark>
i'm just saying that even if you use EEPROMs in a far more extreme circuit than what i'm actually proposing, they basically work fine
<whitequark>
with i2c fast mode, clock (unstretched) is never low for longer than 2.5 µs. at 5 µA this is 12.5 pC of charge
<whitequark>
let's say you want your (actual) Vdd to stay within 10% of 3.3V
<electronic_eel>
Attie: the eeprom content could also have a crc32 or md5 checksum, so you know if your read something wrong
<whitequark>
that means you need a 42 pF capacitor to keep the chip powered within the proper range for the low period of the clcok
<whitequark>
i don't know for sure and don't have an easy way to figure out, but i assume that the capacitance of a Vdd pin of a typical EEPROM is naturally higehr
<whitequark>
which is why they happen to work fine
<whitequark>
you definitely want a checksum there, and in fact i would put at least 2 copies of data on a non-write-protected EEPROM
<d1b2>
<Attie> you're thinking something like this?
<d1b2>
<Attie> ok, yeah (i left it out after the discussion above)
<whitequark>
since ESD diodes are not really intended for this kinda thing
<d1b2>
<Attie> true / fair
<whitequark>
even if they don't burn (they should withstand a few mA of even write current), you have the problem of high voltage drop over ESD diodes
<whitequark>
and a nice schottky at µA currents will have almost none
<d1b2>
<Attie> (re checksum: agreed - it'll be required)
<d1b2>
<Attie> i think it sounds sensible, but as above... it makes me feel nervous 🙂
<whitequark>
that's why i'm asking here...
<whitequark>
really, the margins are even wider than this, since most I2C EEPROMs have something like 1.75 to 5.5 range
<whitequark>
and the i2c mux is a level translating one, meaning as long as the EEPROM itself is powered on, it'll all work fine
<electronic_eel>
so reading the eeprom will be possible on revD (where we have the i2c mux) with just two extra pins. but then we still need the extra power pins for stuff like stepup converters and similar, and the protection board i want to do
<whitequark>
yes
<sorear>
is there anything that can actually go wrong here? if we don’t detect the addon, we don’t detect the addon, it’s not safety critical
<whitequark>
my idea is basically to stuff addon i2c bus *only* to those 2 pins, and to fix it at 3V3-ish with parasitic power pullups on glasgow side
<electronic_eel>
an addon might also want to have sideband, like for selecting additional voltages or stuff like that. i2c would be really handy for that
<whitequark>
^ that
<whitequark>
the bus itself must be reliable
<whitequark>
the parasitic power only really matters for simple addons that don't need external power
<electronic_eel>
the i2c interface on the port should somehow be protected against the user connecting it to 5v
<whitequark>
basically every i2c mux we can use will necessarily do that
<whitequark>
er, hm
<electronic_eel>
the mux will have vcc=3.3v
<electronic_eel>
not all muxes will allow voltages above that
<whitequark>
yes, you're right, i misremembered the current solution for PUPD
<whitequark>
ok well, bog standard pca9548 does that
<whitequark>
and lots of other parts
<electronic_eel>
ok, nice
<whitequark>
the only thing that seriously worries me with this plan is the power-on reset of the I2C EEPROM
<electronic_eel>
?
<whitequark>
well, what happens when you power on an I2C EEPROM? what prevents it from detecting spurious SCL/SDA edges during power up?
<whitequark>
it has some sort of (never documented in detail) power on reset. but that logic is obviously designed for SDA/SCL that are pulled up to Vcc, not the other way around
<electronic_eel>
hmm, i guess they have some reset timer in them. because otherwise you'd always get problems with this
<electronic_eel>
i think for glasgow the problem is more that we allow hotplugging. so there will be contact bounce.
<whitequark>
yes, that's the other side of the same coin
<electronic_eel>
that is something the reset circuit in the eeprom is not designed for
<electronic_eel>
so we should probably make the pullups switchable, so they get just turned on when we do addon detection
<electronic_eel>
needs an i2c io expander
<whitequark>
nope, can't do that either
<whitequark>
because then the devices that are powered *not* parasitically will get spurious edges
<electronic_eel>
how are they powered then? with the extra power connectors, right?
<whitequark>
yes
<electronic_eel>
we should switch them too
<electronic_eel>
because of the same problem there
<whitequark>
oh?
<whitequark>
contact bounce?
<electronic_eel>
yes, you'll get that with the power connectors too
<whitequark>
mmmkay
<electronic_eel>
also having the 5v rail hotplugged is a bit risky, contact bounce could create power spikes there
<electronic_eel>
so switching it on only after we detected an addon is the better way
<whitequark>
yes, that was bothering me too, but i also wasn't sure if it would get really complex
<whitequark>
i'm 100% in favor of switching the aux power connector actively
<electronic_eel>
that is why we don't have that in revC yet - it takes time to design this kind of stuff properly
<whitequark>
ok
<whitequark>
agree
<whitequark>
electronic_eel: so basically, you're proposing 2 more GPIOs per port? 1 to control parasitic power, 1 to control Vaux?
<electronic_eel>
i'm not yet convinced that using the 2 pins on the shrouded connectors is worth the extra hassle. an addon board will just need an extra simple female pin header to plug into the aux connector. adding that is cheap and easy. so the only real point is ribbon cables.
<whitequark>
hmmm
<electronic_eel>
if we had just the aux connector and i2c there, no parasitic power, we'd just need one gpio to switch both
<whitequark>
there is the ability to reuse existing cases (unless we decide on the future revC aux connector placement by the time esden starts making cases for revC2)
<electronic_eel>
i don't think future revC will fit in the current cases, we'll need more space for the aux connectors
<whitequark>
we could ditch the 0.05" connectors that are there for bypassing PUPD resistor arrays with the massive keepouts
<electronic_eel>
also the i2c mux and power switches and so on
<whitequark>
it'll still be tight for sure
<electronic_eel>
if we put the aux inside, we reduce the usable board space on addons - because they'd need tht parts there for the connectors
<electronic_eel>
i think making the board a bit wider and putting the aux on the outside would work better
<electronic_eel>
so, I'm going to sleep now, getting late for me
<whitequark>
good night!
<electronic_eel>
thanks, you too
<d1b2>
<Attie> o/
<gruetzkopf>
oh, 0200 (GMT+1)
<d1b2>
<OmniTechnoMancer> How much current will the I2C pull-ups pass?
<whitequark>
depends on the value
<d1b2>
<OmniTechnoMancer> What do those pins connect to on the 20 pin ARM JTAG connector?
<whitequark>
19 is DBGACK, 20 is ground
<d1b2>
<OmniTechnoMancer> Hmmk
<whitequark>
in practice DBGACK would probably be ~always open, possibly sometimes fixed to GND
<_whitenotifier-f>
[glasgow] attie opened pull request #224: applet.video.ws2818_output: convert to nmigen - https://git.io/JTAPx
<d1b2>
<Attie> @whitequark - the ws2812 applet currently expects (requires) RGB LEDs... I have (compatible) RGBW LEDs here, and wonder if it might be nice / sensible to permit color values other than 3x per "pixel"
<d1b2>
<Attie> for example, i could say 4x colors per pixel, 15x pixels, and things will fall into place
<whitequark>
sure why not
<d1b2>
<Attie> currently when driving i get the "next" LED's green where i'd expect the first's white
<d1b2>
<Attie> (and it goes wonky from there)
<d1b2>
<Attie> i'll have a think, but the initial nmigen port PR is done
<d1b2>
<Attie> @whitequark i looking in to the variable bit-per-pixel idea from above
<d1b2>
<Attie> i was wondering if the existing applet is designed to work with anything in particlar, and if the rewrite from RGB to BRG is a hard requirement
<d1b2>
<Attie> two reasons:
<d1b2>
<Attie> 1. i have a chain of RGBW LEDs, and this causes confusion (i.e: G from LED2 comes before W of LED1 in the data stream)
<d1b2>
<Attie> 2. it might introduce a lot of complexity if we need / want to control the byte ordering from the command line
<d1b2>
<Attie> if we can accept data in the order expected on the wire, then the applet becomes more straighforward... but this then puts knowledge and conversion on the client software at the other end of the socket
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JTxQy
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark 7e170bf - cli, device.hardware: prepend bitstream ID to prebuilt bitstreams.
<d1b2>
<Attie> i suppose an alternate option is to select RGB vs. RGBW mode of operation
<d1b2>
<Attie> which makes things quite a bit more simple... but that will rule out 8-bit devices (or 16-bit, etc...) if they exist / appear, which I was hoping to avoid
<whitequark>
hey folks, i would appreciate if someone checked the perf of yowasp-yosys with newer wasmtime
<whitequark>
... uh... in about a hour when it finishes building, i guess
<electronic_eel>
Attie: re ws2812 - what would be a common program to output streams that the applet would then ingest? is it common for such programs to offer options for RGB, BRG, RGBW and so on or not?
<whitequark>
marcan used ffmpeg
<electronic_eel>
do you know which output driver?
<whitequark>
no but it should be in the logs of this channel i think
<d1b2>
<Attie> i was wondering if ffmpeg / gstreamer might do it - the latter certainly is pretty flexible with its pixel formats
<d1b2>
<Attie> not sure how it'd work with RGBW though, as that's not really a thing typical displays / pixel formats do... alpha yes, but white not so much
<electronic_eel>
it seems to just allow rgb format and offers no option for reordering to BRG or similar
<d1b2>
<Attie> oh, well found... i missed that
<electronic_eel>
so from a usability standpoint, it would be nice to specifiy input format and led ordering on the commandline and let glagow do the conversion
<electronic_eel>
the question is how to implement that without making it awfully slow
<whitequark>
numpy
<marcan>
^^
<whitequark>
wait
<whitequark>
why are we talking about conversion being slow when we have a perfectly good FPGA right there?
<marcan>
I don't remember why I put RGB into the applet but I seem to recall there was a reason
<marcan>
but also that
<whitequark>
can't you just swizzle the bits on the device?
<whitequark>
it's literally free!
<marcan>
that's what I do now I believe
<marcan>
it's just hardwired for RGB
<whitequark>
i'll admit, i basically have never looked at that applet so far
<whitequark>
been busy more or less rewriting the jtag probe stuff
<whitequark>
really excited about it
<d1b2>
<Attie> we can swap bytes on the FPGA, and i was really asking how best to handle it... because it could get complex fast
<marcan>
ok the applet obviously needs to know how many bits per pixel even if it doesn't swizzle, because it does deinterleave the multiple outputs
<d1b2>
<Attie> i wonder if this is a "video" applet, and therefor it should be considered an RGB use-case only
<d1b2>
<Attie> but that prevents usage with RGBW LEDs, for example
<whitequark>
Attie: our "video" taxon *specifically* includes non-RGB :p
<whitequark>
The ``video`` taxon groups applets implementing video interfaces, that is, interfaces for periodic
<electronic_eel>
if you have RGBW leds and included numpy or whatever to create a RGBW stream, you should able to output it
<whitequark>
transfers of 2d arrays of samples of electromagnetic wave properties.
<whitequark>
i don't quite get the problem still
<whitequark>
what is our input format?
<d1b2>
<Attie> @wq ha, fair
<marcan>
ok so it's pretty easy to generalize the applet for arbitrary pixel widths in multiples of 8, I think
<marcan>
now if you want it to also swizzle, that requires some dynamic mapping of course
<d1b2>
<Attie> the expected input format (into the socket) is RGB... the expected on-the-wire format is GRB
<d1b2>
<TiltMeSenpai> do you really need to "swap" bytes or can you just make it so you can say "in one cycle, output channel 1, 1, 2", and leave it up to the host to ensure that ordering is sane
<d1b2>
<TiltMeSenpai> if that makes sense
<whitequark>
Attie: so... it's a simple permutation of a small bit width?
<d1b2>
<Attie> the issue being that if you want to operate with RGBW LEDs, then the expected on-the-wire format is WGRB (i think, datasheet lies)
<marcan>
state B: shift the final output reg 24 bits, append R/G/data_in in the right order
<whitequark>
yeah, that's how i was writing the very first applets
<whitequark>
it's an easy way but it's kinda meh after a while
<marcan>
then it loops those states as many times as there are output channels
<d1b2>
<Attie> correct - i agree we're fine for 24-bit "pixels"
<d1b2>
<Attie> but how do we best support other sizes or other formats
<d1b2>
<Attie> i like wq's suggestion above
<whitequark>
what other sizes and formats do we want to support?
<marcan>
do we really need arbitrary bit widths?
<whitequark>
and how do those formats actually get into the applet?
<whitequark>
marcan: i dunno, it seems easy enough to me?
<marcan>
byte alignment?
<marcan>
padding?
<whitequark>
oh i would probably ensure that the *word* is byte-aligned
<marcan>
have you *seen* the ffmpeg raw video format list?
<d1b2>
<Attie> e.g: RGB565
<whitequark>
^ that
<whitequark>
marcan: no i actually have not
<whitequark>
hence i'm asking: "how do those formats actually get into the applet"
<marcan>
$ ffmpeg -pix_fmts
<whitequark>
let's see
x56 has quit [Quit: Ծ-Ծ]
<marcan>
you don't want to go down the path of supporting all kinds of crazy nonsense
<d1b2>
<Attie> i've used things like RGBx8888, and BRG888, RGB565 to specify pixel formats in the past
<d1b2>
<Attie> but it's not super simple
<marcan>
are there any LEDs that use something like RGB565?
<marcan>
or anything other than 8-bit per component formats?
<whitequark>
no idea
<whitequark>
that's why i'm asking!
<d1b2>
<Attie> marcan: doubtful tbh
<marcan>
then let's keep it to "pixels are N bytes, applet can swizzle those bytes arbitrarily"
<d1b2>
<Attie> which was why i came to the suggestion earlier, of only supporting RGB, and RGBW LEDs...
<marcan>
at 8bpc
<whitequark>
if the swizzle is byte-granularity then implementing this is utterly trivial
<marcan>
that should cover anything reasonable
<d1b2>
<Attie> are we aware of any 8-bit / one color variants
<marcan>
the only edge case is 8 bits, yes
<marcan>
which entirely removes one state
<whitequark>
use a counter, Luke!
<marcan>
other than that it's just a matter of generalizing the r/g states into one buffer with a counter
<whitequark>
i guess i just wrote so damn many of these tiny FSMs that they look completely obvious to me
<whitequark>
maybe not so much to others
<whitequark>
marcan: have you seen what i do in the PROM applet?
<marcan>
no
<whitequark>
first off it has an address bus that to the main part of the applet looks like parallel out, but in reality it is partly serial partly parallel with arbitrary split
<whitequark>
when the main part of the applet changes the serial part of the address bus, it gets stopped until the bits are shifted out
<whitequark>
so it's transparent
<marcan>
I mean I can think of two ways of doing the swizzling
<marcan>
the way I'm doing it now, which is "read all bytes but one, then when you read the final byte swizzle everything at the same time"
<whitequark>
second, page programs in parallel EEPROMs don't tolerate latency, so the applet has a secondary FIFO that the host can fill with commands and then execute in one step
<marcan>
or you could "just have one loop for all bytes, and each byte read inserts itself into the right place" which means you need an if/switch in the data path there
<whitequark>
(not really directly related, i just like how it ended up0
<marcan>
not sure which makes more sense in the hardware. the first way felt like it would produce simpler logic but what do I know
<whitequark>
marcan: here's how i would do it
<d1b2>
<TiltMeSenpai> I mean the fmax on these led's aren't that high, are they?
<whitequark>
the FSM attached to the OUT FIFO stuffs bytes into basically a shift register, except it shifts 8 positions at a time
<whitequark>
each N cycles it asserts a strobe and waits for acknowledgement
<whitequark>
that strobe causes something else to sample the shift register
<marcan>
oh so you would use two FSMs
<whitequark>
the swizzle is implicit in the sampling step. i.e. you launch from a 32-bit register and capture into a 32-bit shift register but there's a permutation in between
<whitequark>
yes. two FSMs and a 1-element FIFO
<marcan>
I mean this is what i'm doing except with one FSM, and combining states
<whitequark>
yup
<whitequark>
but it's way simpler with two FSMs
<whitequark>
well, way easier to get right
<whitequark>
you don't need to use your brain
<whitequark>
this is exactly why the PROM applet was easy to develop: it has two complicated FSMs talking through a very simple interface
<marcan>
well, feel free to take a look at the code and rewrite it, it's pretty simple
<marcan>
the whole FSM is less than one terminal page
<whitequark>
yeah, it's not much of an improvement in this case
<whitequark>
mostly matters for more complex applets with similar issues
<marcan>
sure
<whitequark>
it's less that i think it needs to be rewritten and more that i'm explaining to Attie how i would do it
<marcan>
I mean if you don't care about introducing a wasted cycle and an extra 8 bits of register, you can decouple the read-last-8-bits step from the swizzle-and-stage-data step and make it more orthogonal
<whitequark>
uhm
<whitequark>
the FPGA runs at 48 MHz
<whitequark>
there's no LED strip in the world that can tolerate such a clock rate
<marcan>
well you can compensate those cycles anyway
<d1b2>
<Attie> these run at ~800kHz
<marcan>
# bit period needs to be > 1250ns and < 7µs
<whitequark>
yeah but... why compensate 20 ns if the LEDs are two orders of magnitude slower? i don't understand
<whitequark>
you're going to run in lockstep with WS2812 clock anyway no matter what you do
<marcan>
it's one state machine
<marcan>
the load steps add time to the output period
<marcan>
but I'm not compensating right now *anyway*
<whitequark>
oh, right
<marcan>
also the thing has no buffering beyond one pixel-group, so it assumes the USB data comes in faster than output speed, or at least with stalls shorter than the reset time which is 300µs, otherwise it breaks
<whitequark>
there is buffering in the FPGA, created by the applet framework
<whitequark>
well, not exactly
<marcan>
can you peek the buffer fullness?
<whitequark>
the buffer is a part of the FX2 crossbar
<whitequark>
yes, and in fact we recently merged a bunch of code in nmigen and now you can peek at the level even for async FIFOs
<marcan>
one way to improve this would be to only start outputting when the buffer has at least one frame of video in it, but of course that only works for buffer sizes > 1 frame
<marcan>
then if the source is slow the output is slow, but it won't break
<whitequark>
you can set the buffer size. get_in_fifo(depth=2048)
<marcan>
though this introduces latency anyway
<marcan>
actually, maybe we should just cheat
<marcan>
well, wait, no, we can't
x56 has joined #glasgow
<marcan>
it would complicate things too much anyway
<marcan>
anyway, I need to get some sleep
<whitequark>
good night!
<marcan>
busy day tomorrow (because this week has been unproductive af so far)
<d1b2>
<Attie> nn
<sorear>
so anything with a loop filter is obviously right out due to not having enough storage for more than a couple lines but I wonder if mjpeg decoding is doable
<_whitenotifier-f>
[glasgow] attie opened pull request #225: applet.video.ws2818_output: add support for LEDs other than RGB - https://git.io/JTpzp
<d1b2>
<Attie> @whitequark how are we handling things like documenting an example "other application"? Can I put it in a README.md next to the applet, or perhaps in a comment at the top?
<d1b2>
<Attie> I ended up using the same pipeline as marcan, but with the rgba pixel format instead of rgb
<whitequark>
Attie: good question. let me review the applet first (later, pretty tired now)
<d1b2>
<Attie> yeah, no problem
<d1b2>
<Attie> i'll pop it in the PR notes for now
<d1b2>
<OmniTechnoMancer> Is it worth having support for the SK9822 kind of RGB chainable LEDs?