I am creating an abstraction to ease the communication with an UBW (USB Bit Wacker: http://greta.dhs.org/UBW/index.html).
The abstraction uses comport to communicate with the device. It is considered as USB modem by the system. See the tail of dmesg when the device is plugged in to my Ubuntu machine:
[102406.169656] usb 1-5: new full speed USB device using ohci_hcd and address 8 [102406.381592] usb 1-5: configuration #1 chosen from 1 choice [102415.654264] usb 1-5: USB disconnect, address 8 [102416.484598 ] usb 1-5: new full speed USB device using ohci_hcd and address 9 [102416.706005] usb 1-5: configuration #1 chosen from 1 choice [102416.708971] drivers/usb/class/cdc-acm.c: This device cannot do calls on its own. It is no modem. [102416.708984] cdc_acm 1-5:1.0: ttyACM0: USB ACM device
The problem is as follows: The abstraction works fine in XP, but in Ubuntu, when I want to send more than three values (i.e. something like [77,65,49,42,13< ), comport complains that:
"[comport] write returned -1, errno is 11 Write error, maybe TX-OVERRUNS on serial line"
Now, ttyACM0 is a weird device because it does not have a baud rate. It simply sends the data as fast as it can. So, this message DOES not make any sense.
I know it is not a problem with my configuration of Ubuntu because I was able to establish proper communication with Perl.
Anybody have a clue on how to solve this or modify comport? (I used a version I compiled from pd cvs and another from pd-extended and both failed).
Tom
Thomas O Fredericks wrote:
I am creating an abstraction to ease the communication with an UBW (USB Bit Wacker: http://greta.dhs.org/UBW/index.html http://greta.dhs.org/UBW/index.html).
The abstraction uses comport to communicate with the device. It is considered as USB modem by the system. See the tail of dmesg when the device is plugged in to my Ubuntu machine:
[102406.169656] usb 1-5: new full speed USB device using ohci_hcd and address 8 [102406.381592] usb 1-5: configuration #1 chosen from 1 choice [102415.654264] usb 1-5: USB disconnect, address 8 [102416.484598 ] usb 1-5: new full speed USB device using ohci_hcd and address 9 [102416.706005] usb 1-5: configuration #1 chosen from 1 choice [102416.708971] drivers/usb/class/cdc-acm.c: This device cannot do calls on its own. It is no modem. [102416.708984] cdc_acm 1-5:1.0: ttyACM0: USB ACM device
The problem is as follows: The abstraction works fine in XP, but in Ubuntu, when I want to send more than three values (i.e. something like [77,65,49,42,13< ), comport complains that:
"[comport] write returned -1, errno is 11 Write error, maybe TX-OVERRUNS on serial line"
From an errno.h:
#define EAGAIN 11 /* Try again */
Maybe try sending the bytes one at a time slowly? I'm guessing that EAGAIN means the data has not been sent yet, it's still in the queue. I think it works in the XP version because write_serial() explicitly checks for an ERROR_IO_PENDING. But the result should be the same, the data gets sent anyway, the error is bogus. If that's the problem I'll fix it tomorrow in cvs.
Martin
Now, ttyACM0 is a weird device because it does not have a baud rate. It simply sends the data as fast as it can. So, this message DOES not make any sense.
I know it is not a problem with my configuration of Ubuntu because I was able to establish proper communication with Perl.
Anybody have a clue on how to solve this or modify comport? (I used a version I compiled from pd cvs and another from pd-extended and both failed).
Tom
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Martin,
just to make sure, the newest version of comport is in iem/comport/comport right?
"But the result should be the same, the data gets sent anyway, the error is bogus."
Nope, the data is never received by the device. Please note that there are only problems with sending data through comport (the actual message sent is 16 bytes long). I can receive long messages without a problem (sometimes a returned message can be as long as 63 bytes).
" Maybe try sending the bytes one at a time slowly?"
Yes, that works with the ridiculous slow drip/unfold speed of 5 ms between every byte!
Tom
Thomas O Fredericks wrote:
Hi Martin,
just to make sure, the newest version of comport is in iem/comport/comport right?
Yep.
"But the result should be the same, the data gets sent anyway, the error is bogus."
Nope, the data is never received by the device.
OK, I'll look into it. I guess comport should have a way of sending lists of bytes as well.
Martin
Hi Martin, I modified my local copy of comport to work with lists and it solved all problems.
I sooo don't know how to code in C, but this is what I added to make it work with lists:
//Added for LIST processing static void comport_list(t_comport *x, t_symbol *s, int argc, t_atom *argv) {
unsigned char temp_array[argc];
int i;
for(i = 0; i < argc; i++)
{
temp_array[i] = ((unsigned char) atom_getint(argv + i)) & 0xFF;
// post ("Data: %d", temp_array[i]);
}
int result = write(x->comhandle,(char *) &temp_array[0],argc);
if (result < 0)
post ("[comport] write returned %d, errno is %d", result, errno);
//return result;
} //Added end
Tom
On 10/11/07, Martin Peach martin.peach@sympatico.ca wrote:
Thomas O Fredericks wrote:
Hi Martin,
just to make sure, the newest version of comport is in iem/comport/comport right?
Yep.
"But the result should be the same, the data gets sent anyway, the error is bogus."
Nope, the data is never received by the device.
OK, I'll look into it. I guess comport should have a way of sending lists of bytes as well.
Martin
Thanks Thomas, I changed it a bit and it's in cvs now. Let me know if it works for you. I have it working with a serial LCD display from WinXp but haven't tried with linux yet. I also found a [print( message for comport that wasn't documented before. It will send a symbol as ascii. And someone else has added a [hupcl( message as well that doesn't work on Windows at all, so I moved it to the unix part.
Martin
Thomas O Fredericks wrote:
Hi Martin, I modified my local copy of comport to work with lists and it solved all problems.
I sooo don't know how to code in C, but this is what I added to make it work with lists:
//Added for LIST processing static void comport_list(t_comport *x, t_symbol *s, int argc, t_atom *argv) {
unsigned char temp_array[argc]; int i; for(i = 0; i < argc; i++) { temp_array[i] = ((unsigned char) atom_getint(argv + i)) & 0xFF; // post ("Data: %d", temp_array[i]); } int result = write(x->comhandle,(char *) &temp_array[0],argc); if (result < 0) post ("[comport] write returned %d, errno is %d", result, errno); //return result;} //Added end
Tom
On 10/11/07, Martin Peach martin.peach@sympatico.ca wrote:
Thomas O Fredericks wrote:
Hi Martin,
just to make sure, the newest version of comport is in iem/comport/comport right?
Yep.
"But the result should be the same, the data gets sent anyway, the error is bogus."
Nope, the data is never received by the device.
OK, I'll look into it. I guess comport should have a way of sending lists of bytes as well.
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Cool. It's great the behavior will be the same on XP and POSIX. I get the following warning (treated as an error):
cc -DPD -O2 -fPIC -funroll-loops -fomit-frame-pointer -Wall -W -Wshadow -Wstrict-prototypes -Werror -Wno-unused -Wno-parentheses -Wno-switch -I../../src -I../../../../pd/src -o comport.o -c comport.c cc1: warnings being treated as errors comport.c: In function 'write_serials': comport.c:1017: warning: comparison between signed and unsigned
It works if I replace line 1017 with: if (result != (int)buf_length)
Tom
Thomas O Fredericks wrote:
Cool. It's great the behavior will be the same on XP and POSIX. I get the following warning (treated as an error):
cc -DPD -O2 -fPIC -funroll-loops -fomit-frame-pointer -Wall -W -Wshadow -Wstrict-prototypes -Werror -Wno-unused -Wno-parentheses -Wno-switch -I../../src -I../../../../pd/src -o comport.o -c comport.c cc1: warnings being treated as errors comport.c: In function 'write_serials': comport.c:1017: warning: comparison between signed and unsigned
It works if I replace line 1017 with: if (result != (int)buf_length)
OK, it's changed. Thanks!
Martin
-
Martin Peach -
Thomas O Fredericks