Programmdurchlaufzeit zu langsam

[ThKloib]

Guten Tag,

wenn Zeile 276 - 326 auskommentiert werden schafft der Mega ca 85 Durchläufe/ms

werden diese Zeilen nicht auskommentiert erreicht der µC nur 6(!) Durchläufe

mein Problem... ich finde in den auskommentierten UPs keine schleifen o. Ä. Was bremst dem µC so ein?
Bin noch Schüler, bin daher für jeden Tipp dankbar!!

herausgefunden habe ich das ganze mit der Variable A - diese habe ich mir im Visual Studio (mit Visual Micro Extention) gemeinsam mit millis() ausgeben lassen. -> Beispielbild im Anhang

Im Anhang beim Programm und die Wiegand Library.

vielen Dank schon mal im Vorraus

Programmdurchlaufzeit langsam.zip (14.7 KB)

[zwieblum]

Kannst du den Code in Codetags anhägen?

[uwefed]

for (int i = 1; i <= 53; i++)
	{
		pinMode(i, OUTPUT);
		digitalWrite(i, AUS);//alle pins ausschalten
	}

Ist das Dein Ernst? Wieso machst Du das?? Willst Du den Microkontroller kaputtmachen?

Serial2.begin(9600);
Das verschicken eines einzigen Zeichens braucht 1mS. Daher kommt die Verzögerung.
Du kannst höhere Geschwindigkeiten nehmen zb 115200. Dann wird weniger gebremst.

Dein Kode ist unmöglich zu lesen. Darum weiß ich nicht ob noch andere Bremsen drin sind.
Häng Deinen Sketch wenigstens nicht als zip.Datei an. Zum Einfügen wird er zu groß sein.

Grüße Uwe

[system]

(deleted)

[ThKloib]

Code kann ich nicht einfügen -> über 9000 Zeichen. Ist aber als .ino File im Anhang.

Peter-CAD-HST:
schubs mal nacheinander die unterprogamm-aufrufe raus.

wie beschrieben, habe ich die Zeilen 276 - 326 auskommentiert, es die Durchläufe werden mit jedem UP drastisch reduziert (eigentlich müsse in jedem etwas Faul sein)

uwefed:

for (int i = 1; i <= 53; i++)

{
	pinMode(i, OUTPUT);
	digitalWrite(i, AUS);//alle pins ausschalten
}

Ist das Dein Ernst? Wieso machst Du das?? Willst Du den Microkontroller kaputtmachen?

Serial2.begin(9600);
Das verschicken eines einzigen Zeichens braucht 1mS. Daher kommt die Verzögerung.
Du kannst höhere Geschwindigkeiten nehmen zb 115200. Dann wird weniger gebremst.

Dein Kode ist unmöglich zu lesen. Darum weiß ich nicht ob noch andere Bremsen drin sind.
Händ Deinen Sketch wenigstens nicht als zip.Datei an. Zum Einfügen wird er zu groß sein.

Grüße Uwe

1. warum wird dabei der µC kaputt?
2. definitiv richtig, aber bei meinem Test wurde nichts versendet - außerdem würde das auch bremsen wenn ich die genannten Zeilen auskommentiere.
3. "Kode ist unmöglich zu lesen" -> muss ich so akzeptieren, ohne Tipp bringt mir das aber auch für das nächste mal nichts

danke für eure Antworten

Arduino_Mega.ino (43.8 KB)

[ThKloib]

anders gefragt: welche Durchlaufzeiten sind max. empfehlenswert? derzeit liege ich bei 170µs

[Serenifly]

Man schaltet keine Pins auf Ausgang wenn es nicht nötig ist. Eingänge sind normal hochohmig. Dann passiert nichts wenn da mal High oder Low anliegt

welche Durchlaufzeiten sind max. empfehlenswert?

Kommt immer auf die Anwendung an. Einige Millisekunden können in Ordnung sein. Wenn man sonst nichts macht können es auch Sekunden sein.

[postmaster-ino]

Hi
unsigned long ZiegeInStation[5][4] = { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 }; //[Stand] [Laser, TagCode, Futtermenge]
... soll Was bringen?
unsigned long ZiegeInStation[][4] = {
{0,0,0,0},
{0,0,0,0},
{0,0,0,0},
{0,0,0,0},
{0,0,0,0},
}; //[Stand] [Laser, TagCode, Futtermenge]
... könnte halbwegs zum Erfolg führen.

MagicNumbers - z.B. die Pin-Nummern für RFID Zeile 231/232 - warum keine Variablen?
Stuchwort ... #define weg, const byte hin.
Sofern Dein µC keine 256 Pins hat, reicht BYTE dicke aus.

Was machen A0 bis A15?

Zeile 1229:
tSchneckAusschalten = Zeit + millis();// = abschaltzeit
DAS fällt Dir (nach 49,x Tagen) auf die Füße.
IMMER
millis()-Startzeit>=Wartezeit

Wenn Es blöd läuft, loop() braucht knapp über 1ms pro Durchlauf - verpasst Du den Ausschalt-Zeitpunkt und die Schnecke wird frühestens in 49,x Tagen erneut erfolgreich geprüft werden können - sofern dann dort 'passend' die Millisekunde getroffen wird.
Ok, weit hergeholt, aber warum nicht einfach sauber programmieren??
Davon ab wird dieser Fehler MIT SICHERHEIT mitten in der Nacht, Freitag auf Samstag auftreten - so hat die Schnecke über 2 Tage Zeit, Unsinn zu treiben.

Zeile 1669:
void shift()
Das schreib förmlich nach einer Schleife - macht dann zwar nichts Anderes, liest Sich aber deutlich besser - und wird weniger Platz brauchen.

Das Ganze liest sich zumindest so, als ob Du Dir den einen oder anderen Gedanken gemacht hättest.
Du wirst also eine Art Ablauf erstellt haben, nach Dem Du Das geschrieben hast - zeig besser Den - aus dem Code werde ich nur so schlau, daß Du wohl fünf Ziegen füttern und melken willst.

MfG

[Serenifly]

Zusätzlich zu Arrays solltest du dir mal Strukturen (struct) anschauen. Array sind für Dinge die das Gleiche sind. Sobald verschiedene Einträge unterschiedliche Sachen darstellen ist es falsch. Dafür nimmt man Strukturen, bzw. Arrays aus Strukturen.

Diese ganzen Orgien mit der String Klasse kann man auch effizienter machen. Sowohl was Speicher als auch Geschwindigkeit betrifft. Als ersten Schritt solltest du String Objekte immer als Referenz übergeben damit keine Kopie erstellt wird:

void func(String& str)
{ }

[michael_x]

Wenn tatsächlich Programmausführungszeit optimiert werden soll, ist String natürlich auch ein Kandidat für Säuberungen.

170 µs riecht üblicherweise nach 1x analogRead + 50µs sonstwas... und stellt die Frage, welche Geschwindigkeit denn warum gewünscht wird. Die erste Anforderung ist in der Regel "spontane Reaktion auf interaktive Ereignisse" (das wäre ca. < 100 ms) "schnelle optische Darstellung" ( < 40 ms )
Aktionen im einstelligen ms - Bereich erfordern dann schonmal spezielle Überlegungen.

Wenn Serial-Ausgaben den Code bremsen, kann man natürlich 1. über höhere Geschwindigkeit, aber auch 2. über weniger Ausgaben nachdenken.

Code, der wegen der Größe hier nicht reinpasst, wird aus demselben Grund auch nicht ungern angeschaut.
Und wenn dann noch sowas kommt

"Arduino_Mega.ino" enthält unbekannte Zeichen. Wenn der Code mit einer älteren Version von Arduino erstellt wurde, sollten Sie eventuell über Werkzeuge -> Kodierung korrigieren & neu laden den Sketch auf UTF-8-Kodierung aktualisieren. Wenn nicht, sollten Sie die ungültigen Zeichen manuell entfernen, um diese Warnung zu deaktivieren.