Testing serial communication programming

I have made a user interface program (with buttons, trackbars, etc.) for Windows (using .NET C#) where one talks to an embedded device (an ARM uC) through its RS232 port and I use a RS232-USB converter to use with my laptop.

When I test everything works fine. But if I send it to a customer I am afraid their ports, CPU speeds, etc. could be different. And I don't know would that affect the data transmission

Can we be sure about the physical layer with different computers would behave same way?

Does anybody have any experience with testing serial port for production SW? Or what could be done to test the protocol for such scenario. I hesitated to ask this here because it involves electronic communication and programming topics.

• I don‘t think that one could give you an answer to this type of question. RS232 is a standardized protocol so it should work as long the involved components follow the standard. – Stefan Wyss Mar 23 at 9:16
• I have made evaluation kits for Maxim Integrated for the past 30 years, back when we could expect customer PCs to have RS232 ports. Now everyone has USB and nobody has native RS232, and we have to worry about the customer finding the right device drivers. USB-CDC "COM" port numbers can be found by using mode | findstr "COM[0-9]*" or by using the applicable windows API calls. However it seems every USB-serial bridge introduces some timing delays, on the order of 10ms(!!!) between sending and receiving a burst of characters. Timing hazards are worse if supporting random customer hardware. – MarkU Mar 23 at 9:32
• Testing on the developer's computer doesn't cover everything. Sometimes the software depends on files that are part of the development system toolkit, and so it works on the developer's system but not of the customer's system. When I was at HP we had a room full of 50+ target test computers (PCs and laptops) of different brands, in different configurations, for testing the deployed software. But it's hard to know how much is enough, there's no bounds to what a customer might use. Probably should test on at least one non-developer computer with the minimal configuration you'd expect to support. – MarkU Mar 23 at 9:40
• Which USB converter you are using, which embedded device it is, and is your customer using a similar USB converter? Do they use RS232 levels or TTL levels? @StefanWyss RS232 is not a protocol, it's an interface standard that specifically does not define any protocol. – Justme Mar 23 at 9:57
• @MarkU Very good point. I use converter and myself noticed when I write and read port I need to put at least 50ms delay to be able to receive data. I think to overcome delay issues I need to embed the USB converter within my setup so they will just use the same converter. This eliminates the possible different delay problem. (?) – cm64 Mar 23 at 10:12

In order for your customer to use your .net application you have to:

1. Make sure the correct version of the .net framework is installed.

For this, you might want to ship your application by an installer like InstallShields.

That installer will check all the dependancies that your application has and will prompt the user for installing the missing ones.

1. Make sure the PC has an available serial port.

It may sound silly but sometimes the end-user doesn't even know what a comm port is.

On some PC's, for some reasons, comm port 1 is mapped onto comm port 2. Maybe because they installed a third party hardware PCI card that let the user remap comm port names.

You might want to modify your code in order to let the user chose the comm port he wants.

Once you set the baud rate (example: BAUDRATE = 9600) the CPU speeds is nothing you should concern about: the OS will take care of anything to make your comm port run at 9600 baud per second.

• Thanks for the answer. However when the user plugs the USB of the HW it is Windows OS that assigns the port number. I guess the user should know which port is assigned by looking to Device Manger and then from UI should select that port. Correct? – cm64 Mar 23 at 10:51
• I plan to sent it along with USB this converter aten.com/eu/en/products/usb-&-thunderbolt/usb-converters/… Do you think InstallShields can install this driver for the user? – cm64 Mar 23 at 11:06
• InstallShields or similar softwares will prompt for missing Microsoft's software or for the software that you require. It won't look automatically for the USB drivers of your cable. If the user is skilled than he/she can look up Device Manager than you are all set. I suggest you not to hard code in your software, for example, "COM1" but list a set of COM names. Alternatively you might probe your hardware and automatically find the right comm port without the user intervention. – Enrico Migliore Mar 23 at 11:49
• Program detect all the available ports and list them for the user that's fine, I can also set the baudrate; but automatically detecting the device's port by program I never tried. The program needs to know something about that device's port I guess. – cm64 Mar 23 at 11:55

Are you interested in testing the hardware or testing your software product? This is a hardware site.

As pointed out in comments RS232 is not a protocol standard it is a pinout/voltage level standard. The protocol does not really have a name UART protocol is probably the closest, but there are variations on a theme there.

But this brings up the question does your product rely on RS232 levels or "TTL" levels (as in 5V, or 3.3V or 1.8V or other). RS232C has a defined range for what a "1" and what a "0" is. So for example some random uart to RS232C product may land anywhere within that, if you are testing your hardware product you probably want to test those limits the low end to see if the product functions and the high end (+/- 15V) does not damage the product. Those would be the minimum tests on voltage levels, you can do more there.

While you may set the baud rate for a specific speed 9600 for example, the reality is you are rarely at that speed. Some hardware will use the proper crystal/reference, within a tolerance of course, to generate these speeds, but often, specifically on the uC side for sure, you are not doing that. On the ideal reference clock side you are creating an approximation, say 8MHz/9600 = 833.333... so 8000000/833 = 9603 which may not seem like much but often these are often divided down say 8x and you want to run your mcu at the lowest clock you can to save power. 2000000/(16*9600) = 13.0208 which gives 9615. 16x oversampling and it gets worse.

Bottom line is sometimes the variation is small and sometimes not as small. This is assuming a perfect clock but if the mcu is using an internal R/C oscillator, then that clock has more error than a crystal reference and it can/will drift with temperature. So your two sides are not communicating at the same speed. The 8x or 16x oversampling helps with finding the middle of a bit cell, but one has to assume it is reset on the edge of the start bit so you have to make it through 10 give or take bit cells with the worst error both side has chosen. You seem to be asking about a software product and not necessarily hardware, but you asked if the physical layer works in the same way. NO absolutely not, different hardware and different computers can definitely affect the results/success.

Test your software for breaks. In uart terms this is a long period of zeros, last time I messed with windows, it very poorly handled breaks at the driver level, tools like hyperterm, etc you have to restart, plus any software I wrote, one would hope they would have fixed this buy now but uart is so low priority and even then com ports were going away, so why would they bother to fix it? See how your software handles this. Same goes for framing errors.

Your protocol that sits on top of the uart serial protocol needs to be able to handle various framing errors in some way. One good way is to packetize the communication, a start pattern, length perhaps, and some form of checksum or CRC, if the packet does not pass this self checking then discard it. Then the next layer of protocol above that have a solution for re-sending. In any case you should test various forms of error injection.

Being a high level language environment on windows there are many layers below your code and many different versions of windows and various update levels along with the hardware windows runs on in addition to your serial/uart solution. You cant possibly own/test all combinations, but you should test more than one. "Works on my machine" will only get you so far with a product.

Do you know the minimum requirements, if you go with a clean operating system install does your software work? What is the minimum number of things a user would need to install on a clean system, to get it to work. Are there minimum versions of these software items for your product to work? How much testing have you done to prove this? Could you handle tech support questions related to these issues?

Who controls this target arm based product? And it's software? You? Does this product work as is? Does it require the user to load/configure something? Does this product have firmware updates? Does your product work with the various updates? From either a tech support perspective or a product just working perspective do you have an array of these as test fixtures with various settings and firmware versions?

Hopefully you can get the idea of what you need to look at and think about. Can the hardware affect the success of your product, absolutely, both the computer and the serial interface options. And being windows, .net, C#, and uart/serial/RS232 that is a wide range of stuff that can go wrong and needs testing and tech support, and it is not possible to test all the combinations, but you had better test some of the combinations at a minimum.