redstarcomrade has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
figushki has quit [Ping timeout: 276 seconds]
viskipappa has quit [Quit: ZNC 1.9.1+deb2+b2 - https://znc.in]
viskipappa has joined #glasgow
figushki has joined #glasgow
figushki has quit [Ping timeout: 276 seconds]
figushki has joined #glasgow
figushki has quit [Ping timeout: 248 seconds]
figushki has joined #glasgow
Foxyloxy has quit [Read error: Connection reset by peer]
figushki has quit [Ping timeout: 252 seconds]
figushki has joined #glasgow
figushki has quit [Ping timeout: 248 seconds]
figushki has joined #glasgow
figushki has quit [Ping timeout: 268 seconds]
redstarcomrade has quit [Read error: Connection reset by peer]
figushki has joined #glasgow
endrift[m] has joined #glasgow
<endrift[m]>
so I still haven't actually done anything with my glasgow, but would sniffing a USB 2 (I'm not sure what speed, but < USB 3 speeds) connection between a host and device be feasible to implement/something that's already available? The host in this case is embedded hardware, not a PC, so I can't just plug it into my computer and sniff USB directly
<endrift[m]>
I know the connection is pretty low bandwidth so it might just be FS, not even HS
<whitequark[cis]>
FS is feasible and relatively easy, though you might hit latency issues unless you have the RAM-Pak addon
<whitequark[cis]>
HS would require a specialized frontend (ULPI PHY), RAM-Pak is mandatory, and there will be a non-trivial amount of RTL development necessary, ideally by someome with an expert level understanding of USB
<endrift[m]>
I don't need things to be relayed in real time, but I don't know how much could be buffered without the RAM-Pak
<whitequark[cis]>
out of the box you could try the analyzer applet on FS but it will almost certainly overrun the buffer due to said latency issues
<whitequark[cis]>
okay, let's see. worst case latency on my debian system with a python host is about 2ms
<endrift[m]>
the connection is mostly idle, with short bursts that are unlikely to exceed a few hundred bytes per second. It's an input device, but not HID
<endrift[m]>
It's honestly probably FS, but I haven't checked
<whitequark[cis]>
USB FS adds two bits of data per cycle, you need to sample at least at 24 MHz (really 48), and you have 16 KiB of buffers on the FPGA plus about 2 KiB on the FX2
<endrift[m]>
the important part is the passthrough so it can communicate with its intended device
<endrift[m]>
hmm. It's mostly actually only the negotiation I'm curious about. I have the post-negotiation data pretty much down. But the negotiation is the part that transfers the most data
<whitequark[cis]>
at 12 MB/s, 2ms of worst case latency means 24 KB of data
<endrift[m]>
oh yeah there's no way it's gonna be that much data
<endrift[m]>
I just don't know how to get started with any of this
<whitequark[cis]>
however that latency figure is for bidirectional comms. unidirectional worst case latency can be as low as 125 us
<endrift[m]>
but then again, I also only have the device, not the host
<endrift[m]>
been trying to figure this out without the host
<whitequark[cis]>
endrift[m]: you probably would sample the raw D+D- lines without compression
<whitequark[cis]>
you *could* decode USB traffic but it's going to be more of a pain to analyze later if you do since you can't put it into pulseview or saleae anymore
<whitequark[cis]>
LUNA has a FS PHY if you want that
<endrift[m]>
can saleae logic decode USB?
<endrift[m]>
I'd love to just convert the signal to a pcap
<endrift[m]>
* to a decoded pcap
<whitequark[cis]>
not sure anything around will give you a pcap from a bit level capture
<whitequark[cis]>
not that i have seen
<endrift[m]>
yeah, that's why I want it decoed
<endrift[m]>
s/decoed/decoded/
<whitequark[cis]>
that's what I mean, I haven't seen LA decoders that give you a pcap
<endrift[m]>
the raw bits would need to be decoded into usb somehow
<whitequark[cis]>
they may exist though
<endrift[m]>
ah...
<whitequark[cis]>
usually you get like text logs or sth
<whitequark[cis]>
how urgent is this?
<endrift[m]>
that would be frustrating, but not the end of the world
<endrift[m]>
not
<whitequark[cis]>
ping me in a week and i might just write an applet for this
<endrift[m]>
I'll try to remember
<whitequark[cis]>
or whenever you care to think about it, i mean
<endrift[m]>
that's fair, but it's quite likely I'll have forgotten by then and have moved onto something else haha
<endrift[m]>
this is for a work project (hence the vague wording) but I don't think they'll care if I can't get this one detail right
<whitequark[cis]>
ah. then i'd say try to start with the analyzer applet
<endrift[m]>
well, first I'd need the device. I might need to borrow one, since it's kinda expensive
<whitequark[cis]>
it gives you a VCD you can import into PV, and has RLE compression
<whitequark[cis]>
yeah, a bit pricy for a one off, though if you do hardware security it might be easy to expense
<endrift[m]>
if there are better tools for this I'm open to it, I just have a Glasgow and realized it might be able to do this
<endrift[m]>
I mean the device this is a peripheral for
<whitequark[cis]>
oh wait the device as in DUT
<endrift[m]>
I have the peripheral and I'm trying to get it working on PC
<endrift[m]>
(I'm simplifying a lot)
<whitequark[cis]>
personally i have an openvizsla, which captures USB FS/HS fine but is quite janky itself
<endrift[m]>
but I don't have the thing it's a peripheral _for_
<whitequark[cis]>
and i can borrow my headmate's Beagle 5000 which is the industry standard USB analyzer
<endrift[m]>
I do have an old Saleae that might work if I just want the raw bits, but I was hoping that the Glasgow could decode it too
<whitequark[cis]>
in principle? yes. in practice? nobody wired it up yet
<endrift[m]>
fair enough
<whitequark[cis]>
so you'd have to start with LUNA FS PHY to do the decode
<endrift[m]>
I have 0 experience with HDL so it would be quite a diversion
<whitequark[cis]>
yeah
<endrift[m]>
if I just want a bit level capture I could probably just use the Saleae and call it a day
<endrift[m]>
which...may be what I end up doing, if that's what it's gonna wind up being anyway
<whitequark[cis]>
yeah makes sense
<endrift[m]>
I'd need a USB breakout I can tap but that's not hard
<whitequark[cis]>
FS is slow enough you could just cut a cable or solder to the pads
<endrift[m]>
it's a captive cable on the peripheral but I could always just cut open a USB extension cable
<endrift[m]>
that's what I did when I was tinkering with JOY a decade ago
<endrift[m]>
bought a gamecube extension cable, cut it open, tapped that
<whitequark[cis]>
asjackson: okay, i did a first review pass on the applet
<whitequark[cis]>
overall i think it looks pretty good, especially for someone's first applet! i don't see any major issues, just a bunch of loose ends to chase down and polish it a bit
<whitequark[cis]>
i do want to mention that i haven't examined and traced the main FSM in detail; there may be issues there that i wouldn't have noticed. i'm going to do this on a later review pass
<asjackson>
thanks whitequark[cis] ! :) really useful comments, since moving from registers to fifo it's become a tad temperamental so i still have some things to figure out
<whitequark[cis]>
yeah, i could take a look at the FSM later once i have more free time
<whitequark[cis]>
i want to finish the ARM7TDMI debugger first and send it off
<asjackson>
the pin numbering is currently very much uhhh they ended up that way when wiring :D will set them to something that works probably with a socket and pcb eventually
figushki has quit [Ping timeout: 244 seconds]
figushki has joined #glasgow
figushki has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
coderobe has quit [Ping timeout: 252 seconds]
figushki has joined #glasgow
coderobe has joined #glasgow
figushki has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
figushki has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]