Hi!
does anybody have a working [comport] for Windows? I have one that crashes after a few minutes at higher serial data traffic :-(
thanks in advance,
Piotr Majdak
does anybody have a working [comport] for Windows? I have one that crashes after a few minutes at higher serial data traffic :-(
what about pyext and pyserial?
cheers ... tim
Tim Blechmann wrote:
does anybody have a working [comport] for Windows? I have one that crashes after a few minutes at higher serial data traffic :-(
what about pyext and pyserial?
I have no python installed and I'd like to avoid to install it just for comport only. And, I've got a 56kbit/s stream coming from serial port - can a python script handle that?
br, piotr
I have no python installed and I'd like to avoid to install it just for comport only. And, I've got a 56kbit/s stream coming from serial port
- can a python script handle that?
i think so .... whenever i read "comport" or "serial", i only think of pyserial ... for my applications it just worked ...
tim
Hi,
does anybody have a working [comport] for Windows? I have one that crashes after a few minutes at higher serial data traffic :-(
thanks in advance,
Not being a Windows-Nerd, but we have the external working here stable since some years but we have one for win98 and one for WinNT, which has a different behavior...
Please tell us mor about your setting, which windows, which compiler....
Did you compile it yourself on the target machine ?
mfg winfried
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch@iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
- PGP-ID 69617A69 (see keyserver http://wwwkeys.at.gpg.net/)
--
Winfried Ritsch wrote:
Please tell us mor about your setting, which windows, which compiler....
The OS is Windows 2000, the comport.c was compiled with MS VS6.0 using the makefile.
Did you compile it yourself on the target machine ?
Two years ago IOhannes sent me a version of the comport external. It didn't work on Windows 2000 properly so I tuned it a little bit. I tested it, unfortunetaly, with slow traffic and short time period only (9600 baud, one or two minutes of communication) and thus, I thought I fixed the problem. Now, I use a higher baudrate (57600baud) and streamed data, which means, I get appr. 5000 Bps for the serial port and pd crashes like this:
I create the comport object with the proper baudrate in naked pd on the machine receiving the data stream and wait (the data stream from the periphery must have been started before). Half an hour later, pd increases the CPU load to 50% and becames not responsible...
I looked to the CVS repository for a newer version, but it seems to be the one I got from IOhannes. Do you have a newer one? If yes - could you put your version into CVS or just send me the comport.c file - I'd like to diff it against mine to see what I'm doing wrong here.
Thanx,
Piotr
Hallo,
Winfried Ritsch wrote:
The OS is Windows 2000, the comport.c was compiled with MS VS6.0 using the makefile.
for WINDOWS 2000 i had a #ifdef WIN2000 in my code which wasnt in CVS, i just committed now. This means the FILE_FLAG_OVERLAPPED at open is not used. I never found out why but then WINDOWS2000 worked,
Else the recommended code for Windows read is using
SetCommMask() and WaitCommEvent() before reading a byte
I put the code commented out in the external, maybejust uncomment and
compile again. This code dindt work for Windows NT so it was commented out,
even i copy and pasted it from seriell example of MS VS6.00 which also didnt
work.
Two years ago IOhannes sent me a version of the comport external. It didn't work on Windows 2000 properly so I tuned it a little bit. I tested it, unfortunetaly, with slow traffic and short time period only (9600 baud, one or two minutes of communication) and thus, I thought I fixed the problem. Now, I use a higher baudrate (57600baud) and streamed data, which means, I get appr. 5000 Bps for the serial port and pd crashes like this:
The complicated thing is that under Settings in Windows you can specify the baud rate and sometimes it was not possible to overwrite it with the example.
I create the comport object with the proper baudrate in naked pd on the machine receiving the data stream and wait (the data stream from the periphery must have been started before). Half an hour later, pd increases the CPU load to 50% and becames not responsible...
This looks like a blocked read (see above).
I looked to the CVS repository for a newer version, but it seems to be the one I got from IOhannes. Do you have a newer one? If yes - could you put your version into CVS or just send me the comport.c file - I'd like to diff it against mine to see what I'm doing wrong here.
I just updated the CVS now.
mfg winfried
Hi!
Winfried Ritsch wrote:
for WINDOWS 2000 i had a #ifdef WIN2000 in my code which wasnt in CVS, i just committed now. This means the FILE_FLAG_OVERLAPPED at open is not used. I never found out why but then WINDOWS2000 worked,
Yeah, that's exactly the same change I did in my version of comport. In overlapped mode, the thing gets more complicated...
I create the comport object with the proper baudrate in naked pd on the machine receiving the data stream and wait (the data stream from the periphery must have been started before). Half an hour later, pd increases the CPU load to 50% and becames not responsible...
This looks like a blocked read (see above).
I just updated the CVS now.
Thanks for the update - I'll test it, try to fix it if necessary and give you a summary of what happened. If I can't resolve the blocked read problem using nonoverlapped mode, I'll have to use serial port in overlapped mode - in this case I'm afraid I'll need your support :-)
Thanks again and greetings to Graz,
Piotr
Hi all,
Winfried Ritsch wrote:
The OS is Windows 2000, the comport.c was compiled with MS VS6.0 using the makefile.
for WINDOWS 2000 i had a #ifdef WIN2000 in my code which wasnt in CVS, i just committed now. This means the FILE_FLAG_OVERLAPPED at open is not used. I never found out why but then WINDOWS2000 worked,
i have no insight into the comport external but a #define WIN2000 seems odd to me. To differentiate between Windows and linux there are other preprocessor defines like _WIN32 which should be defined for every Windows-based compiler (or __linux__ respectively). To make a compilation specific for different Windows versions, like Win95, 2000, XP the preprocessor definitions WINVER and _WIN32_WINNT should be used (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winprog/win...) which also let the respective Windows API functions be included. There are other available definitions for MacOS (9/X CFM/MachO) and linux.
It would be great if the PD (as already motivated by James Tittle, as i think to recall) and external sources could use these symbols for automatic configuration.
best greetings, Thomas
Hello,
for WINDOWS 2000 i had a #ifdef WIN2000 in my code which wasnt in CVS, i just committed now. This means the FILE_FLAG_OVERLAPPED at open is not used. I never found out why but then WINDOWS2000 worked,
i have no insight into the comport external but a #define WIN2000 seems odd to me.
[...]
You are right. I used a definition which is not official because the code should be never used except on some windows2000 computer where we dont know why this is needed. So I used this trick just to get some more testing and input to fix this issue more seriously, not breaking other compilations and then this define will be removed. It should not be used by default even for windows2000 machines. Maybe i should rename it to BUGWIN2000 or so.
mfg winfried
To differentiate between Windows and linux there are other preprocessor defines like _WIN32 which should be defined for every Windows-based compiler (or __linux__ respectively). To make a compilation specific for different Windows versions, like Win95, 2000, XP the preprocessor definitions WINVER and _WIN32_WINNT should be used (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winprog/wi nprog/using_the_windows_headers.asp) which also let the respective Windows API functions be included. There are other available definitions for MacOS (9/X CFM/MachO) and linux.
It would be great if the PD (as already motivated by James Tittle, as i think to recall) and external sources could use these symbols for automatic configuration.
best greetings, Thomas
-
Piotr Majdak -
Thomas Grill -
Tim Blechmann -
Tim Blechmann -
Winfried Ritsch