Fletchers-Corner

Hab's mir schon gedacht. Du pollst also in loop() auf den Interrupt. Das kostet dich einen Haufen Rechenleistung
und ist nicht noetig.
Schieb deinen ganzen Code von loop() nach countA() und schreib in loop() nur einen sleep(10) rein. Dann schlaeft
das Programm solang, bis der Interrupt kommt, tut was es tun soll und schlaeft dann weiter. Waerenddessen hat
das Betriebsystem Zeit die Daten wegzuschreiben. Die Variablen muessen dazu global definiert sein, aber das hast
du eh schon so gemacht.

Hmm das ist etwas gefährlich. Man soll ISR (Interrupt subroutinen) so kurz wie möglich halten. Wenn der nächste Interrupt kommt bevor die aktuelle ISR durch ist, schlägt die Auswertung fehl und das Programm macht komische Sachen. Der Code in der ISR sollte daher mit nointerrupts geschützt werden damit der Code auf jeden Fall den aktuellen Wert zuende verarbeitet.
Außerdem muss alles aus dem loop verschwinden, dass nicht bei jedem cycle ausgeführt werden muss. Das würde ich in eigene Funktionen auslagern und nur die Bedingungen dafür in der Main loop abfragen.

Aber so wie's grad ist pollt er mit Vollgas auf das Flag. Das kann's ned sein. Dann kannst den Interrupt gleich bleiben lassen
und auf den Eingang poillen.
Wenn er in loop() eine langen sleep reinmacht, holt ihn da der Interrupt raus? Wenn ja koennt er danach das Flag abpruefen,
so wie er das jetzt auch schon macht.

Hallo,
ich hatte die ISR so kurz gehalten, da dies die gängige Meinung in Programmiererkreisen war.
Natürlich läuft im Loop permanent die Abfrage, ob sich der Status, der im Interrput gesetzt wird, geändert hat.
Ist das schlimm? Wenn die Werte weggeschrieben sind, muss der Prozessor ja auch eine Daseinsberechtigung haben, ob er jetzt schläft oder anfragt, er hat ja nichts besseres bzw wichtigeres zu tun?
Die erste Fassung sah tatsächlich so aus, dass ich direkt im Loop den Port abfragte, also ohne Interrupt. Ging genauso gut oder schlecht, wie man es nimmt. Meine Frage ist nur, was ist, wenn ich gerade beim Abfragen der Kraft und Wegschreiben der Werte bin, und jetzt durch das Kurbeln der nächste Puls kommt? Mein Verständnis war, dass der Interrupt diese Arbeit kurz unterbricht, dann wird im Interrupt das Flag gesetzt, das etwas war, und danach kann der loop da weitermachen, wo er stehengeblieben war, nämlich beim Datenschreiben. Wenn er dabei ständig unterbrochen wird, gibt es Verluste.
Andererseits, bei direkten Abfragen des Ports konnte es passieren, dass der Puls am Eingang einfach unentdeckt blieb, da der Prozessor gerade beim Schreiben war.
Ich verstehe jetzt noch nicht genau, wie diese Verluste eliminiert werden, wenn ich entweder alles in den Interrupt setze oder alles in Functions stecke. Wenn der prozessor länger braucht zum Daten verarbeiten als bis zum nächsten Puls, dann hat er doch immer Streß, oder?
Rainer

Rainer_K hat geschrieben:Wenn der prozessor länger braucht zum Daten verarbeiten als bis zum nächsten Puls, dann hat er doch immer Streß, oder?

Ja, genau das. Ist ein typisches Problem z.B. bei Maschinensteuerungen. Wenn du nimmer nachkommst, geht's in die
Binsen....
Aber generell ist es nicht gut Rechenleistung zu verballern. Das Betriebssystem tut ja hin und wieder auch noch was.
Meine Idee oben war halt, dass es so zeitmaessig noch reichen koennte.

Probier mal loop() schlafen zu zu lassen, bevor du das Flag abfraegst. Normal muesste es da rausgeholt werden, wenn
der Interrupt auftritt. Und lass die Datei mal offen.
Aber generell waere es besser, alles in ein Array zu schreiben und erst am Ende in ein File. Wenn Floats zu gross
sind kannst auch durch geschickte Skalierung Integers nehmen. Wenn dir zB. 2 Nachkommastellen reichen
multiplizierst einfach mit 100, bevor du den Wert als int ablegst und wenn du ihn dann wegschreibst dividierst du
wieder durch 100.

Habt ihr eigentlich alle eine Kristallkugel, oder hab ich übersehen, wo der Code angehängt ist?

12. Post in diesem Thread. Der erste von den Anhaengen ist ein zip-File mit dem Code.
Hab auch ein wenig gebraucht....

Ja ich würde das auch so machen. Schreibe eine Funktion, z. B. namens writetosd(filehandle, wert) die du z. B. alle x pulse aufrufst. Die Funktion öffnet und schließt die Datei aber nicht sondern schreibt nur.
Geöffnet und geschlossen wird nur am Anfang und am Ende der Messung. Das sollte erheblich Performance bringen.

Ein Interrupt unterbricht ALLES, sogar wenn der Prozessor gerade 1+1 ausrechnet, wird die Berechnung unterbrochen und der Interrupt ausgeführt. Der Interrupt ist quasi Gott wenn man so will. Auch die Interrupt Routine wird unterbrochen, wenn innerhalb dessen Ausführung ein neuer Interrupt erfolgt.
Echtzeit Anforderungen sind leider manchmal ziemlich tricky

hallo zusammen,
ich habe noch ein wenig weitergewerkelt an der Kraft-Weg Messung.
Die Arduino software ist ein wenig getunt, soweit es geht werden die Messwerte in einen Ringspeicher geschrieben und wenn Zeit bleibt auf die SD Karte. Damit konnte die Anzahl der Messpunkte weiter erhöht werden.
Ausserdem habe ich eine Schrittmotorvariante und eine mit Gleichstrom Getriebemotor. Auf den Bilder die mit dem Getriebemotor.
Der Messablauf ist jetzt folgendermaßen:
- Bogen befestigen und Gerät auf Standhöhe fahren
- Messelektronik einschalten
- Standhöhe in mm eingeben, dabei wird die letzte Standhöhe aus dem Speicher gelesen, Änderungen mittels Drehgeber und dann bestätigen
- Mit dem Wippschalter kann der Motor vorwärts und rückwärts drehen. Währeds des Verfahrens wird Standhöhe und zugehörige Kraft angezeigt. Es kann jederzeit beliebig vor- und zurück gefahren werden. Ich fahre meist zum Endauszug und dann wieder auf Standhöhe.
- Karte abziehen und Messwerte verarbeiten

die dargestellten Kurven sind die direkte gemessene Kraft-Weg Kurve und die Ableitung als Differenzenquotient und geglättet

Von der Schrittmotor Variante habe ich dann letztlich Abstand genommen, sie brachte keinen Vorteil im Vergleich zum Getriebemotor

Rainer

Cool. Wie lange brauchst Du für eine Messung?

Was mich nur irritiert, ist die 1. Ableitung. Wenn die so zumzackt, ist in den Rohdaten viel Datenmüll dabei. Da sollte man vielleicht zunächst mal die Daten aufbereiten, denn so sieht das nicht überzeugend aus. Bei ca. 27 " sieht man den Haken ja schon in der Auszugskurve.

hallo MBF,
die Messung dauert ca. 2 Minuten. Es ginge auch schneller, dann bräuchte ich einen schnelleren Motor. Der müsste für das gleiche Drehmoment wieder größer sein oder ich gebe über ein Netzgerät 24V drauf, dann rennt er natürlich auch schneller.
Da ich bei den Rohdaten direkt den Differenzenquotienten nehme und die Messwerte alle 2mm erfolgen , führen schon kleinste Unstetigkeiten in der Messung zu diesen Ausschlägen. Wenn ich die Messkurve zuerst glätte, dann fallen die Unstetigkeiten natürlich weg, aber die Aussagekraft der Kurve wird für mich dadurch nicht besser, nur schöner.

Rainer

Hm. Wenn Du bei dem Grundrauschen im System mal die Vertrauensbereiche über die 1. Ableitung legst, wird der Statistiker nur den Kopf schütteln. Ein R^2 von 0,8 ist schlichtweg zu schwach für das, was zu erwarten ist. Das solltest Du wirklich mal drüberschauen, wie man das ohne Verlust an Information besser hinbekommt. Ich plädiere für einen guten Fit der Auszugskurve und dem Weiterrechnen mit diesem Polynom.