controling individual pins on a serial port - c++

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.

Related

Qt modbus serial port flow control handling

I'm writing a small program using QModbusDevice over the serial port (using the QModbusRtuSerialMaster class) and have some problems.
One of the problems seems to be that the flow control of the serial port is incorrect. Checking in a serial port sniffer I see that a working client sets RTS on when it sends requests, and then RTS off to receive replies. When I use QModbusRtuSerialMaster to send messages that doesn't happen.
The message is sent correctly (sometimes, subject for another question) compared to the working client. It's just the control flow that doesn't work and which causes the servers to be unable to reply.
I have set the Windows port settings for the COM-port in question to hardware flow control but it doesn't matter, the sniffer still reports no flow control.
Is there a way to get QModbusRtuSerialMaster to set the flow control as I would like? Or is there a way to manually handle the flow control (which is what the working client does)? Or is the only solution to skip the Qt modbus classes and make up my own using the serial port directly?
A short summary of what I'm doing...
First the initialization of the QModbusRtuSerialMaster object:
QModbusDevice* modbusDevice = new QModbusRtuSerialMaster(myMainWindow);
modbusDevice->setConnectionParameter(QModbusDevice::SerialPortNameParameter, "COM3");
modbusDevice->setConnectionParameter(QModbusDevice::SerialParityParameter, QSerialPort::NoParity);
modbusDevice->setConnectionParameter(QModbusDevice::SerialBaudRateParameter, QSerialPort::Baud115200);
modbusDevice->setConnectionParameter(QModbusDevice::SerialDataBitsParameter, QSerialPort::Data8);
modbusDevice->setConnectionParameter(QModbusDevice::SerialStopBitsParameter, QSerialPort::OneStop);
modbusDevice->setTimeout(100);
modbusDevice->setNumberOfRetries(3);
modbusDevice->connectDevice();
Then how I send a request:
auto response = modbusDevice->sendReadRequest(QModbusDataUnit(QModbusDataUnit::Coils, 0, 1), 1);
QtModbus does not implement an automatic toggling for the RTS line because it expects your hardware to do it on its own (with a dedicated line instead).
This should be the case for most RS485 converters (even cheap ones). You would only need the RTS line if you have a separate transceiver like this one with a DE/~RE input.
If you were on Linux and had some specific hardware you could try to use the RS485 mode to toggle the RTS line for you automatically. But you don't seem to be on Linux and the supported hardware is certainly very limited.
You can also toggle the line manually with port.setRequestToSend(true), see here. But note that depending on the timing needs of the device you are talking too, this software solution might not be very reliable. This particular problem has been discussed at length here. Take a look at the links on my answer too, I made some benchmarks with libmodbus that show good results.
Enabling or disabling flow control on the driver won't have any effect on this issue because this is not actually a flow control problem but a direction control one. Modbus runs on two-wire half-duplex links very often, and that means you need a way to indicate which device is allowed to talk on the bus at all times. The RTS (flow control) from an RS232 port can be used for this purpose as a software workaround.
In the end, it would be much less of a headache if you just replace your transceiver with one that supports hardware direction control. If you have a serial port with an FTDI engine you should be able to use the TXEN line for this purpose. Sometimes this hardware line is not directly routed and available on a pin but you can reroute it with MProg.
I would like to highlight that you did not mention if you are running your Modbus on RS485. I guess it's fair to assume you are, but if you have only a couple of devices next to each other you might use RS232 (even on TTL levels) and forget about direction control (you would be running full-duplex with three wires: TX, RX and GND).

Fast asynchronous serial communication

I have a controller design application where i get data from 3 USB devices (seen as virtual com port under windows), process it, and then send the action to a 4th USB device (also virtual com port). I need to process that data once i recieve it with a minimum latency.
I decided to use C++ on windows embedded and do the serial communication using the .Net System::IO::Ports and DataReceived event. I tested my code performance using only one USB device where USB device sends one byte to the computer and then the computer sends it back. I measure the time difference and it was totally indeterministic. Sometimes 2 ms and sometime 20 ms.
Note: the process priority is set to be realtime.
Is it a better way to get a deterministic latency where a max delay is guaranteed? may be another API suitable for realtime serial communication on windows embedded?
Thanks in advance
In Windows, you cannot get a deterministic latency delay. You cannot have any guarantee. Because it is not a real-time OS.
If you want some guarantee that are mandatory for your project, you can either deport the real-time part into a smaller device like Arduino (open-source, some users made a Real Time OS with it) or a Beck chip (commercial, delivered with a Real Time miniOS); or you can install a RealTime Linux, which brings in some guaranteed delay.

Using GPIO input instead of TDO/DI on the FTDI 2232H Mini-Module

I’m using the FTDI 2232H Mini Module as a module for a system I’m working on. I’m attempting to read data serially from a device using the FTDI’s GPIOs instead of the TDO/DI pin (MPSSE mode). So, for example, my idea of it would be to perhaps connect a GPIO input to the device’s output, and at each SCLK that the FTDI sends, check whether the GPIO input is high or low. By doing this I would be able to store these highs or lows as 1s or 0s, respectively, into a buffer.
Is it possible to do this, or something similar with the FTDI?
Is there a way to keep count of SCLK pulses or rising/falling edges?
I'm using C++ on a Windows environment.
Thanks
What you are describing is using bit banging which FTDI chips support
including FT232H.
This is the technology I use for my device Nusbio and all the bit banging
computation is written in C#.
Here some source executing SPI bit banging to read data from an EEPROM.
EEPROM/SPI/EEPROM_25AAXXX_BASE.cs
Bit banging is good for chip like the FT232RL or FT231X.
But if you have an FT232H, you can do better.
To answer you question the key is know what is the communication
protocol used by the device your are trying to read data from.
If the protocol is SPI, I2C, JTAG or Serial Port then you should use the native
mode supported by the FT232H.
As mentioned it is called mpsse, Multi-Protocol Synchronous Serial Engine
to simplify synchronous serial protocol (USB to JTAG, I2C, SPI (MASTER) or bit-bang)
design.
If your device support some exoteric protocol with a CLOCK wire which you mentioned, you might have to write your own bit banging.
Is there a way to keep count of SCLK pulses or rising/falling edges?
The Windows PC moslt likely would considered the master so your program is in charge of clocking HIGH and LOW and keeping track of it.
I2C Bit banging Adafruit 16x9 LED Matrix with Nusbio
mpsse SPI with the FT232H and OLED 128x64 display

Getting notification that the serial port is ready to be read from

I have to write a C++ application that reads from the serial port byte by byte. This is an important need as it is receiving messages over radio transmission using modbus and the end of transmission is defined by 3.5 character length duration so I MUST be able to get the message byte by byte. The current system utilises DOS to do this which uses hardware interrupts. We wish to transfer to use Linux as the OS for this software, but we lack expertise in this area. I have tried a number of things to do this - firstly using polling with non-blocking read, using select with very short timeout values, setting the size of the read buffer of the serial port to one byte, and even using a signal handler on SIGIO, but none of these things provide quite what I require. My boss informs me that the DOS application we currently run uses hardware interrupts to get notification when there is something available to read from the serial port and that the hardware is accessible directly. Is there any way that I can get this functionality from a user space Linux application? Could I do this if I wrote a custom driver (despite never having done this before and having close to zero knowledge of how the kernel works) ??. I have heard that Linux is a very popular OS for hardware control and embedded devices so I am guessing that this kind of thing must be possible to do somehow, but I have spent literally weeks on this so far and still have no concrete idea of how best to proceed.
I'm not quite sure how reading byte-by-byte helps you with fractional-character reception, unless it's that there is information encoded in the duration of intervals between characters, so you need to know the timing of when they are received.
At any rate, I do suspect you are going to need to make custom modifications to the serial port kernel driver; that's really not all that bad as a project goes, and you will learn a lot. You will probably also need to change the configuration of the UART "chip" (really just a tiny corner of some larger device) to make it interrupt after only a single byte (ie emulate a 16450) instead of when it's typically 16-byte (emulating at 16550) buffer is partway full. The code of the dos program might actually be a help there. An alternative if the baud rate is not too fast would be to poll the hardware in the kernel or a realtime extension (or if it is really really slow as it might be on an HF radio link, maybe even in userspace)
If I'm right about needing to know the timing of the character reception, another option would be offload the reception to a micro-controller with dual UARTS (or even better, one UART and one USB interface). You could then have the micro watch the serial stream, and output to the PC (either on the other serial port at a much faster baud rate, or on the USB) little packages of data that include one received character and a timestamp - or even have it decode the protocol for you. The nice thing about this is that it would get you operating system independence, and would work on legacy free machines (byte-by-byte access is probably going to fail with an off-the-shelf USB-serial dongle). You can probably even make it out of some cheap eval board, rather than having to manufacture any custom hardware.

Steps to make a LED blink from a C/C++ program?

What are the easiest steps to make a small circuit with an LED flash from a C/C++ program?
I would prefer the least number of dependencies and packages needed.
What port would I connect something into?
Which compiler would I use?
How do I send data to that port?
Do I need to have a micro-processor? If not I don't want to use one for this simple project.
EDIT: Interested in any OS specific solutions.
Here's a tutorial on doing it with a parallel port.
Though I would recommend an Arduino which can be purchased very cheaply and would only involve the following code:
/* Blinking LED
* ------------
*
* turns on and off a light emitting diode(LED) connected to a digital
* pin, in intervals of 2 seconds. Ideally we use pin 13 on the Arduino
* board because it has a resistor attached to it, needing only an LED
*
* Created 1 June 2005
* copyleft 2005 DojoDave <http://www.0j0.org>
* http://arduino.berlios.de
*
* based on an orginal by H. Barragan for the Wiring i/o board
*/
int ledPin = 13; // LED connected to digital pin 13
void setup()
{
pinMode(ledPin, OUTPUT); // sets the digital pin as output
}
void loop()
{
digitalWrite(ledPin, HIGH); // sets the LED on
delay(1000); // waits for a second
digitalWrite(ledPin, LOW); // sets the LED off
delay(1000); // waits for a second
}
http://www.arduino.cc/en/Tutorial/BlinkingLED
Which port? Parallel port is my favorite choice since it outputs +5V (TTL logic level) and is very straightforward to program. Most parallel ports have enough power to drive an LED. It's important to remember that computer ports in general are designed to only output signaling voltages, and not to produce enough current to actually power most devices.
Which compiler? Doesn't matter. This kind of hardware hacking is more fun and easy under Linux, though, so GCC is a good choice.
How do I send data? Depends on the port and the operating system. USB is frightfully complicated for a simple project, so forget it. Serial and parallel ports can be controlled via a variety of different interfaces. My preference is to use the ioctl() system call under Linux to directly control the parallel-port pins. Here's info on how to do that: http://www.linuxfocus.org/common/src/article205/ppdev.html
Do I need a microprocessor? No, you don't need a microprocessor in the external device (obviously your computer has a microprocessor :-P). If you use the parallel or serial ports, you can just use the LED and a resistor or two and the necessary parts to connect the LED directly.
(Also: The Linux Device Drivers book, available for free online, has information on interfacing simple electronic devices to parallel ports and writing kernel drivers for them.)
EDIT: There seems to be massive confusion in this thread about what the OP means by, "Do I need a microprocessor?" Emphatically, the parallel port alone can drive an LED based on the software in the computer. No microprocessor is needed in the device. However, if you want the device to be able to control itself without being connected to the computer, a microprocessor or some other digital logic is required.
If you want to blink an LED without a microprocessor (which implies no C/C++), a simple circuit using a 555 timer IC will do the trick. These are common projects in beginner hobbyist electronics books or kits because they're really simple and you can get the parts at any Radio Shack type of place:
http://www.kpsec.freeuk.com/projects/flashl.htm
http://www.electronics-project-design.com/LED-Flasher-Circuit.html
If you want to do it in software, as Vlion mentions, everything depends on the hardware being used and the design of the circuit that hooks up the LED.
If you want to try and mess around with something on your PC, here's an article on how to blink LEDs that are hooked up to pins on the PC parallel port:
http://www.codeproject.com/KB/cs/csppleds.aspx
You could try to put an LED and a 300 Ohm resistor on the serial port transmit (pin 3) to Ground (pin 5). Then send data to turn it on.
The serial port can probably only source 10mA.
Good luck.
for quick and dirty operations, you have 2 easy options: serial or parallel port.
The serial port is easier, but is limited in the number of LEDs.
To connect the LEDs, you need a shell connector (DB25/DB9) of the correct sex, the LED's and a resistor. You would have to look up the value for your resistor yourself.
The serial port has control-flow signals which are under programmer control. It's a simple matter of outputting the correct bits to the MCR register (after opening the serial port).
The parallel port is a little bit harder, in that there is a bit more handshaking to do, but is generally the same principle of writing to a register.
You may have to fight your OS to gain control of the port.
Using the Tx line is somewhat complex, as the signal coming out is the serial bitstream of the data written to the transmit register. I would stick to the CTS and DSR signals.
For quick-and-dirty debugging, I have just written to the registers and watched the modem lights.
It also depends on the OS. On Linux, you could wire an LED directly to the parallel port (with an appropriate current-limiting resistor, of course) and simply use the C function "outb()" to turn it on and off.
On Windows, it's a lot more complicated because the OS doesn't let user applications talk to ports directly.
The easiest port to do this on would be serial or parallel. Always remember to put a resistor in series with the LED or you will burn it out.