Hi there!
I'm getting number 10 instead of 13 from my adruino.
I remember something that 13 is something like "end of line" or "carriage return".
In some cases 13 was replaced by 10 for some sort of simplification - I don't remember any more details.
What can I do to set up [comport] to output the correct numer 13 instead of 10?
There should be a setting for not treating it as a "modem" ...
Thanks!
Ingo
Hi Ingo
On Tue, 2019-05-14 at 07:38 +0200, Ingo wrote:
I'm getting number 10 instead of 13 from my adruino.
This sounds somehow familiar to me, but I can't recall the exact details of the issue nor am I able to find something about it on the web.
Have you ruled out any other source besides [comport]? Can you print the data with some other tool to make sure that the Arduino is not messing up the bytes 10 and 13? If it indeed [comport] is the culprit, then it should be quite easy to fix, but then again there we probably would find code that does the translation. I am not sure such code exists.
Roman
On 14/5/19 9:45 π.μ., Roman Haefeli wrote:
Hi Ingo
On Tue, 2019-05-14 at 07:38 +0200, Ingo wrote:
I'm getting number 10 instead of 13 from my adruino.
This sounds somehow familiar to me, but I can't recall the exact details of the issue nor am I able to find something about it on the web.
Have you ruled out any other source besides [comport]? Can you print the data with some other tool to make sure that the Arduino is not messing up the bytes 10 and 13? If it indeed [comport] is the culprit, then it should be quite easy to fix, but then again there we probably would find code that does the translation. I am not sure such code exists.
I have been having the same issue for quite some time now, and have posted it in this list in the past. Martin Peach replied by saying that he couldn't reproduce it and that [comport] doesn't interpret anything, so it shouldn't be a problem with the object, but I would leave that to him again, or anyone else who can give a definite answer.
I have tried Serial.write(13) and Serial.print((char)13) and they both output 10 in Pd. The work-around I have figured to this is to write a second byte after every value I send, and in case of sending a 13, send a unique value to this second byte, so that Pd knows it should be receiving a 13. It's double the load but in most cases it shouldn't be a problem, especially when writing raw bytes with Serial.write().
On Tue, 2019-05-14 at 10:00 +0100, Alexandros wrote:
On 14/5/19 9:45 π.μ., Roman Haefeli wrote:
Hi Ingo
On Tue, 2019-05-14 at 07:38 +0200, Ingo wrote:
I'm getting number 10 instead of 13 from my adruino.
This sounds somehow familiar to me, but I can't recall the exact details of the issue nor am I able to find something about it on the web.
Have you ruled out any other source besides [comport]? Can you print the data with some other tool to make sure that the Arduino is not messing up the bytes 10 and 13? If it indeed [comport] is the culprit, then it should be quite easy to fix, but then again there we probably would find code that does the translation. I am not sure such code exists.
I have been having the same issue for quite some time now, and have posted it in this list in the past.
Have you ruled out any other culprit? Have checked what is sent with some means other than [comport], for instance with the Arduino IDE? I don't have an Arduino at hand, so I don't know the exact procedure, but maybe there is a way to print data as hex values or so.
Roman
The strange thing is that I'm using 2 Arduino ProMicro.
Sometimes one does it and the other one is fine. Next time both of them do it and next time none of them. It's completely unpredictable. The same Arduino sends the same data that gets interpreted differently when I reopen Pd. So I wouldn't blame the Arduino in this case. I don't expect it to send different values upon reopening Pd. (I'm not sure if I did a hardware restart in between - I'll have to observe this.)
However, the Pd programming hasn't changed either ... I know there is some sort of modem code that replaced 13 with 10. Carriage Return is 13. Line Feed is 0x10. In some cases The Carriage Return is either followed or even replaced by Line Feed. It looks like this is happening here.
The question is: How can I control this type of Carriage Return behavior? I don not my Arduino to be handled as an old modem ...
I have tried Serial.write(13) and Serial.print((char)13) and they both output 10 in Pd. The work-around I have figured to this is to write a second byte after every value I send, and in case of sending a 13, send a unique value to this second byte, so that Pd knows it should be receiving a 13. It's double the load but in most cases it shouldn't be a problem, especially when writing raw bytes with Serial.write().
I have already a bunch of units out with the same hardware. So changing the programming on the Arduino is not necessarily the best choice.
Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Roman Haefeli Sent: Tuesday, May 14, 2019 11:38 AM To: pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
On Tue, 2019-05-14 at 10:00 +0100, Alexandros wrote:
On 14/5/19 9:45 p. ., Roman Haefeli wrote:
Hi Ingo
On Tue, 2019-05-14 at 07:38 +0200, Ingo wrote:
I'm getting number 10 instead of 13 from my adruino.
This sounds somehow familiar to me, but I can't recall the exact details of the issue nor am I able to find something about it on the web.
Have you ruled out any other source besides [comport]? Can you print the data with some other tool to make sure that the Arduino is not messing up the bytes 10 and 13? If it indeed [comport] is the culprit, then it should be quite easy to fix, but then again there we probably would find code that does the translation. I am not sure such code exists.
I have been having the same issue for quite some time now, and have posted it in this list in the past.
Have you ruled out any other culprit? Have checked what is sent with some means other than [comport], for instance with the Arduino IDE? I don't have an Arduino at hand, so I don't know the exact procedure, but maybe there is a way to print data as hex values or so.
Roman
Sorry, this was meant to be: Carriage Return is 13. Line Feed is 10 (not 0x10).
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Ingo Sent: Tuesday, May 14, 2019 12:31 PM To: 'Roman Haefeli'; pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
The strange thing is that I'm using 2 Arduino ProMicro.
Sometimes one does it and the other one is fine. Next time both of them do it and next time none of them. It's completely unpredictable. The same Arduino sends the same data that gets interpreted differently when I reopen Pd. So I wouldn't blame the Arduino in this case. I don't expect it to send different values upon reopening Pd. (I'm not sure if I did a hardware restart in between - I'll have to observe this.)
However, the Pd programming hasn't changed either ... I know there is some sort of modem code that replaced 13 with 10. Carriage Return is 13. Line Feed is 0x10. In some cases The Carriage Return is either followed or even replaced by Line Feed. It looks like this is happening here.
The question is: How can I control this type of Carriage Return behavior? I don not my Arduino to be handled as an old modem ...
I have tried Serial.write(13) and Serial.print((char)13) and they both output 10 in Pd. The work-around I have figured to this is to write a second byte after every value I send, and in case of sending a 13, send a unique value to this second byte, so that Pd knows it should be receiving a 13. It's double the load but in most cases it shouldn't be a problem, especially when writing raw bytes with Serial.write().
I have already a bunch of units out with the same hardware. So changing the programming on the Arduino is not necessarily the best choice.
Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Roman Haefeli Sent: Tuesday, May 14, 2019 11:38 AM To: pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
On Tue, 2019-05-14 at 10:00 +0100, Alexandros wrote:
On 14/5/19 9:45 p. ., Roman Haefeli wrote:
Hi Ingo
On Tue, 2019-05-14 at 07:38 +0200, Ingo wrote:
I'm getting number 10 instead of 13 from my adruino.
This sounds somehow familiar to me, but I can't recall the exact details of the issue nor am I able to find something about it on the web.
Have you ruled out any other source besides [comport]? Can you print the data with some other tool to make sure that the Arduino is not messing up the bytes 10 and 13? If it indeed [comport] is the culprit, then it should be quite easy to fix, but then again there we probably would find code that does the translation. I am not sure such code exists.
I have been having the same issue for quite some time now, and have posted it in this list in the past.
Have you ruled out any other culprit? Have checked what is sent with some means other than [comport], for instance with the Arduino IDE? I don't have an Arduino at hand, so I don't know the exact procedure, but maybe there is a way to print data as hex values or so.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Does that help:
https://superuser.com/questions/714078/wrong-newline-character-over-serial-p...
Roman
On Tue, 2019-05-14 at 12:35 +0200, Ingo wrote:
Sorry, this was meant to be: Carriage Return is 13. Line Feed is 10 (not 0x10).
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Ingo Sent: Tuesday, May 14, 2019 12:31 PM To: 'Roman Haefeli'; pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
The strange thing is that I'm using 2 Arduino ProMicro.
Sometimes one does it and the other one is fine. Next time both of them do it and next time none of them. It's completely unpredictable. The same Arduino sends the same data that gets interpreted differently when I reopen Pd. So I wouldn't blame the Arduino in this case. I don't expect it to send different values upon reopening Pd. (I'm not sure if I did a hardware restart in between - I'll have to observe this.)
However, the Pd programming hasn't changed either ... I know there is some sort of modem code that replaced 13 with 10. Carriage Return is 13. Line Feed is 0x10. In some cases The Carriage Return is either followed or even replaced by Line Feed. It looks like this is happening here.
The question is: How can I control this type of Carriage Return behavior? I don not my Arduino to be handled as an old modem ...
I have tried Serial.write(13) and Serial.print((char)13) and they both output 10 in Pd. The work-around I have figured to this is to write a second byte after every value I send, and in case of sending a 13, send a unique value to this second byte, so that Pd knows it should be receiving a 13. It's double the load but in most cases it shouldn't be a problem, especially when writing raw bytes with Serial.write().
I have already a bunch of units out with the same hardware. So changing the programming on the Arduino is not necessarily the best choice.
Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Roman Haefeli Sent: Tuesday, May 14, 2019 11:38 AM To: pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
On Tue, 2019-05-14 at 10:00 +0100, Alexandros wrote:
On 14/5/19 9:45 p. ., Roman Haefeli wrote:
Hi Ingo
On Tue, 2019-05-14 at 07:38 +0200, Ingo wrote:
I'm getting number 10 instead of 13 from my adruino.
This sounds somehow familiar to me, but I can't recall the exact details of the issue nor am I able to find something about it on the web.
Have you ruled out any other source besides [comport]? Can you print the data with some other tool to make sure that the Arduino is not messing up the bytes 10 and 13? If it indeed [comport] is the culprit, then it should be quite easy to fix, but then again there we probably would find code that does the translation. I am not sure such code exists.
I have been having the same issue for quite some time now, and have posted it in this list in the past.
Have you ruled out any other culprit? Have checked what is sent with some means other than [comport], for instance with the Arduino IDE? I don't have an Arduino at hand, so I don't know the exact procedure, but maybe there is a way to print data as hex values or so.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
This works:
$ sudo stty -F /dev/ttyACM0 raw
https://acassis.wordpress.com/2016/01/22/configuring-linuxs-serial-port-to-r...
Now I need to find a way to set it permanently to raw. I think the [comport] object should actually do this during initilization. There is no need for modem options in Pd.
Thanks, Roman for finding the cause!
Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Roman Haefeli Sent: Tuesday, May 14, 2019 12:58 PM To: pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
Does that help:
https://superuser.com/questions/714078/wrong-newline-character-over- serial-port-cr-instead-of-lf
Roman
On Tue, 2019-05-14 at 12:35 +0200, Ingo wrote:
Sorry, this was meant to be: Carriage Return is 13. Line Feed is 10 (not 0x10).
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Ingo Sent: Tuesday, May 14, 2019 12:31 PM To: 'Roman Haefeli'; pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
The strange thing is that I'm using 2 Arduino ProMicro.
Sometimes one does it and the other one is fine. Next time both of them do it and next time none of them. It's completely unpredictable. The same Arduino sends the same data that gets interpreted differently when I reopen Pd. So I wouldn't blame the Arduino in this case. I don't expect it to send different values upon reopening Pd. (I'm not sure if I did a hardware restart in between - I'll have to observe this.)
However, the Pd programming hasn't changed either ... I know there is some sort of modem code that replaced 13 with 10. Carriage Return is 13. Line Feed is 0x10. In some cases The Carriage Return is either followed or even replaced by Line Feed. It looks like this is happening here.
The question is: How can I control this type of Carriage Return behavior? I don not my Arduino to be handled as an old modem ...
I have tried Serial.write(13) and Serial.print((char)13) and they both output 10 in Pd. The work-around I have figured to this is to write a second byte after every value I send, and in case of sending a 13, send a unique value to this second byte, so that Pd knows it should be receiving a 13. It's double the load but in most cases it shouldn't be a problem, especially when writing raw bytes with Serial.write().
I have already a bunch of units out with the same hardware. So changing the programming on the Arduino is not necessarily the best choice.
Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Roman Haefeli Sent: Tuesday, May 14, 2019 11:38 AM To: pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
On Tue, 2019-05-14 at 10:00 +0100, Alexandros wrote:
On 14/5/19 9:45 p. ., Roman Haefeli wrote:
Hi Ingo
On Tue, 2019-05-14 at 07:38 +0200, Ingo wrote: > I'm getting number 10 instead of 13 from my adruino.
This sounds somehow familiar to me, but I can't recall the exact details of the issue nor am I able to find something about it on the web.
Have you ruled out any other source besides [comport]? Can you print the data with some other tool to make sure that the Arduino is not messing up the bytes 10 and 13? If it indeed [comport] is the culprit, then it should be quite easy to fix, but then again there we probably would find code that does the translation. I am not sure such code exists.
I have been having the same issue for quite some time now, and have posted it in this list in the past.
Have you ruled out any other culprit? Have checked what is sent with some means other than [comport], for instance with the Arduino IDE? I don't have an Arduino at hand, so I don't know the exact procedure, but maybe there is a way to print data as hex values or so.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I just tested this on another OS.
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.
If I send a MIDI program change from my EWI to the USB (-MIDI) input I get the correct program number. If I use the MIDI Din cable going from the EWI into my Arduino MIDI interface I get MIDI program #11 instead of #14 (counting from 1-128!). Still the number 13 gets replaced with 10.
This time the Arduino is a Arduino Micro and not a ProMicro with a different programming.
So, neither the OS nor the Pd or [comport] version seem to make any difference.
Ingo
-----Original Message----- From: Ingo [mailto:ingo@miamiwave.com] Sent: Tuesday, May 14, 2019 12:36 PM To: 'Ingo'; 'Roman Haefeli'; pd-list@lists.iem.at Subject: RE: [PD] Comport problem with Arduino: 13 is coming in as 10
Sorry, this was meant to be: Carriage Return is 13. Line Feed is 10 (not 0x10).
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Ingo Sent: Tuesday, May 14, 2019 12:31 PM To: 'Roman Haefeli'; pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
The strange thing is that I'm using 2 Arduino ProMicro.
Sometimes one does it and the other one is fine. Next time both of them do it and next time none of them. It's completely unpredictable. The same Arduino sends the same data that gets interpreted differently when I reopen Pd. So I wouldn't blame the Arduino in this case. I don't expect it to send different values upon reopening Pd. (I'm not sure if I did a hardware restart in between - I'll have to observe this.)
However, the Pd programming hasn't changed either ... I know there is some sort of modem code that replaced 13 with 10. Carriage Return is 13. Line Feed is 0x10. In some cases The Carriage Return is either followed or even replaced by Line Feed. It looks like this is happening here.
The question is: How can I control this type of Carriage Return
behavior?
I don not my Arduino to be handled as an old modem ...
I have tried Serial.write(13) and Serial.print((char)13) and they both output 10 in Pd. The work-around I have figured to this is to write a second byte after every value I send, and in case of sending a 13, send a unique value to this second byte, so that Pd knows it should be receiving a 13. It's double the load but in most cases it shouldn't be a problem, especially when writing raw bytes with
Serial.write().
I have already a bunch of units out with the same hardware. So changing the programming on the Arduino is not necessarily the best choice.
Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Roman Haefeli Sent: Tuesday, May 14, 2019 11:38 AM To: pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
On Tue, 2019-05-14 at 10:00 +0100, Alexandros wrote:
On 14/5/19 9:45 p. ., Roman Haefeli wrote:
Hi Ingo
On Tue, 2019-05-14 at 07:38 +0200, Ingo wrote:
I'm getting number 10 instead of 13 from my adruino.
This sounds somehow familiar to me, but I can't recall the exact details of the issue nor am I able to find something about it on the web.
Have you ruled out any other source besides [comport]? Can you print the data with some other tool to make sure that the Arduino is not messing up the bytes 10 and 13? If it indeed [comport] is the culprit, then it should be quite easy to fix, but then again there we probably would find code that does the translation. I am not sure such code exists.
I have been having the same issue for quite some time now, and have posted it in this list in the past.
Have you ruled out any other culprit? Have checked what is sent with some means other than [comport], for instance with the Arduino IDE? I don't have an Arduino at hand, so I don't know the exact procedure, but maybe there is a way to print data as hex values or so.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
So, neither the OS nor the Pd or [comport] version seem to make any
difference.
check my last two mails, I think this is macOS/Linux issue. can you try my fix?
Gesendet: Dienstag, 14. Mai 2019 um 13:07 Uhr Von: "Ingo" ingo@miamiwave.com An: 'Ingo' ingo@miamiwave.com, "'Roman Haefeli'" reduzent@gmail.com, adrcki@gmail.com, itensimon@gmail.com, pd-list@lists.iem.at Betreff: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
I just tested this on another OS.
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.
If I send a MIDI program change from my EWI to the USB (-MIDI) input I get the correct program number. If I use the MIDI Din cable going from the EWI into my Arduino MIDI interface I get MIDI program #11 instead of #14 (counting from 1-128!). Still the number 13 gets replaced with 10.
This time the Arduino is a Arduino Micro and not a ProMicro with a different programming.
So, neither the OS nor the Pd or [comport] version seem to make any difference.
Ingo
-----Original Message----- From: Ingo [mailto:ingo@miamiwave.com] Sent: Tuesday, May 14, 2019 12:36 PM To: 'Ingo'; 'Roman Haefeli'; pd-list@lists.iem.at Subject: RE: [PD] Comport problem with Arduino: 13 is coming in as 10
Sorry, this was meant to be: Carriage Return is 13. Line Feed is 10 (not 0x10).
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Ingo Sent: Tuesday, May 14, 2019 12:31 PM To: 'Roman Haefeli'; pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
The strange thing is that I'm using 2 Arduino ProMicro.
Sometimes one does it and the other one is fine. Next time both of them do it and next time none of them. It's completely unpredictable. The same Arduino sends the same data that gets interpreted differently when I reopen Pd. So I wouldn't blame the Arduino in this case. I don't expect it to send different values upon reopening Pd. (I'm not sure if I did a hardware restart in between - I'll have to observe this.)
However, the Pd programming hasn't changed either ... I know there is some sort of modem code that replaced 13 with 10. Carriage Return is 13. Line Feed is 0x10. In some cases The Carriage Return is either followed or even replaced by Line Feed. It looks like this is happening here.
The question is: How can I control this type of Carriage Return
behavior?
I don not my Arduino to be handled as an old modem ...
I have tried Serial.write(13) and Serial.print((char)13) and they both output 10 in Pd. The work-around I have figured to this is to write a second byte after every value I send, and in case of sending a 13, send a unique value to this second byte, so that Pd knows it should be receiving a 13. It's double the load but in most cases it shouldn't be a problem, especially when writing raw bytes with
Serial.write().
I have already a bunch of units out with the same hardware. So changing the programming on the Arduino is not necessarily the best choice.
Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Roman Haefeli Sent: Tuesday, May 14, 2019 11:38 AM To: pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
On Tue, 2019-05-14 at 10:00 +0100, Alexandros wrote:
On 14/5/19 9:45 p. ., Roman Haefeli wrote:
Hi Ingo
On Tue, 2019-05-14 at 07:38 +0200, Ingo wrote: > I'm getting number 10 instead of 13 from my adruino.
This sounds somehow familiar to me, but I can't recall the exact details of the issue nor am I able to find something about it on the web.
Have you ruled out any other source besides [comport]? Can you print the data with some other tool to make sure that the Arduino is not messing up the bytes 10 and 13? If it indeed [comport] is the culprit, then it should be quite easy to fix, but then again there we probably would find code that does the translation. I am not sure such code exists.
I have been having the same issue for quite some time now, and have posted it in this list in the past.
Have you ruled out any other culprit? Have checked what is sent with some means other than [comport], for instance with the Arduino IDE? I don't have an Arduino at hand, so I don't know the exact procedure, but maybe there is a way to print data as hex values or so.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Tue, 2019-05-14 at 13:27 +0200, Christof Ressi wrote:
So, neither the OS nor the Pd or [comport] version seem to make any
difference.
check my last two mails, I think this is macOS/Linux issue. can you try my fix?
Yeah, I will when I have access to an Arduino (or other serial device) and report back. Thanks for looking into this.
Roman
It's odd that the lines
/* no post processing */
new->c_oflag &= ~OPOST;
and
/* always nocanonical, this means raw i/o no terminal */
new->c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
_are_ present in open_serial() in comport.c. That should disable all postprocessing of traffic.
Martin
On Tue, May 14, 2019 at 7:58 AM Roman Haefeli reduzent@gmail.com wrote:
On Tue, 2019-05-14 at 13:27 +0200, Christof Ressi wrote:
So, neither the OS nor the Pd or [comport] version seem to make any
difference.
check my last two mails, I think this is macOS/Linux issue. can you try my fix?
Yeah, I will when I have access to an Arduino (or other serial device) and report back. Thanks for looking into this.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
That should disable all postprocessing of traffic.
I think the problem is input processing, look at the flags set by cfmakeraw (http://man7.org/linux/man-pages/man3/tcflow.3.html), they explicitly disable CR/NL transformation:
termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON);
I don't know what's the default value for c_iflag, but I suppose it's platform specific. maybe [comport] could just do cfmakeraw(), to make sure it is really in raw mode.
Christof
Gesendet: Dienstag, 14. Mai 2019 um 15:32 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
It's odd that the lines
/* no post processing */ new->c_oflag &= ~OPOST; and
/* always nocanonical, this means raw i/o no terminal */ new->c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
_are_ present in open_serial() in comport.c.That should disable all postprocessing of traffic. Martin
On Tue, May 14, 2019 at 7:58 AM Roman Haefeli <reduzent@gmail.com[mailto:reduzent@gmail.com]> wrote:On Tue, 2019-05-14 at 13:27 +0200, Christof Ressi wrote:
So, neither the OS nor the Pd or [comport] version seem to make any
difference.
check my last two mails, I think this is macOS/Linux issue. can you try my fix?
Yeah, I will when I have access to an Arduino (or other serial device) and report back. Thanks for looking into this.
Roman _______________________________________________ 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...]
Could it be possible that the operating system does this even before it gets to the comport object?
From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Martin Peach Sent: Tuesday, May 14, 2019 3:32 PM To: pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
It's odd that the lines /* no post processing */ new->c_oflag &= ~OPOST;
and /* always nocanonical, this means raw i/o no terminal */ new->c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
_are_ present in open_serial() in comport.c. That should disable all postprocessing of traffic. Martin
On Tue, May 14, 2019 at 7:58 AM Roman Haefeli reduzent@gmail.com wrote: On Tue, 2019-05-14 at 13:27 +0200, Christof Ressi wrote:
So, neither the OS nor the Pd or [comport] version seem to make any
difference.
check my last two mails, I think this is macOS/Linux issue. can you try my fix?
Yeah, I will when I have access to an Arduino (or other serial device) and report back. Thanks for looking into this.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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 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 mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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...]
Whatever version was current in September 2018 is the version I have installed in the new setup. I wouldn't have been surprised about this behavior in the old version from 2011 - but 2018?
I don't think there have been too many major changes since September 2018.
As I had mentioned before: Sometimes it works - sometimes it doesn't .
Ingo
From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Martin Peach Sent: Tuesday, May 14, 2019 4:20 PM To: pd-list@lists.iem.at Subject: 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 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 mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I ran this code on an arduino nano and sent it into a comport-print to verify that it passes all the values without change:
void setup() { Serial.begin(115200); while(!Serial); Serial.println("OK"); }
void loop() { static uint8_t x = 0; Serial.write(x); delay(25); x++; }
Maybe you could try that to be sure it's not your arduino code that's doing it.
Martin
On Tue, May 14, 2019 at 11:14 AM Ingo ingo@miamiwave.com wrote:
Whatever version was current in September 2018 is the version I have installed in the new setup. I wouldn't have been surprised about this behavior in the old version from 2011 - but 2018?
I don't think there have been too many major changes since September 2018.
As I had mentioned before: Sometimes it works - sometimes it doesn't .
Ingo
From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Martin Peach Sent: Tuesday, May 14, 2019 4:20 PM To: pd-list@lists.iem.at Subject: 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 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 mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
How could it be the Arduino code if everything works fine after I manually set the ttyACM0 to raw?
I have made myself a workaround by now to set all Arduino ttyACM* to raw by sending
stty -F /dev/ttyACM* raw
to a [shell] object after starting up the patch.
So the Arduino cannot be causing the problem. It's the [comport] object that does not correctly set to port to raw in "all" cases. Maye in most cases but not in "all" cases.
Ingo
From: Martin Peach [mailto:chakekatzil@gmail.com] Sent: Tuesday, May 14, 2019 5:28 PM To: Ingo Cc: pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
I ran this code on an arduino nano and sent it into a comport-print to verify that it passes all the values without change:
void setup() { Serial.begin(115200); while(!Serial); Serial.println("OK"); }
void loop() { static uint8_t x = 0; Serial.write(x); delay(25); x++; }
Maybe you could try that to be sure it's not your arduino code that's doing it.
Martin
On Tue, May 14, 2019 at 11:14 AM Ingo ingo@miamiwave.com wrote: Whatever version was current in September 2018 is the version I have installed in the new setup. I wouldn't have been surprised about this behavior in the old version from 2011 - but 2018?
I don't think there have been too many major changes since September 2018.
As I had mentioned before: Sometimes it works - sometimes it doesn't .
Ingo
From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Martin Peach Sent: Tuesday, May 14, 2019 4:20 PM To: pd-list@lists.iem.at Subject: 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 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 mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
How could it be the Arduino code if everything works fine after I manually set the ttyACM0 to raw?
I think I've already explained that in my previous mails. now can you try the code changes I've suggested? if you're not sure, I can send you a patched version you can compile and test.
Gesendet: Dienstag, 14. Mai 2019 um 17:53 Uhr Von: "Ingo" ingo@miamiwave.com An: "'Martin Peach'" chakekatzil@gmail.com Cc: pd-list@lists.iem.at Betreff: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
How could it be the Arduino code if everything works fine after I manually set the ttyACM0 to raw?
I have made myself a workaround by now to set all Arduino ttyACM* to raw by sending
stty -F /dev/ttyACM* raw
to a [shell] object after starting up the patch.
So the Arduino cannot be causing the problem. It's the [comport] object that does not correctly set to port to raw in "all" cases. Maye in most cases but not in "all" cases.
Ingo
From: Martin Peach [mailto:chakekatzil@gmail.com] Sent: Tuesday, May 14, 2019 5:28 PM To: Ingo Cc: pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
I ran this code on an arduino nano and sent it into a comport-print to verify that it passes all the values without change:
void setup() { Serial.begin(115200); while(!Serial); Serial.println("OK"); }
void loop() { static uint8_t x = 0; Serial.write(x); delay(25); x++; }
Maybe you could try that to be sure it's not your arduino code that's doing it.
Martin
On Tue, May 14, 2019 at 11:14 AM Ingo ingo@miamiwave.com wrote: Whatever version was current in September 2018 is the version I have installed in the new setup. I wouldn't have been surprised about this behavior in the old version from 2011 - but 2018?
I don't think there have been too many major changes since September 2018.
As I had mentioned before: Sometimes it works - sometimes it doesn't .
Ingo
From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Martin Peach Sent: Tuesday, May 14, 2019 4:20 PM To: pd-list@lists.iem.at Subject: 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 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 mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
here's a fork containing the fix: https://git.iem.at/ressi/comport/tree/input-fix - completely untested! :-) I won't be able two test myself for the next 2 weeks, so no need to rush.
Gesendet: Dienstag, 14. Mai 2019 um 13:56 Uhr Von: "Roman Haefeli" reduzent@gmail.com An: pd-list@lists.iem.at Betreff: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
On Tue, 2019-05-14 at 13:27 +0200, Christof Ressi wrote:
So, neither the OS nor the Pd or [comport] version seem to make any
difference.
check my last two mails, I think this is macOS/Linux issue. can you try my fix?
Yeah, I will when I have access to an Arduino (or other serial device) and report back. Thanks for looking into this.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I skimmed through the comport code and it certainly doesn't translate anything but I stumbled across this: https://stackoverflow.com/a/42218147/6063908 or look for INLCR in http://man7.org/linux/man-pages/man3/tcflow.3.html
this only seems to affect [comport] on non-Windows platforms.
you can try to add
new->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON);
after https://git.iem.at/pd/comport/blob/master/comport.c#L953 and recompile. if that works we should probably make a PR and fix this.
Christof
Gesendet: Dienstag, 14. Mai 2019 um 12:30 Uhr Von: "Ingo" ingo@miamiwave.com An: "'Roman Haefeli'" reduzent@gmail.com, pd-list@lists.iem.at Betreff: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
The strange thing is that I'm using 2 Arduino ProMicro.
Sometimes one does it and the other one is fine. Next time both of them do it and next time none of them. It's completely unpredictable. The same Arduino sends the same data that gets interpreted differently when I reopen Pd. So I wouldn't blame the Arduino in this case. I don't expect it to send different values upon reopening Pd. (I'm not sure if I did a hardware restart in between - I'll have to observe this.)
However, the Pd programming hasn't changed either ... I know there is some sort of modem code that replaced 13 with 10. Carriage Return is 13. Line Feed is 0x10. In some cases The Carriage Return is either followed or even replaced by Line Feed. It looks like this is happening here.
The question is: How can I control this type of Carriage Return behavior? I don not my Arduino to be handled as an old modem ...
I have tried Serial.write(13) and Serial.print((char)13) and they both output 10 in Pd. The work-around I have figured to this is to write a second byte after every value I send, and in case of sending a 13, send a unique value to this second byte, so that Pd knows it should be receiving a 13. It's double the load but in most cases it shouldn't be a problem, especially when writing raw bytes with Serial.write().
I have already a bunch of units out with the same hardware. So changing the programming on the Arduino is not necessarily the best choice.
Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Roman Haefeli Sent: Tuesday, May 14, 2019 11:38 AM To: pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
On Tue, 2019-05-14 at 10:00 +0100, Alexandros wrote:
On 14/5/19 9:45 p. ., Roman Haefeli wrote:
Hi Ingo
On Tue, 2019-05-14 at 07:38 +0200, Ingo wrote:
I'm getting number 10 instead of 13 from my adruino.
This sounds somehow familiar to me, but I can't recall the exact details of the issue nor am I able to find something about it on the web.
Have you ruled out any other source besides [comport]? Can you print the data with some other tool to make sure that the Arduino is not messing up the bytes 10 and 13? If it indeed [comport] is the culprit, then it should be quite easy to fix, but then again there we probably would find code that does the translation. I am not sure such code exists.
I have been having the same issue for quite some time now, and have posted it in this list in the past.
Have you ruled out any other culprit? Have checked what is sent with some means other than [comport], for instance with the Arduino IDE? I don't have an Arduino at hand, so I don't know the exact procedure, but maybe there is a way to print data as hex values or so.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
or just use cfmakeraw? http://man7.org/linux/man-pages/man3/tcflow.3.html
Gesendet: Dienstag, 14. Mai 2019 um 13:01 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: Ingo ingo@miamiwave.com Cc: pd-list@lists.iem.at Betreff: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
I skimmed through the comport code and it certainly doesn't translate anything but I stumbled across this: https://stackoverflow.com/a/42218147/6063908 or look for INLCR in http://man7.org/linux/man-pages/man3/tcflow.3.html
this only seems to affect [comport] on non-Windows platforms.
you can try to add
new->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON);
after https://git.iem.at/pd/comport/blob/master/comport.c#L953 and recompile. if that works we should probably make a PR and fix this.
Christof
Gesendet: Dienstag, 14. Mai 2019 um 12:30 Uhr Von: "Ingo" ingo@miamiwave.com An: "'Roman Haefeli'" reduzent@gmail.com, pd-list@lists.iem.at Betreff: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
The strange thing is that I'm using 2 Arduino ProMicro.
Sometimes one does it and the other one is fine. Next time both of them do it and next time none of them. It's completely unpredictable. The same Arduino sends the same data that gets interpreted differently when I reopen Pd. So I wouldn't blame the Arduino in this case. I don't expect it to send different values upon reopening Pd. (I'm not sure if I did a hardware restart in between - I'll have to observe this.)
However, the Pd programming hasn't changed either ... I know there is some sort of modem code that replaced 13 with 10. Carriage Return is 13. Line Feed is 0x10. In some cases The Carriage Return is either followed or even replaced by Line Feed. It looks like this is happening here.
The question is: How can I control this type of Carriage Return behavior? I don not my Arduino to be handled as an old modem ...
I have tried Serial.write(13) and Serial.print((char)13) and they both output 10 in Pd. The work-around I have figured to this is to write a second byte after every value I send, and in case of sending a 13, send a unique value to this second byte, so that Pd knows it should be receiving a 13. It's double the load but in most cases it shouldn't be a problem, especially when writing raw bytes with Serial.write().
I have already a bunch of units out with the same hardware. So changing the programming on the Arduino is not necessarily the best choice.
Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Roman Haefeli Sent: Tuesday, May 14, 2019 11:38 AM To: pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
On Tue, 2019-05-14 at 10:00 +0100, Alexandros wrote:
On 14/5/19 9:45 p. ., Roman Haefeli wrote:
Hi Ingo
On Tue, 2019-05-14 at 07:38 +0200, Ingo wrote:
I'm getting number 10 instead of 13 from my adruino.
This sounds somehow familiar to me, but I can't recall the exact details of the issue nor am I able to find something about it on the web.
Have you ruled out any other source besides [comport]? Can you print the data with some other tool to make sure that the Arduino is not messing up the bytes 10 and 13? If it indeed [comport] is the culprit, then it should be quite easy to fix, but then again there we probably would find code that does the translation. I am not sure such code exists.
I have been having the same issue for quite some time now, and have posted it in this list in the past.
Have you ruled out any other culprit? Have checked what is sent with some means other than [comport], for instance with the Arduino IDE? I don't have an Arduino at hand, so I don't know the exact procedure, but maybe there is a way to print data as hex values or so.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
i think it boiled down to using Serial.write with an explicit byte statement
Serial.write(byte(variable));
at least this works with all my midi gear here. what happens if you send 10 from the arduino? do you also get a 10 in pd?
On 14 May 2019, at 10:45, Roman Haefeli reduzent@gmail.com wrote:
Hi Ingo
On Tue, 2019-05-14 at 07:38 +0200, Ingo wrote:
I'm getting number 10 instead of 13 from my adruino.
This sounds somehow familiar to me, but I can't recall the exact details of the issue nor am I able to find something about it on the web.
Have you ruled out any other source besides [comport]? Can you print the data with some other tool to make sure that the Arduino is not messing up the bytes 10 and 13? If it indeed [comport] is the culprit, then it should be quite easy to fix, but then again there we probably would find code that does the translation. I am not sure such code exists.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 14/5/19 10:08 π.μ., Simon Iten wrote:
i think it boiled down to using Serial.write with an explicit byte statement
Serial.write(byte(variable));
at least this works with all my midi gear here. what happens if you send 10 from the arduino? do you also get a 10 in pd?
Doesn't work here, still get 10 instead of 13.
-
Alexandros -
Christof Ressi -
Ingo -
IOhannes m zmoelnig -
Martin Peach -
Roman Haefeli -
Simon Iten