home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / lisp / mcl / 1213 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  3.0 KB
  1. Path: sparky!uunet!elroy.jpl.nasa.gov!swrinde!mips!apple!cambridge.apple.com!bill@cambridge.apple.com
  2. From: bill@cambridge.apple.com (Bill St. Clair)
  3. Newsgroups: comp.lang.lisp.mcl
  4. Subject: Re: Interfacing to I/O boards
  5. Message-ID: <9208131601.AA12690@cambridge.apple.com>
  6. Date: 13 Aug 92 17:04:11 GMT
  7. Sender: info-mcl-request@cambridge.apple.com
  8. Lines: 54
  9. Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
  10. Full-Name: Bill St. Clair
  11. Original-To: John Doleac <jd05@gte.com>
  12. Original-Cc: info-mcl
  13.  
  14. >I am using GW's MacADIOS I/O board to interface to sensors and 
  15. >motors which are part of a control algorithm testbed.  I want to 
  16. >call C functions compiled using Symantec's Think C development
  17. >system.  These C functions are used to get data from sensors and
  18. >to give commands to motors.
  19. >
  20. >The manual tells how to use foreign function calls for code
  21. >compiled by MPW.  This does not work for Think C.  Can anyone
  22. >recommend a way to overcome this problem?
  23. >
  24. >I asked this question at MacWorld last week in Boston.  No one in 
  25. >the Apple booth knew much about LISP nor could they provide
  26. >any recommendations for hardware interfaces for this kind of
  27. >application.  The most consistent recommendation I got for 
  28. >interfacing to sensors and motors from a mac was to use a 
  29. >serial connection to a PC outfitted with a good I/O board.  The
  30. >PC could be used as a co-processor.
  31. >
  32. >If using a serial connection to a PC is a good solution, can 
  33. >anyone recommend examples of protocols I can use?
  34.  
  35. Straz told you about Guillaume Cartier's package.
  36. I have a few more comments.
  37.  
  38. I see no reason to use a PC as a co-processor unless your real-time
  39. constraints are such that one processor cannot handle the load.
  40. In this case, you'll need the PC to do more than toggle bits on an
  41. interface card. You've already said you have an I/O board that does the
  42. job, Why buy another computer?
  43.  
  44. Depending on the size of the Think C functions that interface to
  45. the I/O board, you may be able to recode them in MCL rather than
  46. using them directly. MCL's memory referencing code is not quite
  47. as fast as Think C's, but you'll probably make up for the speed
  48. difference by eliminating the cross-language calls (not that speed
  49. is an issue here: we're talking about differences in microseconds,
  50. and motors only notice differences in milliseconds).
  51.  
  52. Of course, if your Think C code is large, then recoding will not be
  53. cost-efficient, and you'll want to use Guillaume Cartier's package.
  54.  
  55. It's very likely that your real-time constraints will be such that
  56. you can't afford to wait for MCL to garbage collect. You'll need to
  57. be careful from the beginning to write code that does not cons.
  58. Peter Norvig's book, "Paradigms of Artificial Intelligence Programming",
  59. has a short section about this, and people on info-mcl can help you
  60. with specifics as they arise. Ashok Khosla has been writing a paper
  61. about optimization techniques for Lisp in general and MCL in particular,
  62. which he should be posting soon. It includes information on where
  63. DYNAMIC-EXTENT declarations will prevent heap consing in MCL.
  64.  
  65. Enjoy!
  66.  
  67. -Bill
  68.