I have hardware device that is controlled through an rs-232 interface (Its an ultrasound pulser-receiver). I need to write a program to send the commands to the device from my computer. Unusually, however, the device does not have a serial port (DB-9 COM port) but rather has a RJ45 receptacle (an ethernet socket). The device comes with an adapter to connect the ethernet port on the device to a serial cable for communication with a computer.
Unfortunately my computer does not have a serial port - only an ethernet port. If possible I would like to do away with the adapter and connect my computer directly to the device with the ethernet cable. This is possible physically - but I don't know how to convert the message protocol? For instance, my device does not have an ip-address with which to open a tcp socket?
So far I have been using Boost.asio (on a Ubuntu box) for sending message streams via a tcp socket to other devices that support tcp. If possible I would like to continue to use the Boost.Asio library - since it is cross platform. I do not really know where to start - I have always used the Boost.Asio library which nicely hides most of the protocol issues. I believe it is possible, however, as there are windows programs that seem to do a similar thing, see for example http://com0com.sourceforge.net/
Any guiding advice would be welcome. Many thanks
Actually it doesn't work physically. It just works mechanically. The physical electrical voltages and currents used by ethernet is very different from that used by serial ports. Not only that, the pinouts are also incompatible.
Lucky for you ethernet uses magnetically coupled signals otherwise you would have fried either your motherboard or the ultrasound device.
It is not just a matter of software protocols.
You cannot do this directly. The best thing you can do, since your computer lacks an RS-232 serial port, is to add one.
This can easily be done either via USB-to-RS232 converter/dongle, or a PCI card.
You cannot program Ethernet to act like RS-232.
There's actually another solution. There are companies which makes serial-over-ethernet devices. I've personally worked with two:
Digi
Lantronix
It's a great solution although a bit on the expensive side.
Related
I realize that multiple bluetooth devices can be connected to a master device.
My question is simple: can a single bluetooth chip with a single MAC address connect to another bluetooth device as more than one client?
EDIT:
Basically is it possible to accept multiple bluetooth clients with the same MAC address, if not can the client computer connect using different faux addresses?
For example, I am writing software that emulates a wiimote for the Wii/WiiU. I am hoping to emulate more than a one wiimote using a single bluetooth usb dongle.
If a hack is needed C or C++ code would be prefered.
Preferably for windows if platform dependent.
Please be descriptive in any answers.
Bluetooth HID Spec v1.0
4.4 Multiple Devices per Host/Multiple Hosts per Device
Bluetooth HIDs shall set no limitation on the number of devices per host (up to the seven simultaneous active devices allowed per piconet). All trusted devices (devices that have either been authenticated or have no security procedures required) shall be allowed to have simultaneous connections to the host, if the host so desires. For example, multiple Bluetooth mice and keyboards are allowed. The behavior in this case shall be the same as for the USB case; i.e., input from all devices is allowed and the data streams are logically ORed together.
Similarly, a single Bluetooth HID may have established a bond or have its address known by multiple hosts. However, if it has declared itself virtually cabled, it is mandatory that the device only support a single host connection, and only one control and one interrupt L2CAP channel to that host, at one time (see SDP attribute HIDVirtualCable). If the device has not declared itself virtually cabled, it is still recommended that the device only support a single host connection at one time, i.e. no more than one SDP, control, and interrupt channel may be open at a time. A Bluetooth HID that implements the Virtual Cable feature shall have sufficient resources to remember a minimum of two hosts, and four hosts is recommended, to make later reconnection easier without passkey entry.
I'm not sure what you are asking for but:
A bluetooth network is called piconet, a piconet must have a min number of 2 devices and max 8 devices (7 slaves and 1 master). A device can be the member of one or more piconets but he can be only the master of one of them, this device is called bridge because he blends more piconets in a scatternet.
Therefore you can connect a single bluetooth chip with a single MAC address to more bluetooth devices , but i think you can't connect the same device A as more than one client to the same Master M because when the Master M starts the inquiry phase A will respond with his MAC address and his clock's offset only one time, later during the page phase M and A will establish one connection.
I have a controller which has a serial port and ethernet. I want to retrieve an event and the data associated with this event from the event directory through the serial or ethernet port of the controller. I do have a packet format (request packet data) for the specified event to be retrieved. Can anyone tell me how to retrieve the data by sending a request through the serial port? I am beginner and not that much well-versed in programming.
You will need to have some kind of a program running on your embedded platform, listening to the serial port and answering requests. This kind of program is usually called a "daemon" (pronounced the same as "demon"; just like "Caesar" rhymes with "sea star").
If you already have a daemon, you will need to figure out what format it uses. Since I have no idea what you might have I cannot even guess.
If you will be writing your own daemon, you will need to choose some sort of protocol. Personally I like the JSON format for a serial protocol; it is simple enough that you can extract data just using sscanf() from the C library if there is not a better library available, and of course it's easy to build JSON strings just using sprintf().
http://json.org/
What you want is the Serial Programming Guide for POSIX Operating Systems. If you are bound to Windows for some reason, you get POSIX through installing Cygwin. Expect to become familiar with man pages like termios and fcntl since you'll first have to set the serial port parameters to work with your device, though they're likely to be the standard 8-N-1 at some rate. Then it's a matter of reading and writing bytes to the port's file descriptor. You're more likely to be using the low level open(), close(), read(), and write(), which are a level below the stdio (printf, fopen, stdout) you're more likely to be used to as a newer programmer.
Computers these days often lack the RS232 serial port, so if you need one you can find a cheap USB adapter. Be aware that USB adapters don't necessarily implement some of the ancillary signals (RTS,CTS,etc.) in my experience.
Also look into libraries for your specific needs and situation.
You should specify the controller for more useful answers.
Your controller should support any data exchange protocol. You can find this info in documenttion. May be, it supports MODBUS or MODBUS TCP. In this case you can use any modbus compatible software.
I going to create kernel mode driver level app that establish a TCP connection, here is my requirement:
I don’t want pass data to user-mode
I don’t want use winsocket and OS socket library
I need to just pass tcp packet to a library and
the library create simple TCP-client or TCP-Server connection for me. It should perform all TCP connection requirements such as tcp handshake, generate packet, calculate checksum, set TCP flags and acknowledgment then give the new packet to me so I can send the packet to my network adapter.
Do you know exiting TCP implementation that it does not use OS socket library?
I think the proper way to ask this question is this:
What is the proper way to do TCP sockets within kernel code?
And I'm not sure you want to do TCP just at the packet level, because you'll also likely want to handle TCP segmentation, IP fragmentaion, sending only when the remote window size permits it, and ACK generation. In other words, if you're doing a TCP server within kernel mode, you want the whole kernel TCP stack.
In any case, Bing or Google around for "kernel sockets" or "ksocket".
For Linux: http://ksocket.sourceforge.net/ Also, check out this example for UDP.
For Windows: Go to this page and downlaod both the HttpDisk and KHttpd samples. Both feature a windows device driver than makes use of a similar "ksocket" library. (Look for ksocket.c and ksocket.h in each)
For Linux, use the kernel_*() versions of the usual socket API, i.e. kernel_bind(), kernel_listen(), kernel_accept(), kernel_connect(). They're in #include <linux/net.h> and are used in ways very similar to "normal" sockets.
Solaris has very similar interfaces, there named ksocket_*(), see #include <sys/ksocket.h> for references.
For the *BSD UN*X flavours, Apple's Network Kernel Extensions Guide gives some details (also with references to the corresponding interfaces on Free/Net/OpenBSD).
Don't know about Windows.
I know that serial ports work by sending a single stream of bits in serial. I can write programs to send and receive data from that one pin.
However, there are a lot more other pins on the serial port connection that normal aren't used but from documentation all seem to have some sort of function for signalling as opposed to data transfer.
Is it possible in any way to cause the other pins that are not used for direct data transfer to be controlled individually? If so, how would i go about doing that?
EDIT: more information
I am working with a modern CPU running windows 7 64-bit on an intel core i7 870 processor. I'm using serial to usb ports because its imposable for me to do anything directly with a usb port and my computer does not come with serial ports and also for some inexplicable reason i have a bunch of these usb to serial port adapters lying around.
My goal is to control mutipul stepper motors (200 steps per rotation, 4 phase motors). My simple circuitry accepts single high pulses and interprets it as a command to cause the motor to rotate one step. The circuit itself will handle the power supply and phase switching. I wish to use the data transfer pin to send the rotation signals (we can control position and velocity by altering the number of high pulses and frequency of high pulses through the pin, however there is no real pulse width modulation).
I have many motors to control but they do not need to be controlled simultaneously. I hope to use the rest of the pins and run them through a simple combination logic circuit to identify which motor is being moved and which direction it is to move in. This is part of the power switching circuitry.
The data transfer pin will operate normally at some low end frequency. However, i want to control the other pins to allow me to give a solid on or off signal (they wont be flipping very quickly, only changes when i switch to controlling another motor).
Based of the suggestion of Hans Passant , I'd like to suggest that you use an Arduino instead of an USB-to-serial converter. The "Duemilanove" is an Arduino-based board that provides 6 PWM outputs (as well as 8 other digitial I/Os and 6 analog). Some more specialized boards might be even cheaper (Arduino Pro Mini, $15 in volume, some soldering required).
Using the handshaking pins to send data can work very well, though probably not on a multitasking OS, it's just very processor intensive (because the port needs to be polled constantly) and requires some custom cables. In fact, back in the day, this is exactly how Laplink got such high transfer rates over serial connections (and why to get those rates you needed a special 'Laplink' cable). And you need both sides of hte link to be aware of what's going on and be able to deal with the custom communications. Laplink would send a packet of data over both the normal UART pins while trying to send data from the other end of the packet over the handshaking pins. If the correct cable wasn't used (or there was some other problem with sending over the handshaking pins) there was no problem - all the data would just get send normally.
Embedded developers might know this as 'bit banging' - often on small embedded systems there's no dedicated UART circuitry - to get serial communications to work they have to toggle a general I/O pin with the correct timing. The same can be done on a UART's handshaking pins. But like I said, it can be detrimental to the system if other work needs to be done.
You can use DTR and RTS only, but that is four possible states. You do need to be careful that the device on the other end uses TTL levels. At he end of this link Serial there are tips on hardware if you need it.
What kind of data rate are you thinking of when you say high frequency? What kind of serial port do you have? With the old 9 pin connectors on the back of the computer the best you can do is around 115Kbps. With a USB adapter I have done test where I could push close to 1Mbps through the port.
Here's an article from Microsoft that goes into great detail on how to work with serial ports:
http://msdn.microsoft.com/en-us/library/ms810467.aspx
It mentions EscapeCommFunction for directly controlling the DTR line.
Before you check out this information, I'm joining in with the others that say a serial port is inappropriate for your application.
I´ve been trying to find an answer to your question for 3 hours, seems like there is no "simple way" to get a simple boolean signal from a computer...
But, there is always a way, and jet, as simple (maybe even stupid) as this may sound, have you considered using the audio jack connector as an output?, It is stereo so you would have 2 outputs available,the programming would is not that difficult. and you don#t need to buy expensive shit to make it work.
If you also need an input, just disassemble a mouse... and bridge the sensors to the servos, probably the most cheap and easiest way of doing it...
Another way would be using the leds for the Num-lock, caps-lock and the dspl-lock on the keyboard, these can be activated using software, and you just need to take a cheap external keyboard, and use the connectors for these 3 leds.
you are describing maybe a parallel port - where you can set bit patterns all at once - then toggle the xmit line to send it all...
Lets take a look from the "bottom up" point of view:
The serial port pins
Pins on the serial port may be connected to a "controller" or directly connected to the processor. In order for the processor to have access (control) the pins, there must be an electrical connection from the pins to the processor. If not, the processor nor the program can control the pins.
Using a serial controller
A controller, such as a USART, would be connected between the serial port and the processor. The controller may function as to convert 8 parallel data bits into serial bitstream. In the big picture, the controller must provide access to the port pins in order for them to be controlled. If it doesn't, the pins can't be accessed. The controller must be connected to the processor in order to control the pins if a controller is connected.
The Processor and the Serial port
Assuming that the pins you want to control are connected to the processor, the processor must be able to access them. Sometimes they are mapped as physical addresses (such as with an ARM processor), or they may be connected to a port (such as the intel 8086). A program would access the pins via a pointer or using a i/o instruction. In some processor, the i/o ports must be enabled and initialized before they can be used.
Support from the OS
Here's a big ticket item: If your platform has an Operating System, the Operating System must provide services to access the pins of the serial port. The services could be a driver or an API function call. If the OS doesn't provide services, you can't access the serial port pins.
Permission from the OS
Assuming the OS has support for the serial port, your program must now have permission to access the port. In some operating systems, permission may only be granted to root or drivers and not users. If your account does not have permission to access the pins, you are not going to read them.
Support from the Programming Language
Lastly, the programming language must have support for the port. If the language doesn't provide support for the port you may have to change languages, or even program in assembly.
Accessing the "unused" pins of a serial port require extensive research into the platform. Not all platforms have serial ports. Serial port access is platform dependent and may change across different platforms.
Ask another, more detailed question and you will get more detailed answers. Please provide the kind of platform and OS that you are using.
I have a GPS device connected to my system which is running Windows Vista.
I wanted to read the NMEA sentences from GPS device and print on screen.
How I will come to know, on which port the GPS device has been connected, as there can be other devices also connected on various com ports. I am developing the application in c++,
Does Microsoft provide any API's for this?
What kind of port is it? If it is a serial port, try connecting to all serial ports, one at a time, and then just listen for a NMEA string. If one is received, use the port, if one is not received, go to the next port.
I'd tend to prompt the user for the port. NMEA typically comes in as an ASCII string through a COM port. Before bluetooth, this used to typically be COM1 to COM4 with 90% of cases being either COM1 or COM2. It is more common now to connect via bluetooth, where you regularly see COM ports up to COM20 and above, so brute force is a slow option. The time taken to check all ports depends on how often your GPS sends sentances (assuming it does not require prompting) and your time-outs. You could expect a search to take up to 30 seconds. If you enumerate the COM ports this will be much quicker, as there will rarely be more that half a dozen active ports at any one time.
Well, in old times you gave the user of your application the privilege to specify the proper port ;) Or indeed, check all of them. Format and the available set of NMEA sentences can differ depending on the particular device - read some info here, for example, but the sentences should be plain text. (If not then it's not NMEA format :) )