linuxcall-list

[Linuxcall] ainda sobre funções de tratamento do modem

[Marcelo B. <md...@ma...>]

tava revendo os mails aqui, e pintou mais ideias:
--------8<------------
# char **modem_ati(char *device)
# 
# A gente passa como parâmetro a saída da função anterior e recebe um
# vetor com as ATI's do modem...

Exatamente, o parâmetro anterior seria retornado como parâmetro, sem
o uso de uma variável global. A partir daí, faço a leitura dos ATI's
e escrevo a resposta no vetor, retornando o ponteiro pro mesmo.
--------8<-----------

Que tal o seguinte:

int modem_ati(char device, char **modem_ati)

ou

int modem_ati(int fd, char **modem_ati)

Valores de retorno:
0 - OK
1 - Erro: não leu nada
2 - Erro: leu apenas alguns ATIs, falhou em outros

Quanto aos parâmetros:
char device: passaria o número da porta, ttyS[device]
int fd: passaria o file descriptor, retornado por uma função, por
exemplo, int openport(char port);

Tudo é possivel, não há problema algum em implementar de uma forma ou
outra, digam ai o que voces acham melhor.

Alex e interface texto, seja em C ou script:
Acham valido um executavelzinho pra resetar o modem, ou localizar o
modem?  Esse executavel retornaria 0 (sucesso) ou outros valores para
codigos de erros. O valor de retorno pode ser aproveitado por um
script ou um prog em C.

Nesse caso, achariam legal que fosse?:
resetmodem [x]

sendo x a porta do modem.

Poderia ser feito tb um:
atimodem x [output-file]

Retornaria as respostas dos ATI's, em stdout (caso não seja passado
o segundo parametro), ou escreveria em um arquivo. x, novamente, é a
porta ttyS[x] do modem.

A saida tb poderia ser redirecionada para um pipe, outro comando, etc.


Em anexo, estou enviando o modem.c
Ele vasculha as portas ttyS0 a ttyS3 em busca de algum modem.

O retorno dele é algo parecido com:
[marcelo@arise linuxcall]$ ./modem.exe 
Modem Seek and Destroy - versão 0.2

Seek modem at ttyS0: unable to open port         * ver mais adiante
Seek modem at ttyS1: (0)(1)(2) ...nothing :(
Seek modem at ttyS2: unable to open port         * ver mais adiante
Seek modem at ttyS3: (0)[9] ...modem found!!!

O que significa isso?

unable to open port:
Estou rodando como usuario comum.
[marcelo@arise linuxcall]$ l /dev/ttyS*
crw-------   1 root     tty        4,  64 Nov 16 20:38 /dev/ttyS0
crw----rw-   1 root     tty        4,  65 Nov 16 22:43 /dev/ttyS1
crw-------   1 root     tty        4,  66 May  5  1998 /dev/ttyS2
crw----rw-   1 root     tty        4,  67 Nov 16 22:43 /dev/ttyS3

Tenho poder de escrita/leitura só em ttyS1 e ttyS3, por isso o unable
na 0 e 2.

Entre parenteses, esta o numero de tentativas de envio de AT para o
modem. O programa faz 3 tentativas.

Entre []'s, o numero de bytes recebidos do modem.

Aqui, se rodar como root, abro e escrevo a ttyS0, mas nela esta
rodando tb o gpm, entao, tenho que dar um restart no gpm apos rodar o
'modem'. Estejam preparados para isso, de preferencia rodem no
terminal, já que pode travar o mouse. :(

Aqui testei em dois modems:
* boca SRS33600, em ttyS3
* microcom deskporte 14400, externo, ligado em ttyS1

Ambos foram detectados sem problemas.

Para compilar o programa, executem:
gcc modem.c -o modem

e rodem com:
./modem

Se puderem testar ai, eu agradeço. Se encontrarem algum problema,
ou se não funcionar muito bem, me avisem pra eu poder corrigir.

Na sequencia, estarei mandando as funcoes preparadas
especificamente para o Andre e o Alex usarem na interface/scripts.

Quanto a internacionalização da interface, acabou ficando de lado, eu
não estava prevendo que trabalharia tanto nos ultimos dias, acabei
dando um trampo no final de semana/feriado, o que não estava previsto
:(

Bom, por enquanto é isso pessoal, na medida do possivel vou mandando
mais coisa ai.

[]s

-- 
#=-=[  ser...@us...  ]=-=+=#=--------------=#
|  Marcelo D. Beckmann  --user[]="#173935"--  | |     CL5 2.2.14
| md...@ma...     UIN [53189692]----+ | Slack 7 2.2.13
#  - =-#--=[ http://marcelobeckmann.cjb.net ]=--#-==-==-==-==-==-#
+ .~.  |                  233MMX 32MB 8.4+3.2GB Quantum Fireball ]
  /V\  #------------------466.94----[ OPL3SAx TGUI9680 2MB 33600 ]
 /(.)\ "Estamos de volta aos tempos em que os homens eram homens ]
 ^`~´^  e programavam seus próprios drivers de dispositivo."L.T. ]
#-====-#----=[ serialcoder ]=- + -=[ http://wm.themes.org ]=-----'
RTS-[CTS]-DLE-STX-17-39-35-CRC-F6-66-DLE-ETX-/RTS-[/CTS-RTS]-CTS-[ACK]

Re: [Linuxcall] ainda sobre =?iso-8859-1?Q?fun=E7=F5es?= de tratamento do modem

[C. <dig...@us...>]

Marcelo Beckmann wrote:
> 
> tava revendo os mails aqui, e pintou mais ideias:
> --------8<------------
> # char **modem_ati(char *device)
> #
> # A gente passa como parâmetro a saída da função anterior e recebe um
> # vetor com as ATI's do modem...
> 
> Exatamente, o parâmetro anterior seria retornado como parâmetro, sem
> o uso de uma variável global. A partir daí, faço a leitura dos ATI's
> e escrevo a resposta no vetor, retornando o ponteiro pro mesmo.
> --------8<-----------
> 
> Que tal o seguinte:

Essa me pareceu mais interessante...

> int modem_ati(int fd, char **modem_ati)

> Quanto aos parâmetros:
> char device: passaria o número da porta, ttyS[device]
> int fd: passaria o file descriptor, retornado por uma função, por
> exemplo, int openport(char port);
> 
> Tudo é possivel, não há problema algum em implementar de uma forma ou
> outra, digam ai o que voces acham melhor.
> 
> Alex e interface texto, seja em C ou script:
> Acham valido um executavelzinho pra resetar o modem, ou localizar o
> modem?  Esse executavel retornaria 0 (sucesso) ou outros valores para
> codigos de erros. O valor de retorno pode ser aproveitado por um
> script ou um prog em C.

Com certeza... se puder fazer, vai ser uma boa... :)

> Nesse caso, achariam legal que fosse?:
> resetmodem [x]
> 
> sendo x a porta do modem.

Essa mais simples parece ser melhor...

> Em anexo, estou enviando o modem.c
> Ele vasculha as portas ttyS0 a ttyS3 em busca de algum modem.
> 
> O retorno dele é algo parecido com:

digitalcoder [alcs]$ sudo ./modem
Modem Seek and Destroy - versão 0.2

Seek modem at ttyS0: (0)(1)(2) ...nothing :(
Seek modem at ttyS1: unable to open port
Seek modem at ttyS2: unable to open port
Seek modem at ttyS3: (0)[9] ...modem found!!!
digitalcoder [alcs]$ 

Só é uma pena que não esteja funcionando como usuário comum... Talvez
tenhamos que usar akele lance do fork como root (UID 0) para que o user
comum possa usar essas funções...

> Entre []'s, o numero de bytes recebidos do modem.

hehehhe... mexa o mouse durante o scan da tttS0... ;-)

> Aqui, se rodar como root, abro e escrevo a ttyS0, mas nela esta
> rodando tb o gpm, entao, tenho que dar um restart no gpm apos rodar o
> 'modem'. Estejam preparados para isso, de preferencia rodem no
> terminal, já que pode travar o mouse. :(

Curioso, testei aki no X, com mouse pendurado no gpm (no XF86Config, o
device do mouse é o /dev/gpmdata) e não teve nada demais... mouse na
boa... :)

> Aqui testei em dois modems:
> * boca SRS33600, em ttyS3
> * microcom deskporte 14400, externo, ligado em ttyS1

Aki eu testei com um Trellis, 28.8 ISA, funcionou sem problemas tb.
Marcelo, quanto à akele lance do winmodem cara, o f*da é que se o driver
dele não estiver carregado, não rola. Tipo, no caso do HSP por exemplo:
se vc não carregar o pctel.o, o /dev/ttyS15 fica "NULL". Nesses casos, o
mais correto seria um scan no link simbólico (o kppp faz isso) em
/dev/modem... dá prá implementar ?
 
> Se puderem testar ai, eu agradeço. Se encontrarem algum problema,
> ou se não funcionar muito bem, me avisem pra eu poder corrigir.

Aki funcionou sem problemas...

> Na sequencia, estarei mandando as funcoes preparadas
> especificamente para o Andre e o Alex usarem na interface/scripts.

Opa. Maravilha mano... valeu aí o gaz que vc tá dando na coisa...
Eu tava todo empolgado tb, mas de uma hora prá outra apareceu um monte
de trampo aki.... puts, é bom e é ruim. :) Ainda não tive tempo de
implementar as funcs de acesso ao arkivo, mas se Deus quiser ainda nesse
fim de semana a coisa sai... :)

Ps: Eae Amauri, bem vindo de volta cara !!! :P 
Peguei uns trecos legais sobre o GTK e pasmem !!! Ainda nesse fim de
semana deve sair um BETA _funcional_ da interface em gtk (mesmas
funcionalidades do atual BETA da XSTEP. :)))

[]'s

-- 
André Casteliano
Analista de Sistemas

+-=-=[ dig...@us...]=-=-+
[ Linux User: # 178853	Machine: # 79923      ]
[ Linux Heavy User - Powered by Slackware 7.1 ]
[ http://www.geocities.com/andre_casteliano/  ]
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
[        LinuxCall - The Linux Dialer         ]
[      http://linuxcall.sourceforge.net       ]
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+