I'd like your views on the feasibility of realising my idea for a project. In a nutshell, I would like to have a gadget that I can send rs232 commands to and have it indicate that those commands have been received. It would also indicate what the command was. What I mean is, could I programme this hypothetical gadget to emulate a given piece of equipment, say an LCD monitor or an HDMI matrix switcher. Anything that is controllable via rs232 really.
Yes that's feasible. Years ago I used a home made PIC based devices to sit on a serial line between a piece of closed source software and a Sony tape deck. It captured and saved the serial data in both directions so I could later look at the data and use a PC to make it more human readable for debugging. From this a device was made to sit in the serial stream to correct problems the software had with some VT tapes with discontinuous timecode.
Using Arduino this would be easier to do now and if you know the command sequences being sent they could also be decoded on the Arduino.
SoftwareSerial (on any Arduino) might be enough for simple low baud-rate commands.
Read/write sample sketches can be found in the examples of the IDE.
Leo..
I understand the rs232 / ttl level conversion requirement, but why would I need more than one serial input? At this stage, I can only forsee this gadget emulating one device, but you've given me food for thought.....and I've probably just answered my own question.
Firstly, though, I have to work out how to recognise an incoming string and produce a reaction. Like maybe send some text to an lcd display.
Thud:
I understand the rs232 / ttl level conversion requirement, but why would I need more than one serial input?
The only TX/RX pins on e.g. an Uno are already used by the USB<>Serial chip.
Piggybacking a second device on the same pins could have unexpected results.
See post#4 for a software solution.
Leo..
Two Serial ports are required for both RS-232 lines, and one more for communication with the user (PC...). It's not a good idea to use a board with only one Serial port for such a project.
Now I get why the micro is in the list, as it has only one TX/RX pair, but no integrated USB.
Still, a second Serial port or using software serial would allow you to easily program the device and get debug output to the Serial console.
Thud:
Thanks Riva.
I need to study how to read serial strings then.
Where's the best place to start, in your opinion.
Decide what device you need to emulate and then grab any datasheets for that device that cover the serial protocol used. From this you can hopefully work out what commands your going to receive, how to act on the command and if/what reply you need to send back.
You're totally right. But I'm stuck on the first hurdle. I have all the manufacturer's data for devices I wish to emulate, so I know what I'm likely to receive (baud rate , actual message in hex and/or ascii).
This data is output from the Controller: (a well known brand of proprietary control hardware)
6B 61 20 30 30 20 30 31 0D (HEX) or ka 00 01 (ASCII)
and what it means is, "Switch On Display" (on an LG monitor)
I don't really need to receive any data back from the emulator, just have it react. Like print a line of text to an lcd display or even just light up an led.
Using this sketch I can read the controller's output.
#include <SoftwareSerial.h>
SoftwareSerial mySerial(10, 11); // RX, TX
void setup() {
// Open serial communications and wait for port to open:
Serial.begin(9600);
while (!Serial) {
; // wait for serial port to connect. Needed for native USB port only
}
Serial.println("OK");
// set the data rate for the SoftwareSerial port
mySerial.begin(9600);
Serial.println("Ready");
}
void loop() { // run over and over
if (mySerial.available()) {
Serial.write(mySerial.read());
}
}
After that I'm kinda stumped because I've tried various other ideas, like the serialEvent example but with no success, yet.
Is this maybe a post for a different forum, now that with this forum's help, I know that the project is indeed feasible.
How you tackle this depends on how many commands your expecting to react to and the syntax they use.
In the example you supplied you could do a simple string comparison for the entire command (ka 00 01) and react on that but if you have lots of commands with varying parameters then this will not be flexible and maybe consume a lot of Arduino resources.
You could also break the commands down so you start with the base command (ka) and it's two parameters (0x00 0x01) and then parse these. This will require more programming but should consume less Arduino resources in the long run.
To properly emulate a device you should also determine if/what the response to a particular command is and send it back (in this case probably something like 'a 01 OK01x'). This should keep the sender device happy and maybe unlock more options.
But I'm stuck on the first hurdle. I have all the manufacturer's data for devices I wish to emulate, so I know what I'm likely to receive (baud rate , actual message in hex and/or ascii).