Re: Interfacing to I/O boards

[bill@cambridge.apple.com (Bill St. Clair)]

>I am using GW's MacADIOS I/O board to interface to sensors and 
>motors which are part of a control algorithm testbed.  I want to 
>call C functions compiled using Symantec's Think C development
>system.  These C functions are used to get data from sensors and
>to give commands to motors.
>
>The manual tells how to use foreign function calls for code
>compiled by MPW.  This does not work for Think C.  Can anyone
>recommend a way to overcome this problem?
>
>I asked this question at MacWorld last week in Boston.  No one in 
>the Apple booth knew much about LISP nor could they provide
>any recommendations for hardware interfaces for this kind of
>application.  The most consistent recommendation I got for 
>interfacing to sensors and motors from a mac was to use a 
>serial connection to a PC outfitted with a good I/O board.  The
>PC could be used as a co-processor.
>
>If using a serial connection to a PC is a good solution, can 
>anyone recommend examples of protocols I can use?

Straz told you about Guillaume Cartier's package.
I have a few more comments.

I see no reason to use a PC as a co-processor unless your real-time
constraints are such that one processor cannot handle the load.
In this case, you'll need the PC to do more than toggle bits on an
interface card. You've already said you have an I/O board that does the
job, Why buy another computer?

Depending on the size of the Think C functions that interface to
the I/O board, you may be able to recode them in MCL rather than
using them directly. MCL's memory referencing code is not quite
as fast as Think C's, but you'll probably make up for the speed
difference by eliminating the cross-language calls (not that speed
is an issue here: we're talking about differences in microseconds,
and motors only notice differences in milliseconds).

Of course, if your Think C code is large, then recoding will not be
cost-efficient, and you'll want to use Guillaume Cartier's package.

It's very likely that your real-time constraints will be such that
you can't afford to wait for MCL to garbage collect. You'll need to
be careful from the beginning to write code that does not cons.
Peter Norvig's book, "Paradigms of Artificial Intelligence Programming",
has a short section about this, and people on info-mcl can help you
with specifics as they arise. Ashok Khosla has been writing a paper
about optimization techniques for Lisp in general and MCL in particular,
which he should be posting soon. It includes information on where
DYNAMIC-EXTENT declarations will prevent heap consing in MCL.

Enjoy!

-Bill