moin,

also mit meiner "protokoll-freien" N-Spur-Moba" komme ich offenbar schon an die Grenzen des Arduino Mega :
20 Sensoren(TTP) ebensoviele LED's , 20x4-LCD, 5PWM-Pin's belegt und 900 Zeilen Code : anscheinend schon zuviel
Diese sind in einem Gleisbildstellpult herkömmlicher Art verbaut.

Jedenfalls repeated er im Setup..viele Änderungen versucht, aber bisher keine wirkliche Ursache gefunden..
hab auch in forum.arduino.cc gepostet..keiner weiß die realen Ursachen, nur Vermutungen

gibt es einen Noch Mächtigeren Arduino als den A. mega ?

oder sollte man auf Rasperry oder sonstwas umsteigen ?

oder mehrere A.mega parallel betreiben und für Fahrstraßensteurung von einem zentralen Arduino (nano oder mega)
verwalten lassen ?

momentan versuche ich ne kleinere Lösung Ohne LED-Azeige der Weichenstellungen und Blockstreckenschaltung
- diese erstmal über konventionelle Kippschalter-..mal sehn, ob wenigstens das funktioniert..

Freue mich auf eure Tipps..

Deine PWM und LCD Displays benötigen vermutlich einfach viel CPU Zeit, das hat nicht zwingend was mit der Größe des Codes zu tun.

Ein größerer Arduino ist mir nicht bekannt, der nächste logische Schritte wäre m.E. der ESP32 - ähnliche Architektur aber mehr CPU Leistung und parallele Cores und läßt sich problemlos mit der Arduino IDE programmieren. Raspi hab ich bisher nur direkt mit Linux benutzt, ob man das mit dem Arduino OS bespielen kann weiß ich leider nicht.

Oli

Hi,

900 Zeilen Code heißt mal gar nichts. Kommt drauf an, wie geschickt die geschrieben sind und wie weit der Compiler das Zeug optimiert. Insofern ist die Zahl der Code Zeilen in einer höheren Programmiersprache faktisch völlig aussagelos. Hinsichtlich des Flash-Speichers würde ich aber bei Mega265 nicht erwarten, daß man den voll bekommt ohne nicht vorher das RAM zu überfüllen. AVRs sind leider etwas schwach mit RAM bestückt und der GCC sehr dämlich, was die Nutzung angeht. Der GCC legt zum Beispiel alle V-Tabellen in das RAM, was normale C++ Programmierung nahezu unmöglich macht.

Zitat

---

20 Sensoren(TTP) ebensoviele LED's , 20x4-LCD, 5PWM-Pin's

---

Das klingt eher so, als könnte man das mit einem Mega32 erledigen. bin da schon erstaunt. LCD sind ja nur 50 Bytes Code + Texte, PWM läuft vermutlich voll in Hardware?, und 20 In + 20 Out...

Bleibt halt offen, wieviel Logik nun noch in Deiner Software steckt.

Wie auch immer, ich würde mal einen Simulator nehmen und einfach mal gucken, wo es kracht. Speicherschreiber? Stacküberlauf? Verschachtelte Interrupts, die nicht zum Ende kommen und "von sich selbst" immer neu gestartet werden bis der Stack voll ist? Wenn der Programmspeicher voll wäre, sollte schon der Linker meckern. Das kann man wohl ausschließen.

Gruß
Klaus

P.S.: Tut mir bitte alle einen Gefallen: Es gibt keinen Arduino-Controller! Es gibt mehr als eine Handvoll von Controller-Familien, die sich mit der Arduino-Umgebung programmieren lassen. Diese Controller sind aber so verschieden, daß man mit dem Begriff Arduino hier aber auch gar nichts aussagt! Also: Immer die verwendete Prozessor-Familie dazu nennen, sonst redet man über nichts. Mit persönlich erschließt sich das Arduino-Zeug nicht. Der Editor ist ein Desaster, alles sieht sehr schön aus, paßt aber nur bedingt zusammen und alles verbirgt den Zugang zu "normaler" Programmierung. Ich empfehle jedem sich das Datenblatt des Controllers zu nehmen und richtig zu programmieren, statt sich auf die oft sehr wackeligen Arduino-Bibliotheken zu verlassen. Die helfen nur dann, wenn man Projekte ggf. mal auf einen anderen Controller migrieren will, aber auch da hakt es gewaltig.

Was ist denn eigentlich das Problem?

Zu wenig Programmspeicher?
Zu wenig Flash-Speicher?
Eeprom zu klein?
Zu wenig Ein-/Ausgänge?
Zu wenig IR-Pins?
Fehlen Timer, serielle Schnittstellen oder sonstige Features?
Sketch zu langsam?
Sketch stürzt ab?

Ich hab weit mächtiger Projekte auf einem Mega2560 am laufen, ich sag nur als Stichwort Marlin. Ohne die Software im Detail zu kennen: mit 900 Zeilen bringt man einen Mega2560 nicht ins Schwitzen was den Speicher etc. betrifft. Rein von der Rechenleistung geht das schon wenn man sehr unglücklich programmiert bzw. die Schaltung auslegt. 20 Sensoren sind nicht gleich 20 Sensoren. Frage ich die per I2C-Expander ab der bei Änderung an einem PIN einen Interrupt generiert frisst das kein Brot, frage ich jeden Pin einzeln ab, eventuell noch mit Delay für's entprellen gute Nacht. Das gleiche für die Leds, setze ich die entsprechenden Pins in jedem Programmdurchlauf frisst das irgendwann Rechenzeit, setze ich die nur wenn sich wirklich was geändert hat merkt man es kaum. PWM in Hardware ist eigentlich stressfrei, aber auch hier gilt: Immer nur was tun wenn auch wirklich was zu tun ist, sprich: das Analog.write() kommt nur wenn sich was geändert hat..
Die Z21 PG als Z21-Nachbau macht definitiv eine Menge komplexer Sachen, das auch noch scheinbar parallel und mit kritischem Timing (DCC Signal erzeugen , Expressnet, Loconet, LAN, WLAN-Modul ansteuern, Display...). Insgesamt sind das sehr viel mehr als 900 Zeilen wenn man die einzubindenden Bibliotheken berücksichtigt.

Zitat von Domapi im Beitrag #4

---

Sketch zu langsam?
Sketch stürzt ab?

---

@Klaus3 Die Arduino-Begrifflichkeiten sind hier nicht unbedingt ein Thema und aus der ursprünglichen Zielrichtung des Arduino-Projektes abgeleitet: Tinkering (Basteln) von nicht-programmieraffinen Personen die mal eben so ein Programm skizzieren, ohne Anspruch auf Perfektion.
In der Arduino-Welt ist ein Sketch auch etwas mehr, das ist mit dem Begriff Projekt in anderen IDEs vergleichbar. Wenn man weiß wovon man im entsprechenden Kontext spricht bzw. schreibt ist da auch nix untechnisches bei.

hi,
danke für das zahlreiche Echo !

"20 Sensoren sind nicht gleich 20 Sensoren. Frage ich die per I2C-Expander ab der bei Änderung an einem PIN einen Interrupt generiert frisst das kein Brot, frage ich jeden Pin einzeln ab, eventuell noch mit Delay für's entprellen gute Nacht. "

Die Sensoren sind TTP223, da gibts kein Prellen, direkt an PIn xxx digitalRead..funzt wunderbar..
Die LED's werden nur ein- bzw ausgeschaltet, wenn eine Weiche mittels Servo gestellt wird..da hört man ja kein Klicken wie bei den elektromechanischen.

Ich fahre Gleichstrom-Loks Epoche I-III in Spur N..das ist alles so winzig..weiß nicht, wo da noch ein Dekoder reinpassen soll..zum "energiereichen" Fahren habe ich
mir einen extra PWM-Handregler gebaut an langem Kabel..ähnlich (wie bei ner IR-Handbedienung meiner zusätzlichen Märklin-H0-Klappbahn, die
fahrstrommäßig MIT Decoder und IR-Handregler betrieben wird).. ich bin also Nicht grundsätzlich gg Digitalbetrieb !

Aber das ist für mich noch "eine andere Welt"
Will auch möglichst was von dem verstehen, was da abgeht..ist für mich mit reinem Gleichstrom+PWM-Betrieb erstmal einfacher UND BILLIGER !


Ich sage auch lieber "Programm" statt Sketch..habe an die 40 Jahre Anwendungen in PAscal und Java mit Datenbankanbindung geschrieben..naja,bei
Hardwaresachen kenne ich mit nicht ganz so gut aus und erwarte da nicht irgendeinen Kompfort..mit Arduino-IDE und zahlreichen Hilfen kommt man da
aber so schnell rein, daß es anfängt, Spaß zu machen !

Aber mein Hauptziel ist meine Schweizer N-Spur-Anlage (3,0 * 1,0m) mit Fahrstraßensteurung und ich will auch mal nur dumm spielen

hoffe, die nächsten Tage meine reduzierte Steurung erstmal in Gang zu kriegen..

Wenn der 2560 wirklich zu langsam wir müsste man das Programm bzw. die Programmlogik mal auseinanderpflücken. Zeitfresser sind grundsätzlich Delays jeder Art, gerne auch mal Schleifen die irgendetwas hochzählen und dabei das restliche Programmblockieren. 900 Zeilen ergeben im Schnitt etwa das vierfache an Maschinenbefehlen, macht 3600. Bei 16MHz werden die meisten in einem Takt verdaut, ein paar Multiplikationen und Divisionen dabei und langsame Zugriffe auf das Display sollte der komplette Sketch ein- bis zwei ms brauchen...

hi,

also ich habe delays Nur bei digitalRead nach Sensorabfrage und nach dem servo.Write (jeweils 30),
außderdem nach LCD-Ausgabe (1000).

Serial bleibt unbenutzt ,da an der Anlage keine Ausgabemöglichkeit außer dem Lcd besteht.

Inwieweit LCD-Ausgaben das Prozessorverhalten beeinflussen könnten, weiß ich nicht.

Zitat von lupus51 im Beitrag #10

---

also ich habe delays Nur bei digitalRead nach Sensorabfrage und nach dem servo.Write (jeweils 30),
außderdem nach LCD-Ausgabe (1000).

---

Hallo,

Zitat von lupus51 im Beitrag #1

---

Jedenfalls repeated er im Setup

---

Diese delays erklären einiges, 30 ms mal 20 Eingabegeräte = 0,6 Sekunden, die 1000 ms beim Display sind eine Sekunde, das ist happig!
Wenn ich z.B. das Display nur alle Sekunde aktualisieren will teile ich das auf zwei Funktionen auf:
Zählervariable anlegen:
long disp.millis = 0;
und die Verzögerung definieren:
int disp.time = 1000; //Intervall in ms

Als loop() aufgerufen:

if(disp.millies <= millis()){ //alle in disp.time definierten ms die Display-Aktualisierung aufrufen.
disp.millis = millis() + disp.time;
Display();
}

Funktion:
void Display(){
// hier alles was für die Display-Ausgabe nötig ist
}

Bei jedem Durchlauf von loop() wird geprüft ob disp.millis kleiner millis() ist. Wenn ja auf millis() + 1000 gesetzt, das Display aktualisiert und weiter geht's.
Anstelle einer Sekunde des Delays dauert das Prüfen nur ein paar µs..
Dieses Vorgehen lohnt ab 2-3 ms Delay, es gibt auch micros() die in Mikrosekunden hochzählen. Muss das Timing präzise sein kommt man nicht um die Timer und Interrupts herum.
Beim Servo.write ist es wichtig nur etwas zu schreiben wenn sich wirklich was geändert hat. Dabei sollten die Schreibvorgänge auch mindestens eine Periode (20 ms) des Servo-Signals auseinander liegen.
Einfach ohne Prüfung auf Änderung delay-frei die Servos schreiben sähe dann so aus:

long servo.millis = 0;
und die Verzögerung definieren:
int servo.time = 30; //Intervall in ms

Als loop() aufgerufen:

if(servo.millis <= millis()){ // all mit servo.time definierten ms die Servos aktualisieren.
servo.millis = millis() + servo.time;
Servos();
}

Funktion:
void Servos(){ //alle Servos mit frischen Werten versorgen
servo1.write(xx);
...
...
}

Braucht zwar durch die Zähler-Variablen mehr RAM, aber spart mächtig Maschinenzyklen. (30 ms @ 16MHz = 480.000 Zyklen = 480.000 Befehle oder 120.000 Multiplikationen...)

Wenn millis() alle etwa 50 Tage non-stop-Betrieb des Arduino einen Überlauf hat hängen diese Schleifen resetpflichtig... Lässt sich aber bei bedarf auch abfangen.

delay() is dein Feind, v.a. wenn Sensoren abgefragt und verarbeitet werden sollen und das Programm viele Dinge quasi parallel machen muss.
In der Wartezeit macht der µC nämlich sonst nichts, außer dumm zu warten.

Es ist immer besser, mit millis() und verschiedenen Vergleichwerten für verschiedene Ereignisse zu arbeiten.
Sobald diese Zeitspannen überschritten werden, führt der Sketch, das Programm, die App (wir wollen doch hier keine Grundsatzdiskussion von Zaun brechen ) entsprechenden Code aus.
Man kann sich das wie einen Zeitstrahl vorstellen, auf dem immer wieder Erinnerungstermine gesetzt sind, zu denen dann etwas passieren soll.

BTW: wenn man die if-Bedingung richtig macht, spielt der millis()-Überlauf nach 49,xxx Tagen keine Rolle.

if (aktuelleMillis - letzteMillis >= Intervall)
 

Aber der TO hat immer noch nicht beantwortet, was eigentlich nicht funktioniert, vgl. meinen Fragen oben.

@Domapi Hast recht, Knoten im Hirn, von wegen der If-Bedingung.

Hallo Rhoenwolf,

Zitat von lupus51 im Beitrag #1

---

also mit meiner "protokoll-freien" N-Spur-Moba" komme ich offenbar schon an die Grenzen des Arduino Mega :20 Sensoren(TTP) ebensoviele LED\'s , 20x4-LCD, 5PWM-Pin\'s belegt und 900 Zeilen Code : anscheinend schon zuviel

---

zu
"Verstehe ich das richtig, dass der Arduino immer neu startet?"
: Ja

Das klingt nach einem Programmfehler, durch den fälschlicherweise Ram-Speicher überschrieben wird. Das kann z.B. leicht beim Zugriff auf Arrays passieren. C++ hat da keinerlei Schutzmechanismen. Auch die intensive Verwendung der 'String' Klasse kann solche Nebeneffekte haben.

Ständiges Neustarten kann auch ein Stromversorgungsproblem sein. Der Onboard-Spannungsregler kann den Arduino zwar theoretisch direkt aus der 12V-Schiene versorgen, wird dann aber reichlich warm. Für den Dauerbetrieb versorge ich Arduinos grundsätzlich mit extern erzeugten 5 oder 3,3V, je nach Typ. Kleine Schaltreglermodule gibt es ja en masse. Auch (teil)defekte Arduino-Clones hatte ich schon, mit beschriebenen instabilen Verhalten.
Hab erst dieses Jahr bei einem Freund eine Terrarium-Steuerung gebaut, mit Grafik-LCD, Menüführung, RTC etc. Steuert Temperatur (5 Sensoren, zwei Heatpanels via SSR), Luftfeuchtigkeit (zwei Sensoren, eine Pumpe via FET), Licht (Weiß + RGB, mit Sonnenauf- und Untergang, PWM via FET..), Belüftung (anhand Temerauturdifferenzen, Lüfter via FET), protokolliert alles auf SD-Karte und kriegt jetzt noch ein ESP8266-Modul um von Überall den Status abzufragen... Längster Non-Stop-Betrieb gut zwei Monate, dann hatte ich die Firmware nochmal überarbeitet und der Neustart war unumgänglich...Board ist da ein Mega2560-Clone. Ein grundsätzliches Stabilitätsproblem auf Hardwareebene dürfte es also nicht geben.

Na, dann poste doch mal den Sketch, am besten incl. eines Schaltplanes der angeschlossenen Komponenten - und bitte kein FRITZdings-Bildchen.
Eine kleine Beschreibung, was der Sketch theoretisch tun soll, ist auch hilfreich, genauso, wie eine Fehlerbeschreibung.

Durch ein paar PRINT-Ausgaben kannst Du zumindest in der setup() herausfinden, wo der µC aussteigt.

Stahlblauberlin war schneller: Manchmal liegt es auch an der Stabilität der Spannungsversorgung.

Oder an der falschen Verwendung von Bibliotheken.

Hallo,
wie Franz-Peter schon schrieb deutet das auf einen Bereichslängenfehler hin, z.Bsp. beim Zugriff auf Arrays.
Kannst du eine Fehlermeldung erkennen?
VG Jo

hi,

würde ja gerne den Sketch hier darstellen, aber ca 900 Zeilen Code ?
Leider finde ich bei diesem Editor in Icons rechts Keine Möglichkeit, z.B. ein Zip-File "beizuhängen" ?
bei anderen Online-Plattformen gibts sowas schon..
dafür das hier:
Datei von filehorst.de laden

außerdem kann ich eine schematische Darstellung liefern, damit man sieht , was wie versorgt wird..


und außdem gibts nen schematisierten Gleisplan (klassische 8) :




zu millis : in "forum.arduino.cc" im englischsprachlichen Bereich hab ich auch schon meinungen gefunden, die die "Vorteile" von
millis in Abrede stellten..

Zitat von lupus51 im Beitrag #22

---

zu millis : in "forum.arduino.cc" im englischsprachlichen Bereich hab ich auch schon meinungen gefunden, die die "Vorteile" von
millis in Abrede stellten..

---

Hallo,
hab dein setup() nur kurz überflogen.
Meine Vermutung: du initialisierst dein obr[idx] von 0 ..43 greifst aber in Z616 auf idx= 44 zu!
VG Jo

"Hast Du dir mein Tutorial mal angeschaut?" :
sorry, habs angeklickt, aber mangels Zeit noch nicht eingehender betrachtet..wollte erstmal hier was aussagekräftigeres reinstellen..
das braucht auch n paar Minuten..
aber "wir schaffen das"

Zitat von MicroBahner im Beitrag #23

---

Hast Du einen Link wo Du das gelesen hast?

---

Zitat von Jo2 im Beitrag #24

---

du initialisierst dein obr[idx] von 0 ..43 greifst aber in Z616 auf idx= 44 zu!

---