search

ytai / ioio

Software, firmware and hardware of the IOIO - I/O for Android
Apache License 2.0
747 stars 355 forks source link

Avoid filtering on character stream (followup to #110) #111

Open mptei opened 9 years ago

mptei commented 9 years ago

retargeted to master from #110

ytai commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 https://github.com/ytai/ioio/pull/111#issuecomment-119830628.