I'm a developing a Windows application for communication with meter devices over serial modems. Some of the devices using half duplex communication. For that reason I'm setting the Windows RtsControl parameter to RTS_CONTROL_TOGGLE, which enables an automatic switch of the RTS line state.
Now I want to port this application to Linux. Is there an function to enable an equivalent feature to the RTS_CONTROL_TOGGLE parameter on a Linux OS?
If there is no such function, does a workaround exist to enable a similar behavior?
I'm assuming you're in user space - so you'll probably end up using an IOCTL. If you're moving from Windows to Linux for serial control I recommend reading The POSIX Serial Programing Guide. The link I give is an example for setting serial values with an IOCTL, you would need to change it to use TIOCM_RTS, TIOCM_CTS, but it gives the right idea.
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 want to write a driver for sensor which can tell me if my yoga 2 pro is in tablet mode or not.
I read some about writting modules but as far as I know, I need to know address in memory which belongs to this device (hope it's correct), and here is my question.
How can I find information about this address?
Or what should I do to find this address?
Both in Windows and in Android you absolutely don't need to write a driver for this purpose. To identify Tablet/Laptop mode, you need just one sensor - accelerometer. In Windows 8.1 + this functionality is built-in, but in case you wish to build your own application you can use an example from here: https://code.msdn.microsoft.com/windowsapps/Accelerometer-Sensor-Sample-22982671
In Android, you have a Java API to all sensors:
https://developer.android.com/guide/topics/sensors/sensors_overview.html
However if you have a custom Linux installed on your Yoga, there indeed may arise a need to add a driver. As of now, the most useful solution are IIO drivers that are part of Kernel:
http://events.linuxfoundation.org/sites/events/files/slides/lceu15_baluta.pdf
If there aren't already there, you'll have to rebuild a Kernel and include those drivers. If you don't know how to find a device address, you have to learn for a while about Linux Kernel in general. Anyway, some tips:
Sensors are normally defined via USB/HID interface
If you still have your Windows along with Linux, you may go to
Devices Manager and there you can easily reach Sensors and see what
address is used by a driver.
I have an Ada program that communicates with an Intellibox Basic(a box that allows you to control trains) that is connected via USB.
Under Windows, I had to install a specific Serial driver (CP210x USB to UART Bridge VCP). With that driver I can communicate perfectly with the box. That means sending commands to the box.
Under Linux I'm communicating via /dev/ttyusb0 and I'm able to get messages from the box, but I can't send commands to the box. Nothing happens. I don't get an error or something.
Is the behavior of GNAT.SerialCommunication differently on Linux ? The program is the same. Do I have to setup certain things to get it to work on Linux ?
For example: A typical 2-byte command has the Command as the first Byte and the CRC check as the second one.
I had trouble with Serial_Communication at some point, where it turned out to be a problem with hardware-handshake being enabled in Linux. It's hard-coded in g-sercom.adb, look for "CRTSCTS". If your Intellibox does not use hardware handshake, Write() will block.
I believe I solved it by removing the CRTSCTS mask from the flags.
My question is pretty much the same as -
How to create a virtual file?
except I want to do it in Linux instead. I imagine what I need to do is create a virtual device and point the application logging to that device. I'd like to write the device in python or ruby or something else interpreted, if possible.
check out named pipes http://en.wikipedia.org/wiki/Named_pipe
Use mknod. You can create a socket file which your apps can write too. And your logging app would connect to the socket to read from it.
Mocking usb devices using umockdev
Umockdev is a linux based application which record the behaviour as well as properties of hardware and run the software independent of actual hardware it is running on. Hardware devices can be simulated in virtual environments
without disturbing the whole system.It currently supports sysfs, uevents, basic support for /dev devices, and recording/mocking usbdevfs ioctls (for PtP/MTP devices).
umockdev home page
source code and examples
On this machine: http://www.nexcom.com/ProductModel.aspx?id=376f4fa5-64f3-41d1-afba-60ee48883465
I'm trying to access gpio, but neither Nexcom or Intel support has been very helpful.
The closest I've come is this blog post which says I have to write my own driver: http://geekswithblogs.net/BruceEitman/archive/2010/08/01/windows-ce-using-a-driver-to-readwrite-hardware-registers.aspx
From the nexcom manual it states gpio port is located at 0EE4H (0xEE4). What am I supposed to with this info? Am I really supposed to write my own driver?
edit: is must work on windows xp embedded and windows 7 embedded.
You can't directly access hardware resources (like GPIO pins) from userspace processes unless there's a driver that exposes this functionality. This means that either you find a suitable driver (I have no clue about where to look for such a thing) or you write your own.
p.s. It may also be the case that your OS expose the GPIO pins somewhere. On a linux prototyping board I worked on once there were a few files (IIRC /dev/gpioX, with X being the number of the pin) you could read/write to if you had the appropriate permissions.
You need GIVEIO.SYS.
It actually comes from Microsoft originally.
when you install it, you specify what port addresses you want.
then the user space program can access the ports directly.
You unix bretheren can just call ioperm() instead with the process running as a root. A shame MS didn't do that, but GIVEIO.SYS is okay.