2

Im writing application that communicate (via serial port) with electronic device which i designed myself.

When my PC application starts - it opens available COM ports one by one and it sends some string ("What are you?" for example).

My device is programmed, to reply to that "magic question" with own ID (for example: "I am evil device for supervising employees").

When my PC software receive that "magic reply" it starts working normally and its not searching other ports anymore.

Of course im not using stupid questions in data transmission, its just example.

Question is - can i send strings like on all (not busy) ports, to discover my device?

If I can - how that "question" string should look? Are there any normalized standards?

This is not first project like this on my desk, but now im developing solution for little industry and i need to pay more attention what my application is doing, because there may be other devices connected to COM ports and I do not know how they can react.

Im sorry, if i made some language mistakes, english is my third language.

Thanks in advance for replies.

Kamil
  • 13,363
  • 24
  • 88
  • 183

2 Answers2

6

After Alvin Wong confirmed my concerns I thought about it again and redesigned my device discovery functionality, because I don't want to abandon that idea.

I will send unique-complicated-ID every 1-5 seconds from device.

When my PC starts - it will try to open sequentially all available ports and will listen for that ID for few seconds.

If application receive that ID - it will be confirmation, that port number/name is correct and I my connection is established.

Kamil
  • 13,363
  • 24
  • 88
  • 183
3

No, you wouldn't want to do that.

When you are using COM serial port, you have no idea what is plugged into the port. It could be nothing, your device, a modem, a mouse (though I believe nobody uses this anymore...) or whatever you can't even imagine.

Imagine if it is connected to another computer (probably a Linux/router), sending things may lead to execution of "that command", thus creating unexpected effects (though your program may not notice). Or if it is some badly-programmed device, it may trigger a bug in the firmware, thus failing the device and making it malfunction.

In short, in the worst case, you can cause a catastrophic event.

Serial (RS232 or UART I assume) communications don't have a designated transfer protocol (in contrast to USB which has one) to identify a device, so it isn't fail-safe. The user must make sure he selected the correct port. This is probably one of the reasons why hardware manufacturers choose USB, and one of the reasons why USB is so popular, even to computer idiots.

Alvin Wong
  • 12,210
  • 5
  • 51
  • 77
  • So have confirmed my concerns. Thank you. And by the way - i know USB is a lot better, but sometimes its too complicated for simple pc->device communication, even when im using simplified USB solutions from Atmel or Microchip - it takes too much time to learn how to deal with that. – Kamil Oct 01 '12 at 16:43
  • If you limited to serial port then it's pretty much the same whether you do discovery or leaving for the users to choose from the list which looks to them like: COMM1, COMM2 ... Chance to screw something up is the same. – ruruskyi Nov 06 '14 at 17:36