Creating modem process and receiving output of AT commands

Creating modem process and receiving output of AT commands

[白い熊]

Hi:

I'm creating a frontend to GNU Emacs BBDB for sending SMSes via AT
commands, on a Nokia N900 mobile.

It has a `pnatd' program which when run works as a modem and enables you
to send AT commands to the phone.

As per http://www.gnu.org/software/emacs/manual/html_node/elisp/Output-from-Processes.html#Output-from-Processes
I've been messing with this back and forth, along the following
lines:
(defun nokia-n900-send-output-keep (process output)
  (setq nokia-n900-send-output-kept (cons output nokia-n900-send-output-kept)))

(defun testos ()
  (start-process "n900-sms-dispatch" "*n900-sms-dispatch*" "pnatd")
  (setq nokia-n900-send-output-kept nil)
  (set-process-filter (get-process "n900-sms-dispatch") 'nokia-n900-send-output-keep)
  (process-send-string "n900-sms-dispatch" "at\r")
  (accept-process-output (get-process "n900-sms-dispatch"))
  (process-send-string "n900-sms-dispatch" "AT+CSCS=\"HEX\"\r")
  (accept-process-output (get-process "n900-sms-dispatch"))
  (process-send-string "n900-sms-dispatch" "AT+CSMP=17,167,0,8\r")
  (accept-process-output (get-process "n900-sms-dispatch"))
  (process-send-string "n900-sms-dispatch" "at+cmgf=1\r")
  (accept-process-output (get-process "n900-sms-dispatch")))

But running (testos), it doesn't even get to sending the first `at\r'. I think the reason
is, as the page says: When a subprocess terminates, Emacs reads any
pending output, then stops reading output from that
subprocess. Therefore, if the subprocess has children that are still
live and still producing output, Emacs won't receive that output.

And this is the case here, when you start the pnatd process, it runs and
then you're supposed to send the AT commands and wait for their output,
however the process doesn't terminate, so no output is received by
Emacs.

How around this?

Thanks for any help.
-- 
C уважением / 宜しく御願い致します / Best regards / S pozdravem / Z poważaniem / Mit freundlichen Grüßen

白い熊

Re: Creating modem process and receiving output of AT commands

[Thien-Thi Nguyen]

() 白い熊 <emacs-devel_gnu.org@sumou.com>
() Mon, 01 Mar 2010 13:05:55 +0300

  (defun nokia-n900-send-output-keep (process output)
    (setq nokia-n900-send-output-kept (cons output nokia-n900-send-output-kept)))

Probably you want to add output to the tail, not the head.

   But running (testos), it doesn't even get to sending the first `at\r'.

What does that mean, precisely?  Does Emacs signal an error?

   I think the reason is [...].

It's possible that \r is being mangled.
See `process-coding-system-alist' (and friends).

You should make sure the subprocess sees what Emacs is purporting to send,
first, before worrying about whether or not Emacs sees what the subprocess
outputs.

thi

Re: Creating modem process and receiving output of AT commands

[白い熊]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:
>   (defun nokia-n900-send-output-keep (process output)
>     (setq nokia-n900-send-output-kept (cons output nokia-n900-send-output-kept)))
>
> Probably you want to add output to the tail, not the head.

Yeah, however, if adding to the tail, for some reason it adds some
strange quotation marks and brackets. This way, the variable has an
identical log, just in reverse order, as when you don't use a filter,
and have output logged to a buffer. Not a big deal, could probably
figure out what's wrong later, after I get it working...

>    But running (testos), it doesn't even get to sending the first `at\r'.
>
> What does that mean, precisely?  Does Emacs signal an error?

No, there is no error, the first AT command doesn't get sent, Emacs just
waits forever.

>    I think the reason is [...].
>
> It's possible that \r is being mangled.
> See `process-coding-system-alist' (and friends).

It's not. If I run all the commands by hand, i.e. line by line, then
Emacs updates, and they are carried out, but if run in a function, it
just halts before getting to the first AT command, if I interrupt the
process, and inspect the value of nokia-n900-send-output-kept it's still
empty.

If I send the commands one by one, i.e. not as a whole function, but
line by line, the nokia-n900-send-output-kept is updated well and it
carries out.

> You should make sure the subprocess sees what Emacs is purporting to send,
> first, before worrying about whether or not Emacs sees what the subprocess
> outputs.

I'm sure of that, as I'can send the SMS each and every time, evaluating
line-by-line, just running the whole function, it gets stuck as Emacs
doesn't see process output and thus doesn't advance to the next step.
-- 
C уважением / 宜しく御願い致します / Best regards / S pozdravem / Z poważaniem / Mit freundlichen Grüßen

白い熊

Re: Creating modem process and receiving output of AT commands

[Thien-Thi Nguyen]

() 白い熊 <emacs-devel_gnu.org@sumou.com>
() Mon, 01 Mar 2010 16:24:23 +0300

   I'm sure of that, as I'can send the SMS each and every time,
   evaluating line-by-line, just running the whole function, it
   gets stuck as Emacs doesn't see process output and thus doesn't
   advance to the next step.

In this case, i suggest you look at tq.el, and if
it doesn't do what you want, improve it so that it does.

thi

Re: Creating modem process and receiving output of AT commands

[白い熊]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:
> In this case, i suggest you look at tq.el, and if
> it doesn't do what you want, improve it so that it does.

Yep, I was sorta afraid it was gonna lead to this :O) That's the
conclusion I've been leaning towards...

Will have to study now how tq.el works, have started looking for working
tq.el implementations, so I may try to understand it, ufffgh...

If you have any pointers or recommendations, please let me know.
-- 
C уважением / 宜しく御願い致します / Best regards / S pozdravem / Z poważaniem / Mit freundlichen Grüßen

白い熊

Re: Creating modem process and receiving output of AT commands

[Thien-Thi Nguyen]

() 白い熊 <emacs-devel_gnu.org@sumou.com>
() Tue, 02 Mar 2010 01:47:58 +0300

   If you have any pointers or recommendations, please let me know.

Have a look at (info "(elisp) Transaction Queues").

Since you already know (and have verified) the correct sequence of
subprocess input and corresponding output, only the timing remains.
In questions of timing, the language revolves around the expression
of "wait".  What spins fast carelessly must spin slow carefully.

thi