serial connection to Nano vs Mega: differences?

dear forum users,
I wrote a small GUI in AutoIt using a user supplied serial communication function that exploits kernel32.dll
My GUI simply sends a short string of text to Arduino via the serial port in order to alter its behavior (which signals Arduino sends to some electronics). The same string I can alternatively send through the Arduino built-in serial monitor.
When I use it with my Mega 2560, everything works fine and the result of sending the string is successful both from the Arduino serial monitor and from the AutoIt GUI.
When I use it with my Nano v3.0 (with the same Arduino sketch loaded), everything works nicely as expected with the Arduino serial monitor, but instead it does not work at all with the same AutoIt script. It probably produces some kind of error (which I cannot learn anything about) and it does not receive the string.
Is serial communication to the Nano any different? maybe Arduino serial monitor takes care of the difference and other sw does not? all my Nano drivers seem to be installed correctly (2014 versions).
Could it be that kernel32.dll does not talk to the Nano but it talks to the Mega? shouldn't the Nano FDI driver take care of this silently?

I though I had a similar problem as described in http://forum.arduino.cc/index.php?topic=114945.0, but it does not look that the solution there works for me.

I am not an expert in serial communication or drivers, so I do not really know what to do.
Thank you to whomever could help,

Hi giampa,

the first thing to notice is the "thing" that does the serial-communication towards the PC and which determines which driver is used.

(1) Arduinio Mega : depending on your board revision its done by an ATmega16U2 or ATmega8U2. Both USB transceiver chips would result in the usage of the default USB CDC driver from Windows. If you take a look at the device manager and do a right click on the "virtual COM port" of your Mega you will might see an Arduino driver at first sight (dialog) but if you click under "details -> driver details" you will see that "usbser.sys" is used under the hood which is from Microsoft.

(2) Arduino Nano : uses a FTDI USB-to-TTL Serial chip as I can see from the product page (I don't have one at my hands), which will result in the usage of the FTDI driver.
If you might use a quite new Windows 10 installation its a very good idea to go to the "device manager" right click on the "virtual COM port" of you Nano, change to the tab "Driver" and click the button "update driver ..." and choose the option "automatically search for updated driver" (maybe things are labeled different as I got no English Windows 10 installation running and these are just "on the fly" translations of mine ... my guesses) ... in the end : let Windows lookup on Microsoft Servers if there is a new driver version.
In the "early days" of Windows 10 this was the solution for the problems I got with an old Duemilanove which uses a FTDI chip as well - I went to the FTDI Webiste and installed the newest driver with Version 2.12.06 ... but maybe this is already deployed to Microsofts Servers so you might have got it via Windows Update already or you could pick it up with procedure described above.

The second & typical problem is "flow control" which is different if a "UART / TTL to USB chip" (like the FTDI one) or a "real USB Transceiver chip" is in the game ... this results not only in different driver from the specific vendor (or the default driver from Microsoft), but in a totally different driver stack (its like another genre of drivers) - and this has impact on the "flow control" : which options are valid (or will take effect) and which have to be set.

I got experince using C# and Python with these 2 different "driver stacks" (old style RS-232 and new styls USB CDC) and as I discovered 2 flow-control bits are the "game changers" : DTR & RTS (see RS-232 - Wikipedia" for the details).

As I looked at your linked website I saw two corresponding helper functions : SetOnDTR (Data Terminal Ready) and SetOnRTS (Request to Send) - I would try these.

For Example : using a Duemilanove (FTDI chip based) I never cared about these flags in the old .NET Desktop framework, but using an Arduino Leonardo or Micro (which use the ATmega32U4 which have an embedded USB transceiver) with the new Windows 10 UWP .NET APIs I had to set DTR = true and RTS = true to be able to talk to these boards.

cheers
buildiy

If you have a Nano clone with the CH340 chip you won't have the FTDI chip.

Thank you all!
Dear Buildiy,
thank you very very much for your reply, generously well-written. Some of it is a bit over my understanding :frowning: but I guess it kinda worked, or set me in the right direction.
Upgrading the drivers made no difference.
What apparently made some difference is fiddling with the communication command in the AutoIt serial communication function (CommAPI), that I did as you suggested it might be 'flow control'.
I admit I am not sure what is the difference from the inner working of the more general command "OpenPort" I am using now and the COM-specific one "OpenCOMPort" I was using before, but it now correctly opens the port (I guess it was not doing that before) and so I can send a string to it.
Thank you again!