Re: Lua module wrapping the Windows COMM port API

[Ross Berteig <Ross@...>]

On Sat, 21 Jun 2008, David Girault wrote: 
>This sound great, but why don't create a generic comm API that 
>can use either the windows API or the linux API ? Since LUA itself is 
>ported to all plateform, why limiting module to Windows plateform?

The simple answer is that I have multiple Windows platforms 
available to me, but no Unix, Linux, or Mac systems. I am not 
hostile to platform portability, I just don't have the resources 
at hand. Also, my immediate and direct need is to make efficient 
use of serial ports on a Windows platform.

Were I designing a portable serial port API, I would imagine that 
it would be a portable Lua module that lays over a mostly 
non-portable interface to each supported platform's native API. 
Deciding what features should be provided and how they are 
abstracted from the capabilities provided by multiple platforms 
is not a task I can take on at the moment. That said, I'd be 
happy to advise someone who want that architectural role from my 
understanding of how things work on the Windows side.

Some of the upper layer design really should be done with 
LuaSocket fully involved. Ideally, LuaSocket or something derived 
from it should be able to provide a socket-like abstraction over 
nearly any kind of I/O channel. Serial ports should fit that 
model nicely.

Another approach would be to fit serial port configuration into 
the framework of the existing standard io library. That is the 
approach I took in my prior version of this code which 
effectively extended the file class to add support for 
controlling baud rate, handshake modes, and so forth. It was a 
very ad hoc approach that got the job done, but since io is 
itself implemented through the C stdio library I kept running 
into edge cases involving just which layer had buffered a 
character without delivering it. My wrapper is only buffered to 
the extent that the Windows device driver (and the UART itself) 
is buffered, so I expect to find a whole new set of edge cases to 
worry about ;-) 


Ross Berteig                               Ross@CheshireEng.com
Cheshire Engineering Corp.           http://www.CheshireEng.com/