<matt___>
I build a plugin board for the Raspberry Pi that adds the ADCs, current sense etc that we need for our tests
<matt___>
but I would change that in the future. better to use a windows laptop I think
<matt___>
PCBa factories are happier with that
<electronic_eel>
oh, you are making ergo keyboards? I'm using a keyboardio, you have maybe heard of those
<matt___>
yay!
<matt___>
we are using their firmware. We added the ARM support
<whitequark>
heh, interesting that an rpi is actually worse for this
<whitequark>
a windows laptop should work just fine with the glasgow software, although it will be slower than linux.
<whitequark>
maybe 2x?
<electronic_eel>
what were the issues the factories were having with the rpi?
<matt___>
how long does the selftest take?
<whitequark>
matt___: 1-2 seconds
<matt___>
sweet
<electronic_eel>
I'd include some run of the loop-benchmark to make sure there are no usb transmission errors - won't be reliable on windows
<whitequark>
wait, what?
<electronic_eel>
why not?
<whitequark>
no, I mean, why won't that be reliable on windows?
<whitequark>
or why would it be any different on windows?
<whitequark>
the only problem with windows (apart from stupid driver issues) is that it's slow
<electronic_eel>
I don't think the throughput and latency will be as reliable as on linux
<matt___>
electronic_eel: one part was that they'd not seen them before. another was that they're not used to linux so I had to include in the SOPs how to turn off the computer for example.
<electronic_eel>
matt___: ok, so just basic usability stuff. you could ro mount the filesystems so no need to shut down
<matt___>
yes, we got round most of it. I started off with the little touch screens, but they much preferred a keyboard, mouse and monitor
<matt___>
I think trying to keep things as the factory is used to helps smooth the process
<matt___>
even if it's not what I would want myself
<whitequark>
and tbh it'd be only marginally harder (if at all) for me to go for Windows.
<whitequark>
I think I would just provide the prebuilt bitstream and not bother with the toolchain
<matt___>
so in that respect, a test jig for esden would probably be fine running linux
<whitequark>
the rest is already supposed to be portable
<electronic_eel>
I think esden won't like using windows for the test jig
<whitequark>
the OS doesn't matter one way or another because the glasgow tools already are supposed to be portable
<whitequark>
the only difference is that when targeting Windows I'd have to do some equivalent of a Docker image
<whitequark>
py2exe is shit
<whitequark>
I'm not sure if there's portable Python but that'd be the easiest option
<matt___>
I've just had a good experience with pyinstaller
<matt___>
with qt5 and control of the jig with pyserial
<electronic_eel>
next to something that looks like a bunch of capacitors to me
<electronic_eel>
so much for them claiming they use optical coupling...
<electronic_eel>
... and I found the original manufacturer: Comwise Tech, model MG- 14346IS, http://35.222.228.198/usb-hubs/
<disasm[m]>
electronic_eel: seems like the ic left to the bottom usb port does the job
<electronic_eel>
yes, that's the silanna one
<electronic_eel>
but the usb 3 seems to be transferred just by coupling capacitors, the big ceramic ones next to the silanna
<disasm[m]>
But there is sort of differential line from left ic to the silanna ic and then to the right ic
<electronic_eel>
yes, it seems like they are using two usb hub ics there
<disasm[m]>
According to the GL3522 datasheet it's DM0,DP0
<electronic_eel>
maybe to buffer the signal before sending it over the capacitors?
<disasm[m]>
And TXN_UP,TXP_UP near DP/DM are "isolated" with capacitors
<disasm[m]>
Maybe it's ok to isolate differential lines with capacitors like this, I don't know. And DM0/DP0 are not strictly differential, so you need special ic for them
<electronic_eel>
you can transfer the data over capacitors like this. The problem is capacitative coupling. When one side floats on ac a current starts to flow
<electronic_eel>
yes, exactly. that is why we want that for glasgow too
<whitequark>
disasm[m]: then why are you saying "maybe you do not need them?"..
<disasm[m]>
I mean, why do you need an ic while you can buy a complete isolation device?
<whitequark>
have you seen how much they cost?
<disasm[m]>
They are present on market (ics are not)
<whitequark>
also
<disasm[m]>
Yes
<whitequark>
15:25 < whitequark> i wonder how the silanna chip works
<whitequark>
15:26 < disasm[m]> Just mail a few chips to zeptobars ;)
<whitequark>
this is why
<disasm[m]>
Hmm, I see
<whitequark>
I'd like to a) decap and b) design-in them. Neither of which I can do
<whitequark>
which sucks
<electronic_eel>
you don't trust usb hub manufacturers with safety, so you want to reverse the isolation device before putting high voltages between them
<whitequark>
also that
<whitequark>
dumb idea
<whitequark>
what if instead of USB isolator we made an Ethernet-to-USB bridge that speaks the Linux USB IP protocol in hardware
<electronic_eel>
ethernet signals are isolated, but the shield is not. also the signal isolation is just functional, not for safety
<electronic_eel>
so you'd either need an additional ethernet isolator or wifi
<whitequark>
of course, but you could build a safety rated ethernet port easily
<whitequark>
a wifi module with rgmii would work just fine
<daveshah>
Or optics
<disasm[m]>
And sort of SFP connector for those who want an optical cable option
<whitequark>
yep
<electronic_eel>
ah yeah, forgot about fiber
<electronic_eel>
that is properly isolated ;)
<disasm[m]>
Also SFP can be used for both copper and optics afaik
<whitequark>
yes
<whitequark>
but I'm not sure if safety rated SFPs exist
<electronic_eel>
why would you need safety rated sfp if you can just plug in fiber modules?
<whitequark>
because you don't have SFPs anywhere else?
pie_ has quit [Ping timeout: 252 seconds]
<whitequark>
I don't, for example
<electronic_eel>
you can buy ethernet/sfp boxes for like 30 bucks
<electronic_eel>
gigE, not 10gig though
<whitequark>
mhm
<davidc__>
whitequark: I'd considered doing that (USB over IP box). I concluded the cheapest way of doing it would be a RPI or equivalent SBC
<whitequark>
RPI USB performance is very bad.
<whitequark>
I would aim for 100% USB2 saturation
<electronic_eel>
rpi 4 should be better in that regard
<electronic_eel>
has usb 3 connected via pcie
<whitequark>
mhh right
<electronic_eel>
that is probably the cheapest way
<electronic_eel>
but also a bit clumsy for everyday use
<electronic_eel>
I just ordered the isolated Exsys hub, will give it a try
<electronic_eel>
flarum, haven't seen that one before
<whitequark>
TD-Linux: poke re: isa card
<TD-Linux>
*rolls excuse die*
<TD-Linux>
I just fixed the last midiori bug so I can start mailing them out right now.
<whitequark>
lol
<whitequark>
what's midiori
<TD-Linux>
my x68000 expansion card that implements the YM3802-X chip on fpga
<whitequark>
oh huh
<whitequark>
cool
<electronic_eel>
what kind of isa card do you want to develop for Glasgow?
<whitequark>
LPC to ISA converter, not Glasgow specific actually, not inherently anyway
<whitequark>
but it'd let me be an ISA host, ISA device, and a parallel ROM reader easily
<whitequark>
I was thinking about a PCI SERDES card but then I looked at the PCI spec
<whitequark>
PCI electrical spec is totally insane
<whitequark>
how did it ever work is totally beyond me
<electronic_eel>
so glasgow would do lpc, and this addon converts it to isa host or device?
<whitequark>
yes
<whitequark>
lpc is kinda bad actually but it seems easier to reuse it
<whitequark>
given that glasgow already needs to be lpc host and device
<electronic_eel>
already?
<whitequark>
and thta i want it to do ISA via some kind of SERDES
<whitequark>
i mean
<hellsenberg>
o_O
<whitequark>
being an LPC device is super useful
<whitequark>
for all sorts of intel platform work
<whitequark>
being an LPC host is a bit less useful but still handy
<whitequark>
and easier to do anyway
<whitequark>
so instead of making a totally new wire protocol for ISA it'd be cool to just use that for it
<whitequark>
since LPC is quite literally serialized ISA
<electronic_eel>
a lot of current mainboards still have lpc headers, but I haven't played with them yet
<whitequark>
yep
<whitequark>
lpc is very very common
<whitequark>
most laptops have it
<whitequark>
with minipcie anyway
<hellsenberg>
until not too long ago, LPC was on every single mainboard
<hellsenberg>
(sure, not always easy to hook on, but still there)
<whitequark>
did they deprecate it?
<whitequark>
is it "eSPI" now?
<hellsenberg>
not sure if they deprecated it, but I think they want to
<whitequark>
intel seems really obsessed with eliminating every single extra ball they can find
<electronic_eel>
isn't a lot of stuff, like the multi-io ic, usually connected via lpc?
<hellsenberg>
current chips can be strapped as either LPC or eSPI
<hellsenberg>
electronic_eel: the SuperIO and EC chipies used to be connected via LPC, but there's already eSPI variants of those
<electronic_eel>
is accessing them from the pc side transparent or is it different for espi?
<hellsenberg>
also Intel stuffed a SuperIO inside Haswell and newer, the PCU (Power Control Unit) iLB (integrated Legacy Block)
<hellsenberg>
I've never dealt with eSPI (all of my hardware is too old), but I hope that it doesn't have the strict timings SPI requires
<electronic_eel>
that timing would be something the chipset has to do, don't think they require the os to do it
<hellsenberg>
the devices would have to be fast enough to work, though
<electronic_eel>
but intel being intel, they probably hide it between three levels of registers that are invisible first
<whitequark>
>The slave may
<whitequark>
insert WAIT_STATE response code after the TAR window for any eSPI transactions if
<whitequark>
additional time is needed for the slave to sample the command and prepare the
<whitequark>
response
<whitequark>
it's like LPC in that regard
<hellsenberg>
oh, nice
<whitequark>
eSPI is actually uhhh not very like SPI
<whitequark>
in fact the 4-pin eSPI is a lot like LPC
<whitequark>
and not a lot like SPI at all
<hellsenberg>
I guess that either means that SPI sucks quite a lot or that eSPI is intel-grade cursed
<whitequark>
eSPI is intel-grade cursed.
<whitequark>
definitely.
<whitequark>
"The SMBus packets can be tunneled through eSPI as Out-Of-Band(OOB) messages. "
<electronic_eel>
haha
<electronic_eel>
seems they wanted to save pins, no matter the added complexity
<whitequark>
yes
<electronic_eel>
at least they didn't include multimaster and clock stretching...
<TD-Linux>
SPI is pretty underdefined, you can call a lot of things "SPI"
<TD-Linux>
I'm hoping I'll be able to write to my motherboard's LPC controller and expose a larger io port window to it
<TD-Linux>
whitequark found the docs earlier and it should be possible
<hellsenberg>
which board is it?
<hellsenberg>
if you use proper firmware, you can do whatever you want
<electronic_eel>
if you aren't scared away by the overly complex access schemes, you can poke around a lot in intel chipsets without involving firmware (as in bios/uefi)
<whitequark>
yes
<whitequark>
i did that
<TD-Linux>
yeah I was just going to poke the registers directly without telling linux
<electronic_eel>
i did it too once, had to switch a gpio of the chipset
<TD-Linux>
also my favorite file of the day is /proc/ioports