claireare there like. no good solutions for viewing logic analyser dumps on macOS? Both pulseview and GTKWave don't seem to run under modern macOS...
✧✦Catherine✦✧@protosphere pulseview isn't really "good" in first place; I'd convert it to a VCD and use Surfer
@whitequark Ohhh that is what I’m looking for. I’ll be getting VCD files anyway since I (will be) using the glasgow analyzer applet for this
@whitequark If you don't mind me asking, how does one actually use the glasgow analyzer applet? The docs state that it's removed, yet it still seems to be there. But I can't get it to produce anything except a 0-byte VCD file
@protosphere the removed thing is the "applet analyzer", a distinct entity from "analyzer applet" (internal vs external logic analyzer)
glasgow run analyzer foo.vcd should do something, if not run with glasgow -vvv and upload log
@whitequark Seems to do nothing (I'm terminating it with Ctrl-C). Log has one error, E: g.hardware.assembly: cannot configure pulls for port A: Vio is off. There's no activity after starting the applet.
@whitequark Yeah ok that makes sense. It was an optional parameter so I imagine it maybe detected automatically voltage if left out (imo this is not clear in the documentation for someone more less technical in electronics like myself)
@protosphere it's also using the legacy applet infrastructure which is slowly falling apart concurrently with us porting applets to V2 infrastructure (which has actual design and is the only one I'm comfortable documenting)
@protosphere to autodetect voltage based on "S" wire, use
-V A=SA@whitequark Is this the "VA SENS" pin on the included diagram?
@whitequark This seems to crash the applet when it actually detects something. If I can be reasonably confident it's 5V (80s electronics), can I set that? Can it potentially damage the device if it operates at a lower voltage?
@protosphere ah, that's a bug in the legacy infrastructure
the analyzer applet sets all pins to inputs and we've taken great care to make sure they are never accidentally set to outputs, but if you want to 100% make sure this will not damage the device you can just put some 10K inline resistors
note that this changes if you enable pull-up resistors as that will put 5V (via a 10k resistor) on every pin
@protosphere you can also use
glasgow voltage to see what's being sensed on the VA SENS wire and then manually set that voltage@whitequark ah that works wonderfully, thank you
@whitequark It looks to be 3.3v, with 6V on one pin (battery voltage). Though I'm not sure if this is a data line and it's being averaged out to around 3v. Will running 5V into the glasgow in 3.3V mode damage it?
@protosphere it will not damage the glasgow (note that 6V is right on the edge of absolute maximum ratings for the data lines, anything above that will damage it), however you must be aware that if you configure it for 3V3 and connect to a set of mixed 3V3/5V signals, the 5V from the 5V signals may end up escaping to the 3V3 signals via ESD diodes
@protosphere 6V on the sense line is fine, I don't remember what the AMR for that is but it's something over 20V
@whitequark Yeah this was on the sense line. I'll make note to avoid that pin when probing for data
@whitequark I'm still so far unsuccessful in producing a VCD file with data in it. Best I could get was this. Do I need to set either pull up or pull down?
@protosphere oh, right, this is a legacy applet
you need to set voltage on port B too on those
@whitequark ohhh there we go. it works now!
@protosphere (once it's ported to the V2 infrastructure, there will be an error message for this case, I just don't care to spend any more time supporting the legacy infra)
@whitequark That's totally fair
Thanks for all the help! So far the experience of using glasgow has been great overall. It's made this task much less daunting to work on
Thanks for all the help! So far the experience of using glasgow has been great overall. It's made this task much less daunting to work on
@protosphere nice, i'm very happy to hear that!
the underlying core of the analyzer applet is a bit weird (it is one of my first RTL designs dating back to like 2018, i was inexperienced then) so it might have some issues; if you hit overflows quickly, add --pull-ups or --pull-downs
(it compresses the capture data under the hood, which is good for long captures, except if the data is not very compressible like voltage around Vcc/2, it quickly overruns the buffers...)