Funktion erstellen

ist sicher eine Kleinigkeit für einen erfahrenen Arduinonutzer.

Is klar....
Keine Fragen ...
Alles klar...

Nachdem ich ja schon stundenlang Bücher über C programmieren ...

Da steckt schon mal ein Irrtum!
Arduino ist C++, nicht C.
Und ja, das macht einen Unterschied.


Deine ISRs nutzen Funktionen/Methoden, welche ihrerseits ISRs benötigen/nutzen.
Das geht ins Auge, da Interrupts in ISRs grundsätzlich erst mal gesperrt sind.

Zusätzliche Stichworte: volatile und atomic


Zu deinem Array "WertTaste"
Ich sehe keinen Schutz, welcher das Schreiben über das Arrayende hinweg, verhindern würde.
Auch erwartet atoi() einen C- String, mit einem Null Byte als Begrenzer.

Was hat der Interrupt mit meiner Funktion keyInput zu tun?
Arrayende,ist das nicht durch [4] gegeben?
Und sehr eigenartig finde ich das der ganze Sketch in der ersten Version ohne meiner keyInput wie gewünscht funktioniert.Danke trotzdem für deinen Denkanstoss combie,werde das weiter verfolgen sobald ich die Sache mit der Funktion gelöst habe.
Hat vielleicht jemand einen Tipp der sich auf keyInput bezieht?
Gruss

Arrayende,ist das nicht durch [4] gegeben?

Wie kommst du darauf...?

Du reservierst 4 Speicherplätze, mehr nicht.
Im Programm ignorierst du die sich daraus ergebene und auch notwendige Grenze.
Dein C++ kennt da keine Gnade, das schreibt gerne über das Ziel hinaus, wenn du ihm das befielst.

Beispiel:
Ist der Autofahrer für das lesen der Schilder zuständig, oder das Auto?

Und das ist der Grund das die Funktion nicht funktioniert? Na das muss mal wer verstehen.Hut ab vor den c++ Programmierern..
Danke sehr.
Dann bleib ich wohl lieber bei der Version ohne Funktion,die funktioniert wenigstens.
Gruss

Und das ist der Grund das die Funktion nicht funktioniert?

Das habe ich nicht gesagt.
Ist aber durchaus möglich.

Na das muss mal wer verstehen.Hut ab vor den c++ Programmierern..

Naja...
Ich würde dazu neigen, solche Situationen zu vermeiden.
Im Vorfeld schon.

Aber sowas fällt einem nicht von selber zu.
Dazu muss man diese Falle schon mal gespürt haben.

Wer einmal stundenlang einen solchen Fehler gesucht hat, investiert die 2 Minuten im Vorfeld gerne.

Dann bleib ich wohl lieber bei der Version ohne Funktion,die funktioniert wenigstens.

Kannst du natürlich tun...

Aber ob das die beste Idee ist? Naja....

Mein Rat:
Eliminiere alle Interrupts, es sei denn, sie sind unbedingt nötig.

Und wenn du Interrupts nutzt, dann denke an volatile und atomic. (sachte ich aber doch schon)
Auch eine der Fallen, die man mal gespürt haben muss.
Möglich, dass dir das auch hier ins Essen spuckt.

Teile den Code sinnvoll in Zuständigkeiten auf.
Jede Zuständigkeit gehört in eine Funktion oder Klasse gekapselt.
Das erlaubt die Dinge einzeln zu testen.

Ich kann vielleicht 3 Zuständigkeiten gleichzeitig im Fokus halten.
Bei 5 komme ich in Schwierigkeiten, es bildet sich ein Widerwille.

Das gilt auch für Schachtelungstiefen, von Schleifen und If Konstrukten.

Anfängern traue ich da noch weniger zu.

Ich habe Deine Sketches nicht gelesen. Mir ist nur aufgefallen:

Combie sondert wieder einmal Müll ab.

C++ ist eine Obermenge (quasi Erweiterung) von C. Du kannst also problemlos pures C programmieren.

Was das mit dem Index des Arrays angeht: In der Deklaration gibst Du die Zahl der Elemente im Array an (z. B. 5), der Index beginnt jedoch bei 0, woraus folgt, dass Du bei 5 Elementen maximal den Index 4 benutzen kannst. Wenn Du den Index 5 verwendest, erhältst Du eine Fehlermeldung („out of range“ oder so, das hängt evtl. auch davon ab, ob Du lesen oder schreiben möchtest).

Mehr ist mir auf die Schnelle nicht aufgefallen.

Allgemeiner Tipp: Strukturiere Dein Programm durch passende Einrückungen und setze die Klammern einheitlich. Das entlastet beim Lesen und ist bei der Fehlersuche Gold wert.

Soviel für jetzt, ich bin erstmal wieder AFK.

Gruß

Gregor

gregorss:
Wenn Du den Index 5 verwendest, erhältst Du eine Fehlermeldung („out of range“ oder so, das hängt evtl. auch davon ab, ob Du lesen oder schreiben möchtest).

Das ist in C/C++ eben nicht der Fall. Arrays sind anderes als in manchen anderen Sprachen kein eigenständiger Datentyp. Eine Überprüfung auf Array Grenzen findet nicht statt

Serenifly:
Das ist in C/C++ eben nicht der Fall. Arrays sind anderes als in manchen anderen Sprachen kein eigenständiger Datentyp. Eine Überprüfung auf Array Grenzen findet nicht statt

Eieiei ... da bin ich mal wieder auf die Schnauze gefallen. Was soll's, C bzw. C++ ist wohl die zehnte Programmiersprache, mit der ich mich herumschlage.

Gruß

Gregor

C++ ist eine Obermenge (quasi Erweiterung) von C. Du kannst also problemlos pures C programmieren.

Auch das ist falsch.
Es gibt genügend C Code, welcher sich nicht durch einen C++ Compiler jagen lässt.

Vor ca 30 Jahren haben sich die beiden Sprachen getrennt und sind seit dem, trotz aller Ähnlichkeit unterschiedliche Sprachen.

Und ja, Arduino mit seiner AVR Tool Chain, kann auch C Dateien kompilieren.
Aber dann sollte man sie auch *.c nennen, damit der C Compiler sie zu schlucken bekommt, und nicht der C++ Compiler.
Alles andere wäre schlampige Arbeit, und das wollen wir doch nicht, oder?

Combie sondert wieder einmal Müll ab.

Tja...
Wenn es dir damit besser geht, dann haue und steche...

Aber dann, ein Tipp:
Recherchiere besser, sonst blamierst du nicht mich, sondern nur dich selber.

Sorry,wollt hier keinen Streit auslösen.
Aber mein Gefühl sagt mir,ich habe charArray[4] weil keypad.getKey char zurück gibt,UND dadurch kann ich maximal 9999 eingeben.
Und so funktioniert mein Programm auch.Aber nur DAS wo ich keine Funktion versuche zu erstellen.
Also sieht es für mich nicht danach aus als müsste ich es begrenzen.

Aber ich werde mich auf jeden Fall an euren Tipps orientieren.(und vielleicht mal die c++ Bücher die hier rum liegen lesen).
Sonst vielleicht jemand eine Idee die mit meiner Funktion keyInput zu tun hat? Muss ich da vielleicht doch einen Parameter übergeben oder ein Denkfehler im Gültigkeitsbereich einer Variable?
Gruss

Sorry,wollt hier keinen Streit auslösen.

Da mache dir mal keine Sorgen drum...
Mit der Baustelle, hast du nichts zu tun.

Aber mein Gefühl sagt mir,

Programmieren basiert auf Logik.
Gefühle sind da oft hinderlich, ins besondere, wenn sie Wissen ersetzen.

4 mal '9' in einer Zeichenkette benötigt ein Array von der Größe 5
Dein Array ist zu klein.

Begründung:

Auch erwartet atoi() einen C- String, mit einem Null Byte als Begrenzer.

Warum holst Du vor dem Aufruf von der Funktion schon einmal die Taste mit getKey ab?
Das macht doch die Funktion dann - und die könnte auch NO_KEY zurückgeben.
Also vor der Abfrage die Funktion aufrufen; nicht hinter der Abfrage.

Gruß Walter

chubacca:
Und so funktioniert mein Programm auch.Aber nur DAS wo ich keine Funktion versuche zu erstellen.
Also sieht es für mich nicht danach aus als müsste ich es begrenzen.

Es ist so oder so falsch. Egal wo es steht. Dass das manchmal funktioniert ist reiner Zufall. Und das meine ich wörtlich. Es hängt davon was in der Speicherzelle nach dem Array steht. Also wahrscheinlich von dem Wert von WertRPM

Was ist jetzt falsch?das man es begrenzen muss oder keine Begrenzung notwendig?

Es ist falsch egal wo es steht. Ob Funktion oder nicht spielt keine Rolle
Erstens musst du schon beim Tastendrücken aufpassen dass du nicht über die Array-Grenze schreibst. Zweitens erwartet atoi() ein Null-terminiertes char Array

Serenifly:
Arrays sind anderes als in manchen anderen Sprachen kein eigenständiger Datentyp.

Deine Aussage hat mich gerade stutzig gemacht.

Immerhin:
C++ trägt sehr wohl die Größe eines Arrays mit sich rum.

Das kann man auch schön nutzen, um Bereichsüberschreitungen zu vermeiden.
Man muss es allerdings zufuß machen. Automatisch erkannt werden Bereichsüberschreitungen nur bei der Initialisierung.

Ein echter Fortschritt, gegenüber C.

Testprogramm:

using EinEigenerType = char[5];


char testA[] = "9999";
char testB[5] = "9";
EinEigenerType testC = "9";
EinEigenerType testD = "999999"; // hier wirft der Compiler eine Warnung


void setup() 
{
  Serial.begin(9600);      
  Serial.println("Start");
  Serial.println(sizeof(testA));
  Serial.println(sizeof(testB));
  Serial.println(sizeof(testC));
  Serial.println(sizeof(testD));
}

void loop() 
{
   
}

Hi

So oder so verhindert der Kompiler (zumindest hier beim Arduino) aber nicht, daß man auf das x-te Element des Array zugreift, egal, wie hoch X ist, egal ob lesend, oder schreibend.
Wie's bei einem Speicherüberlauf aussieht - kA (also wohin testA[15000] dann schaut) und oder ob die Größe des Index reglementiert ist wobei uint16_t schon recht weit hinter die Speichergrenze reichen wird.

MfG

postmaster-ino:
So oder so verhindert der Kompiler (zumindest hier beim Arduino) aber nicht, daß man auf das x-te Element des Array zugreift, egal, wie hoch X ist, egal ob lesend, oder schreibend.

Da hast du Wahr!

Und das hat auch seinen Grund!

Würde C++ diese Laufzeitprüfungen machen, dann wären die erzeugten Kompilate erheblich größer, und langsamer. Das würde der "Maschinennähe" gar nicht gut tun.
Es sind ja nicht nur die Arrays, sondern eher die Zeiger, welche in die Wiese zeigen(können)
Und auf Zeiger will man nicht verzichten.

Ein C/C++ Programmierer ist halt nicht auf Rosen gebetet, ihm wird nicht bei jeder Gelegenheit der Hintern abgeputzt.
Er ist selber verantwortlich, für das, was er/sie/es tut.

:smiling_imp: Eine gute Gelegenheit, etwas Verantwortung, Disziplin und Sorgfalt zu lernen. :smiling_imp:

Hier mal ein Progrämmchen, welches die Äquivalenz von Zeigern und Arrays vorführt:
(und ja, der Code ist Standardkonform)

unsigned long test[] {30,40,50};


void setup() 
{
  Serial.begin(9600);      
  Serial.println("Start");

  int i = 1;
  Serial.println( test[i] );
  Serial.println( i[test] );
  Serial.println( 1[test] );
  Serial.println( *(test+i) );
  Serial.println( *(1+test) );
}

void loop() 
{

}

Hi

... kommt mir bekannt vor ... in Assembler hat man nicht Mal Das :o
(und auch, wenn ich Assembler schon irgendwie geil finde, hat man's in C++ doch erheblich einfacher)

MfG

postmaster-ino:
... und auch, wenn ich Assembler schon irgendwie geil finde, hat man's in C++ doch erheblich einfacher ...

Nicht ohne Grund ist C/C++ so beliebt: Es ermöglicht eine sehr maschinennahe Programmierung, bei der einem viel Assembler-Gehampel abgenommen wird.

Gruß

Gregor