<_whitenotifier>
[glasgow] whitequark synchronize pull request #167: applet.sensor.ina260: add applet for the INA260 I2C power monitoring IC - https://git.io/JeCZS
<_whitenotifier>
[glasgow] whitequark closed pull request #167: applet.sensor.ina260: add applet for the INA260 I2C power monitoring IC - https://git.io/JeCZS
<_whitenotifier>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+1/-0/±1] https://git.io/JeC8i
<_whitenotifier>
[GlasgowEmbedded/glasgow] electroniceel 8374131 - applet.sensor.ina260: add applet for the INA260 I2C power monitoring IC.
<_whitenotifier>
[glasgow] whitequark commented on pull request #167: applet.sensor.ina260: add applet for the INA260 I2C power monitoring IC - https://git.io/JeC8P
<whitequark>
marcan: currently thinking if maybe we should get rid of two-interface mode from the firmware entirely
<whitequark>
one problem is that the windows kmdf usb target can't switch USB configurations, which is idiotic but we're stuck with it
<whitequark>
so if the default configuration is 1IF, then we get performance but can only ever run one applet
<whitequark>
and if the default configuration is 2IF, we can run up to 2 applets (or applet+analyzer) but it's slower
<whitequark>
by like 10 MB/s, and no longer saturates USB
<whitequark>
another problem is that having two completely different ways to packetize stuff is hard to test etc
<whitequark>
so i'm thinking, maybe we should get rid of two configurations, only ever have two FIFOs, and use your idea with 1st byte of packet as discriminant
<whitequark>
this makes exchanging 511-byte packets inefficient, but i think that's fine
<whitequark>
what worries me more is that suppose you have two applets, filling their respective FIFOs at 1/2 line rate
<whitequark>
i can't come up with a scheduling scheme that can result in filling the USB buffers at 1/1 line rate
<whitequark>
e.g. if the applets alternate by spewing 256 bytes and doing nothing for the next 300-400 cycles
<_whitenotifier>
[glasgow] electroniceel commented on pull request #167: applet.sensor.ina260: add applet for the INA260 I2C power monitoring IC - https://git.io/JeCBN
<electronic_eel>
whitequark: thanks for the invite. I guess you want me to continue to work with pull requests for anything but uncontroversial stuff, like archive-additions and such?
<electronic_eel>
whitequark: about the usb interface stuff you wrote above - will the 1st byte of packet always be set, or just if there are actually more applets in the gateware?
<electronic_eel>
set to the applet number I mean
<electronic_eel>
because you said you wanted to support direct-to-gateware interfaces on the host, like for supporting other programs like sigrok, openocd and such
<electronic_eel>
these would need to know the correct applet id and also actually add it to all urbs
<electronic_eel>
but how does an external program find out the correct applet it? do you need to set it as parameter there?
<electronic_eel>
id I mean, not it
<whitequark>
i don't know
<whitequark>
the same mechanism that communicates applet parameters
<whitequark>
which we don't have yet
<electronic_eel>
maybe a control request that responds with a descriptor table?
<electronic_eel>
or am I thinking too complicated here?
<electronic_eel>
a descriptor table will have to be really small though, we don't have much memory to waste
<whitequark>
yes
<whitequark>
that is the challenge here
<whitequark>
there are something like 4k free in firmware
<whitequark>
maybe it can be optimized more
<whitequark>
by changing functions to macros for example
<whitequark>
fucking 8051
<electronic_eel>
we have to add the interface to the internal i2c for the test jig to work, also the addon interface for revD
<electronic_eel>
so I wouldn't want to waste the 4k
<electronic_eel>
we could store the descriptor table on the host filesystem
<electronic_eel>
indexed by bitstream id or something like that
<whitequark>
i don't think that is any better than running the glasgow cli as a proxy
<electronic_eel>
^ which is something you don't like
<electronic_eel>
I think the cli proxy isn't all that bad
<electronic_eel>
we could make changes to the interface, like adding ids in the first byte or something, without the other programs knowing
<electronic_eel>
also the other programs don't have to care if glasgow is connected via usb or ip
<whitequark>
yes
<electronic_eel>
biggest downside I see is speed on revE
<whitequark>
speed on revE?
<whitequark>
why?
<whitequark>
11:22 < electronic_eel> I think the cli proxy isn't all that bad
<whitequark>
yeah, i'm thinking the proxy would have the same itnerface as revE over IP
<whitequark>
in fact
<electronic_eel>
the proxy will have to process the packets, that adds latency, buffering and all that. with a usb3 ss interface that matters
<whitequark>
it doesnt even have to be strictly in python
<whitequark>
it could be a rust thing
<whitequark>
on revE the USB interface will be solely CDC Ethernet
<whitequark>
well, maybe CDC-Ethernet and RNDIS or w/e the combination needed to support three OSes
<electronic_eel>
can you get a ss interface saturated with CDC ethernet without using kernel drivers for networking?
<whitequark>
why would you not use kernel drivers?
<electronic_eel>
routing, firewalls, ip conflicts,...
<electronic_eel>
security policy forbidding usb cdc ethernet
<whitequark>
it would be ipv6-only and use exclusively link local addresses
<electronic_eel>
(usb ethernet is a very common attack vector on locked win pcs)
<whitequark>
that solves routing, firewalls, and ip conflicts
<whitequark>
if your security policy prohibits cdc ethernet it will also prohibit winusb
<whitequark>
also: not my problem lol
<electronic_eel>
getting the usb hs saturated with the fx2 took some effort, fx2-side and in libfx2
<whitequark>
did it take any fx2-side effort?
<electronic_eel>
how is that with fx3, is it optimized for cdc ethernet?
<electronic_eel>
getting ss saturated is much more complex i guess, with lots of buffers to be filled and so on
<electronic_eel>
does the fx3 have the means for that?
<electronic_eel>
or can it only saturate the link if you use a custom, adapted protocol?
<whitequark>
i don't understand the question
<whitequark>
fx3 also gives you a fifo
<whitequark>
32-bit wide
<whitequark>
at 100 MHz
<whitequark>
so you can do 3200 Gbps, which is less than USB3 bandwidth
<electronic_eel>
so 3200 is the limit?
<whitequark>
yeah
<whitequark>
i dont' see why you couldn't do 3200 Gbps of Ethernet traffic
<whitequark>
er
<whitequark>
3200 Mbps
<electronic_eel>
i actually haven't looked at the fx3 datasheet for some time
<electronic_eel>
but i vaguely remember that the give you some sdk and tell you to stick to that because otherwise it will be hard to get anywhere near the specced speed
<whitequark>
i didn't look at it super in depth
<whitequark>
no
<whitequark>
oh
<whitequark>
wait, really?
<whitequark>
can you link to that?
<electronic_eel>
as i said "vaguely remember"
<whitequark>
i know there is an sdk
<whitequark>
but they give you register maps too
<whitequark>
so i'll write libfx3 ofc
<electronic_eel>
yes, registers are provided. but i don't know how hard it will be to get libfx3 to perform
<electronic_eel>
there might be some problem hidden in there t
jim123_456 has quit [Quit: leaving]
<electronic_eel>
that makes it hard to get the performance when sticking to cdc ethernet protocol
<marcan>
given the current architecture I think it doesn't make a whole lot of sense to commit to a fixed protocol
<marcan>
I'm fine with separate-process proxying as long as it doesn't become a performance problem
<marcan>
this might require some rethinking of the software architecture though
<marcan>
e.g. doing per-applet protocol management shenanigans in cython or rust or whatever
<marcan>
the current architecture has a bunch of layers in the fifo stuff that make everything nice and buffered, but once you start getting into high-bandwidth applets you're going to want to short circuit a lot of that
<marcan>
I guess for large packets the current solution is fime for high-speed USB, but going beyond that is going to be a problem
<whitequark>
marcan: i'm unconvinced it'll become a problem
<whitequark>
in fact, i'm quite definitely against providing the ability to short-circuit fx2crossbar
<marcan>
I mean at the software side
<whitequark>
whether it makes sense to do this for tcpv6 (and so drop down to udpv6 instead) is to be seen, probably yes
<whitequark>
hm
<whitequark>
but the software side complexity is what makes the current code fast
<whitequark>
that's like its only purpose
<marcan>
what I'm saying is that ultimately python is limited in how much $stuff you can do on the software side of things
<marcan>
and that at some point we're going to want to support something faster
<marcan>
we have this problem with openvizsla
<marcan>
it's horridly bottlenecked on parsing USB packets in python
<whitequark>
ohhh i see
<whitequark>
you mean the specific demux implementation in python
<whitequark>
not in general
<marcan>
and we're now talking about exporting the raw datastream and there is a bunch of discussion of pcap formats
<marcan>
but that also means the python at least needs to repacketize
<marcan>
and I'm not even sure if it can do that at line rate
<marcan>
yes
<whitequark>
ok
<whitequark>
that makes sense
<whitequark>
i think rust-demux would work well
<marcan>
yeah
<marcan>
basically I'm fine with moving a bunch of the data-munging to rust
<whitequark>
not moving
<whitequark>
duplicating
<marcan>
ah
<marcan>
sure
<marcan>
how would that integrate?
<whitequark>
there would be some way to specify a remote device
<whitequark>
which we need anyway, btw
<whitequark>
it would probably use a single control port and a bunch of data ports, per applet
<marcan>
sure
<marcan>
anyway, sounds like we're mostly on the same page here so I'm going to go back to cleaning up my living room, at least to the point where they can deliver the washing machine tomorrow
<whitequark>
ack
<marcan>
I have... a bunch of related deadlines this week.
<_whitenotifier>
[glasgow] electroniceel synchronize pull request #168: applet.interface.i2c_master: do write scanning before read scanning t… - https://git.io/JeC2L
<_whitenotifier>
[glasgow] whitequark closed pull request #168: applet.interface.i2c_master: do write scanning before read scanning t… - https://git.io/JeC2L
<_whitenotifier>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JeC2S
<_whitenotifier>
[GlasgowEmbedded/glasgow] electroniceel 9d7e113 - applet.interface.i2c_master: do write scanning before read scanning to reduce possible side-effects