<whitequark>
cr1901_modern: btw I have a large part of a PS/2 applet
<whitequark>
the problem is i never figurd out how to make it function reliably
<cr1901_modern>
the keyboard or mouse part?
<whitequark>
either
<whitequark>
see the thing is
<whitequark>
it's packet based
<whitequark>
but it will never tell you where the packet boundaries are
<whitequark>
this is fine in an IBM PC, because you can always just inhibit the device
<whitequark>
the problem is that glasgow has FIFOs
<whitequark>
so, you send a command to inhibit, it arrives.... some unknown time later.
<whitequark>
combined with the fact that the mouse or keyboard will gladly send you packets on its own
<cr1901_modern>
yea that sounds like it's going to be a problem. Why can't there be some gateware just before the I/O pins which inhibits on your behalf (and then propogates to the FIFO)?
<whitequark>
think of how it would work
<whitequark>
e.g. mouse sends 3 byte report
<whitequark>
it sends 1 byte into that report, that gateware activates
<whitequark>
the 1 byte glasgow has just received is already in the FIFO travelling towards the host
<cr1901_modern>
Hmmm, okay... >>
<whitequark>
glasgow doesn't know if the 1 byte is an entire packet, half a packet, third of a packet
<whitequark>
so it can't wait until it's complete, for example
<cr1901_modern>
I'm not actually familiar w/ PS/2 mice. I was under the impression the PS/2 keyboard was "the same protocol as the AT keyboard, just a smaller connector"
<cr1901_modern>
was the keyboard protocol extended?
<whitequark>
it's also packet-based
<whitequark>
G00031 explicitly describes that
<cr1901_modern>
Okay then indeed my question doesn't apply :P
<whitequark>
hm wait, it doesn't
<whitequark>
cr1901_modern: it might have been extended
<whitequark>
the docs i can find elsewhere say that keyboards are all packet based
<whitequark>
i.e. it has an output buffer and if you inhibit it, it starts sending from the start of the output buffer
<cr1901_modern>
This worked for my needs on the PS/2 keyboards I tested, so I never delved further lol
<cr1901_modern>
yes PC keyboards do have like a 16-32 byte buffer. Some keys require more than one byte to send. However, it is encoded in-band how long the expected key input is.
<cr1901_modern>
So I can still inhibit safely after each byte is sent w/o things breaking
<whitequark>
cr1901_modern: inhibiting the keyboard and explicitly requesting each key to be sent is something i've considered
<whitequark>
cr1901_modern: hang on
<whitequark>
does the keyboard resend the entire multi-byte combination?
<cr1901_modern>
whitequark: Good to know :). Have no idea whether this helps w/ mouse protocol or not- never studied it lol (serial mice are still cheap, while XT keyboards aren't)
<marcan>
whitequark: is it okay to not label the Vio leds? we don't really have the silkscreen space for that.
<marcan>
(refspec is in there, I mean an actual label for the led)
<davidc__>
whitequark: agreed (re socket). I don't know the best way to do it either; but I'll make up a list of the use cases I know about, and the tricky corner cases for each where I know them
<whitequark>
excellent
<electronic_eel>
re socket: I was thinking the idea of a direct connection between progs like sigrok and the fpga over
<electronic_eel>
I don't know if it is such a great idea
<electronic_eel>
you can't change the bitstream this way
<electronic_eel>
let's say you want some cool trigger logic in the fpga, then you'd need to change the bitstream
<electronic_eel>
also let's say we develop some cool compression to improve throughput
<electronic_eel>
then sigrok needs a compatible counterpart
<electronic_eel>
but developing improvements for the compression is difficult because we always need to also update sigrok (or similar progs)
<electronic_eel>
So I think a socket between the program and the Glasgow program on the host is best
<electronic_eel>
the Glasgow program can then translate the stuff that goes over the wire to the fpga
m4ssi has quit [Remote host closed the connection]
<davidc__>
For a high-throughput LA; the bitstream and host (display) software will always be intertwined
<davidc__>
translation is no good.
<electronic_eel>
so new compression and the like could be developed without having to change other programs
<davidc__>
Unless you have gobs of CPU power, realtime decompression and recompression is a no-go
<electronic_eel>
but is 480mbit high throughput these days?
<davidc__>
and you definitely want to spool to disk in a compressed format
<davidc__>
its not necessarily the bitrate of the compressed data thats the problem; its the bit-rate of the uncompressed stream
<davidc__>
trivial example: a high speed, but very low duty cycle SPI bus
<electronic_eel>
yes, exactly. the low duty cycle bus is what I'm thinking of when talking about compression
<whitequark>
davidc__: you don't have to decompress
<whitequark>
you can translate one compressed format to another
<whitequark>
like two different kinds of RLE
<davidc__>
whitequark: assuming they are similar enough, yes
<whitequark>
you can decompress to some intermediate representation, generally
<tnt>
Can sigrok work internally with RLE compressed samples now ? A few month ago it couldn't (i.e. driver had to decompress to raw).
<whitequark>
i think decoders still have to do that? which is really odd.
<davidc__>
I didn't dive into the code, but it seems they still iterate sample-by-sample, rather than by-edge
<tnt>
depends on which PD, some definitely set 'conditions' / wait-for-change
<tnt>
but I wasn't even talking about the PD, I was just talking internally how sigrok & pulseview can represent the data from the session.
<marcan>
I used planes as recommended by the datasheet, but everything is wired prior to that on the topside, so they could be deleted without breaking anything
<electronic_eel>
marcan: it looks like they are recommending to connect pin 2 (nc) to the gnd plane in the datasheet
<electronic_eel>
(fig. 34 - layout example for DRV)
<marcan>
that's there because previously the 1V2 trace went pretty far down, and segmented the 3V3 plane kind of nastily (it was still connected but it felt too roundabout)
<marcan>
but now that pops off the top side regulator, so there's plenty of 3V3 plane
<_whitenotifier-9>
[GlasgowEmbedded/Glasgow] marcan pushed 3 commits to master [+1/-0/±7] https://git.io/fjsLl
<_whitenotifier-9>
[GlasgowEmbedded/Glasgow] marcan ddf1749 - revC1: add TLV733/755/757 in DFN-6 footprint to library
<_whitenotifier-9>
[GlasgowEmbedded/Glasgow] marcan f3fa13a - revC1: Replace 1V2/3V3 regulator with TLV755/733 series
<_whitenotifier-9>
[GlasgowEmbedded/Glasgow] marcan 1db6e87 - revC1: Add extra vias to the 1V2 regulator top side
<electronic_eel>
yes, the 3V3 stitich doesn't seem to be necessary now anymore
<marcan>
whitequark: okay, I can repro, and this is weeeeeeeird
<marcan>
the EN pin is dead at 0V, yet the regulator is passing current
<marcan>
but just *touching* EN kicks it into resetting
<whitequark>
yep
<whitequark>
probably a regulator bug? :(
<marcan>
yeah... let me look over the datasheet more closely
<electronic_eel>
is the en signal maybe dropping too slow for the regulator?
<electronic_eel>
there is a 100k pulldown, maybe that is too high?
<marcan>
maybe, I was going to test that
<electronic_eel>
when looking at fig 30 in the datasheet it seems that EN is used for all kinds of internal power
<electronic_eel>
like for the bandgap and error amp
<electronic_eel>
could be that it makes the en susceptible to glitches
<marcan>
not sure if that's really "power"...
<electronic_eel>
yeah, the figure is quite vague
<electronic_eel>
but they don't show a buffer with schmitt trigger at the en input
<electronic_eel>
so they probably don't have one
<marcan>
heeee no
<marcan>
the problem is we're oscillating
<whitequark>
whaaaaat
<marcan>
but...why
<electronic_eel>
who is oscillating?
<marcan>
whitequark: well the current limit is oscillating (the vusb one)
<marcan>
which is fine
<marcan>
but the question is why is EN going high
<whitequark>
i wonder if the FX2 has small internal pullups
<whitequark>
i... don't think it's supposed to?
<whitequark>
it might though
<marcan>
5V is going high but *not* 3V3
<marcan>
so... where is the current into EN coming from
<electronic_eel>
I had a similar problem when using an FTDI usb ic. During reset it enabled my power regulator, then when reset was finished it disabled it as it should
<marcan>
wait, no
<electronic_eel>
was a silicon bug in the ftdi in the end
<whitequark>
electronic_eel: see we don't trust the FX2
<marcan>
so I get about 400mV on 5V and 40mV on EN and 3V3
<marcan>
(had a snafu with probe settings)
<electronic_eel>
yes, not trusting usb ics is good practice
<marcan>
so the FX2 is presumably trying to pull EN high as 3V3 rises
<marcan>
I wonder what the startup behavior is here
<electronic_eel>
marcan: desolder the regulator and have a look with the scope during powerup
voxadam has quit [Read error: Connection reset by peer]
<marcan>
ugh, I have a ground loop making everything more confusing
<electronic_eel>
run a laptop off battery and with wifi, that gets rid of it (for low voltage cases like this)
<marcan>
yeah, EN is really 0V, the waveform I was seeing was the ground loop
<marcan>
shorting EN to GND does not unjam it
<electronic_eel>
can you try to catch the moment it goes down with the scope?
<marcan>
yeah
<marcan>
but let me fix the ground loop first
<electronic_eel>
then you can see if it falls slow or strange
<marcan>
btw, mine spontaneously recovers sometimes
<marcan>
ohh here's a fun one
<marcan>
if I trigger the short, then unplug the glasgow, then plug it back in, it does not recover
<marcan>
unplugging it, removing the short, reinstating the short, and plugging it back in *still* leaves it wedged
<electronic_eel>
but plugging in without the short fixes it?
<marcan>
however, removing the short and letting it power up properly, then reinstating it (with no vio now), and unplugging it and plugging it back in works
<marcan>
so there is some serious capacitance somewhere keeping something alive
<marcan>
it has one bit of long-term memory :D
<marcan>
maybe we just need discharge resistors on a bunch of rails?
<electronic_eel>
is the regulator enabled for a very short time during plugin?
<marcan>
if that were the case it would wedge on cold power up with a short unconditionally
<marcan>
but it doesn't
<electronic_eel>
like the fx2 pulling en up for a short time
<marcan>
it only happens after it was *already* wedged when it was powered down
<electronic_eel>
huh
<whitequark>
lol re: one bit of memory
<electronic_eel>
question is if it is the fx2, the regulator or something else
<marcan>
the regulator is definitely involved
<marcan>
because that EN pin is going nowhere near Vil
<electronic_eel>
maybe the thermal protection going crazy?
<marcan>
doesn't explain the memory :D
<electronic_eel>
it could still be hot when you replug
<electronic_eel>
so the temp is the memory
<marcan>
and it would still be hot after I replug after fixing the problem
<marcan>
so no
<marcan>
i.e. I can leave it unplugged for longer than a reset cycle
<electronic_eel>
I don't like this
<electronic_eel>
marcan: do you have samples of other ldo models laying around that would fit the footprint?
<marcan>
so the 1 bit of memory survives shorting all 3 rails to GND
<marcan>
*magic*
<electronic_eel>
maybe you can patent this as a new alternative to flash ;)
<marcan>
okay, I don't get this
<marcan>
it has to be the regulator, there is no other explanation
<marcan>
the one bit of memory is the gate capacitance of the pass FET of the regulator
<marcan>
EN is solid low
<electronic_eel>
there is some text about the pass fet gate in the datasheet of the reg, the enable section
<electronic_eel>
but it is vague
<marcan>
yeah
<electronic_eel>
seem they leave it to the user to discover what is going on...
<marcan>
seems to me that in the pursuit of low Iq they have absolutely no self-discharge on that gate
<electronic_eel>
yes, that may well be the reason
<electronic_eel>
so we should choose a regulator that isn't so optimized for low Iq
<marcan>
fwiw that thing holds charge for over 1 minute
<electronic_eel>
the gates in flash memory hold their charge for years
<marcan>
well yeah :p
<marcan>
but those are floating gates
<marcan>
this one is connected to stuff
<electronic_eel>
true
<electronic_eel>
but there is a reason why you usually put pulldowns on gates
<marcan>
so one solution to this is to just introduce some resistance
<marcan>
1 ohm across Vio definitely gets the regulator into current limiting, but doesn't kill glasgow entirely
<marcan>
that's 0.5V at 500mA, and we can stick it before the feedback divider so it'll just cause dropout, not bad regulation
<marcan>
I wonder how low we can go while avoiding the issue
<whitequark>
iiiinteresting
<marcan>
the problem here is that the regulator *does* have gate discharge
<electronic_eel>
at what current does your reg begin to limit?
<marcan>
but if the short is super low impedance, the *input* to the regulator doesn't rise high enough for it to start *working*
<marcan>
everything is so far below operating voltage it's just stuck in this weird limbo
<marcan>
but if you have just enough resistance to allow Vin to rise high enough for all the protections to kick in, it's fine
<electronic_eel>
the plan is to provide 150mA for Vio - that would be just 0.15V
<marcan>
yeah
<marcan>
well, we actually go higher, and that's good
<electronic_eel>
how high does the regulator go before it begins to limit?
<marcan>
oh btw
<marcan>
the culprit here is the VUSB current limit
<marcan>
bypassing that brings it back to life
<marcan>
maybe we should switch to the 1.5A version?
<whitequark>
that sounds fine
<marcan>
whitequark: should I mouser it and see if it fixes the problem?
<whitequark>
yep
<electronic_eel>
hmm, but does it limit at 1.5A or is that just the designed current
<electronic_eel>
with a limit at 2A or even higer?
<marcan>
2.15
<marcan>
but I mean, it's a safety
<electronic_eel>
There are nice usb current limiters available at LCSC
<electronic_eel>
they allow to set the current with a resistor
<marcan>
and fwiw, I could see myself wanting >500mA out of glasgow
<marcan>
give it 100mA for internal use, 300mA per port, that's 700mA
<marcan>
the current limit is actually 360mA typ per port