<d1b2>
<david.lenfesty> Some little things to clean up and could probably be re-written to fully specify things, but we're not making a general-purpose protocol here so idc as long as it specifies everything
<d1b2>
<david.lenfesty> *fully re-written to improve clarity
<d1b2>
<david.lenfesty> Also added a few things we didn't talk about here but felt were necessary, namely specifying request/response and some error codes
<_whitenotifier>
[scopehal] azonenberg opened issue #395: Crash when using OpenCL FFTs and more than one FFT is active - https://git.io/JtVWS
<_whitenotifier>
[scopehal] azonenberg labeled issue #395: Crash when using OpenCL FFTs and more than one FFT is active - https://git.io/JtVWS
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 246 seconds]
Degi_ is now known as Degi
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
bvernoux has quit [Quit: Leaving]
_whitelogger has joined #scopehal
<d1b2>
<theorbtwo> Just read the protocol spec, and a few ideas... First off, is it worth defining a way for the probe to initiate a transfer? IE, if it has some sort of sideband information to report? Should there be support for the probe to report an arbitrary error string to the host, so it can report errors specific to the technique it is using? How about units information? Attenuation? S-parameters have already been mentioned. The spec seems to assume that
<d1b2>
the scope will have a whitelist of vid/PID pairs that it will recognize as valid. That seems awful vendor-lock-in-ish.
Nero_ has joined #scopehal
Nero_ is now known as NeroTHz
esden has quit [Read error: Connection reset by peer]
JSharp has quit [Read error: Connection reset by peer]
lukego has quit [Read error: Connection reset by peer]
sorear has quit [Read error: Connection reset by peer]
elms has quit [Read error: Connection reset by peer]
hlzr has quit [Read error: Connection reset by peer]
esden has joined #scopehal
sorear has joined #scopehal
lukego has joined #scopehal
hlzr has joined #scopehal
JSharp has joined #scopehal
elms has joined #scopehal
bvernoux has joined #scopehal
<d1b2>
<david.lenfesty> - Probably, but I also don't really know what information it would report. The simplest implementation would be not limiting requests/responses to either side and adding some registers on the host for extra info. - I guess it depends how we want to propogate these errors up the stack. A string basically needs to be propagated all the way back to the user to be useful at all. - The intent on my end was to just make the units depend on the
<d1b2>
register. If you don't have complete information about the register (not just units, but also function), then it's not useful to you, so IMO it's either add complete info about the register into the protocol or just leave it as an assumption on the host side. - Likely we would just be obtaining a single VID/PID and using it for all probes. We don't actually want/need to be properly USB compliant, so all probes will have the same VID/PID (unless I'm
<d1b2>
misinterpreting), and and if you want to design another probe you simply use the same pair. We aren't building a USB device we're building a device that uses USB protocols.
<azonenberg>
Yes we would be using a single vid/pid. The point of doing that isn't lock-in, it's to ensure we dont damage anybody else's hardware with +/- 7V on the data lines
<azonenberg>
the vid/pid check is the first of a two phase safety check (the second being the negotiation of exact voltage)
<azonenberg>
we'll be using the openmoko vid and a custom pid
<azonenberg>
so anybody could use it to make a custom probe if they wanted
<monochroma>
not pid 666? ;)
<monochroma>
er VID
<azonenberg>
lol
<azonenberg>
As far as the probe initiating a transfer, i don't see that happening
<azonenberg>
Probably 90% of probes will not even have any settings other than maybe a zero point for calibration
<azonenberg>
i dont think any of them will have input buttons etc
<monochroma>
hmm buttons on probes would be nice
<azonenberg>
for what though? it's an amplifier
<azonenberg>
offset null and maaaybe gain are about the only controls
<azonenberg>
if those are controllable it will be write only through scopehal
<monochroma>
i mean on probe itself
<miek>
a single trigger button on a probe would be really cool
<monochroma>
yeah
<monochroma>
i hate probing with one hand and realizing im a little to far to poke the trigger/reset button on the scope :P
<monochroma>
but maybe thats actually outside the scope (hah) of the probe
<monochroma>
have a seperate little trigger remote
<azonenberg>
Yeah, or a foot pedal or something
esden has quit [Read error: Connection reset by peer]