I'm exploring porting a .NET C# application from Windows to Linux using Mono. The problem I'm stuck with is that asynchronous TCP socket calls do not work. This means that I can send data with no problems but I'm only seem to be able to receive the very first response from the socket (via Socket.BeginReceive()). The next BeginReceive() puts the thread into a wait state.
In it possible in principle that our socket code contains a bug but as it's been working flawlessly in Windows for years.
Thank you
This works fine with the mono-2-10 branch (soon to be released as Mono 2.10) and master.
The Mono 2.6.7 shipped with ubuntu fails and so does Mono 2.8. I've found the problem and I am testing a fix.. The next releases in the 2.6.x series will have the fix (also 2.8.x if there's any, since we are moving to 2.10 in a few days).
Btw, you should report problems in Mono following http://mono-project.com/Bugs instead of here.
If you use a synchronous socket, do things work as expected? That's a quick way to help narrow down the issue.
Related
I'm posing a question here directly in relation to this issue on github for node-serialport. In a nutshell something that used to work fine in v4.x of the library no longer works in v6.x of the library. I think it must have something to do with how the library is opening the COM port (options or something), and I suspect its artificially limiting the power delivered over USB in the current version of the library.
I wrote the simplest scripts that I could to reproduce the problem (scripts posted in the issue) using:
NodeJS and v4.x of the library [works]
NodeJS and v6.x of the library [fails]
Python and PySerial equivalent [works]
Following through on a recommendation by the repository maintainer, I researched and found a utility for windows called drstrace that allowed me to capture logs of the execution of each of these scripts executing for a period of time (these logs are posted as attachments in the referenced issue).
Now I'm stuck, as I don't know how to make heads or tails of the drstrace logs, though I feel confident that the difference is probably evident in comparing the three files. I just don't know enough about how to read the drstrace logs and windows drivers and system calls to break through.
I realized posting this question here is something of an act of desperation, but I figure it's worth a shot. Hopefully it is clear that I've not lacked in effort pursuing this on my own, I'm just over my head at this point, and could use help getting further. Any guidance would be appreciated. Most awesome would be someone who is versed in this level of diagnostics giving it a look and reading the tea leaves. It would be great to contribute back to such an important open source library.
Update 2017 Nov 10
I reached out to FTDI support asking:
I use the FT231X in many of my products. I need some help with
understanding how the Windows FTDI driver manages power. More to the
point, I'm hoping you can help me understand how to direct the driver
to allow the full 500mA allowed by USB to be delivered to my product
by a Windows computer.
The reply was:
Just use our FT_Prog utility to set the max VBUS current to 500
mA:
This drive current becomes available after the FT231X enumerates.
I haven't tried this advice yet, but I wanted to share it with anyone reading this. The fact remains that node-serialport 6.0.4 behavior differs from both node-serialport 4.0.7 behavior and pyserial behavior.
Here is an alternative theory you could look into:
Windows interacting with V6.x might be interacting with the flow control settings differently, which might be causing your device to respond with an unexpected state causing your test to fail.
I Read a bit more about windows drivers and how they manage that i only found out that its related to the hardware manufacturer i think its not a fail from serialport it self since its really using the drivers it self it adds no extras on that level.
i am Contributor of SerialPort and can tell you that it offers only bindings for the Operating System to node that means it don't does any actions it offers you only a API read the following from microsoft they say you should ask your hardware vendor
Power Management in Serial Port Drivers (Windows CE 5.0)
Windows CE 5.0
Send Feedback
The minimum power management that a serial port driver can provide is to put the serial port hardware into its lowest power consumption state with the HWPowerOff function, and to turn the serial port hardware fully back on with the HWPowerOn function. Both of these functions are implemented in the lower layer. Beyond this minimal processing, a serial port driver can conserve power more effectively by keeping the port powered down unless an application has opened the serial port. If there is no need for the driver to detect docking events for removable serial port devices, the driver can go one step further and remove power from the serial port's universal asynchronous receiver-transmitter (UART) chip, if no applications are using the port.
Most serial port hardware can support reading the port's input lines even without supplying power to the serial line driver. Consult the documentation for your serial port hardware to determine what parts of the serial port circuitry can be selectively powered on and off, and what parts must be powered for various conditions of use.
Source:
https://msdn.microsoft.com/en-us/library/aa447559.aspx
about changes from serialport v4 => 6
new Stream Interface
but nothing changed with the core opening method of the port.
also nothing changed in the bindings which open the port
node serialport is a collection of bindings written in c++
I'm trying to get the node-hid (https://github.com/node-hid/node-hid) module working on Windows 7. I can open a device and write to it, but no data ever arrives.
I've verified the device is sending data. I've dug through the node-hid code (HID.cc) and tried several things to get it working:
Modified the HID::recvAsync function to use an hid_read_timeout in a loop to see if that would return anything.
Set both blocking and non-blocking.
Changed buffer sizes to exactly fit what the device sends.
On Windows 8, with the hid_read_timeout call change, this all works fine. I'm not sure what may have changed between the two systems, but I plan on using this on windows XP as well, so I can't just call it good.
I'm struggling to come up with more ideas as to how to debug this issue. Has anyone successfully done this before? Is there a better option to use Node.js with an HID device?
After some serious debugging, I found that for some reason I have as of yet not been able to determine, the source file, HID.cc for the node module node-hid needed a call to hid_init() within the constructor before the hid_open call. I'm assuming that somehow this is getting hit with multiple threads, making the safety of calling hid_init before hid_open necessary.
I now have this working on both windows 7 and windows 8.
Summary of changes I had to make:
Add hid_init before the hid_open call I'm using.
Change hid_read to hid_read_timeout in a loop. (Since reads won't return on windows XP when shutting down otherwise.)
Once I've cleaned it up, I'll send the author my changes.
I'm running Asterisk 11.2.2 with SRTP and STUN support under Calculate Linux (Gentoo-based distribution).
When I try to call from one WebRTC instance to another, using JSSIP, the call passes, but if i answer it on another instance, the call suddenly terminates. Using Asterisk debug mode, i can catch 488 error (Not acceptable here).
If I use one SIP phone (Ekiga) instance instead of WebRTC, then I can call JSSIP from it, and everything works fine. Nevertheless, I can't call Ekiga from JSSIP, and this makes me confused.
Can you advise me, what have I do to localize this bug?
The problem was in my Asterisk: it had some WebRTC issues in 11.2.2 version. Upgrading to 11.4.0 makes everything works fine.
I just encountered the same issue, for me it was codecs issue. I was allowing only G729 in sip.conf file and hence it was throwing 488 error. For now, I fixed it by setting allow=all (I would check later on which particular codec does it needs).
I am working with the latest Lazarus compiler and have worked with Synaser for serial communication with the previous version of Lazarus. It has worked flawlessly, but now with latest version of Lazarus Synaser code is not even compiling but raising all sorts of error.
So, my question is this. Are there any replacement for Synaser tool for Lazarus? if not, is there an update to Synaser tool?
FPC 2.6.2
Lazarus 1.0.8
There are several Serial Communication (COM port) options available for Lazarus, but I would first suggest giving Synaser another try.
I'm currently using Lazarus 1.2.4 with Synaser from Synapse v40 and even latest trunk revision without any problems.
Alternative COM port implementations:
TComport port for Lazarus (cportlaz)
Serial Communications Windows API (CreateFile, ReadFile, SetCommMask, etc)
more in Hardware Access and Serial Communication for Lazarus
You can write your own library, on both Windows and Linux the COM ports are just files that you read and write to.
To answer your question : NO as far as I know and I use Lazarus almost every day.
Try
http://www.pilotlogic.com/sitejoom/index.php/codetyphon/codetyphon-download
It has synaser bundeled in and lot's more
I need to be able to read the serial port from within my JS code. I recently stumbled across this component
https://github.com/voodootikigod/node-serialport
What are the requirements for the client computer O/S?
To install it, all it says to do is
npm install serialport
What is that? Where should this command be run? More details would be appreciated.
Thank you
The module you've pointed out is for node.js an event-driven Javascript application server. The emphasis here is that node.js is server-side, not something that runs in a browser.
The command you've pointed out invokes npm, a package manager for node.js. You would need to execute that command on the server where the code expects to run.
While only the author of the code will be able to give you an authoritative answer, a quick review of both the Javascript and the C++ code doesn't seem to reveal anything that's platform specific.
Well, as long as you can compile that C++ code. That looks to be a problem if your server is on Windows.
The library seems to want to treat the serial port as a regular file. While this should be an obvious way to do it if you're on a Unixish operating system (Linux, BSD, Solaris, OS X, etc -- though I don't think Macs have had serial ports in a few decades), it's not immediately clear or obvious if you can just ask Windows to open COM1 and have it work correctly.
So, chances are that you'll have a much larger chance of success if you're hosting this on a Unix than on Windows.