Re: [shell-script] Ler e Escrever - USB serial

[Fernando Gottlieb]

Olá Reinaldo.
Agradeço imensamente sua explicação.
Posso concluir que, infelizmente, shell não será a melhor solução.
Estou encerrando este tópico para não se tornar off e não prejudicar o
andamento da lista.
Entrarei em contato com vc diretamente para dar continuidade ao assunto.

Abraços

Fernando A. Gottlieb

2009/4/21 Reinaldo de Carvalho <address@hidden>:
>
>
> 2009/4/20 Alain M. <address@hidden>:
>
>> provavelmente você abortou o picocom e deixou o lock...
>>
>> A a maioria dos recursos no Linux têm travamentos assim, enm sempre é
>> muito fácil descobrir onde os arquivos lock ficam para poder eliminálos
>> nos scripts...
>>
>> a maneira correta de sair so picocom é Control+A Ctrl+X, onde Ctrl+A é
>> chamado de Escape-char, ou seja caracter de comando, e X para Exit. pode
>> também usar  picicom com --nolock
>>
>> Todos os terminais tem comandos assim.. não tem jeito porque é para
>> evitar conflito com a aplicação.
>>
>> Alain
>>
>
> Na minha opinião pode não ser questão de lock, mas de entender que um
> hardware tem estados, basicamente "lendo" e "escrevendo" sobre um
> buffer. E enquanto a operação não é concluida, ele fica ocioso.
>
> Normalmente quando o aplicativo do usuário escreve no device (no
> buffer) o hardware processa isto, e devolve uma informação ao buffer,
> ao qual pode ser lido.
>
> Mas vamos imaginar o primeiro passo, de escrita no buffer via device,
> a questão é "quando" o hardware vai processar, pode ser de caracter a
> caracter, de quebra de linha a quebra de linha, isto depende da
> especificação do hardware, e enquando esta 'trigger' não disparada o
> hardware não processará e pode não ser possível efetuar a operação de
> leitura (via cat).
>
> A questão é enquanto uma operação esta sendo realizada, o hardware
> esta aguardando uma situação que ativa o processamento.
>
> É provavel que um simples "echo > /dev/ttyUSB0" dispare o
> processamento do hardware, e possa novamente ser acesso pelo "cat",
> mas se isso não funcionar, a especificação da comunicação deve ajudar.
>
> O shell não tem recursos de alto nível para comunição com hardware, por
> exemplo:
>
> - muitos protocolos necessitam sequencias binárias, o que daria
> trabalho a mais com o 'echo'.
>
> - o cat não suporte a 'timeout' o que é necessário para identificar
> que o hardware não esta respondendo, provavelmente pois o
> processamento do buffer ainda não foi disparado, levando a escrita da
> mais códigos para esse controle
>
> Uma simulação de timeout...
>
> cat /dev/ttyUSB0 &
> bg
> i=0
> while true; do
> jobs | grep -q cat || break
> let i++
> if [ "$i" -eq 10 ] ; then
> killall -9 cat >/dev/null 2>&1
> echo 'Nao pude ler do device.'
> break
> fi
> sleep 1
> done
>
> Nesse caso, não havia nada no buffer do hardware ou o hardware não
> permitiu a leitura, tendo que tentar disparar o processado do hardware
> sobre o conteudo do buffer, que como disse, dependendo do hardware
> pode ser "echo > /dev/ttyUSB0".
>
> Na minha opinião, usar shell para interagir com hardware é muito mais
> trabalhoso do que outras linguagens que possuem funções/métodos
> disponíveis para acesso ao hardware, como python.
>
> Ps: o Júlio leu minha mente quando eu me referi ao "ps -ef". ;)
>
> --
> Reinaldo de Carvalho
> http://korreio.sf.net
> http://python-cyrus.sf.net
>