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

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

Re: [shell-script] Comandos em eventos recebidos pela USB


From: Alfredo Casanova
Subject: Re: [shell-script] Comandos em eventos recebidos pela USB
Date: Wed, 21 Jan 2015 13:02:44 +0000

Fernando, mandei um e-mail pro autor do código em C



On Tue Jan 20 2015 at 10:21:05 PM 'Julio C. Neves' address@hidden
[shell-script] <address@hidden> wrote:

>
>
> Nando, Nao seria melhor tratar o hexa com printf?
> Em 20/01/2015 15:46, "Alfredo Casanova address@hidden
> [shell-script]" <address@hidden> escreveu:
>
>
>
>>
>> Fernando, quando seto o valor do status (head -c1 buf) ele não pega um
>> valor inteiro pra ser testado...
>> $ echo -ne "\x08\x00\x00\x00\x00\x00\x00\x02" > buf
>>
>> $ dd if=buf of=/dev/hidraw3 bs=8 count=1 conv=notrunc
>> 1+0 records in
>> 1+0 records out
>> 8 bytes (8 B) copied, 0.00300605 s, 2.7 kB/s
>>
>> $ cat buf
>> [caractere truncado]
>>
>> $ cat buf | od -h
>> 0000000 0008 0000 0000 0200
>> 0000010
>>
>> $ dd if=/dev/hidraw3 of=buf bs=1 count=1
>> 1+0 records in
>> 1+0 records out
>> 1 byte (1 B) copied, 0.0108561 s, 0.1 kB/s
>>
>> $ siz=$(cat buf | wc -c)
>> $ echo $siz
>> 1
>> $ status=$(head -c1 buf)
>>
>> $ echo $status
>> [caractere truncado]
>>
>> $ echo $status | od -h
>> 0000000 0a15
>> 0000002
>>
>> assim é impossível testar
>>
>>
>>
>>
>> On Tue Jan 20 2015 at 1:12:26 PM Alfredo Casanova <address@hidden>
>> wrote:
>>
>>> Exatamente o que eu queria! Vou testar mais tarde e mando o que consegui
>>> (ou não consegui)!
>>> Valeu!!
>>>
>>> On Tue Jan 20 2015 at 12:41:41 PM Fernando Mercês address@hidden
>>> [shell-script] <address@hidden> wrote:
>>>
>>>>
>>>>
>>>> Alfredo,
>>>>
>>>> Creio que sim, seja possível. Só vai dar um certo trabalhinho de
>>>> trabalhar com os dados binários. Deve dar pra fazer em memória, mas em fase
>>>> de desenvolvimento eu usaria um arquivo, que é a maneira nativa de I/O do
>>>> dd.
>>>>
>>>> No início do while na linha 31 o driver escreve 8 bytes do device:
>>>>
>>>>
>>>>    1.   while (1) {
>>>>    2.     memset(buf, 0x0, sizeof(buf));
>>>>    3.     buf[0] = 0x08;
>>>>    4.     buf[7] = 0x02;
>>>>    5.
>>>>    6.     res = write(fd, buf, 8);
>>>>
>>>>
>>>> Usando minha sugestão para o desenvolvimento temporário, pode-se
>>>> traduzir em bash para:
>>>>
>>>> $ echo -ne "\x08\x00\x00\x00\x00\x00\x00\x02" > buf
>>>> $ dd if=buf of=/dev/hidraw3 bs=8 count=1 conv=notrunc
>>>>
>>>> Depois ele lê de volta 8 bytes do device:
>>>>
>>>>
>>>>    1.     memset(buf, 0x0, sizeof(buf));
>>>>    2.     res = read(fd, buf, 8);
>>>>
>>>>
>>>> O que poderia ser feito com:
>>>>
>>>> $ dd if=/dev/hidraw3 of=buf bs=8 count=1
>>>>
>>>> Mas como ele testa somente buf[0], o primeiro byte, pra saber como
>>>> estão o botão, então bastaria ler 1:
>>>>
>>>> $ rm -f buf
>>>> $ dd if=/dev/hidraw3 of=buf bs=1 count=1
>>>>
>>>> E então vêm os testes:
>>>>
>>>>
>>>>    1.     if (res >= 0) {
>>>>    2.       if (prior == LID_CLOSED && buf[0] == LID_OPEN) {
>>>>    3.          printf("Lid Aberto?\n");
>>>>    4.          fflush(stdout);
>>>>    5.       } else if (prior != BUTTON_PRESSED && buf[0] == BUTTON_
>>>>    PRESSED) {
>>>>    6.          printf("Fire!!\n");
>>>>    7.          system("cvlc --play-and-exit /home/atcasanova/Dropbox/
>>>>    atila.mp3");
>>>>    8.          fflush(stdout);
>>>>    9.       } else if (prior != LID_CLOSED && buf[0] == LID_CLOSED) {
>>>>    10.          printf("Lid Closed!");
>>>>    11.          fflush(stdout);
>>>>    12.       }
>>>>    13.       prior = buf[0];
>>>>
>>>>
>>>> A variável prior é antes iniciada com o valor decimal 21 fora do loop.
>>>> Eu chamaria de "last", já que aparenta ser o último valor em buf[0]:
>>>>
>>>> last=21    # LID_CLOSED
>>>>
>>>> siz=$(wc -c buf | cut -d' ' -f1)
>>>> [ $siz -eq 1 ] || continue
>>>>
>>>> status=$(head -c1 buf)
>>>> [ $last -eq 21 -a $status -eq 22 ] && cvlc...
>>>> # outras condições
>>>> last=$status
>>>>
>>>> E por aí vai. Depois de debugado e prováveis bugs resolvidos, ao invés
>>>> de ficar com um buffer temporário no arquivo "buf" usando o dd, você pode
>>>> trabalhar em memória direto, tipo:
>>>>
>>>> # ler 8 bytes
>>>> buf=$(head -c8 /dev/hidraw3)
>>>>
>>>> # escrever 8 os bytes lidos
>>>> echo -ne "$buf" /dev/hidraw3
>>>>
>>>> Duvidas nas opções do dd ou echo, só ver no man. ;-)
>>>>
>>>> Boa sorte!
>>>>
>>>>
>>>>
>>>> Att,
>>>>
>>>> Fernando Mercês
>>>> Linux Registered User #432779
>>>> www.mentebinaria.com.br
>>>> ------------------------------------
>>>> "Ninguém pode ser escravo de sua identidade; quando surge uma
>>>> possibilidade de mudança é preciso mudar". (Elliot Gould)
>>>>
>>>> 2015-01-19 13:23 GMT-02:00 Alfredo Casanova address@hidden
>>>> [shell-script] <address@hidden>:
>>>>
>>>>
>>>>
>>>>>
>>>>> Fernando, já postei o código do driver, mas aí vai novamente:
>>>>> http://pastebin.com/sJqAmFVT
>>>>>
>>>>>
>>>>> On Sun Jan 18 2015 at 11:42:14 AM 'Julio C. Neves'
>>>>> address@hidden [shell-script] <address@hidden>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Tens razão Nando: o od é da velha guarda (deve ser Old Dump ;). Já
>>>>>> conhecia o hexdump (que tb é bem velhinho. Foi desenvolvido para o BSD
>>>>>> original, se não me falha a memória), mas dou preferência ao od pq ambos
>>>>>> fazem o mesmo e tenho mais intimidade com as opções do od.
>>>>>>
>>>>>> Mas o hd eu não conhecia. Vou estudá-lo. Valeu!
>>>>>>
>>>>>>
>>>>>> Abcs,
>>>>>> Julio
>>>>>> *@juliobash*
>>>>>> *Próximos cursos de Shell*
>>>>>> *Cidade         Local Período*
>>>>>> *Rio de Janeiro EDX <http://edx.srv.br/> 09 a 13/03/15*
>>>>>> *São Paulo 4Linux
>>>>>> <http://www.4linux.com.br/cursos/programacao-em-shell-script> 24 a 
>>>>>> 28/11/14*
>>>>>> Dou treinamento de *Shell* em qualquer cidade.
>>>>>> Para mais detalhes, me mande um e-mail <address@hidden>.
>>>>>>
>>>>>>
>>>>>> Em 18 de janeiro de 2015 09:12, Fernando Mercês address@hidden
>>>>>> [shell-script] <address@hidden> escreveu:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Alfredo, posta o link do driver que você achou que fica melhor pra
>>>>>>> gente avaliar.
>>>>>>>
>>>>>>> Julião, sei que você, assim como o od, é old school. Já testou o
>>>>>>> hexdump?
>>>>>>>
>>>>>>> $ od -N16 -h /bin/ls
>>>>>>> 0000000 457f 464c 0102 0001 0000 0000 0000 0000
>>>>>>> 0000020
>>>>>>>
>>>>>>> $ hexdump -n16 /bin/ls
>>>>>>> 0000000 457f 464c 0102 0001 0000 0000 0000 0000
>>>>>>> 0000010
>>>>>>>
>>>>>>> Mesma coisa. Agora, se você chamar o hexdump pelo seu symlink hd,
>>>>>>> olha que legal:
>>>>>>>
>>>>>>> $ hd -n16 /bin/ls
>>>>>>> 00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00
>>>>>>>  |.ELF............|
>>>>>>> 00000010
>>>>>>>
>>>>>>> Eu curti tanto essa saída que fiz um clone portável em ANSI C
>>>>>>> chamado hdump [1] pra usar em outros sistemas, incluindo ruindows:
>>>>>>>
>>>>>>> $ hdump -n16 /bin/ls
>>>>>>> 00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00
>>>>>>>  |.ELF............|
>>>>>>>
>>>>>>> Abraços!
>>>>>>>
>>>>>>> [1] https://github.com/merces/hdump
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Att,
>>>>>>>
>>>>>>> Fernando Mercês
>>>>>>> Linux Registered User #432779
>>>>>>> www.mentebinaria.com.br
>>>>>>> ------------------------------------
>>>>>>> "Ninguém pode ser escravo de sua identidade; quando surge uma
>>>>>>> possibilidade de mudança é preciso mudar". (Elliot Gould)
>>>>>>>
>>>>>>> 2015-01-16 11:58 GMT-02:00 Alfredo Casanova address@hidden
>>>>>>> [shell-script] <address@hidden>:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Entendi um pouco, vou ter que ler mais sobre o assunto.
>>>>>>>> Mas pelo que vi é impossível 'controlar' qualquer coisa que venha
>>>>>>>> pela USB sem ter um driver controlando isso, correto? O bash pode ler e
>>>>>>>> tratar esse output, mas não pode gerá-lo.
>>>>>>>>
>>>>>>>> On Fri Jan 16 2015 at 11:50:39 AM 'Julio C. Neves'
>>>>>>>> address@hidden [shell-script] <address@hidden.
>>>>>>>> br> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Vamos entender isso:
>>>>>>>>> >> Esqueça o primeiro bloco de 7 algarismos, que é só um sequencial;
>>>>>>>>> >> Cada linha tem duas partes, então a linha 0057520 tem uma parte
>>>>>>>>> que é 0015 0000 0000 0300 e outra que é 0017 0000 0000 0300
>>>>>>>>> >> O od inverte os bytes, assim bloquinho desses de 4 algarismos
>>>>>>>>> está invertido, ou seja 0300 no duro é 0003;
>>>>>>>>> Prova disso:
>>>>>>>>> $ echo "$IFS" | od -h
>>>>>>>>> 0000000 0920 0a0a
>>>>>>>>> 0000004
>>>>>>>>> $ echo "$IFS" | cat -vet
>>>>>>>>>  ^I$
>>>>>>>>> $
>>>>>>>>> No od -h primeiro vinha o <TAB> (09) e depois o espaço (20) mas o
>>>>>>>>> cat -vet mostrou que, no duro, a ordem é <BRANCO> <TAB> <ENTER>
>>>>>>>>> >> Sabendo disso repare que todos terminam em 0003, que seria NULL
>>>>>>>>> e ETX. ETX no protocolo BSC1 é END OF TEXT.
>>>>>>>>>
>>>>>>>>> Tirando o sequencial, o fire é sempre o mesmo.
>>>>>>>>>
>>>>>>>>> Experimente trocar o od -h por cat -vet, depois por od -c para que
>>>>>>>>> vc vá entendendo o que acontece. Pelo que vi, acho que dá para 
>>>>>>>>> implementar
>>>>>>>>> essa solução por bash sim (awk deve ser melhor para interpretar esses
>>>>>>>>> caracteres hexa)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Abcs,
>>>>>>>>> Julio
>>>>>>>>> *@juliobash*
>>>>>>>>> *Próximos cursos de Shell*
>>>>>>>>> *Cidade         Local Período*
>>>>>>>>> *Rio de Janeiro EDX <http://edx.srv.br/> 09 a 13/03/15*
>>>>>>>>> *São Paulo 4Linux
>>>>>>>>> <http://www.4linux.com.br/cursos/programacao-em-shell-script> 24 a 
>>>>>>>>> 28/11/14*
>>>>>>>>> Dou treinamento de *Shell* em qualquer cidade.
>>>>>>>>> Para mais detalhes, me mande um e-mail <address@hidden>.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Em 16 de janeiro de 2015 11:24, Alfredo Casanova
>>>>>>>>> address@hidden [shell-script] <address@hidden.
>>>>>>>>> br> escreveu:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Julio, o tail -f não mostrou nada.
>>>>>>>>>> Usei o cat mesmo com od -h, mas só consigo output com o driver
>>>>>>>>>> que encontrei rodando (http://pastebin.com/sJqAmFVT). Se ele não
>>>>>>>>>> estiver rodando, nada acontece.
>>>>>>>>>>
>>>>>>>>>> Então:
>>>>>>>>>>
>>>>>>>>>> $ cat /dev/hidraw3 | od -h
>>>>>>>>>> 0000000 0015 0000 0000 0300 0015 0000 0000 0300
>>>>>>>>>> *
>>>>>>>>>>
>>>>>>>>>> Ao levantar o LID, apareceu:
>>>>>>>>>>
>>>>>>>>>> 0057520 0015 0000 0000 0300 0017 0000 0000 0300
>>>>>>>>>> 0057540 0017 0000 0000 0300 0017 0000 0000 0300
>>>>>>>>>> *
>>>>>>>>>>
>>>>>>>>>> Apertei Fire:
>>>>>>>>>>
>>>>>>>>>> 0103240 0017 0000 0000 0300 0016 0000 0000 0300
>>>>>>>>>> 0103260 0016 0000 0000 0300 0017 0000 0000 0300
>>>>>>>>>> 0103300 0017 0000 0000 0300 0017 0000 0000 0300
>>>>>>>>>> *
>>>>>>>>>>
>>>>>>>>>> Fire Novamente:
>>>>>>>>>>
>>>>>>>>>> 0112100 0017 0000 0000 0300 0016 0000 0000 0300
>>>>>>>>>> 0112120 0016 0000 0000 0300 0017 0000 0000 0300
>>>>>>>>>> 0112140 0017 0000 0000 0300 0017 0000 0000 0300
>>>>>>>>>> *
>>>>>>>>>>
>>>>>>>>>> Lid Fechado:
>>>>>>>>>>
>>>>>>>>>> 0131700 0015 0000 0000 0300 0015 0000 0000 0300
>>>>>>>>>> *
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri Jan 16 2015 at 10:46:33 AM 'Julio C. Neves'
>>>>>>>>>> address@hidden [shell-script] <
>>>>>>>>>> address@hidden> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Experimente fazer um tail -f /dev/hidraw3 | od -h | tee
>>>>>>>>>>> /tmp/botao.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Abcs,
>>>>>>>>>>> Julio
>>>>>>>>>>> *@juliobash*
>>>>>>>>>>> *Próximos cursos de Shell*
>>>>>>>>>>> *Cidade         Local Período*
>>>>>>>>>>> *Rio de Janeiro EDX <http://edx.srv.br/> 09 a 13/03/15*
>>>>>>>>>>> *São Paulo 4Linux
>>>>>>>>>>> <http://www.4linux.com.br/cursos/programacao-em-shell-script> 24 a 
>>>>>>>>>>> 28/11/14*
>>>>>>>>>>> Dou treinamento de *Shell* em qualquer cidade.
>>>>>>>>>>> Para mais detalhes, me mande um e-mail <address@hidden>.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Em 15 de janeiro de 2015 16:03, Alfredo Casanova
>>>>>>>>>>> address@hidden [shell-script] <
>>>>>>>>>>> address@hidden> escreveu:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Mr. Bits, o que quero é o inverso: 'escutar' os eventos que o
>>>>>>>>>>>> periférico envia via USB e executar comandos de acordo com eles.
>>>>>>>>>>>>
>>>>>>>>>>>> No driver que encontrei em C, são 3 eventos: open lid, fire,
>>>>>>>>>>>> close lid.
>>>>>>>>>>>>
>>>>>>>>>>>> O dispositivo aparece em /dev/hidraw3. Um cat nele não mostra
>>>>>>>>>>>> nada, a não ser que o programa em C esteja rodando.
>>>>>>>>>>>>
>>>>>>>>>>>> Em qui, 15 de jan de 2015 15:13, MrBiTs address@hidden
>>>>>>>>>>>> [shell-script] <address@hidden> escreveu:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>>>>> Hash: SHA256
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> > Tenho um dispositvo usb aqui (http://dreamcheeky.com/big-re
>>>>>>>>>>>>> d-button) e achei até um driver escrito em C pra ele, que
>>>>>>>>>>>>> funciona.
>>>>>>>>>>>>> > Compilei com os comandos que queria e tá tudo OK. Só queria
>>>>>>>>>>>>> saber se existe alguma forma de fazer isso usando bash puro!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bash puro = comandos internos do interpretador. Se você usa um
>>>>>>>>>>>>> sed, um grep, um cut, já não é mais "bash puro".
>>>>>>>>>>>>>
>>>>>>>>>>>>> O que é "fazer isso"? Compilar os comandos que você queria?
>>>>>>>>>>>>> Não dá pra fazer em bash puro porque bash não tem compilador C.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Agora, se você quer controlar o dispositivo simplesmente via
>>>>>>>>>>>>> bash, tenta um echo 0>/dev/ttyUSB1 e veja o que acontece. De 
>>>>>>>>>>>>> repente,
>>>>>>>>>>>>> lendo o código C, você descobre quais são as instruções e
>>>>>>>>>>>>> manda os códigos via echo para o dispositivo. Eu faço echo xx >
>>>>>>>>>>>>> /dev/ttyUSB123 (onde por exemplo está minha impressora) e ela
>>>>>>>>>>>>> faz uns barulhos, moe umas folhas. Se eu souber exatamente os
>>>>>>>>>>>>> comandos de impressão, posso até fazê-la imprimir. É um belo
>>>>>>>>>>>>> exercício, mas nada mais.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - --
>>>>>>>>>>>>> echo
>>>>>>>>>>>>> 920680245503158263821824753325972325831728150312428342077412
>>>>>>>>>>>>> 537729420364909318736253880971145983128276953696631956862757
>>>>>>>>>>>>> 408858710644955909208239222408534030331747172248238293509539
>>>>>>>>>>>>> 472164571738870818862971439246497991147436431430964603600458
>>>>>>>>>>>>> 631758354381402352368220521740203494788796697543569807851284
>>>>>>>>>>>>> 795072334480481413675418412856581412376640379241258356436205
>>>>>>>>>>>>> 061541557366641602992820546646995466P
>>>>>>>>>>>>> | dc
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>>>>>>>>> Version: GnuPG v1
>>>>>>>>>>>>> Comment: Using GnuPG with Thunderbird -
>>>>>>>>>>>>> http://www.enigmail.net/
>>>>>>>>>>>>>
>>>>>>>>>>>>> iQEcBAEBCAAGBQJUt/VDAAoJEG7IGPwrPKWrGogH/3Ju0HhXuTa/mdyVmj+
>>>>>>>>>>>>> BvqEK
>>>>>>>>>>>>> F0nd1849P/Rna9jrIesGvaqOIeaP36B76d89w1mAaYcYCvvZFeyXgFixxKof
>>>>>>>>>>>>> vuSW
>>>>>>>>>>>>> u11uq7FaQDsdYndV173XTZU5aXPwoyCZFebHD/U8p6+iHhbhHBKrcT23KMIY
>>>>>>>>>>>>> 88+a
>>>>>>>>>>>>> xph57s4PN5JeBQJKmSdMa3HoltY/e85pelL//dbk/vpIh7tjovX2HT8y92m7
>>>>>>>>>>>>> 3DTB
>>>>>>>>>>>>> /AI5GcaXYCcAZTqKY+WnSjq1QBQ4cvoQN/uGyenUPzoQoydec2gLJDukaVkR
>>>>>>>>>>>>> 6k83
>>>>>>>>>>>>> byZwb1+1v+7UEogrc0Wh5lk41+MRi3qSMg0tL6Hqv2fiRI/ufZC5QmvI7f+
>>>>>>>>>>>>> v5EY=
>>>>>>>>>>>>> =FAG7
>>>>>>>>>>>>> -----END PGP SIGNATURE-----
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>       
>


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



reply via email to

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