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 <[email protected]>: > > > 2009/4/20 Alain M. <[email protected]>: > >> 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 >
