I think the Saleae Logic software should have a kind of DIY Logic Decoder Module "built in," that would allow anyone to easily design their own decoder without resorting to C.
The protocols included in Saleae Logic software are pre-set patterns that have been set down by an official international organization such as ANSI. If you're dealing with a protocol such as CAN (very big in the automotive industry), then of course that protocol is 100% compliant to industry standards. It's easy for Saleae to incorporate that into their software because it's easy to get a device that outputs the CAN protocols to test it. There can be no deviation.
However, if CAN were missing from Saleae, you could get the datasheet and sit down and write out some C code in accordance to the standard and perhaps within a few days you'd be up and running. That is, if you're a expert at Microsoft Visual C++.
However, real life has thrown me some curve balls that no logic analyser (as far as I know that is) has ever reasonably dealt with. There are protocols out in the concrete jungle that mother never told me about.
Take for instance, I2S audio. It dates back to the 80's. It's as old as the midi music standard. However, modern day engineers have resolved to get a few more miles out of this old dog by using something known as Time Division Multiplexing. TDM allows you to use the same two basic channels that the I2S data stream uses to add in multiple channels of audio by slicing up the audio data into very fine pieces and sending them down the pipe in a very neat row. However, each company has it's own unique way of doing this and it all starts on the hardware level with the ADC. Some IC's have multiple ADC's and some cut costs by only having two ADC and doing the TDM within the pre-mixer/multiplexer buffer. They all have one thing in common, the data sheets are pretty poor. You really need access to the engineers at the company in order work with these chips and they don't have much time for anyone else.
I can't begin to tell you how amazingly difficult it is working with Time Division Multiplexed audio streams. DSP can be just as difficult. There are no resources available. It would be nice if Saleae took the initiative to deal with such unknown protocols. It would really open a world of possibilities. Perhaps it could start experimentally with pattern recognition routines?
Jan Kok Jul 11, 2018
Yes, it would be great to have user-definable decoders that could be loaded into the Logic software so you could view the decoded traffic right in the Logic UI instead of exporting the data and writing a separate program to decode the data.
This would be useful when dealing with devices more complex than an EEPROM. For example, a motor controller might have commands like Set Top Speed, Set Acceleration, etc. It would be nice to decode that and show multibyte values in decimal, etc.
What language do you want to write the decoders in? My preference would be some standard programming language such as Python or C#. If there is a library available that does common decoding and display tasks, it would make writing decoders easier.
I'm not sure, but I believe that if Logic is built with C# (or C++?), it already has the capability to import a text file containing C# code and compile and run that code. I don't think Visual Studio is required. (But Visual Studio Community is free for individuals and small companies to use. See visualstudio.com)
A couple other things that should be considered in conjunction with this suggestion:
* Provide a full screen, spreadsheet-like, transaction-oriented display for viewing data, similar to the UIs provided by other manufacturers of bus analyzers.
* Provide a way to compare traces, for example a "good" and a "bad" trace, so that the differences are highlighted.
Joe Garrison May 23, 2019
The plan is to solve this comprehensively in the next-gen software by making it as easy as we possibly can to create your own protocol analyzers, ideally without needing to leave the software, and ideally with great community/github integration.
Automatic decoding of arbitrary waveforms is a hard problem generally speaking, but one we're thinking about longer term.