Avoid filtering on character stream (followup to #110)

[mptei]

retargeted to master from #110

[ytai]

Following up on the discussion on #110
Representing corrupt bytes on the Java API for the UART (InputStream) is somewhat unpleasant. Since this is not a really interesting case (typically resulting from very poor signal integrity, baud rate mismatch or the first byte when connecting to a live stream), I would rather not complicate the API.
If we agree with that, we face the choice of either sending an arbitrary byte or not sending anything. I opted for the latter, although one could probably find cases when the former is more useful. I'm reluctant to change this behavior for the time being.
However, your argument about discarding the wrong byte is solid. I'll be happy to accept a fix for that (or can do it myself if you prefer).

[mptei]

Suppressing bytes of a data stream is unpleasant to.

For me this is an interesting case, because I had this missing byte still at exactly the same position within a specific data transfer. Repeatable. For me it looked like the error signaling is wrong, because looking at the scope this byte had the same timings like the other bytes around. I looked in the erratas of the chip but didn't found a hint in this direction.

The case "the first byte when connecting to a live stream" is already handled without skipping, because your code is skipping the byte before the error byte. In this case there is no byte to skip.

By discarding a byte we lose more information than needed. The PIC gives the information that it has received a byte and that (it seems) there is an error with that byte. By discarding a byte you throw a valuable information away. Or you might say, at this level you don't know if it is valuable or not. But by throwing it away you decided that it is not valuable. In my opinion it is better to let a higher level make that decision.

When you throw a byte away, than for me it doesn't matter which byte. It breaks the communication anyway.

[ytai]

Thanks for taking the time to argue the case. I'm not convinced that your
solution is generally more correct than the other approach. I'm definitely
on-board with your find about throwing away the wrong byte, if you want to
push that. In any case, if ignoring the error is what's right for your app,
you can always use custom firmware.
If you're getting errors, though, there's definitely something wrong with
the setup, regardless.

On Wed, Jul 8, 2015 at 11:06 PM, mptei notifications@github.com wrote:

Suppressing bytes of a data stream is unpleasant to.

For me this is an interesting case, because I had this missing byte still
at exactly the same position within a specific data transfer. Repeatable.
For me it looked like the error signaling is wrong, because looking at the
scope this byte had the same timings like the other bytes around. I looked
in the erratas of the chip but didn't found a hint in this direction.

The case "the first byte when connecting to a live stream" is already
handled without skipping, because your code is skipping the byte before the
error byte. In this case there is no byte to skip.

By discarding a byte we lose more information than needed. The PIC gives
the information that it has received a byte and that (it seems) there
is an error with that byte. By discarding a byte you throw a valuable
information away. Or you might say, at this level you don't know if it is
valuable or not. But by throwing it away you decided that it is not
valuable. In my opinion it is better to let a higher level make that
decision.

When you throw a byte away, than for me it doesn't matter which byte. It
breaks the communication anyway.

—
Reply to this email directly or view it on GitHub
#111 (comment).