Seriele conectie valt weg

International Nederlands
1

Hallo ik heb een probleem met mijn Bluetooth seriële verbinding tussen 2 nano's
bij het opstarten zie ik de verbinding opbouwen vervolgens doet hij het ongeveer 10 tot 20 seconden en daarna reageert de seriële verbinding niet meer. Als ik hem uitlees blijft er wel waarde uit gestuurd worden maar de bluetooth doet er niks mee.
gebruik 2 nano's en bij de keren een HC-05 1 als master 1 als slave

Master

#define ledPin 9

int state = 0;


void setup() {
  pinMode(ledPin, OUTPUT);
  digitalWrite(ledPin, LOW);
  Serial.begin(9600); 
}

void loop() {
 if(Serial.available() > 0){ 
    state = Serial.read(); 
 }
 // Controlling the LED
 if (state == '1') {
  digitalWrite(ledPin, HIGH); 
  state = 0;
 }
 else if (state == '0') {
  digitalWrite(ledPin, LOW);
  state = 0;
 }

}

Slave


#define button 8


int buttonState = 0;

void setup() {
  pinMode(button, INPUT);

  Serial.begin(9600); 
}

void loop() {
 if(Serial.available() > 0){ 
    state = Serial.read(); 
 }


 buttonState = digitalRead(button);
 if (buttonState == HIGH) {
   Serial.write('1'); 
 }
 else {
   Serial.write('0');
 }  
}
2

Hoi mrnico86, welkom !

Wanneer deze code alles is wat je hebt (in dat geval vermoedelijk om te testen of dit wil lukken), probeer dan eens te zien hoe vaak er wat verzonden wordt.
Je zult zien dat dat enorme aantallen enen en nullen zijn.
Want deze sketch draait waarschijnlijk honderdduizenden malen per seconde (zo snel is een trage Arduino* nog steeds).
Je kunt een aantal dingen doen om dit vast te stellen.
Namelijk gewoon een tellertje mee laten lopen, en/of die ook mee te sturen.

Het probleem wat je hiermee zou kunnen krijgen, is dat de buffer die hiervoor nodig is, vol loopt (want de trage Arduino* heeft ook geen erg groot geheugen*).
En daarmee loopt dus je sketch (gedeeltelijk) vast.

Wanneer dit het geval blijkt, zijn hier verschillende oplossingen te bedenken.
Het eerste wat bij mij dan opduikt, is dat je niet mèèr moet verzenden dan noodzakelijk.
Zo houd je de "ether" schoon, en voorkom je dus buffer overflows.
Dat niet meer dan noodzakelijk, betekent dat je alleen iets verzendt, wanneer de waarde die je wil overbrengen ook anders is dan de vorige keer toen je 'm verzond.
Omdat je dan nog wel aan de ontvangende kant toevallig net die ene waarde zou kunnen missen, kun je dan ook nog een soort van time out toepassen, waarbij je alleen als er wat verandert iets verzendt, of wanneer er na verlopen van zo'n time out niets veranderd is dan die waarde herhalen, bijvoorbeeld 1 of een halve seconde.

Het kan nog zuiniger, dan ga je met protocollen werken.
Dan vraagt de master aan de slave hoe het er voor staat, en moet de slave het antwoord geven.
Dat heet "pollen".
Het voordeel daaraan is dat de master gewoon zijn ding staat te doen, en wanneer ie er aan toe is aan de slave vraagt (of eigenlijk opeist) hoe het met die pin staat.
De master moet dan wel zo opgebouwd worden dat ie vaak genoeg pollt en dus de waarde opvraagt.

  • Traag en klein geheugen is dus relatief (dus in vergelijking met andere systeempjes), maar daar kun je met een beetje vernuft nog steeds prima mee omgaan en hoeft hier helemaal geen probleem te zijn, zolang je je er maar van bewust bent.
3

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.