Help on API

[Roger]

Hello All,

Since this is my first post permit me to introdce myself and my current project.

I am trying to write a programme which will connect to a serial port, and put text from the port to screen and from the keyboard to port, echoed to the screen; basically similar to a simple terminal emulator. When it works I will need to parse the incoming data, analyse and store it and display the data graphically. This I have done using DOS for one end of the serial link and as an embedded programme running on 80188 based processors at the other end. Sofar no problem.

Now comes the snag: due to a lightning strike, the machine rumming DOS has had to be replaced and the replacement is using XP.....

I'm having difficulty finding out which API calls to use for a particular task - once I have the name of one I can look it up in the Platform SDK - but what I need is a list of them sorted by subject/function rather than alphabeticaly so that I can find wich ones to look up.

I know that the API calls produce messages which seem to be of the form WM_??????? and I even have a list of sorts which gives the hex values of each message but nowwhere can I find details of which API call produces which message, which I can safely ignore and leave to default processing and which I have to write code for.

I'm also having trouble in that while I can find tutorials and examples of code which show how simple bits of code work, none of them help me with the overall structure of a programme which has to do real things. The examples seem to consist of initialisation code (usually) and a message loop with lots of seperate message handlers. None of them explain where to put all the bits of programme which arn't actually to do with the API and how to tie them all together.

Can anyone sugest a tutorial or other resorces which will help me with these aspects of Windows API programming in assember.

It seems one must know how to run very fast just to have the skills needed to learn how to walk

Regards Roger

[donkey]

Hi Roger,

The messages (WM_xxx and the other control specific ones) are all designed to allow you to pass them to the DefWindowProc except WM_CLOSE to which you must respond in your main window otherwise you will not be able to terminate your application. WM_CLOSE in child windows is not important.

The contents tab of the SDK is sorted by heading, subsection and category. In your case you are probably interested in the System Services heading, Device IO subsection, communications category. All of the functions that relate to communications can be found there along with articles and example code (in C)

Edgar

[Mark Jones]

Hello Roger and welcome to the forum. :)

You didn't say, are you coding the app in C or MASM32 or another assembler? Interesting project.

Here is a link into the Workshop where MichaelW has made MASM32-compatible include libraries for WinIO, a DLL used to simplify access to parallel and serial ports in XP and the other flavors of Windows. Why reinvent the wheel if you don't have to?  :toothy    http://www.masmforum.com/simple/index.php?topic=3894.0

All the details of the DLL itself can be found at WinIO's website: http://www.internals.com/

[GregL]

Roger,

Hello

MSDN Win32 API Functions by Category

Serial Port programming with the Windows API is not an easy task, but it can be done. There is much more example code in C than in MASM. WinIO is a Device Driver that allows direct access to the serial port, it's not the "approved" method for Windows NT/2000/XP, but it works. I don't want to discourage you, but I started a serial communications program in MASM using the Windows API and soon realized what a daunting task it would be. I decided to use PowerBASIC which has the serial communications functionality built-in. I took the easy path. I guess it depends on how much you want to do it in MASM and how much time you have. If you do choose to write it in MASM you will surely learn a great deal. :bg

[ChrisLeslie]

My comments are not designed to put you off trying to use Windows API's, but a few years ago I had written code to do a simular thing - interface geophysical equipment through the serial port and capture/process serial data in real time. My program was written initially in PowerBasic for DOS but I had also written a version in MASM611, and later in PBCC. The programs could easily run on a WIN98 OS in a "DOS box" with no problems. I can't see any reason why they would not have worked using a WINXP command window as it emulated DOS. So why don't you just try your original appication running from a command window and see how it goes?

Chris

[Mark Jones]

As I understand it, XP especially doesn't allow applications to directly access ports, and direct access is required to communicate with hard-wired devices because of timing issues (non real-time access causes data desyncronization.) WinIO solves this problem by providing IO routines at Ring Zero privlege level (or REALTIME_PRIORITY.) The WinIO team says it better than I can:  http://www.internals.com/faq_main.htm

[Roger]

Thank You all for your replies and I shall be working through your ideas.

You didn't say, are you coding the app in C or MASM32 or another assembler? Interesting project.

I will almost certainly be using GoAsm. The DOS version was programmed using A86 which I found to be more to my liking than MASM.
The 80188s run Forth which is my prefered higher level language.

I can't see any reason why they would not have worked using a WINXP command window as it emulated DOS. So why don't you just try your original appication running from a command window and see how it goes?

I did and it didn't know where to crash first. I directly programmed the UARTs using code similar to the 80188 code, I directly progammed the VGA screen graphics for speed since it ran originaly on an XT clone and if that dosen't stop it I haven't yet found a way of making Windows XP recognise a mono screen. Win95 dosent either but at least it lets the "DOS box" get on with it.

As I understand it, XP especially doesn't allow applications to directly access ports, and direct access is required to communicate with hard-wired devices because of timing issues (non real-time access causes data desyncronization.)

Absolutely. This is why I like to programme at the chip level using the simplest tools for the purpose. What I don't know - yet - is whether a32bit  2.8GHz machine running through the "fog" of windows will be able to keep up with a simple 8 bit 10MHz processor runing - dare I say it - un-bloated code

Regards, Roger

[ChrisLeslie]

Quote from: Mark Jones on Today at 09:37:30 AM

As I understand it, XP especially doesn't allow applications to directly access ports, and direct access is required to communicate with hard-wired devices because of timing issues (non real-time access causes data desyncronization.)


Absolutely. This is why I like to programme at the chip level using the simplest tools for the purpose. What I don't know - yet - is whether a32bit  2.8GHz machine running through the "fog" of windows will be able to keep up with a simple 8 bit 10MHz processor runing - dare I say it - un-bloated code

Aha! Thanks for that info. That explains another problem that I was having.  :red

Chris

[anon]

As has already been stated, you can use the API to do the communication. But
it will not be easy, especially combined with graphically displaying the data. Have
you considered the EASY answer? Dump XP and load DOS on the machine or get
a cheap older machine to replace the dead one.

[Light-I]

But
it will not be easy, especially combined with graphically displaying the data.

You can create second thread for communication only, with higer priority, you can create 32bit console application and use API.... Usually, who starts programming in asm, doesn't expect easy way, so don't worry about it... ;)

I've made some procedures in masm32/WinAPI (using succesfully at 115200kbps without any problems @PIII/600MHz/Win98SE - communication with Atmel AVR RISC microcontroller programmed in asm too ;) ), you can use them :

Code Select Expand

.data?
dcb DCB<>
cmtout COMMTIMEOUTS<>
BuffRxD db 20h dup (?)
BuffTxD db 20h dup (?)
hFilePort HANDLE ?
FileWSize dd ?
FileRSize dd ?
OpenPort PROTO
ClosePort PROTO
SendCmd PROTO :LPSTR,:DWORD
RecvCmd PROTO :LPSTR,:DWORD
.const
BAUD_RATE equ CBR_115200
; BAUD_RATE equ CBR_19200
.code
OpenPort proc
; ****************************** Open Serial Port ******************************
invoke CreateFile, ADDR BuffPortName,\; lpFileName - pointer to name of the file
  GENERIC_READ or GENERIC_WRITE,\; dwDesiredAccess - access (read-write) mode
  NULL,\; dwShareMode - share mode
  NULL,\; lpSecurityAttributes - pointer to security attributes
  OPEN_EXISTING,\; dwCreationDistribution - how to create
  FILE_ATTRIBUTE_NORMAL,\; dwFlagsAndAttributes - file attributes
  NULL; hTemplateFile - handle to file with attributes to copy
mov hFilePort, eax
cmp eax, INVALID_HANDLE_VALUE
jz @F
invoke GetCommState, hFilePort, ADDR dcb
mov dcb.DCBlength, sizeof dcb
mov dcb.BaudRate, BAUD_RATE
mov dcb.ByteSize, 8
mov dcb.Parity, NOPARITY ; no, odd, even, mark, space
mov dcb.StopBits, ONESTOPBIT ; 0,1,2 = 1, 1.5, 2
mov  dcb.fbits, BITRECORD<\
TRUE,\ ; fBinary:1
FALSE,\ ; fParity:1
FALSE,\ ; fOutxCtsFlow:1
FALSE,\ ; fOutxDsrFlow:1
DTR_CONTROL_DISABLE,\ ; fDtrControl:2
FALSE,\ ; fDsrSensitivity:1
TRUE,\ ; fTXContinueOnXoff:1
FALSE,\ ; fOutX:1
FALSE,\ ; fInX:1
TRUE,\ ; fErrorChar:1
FALSE,\ ; fNull:1
RTS_CONTROL_DISABLE,\ ; fRtsControl:2
FALSE,\ ; fAbortOnError:1
NULL> ; fDummy2:17
mov dcb.ErrorChar, 0FFh
mov dcb.EvtChar, 0
;IFDEF _DEBUG_
;PrintHex dcb.fbits
; ENDIF
invoke SetCommState, hFilePort, ADDR dcb
or eax, eax
jz BadSettings
;---------------------------------------------------------------------
invoke GetCommTimeouts, hFilePort, ADDR cmtout
mov cmtout.ReadIntervalTimeout, 10 ; Timeout between received bytes [ms]
mov cmtout.ReadTotalTimeoutMultiplier, 10 ; Timeout part multipled by number of bytes to receive [ms]
mov cmtout.ReadTotalTimeoutConstant, 50 ; Constant part of receive timeout [ms]
mov cmtout.WriteTotalTimeoutMultiplier, 10 ; Timeout part multipled by number of bytes to transmit [ms]
mov cmtout.WriteTotalTimeoutConstant, 100 ; Constant part of transmit timeout [ms]
invoke SetCommTimeouts, hFilePort, ADDR cmtout
;---------------------------------------------------------------------
invoke SetupComm, hFilePort, 4096, 4096 ; COMM_INBUFSIZE,COMM_OUTBUFSIZE
invoke PurgeComm, hFilePort, PURGE_TXABORT or PURGE_RXABORT or PURGE_TXCLEAR or PURGE_RXCLEAR
@@:
mov eax, hFilePort
ret
BadSettings:
invoke CloseHandle, hFilePort
xor eax, eax
mov hFilePort, eax ; Port Already Closed
ret
OpenPort endp
ClosePort proc
invoke FlushFileBuffers, hFilePort
invoke CloseHandle, hFilePort
ret
ClosePort endp

SendCmd proc lpSerCmd:LPSTR, lenSerCmd:DWORD
lea eax, FileWSize
invoke WriteFile, hFilePort, lpSerCmd, lenSerCmd, eax, NULL
ret
SendCmd endp

RecvCmd proc lpBuffRecv:LPSTR, lenExpectRecv:DWORD
mov ebx, lpBuffRecv
xor ecx, ecx
mov [ebx], ecx
mov FileRSize, 0
lea eax, FileRSize
invoke ReadFile, hFilePort, lpBuffRecv, lenExpectRecv, eax, NULL
ret
RecvCmd endp

[Roger]

Thank you Light-I for your posting and I will look carefully at your code. I had thought of extra threads - once I can learn how to make the 1st thread work.

Have you considered the EASY answer? Dump XP and load DOS on the machine or get
a cheap older machine to replace the dead one.

I would love to dump XP and will when I can get a DOS with plug and play and NTFS capability <grin> Unfortunatly ACER only provide drivers for XP so I shall have to stick with my older machine.

Talking of older machines I have just got WinIo working to talk to a mono display adapter for testing the serial link.

Regards Roger