help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Controlling an external device with elisp


From: upro
Subject: Re: Controlling an external device with elisp
Date: Mon, 05 May 2003 10:13:40 +0200
User-agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux)

Ed L Cashin <address@hidden> writes:

> upro <address@hidden> writes:
>
>> Jonas Steverud <address@hidden> writes:
>>
>>> upro <address@hidden> writes:
>>>
>>>> Now this might be a strange question, but is it possible to control an
>>>> external device, through parallel or serial port, using elisp as
>>>> programming language?
>>>
>>> It should be possible if the device has a text-based protocol and
>>> supports a tcp/ip connection. Gnus, which I use right now, does that
>>> to my ISP's newsserver.
>>>
>>> But if you mean on a lower level, if the device is stupid, like an
>>> thermometer or simple motor; I do not know.
>>>
>>> Depends on the device, a bit.
>>
>> Hi Jonas, what I meant was indeed a "stupid" device, like a selfmade
>> small circuit to switch on a light or somolar (as seen in the Coffee
>> mini-HOWTO).
>>
>> Do you think this is impossible?
>
> No, it's perfectly possible.  The thing is that you can *use* the
> device from emacs but ultimately talking to hardware is a kernel
> thing.  Assuming Linux, as your reference to the Coffee mini-HOWTO
> would suggest, your choices are to ...
>
>   * build the circuit to recognize codes you can send using an
>     existing driver
>
>     e.g., you could put the device on your first serial port and
>     control it from emacs by writing strings like "please turn on the
>     light" or numbers like 101 to /dev/ttyS0.
>
> or
>
>   * use IO primitives or write your own driver as suggested in the
>     Coffee mini-HOWTO

Are these IO primitives in C? I don't really understand this. 

I prefer the second suggestion, since I have very few knowledge of how
to build circtios (not to speak of how to recognize signals...)

Thank You In Advance!

>
> The former option is probably a lot easier in software; the latter is
> probably easier for you in terms of circuit design.

-- 
Michael

r-znvy: zvpunry.wryqra  jro.qr (chg gur "@" jurer vg svgf...)
ab fcnz cyrnfr


reply via email to

[Prev in Thread] Current Thread [Next in Thread]