receiving binary data thru a serial port

[joseLB 2]

This topic is a complement of  therealhanuta´s >CommAPI - Serial and parallel communication with Windows API

I think these routines are great, as they are simple to use, and use windows API with NO DLL´s.

It is about tips in receiving binary data thru a serial port, including value 0 (=end of string**). I hope it can help someone..

To know about the UDF to read/write serial port, please refer to the above link, with focus at post #3 and over

First, what is a binary stream? As an example, a microcontroler (PIC) getting data thru ADC and sending the 2 adquired bytes straight thru serial, without any treatment.

Now supose the message has: 1 letter(A-Z)  + 4 ADC values + 3 counters of anything (each one byte). Your message will arrive with 1 + 4 x 2 + 3 = 12 bytes (or as AU3 sees it,  a "string" with 12 "chars").

1. $sResult = _CommAPI_ReceiveData($hFile) will have at $sResult a "string" with 12 "chars" **
2. besides the first one, all other chars have byte values. On them can exist even binary value 0. So, it´s vital that 0 be not interpreted as end of string by receiver (PC)
3. now let´s separate the 1 + 4 + 3 = 8 fields

   field1= StringMid($sResult,1,1)  ;this is just a characte rbetwen A-Z
   field2= ASC(StringMid($sResult,2,1))  ;LSB of the ADC value. First byte = LSBb, 2nd. byte = MSB
   field2= field2 +  ASC(StringMid($sResult,3,1))*256  ;MSB of ADC => now field2 has LSB + MSB (betwen 0-65535)
   ;field3..5 are similar to field 2, just increase  by one the start position in stringMid
   field6= ASC(StringMid($sResult,10,1)) ;now field6 a "number" betwen 0-255;
   ;field7-8 are similar to field 6, just increase by one the start position in stringMid

   ** - be carefull, as probably $sResult = _CommAPI_ReceiveData($hFile) will get just the chars avaiable at the moment of call, so a kind of test/loop will be necessary to get all them, something like

$sResult=""
DO
     $sResult = $sResult  &  _CommAPI_ReceiveData($hFile)
UNTIL stringLentgth($sResult) >= 12

Jose

** thanks Martin into explaining about hex (0) to be interpreted as end-of-string and not xoff.

Edited November 5, 2013 by joseLB

[joseLB 2]

This very very simple and TESTED example to show basic usage of CommAPI or to test your serial connection

(CommAPI works like a charm)
It needs a terminal emulator, like putty, on your pc (with a loopback cable= pins 2<->3)
   or a emulator in another PC with cross cable ( pins 2 <->3 and 3<->2)
It asks at terminal emulator to type something and shows what was typed 3 seconds later.
Typing ... (3 dots) terminate the program.
Tested with a USB - serial converter (prolific) at 9600 cross cabled to another PC with putty terminal emulator

Jose

#include "CommInterface.au3"

Global Const $iPort = 6             ;============== > CHANGE HERE  TO THE PORT YOU ARE USING ==================
Global Const $iBaud = 9600
Global Const $iParity = 0
Global Const $iByteSize = 8
Global Const $iStopBits = 0


$x=_CommAPI_GetCOMPorts()                   ;get a string with all your serial ports separated with @CRLF
MsgBox(4096,"list of Com Ports",$x)             ;show avaiable ports
$loop=1
$hFile = _CommAPI_OpenCOMPort($iPort, $iBaud, $iParity, $iByteSize, $iStopBits)
$x= _CommAPI_ClearCommError($hFile)

Do
    _CommAPI_TransmitData($hFile, @crlf&"type anything (... = end):")  ;send prompt
    sleep (3000)                                                           ;user have  up to 3 seconds to type something
    $digitado= _CommAPI_ReceiveData($hFile)            ;get typed string
    _CommAPI_TransmitData($hFile, @crlf&"-->" & $digitado)  ;echoes to serial what was typed above
    ToolTip($loop & $digitado)              ;shows in tooltip typed chars, preceded by number of iterations
    $loop=$loop+1
Until $digitado= "..."                      ;if user types ... (3 dots) program finishes
_CommAPI_CLosePort($hFile)
Exit

[martin 90]

Just a note joseLB. Hex 0 is not normally interpreted as XOFF because XOFF is usually Hex 13. The main problem with sending or receiving binary data is that Hex0 is interpreted as the end of a string and following bytes are ignored.

I hope you and therealhanuta can keep going and produce a full set of UDF functions for serial comms using direct calls to the API, it seems to have been a long time coming.

[joseLB 2]

Just a note joseLB. Hex 0 is not normally interpreted as XOFF because XOFF is usually Hex 13. The main problem with sending or receiving binary data is that Hex0 is interpreted as the end of a string and following bytes are ignored.

I hope you and therealhanuta can keep going and produce a full set of UDF functions for serial comms using direct calls to the API, it seems to have been a long time coming.

Thanks Martin, I will corrected the first post!

[Kovacic 14]

That would be great if this becomes a UDF! I have an arduino sitting around I'm just waiting to do more awesome things with.

Arduino uses C im pretty sure.. if I could upload a simple sketch to the arduino and let autoit handle the rest, my life would have new meaning.

[martin 90]

Kovacic,

people are already using AutoIt to control Arduino's. You can use my udf for serial comms (see my signature) The point of this thread is to produce an AutoIt udf which doesn't use a dll like mine does, but if you aren't worried about the dll then there is no need to wait. (You don't need to know anything about using a dll to use my udf by the way.)

[joseLB 2]

Kovacic,

people are already using AutoIt to control Arduino's. You can use my udf for serial comms (see my signature) The point of this thread is to produce an AutoIt udf which doesn't use a dll like mine does, but if you aren't worried about the dll then there is no need to wait. (You don't need to know anything about using a dll to use my udf by the way.)

Kovacic

Martin is right. His UDF is the "standard" UDF for serial communications, with lots of functions. The only drawback is the DLL, that can be a problem for some uses. For example, I have an application where I can distribute just one .exe, and can´t install anything.

On this "new" method up to now I found 1 problem, described at post #10 on it´s tread. I still don´t know if it is a fact or not, but if yes, it become almost unusable.

Martin

Do you believe that your DLL could be embebed on autoit ? If yes, what you thing about the idea?

Jose

Edited November 7, 2013 by joseLB

[martin 90]

joseLB,

you could probably use memorydll by ward. I would like to try but I won't be spending the time on it at the moment.

Out of interest, although I understand that a pure AutoIt solution is better, what in your opinion are the problems with using a dll? The fact that it means including another executable doesn't seem like a problem to me.  The one time I have used AutoIt for a commercial application there were about 6 compiled AutoIt scripts as well as my print dll, though not the comms dll. I sold a few of those apps and in one company their virus scanner started deleting the dll. I don't know why.

[joseLB 2]

joseLB,

you could probably use memorydll by ward. I would like to try but I won't be spending the time on it at the moment.

Out of interest, although I understand that a pure AutoIt solution is better, what in your opinion are the problems with using a dll? The fact that it means including another executable doesn't seem like a problem to me.  The one time I have used AutoIt for a commercial application there were about 6 compiled AutoIt scripts as well as my print dll, though not the comms dll. I sold a few of those apps and in one company their virus scanner started deleting the dll. I don't know why.

Martin,

maybe some "purism", but really, if we do not have to install the dll and it can stay at the same directory than application (as yours), I see no big problem.

About more than one channel on yours: While channel 1 is the selected one, channel 2 "accumulates" the received bytes or they are dscarded?

Please, take a look at your thread, where I repeat this question and did some others...

Thanks

Jose

Edited November 13, 2013 by joseLB

[joseLB 2]

Just an information: I moved to Martin´s Serial Port /COM Port UDF

'?do=embed' frameborder='0' data-embedContent>>