<d1b2>
<mubes> Yeah, I've got a bodgeboard that will give me signals and they'll get a real digital adaptor to us sometime next month...by which time it will hopefully all be done and ready for test.
<azonenberg>
Excellent
<d1b2>
<mubes> They also provided SENT and MANCH codes so will fold the triggers in for those too...if I've got to do a full test it might as well be on the whole thing.
<azonenberg>
Great
<azonenberg>
We need to write trigger classes for those protocols
<azonenberg>
but you should be able to figure out how to do that
<azonenberg>
the only thing to be aware of is that in scopehal/scopehal.cpp there's one line to register the new trigger class in the table
<d1b2>
<mubes> Yeah, I'm getting a feel for how it all holds together.
<azonenberg>
on that note, right now trigger settings are not saved to .scopesession files
<azonenberg>
that has been on my agenda for a while, along with some other tweaks to the file format
<azonenberg>
but i've been too busy w/ other stuff to touch it
<azonenberg>
Is the code reasonably easy to learn your way around? At some point i really want more developer documentation
<azonenberg>
there isn't much of that at the moment, just the comments. all of the formal documentation is end user focused
<d1b2>
<mubes> I had a cursory look at the scpi for the other scopes too and I suspect it's quite different (probably different provenance)....once this is done we might need to borrow one of those from somewhere for a week or two....but that is later.
<azonenberg>
Yeah once we have proven results on the SDS2000X+ series, we should be able to arrange for testing and/or loaner hardware for other instruments
<d1b2>
<mubes> I think moving things into directories might help a lot (scope drivers, triggers etc) cos that makes it easier to see what to finch from, but if it fragments too much it doesn't really help.
<azonenberg>
Yeah that might be worth looking into at some point. Is the overall object model reasonable though?
<d1b2>
<mubes> For developers I personally prefer small markup files in each directory to say what they're for.
<azonenberg>
it took me a while to come up with this trigger model but it seems decent so far
<azonenberg>
also i forget if i mentioned but I have some test waveforms for MIL-STD-1553 now
<azonenberg>
i have one more decode to bang out that i need for $dayjob before i can get to that
<d1b2>
<mubes> Haven't grokked enough of it to criticise, but I can work on one part reasonably independently, which implies the inter-module coupling isn't too bad.
<d1b2>
<mubes> I can generate MANCH easily enough but will have to dig around to see if I've got any real SENT sources.
<azonenberg>
Yes, keeping the codebase modular was a big design goal
<azonenberg>
glscopeclient is not nearly as modular as i'd like
<azonenberg>
it needs a major refactoring but i havent had the time to plan it out yet
<azonenberg>
libscopehal is much nicer to work on in that regard
<d1b2>
<mubes> Close to putting Orb to one side for a week or two (which I need to do to get perspective back) so that'll be a good chance to get this done.
<azonenberg>
BTW, we need a manchester decode in libscopehal
<azonenberg>
So if you're going to make some manchester test waveforms for trigger testing, and have some time, maybe write a decode too?
<azonenberg>
the hard part with manchester will be figuring out how to do sync
<azonenberg>
Maybe look at how siglent's UI does it? and google around, see if you can find docs from lecroy/tek/keysight
<azonenberg>
I'm not saying blindly copy them, but learn from their design
<azonenberg>
Same thing with SENT. It's been on my list of decodes to write for a while, but i haven't actually done it because i haven't had any signal sources
<azonenberg>
so if you find something, or rig up a bitbanged signal source, now we'll have test data for a decode
<d1b2>
<mubes> Manch is pretty easy to create using Arm SWO.
<azonenberg>
I was gonna use 10baseT
<azonenberg>
i have waveforms for that already
<azonenberg>
in fact i have a working manchester decode as part of the 10baseT decode already
<d1b2>
<mubes> Or coded infrared etc. Yeah there are loads of sources at different speeds.
<azonenberg>
the only thing stopping me from pulling it out into its own filter is figuring out how to do sync
<azonenberg>
the implementation in the 10baseT decode i think actually relies on differential voltage
<azonenberg>
it works on the analog waveforms and going from differential zero to significant amplitude is the sync
<d1b2>
<mubes> The sync mechanism is pretty independent of the signalling afaik. I'll look how the scope does it as a starting point.
<azonenberg>
well *bit* sync is well defined
<azonenberg>
*byte* sync is not
<azonenberg>
especially if there's noise at the start of the packet
<_whitenotifier-5>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/JO8n2
<_whitenotifier-5>
[scopehal] azonenberg e0b8547 - Continued work on eSPI decode
<_whitenotifier-5>
[scopehal] azonenberg 552411f - Continued work on eSPI decode. Now works on raw signals instead of base SPI bus because eSPI needs weird 2-SCK cycle bus turnaround instead of something sane. See #407.
<_whitenotifier-5>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JO8Cl
<_whitenotifier-5>
[scopehal] azonenberg 8f60651 - eSPI: correctly detect x1 vs x4 mode via heuristics. See #407.
<d1b2>
<mubes> Scopehal saves me real-world time already....had a clashing bit where I was changing drive on the wrong edge, but couldn't easily see where in the protocol. Scopehal made that rather easy to find;
<azonenberg>
And yes, one of the things i want to make easy in general is finding things like CRC errors in upper layer protocols
<azonenberg>
then drilling down to find the PHY layer problem causing it
<d1b2>
<mubes> Yes, I already saw what happens when you add a MEMAP to this....very handy
<azonenberg>
BTW, longer term i plan to support integrating FPGA based logic analyzer IP cores with external scopes and trigger cascading
<azonenberg>
so you can do full-system debug of on an off chip stuff
<azonenberg>
most of the ground work is there already
<d1b2>
<mubes> Well, I'm figuring we'll bolt the digital channels of Orb into this pretty soon.
<azonenberg>
remind me, what is orb again?
<d1b2>
<mubes> CORTEX Debug and Trace
<d1b2>
<mubes> (FPGA Based)
<azonenberg>
oh, nice
<azonenberg>
Yeah, i'm all for developing more complex system level debug tools
<d1b2>
<mubes> but @zyp got enthusiastic and added some digital I/o too
<azonenberg>
e.g. being able to build something on top of the mem-ap decoder to be able to go all the way up to register names/fields rather than just raw pointers
<azonenberg>
maybe using SVDs if available
<azonenberg>
so you can debug programming algorithms by seeing what flash registers they poke
<d1b2>
<mubes> yep, or down to corrolated analog signals or across to s/w trace outputs
<azonenberg>
Yep
<azonenberg>
Exactly
<azonenberg>
Or have a protocol error inside FPGA logic triggering an analog scope looking at phy-layer signals
<azonenberg>
to find the source of a corrupted data bit
<azonenberg>
There's lots of potential
<d1b2>
<mubes> yup. The only issue with all of this is that very quickly you end up with a lot of data flying around
<azonenberg>
And this is why my lab is wired for 10GbE everywhere :p