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: Julio C. Neves
Subject: Re: [shell-script] Comandos em eventos recebidos pela USB
Date: Wed, 21 Jan 2015 12:45:16 -0200

O 0x08 é o backspace, e o 0x20 é o espaço. Então vamos voltar uma posição e escrever um branco em cima do último caractere:

$ echo -n 123; printf '\x08\x20:\n'
12 :

Usei os dois pontos só para mostrar que ficou um espaço em branco, mas acho que seria mais fácil de ver se trocassemos o 3 (de 123) por um zero (\x30 em hexa).

$ echo -n 123; printf '\x08\x30\n'
120
É isso?

Vc ainda tem os caracteres de conversão %u, %d, %x e %X para trabalhar em qq sistema de numeração

Abcs,
Julio
@juliobash
P
róximos cursos de Shell
Cidade         Local Período
Rio de Janeiro EDX 09 a 13/03/15
São Paulo 4Linux 24 a 28/11/14
Dou treinamento de Shell em qualquer cidade.
Para mais detalhes, me mande um e-mail.


Em 21 de janeiro de 2015 12:00, Fernando Mercês address@hidden [shell-script] <address@hidden> escreveu:
 

Alfredo, e aí, o que ele disse? A propósito não tem essa de código mais de um que do outro. Fizemos juntos mas o projeto é teu. :)

Excelente ideia de por no Github. Além de permitir que achem o script, o Github é imbatível pra colaboração. Qual o link?

@Julio, mas tem como conveter 0x8 para seu equivalente numérico e imprimível com o printf? Eu busquei mas não achei.

Abraços! 

Att,

Fernando Mercês

Em 21/01/2015, às 11:02, Alfredo Casanova address@hidden [shell-script] <address@hidden> escreveu:

 

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]