shell-script-pt
[Top][All Lists]
Advanced

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

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


From: Reinaldo de Carvalho
Subject: Re: [shell-script] Ler e Escrever - USB serial
Date: Tue, 21 Apr 2009 13:51:29 -0300

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


reply via email to

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