Das Programm leuft super, bisher mehrere Durchläufe ohne Probleme. Nur das Sim900 scheint durch das F() auch nichts mehr zu verschicken. An welchen Stellen sollte ich das weglassen?
void SMSsend() //SMS Funktion falls Temperatur zu hoch ist , \r steht für Enter (CR)
{
serialSIM900.write(F("AT+CMGF=1\r\n"));
delay(1000);
serialSIM900.write(F("AT+CMGS=\"+49"));
delay(1000);
serialSIM900.write(Handynummer);
delay(1000);
serialSIM900.write(F("\"\r\n"));
delay(2000);
serialSIM900.write(Zeile1);
serialSIM900.write(F("*\n\r"));
delay(1000);
serialSIM900.write(Zeile2);
serialSIM900.write(F("*\n\r"));
delay(1000);
serialSIM900.write(Zeile3);
serialSIM900.write(F("*\n\r"));
delay(1000);
serialSIM900.write(Zeile4);
serialSIM900.write(F("*\n\r"));
delay(1000);
serialSIM900.write(Zeile5);
serialSIM900.write(F("*"));
delay(1000);
serialSIM900.write((char)26);
Serial.println(F("gesendet"));
}
Serial.print("text") ; // hat einen festen Platz im RAM
String x="";
x += "text"; // belegt dynamisch zusätzlichen RAM der bei jedem Aufruf neu (und woanders) belegt wird.
da sich noch niemand drauf bezogen hat, wieder gelöscht.
Hab es auch gemerkt: HardwareSerial liefert:
call of overloaded 'write(const __FlashStringHelper*)' is ambiguous
Aber SoftwareSerial schluckt es. Da es - wie beobachtet - nicht geht, ist es meiner Meinung nach ein Bug in SoftwareSerial.h, den falschen Datentyp nicht anzumeckern.
Ist aber off-topic hier
serialSIM900.print(F("AT+CMGF=1\r\n")); // sollte funktionieren.
Ja Compiler Fehler gab es keine , ist es denn "Problematisch" die SMS Funktion von dem F() zu befreien. Denn ich habe meinen Code jetzt aufgeräumt und komme auf um die 60% ohne Thingspeak und 70% mit thingspeak . Bei diesen 70% gibt es schon wieder schneller Fehler (logisch).
Zu dem was "handynummer" macht , ich fange den AT befehl zum sms senden an :
serialSIM900.write(("AT+CMGS="+49"));
und füge die Nummer an
serialSIM900.write(Handynummer);
, hänge mit
serialSIM900.write((""\r\n"));
noch ein " dran und schicke es los, funktioniert super.
Wie deklariere ich denn Arrays ohne feste Größe richtig? Ich dachte eigentlich immer das char name[] = "";
der richtige weg sei aber bin ja noch recht neu hier.
Danke für die Antworten durch euch leuft mein Sketch wieder, damits fertig wird muss es nur noch n bissl flotter laufen
Ok ok fange ich mal an gut, das mit den Arrays wusste ich nicht das ich dann praktisch ins nichts schreibe, werde ich ändern habe ich wie man sieht zu viel verwendet.
Das mit dem AT command "funktioniert" in dem Sinne das der Compiler nichts aussspuckt aber ich keine SMS mehr bekomme (müsste mich mehr mit Beschäftigen und schauen was das SIM900 antwortet bzw wie das auf F() reagiert)
Das mit der Sensorenauswahl hatte ich vorher auch als Char gehabt doch da ich früher Probleme mit Umrechnungen hatte und es bei dem damaligen Code einfacher war hatte ich mich für die String Variante entschieden werde das aber gleich ändern.
(müsste mich mehr mit Beschäftigen und schauen was das SIM900 antwortet bzw wie das auf F() reagiert)
Das SIM900 interessiert gar nicht ob das F() oder nicht F() ist. Das bekommt davon gar nichts mit. Das Problem besteht in der Bibliothek und welche der Methoden darin aufgerufen wird. Die Methoden sind überladen (d.h. der gleiche Methodenname für unterschiedliche Datentypen) und manchmal ist es nicht klar welche aufgerufen werden soll.
write() sollte mit F() eigentlich nicht gehen, da es keine Version davon mit einem FlashStringHelper als Parameter gibt.
Tip: Warnungen aktivieren! Fehler sind nicht alles
doch da ich früher Probleme mit Umrechnungen hatte und es bei dem damaligen Code einfacher war hatte ich mich für die String Variante entschieden
Dann sorge dafür dass es korrekt umgerechnet wird wenn du was damit machst. Irgendwas + '0' geht genauso. Die String Klasse ist auf Grund ihres riesigen Overheads (6 Byte! Für einen Zeiger auf das interne Array, die Länge des Strings und die Größe des Arrays) keine Lösung
AlexArduinoP:
Ok ok fange ich mal an gut, das mit den Arrays wusste ich nicht das ich dann praktisch ins nichts schreibe, werde ich ändern habe ich wie man sieht zu viel verwendet.
Du schreibst nicht ins nichts; Du überschreibst den darauffolgenden RAM-Speicher. Dadurch werden die inhalte verändert und der Sketch macht komische Sachen.
ElEspanol:
Serial << F("**********************************") << F("\r\n") ;
eleganter und vielleicht(?) Flash sparender:
Serial << F("**********************************") << endl) ;
Gute Idee mache ich auch , sieht nochmal besser aus.
uwefed:
Du schreibst nicht ins nichts; Du überschreibst den darauffolgenden RAM-Speicher. Dadurch werden die inhalte verändert und der Sketch macht komische Sachen.
Gut ich werde dann jetzt versuchen alle Arrays eine feste größe zuzuweisen um zu verhindern das mein Sketch irgendwann einfach stehen bleibt richtig?
Weisse den array jeweils die max. zu erwartende Grösse + 1 (für die 0-Terminierung) zu.
Benutze nur EINEN Puffer, auch hier die max. zu erwartende Grösse + 1
Beim Reinschreiben kannst du noch einen Fehler abfangen in dem du den Schreibindex auf
if (Schreibindex >sizeof(buffer)-1 ){
Serial.println(F"Pufferueberlauf in xxx");
Schreibindex = Schreibindex -1; // oder Schreibindex =0; je nach Anwendung
}
Puffer sind, wie der name schon sagt, zum Puffern bzw. zum zusammensetzen von verschiedenen Daten, also nur temporär. Vor erneuter Benutzung sollte man ihn mit
memset (buffer,0,sizeof(buffer));
zurücksetzen. Somit ist auch gewährt, dass der buffer immer terminiert ist.
Jup das hatte ich auch schon in meinem Code gehabt (das mit dem Buffer leeren) nur ich hatte es wieder entfernt gehabt da es mir keinen Vorteil bei dem Ram Problem was ich vorher hatte gegeben hatte. Der Programmcode den ich mithilfe dieses Threads verbessert habe funktioniert mittlerweile und ich habe ihn probeweise über Nacht laufen gelassen und er hat sich nicht aufgehangen oder irgendwelche komischen Sachen gemacht.
Danke für die hilfreichen Antworten hat mir in meinem ersten Projekt echt weitergeholfen.
hier noch einmal der fertige code falls es noch jemanden interessiert, Verbesserungsvorschläge um Fehler vorzubeugen oder kreative Ideen werden immernoch gerne angenommen!
code dieses mal leider auf pastebin weil ich sonst 3 posts hintereinander machen müsste.
Ich habe den Code mal kurz überflogen. wenn keine Fehler drin sind, bzw. Alles läuft wie es soll, ändere besser nichts mehr dran.
Kreative Ideen braucht es für die Problemstellung nicht wirklich.
Optimierung von Speicherverbrauch und Programmierstil, da ist noch viel Luft nach oben.
Falls du beim Arduino Hobby bleibst und weiter lernen willst, können wir den Sketch gerne darauf durchgehen.
