I think possibly the OP is using an older version of comport.
to quote Ingo:
My older system that did it was a relatively old Ubuntu 11.10 still using the older [comport] object with Pd-Extended. Now I tested with a rather new Debian (9.5 / 32bit) and a recent Pd (0.48) with the latest [comport] object. Both behave the same way.
I think the behavior of [comport] basically depends on the (OS-specific) default value of c_iflag. if disabling ICANON alone was sufficient to disable all input processing, why would cfmakeraw set all those input flags?
there are other sources suggesting to disable ICRNL (additionally to ICANON): https://viewsourcecode.org/snaptoken/kilo/02.enteringRawMode.html
I'd say let's try cfmakeraw() and see if it solves Ingo's problem. @Ingo can you add the code and compile [comport] yourself or do you need help?
Christof
Gesendet: Dienstag, 14. Mai 2019 um 16:19 Uhr Von: "Martin Peach" chakekatzil@gmail.com An: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
I just tried it here on both Windows 10 and Ubuntu with no issues. I can print every value from 0 to 255 from arduino and receive it unchanged in pd. I think possibly the OP is using an older version of comport. Martin
On Tue, May 14, 2019 at 10:03 AM IOhannes m zmoelnig <zmoelnig@iem.at[mailto:zmoelnig@iem.at]> wrote:On 14.05.19 15:47, Ingo wrote:
Could it be possible that the operating system does this even before it gets to the comport object?
well, those flags are supposed to control exactly what "the operating system does" in this respect.
fgmasdr IOhannes
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l... Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]