Ir ao conteúdo
  • Comunicados

    • Gabriel Torres

      Seja um moderador do Clube do Hardware!   12-02-2016

      Prezados membros do Clube do Hardware, Está aberto o processo de seleção de novos moderadores para diversos setores ou áreas do Clube do Hardware. Os requisitos são:   Pelo menos 500 posts e um ano de cadastro; Boa frequência de participação; Ser respeitoso, cordial e educado com os demais membros; Ter bom nível de português; Ter razoável conhecimento da área em que pretende atuar; Saber trabalhar em equipe (com os moderadores, coordenadores e administradores).   Os interessados deverão enviar uma mensagem privada para o usuário @Equipe Clube do Hardware com o título "Candidato a moderador". A mensagem deverá conter respostas às perguntas abaixo:   Qual o seu nome completo? Qual sua data de nascimento? Qual sua formação/profissão? Já atuou como moderador em algo outro fórum, se sim, qual? De forma sucinta, explique o porquê de querer ser moderador do fórum e conte-nos um pouco sobre você.   OBS: Não se trata de função remunerada. Todos que fazem parte do staff são voluntários.

wBB

Membros Plenos
  • Total de itens

    81
  • Registro em

  • Última visita

  • Qualificações

    N/D

Reputação

16

Informações gerais

  • Cidade e Estado
    CAMPINAS/SP
  • Sexo
    Masculino
  1. Pessoal, estou com um circuito pronto e funcionando, com o qual troco informações pelo celular via Bluetooth. No circuito eu uso um shield HC-06 para ter o Bluetooth disponível e o modo de operação é o "Bluetooth Classic", pois preciso de comunicação contínua do meu celular com o circuito eletrônico (até onde entendo o modo "Low Energy" não serviria). PROBLEMA: Este circuito está instalado em um equipamento maior, num ponto onde a alimentação disponível tem corrente limitada e é muito baixa para suportar o uso que faço do Bluetooth. Sim, eu poderia puxar uma alimentação independente e manter o funcionamento desejado, porém isso implicaria em uma possível perda de garantia do tal "equipamento maior" e por isso preciso usar a alimentação disponível. PERGUNTA: Existe alguma maneira de diminuir o consumo do Bluetooth e ainda assim manter a comunicação contínua que preciso? Obrigado!
  2. Pessoal, estou começando a mexer com os dois módulos ESP, o ESP8266 e o mais novo, o ESP32, e para isso dei start com ESP8266 na IDE Arduino, instalada no Windows 10. Aparentemente a IDE instalou normalmente, incluindo os drivers. Também consegui baixar o pacote de módulos compatíveis com a IDE para ESP8266 (que são uns 150MB), o dispositivo reconheceu na COM3, conectado via USB, etc. Enfim, parece estar tudo OK, exceto pelo fato de não ser reconhecido o ESP8266 dentro da IDE do Arduino, consequentemente não connectam. Ao acessar o menu Ferramentas - Obter informações da Placa, dá a mensagem de "Placa não identificada". Além disso não é possível compilar o programa base. No "Gerenciador de Dispositivos" do Windows ele é reconhecido como "Silicon Labs CP210x USB Bridge (COM3)". Alguém sabe o que pode estar ocorrendo? Obrigado.
  3. Acho que não está funcionando, pois provavelmente você está usando a parte baixa da variável do PORTB e pelo que verifiquei no manual desse PIC (na página 67), os primeiros quatro bits do PORTB (os bits menos significativos) não estão implementados. Então se você atribuir o valor de, por exemplo 10 decimal ao PORTB, você estará setando 0b00001010. Isso significa que não vai acontecer nada mesmo, pois esses bits não tem função. Já para usar a parte alta do PORTB (bits mais significativos), você precisaria setar o valor 0b10100000 ou 0b10101111 para conseguir o mesmo "10 decimal" (tanto faz, pois os quatro primeiros bits não fazem nada como já disse). Também não vi outros registradores relevantes para o que você precisa, que estejam relacionados com o PORTB (página 73); Imagino que isso seja o que você precisa: void main() { TRISB = 0x00; // ou 0b00000000 PORTB = 0x00; // ou 0b00000000 unsigned char MeuContador = 1; while (1) { // Mantém a contagem entre 1 e 15 if (MeuContador >= 15) { MeuContador = 1; } // Seta os valores na parte alta de PORTB PORTB = MeuContador << 4; MeuContador++; Delay_ms(1000); } }
  4. hehehe... Obrigado pela atenção. Concordo com você que está mesmo confuso... desculpe. Eu já entendi como funciona e já resolvi o problema:: Considerando dois dispositivos Bluetooth, dispositivo A e dispositivo B, o dispositivo A abre uma conexão com B e envia dados à B (pergunta), assim como B devolve dados a A (resposta), ambos usando a mesma conexão inicialmente aberta por A. Minha dúvida era: Quando A abre uma conexão com B e lhe envia dados, o dispositivo B deve responder usando esta mesma conexão ou responderá por meio de uma conexão independente? A razão de minha dúvida é que, ambos os dispositivos, A e B, podem ser Clientes ou Servidores Bluetooth. Porém, quem se comportará como Cliente ou Servidor dependerá exclusivamente de qual dispositivo abriu a conexão, sendo considerado Cliente aquele que abriu a conexão. Como nunca mexi nem estudei nada de Bluetooth (agora dei uma estudadinha...), imaginei que a comunicação deveria ser unidirecional, ou seja, uma conexão aberta pelo Cliente só serviria para enviar dados, portanto precisaria (segundo o que imaginei inicialmente) que existisse uma segunda conexão para devolver as respostas no sentido contrário. Pensando da forma como expliquei acima, eu estava monitorando o Serviço Servidor Bluetooth de meu aplicativo e esperando que fosse aberta uma nova conexão para o dispositivo "B" me devolver as respostas, mas isso nunca ocorria.... Resolvido!
  5. Pessoal, preciso estabelecer uma comunicação via Bluetooth com um circuito eletrônico que montei e estou com uma dúvida sobre a conexão Bluetooth. Criei um circuito com PIC e usei um shield HD-06 para bluetooth. Criei um programa desktop para testar a comunicação Bluetooth e já consegui enviar a receber informações. Quando abro uma conexão Bluetooth a partir de meu programa de testes no computador e então conecto ao dispositivo eletrônico, consigo enviar E TAMBÉM RECEBER dados de resposta pela mesma conexão. No meu programa de testes também estou criando uma conexão Servidor, ou seja, um SocketServer de Bluetooth para ficar "escutando" possíveis conexões de entrada no computador. DÚVIDA: As "respostas" do meu dispositivo eletrônico não deveriam vir através de meu servidor socket Bluetooth em lugar de serem recebidas por meio da conexão que abri anteriormente para fazer "perguntas" a este mesmo dispositivo eletrônico? Não sei qual a forma correta de gerenciamento das conexões Bluetooth... Obrigado
  6. Realmente existem diferenças na interpretação de código em um ou outro ambiente. Por exemplo, se você usar o registrador PORTC para setar ou resetar um bit no MPLab, vai funcionar tal como você sugeriu. Já no MikroC, que é o que estou usando, o datasheet é interpretado de forma mais rígida. Dessa forma, o MikroC não vai dar um "jeitinho" para fazer as coisas funcionarem caso deixemos de seguir o datasheet a risca. Pelo menos entendo que é isso que ocorre (baseado em minha pouca experiência). valeu!
  7. Neste link abaixo foi onde encontrei até agora a única explicação para essa alteração da família 16F para a 18F, em relação a existência desses dois registradores de inputs e outputs separados nos PORTx da família 18F (anexei um PDF da página tb para documentar aqui no forum). https://download.mikroe.com/documents/compilers/mikroc/pic/help/rmw.htm Read_Write_18FXX Family.pdf
  8. Grato Isadora, eu já havia tentado isso e não funcionou também. Essa família de PICs tem um registrador PORTC para INPUTs e outro registrador LATC para OUTPUTs, conforme indicação do datasheet. adicionado 10 minutos depois Acabei de descobrir o problema. A configuração "SOSC Power Selection Mode" estava em "High Power SOSC circuit selected" e deveria estar em "Digital (SCLKI) mode". Essa alteração fez com que "LATC.B1 = 1" funcionasse. Ainda não sei quais as implicações dessa mudança... Obrigado!
  9. Estou querendo apenas setar o bit 1 do PORTC num PIC18F46K80 (44 pinos), mas acho que estou deixando escapar alguma configuração (o bit 2 por exemplo, não tem problema e funciona normal). Estou usando o oscilador interno do microcontrolador e MikroC como IDE. Gostaria de uma orientação se está correto o que estou fazendo ou se falta algo? void main() { T0CON = 0x82; // 0b10000010 Habilita contagem do Timer0 // Seta Timer0 com 8bits // Clock proveniente do ciclo de máquina interno // Incrementa na borda de subida do pino T0CKI (indiferente neste caso) // Habilita prescaler // Configura prescaler em 1:8 INTCON = 0xE0; // 0b11100000 Habilita a interrupção global; // Habilita periféricos; // Habilita estouro do Timer0; // Zera flag de estouro do Timer0 (bit 2) PMD0 = 0xFF; // Desabilita os comparadores TRISC = 0x00; // Configura todo o PORTC como saídas LATC.B1 = 1; // Seta o bit 1 do PORTC }
  10. Sim, tranquilo. Tinha ficado claro. ah ok... Com pouca experiência no assunto é mais difícil observar, mas vou ficar atento. Valeu!
  11. Obrigado @Isadora Ferraz . Não que haja desconfiança no hw... É que realmente não sei se é necessária essa verificação adicional. Até pensei em colocar um contador regressivo tal como você indicou, mas imaginei que não fosse a melhor opção. grato!
  12. Pessoal, montei no MikroC umas rotinas para executar um simples Echo via UART1 e mostrar minha dúvida. Nessas rotinas verifico a interrupção por recepção de dados na UART1 em um PIC18F46K80 e então retransmito via UART1 o mesmo dado recebido. Na rotina de "UART1_TX_BuffTest" fico verificando a flag que indica se já foi enviado o dado pela UART1. DÚVIDA: Precisa existir um Timeout nesta rotina "UART1_TX_BuffTest" para evitar que por um eventual problema o programa fique preso aí? Se sim, como faço esse Timeout? void UART1_TX_BuffTest() { //Aguarda buffer esvaziar while(!TXSTA1.TRMT); } void my_echo() { // Devolve o caractere digitado TXREG1 = RCREG1; UART1_TX_BuffTest(); } void interrupt(void) { // Verifica se houve interrupção pela UART1 if (PIR1.RC1IF) { // Limpa a flag de interrupção do Receive da UART1 PIR1.RC1IF = 0x00; // Executa função para transmitir o caracter que foi recebido my_echo(); } }
  13. Realmente não encontrei nada a respeito, apesar de ver em muitos lugares o pessoal usando o tal delay...
  14. Olá Pessoal! Estou precisando escrever na memória Flash de um PIC18F46K80 e estou com dúvida em relação ao tempo de delay para escrita. Já ví em alguns lugares que na EEPROM, por exemplo, o pessoal coloca algo em torno de 10ms de delay logo após a função de escrita (para microntroladores da família 16F e 18F). Supostamente para garantir a correta escrita. Penso que para escrita na memória Flash deva existir algo parecido também, mas não estou encontrando no datasheet essas informações nem da Flash nem da EEPROM. PERGUNTA: afinal, é ou não é necessário este delay após executar a escrita da memória Flash (ou EEPROM também)? Obrigado!
  15. Apenas reportando a solução, caso alguém se depare com o mesmo problema: 1) Para ligar o Beaglebone ao módulo RTC, os quais trabalham com níveis diferentes de tensão, utilizei um "conversor de nível lógico bidirecional 3.3V => 5V" (podem ser o módulo e as conexões que o test man*~ indicou); 2) Acertar a data, hora e o timezone do sistema, que no meu caso é o Debian, pode variar de um caso para outro. Aqui foi o que segue, mas se reiniciar o sistema isso não manterá os valores corretos (precisa automatizar o processo): timezone: root@beaglebone:~# dpkg-reconfigure tzdata data e hora: root@beaglebone:~# ntpdate -u 200.20.186.75 3) Já conectado o dispositivo I2C no Beaglebone, identificar o endereço deste no bus I2C: IMPORTANTE: Para versões mais recentes do Debian o final do comando é "2". Em outras menores que a versão 8, o final do comando é "1": root@beaglebone:/# i2cdetect -y -r 2 Mostrará algo parecido com isso: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 -- -- -- UU UU UU UU -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- 4) Este número "68" (que está em hexadecimal) é o endereço do dispositivo RTC. Setar o novo dispositivo: echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-2/new_device IMPORTANTE: Nas versões do Debian onde o comando do item 3 for de final "1", o comando do item 4 deverá ter a parte "/i2c-2/" alterada para "/i2c-1". 5) Confirmar como o dispositivo foi identificado no sistema: root@beaglebone:~# ls -la /dev/rtc* Vai mostrar algo parecido com isso: lrwxrwxrwx 1 root root 4 May 21 2016 /dev/rtc -> rtc0 crw------- 1 root root 254, 0 May 21 2016 /dev/rtc0 Neste caso foi identificado como "rtc0". 6) Fazendo a escrita do novo valor de data e hora do sistema no novo dispositivo (rtc0 ou rtcX, conforme o caso do item anterior): root@beaglebone:~# hwclock -w -f /dev/rtc0 7) Pronto. O RTC está atualizado e basta ler o valor de data e hora setado nele: root@beaglebone:~# hwclock -r -f /dev/rtc0 Um obrigado ao @_xyko_ e principalmente ao @test man*~ pela ajuda novamente!

Sobre o Clube do Hardware

No ar desde 1996, o Clube do Hardware é uma das maiores, mais antigas e mais respeitadas publicações sobre tecnologia do Brasil. Leia mais

Direitos autorais

Não permitimos a cópia ou reprodução do conteúdo do nosso site, fórum, newsletters e redes sociais, mesmo citando-se a fonte. Leia mais

×