Go Down

Topic: PC-Kommunikation seriell, Abbruch wenn kein Signal (Read 1 time) previous topic - next topic

mde110

#10
Dec 26, 2012, 03:06 pm Last Edit: Dec 26, 2012, 03:08 pm by Mardetuino Reason: 1
Du musst nach sensors.requestTemperatures() mind. 750ms Zeit verplämpern. Der DS braucht bei 11 bit ein wenig Zeit.

Oder so:
sensors.setWaitForConversion(true);

fran83

#11
Dec 26, 2012, 10:31 pm Last Edit: Dec 27, 2012, 12:22 am by fran83 Reason: 1

Bei mir geht dein geposteter Sketch.

Der Fehler sieht für mich nach etwas "internem" aus. Evtl. Arduino nochmals im extra Verzeichnis entpacken und testen...


Habs, da muss man aber erst mal darauf kommen ...
Bei mir hieß der Sketch main.ino, deswegen gings nicht. Komische IDE ... :D


Du musst nach sensors.requestTemperatures() mind. 750ms Zeit verplämpern. Der DS braucht bei 11 bit ein wenig Zeit.

Oder so:
sensors.setWaitForConversion(true);


hmm du hast natürlich Recht. Ich fand das so im Beispiel Sketch von Dallastemperature.h
Code: [Select]
void loop(void)
{
 // call sensors.requestTemperatures() to issue a global temperature
 // request to all devices on the bus
 Serial.print("Requesting temperatures...");
 sensors.requestTemperatures(); // Send the command to get temperatures
 Serial.println("DONE");
 
 Serial.print("Temperature for the device 1 (index 0) is: ");
 Serial.println(sensors.getTempCByIndex(0));  
}

Wahrscheinlich geht das so, weil die Loop() eh nichts anderes macht und da kein Delay vonnöten ist (nach einer bestimmten Ausführungszeit ist eh die Loop() zuende)

Da aber Metro.h und vor allem die serielle Kommunikation mit delay() nicht richtig funktioniert, habe ich wieder millis() benutzt. Das garantiert, dass ich in der Zwischenzeit weiter Mitteilungen empfangen und senden und z.B. auch ein LCD ansteuern kann.

Bei einer Sache bin ich mir aber noch nicht sicher. Im Beispiel "WaitForConversion.pde" von Dallas Temperature sieht der loop so aus:
Code: [Select]
...
 // Request temperature conversion (traditional)
 Serial.println("Before blocking requestForConversion");
 unsigned long start = millis();    

 sensors.requestTemperatures();

 unsigned long stop = millis();
 Serial.println("After blocking requestForConversion");
 Serial.print("Time used: ");
 Serial.println(stop - start);
 
 // get temperature
 Serial.print("Temperature: ");
 Serial.println(sensors.getTempCByIndex(0));  
 Serial.println("\n");
 
 // Request temperature conversion - non-blocking / async
 Serial.println("Before NON-blocking/async requestForConversion");
 start = millis();      
 sensors.setWaitForConversion(false);  // makes it async
 sensors.requestTemperatures();
 sensors.setWaitForConversion(true);
 stop = millis();
 Serial.println("After NON-blocking/async requestForConversion");
 Serial.print("Time used: ");
 Serial.println(stop - start);      
 ...


Also praktisch 2 Möglichkeiten des Auslesens:
Die erste soll "synchron" sein, heißt, dass beim requestTemperatures() immer so lange gewartet wird, wie für die gewählte Resolution nötig ist.
Bei der zweiten wird dann weiter unten im Programmcode noch ein Delay passend für die Resolution eingefügt. Richtig so?

Auf dieser Basis habe ich meinen Code überarbeitet.
Am Anfang lese ich in setup() ein einziges Mal synchron aus, was garantiert, dass zum ersten Aufruf der Schleife schon eine Temperatur in der Variablen gespeichert ist.
Link: http://pastebin.com/Zj2aTUzX

Sind in dem Code noch irgendwo Fehler bzw. seht Ihr Verbesserungsvorschläge vor allem bezüglich der Performance und der Programmgröße?

/edit: noch eine Frage: Kann ich die Variablen HEATING_PIN und MIXER_PIN als byte deklarieren ohne Funktionsverlust? Und geht dasselbe auch mit der Variable incomingByte, in die Serial.Read() eingelesen wird?

mde110

Quote
Also praktisch 2 Möglichkeiten des Auslesens:
Die erste soll "synchron" sein, heißt, dass beim requestTemperatures() immer so lange gewartet wird, wie für die gewählte Resolution nötig ist.
Bei der zweiten wird dann weiter unten im Programmcode noch ein Delay passend für die Resolution eingefügt. Richtig so?

Wobei die Bezeichnung für zweite Möglichkeit mit delay nicht ganz richtig ist. So wie du das gemacht hast passt das ganz gut.
Quote
Sind in dem Code noch irgendwo Fehler bzw. seht Ihr Verbesserungsvorschläge vor allem bezüglich der Performance und der Programmgröße?

Dein Sketch ist so klein, dass Größe und Performance kaum eine Rolle spielen. Der Arduino ist eher unterfordert.
Quote
noch eine Frage: Kann ich die Variablen HEATING_PIN und MIXER_PIN als byte deklarieren ohne Funktionsverlust? Und geht dasselbe auch mit der Variable incomingByte, in die Serial.Read() eingelesen wird?

Du kannst für HEATING_PIN und MIXER_PIN auch das #define nehmen.
Bzgl. incomingByte habe ich keine Ahnung. In der Reference ist das incomingByte tatsächlich auch ein int.

fran83

#13
Dec 27, 2012, 02:30 pm Last Edit: Dec 27, 2012, 09:20 pm by fran83 Reason: 1

Du kannst für HEATING_PIN und MIXER_PIN auch das #define nehmen.
Bzgl. incomingByte habe ich keine Ahnung. In der Reference ist das incomingByte tatsächlich auch ein int.

hmm, hab gerade gemerkt, dass das ja eh Konstanten sind -> kein Einfluss auf Sketch Größe.

Hab den Code jetzt noch mal verändert, da ich will, dass man den Sensor während des laufenden Betriebs an- und abstecken kann.
http://pastebin.com/t7LxjMJ7
Hast du noch irgendwo Verbesserungsvorschläge? (bezügl. Performance: will später noch LCD und SD Karte anschließen, daher will ich jetzt schon "sparen" :D)

Go Up