Jump to content
Sign in to follow this  
joseLB

receiving binary data thru a serial port

Recommended Posts

joseLB

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 by joseLB

Share this post


Link to post
Share on other sites
joseLB

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

Share this post


Link to post
Share on other sites
martin

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.


Serial port communications UDF Includes functions for binary transmission and reception.printing UDF Useful for graphs, forms, labels, reports etc.Add User Call Tips to SciTE for functions in UDFs not included with AutoIt and for your own scripts.Functions with parameters in OnEvent mode and for Hot Keys One function replaces GuiSetOnEvent, GuiCtrlSetOnEvent and HotKeySet.UDF IsConnected2 for notification of status of connected state of many urls or IPs, without slowing the script.

Share this post


Link to post
Share on other sites
joseLB

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!

Share this post


Link to post
Share on other sites
Kovacic

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.


C0d3 is P0etry( ͡° ͜ʖ ͡°)

Share this post


Link to post
Share on other sites
martin

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.)

  • Like 1

Serial port communications UDF Includes functions for binary transmission and reception.printing UDF Useful for graphs, forms, labels, reports etc.Add User Call Tips to SciTE for functions in UDFs not included with AutoIt and for your own scripts.Functions with parameters in OnEvent mode and for Hot Keys One function replaces GuiSetOnEvent, GuiCtrlSetOnEvent and HotKeySet.UDF IsConnected2 for notification of status of connected state of many urls or IPs, without slowing the script.

Share this post


Link to post
Share on other sites
joseLB

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 by joseLB

Share this post


Link to post
Share on other sites
martin

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.


Serial port communications UDF Includes functions for binary transmission and reception.printing UDF Useful for graphs, forms, labels, reports etc.Add User Call Tips to SciTE for functions in UDFs not included with AutoIt and for your own scripts.Functions with parameters in OnEvent mode and for Hot Keys One function replaces GuiSetOnEvent, GuiCtrlSetOnEvent and HotKeySet.UDF IsConnected2 for notification of status of connected state of many urls or IPs, without slowing the script.

Share this post


Link to post
Share on other sites
joseLB

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... :ermm:

Thanks

Jose

Edited by joseLB

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Similar Content

    • Stacker
      By Stacker
      Hi i need help for communication from/to PC to microchip PIC.
      i need to send "ADC1xxx" (where xxx is delimiter)  to microcontroller via serial port and wait for response (with timeout)
      i need to send other "commands" and waiting always a response from microcontroller.
       
      can anyone help me
      Yhanks so much
    • martin
      By martin
      Although serial ports are disappearing, they can still be useful.
      Here is a COMMs UDF. It provides an easy way to use serial ports without the restrictions and problems some methods have. USB to serial is ok, binary data is ok.

      This UDF requires my comMG.dll which can be in either the script folder or the Windows folder by default, or in the path specified using the function _CommSetDllPath.

      Note the following shortcomings:

      the dll link below is 32 bit so it will not work with a 64 bit apps, but there is a 64 bit version in my post around 25th March 2018 for people to try.
      The strings and character functions are all AnsiChar.


      Functions in the UDF are

      _CommVersion
      _CommListPorts
      _CommSetPort
      _CommPortConnection
      _CommClearOutputBuffer
      _CommClearInputBuffer
      _CommGetInputcount
      _CommGetOutputcount
      _CommSendString
      _CommGetString
      _CommGetLine
      _CommReadByte
      _CommReadChar
      _CommSendByte
      _CommSendBreak; not tested!!!!!!!!!!
      _CommCloseport
      _CommSwitch
      _CommReadByteArray
      _CommSendByteArray
      _CommsetTimeouts
      _CommSetXonXoffProperties
      _CommSetRTS (NB these will not work if Hardware handshaking is selected because
      _CommSetDTR then these lines are controlled by the data being sent.)
      _CommSetDllPath
      _CommGetLineStates
      --------------------------------------------------------------------------------------------------------------------------------
      Go to Download Page For Commgv2
      Download includes the dll and udf.
      Most recent changes
      28th March 2014 - dll V2.83
      Correct error setting 6 data bits as 7.
      11th March 2014 dll V2.82
      Allow data bits of 4 to 8 instead of only 7 and 8.
      19th August 2013
      dll v2.81 removes some unwanted eroor message popups. Might not remove popups for some Windows versions.
      27th September 2012
      Correct error closing port. New version of UDF if V2.90, new dll is commg.dll V2.79. Thanks to tfabris.
      18th January 2012
      Corrected typo in UDF V 2.87, and uploaded as V2.88
      Increased max baud allowed by the dll from 200000 to 256000. New version now V2.78
      17th January 2012
      Modified thesleep addition to _CommGetLine so that reading data is not slowed down.

      14th January 2012
      Corrected _CommReadByte in UDF.
      Added sleep(20) to while loop in _CommGetLine to reduce CPU usage
      20th December 2011
      UDF version 2.86. - Changed function GetByte so it returned the error string given by the dll.
      Dll version 2.77 - removed an unwanted erro message dialogue from GetByte function. (Thanks funkey)

      4th December 2011
      New dll and example versions. Dll function SetPort corrected because it was not using the parameters passed for DTR and RTS.
      The example was setting flow control incorrectly: the settings for hardware handshaking and XON./XOFF were reversed.

      25th August 2011 corrected function _CommClosePort.

       
      Example corrected for setting parity and flow 22nd December 2013  (thanks to MichaelXMike)



      mgrefcommg CommgExample.au3
    • Corleone221
      By Corleone221
       
      Hello All,
       
      How can I load  actual connect  Com Ports to combobox?
       
      Thanks.
       
      for example  this 3....(6,7,8)

       
       
×