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

[Noilson Caio]

Com screen rola, você pode até jogar a saida para o syslog *.* /dev/device



2009/4/22 Fernando Gottlieb <address@hidden>

>
>
> 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<reinaldoc%40gmail.com>
> >:
>
> >
> >
> > 2009/4/20 Alain M. <address@hidden <alainm%40pobox.com>>:
> >
> >> 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
> >
>  
>



-- 
" Eu quero saber como renomear um arquivo " ele diz.
Por favor, é dia de pagamento, não é?! Mas eu estou de bom humor.
" Claro. Basta dar 'rm' e o nome do arquivo "
" Obrigado "


[As partes desta mensagem que não continham texto foram removidas]