|
From: | Alfredo Casanova |
Subject: | Re: [shell-script] Comandos em eventos recebidos pela USB |
Date: | Tue, 20 Jan 2015 19:33:47 +0000 |
Agora está funcionando!
As vezes ele pára sem motivo, mas acho q pode ser algum pau por estarmos usando o dd pra arquivo. Segue o código:#!/bin/bashLID_CLOSED=21BUTTON_PRESSED=22LID_OPEN=23last=$LID_CLOSEDwhile truedoecho -ne "\x08\x00\x00\x00\x00\x00\x00\x02" > bufdd if=buf of=/dev/hidraw3 bs=8 count=1 conv=notrunc 2> /dev/nullrm -f bufdd if=/dev/hidraw3 of=buf bs=1 count=1 2> /dev/nullsiz=$(cat buf | wc -c)echo $siz[ $siz -eq 1 ] || continuestatus=$(head -c1 buf)status=$(echo -ne "$status" | hexdump -v -e '/1 "%d"')if [ $last -eq $LID_CLOSED -a $status -eq $LID_OPEN ]thenecho LID OPEN $last $statuselif [ $last -ne $BUTTON_PRESSED -a $status -eq $BUTTON_PRESSED ]thenecho FIRE $last $statuselif [ $last -ne $LID_CLOSED -a $status -eq $LID_CLOSED ]thenecho LID CLOSED $last $statusfilast=$statussleep 0.05doneOn Tue Jan 20 2015 at 4:21:43 PM Fernando Mercês address@hidden [shell-script] <address@hidden> wrote:Alfredo, você tem que ser fiel ao algoritmo em C...1) A $last é setada antes do loop.2) Esqueci de converter pra caracter, já que no bash nada é realmente número. Eu faria assim pra pegar já a representação em decimal:status=$(head -c1 buf)status=$(echo ne "$status" | hexdump -v -e '/1 "%d"')Aí você vai poder fazer [ $status -eq 8 ] normalmente.3) Os condicionais estão sob "else". Do jeito que você fez todos serão testados a cada iteração do loop.4) Ainda tem o sleep 0.02 no fim do loop.Abraços.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-20 16:11 GMT-02:00 Alfredo Casanova address@hidden [shell-script] <address@hidden.br>:bom, fiz uma boa e velha gambiarra pra converter os hexa pra decimal, até agora está assim:
#!/bin/bash LID_CLOSED=21 BUTTON_PRESSED=22 LID_OPEN=23 while true do echo -ne "\x08\x00\x00\x00\x00\x00\x00\x02" > buf dd if=buf of=/dev/hidraw3 bs=8 count=1 conv=notrunc rm -f buf dd if=/dev/hidraw3 of=buf bs=1 count=1 last=$LID_CLOSED siz=$(cat buf | wc -c) [ $siz -eq 1 ] || continue status=$(head -c1 buf) estado=$(echo $status | od -h | grep -Eo "0a[0-9]{2}" | cut -f2 -da) echo $estado status=$((16#$estado)) echo last: $last echo status: $status [ $last -eq $LID_CLOSED -a $status -eq $LID_OPEN ] && echo LID OPEN $last $status [ $last -ne $BUTTON_PRESSED -a $status -eq $BUTTON_PRESSED ] && echo FIRE $last $status [ $last -ne $LID_CLOSED -a $status -eq $LID_CLOSED ] && echo LID CLOSED $last $status last=$status doneA execução não está OK.Ele detecta o estado atual do botão (lid closed ou open) mas não atualiza com novos eventos.Executando com o lid aberto:$ ./redbutton1+0 records in1+0 records out8 bytes (8 B) copied, 0.00288873 s, 2.8 kB/s1+0 records in1+0 records out1 byte (1 B) copied, 0.0107175 s, 0.1 kB/s17last: 21status: 23LID OPEN 21 23e essa mensagem se repete várias vezes, até parar. Fechar o LID ou apertar Fire não dão nenhum retorno.executando com o lid fechado:$ ./sera1+0 records in1+0 records out8 bytes (8 B) copied, 0.00271552 s, 2.9 kB/s1+0 records in1+0 records out1 byte (1 B) copied, 0.008452 s, 0.1 kB/s15last: 21status: 211+0 records in1+0 records out8 bytes (8 B) copied, 0.00298281 s, 2.7 kB/s1+0 records in1+0 records out1 byte (1 B) copied, 0.00475965 s, 0.2 kB/s15last: 21status: 211+0 records in1+0 records out8 bytes (8 B) copied, 0.00303803 s, 2.6 kB/s1+0 records in1+0 records out1 byte (1 B) copied, 0.00621959 s, 0.2 kB/s15last: 21status: 211+0 records in1+0 records out8 bytes (8 B) copied, 0.00297728 s, 2.7 kB/s1+0 records in1+0 records out1 byte (1 B) copied, 0.00483426 s, 0.2 kB/s15last: 21status: 211+0 records in1+0 records out8 bytes (8 B) copied, 0.00281745 s, 2.8 kB/sfica assim parado, também não interage com os eventos do botão.On Tue Jan 20 2015 at 3:46:34 PM Alfredo Casanova <address@hidden> wrote: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=notrunc1+0 records in1+0 records out8 bytes (8 B) copied, 0.00300605 s, 2.7 kB/s$ cat buf[caractere truncado]$ cat buf | od -h0000000 0008 0000 0000 02000000010$ dd if=/dev/hidraw3 of=buf bs=1 count=11+0 records in1+0 records out1 byte (1 B) copied, 0.0108561 s, 0.1 kB/s$ siz=$(cat buf | wc -c)$ echo $siz1$ status=$(head -c1 buf)$ echo $status[caractere truncado]$ echo $status | od -h0000000 0a150000002assim é impossível testarOn 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.br> 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:
while (1) { memset(buf, 0x0, sizeof(buf)); buf[0] = 0x08; buf[7] = 0x02; 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=notruncDepois ele lê de volta 8 bytes do device:
memset(buf, 0x0, sizeof(buf)); res = read(fd, buf, 8);O que poderia ser feito com:$ dd if=/dev/hidraw3 of=buf bs=8 count=1Mas 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=1E então vêm os testes:
if (res >= 0) { if (prior == LID_CLOSED && buf[0] == LID_OPEN) { printf("Lid Aberto?\n"); fflush(stdout); } else if (prior != BUTTON_PRESSED && buf[0] == BUTTON_PRESSED) { printf("Fire!!\n"); system("cvlc --play-and-exit /home/atcasanova/Dropbox/atila.mp3"); fflush(stdout); } else if (prior != LID_CLOSED && buf[0] == LID_CLOSED) { printf("Lid Closed!"); fflush(stdout); } 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_CLOSEDsiz=$(wc -c buf | cut -d' ' -f1)[ $siz -eq 1 ] || continuestatus=$(head -c1 buf)[ $last -eq 21 -a $status -eq 22 ] && cvlc...# outras condiçõeslast=$statusE 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 bytesbuf=$(head -c8 /dev/hidraw3)# escrever 8 os bytes lidosecho -ne "$buf" /dev/hidraw3Duvidas 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.br>:Fernando, já postei o código do driver, mas aí vai novamente:
http://pastebin.com/sJqAmFVTOn Sun Jan 18 2015 at 11:42:14 AM 'Julio C. Neves' address@hidden [shell-script] <address@hidden.br> 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!Em 18 de janeiro de 2015 09:12, Fernando Mercês address@hidden [shell-script] <address@hidden.br> 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/ls0000000 457f 464c 0102 0001 0000 0000 0000 00000000020$ hexdump -n16 /bin/ls0000000 457f 464c 0102 0001 0000 0000 0000 00000000010Mesma coisa. Agora, se você chamar o hexdump pelo seu symlink hd, olha que legal:$ hd -n16 /bin/ls00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|00000010Eu 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/ls00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|Abraços!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.br>: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)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 -h0000000 0015 0000 0000 0300 0015 0000 0000 0300*Ao levantar o LID, apareceu:0057520 0015 0000 0000 0300 0017 0000 0000 03000057540 0017 0000 0000 0300 0017 0000 0000 0300*Apertei Fire:0103240 0017 0000 0000 0300 0016 0000 0000 03000103260 0016 0000 0000 0300 0017 0000 0000 03000103300 0017 0000 0000 0300 0017 0000 0000 0300*Fire Novamente:0112100 0017 0000 0000 0300 0016 0000 0000 03000112120 0016 0000 0000 0300 0017 0000 0000 03000112140 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.br> wrote:Experimente fazer um tail -f /dev/hidraw3 | od -h | tee /tmp/botao.Em 15 de janeiro de 2015 16:03, Alfredo Casanova address@hidden [shell-script] <address@hidden.br> 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.br> escreveu:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> Tenho um dispositvo usb aqui (http://dreamcheeky.com/big-red-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
920680245503158263821824753325972325831728150312428342077412537729420364909318736253880971145983128276953696631956862757408858710644955909208239222408534030331747172248238293509539472164571738870818862971439246497991147436431430964603600458631758354381402352368220521740203494788796697543569807851284795072334480481413675418412856581412376640379241258356436205061541557366641602992820546646995466P
| dc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCAAGBQJUt/VDAAoJEG7IGPwrPKWrGogH/3Ju0HhXuTa/mdyVmj+BvqEK
F0nd1849P/Rna9jrIesGvaqOIeaP36B76d89w1mAaYcYCvvZFeyXgFixxKofvuSW
u11uq7FaQDsdYndV173XTZU5aXPwoyCZFebHD/U8p6+iHhbhHBKrcT23KMIY88+a
xph57s4PN5JeBQJKmSdMa3HoltY/e85pelL//dbk/vpIh7tjovX2HT8y92m73DTB
/AI5GcaXYCcAZTqKY+WnSjq1QBQ4cvoQN/uGyenUPzoQoydec2gLJDukaVkR6k83
byZwb1+1v+7UEogrc0Wh5lk41+MRi3qSMg0tL6Hqv2fiRI/ufZC5QmvI7f+v5EY=
=FAG7
-----END PGP SIGNATURE-----
[Prev in Thread] Current Thread [Next in Thread]
- Re: [shell-script] Comandos em eventos recebidos pela USB, (continued)
- Re: [shell-script] Comandos em eventos recebidos pela USB, Alfredo Casanova, 2015/01/16
- Re: [shell-script] Comandos em eventos recebidos pela USB, Fernando Mercês, 2015/01/18
- Re: [shell-script] Comandos em eventos recebidos pela USB, Julio C. Neves, 2015/01/18
- Re: [shell-script] Comandos em eventos recebidos pela USB, Alfredo Casanova, 2015/01/19
- Re: [shell-script] Comandos em eventos recebidos pela USB, Fernando Mercês, 2015/01/20
- Re: [shell-script] Comandos em eventos recebidos pela USB, Alfredo Casanova, 2015/01/20
- Re: [shell-script] Comandos em eventos recebidos pela USB, Alfredo Casanova, 2015/01/20
- Re: [shell-script] Comandos em eventos recebidos pela USB, Alfredo Casanova, 2015/01/20
- Re: [shell-script] Comandos em eventos recebidos pela USB, Fernando Mercês, 2015/01/20
- Re: [shell-script] Comandos em eventos recebidos pela USB, Alfredo Casanova, 2015/01/20
- Re: [shell-script] Comandos em eventos recebidos pela USB, Alfredo Casanova <=
- Re: [shell-script] Comandos em eventos recebidos pela USB, Alfredo Casanova, 2015/01/20
- Re: [shell-script] Comandos em eventos recebidos pela USB, Fernando Mercês, 2015/01/20
- Re: [shell-script] Comandos em eventos recebidos pela USB, Alfredo Casanova, 2015/01/20
- Re: [shell-script] Comandos em eventos recebidos pela USB, Alfredo Casanova, 2015/01/20
- Re: [shell-script] Comandos em eventos recebidos pela USB, Fernando Mercês, 2015/01/20
- Re: [shell-script] Comandos em eventos recebidos pela USB, Alfredo Casanova, 2015/01/20
- Re: [shell-script] Comandos em eventos recebidos pela USB, Alfredo Casanova, 2015/01/20
- Re: [shell-script] Comandos em eventos recebidos pela USB, Fernando Mercês, 2015/01/20
- Re: [shell-script] Comandos em eventos recebidos pela USB, Alfredo Casanova, 2015/01/20
- Re: [shell-script] Comandos em eventos recebidos pela USB, Julio C. Neves, 2015/01/20
- Prev by Date: Re: [shell-script] Comandos em eventos recebidos pela USB
- Next by Date: Re: [shell-script] Comandos em eventos recebidos pela USB
- Previous by thread: Re: [shell-script] Comandos em eventos recebidos pela USB
- Next by thread: Re: [shell-script] Comandos em eventos recebidos pela USB
- Index(es):