On Mon, 2020-07-06 at 01:20 +0400, JULIO AGUIRRE wrote:
>
> On Thu, Jul 2, 2020 at 9:58 AM Gerhard Sittig <gerhard.sit...@gmx.net> wrote:
>
> > Well, open the file, look at the signal's timing, do the math. Do
> > you remember when I asked you to come up with a set of rules on
> > paper (forgetting that decoders might exist, or may get created)?
> > Rules that follow the available spec, and allow you to interpret
> > the data that you see in the capture. What is _your_ interpretation
> > of that capture, can _you_ see valid packet content there?
>
> [ ... ]
>
> PJON PJDL4.1 runs a completely software-defined implementation, in timing.h
> the different configurations for the supported devices are declared.
Unfortunately you did not respond to the most important question
that I raised above: What is _your_ interpretation of the traffic
that you captured when you hold it to the protocol spec? You know
the spec, you linked to it, you quoted it, you must have read it.
So you should be able to tell whether the signal that you inspect
is valid or isn't, and which data it contains when it's valid, or
why it's invalid when it is.
Forget about the decoder's existence when you try to answer that
question for yourself. Forget about any arbitrary choices which
an arbitrary implementation happened to have made. Nobody should
have to read the internals of an implementation to tell whether a
signal matches a protocol's spec. That's the point!
The implementation could be wrong, or make specific assumptions
which the spec does not support. Another implementation might
take a different choice, and still communication should not
break. Any other tool could be wrong. _You_ as the user need to
be able to verify for yourself whether the tool is correct. The
tool might support you and do the tedious work for you after you
verified it. But before that you need to verify that the tool
works for you. Which means that you need to be able to judge the
tool's correctness, by coming up with the correct answer for
yourself and compare the tool's output to your expectation. This
tool cannot decide for you whether you as an expert consider the
data correct. That's up to you!
You may notice that my protocol decoder does _not_ follow the
spec. If it would, it had considered _all_ currently available
captures as invalid. Go check the paper and see for yourself.
Strictly speaking that decoder is lying to you and you should not
trust it, but neither have I seen a spec that would allow your
traffic to decode at all. And I'm not going to change the decoder
to violate the spec even more than it already does. I will only
return to that implementation when either there is a clear bug in
the current version (which still wasn't shown), or when a spec
becomes available that better specifies what's valid traffic and
what isn't. Currently there are gaps and some hand waving, the PD
is the best that I could make of this paper. And sure I would add
support for more optional or variable length fields if support
would be missing and captures become available, but everything
that I've seen so far is supported by the current version of the
decoder and works as expected, including up to dump3.sr content.
> After fine tuning the definitions for stm32f103 the decoder
> works almost flawlessly in the dump3.sr.
Can you demonstrate where the PD fails to detect valid content in
that dump3.sr capture? Like show an image where a correctly sent
byte or bit isn't seen by the decoder? All "data loss" that I've
researched so far was due to glitches or incorrect timing or lack
of edges where some should be, and I've shown images of the
incorrect input. I do accept bug reports and honestly appreciate
these, but there really needs to be a bug before there is
something to fix. Show how correct input data results in wrong
output. Use the spec's words on it, not an implementation of
uncertain state. I'll happily fix when something is broken, but I
do need proper input to do that. Go to the above first and most
essential step of telling for yourself whether the captured
signal conforms to the spec that you have access to. Don't let me
guess where an issue may or may not be perhaps.
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
