wBB

Bluetooth Low Energy no ESP32: Veja este vídeo:

Agora que você conseguiu jogar na porta serial o dados lidos no sensor, então você precisará transmitir esses dados para seu app/smartphone/PC. Existem algumas formas de fazer isso: 1) Via Bluetooth Low Energy (ou apenas BLE) que é um dos meios de comunicação com o ESP32 (este módulo não disponibiliza o Bluetooth Classic). Por esse meio você poderá estabelecer a comunicação direta entre o smartphone e o ESP32, sem equipamentos intermediários; 2) Via Wifi: por este meio de comunicação você pode estabelecer a conexão entre o smartphone e o ESP usando um roteador para intermediar essa conunicação, ou então, você pode configurar o ESP32 como Access Point, fazendo com que o smartphone se conecte ao ESP diretamente; 3) Via cabo: É possível comunicar-se com o ESP32 via cabo USB, que seria mais comum caso você quisesse criar um aplicativo que rode em PC, evitando assim a necessidade de comunicação sem fio. Dê uma pesquisada nestes três casos. É uma pesquisa meio longa, tem muito material, mas também tem muitos exemplos prontos. Considere que boa parte dos exemplos usados para ESP8266 (muito mais popular que o ESP32), servirá também para seu caso.

Foi como eu disse... Você tem que ir por partes e não é isso que você está nos mostrando em suas dúvidas. Em qual ambiente de desenvolvimento você está programando o ESP32? PlatformIO? Arduino? Usando C numa IDE como Eclipse? Usando Python? Você conseguiu fazer o ESP32 ler o valor que o sensor está disponibilizando? Se sim, onde você viu o valor? No monitor da serial do Arduino (supondo que você esteja usando Arduino)? O valor varia de quanto até quanto? Ajude a galera a te ajudar!

Já vi esse problema de comunicação ocorrer por alguns motivos: 1) Antivirus atrapalhando na compilação do programa e gerando timeout (McAfee no meu caso). Após desabilitar o antivirus, funcionou; 2) Driver com problema ou incorreto. Após reinstalar o driver tudo funcionou OK; 3) Se você estiver ligando o ESP32 (ou ESP8266 também) com alimentação externa e não apenas via USB, coloque um capacitor de uns 10uF entre o GND e o VIN.

Você tem que informar por partes o que você quer. Pelo que pude ver, você não tem nenhuma parte pronta de seu projeto e não sabe por onde começar. Então sugiro você começar pelo que foi informado no título do tópico (e apenas o que está relacionado com o título do tópico). Qual é o seu real problema com ESP32?

Já resolvi. Era uma problema com o de driver que tinha sido comprometido ou instalado indevidamente em alguma das últimas atualizações do Windows 10. Obrigado.

1- Conectei APENAS um computador ao roteador via Wifi (certeza, apenas um computador e mais nada); 2- Conectei o roteador ao modem via cabo; 3- Abri alguns sites de teste de velocidade: http://www.brasilbandalarga.com.br https://www.minhaconexao.com.br/ http://velocidade.algartelecom.com.br/ https://fast.com/pt/ http://www.copeltelecom.com/site/speedtest/ etc.; 4- Executei o teste oferecido por cada um destes sites; 5- Repeti o processo com o celular (sim, certeza que agora só estava conectado ao roteador);

Os testes foram feitos sempre via wireless/wifi (pra falar a verdade meu notebook nem tem entrada ethernet e o celular não tem outra opção mesmo).

Pessoal, gostaria de descobrir o que (ou qual programa) está consumindo minha banda larga. A situação é a seguinte: tenho uma conexão de 15MB com um roteador e apenas um notebook com Windows 10 conectado a este roteador (não tem mais nada conectado, só um único notebook). Nos meus testes, quando verifiquei a velocidade de conexão usando apenas o notebook, a velocidade chegava a 7MB. Porém, se eu verificar a velocidade usando o celular (agora apenas o celular conectado ao roteador), aí consigo alcançar os 15MB esperados. Como faço para detectar no meu notebook o que está derrubando ou consumindo minha conexão?

Felipe, obrigado pelas informações. O chip SN75176 que estou usando, diferente dessa da imagem de resposta (que obtive na resposta de outro usuário em outro site) nem precisa de resistores, ao menos para minha aplicação. Depois de verificar melhor e fazer outros testes percebi que era necessário apenas o capacitor de 100nF entre os terminais do chip RS485. Aliás, foi uma falha minha, pois no próprio datasheet do chip está a indicação desse capacitor. Obrigado

Resolvido. Acrescentei resistores à saída do RS485 conforme a imagem anexa (apenas em uma das placas) e também coloquei um capacitor cerâmico de 100nF direto nos terminais do chip das duas placas. Créditos da resposta

Pessoal, estou desenvolvendo um circuito usando NodeMCU ESP8266 12E com comunicação RS485. A comunicação RS232 está funcionando perfeitamente quando ligo um circuito ao outro (são duas placas iguais ao esquema eletrônico anexo), ou seja, tudo que é enviado de uma placa para outra é recebido corretamente (nos dois sentidos) ao conectar os RxTx das placas. Ao ligar a comunicação RS485 uso o pino D8 (GPIO15) do ESP8266 como bit de controle da transmissão de dados conforme indicado no esquema. PLATAFORMA ARDUÍNO. PROBLEMA: Ao colocar para funcionar a comunicação RS485 conforme indicado no esquema, a placa que envia os dados está transmitindo tudo corretamente. Porém, na placa receptora coloquei um debug para saber o que está recebendo e descobri que está vindo um caractere ZERO a mais no início do frame. Exemplo: Bytes ENVIADOS pela PLACA 1 no frame de teste: 0x21 0x06 0x00 0x0A 0x00 0x14 0xAE 0xA7 Bytes RECEBIDOS pela PLACA 2: 0x00 0x21 0x06 0x00 0x0A 0x00 0x14 0xAE 0xA7 IMPORANTE: Quando eu reinicio a placa receptora (PLACA 2 em meu exemplo), o frame recebido vem sempre correto. Do segundo em diante vem com esse caractere a mais no início. Alguém tem ideia do que pode ser?

Já resolvi. Implementei uma rotina simplificada do protocolo Modbus RTU, apenas com as funções necessárias. Seguem abaixo os dois arquivos do código do protocolo e um arquivo de exemplo com Arduino (funciona no ESP8266). //============================================================================== // ModbusRTU.cpp //============================================================================== /*------------------------------------------------------------------------------- COMUNICAÇÃO MODBUS RTU Descrição: Implementação parcial do protocolo de cominicação Modbus RTU. Funções implementadas: 1) Function 03 (03 hex): Read Holding Registers 2) Function 06 (06 hex): Write Single Register 3) Function 16 (10 hex): Write Multiple Registers REFERÊNCIAS: 1) http://www.modbustools.com/modbus.html 2) http://modbus.org/docs/Modbus_over_serial_line_V1_02.pdf -------------------------------------------------------------------------------*/ #include "modbusRTU.h" /*============================================================================== Function : CRC_16 Descrição : Executa o cálculo do CRC16 sobre os dados passados no parâmetro. Parâmetros: nData : Ponteiro para os dados sobre os quais o CRC16 será calculado; wLength: Quantidade de dados (em bytes) que serão processados no cálculo. Retorno : Valor do CRC calculado. =========================================================== ===================*/ unsigned int CRC_16(const unsigned char *nData, unsigned int wLength) { unsigned char nTemp; unsigned int wCRCWord = 0xFFFF; while (wLength--) { nTemp = *nData++ ^ wCRCWord; wCRCWord >>= 8; wCRCWord ^= wCRCTable[nTemp]; } return wCRCWord; } /*============================================================================== Function : ModbusRTU_Pack Descrição : Faz a interpretação de mensagens Modbus RTU recebidas e também o empacotamento de mensagens Modbus RTU. Parâmetros: MBBuff : Ponteiro para o array que representa o buffer original, proveniente da rotina chamadora; MBHoldingReg : Ponteiro para o array dos registradores Modbus. Retorno : >0 : SUCESSO = Tamanho da mensagem a ser transmitida via TCP/IP. =0 : Erro ou não há mensagem a ser processada como resposta. ==============================================================================*/ unsigned char ModbusRTU_Pack(unsigned char *MBBuff, unsigned int *MBHoldingReg) { unsigned int DataByteLength; unsigned int RegisterStart; unsigned int RegistersCount; unsigned int MessageLength; unsigned int CRC_Ref; unsigned char DeviceAddr; unsigned char MB_Function; // Seleciona os parâmetros da mensagem de Request DeviceAddr = MBBuff[MB_RTU_DEV_ADDR]; MB_Function = MBBuff[MB_RTU_FUNC]; RegisterStart = (MBBuff[MB_RTU_REGISTER_START] << 8) + MBBuff[MB_RTU_REGISTER_START +1]; RegistersCount = (MBBuff[MB_RTU_REGISTER_COUNT] << 8) + MBBuff[MB_RTU_REGISTER_COUNT +1]; // Os devices começam a partir do valor "1" if (DeviceAddr == 0) { return 0; } if (RegistersCount > MB_MAX_HOLDING_REGISTER) { return 0; } switch(MB_Function) { case MB_FC_NONE: MessageLength = 0; break; case MB_FC_READ_REGISTERS: // 03 Read Holding Registers // Verifica se é válido o CRC da mensagem de Request CRC_Ref = (MBBuff[MB_RTU_CRC +1] << 8) + MBBuff[MB_RTU_CRC]; if (CRC_Ref != CRC_16(MBBuff, 6)) { return 0; } // Empacota a resposta para o resquet corrente DataByteLength = RegistersCount * 2; MBBuff[MB_RTU_DEV_ADDR] = DeviceAddr; MBBuff[MB_RTU_FUNC] = MB_Function; MBBuff[MB_RTU_BYTE_COUNT] = DataByteLength; // Seta na resposta os valores atuais dos registradores for (int i = 0; i < RegistersCount; i++) { MBBuff[ MB_RTU_RESPONSE_DATA + i * 2] = (MBHoldingReg[RegisterStart + i] >> 8) & 0xFF; MBBuff[(MB_RTU_RESPONSE_DATA + 1) + i * 2] = MBHoldingReg[RegisterStart + i] & 0xFF; } // Calcula o CRC16 #define HEADER_DATA_READ 3 CRC_Ref = CRC_16(MBBuff, HEADER_DATA_READ + DataByteLength); // "3" = 3 bytes do cabeçalho MBBuff[HEADER_DATA_READ + DataByteLength] = CRC_Ref & 0xFF; MBBuff[HEADER_DATA_READ + DataByteLength +1] = (CRC_Ref >> 8) & 0xFF; MessageLength = HEADER_DATA_READ + DataByteLength + MB_RTU_CRC_LEN; break; case MB_FC_WRITE_REGISTER: // 06 Write Holding Register // Verifica se é válido o CRC da mensagem de Request CRC_Ref = (MBBuff[MB_RTU_CRC +1] << 8) + MBBuff[MB_RTU_CRC]; if (CRC_Ref != CRC_16(MBBuff, 6)) { return 0; } // Seta o registrador com o novo valor recebido no request MBHoldingReg[RegisterStart] = (MBBuff[MB_RTU_S_WRITE_DATA_START] << 8) + MBBuff[MB_RTU_S_WRITE_DATA_START +1]; // Resposta: a resposta é um "echo" do request, que tem sempre tamanho "8" MessageLength = 8; break; case MB_FC_WRITE_MULTIPLE_REGISTERS: // 16 Write Holding Registers // Verifica se é válido o CRC da mensagem de Request CRC_Ref = (MBBuff[MB_RTU_REGISTER_COUNT + 2 + 1 + RegistersCount * 2 + 1] << 8) + MBBuff[MB_RTU_REGISTER_COUNT + 2 + 1 + RegistersCount * 2]; if (CRC_Ref != CRC_16(MBBuff, MB_RTU_REGISTER_COUNT + 2 + 1 + RegistersCount * 2)) { return 0; } // Seta os registradores com os novos valores recebidos no request for (int i = 0; i < RegistersCount; i++) MBHoldingReg[RegisterStart + i] = (MBBuff[MB_RTU_M_WRITE_DATA_START + i * 2] << 8) + MBBuff[(MB_RTU_M_WRITE_DATA_START +1) + i * 2]; // Empacota a resposta para o resquet corrente MBBuff[MB_RTU_DEV_ADDR] = DeviceAddr; MBBuff[MB_RTU_FUNC] = MB_Function; MBBuff[MB_RTU_REGISTER_START] = (RegisterStart >> 8) & 0xFF; MBBuff[MB_RTU_REGISTER_START +1] = RegisterStart & 0xFF; MBBuff[MB_RTU_REGISTER_COUNT] = (RegistersCount >> 8) & 0xFF; MBBuff[MB_RTU_REGISTER_COUNT +1] = RegistersCount & 0xFF; // Calcula o CRC16 #define WRITE_ANS_LENGTH 6 CRC_Ref = CRC_16(MBBuff, WRITE_ANS_LENGTH); MBBuff[WRITE_ANS_LENGTH] = CRC_Ref & 0xFF; MBBuff[WRITE_ANS_LENGTH +1] = (CRC_Ref >> 8) & 0xFF; // O comprimento da resposta é sempre tamanho "8" MessageLength = 8; break; default: // Se nenhuma função Modbus tiver sido processada, então apenas retorna "0" // para indicar que não há nada para ser enviado via TCP/IP MessageLength = 0; break; } return MessageLength; } //============================================================================== // ModbusRTU.h //============================================================================== #ifndef DefModbus #define DefModbus //------------------------------------------------------------------------------ // FUNÇÕES RELACIONADAS AO PROTOCOLO MODBUS // Função de cálculo do CRC16 Modbus unsigned int CRC_16(const unsigned char *nData, unsigned int wLength); // Função de empacotamento de dados unsigned char ModbusRTU_Pack(unsigned char *MBBuff, unsigned int *MBHoldingReg); //------------------------------------------------------------------------------ // CONSTANTES DE COMUNICAÇÃO MODBUS #define MB_MAX_HOLDING_REGISTER 20 // maxHoldingRegister 20 #define MB_FC_NONE 0 #define MB_FC_READ_REGISTERS 3 //implemented #define MB_FC_WRITE_REGISTER 6 //implemented #define MB_FC_WRITE_MULTIPLE_REGISTERS 16 //implemented // MODBUS Error Codes #define MB_EC_NONE 0 #define MB_EC_ILLEGAL_FUNCTION 1 #define MB_EC_ILLEGAL_DATA_ADDRESS 2 #define MB_EC_ILLEGAL_DATA_VALUE 3 #define MB_EC_SLAVE_DEVICE_FAILURE 4 // MODBUS MBAP offsets // READ #define MB_RTU_DEV_ADDR 0 #define MB_RTU_FUNC 1 #define MB_RTU_REGISTER_START 2 #define MB_RTU_REGISTER_COUNT 4 #define MB_RTU_CRC 6 // WRITE SIMPLE #define MB_RTU_S_WRITE_DATA_START 4 // WRITE MULTIPLE #define MB_RTU_M_WRITE_DATA_START 7 #define MB_RTU_BYTE_COUNT 2 #define MB_RTU_RESPONSE_DATA 3 // MODBUS REF #define MB_RTU_CRC_LEN 2 //------------------------------------------------------------------------------ // TABELA CRC16 MODBUS static const unsigned int wCRCTable[] = { 0X0000, 0XC0C1, 0XC181, 0X0140, 0XC301, 0X03C0, 0X0280, 0XC241, 0XC601, 0X06C0, 0X0780, 0XC741, 0X0500, 0XC5C1, 0XC481, 0X0440, 0XCC01, 0X0CC0, 0X0D80, 0XCD41, 0X0F00, 0XCFC1, 0XCE81, 0X0E40, 0X0A00, 0XCAC1, 0XCB81, 0X0B40, 0XC901, 0X09C0, 0X0880, 0XC841, 0XD801, 0X18C0, 0X1980, 0XD941, 0X1B00, 0XDBC1, 0XDA81, 0X1A40, 0X1E00, 0XDEC1, 0XDF81, 0X1F40, 0XDD01, 0X1DC0, 0X1C80, 0XDC41, 0X1400, 0XD4C1, 0XD581, 0X1540, 0XD701, 0X17C0, 0X1680, 0XD641, 0XD201, 0X12C0, 0X1380, 0XD341, 0X1100, 0XD1C1, 0XD081, 0X1040, 0XF001, 0X30C0, 0X3180, 0XF141, 0X3300, 0XF3C1, 0XF281, 0X3240, 0X3600, 0XF6C1, 0XF781, 0X3740, 0XF501, 0X35C0, 0X3480, 0XF441, 0X3C00, 0XFCC1, 0XFD81, 0X3D40, 0XFF01, 0X3FC0, 0X3E80, 0XFE41, 0XFA01, 0X3AC0, 0X3B80, 0XFB41, 0X3900, 0XF9C1, 0XF881, 0X3840, 0X2800, 0XE8C1, 0XE981, 0X2940, 0XEB01, 0X2BC0, 0X2A80, 0XEA41, 0XEE01, 0X2EC0, 0X2F80, 0XEF41, 0X2D00, 0XEDC1, 0XEC81, 0X2C40, 0XE401, 0X24C0, 0X2580, 0XE541, 0X2700, 0XE7C1, 0XE681, 0X2640, 0X2200, 0XE2C1, 0XE381, 0X2340, 0XE101, 0X21C0, 0X2080, 0XE041, 0XA001, 0X60C0, 0X6180, 0XA141, 0X6300, 0XA3C1, 0XA281, 0X6240, 0X6600, 0XA6C1, 0XA781, 0X6740, 0XA501, 0X65C0, 0X6480, 0XA441, 0X6C00, 0XACC1, 0XAD81, 0X6D40, 0XAF01, 0X6FC0, 0X6E80, 0XAE41, 0XAA01, 0X6AC0, 0X6B80, 0XAB41, 0X6900, 0XA9C1, 0XA881, 0X6840, 0X7800, 0XB8C1, 0XB981, 0X7940, 0XBB01, 0X7BC0, 0X7A80, 0XBA41, 0XBE01, 0X7EC0, 0X7F80, 0XBF41, 0X7D00, 0XBDC1, 0XBC81, 0X7C40, 0XB401, 0X74C0, 0X7580, 0XB541, 0X7700, 0XB7C1, 0XB681, 0X7640, 0X7200, 0XB2C1, 0XB381, 0X7340, 0XB101, 0X71C0, 0X7080, 0XB041, 0X5000, 0X90C1, 0X9181, 0X5140, 0X9301, 0X53C0, 0X5280, 0X9241, 0X9601, 0X56C0, 0X5780, 0X9741, 0X5500, 0X95C1, 0X9481, 0X5440, 0X9C01, 0X5CC0, 0X5D80, 0X9D41, 0X5F00, 0X9FC1, 0X9E81, 0X5E40, 0X5A00, 0X9AC1, 0X9B81, 0X5B40, 0X9901, 0X59C0, 0X5880, 0X9841, 0X8801, 0X48C0, 0X4980, 0X8941, 0X4B00, 0X8BC1, 0X8A81, 0X4A40, 0X4E00, 0X8EC1, 0X8F81, 0X4F40, 0X8D01, 0X4DC0, 0X4C80, 0X8C41, 0X4400, 0X84C1, 0X8581, 0X4540, 0X8701, 0X47C0, 0X4680, 0X8641, 0X8201, 0X42C0, 0X4380, 0X8341, 0X4100, 0X81C1, 0X8081, 0X4040 }; #endif //============================================================================== // MB_RTU.ino //============================================================================== // EXEMPLO DE APLICAÇÃO DA FUNÇÃO MODBUS COM ARDUINO / ESP8266 #include "modbusRTU.h" // Buffer para comunicação serial via protocolo Modbus byte MBBuffer[260]; // Registradores Modbus unsigned int MBHoldingRegister[MB_MAX_HOLDING_REGISTER]; int i, MB_msg_length; void setup() { for (i = 0; i < MB_MAX_HOLDING_REGISTER; i++) MBHoldingRegister[i] = 0; Serial.begin(9600); Serial.println(""); Serial.println("Sistema Iniciado..."); } void loop() { int i = 0; while(Serial.available()){ MBBuffer[i] = Serial.read(); i++; } if (i > 0) { // Atualiza as informações nos registradores as informações recebidas na porta serial MB_msg_length = ModbusRTU_Pack(MBBuffer, MBHoldingRegister); if (MB_msg_length > 0){ // Devolve a resposta Modbus Serial.write((const uint8_t *)MBBuffer, MB_msg_length); Serial.flush(); } } }

Pessoal, estou precisando montar uma rede de comunicação Modbus RTU MASTER e também RTU SLAVE com ESP8266 12E (ou F, tanto faz), mas não consegui encontrar uma biblioteca que funcione bem. Tem várias páginas/blogs/vídeos fazendo referência às coisas da PDA Control ou a Trialcommand (que são a mesma biblioteca), mas não consegui fazer nenhuma funcionar bem. A única que ainda consegui fazer comunicar foi essa da PDA Control, mas mesmo assim ocorrem muitos erros de escrita e leitura, muitos timeouts, etc, mesmo setando a serial para trabalhar em 9600 em lugar de velocidades mais altas. Alguém conhece alguma biblioteca que funcione bem para ESP8266 ou alguma rotina de Modbus RTU que funcione (escrita em qualquer linguagem) e que eu possa usar para "traduzir" para a linguagem C usada no Arduino? Já tentei usar sem sucesso essas bibliotecas: https://github.com/Trialcommand/ESP8266-Modbus-RTU-Slave/tree/master/Modbus https://github.com/pkourany/ModBusMaster https://github.com/smarmengol/Modbus-Master-Slave-for-Arduino https://github.com/JhonControl/ESP8266_ModbusRTU_Master_V2 https://github.com/4-20ma/ModbusMaster

Experimente refazer seu código como nesse exemplo abaixo. Eu não tenho como testar direto numa EEPROM então testei no https://repl.it/ e funcionou bem. Não tem motivo para não funcionar numa situação real também. void escrever(unsigned long valor){ unsigned char my_byte = 0; // Você pode colocar esse código num loop "for" também my_byte = valor & 0xFF; valor = valor >> 8; printf("one = %x\n" , my_byte); my_byte = valor & 0xFF; valor = valor >> 8; printf("two = %x\n" , my_byte); my_byte = valor & 0xFF; valor = valor >> 8; printf("three = %x\n" , my_byte); my_byte = valor & 0xFF; valor = valor >> 8; printf("four = %x\n" , my_byte); } unsigned long ler(unsigned int addr) { unsigned long numero_memoria = 0; unsigned char memoria_corrente = 0; // Você pode colocar esse código num loop "for" também memoria_corrente = 0xFF; // byte mais significativo numero_memoria = memoria_corrente; memoria_corrente = 0xFE; numero_memoria = (numero_memoria << 8) | memoria_corrente; memoria_corrente = 0xFD; numero_memoria = (numero_memoria << 8) | memoria_corrente; memoria_corrente = 0xFC; // Byte menos significativo numero_memoria = (numero_memoria << 8) | memoria_corrente; return numero_memoria; } int main(void) { escrever(0xFFFEFDFC); printf("%x\n", ler(0)); }

Problema resolvido. Eu resetei o chip, foram restauradas as configurações default de fábrica e reconfigurei todos parâmetros novamente. Tudo OK por enquanto.

Olá! Pessoal, estou montando um dispositivo que opera com Bluetooth Low Energy (BLE). Está com problema de queda de conexão, em que hora conecta e se mantém por algum tempo, mas a maior parte do tempo se conecta e desconecta em seguida. Sequer há tempo de conseguir transferir alguma coisa... O chip Bluetooth que estou usando é RN4870_71 da Microchip. Estou tentando inicialmente usar o próprio aplicativo da Microchip para me conectar via Android com o chip BluetoothLE, mas também já tentei usar outros aplicativos com mais recursos. Alguém sabe já viu ocorrer esse problema de queda de conexão e sabe como resolver?

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!

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.

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); } }

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!

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

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!

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

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!