Hallo,
einen arduino mega vollprogrammiert mit C-Befehlen, wie lange dauert ein loop maximal?

sinnvolle Einschränkungen:

1. keine Mehrfachaufrufe von Unterprogrammen, auch nicht wie "servo" aus Biblotheken.

2. lineare Arbarbeitung des Programmes ohne Schleifen wie "while, for usw.".

3. bei if, else fürjeden Zweig etwa gleichviel Befehle.

4. kein Aufruf von "wait".

Ich frage wegen der Mindestzeit für Eingangssignale damit die sicher vom Programm erkannt werden, z.B. Lichtschranken oder andere Sensoren.

Gruß

Zitat von SET800

---

Hallo,
einen arduino mega vollprogrammiert mit C-Befehlen, wie lange dauert ein loop maximal?

---

Das ist die völlig falsche Grundannahme! Erst mal gibt es keine C-Befehle im Controller und es ist auch an sich völlig unerheblich, mit welcher Sprache die Befehle erstellt wurden. Letztlich ist es der Binaercode, denn man als Assembler dann als Mensch besser lesen kann. Nehmen wir an, Du hättest einen Atmega128, also 128k Flash Speicher und jeder Befehl darin braucht 2 Bytes und durchschnittlich etwa 1,5 Zyklen bei 16 MHz, dann wäre der Controller in rund 6ms durch. Aber bitte wozu ist eine solche Betrachtung gut?

Zitat

---

Ich frage wegen der Mindestzeit für Eingangssignale damit die sicher vom Programm erkannt werden, z.B. Lichtschranken oder andere Sensoren.

---

So läuft das einfach nicht

Entweder nutzt man Hardware-Interrupts, die bei einem Pegelwechsel auf dem Pin oder einem Pin auf einem Port, je nach Controller gibt es da unterschiedliche Möglichkeiten, eine entsprechende Unterroutine ( Interrupt-Handler) aufrufen oder man muß zwingend die elektrischen Signale so verlängern, daß sie auch eingelesen werden können. Das kann man unter anderem auch durch aktives rücksetzen erreichen. Man baut damit quasi eine Quittung vom Programm ein, so daß kein Signalwechsel verloren geht. Aber das wäre schon eine sehr umständliche Variante.

Gängige Praxis ist aber Interrupt oder das schnelle zyklische Abfragen in einem Timer-Interrupt, falls nicht für alle benötigten Eingangspins ein Pegel-Interrupt zur Verfügung steht.

Ich schlag mal vor, Du schaust Dir erst mal an, was ein Interrupt ist, wie man den in C porgrammiert und wozu das gut ist. Wenn Du das mal ausprobiert hast, wirst Du schnell feststellen, daß Du gerade auf dem Holzweg bist

Viel Spaß!
Klaus

P.S. Die wirklichen Ausführungszeiten, auch die Latenzzeiten bei Interrupts usw, bestimmt man normalerweise mit Simulatoren. Für den AVR zum Beispiel mit simulavr. Beim Simulavr kannst Du dann auch wie auf einem großen PC debuggen und die Hardware um den Controller herum simulieren, also Eingangspins per Script oder Programm vorgeben. Dann siehst Du befehls-genau die Abbarbeitung Deines Programms auf dem Controller, noch bevor die Hardware überhaupt fertig ist.

Hallo,
6ms wäre doch schon mal ein Wort.

Wenn ich mit einem Hallsensor den Zugschluß ekennen möchte, nehme ich Faktor 3 = 20ms, also 3 Programmduchläufe in der Zeit..

Dann 2cm Wegstrecke über die der Sensor den vorbeirollenden Waggon mit Magnet erkennt dann würde das bei Geschwindigkeiten von 2cm/20ms = 1m/s sicher funktionieren. Recht für ICE-2....

Hallo,

Ich kann Klaus nur beipflichten: Ein Ereignis eines Sensors im Programm abzufangen ist eine typische INTERRUPT - Anwendung. Alles andere funktioniert vielleicht. Oder oft. Aber nicht immer. Hier gibt es ein einfaches und verständliches Beispiel: http://fluuux.de/2013/04/interrupts-mit-arduino-benutzen/

mfg

D.

Zitat von SET800

---

Hallo,
6ms wäre doch schon mal ein Wort.

---

Hast Du den wesentlichen Teil meiner Antwort nicht gelesen?

Ich bin wirklich gerne bereit auch längere Hilfestellungen zum Thema für Einsteiger zu geben. Wenn es aber schon damit anfängt, daß Du Deinen ganz offensichtlichen Denkfehler lieber fortsetzen willst, anstatt auf meine/unsere Antworten einzugehen, dann erscheint auch mir das für uns beide nicht hilfreich.

Programmieren ist halt nicht nur eine Programmiersprache erlernen. Bei C wäre das denkbar einfach, hat diese doch gerade mal eine Hand voll an Schlüsselworten, die man halt mal einfach geschickt kombinieren müßte. Aber die "Kunst" des Programmierens ist es eben, Abläufe der Natur in die erst einmal immer nur lineare Programmausführung zu übertragen. Und da kommt man dann nach ganz kurzer Einarbeitung in eine Programmiersprache direkt in die sogenannten "Design Patterns." Diese beschreiben eine Vielzahl der immer wiederkehrenden Programmierprobleme und die typischen Lösungen dafür und das unabhängig von einer konkreten Programmiersprache.

Nehmen wir mal völlig theoretisch an, Du willst einige dutzend Sensoren einlesen. Das ist ja nicht schwer, solange das Programm schnell genug reagiert, OK. Und was passiert dann? Es soll doch in Abhängig von einem Jetzt-Zustand eine Folge von zeitlich gestreckten Folge-Zuständen gewechselt werden. Nehmen wir nur mal an, Du willst eine Weiche schalten mit einem Magnetantrieb. Dann wäre ja festzuhalten, in welcher Stellung die Weiche jetzt ist, welche Zustände Nachbarweichen haben, ob es weitere Belegungen durch andere Fahrzeuge gibt usw. Und dann willst Du erst einmal den Kanal anwählen, auf dem dann in einem weiteren Schritt Strom fließen kann, der in einem weiteren Schritt wieder abzuschalten ist usw. All das aber nicht einfach per C-Befehl nacheinander, denn das ginge alles so schnell, daß da nicht einmal ein Strom fließen würde, weil die Induktivität des Antriebs da faktisch ein sehr hochohmiger Widerstand wäre.

Nee, alles in einer großen Schleife mit hunderten von "Zustandsvariablen" ist niemals eine Lösung für ein reales Programmierproblem. Zudem wären schon die durch Verzweigungen im Programmablauf entstehenden Laufzeitunterschiede in einem trivialen Programm nicht mehr sinnvoll handhabbar.

So schön unsere Bastelwelt dank AVR und ARM basierten Arduinos geworden ist und so toll man auch einen Raspberry mal eben als komplette Anlagensteuerung nutzen kann, umso weniger sind die Aufgaben, die man damit erledigen kann einfacher geworden. Ob man nun eine Kiste Relais und Schalter verdrahtet oder per C-Programm das gleiche auf einem uC realisiert, ist eigentlich egal. Es muß einfach ein tragfähiges Konzept dahinter stecken, soll das ganze nicht in einen riesigen Krampf münden. Und Deine Idee von einem Programm ist der Anfang eines solchen! Glaub es uns bitte vorher Es schont einfach Deine Zeit und Deine Kosten!

Und nun nochmal was zu Ausführungszeiten:
Das Problem bei uC Anwendungen ist nicht, daß diese zu langsam wären, sondern das sie viel zu schnell sind! Mit einem Interrupt an einem Pin bist Du innerhalb von 3 Zyklen in Deiner Ausführungsroutine ( Interrupthändler ). Aber was heißt das wirklich? Das bedeutet, daß jeder kleine elektrische Drecksimpuls einen Interrupt auslöst und Dir einen Zustand vorgaukelt, der ggf. real gar nicht da ist. Jetzt kannst Du elektronisch Filtern, z.B. RC Ketten davor hängen. Die müssen aber schon mal alle wesentlichen auf der Moba existierenden Störungen unterdrücken. Und glaub mir, da geht dank der hohen Ströme wegen der kleinen Spannungen erheblich mehr ab, als in einem Schaltschrank eines Industrieroboters! Und mit diesen Filtern bist Du nun weit jenseits der programmtechnisch möglichen Detektionszeiten. In der Praxis macht man nun beides: Man zieht die Signale auf mindestens 3 Taktzyklen und den Rest macht man dann per Mehrfach-Messung in Software. Und noch ein Hinweis speziell zum AVR: Der Pegel am Pin muß mindestens für 2 Zyklen stabil angelegen haben, sonst erscheint der Interrupt nicht immer, da intern im uC die Pegel auch gesampelt werden. Es ist kein echter Flankeninterrupt, sondern ein Vergleicher. Das ist für sehr schnelle Signale wesentlich, je nachdem was Du nun so vorhast. Dazu einfach mal ins Datenblatt schauen.

Gruß
Klaus

Hallo,
ich denke an das Konzept der SPS, anfangs des loops alle Eingänge lesen, auf Datenbits/Bytes/Wörter ( vulgo Merker ) abspeichern, diese mit internen Daten vernknüpfen und dann davon programmlogikabhängig Ausgänge setzen.
( linears Programmieren auch mit Verzweigungen, Überspringen bei "Schrittketten" und/oder aufrufen von Unterprogrammen, Funktionsbausteinen )

Jetzt benötige ich aber die Durchlaufzeit um zu wissen wie kurze Eingangssignale noch sicher erkannt werden.

In der SPS-Welt wird das NICHT generell mit Interrupts gemacht sondern allenfalls Eingänge die als flipflop geschaltet den Ein-Zustand bis nach dem Auslesen festhalten. Hardwarebaugruppen "schnelle Zähler" und ähnlich.


Alles in allem, ein Zustandsautomat. Die internen Speicher stellen den Zustand dar, Zustandsänderungen ergeben sich je Zyklus aus der Programmlogik die die internen Zuständen und Eingänge verknüpft.

Zitat von SET800

---

Ich denke an das Konzept der SPS, anfangs des loops alle Eingänge lesen, auf Datenbits/Bytes/Wörter ( vulgo Merker ) abspeichern, diese mit internen Daten vernknüpfen und dann davon programmlogikabhängig Ausgänge setzen.

---

Grundsätzlich ist das schon richtig, dass man das so machen kann. Nur dein Ansatz die loop-Zeit vorher bestimmen zu wollen ist vollkommen daneben - das geht so nicht. Du schreibst das Programm ja letztendlich um eine bestimmte Funktionalität zu erreichen, und nicht um den Programmspeicher von vorn bis hinten zu durchlaufen. Da kommen dann - je nach Anwendung - vollkommen andere Loopzeiten zustande. Ich hatte Dir ja schonmal die Loop-Zeiten von meinem Zubehördecoder genannt - da reden wir von 100...500µsec im derzeiten Entwicklungsstand ( auch das wird sich noch ändern ). Zur Decodierung z.B. des DCC-Signals bleibt da nur der IRQ - das geht im loop nicht.
Auf der anderen Seite steht z.B. meine Schattenbahnhofsteuerung, auch mit einem ATMega. Die hat Loopzeiten von um die 100ms, also fast das 1000fache!. Da werden über 100 Eingangssignale verarbeitet - SPS-mäßig und ohne Interrupts. Auch das geht bei entsprechender Auslegung der HW. Es kommt also immer auf den Einzelfall an. Und da muss man - wie schon Klaus schrieb - ein passendes Konzept für SW und HW entwerfen.

So pauschal wie Du das angehst, funktioniert es nicht - oder eher zufällig.
Um ein Gefühl für die Leistungsfähigkeit des Arduino zu bekommen, musst Du mal ein konkretes Programm für deine Anwendung schreiben, und da die Loop-Zeiten messen. Dann kannst Du abschätzen, wie Du die HW auslegen musst und ob dein Vorhaben funktionieren kann. IRQ's funktionieren ja auch nur für eine begrenzte Anzahl von Eingängen. Gegebenenfalls musst Du halt die HW anpassen, damit die Signale lang genug anstehen. Da Du von einem Arduino Mega redest, gehe ich davon aus, dass Du mehr als einen Sensor anschliessen willst. Damit erhöht sich der Auswerteaufwand und damit auch die Loopzeit. Wie Klaus schon schrieb, hängt es auch davon ab, was Du an den Ausgängen ansteuern willst. Das konkrete Gesamtkonzept ist entscheidend für Erfolg oder Misserfolg - und keine Pauschalaussagen.

Hallo,
danke für die Erklärungen. Die Probleme sind mir durchaus bewußt, deshalb fragte ich ja nach der Maximalaufzeit wenn der Programmspeicher voll wäre, alle Befehle im loop abgearbeitet werden und KEINE Schleifen ( while, wait ) oder Mehrfach-Unterprogrammaufrufe stattfinden.

gruß

Zitat von SET800

---

deshalb fragte ich ja nach der Maximalaufzeit wenn der Programmspeicher voll wäre, alle Befehle im loop abgearbeitet werden und KEINE Schleifen ( while, wait ) oder Mehrfach-Unterprogrammaufrufe stattfinden.

---

Das ist genau deine Milchmädchenrechnung - so ein Programm gibt es in der Praxis nicht, und deshalb kannst Du so auch keine Maximallaufzeit bestimmen.

Hallo,

Zitat von SET800

---

In der SPS-Welt wird das NICHT generell mit Interrupts gemacht sondern allenfalls Eingänge die als flipflop geschaltet den Ein-Zustand bis nach dem Auslesen festhalten.

---

eine Idee: Wenn man das SPS-Konzept übertragen will, und ohne Interrupts arbeiten, dann könnte man doch auch allen Eingängen ein Set-Reset-NAND Gatter vorschalten (typ 4044 oder so), dann werden alle Statusänderungen gehalten, man fragt sie in Ruhe ab und Reset dann die Gatter. Kein großer Aufwand oder Kosten.

Zitat von franz_H0m

---

Hallo,

Zitat von SET800

---

In der SPS-Welt wird das NICHT generell mit Interrupts gemacht sondern allenfalls Eingänge die als flipflop geschaltet den Ein-Zustand bis nach dem Auslesen festhalten.

---

eine Idee: Wenn man das SPS-Konzept übertragen will, und ohne Interrupts arbeiten, dann könnte man doch auch allen Eingängen ein Set-Reset-NAND Gatter vorschalten (typ 4044 oder so), dann werden alle Statusänderungen gehalten, man fragt sie in Ruhe ab und Reset dann die Gatter. Kein großer Aufwand oder Kosten.

---

Leute, so schwer ist die Welt doch gar nicht!

Wenn ich mit Relais arbeite, dann muß ich die volle Schaltzeit haben und kann dann in die Selbsthaltung gehen
Wenn ich mit Logik-Gattern arbeiten will, dann muß ich halt alles von Hand verdrahten
Und wenn ich es mit einem Controller machen will, dann muß ich halt lernen wie man den programmiert.

Gatter und Programm ist in diesem konkreten Fall wie Torte mit Senf.

Ich denke, ich bin hier raus... Konkrete Fragen gerne, aber das wird mir hier leider zu unsinnig!

Gruß
Klaus