Arduino Recepção de dados serial via bluetooth e apk utilizando o Arduino

Rodrigo Nogy · 17 de setembro de 2020


int pwm1 = 9;

int led13 = 13;

String android;

char x;

void setup(){

    Serial.begin(9600);
    pinMode(pwm1,OUTPUT);

    pinMode(led13,OUTPUT);

}

void loop{

if(Serial.available()>0){

android = Serial.readString();

x = Serial.read();                                 

     if (x=='A'){

        digitalWrite(led13, HIGH);     // Não aciona quando envio o caractere 'A'

     }


     if(android.startsWith("pwm1")){
     android.replace("pwm1","");
     analogWrite(pwm1,android.toInt());
  
     Serial.println(android);

     delay(100);

   }//if android

  }//fim serial Serial.available

}//fim loop

Olá pessoal.

Estou com dificuldades para entender e executar um comando digital utilizando um caractere. Vou postar apenas uma parte na qual percebo o erro: o programa envia um string para a porta pwm. O controle pwm está funcionando, mas quando adiciono a função Serial.read(), o programa para de responder até o pwm.

Testei o programa a parte enviando dois caracteres um para ligar e deligar o led 13, e está funcionando. O problema é quando envio aplico junto ao controle do pwm via serial.

Agradeço desde já quem puder me ajudar.

alexandre.mbm · 17 de setembro de 2020

Este tópico de fórum externo descobre a possibilidade de se estar a ler caracteres de retorno, por exemplo. Eu não tenho sua resposta. Sugiro que faça testes similares. Imprima suas capturas entre delimitadores. Se quiser facilitar as coisas em detrimento de otimização, pode tentar se fiar na abstração da readString().

Qual é o seu hardware? Lembro-me de já ter lido alguma coisa sobre exclusividades entre PWM e Serial.

Rodrigo Nogy · 18 de setembro de 2020

Então, Alexandre. Primeiramente, obrigado pela atenção.

Estou usando o Arduino Due com o microcontrolador Atmega328P.

Comecei a testar aqui, consegui fazer funcionar, porém, está lento.

alexandre.mbm · 18 de setembro de 2020

Você fez alguma mudança? Qual é o código que está funcionando?

Eu não tinha lido seu programa com atenção. Farei isso agora.

Rodrigo Nogy · 18 de setembro de 2020

Mudei a função que estava utilizando, agora estou usando: void serialEvent(). o curiosos que se eu declarar o pino 13 como OUTPUT, não aciona.

Novo_Teste.txt

alexandre.mbm · 18 de setembro de 2020

Tanto no uso de read() como no uso de readString(), você precisa levar em conta que está "consumindo" (esvaziando) um buffer. Lê — ou melhor: consome — e armazena cópias em suas variáveis. Note que você não está fazendo condição para "ler um caractere" após ler "uma string", e se fizesse, também não faria sentido. Quando lê o caractere, o buffer já está vazio. Acho que é por aí...

Rodrigo Nogy · 18 de setembro de 2020


String android;
int pwm1=9;
int led13=13;

void setup() {
  Serial.begin(9600);
  pinMode(pwm1,OUTPUT);
   //pinMode(led13,OUTPUT);//Se eu declara-lo, não ativará a decisão

void loop() {
  
    //Serial.print(":");
    //delay(500);
  
  if (Serial.available()>0){
      android = Serial.readString();

      if(android.startsWith("pwm1")){
        android.replace("pwm1","");
        analogWrite(pwm1,android.toInt());
      delay(20);
        Serial.println(android);
      }
 }//fim loop

  void serialEvent() {
    while (Serial.available()) {
    char CharSerialRX = (char)Serial.read();
    delay(10);
        if (CharSerialRX =='A'){
       
            digitalWrite(led13,HIGH); 
         } 
         if (CharSerialRX =='D'){
       
            digitalWrite(led13,LOW); 
         } 
         
    Serial.print("Recebido: ");
    Serial.print(CharSerialRX); 
  }
}

Testando noto: que os dados não se alinham, acontecendo alguns erros de caracteres no envio.

adicionado 5 minutos depois

7 minutos atrás, alexandre.mbm disse:

Tanto no uso de read() como no uso de readString(), você precisa levar em conta que está "consumindo" (esvaziando) um buffer. Lê — ou melhor: consome — e armazena cópias em suas variáveis. Note que você não está fazendo condição para "ler um caractere" após ler "uma string", e se fizesse, também não faria sentido. Quando lê o caractere, o buffer já está vazio. Acho que é por aí...

É a primeira vez que faço troca de dados deste formato. Pelo visto terei "organizar o buffer".

alexandre.mbm · 18 de setembro de 2020

Onde entra bluetooth e APK na estória?

Qual é o esquema de ligações?

adicionado 12 minutos depois

16 minutos atrás, alexandre.mbm disse:

Quando lê o caractere, o buffer já está vazio.

Eu não tenho prática com isso. Quis dizer que a leitura do caractere estaria numa próxima linha. Mas isso poderia estar OK para você — quem está controlando a entrada.

Minha cabeça está viajando longe do seu tópico. Não vou poder lhe ajudar.

Rodrigo Nogy · 18 de setembro de 2020

Estou enviando via bluetooth com o apk que criei. Como citei, enviando caracteres comuns, os botões acionam e suas respectivas saídas digitais.

A parte da String android que ativa o pwm deste canal. Também, funciona normal, se não associar com o outro comando serial.

if (Serial.available()>0)

{

android = Serial.readString();

if(android.startsWith("pwm1"))

{

android.replace("pwm1","");

analogWrite(pwm1,android.toInt());

delay(20);

Serial.println(android);

}

O esquema de ligação de hardware, estou somente usando o módulo HC-05.

alexandre.mbm · 18 de setembro de 2020

5 minutos atrás, Rodrigo Nogy disse:

O esquema de ligação de hardware, estou somente usando o módulo HC-05.

APK (console) › HC-05 › Arduino

33 minutos atrás, Rodrigo Nogy disse:

Pelo visto terei "organizar o buffer".

Deve ser por aí. Mas ajudaria na depuração você substituir seu APK por app já validado.

35 minutos atrás, Rodrigo Nogy disse:

É a primeira vez que faço troca de dados deste formato.

Afirmação curiosa, vindo de quem programou o tal aplicativo.

Rodrigo Nogy · 18 de setembro de 2020

7 minutos atrás, alexandre.mbm disse:

APK (console) › HC-05 › Arduino

Deve ser por aí. Mas ajudaria na depuração você substituir seu APK por app já validado.

Afirmação curiosa, vindo de quem programou o tal aplicativo.

Testei os comandos de outro app, enviando caractere. Mas não achei nenhum que faça o aplicação que estou necessitando.

Como disse, o comando para o pwm e o de acionamento digital, funcionam sem problemas "separados"

alexandre.mbm · 18 de setembro de 2020

1 hora atrás, Rodrigo Nogy disse:

Estou usando o Arduino Due com o microcontrolador Atmega328P.

Você quis dizer "Duemilanove", então. Porque o Due é 32 bits (ARM). Mas tudo bem, o LED também está lá, no pino 13, para acionamento em HIGH.

adicionado 16 minutos depois

Citação

pinMode(led13, OUTPUT); //Se eu declara-lo, não ativará a decisão

O que exatamente você está dizendo aqui?

Rodrigo Nogy · 18 de setembro de 2020

45 minutos atrás, alexandre.mbm disse:

Você quis dizer "Duemilanove", então. Porque o Due é 32 bits (ARM). Mas tudo bem, o LED também está lá, no pino 13, para acionamento em HIGH.

adicionado 16 minutos depois

O que exatamente você está dizendo aqui?

Duemilanove, informei errado. Perdão.

Quis dizer, que se colocar este pino como saída, ele não entra em estado alto ao enviar o caractere.

Estou pesquisando como devo aplicar melhor estes dados.

alexandre.mbm · 18 de setembro de 2020

Por que você comentou a linha do pinMode? Você por acaso consegue acender o LED sem ela?!

Como está ligado o HC-05? Esse código parece algo incompleto.

adicionado 8 minutos depois

Este tutorial mostra o básico, ponto de partida, com um Arduino Uno.

adicionado 35 minutos depois

4 horas atrás, Rodrigo Nogy disse:

Vou postar apenas uma parte na qual percebo o erro: o programa envia um string para a porta pwm. O controle pwm está funcionando, ...

É melhor mostrar tudo. Ali é enviado um inteiro.

Como são os comandos "pwm1 VALOR"? Qual é a intenção para esse pino 9?

alexandre.mbm · 18 de setembro de 2020

4 horas atrás, Rodrigo Nogy disse:

o curiosos que se eu declarar o pino 13 como OUTPUT, não aciona.

Sobre o pino 13, os conteúdos mais informativos que encontrei:

Mas eu ainda não entendi!

adicionado 43 minutos depois

4 horas atrás, alexandre.mbm disse:

Eu não tenho prática com isso. Quis dizer que a leitura do caractere estaria numa próxima linha.

Errei, de qualquer jeito. A função readString() não pára com quebras de linha; ela pára com um timeout. E o padrão está para 1 segundo!

adicionado 48 minutos depois

5 horas atrás, alexandre.mbm disse:

Se quiser facilitar as coisas em detrimento de otimização, pode tentar se fiar na abstração da readString().

Pois é. Que caca eu falei aqui! Sem ter ido antes ler a documentação da API. É exatamente o contrário: os caracteres apontarão a saída.

adicionado 50 minutos depois

2 horas atrás, alexandre.mbm disse:

Este tutorial mostra o básico, ponto de partida, com um Arduino Uno.

É o exemplo!

Rodrigo Nogy · 18 de setembro de 2020

8 horas atrás, alexandre.mbm disse:

Sobre o pino 13, os conteúdos mais informativos que encontrei:

No pullup resistor on pin 13 on Duemilanove?

default pinmode of pin 13

Mas eu ainda não entendi!

adicionado 43 minutos depois

Errei, de qualquer jeito. A função readString() não pára com quebras de linha; ela pára com um timeout. E o padrão está para 1 segundo!

adicionado 48 minutos depois

Pois é. Que caca eu falei aqui! Sem ter ido antes ler a documentação da API. É exatamente o contrário: os caracteres apontarão a saída.

adicionado 50 minutos depois

É o exemplo!

Interessante Alexandre. Irei ver este exemplo. Obrigado. Te falo o que consegui.

Sigo geralmente esta lógica do "Switch Case". Mas como te disse, se eu utilizar a leitura do caractere "Serial.read ();" dentro do loop, não funcionará.

alexandre.mbm · 18 de setembro de 2020

2 horas atrás, Rodrigo Nogy disse:

Mas como te disse, se eu utilizar a leitura do caractere "Serial.read ();" dentro do loop, não funcionará.

Não captei. Por que não pode chegar a funcionar?

Você poderá consumir seu buffer com mais precisão. Guardando em variáveis o que consome. Fazendo checagens e desistências. Será uma questão de algoritmo.

Mas provavelmente há um problema:

16 horas atrás, alexandre.mbm disse:

Sugiro que faça testes similares. Imprima suas capturas entre delimitadores.

Parece que essa parte do meu "conselho" também está furada! Ontem andei buscando sobre as tais "exclusividades".

16 horas atrás, alexandre.mbm disse:

Lembro-me de já ter lido alguma coisa sobre exclusividades entre PWM e Serial.

Parece que é o seguinte. Não são "exclusividade" ao pé da letra. Tanto PWM como print() usariam interrupções, mexendo com o tempos no fluxo do programa. Quanto a HardwareSerial, nem vi. Mas só encontrei queixas de quem estava a tentar usar ISRs explicitamente. Na realidade, estou na prática por fora do assunto. Vamos aguardar os mais experientes entrarem nesse mérito. Eu só sei que sinto cheiro de fumaça.

alexandre.mbm · 18 de setembro de 2020

18 horas atrás, Rodrigo Nogy disse:

Comecei a testar aqui, consegui fazer funcionar, porém, está lento.

Começo a ver...

2 horas atrás, alexandre.mbm disse:

Você poderá consumir seu buffer com mais precisão. Guardando em variáveis o que consome. Fazendo checagens e desistências. Será uma questão de algoritmo.

Este é o feijão-com-arroz mal temperado.

A pesquisa é longa e estou sem tempo para ela, mas há uma razão pela qual o NeoHWSerial existe!

aphawk · 18 de setembro de 2020

Como não sei programar nessa linguagem, só posso dar o palpite no hardware :

O PWM usa um dos Timers, e portanto vai usar a interrupção do timer escolhido.

A Serial usa a interrupção dela.

Nenhuma interfere na outra, mas claro isso depende do programador que escreveu as libraries ...... ele pode ter feito tudo por software, e nesse caso não dá para garantir quer a coisa toda funcione.

Eu recomendo sempre usar libraries que implementem a Serial por hardware e o PWM também por hardware.

Já vi implementações de alto nível de serial que dá vontade de chorar .... e também vi algumas que realmente merecem o parabéns, pela perfeição e quase zero interferência em tempos em tudo o que o programa faz.

Hoje , para Arduino, existem dezenas de implementações de Seriais e de PWM, dá para escolher de monte.

Paulo

alexandre.mbm · 18 de setembro de 2020

@aphawk, eu ainda não entendi o que pode estar passando com o pino 13. Esquisito! Mas também, o @Rodrigo Nogy falou pouquíssimo, a respeito...

Interessante que eu li (confuso) em inglês, numa entre-linha de fórum, que um tal resistor limitaria algo justamente na comunicação serial, fazendo um tal "pull down load" no pino, algo para além do pull-up conhecido de todos (e facultativo). Achei "alienígena" demais; resolvi deixar de lado.

Sem cabeça para tal, e praticamente sozinho, eu não quis abrir o esquema do Duemilanove aqui no tópico.

O que fez sentido pra mim foi:

– O pull-up é interno ao ATmega
– O pull-down é na placa — um resistor limitador para o LED, em série com este (até o GND, obviamente)

O mistério está no comportamento mais ou menos reportado por @Rodrigo Nogy.

alexandre.mbm · 19 de setembro de 2020

1 hora atrás, alexandre.mbm disse:

Interessante que eu li (confuso) em inglês, numa entre-linha de fórum, que um tal resistor limitaria algo justamente na comunicação serial, fazendo um tal "pull down load" no pino, algo para além do pull-up conhecido de todos (e facultativo). Achei "alienígena" demais; resolvi deixar de lado.

Ah! O pino 13 da placa também é o pino SCK do cabeçalho ICSP, de comunicação serial.

De fato, LED + 1K fazem uma "carga" pull-down. Só que isso não é "limitar" algo para a serial, segundo entendo. E não explica a anomalia observada, do LED não acender.

aphawk · 19 de setembro de 2020

@alexandre.mbm ,

Tem mais problema aí ....

Para usar um Hc-05 , que não suporta 5V, você tem de fazer um divisor resistivo para limitar o nível do sinal de transmissão para 3,3 V.

Mas repare que no esquema desse Arduino que está sendo utilizado os mesmos pinos de Tx/Rx serial também vão conectado ao Ft-232 através de dois resistores em série com os sinais !

É muito comum ocorrer interferência na comunicação com o HC-05 nessas condições.

Tem de rever os valores do divisor resistivo que protege os pinos do Hc-05 ( se é que o autor utilizou .... se ligou direto pode ter prejudicado o HC-05 ) para valores mais baixos a fim de eliminar a interferência dos resistores do Ft-232.

E sobre os resistores internos , eles sempre são pull up, mas de valor acima de 50K, raramente interferem em alguma coisa.

Já qualquer resistor externo ligado em um pino na função de pull-UP ou Pull-Down normalmente são de valores entre 3K e 10K. Por exemplo o Bus I2C precisa de resistores externos de pull-Up de 4,7K .

Menores do que isso normalmente são limitadores de corrente, e claro que podem interferir bastante.

Paulo

alexandre.mbm · 19 de setembro de 2020

Vamos aguardar @Rodrigo Nogy nos trazer o resultado de um Blink...

Rodrigo Nogy · 23 de setembro de 2020

Obrigado pela atenção, pessoal.

Consegui resolver o problema. Era no firmware. A String e o caractere , necessitavam de serem chamadas por funções criadas em blocos a parte, caso contrário, ocorre o "delay" nos acionamentos.

O acionamento do led, diretamente no looping principal, por comparação de caracteres junto a chamada das funções de leitura serial para habilitar o controle dos canais PWM, utilizando: Serial.read();

Os três canais pwm, funcionando normais sendo chamados por funções criadas com base as funções seriais: while (Serial.available()), e comparadas por: if(readString.length()>0), nos demais blocos fora do "void loop".

alexandre.mbm · 23 de setembro de 2020

@Rodrigo Nogy , gostei muito de vê-lo retornar para nos retribuir com conhecimento. Mas eu não consegui usar a reaction "Amei", porque fiquei sem entender muito do que você acaba de nos escrever.

Se não for lhe pedir muito, por gentileza, dê uma "editada" (enquanto é tempo).

adicionado 50 minutos depois

56 minutos atrás, Rodrigo Nogy disse:

O acionamento do led, diretamente no looping principal, por comparação de caracteres junto a chamada das funções de leitura serial para habilitar o controle dos canais PWM, utilizando: Serial.read();

Os três canais pwm, funcionando normais sendo chamados por funções criadas com base as funções seriais: while (Serial.available()), e comparadas por: if(readString.length()>0), nos demais blocos fora do "void loop".

Vou entender assim:

Não havia problemas com PWM, nenhum dos canais, mas tudo que chamava Serial provocava "atrasos" que confundiam a percepção visual das alterações no estado do LED.