Probleme mit High- und Low-Eingängen Arduino Nano

[Michael (micha1980)]

Ich hoffe ich bin hier richtig- Hallo Leute.
Als Vollblutlaie habe ich mich mal an die Programmierung gewagt.
Mein Projekt: Ein Lichtschlauch (ws2812b), zwei Schalter.
Was es tun soll: Ein Schalter schaltet einen Kanal für Tag, einer für 
Nacht; diese ziehen beim Arduino zwei Kanäle auf High oder Low.
Auf dem Arduino habe ich ein Programm geschrieben, der das Licht am 
Lichtschlauch wie eine Gardine öffnet und schließt. Am Tag heller als 
Nachts. (An Zeit-Funktionen über den Arduino bin ich bereits mehrfach 
gescheitert, also übernimmt die Zeit der Shelly)
Zwei Kanäle werden mit einem definitiven Widerstand belegt, um ein 
klares High und Low zu erzeugen.
So weit, so gut, die Programmierung läuft, wie sie soll:
-drücke ich den Tag-Schalter, wird das Programm für den Tag abgespielt
-drücke ich den Nacht-Schalter, wird das Programm für die Nacht 
abgespielt.
-drückt man beide Schalter, wird das Programm für buntes Licht (Pink) 
abgespielt
ABER immer öfter tritt das Problem auf, dass der Arduino die LOW bzw 
High-Signale falsch interpretiert und den Lichtschlauch falsch 
einschaltet (hell statt dunkel, dunkel statt hell, pink). Mal mitten im 
Programmablauf, mal gänzlich ohne Schalterdruck.
Was ich probiert habe: Beide Kanäle auf High, beide auf LOW, beide 
gemischt- immer das selbe Ergebnis. Die beiden 10kOhm-Widerstande sind 
OK.

Habe ich einen Fehler im System? Die "Schalter" sind übrigens 
potenzialfreie Relaiskontakte.

Danke für eure Tipps.

Der Arduino-Code:

```cpp
#include <Adafruit_NeoPixel.h>
#define PIN 6 //LED-Stripe
#define NUMPIXELS 66
#define SENSORPIN1 A3 //Schalter hell
#define SENSORPIN2 A5 //Schalter dunkel
Adafruit_NeoPixel pixels(NUMPIXELS, PIN, NEO_GRBW + NEO_KHZ800);
int Sensorstatus1 = 0;
int Sensorstatus2 = 0;
int a=0;
int b=0;


void setup() {

  pinMode(SENSORPIN1, INPUT);
  pinMode(SENSORPIN2, INPUT);
  digitalWrite(SENSORPIN1, LOW); //10KOhm-R
  digitalWrite(SENSORPIN2, LOW); //10KOhm-R
  pixels.begin();
}

void EinschaltsequenzTag() {
  for(int i=-7; i<66; i++) {
    pixels.setPixelColor(i, pixels.Color(100,100,200,250)); // weiß wird 
hell dargestellt
    pixels.show();
    pixels.setPixelColor(i+1, pixels.Color(0,0,0,200));
    pixels.setPixelColor(i+2, pixels.Color(0,0,0,150));
    pixels.setPixelColor(i+3, pixels.Color(0,0,0,100));
    pixels.setPixelColor(i+4, pixels.Color(0,0,0,50));

    pixels.setPixelColor(i+5, pixels.Color(0,10,0,0));
    pixels.setPixelColor(i+6, pixels.Color(0,60,0,0));
    pixels.setPixelColor(i+7, pixels.Color(0,150,0,0));
    pixels.setPixelColor(i+8, pixels.Color(0,250,0,0)); // erstes Pixel 
grün
    pixels.show();
    delay(20);
  }
}
void EinschaltsequenzNacht() {
  for(int i=-7; i<66; i++) {
    pixels.setPixelColor(i, pixels.Color(20,20,20,20)); // weiß wird 
dunkel dargestellt
    pixels.show();
    pixels.setPixelColor(i+1, pixels.Color(0,0,0,20));
    pixels.setPixelColor(i+2, pixels.Color(0,0,0,30));
    pixels.setPixelColor(i+3, pixels.Color(0,0,0,40));
    pixels.setPixelColor(i+4, pixels.Color(0,0,0,50));

    pixels.setPixelColor(i+5, pixels.Color(0,10,0,0));
    pixels.setPixelColor(i+6, pixels.Color(0,60,0,0));
    pixels.setPixelColor(i+7, pixels.Color(0,150,0,0));
    pixels.setPixelColor(i+8, pixels.Color(0,250,0,0)); // erstes Pixel 
grün
    pixels.show();
    delay(20);
  }
}
void EingeschaltenTag() {
  for(int i=-7; i<60; i++) {
    pixels.setPixelColor(i, pixels.Color(100,100,200,250)); // helles 
Weiß
    pixels.show();
  }
}
void EingeschaltenNacht() {
  for(int i=-7; i<60; i++) {
    pixels.setPixelColor(i, pixels.Color(20,20,20,20)); // dunkles Weiß
    pixels.show();
  }
}
void Ausschaltsequenz() {
  for(int i=70; i>-4; i--) {
    pixels.setPixelColor(i, pixels.Color(0,0,0,0));
    pixels.show();
    pixels.setPixelColor(i-1, pixels.Color(20,0,0,0)); //letztes Pixel 
rot
    pixels.setPixelColor(i-2, pixels.Color(60,0,0,0));
    pixels.setPixelColor(i-3, pixels.Color(120,0,0,0));
    pixels.setPixelColor(i-4, pixels.Color(255,0,0,0));
    pixels.show();
    delay(50);
  }
}
void Ausgeschalten() {
  for(int i=-7; i<66; i++) {
    pixels.setPixelColor(i, pixels.Color(0,0,0,0));
    pixels.show();
  }
}
void Bunt() {
  for(int i=66; i>-1; i--) {
    pixels.setPixelColor(i, pixels.Color(150,0,150,0)); // sind beide 
Kanäle "akiviert", leuchtet es pink
    delay(20);
    pixels.show();
  }
}

void loop() {
  Sensorstatus1 = digitalRead(SENSORPIN1);
  Sensorstatus2 = digitalRead(SENSORPIN2);

  if((Sensorstatus1 == HIGH) && (Sensorstatus2 == LOW)) {
    if(a==0) {
      a++;
      EinschaltsequenzTag();
    }
    else if(a==1) {
      b=0;
      EingeschaltenTag();
    }
  }
  else if((Sensorstatus1 == LOW) && (Sensorstatus2 == HIGH)) {
    if(a==0) {
      a++;
      EinschaltsequenzNacht();
    }
    else if(a==1) {
      b=0;
      EingeschaltenNacht();
    }
  }
  else if((Sensorstatus1 == LOW) && (Sensorstatus2 == LOW)) {
    if((b==0) && (a==1)) {
      b++;
      Ausschaltsequenz();
    }
    else {
      a=0;
      Ausgeschalten();
    }
  }
  else if((Sensorstatus1 == HIGH) && (Sensorstatus2 == HIGH)) {
    a=0;
    b=0;
    Bunt();
  }
  else {}
}



```

[Wastl (hartundweichware)]

Michael schrieb:
> Als Vollblutlaie

..... solltest du dir erst mal die Hinweise zum Posten von
Quelltexten durchlesen und zu Herzen nehmen. Für alle die
das Kleingedruckte nicht entziffern können, hier nochmal:

Wichtige Regeln - erst lesen, dann posten!
............
    Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Weiterer Hinweis: "Längerer Sourcecode" ist es wenn eine
Bildschirmseite nicht ausreicht den Code vollständig
darzustellen.

[Helmut -. (dc3yc)]

Und ein Schaltplan deines Projekts wäre auch ganz gut. Aber bitte kein 
Fritzing-Wimmelbild!

[Wastl (hartundweichware)]

Michael schrieb:
> Zwei Kanäle werden mit einem definitiven Widerstand belegt, um ein
> klares High und Low zu erzeugen.
> So weit, so gut,

So weit, so gut, wir lieben Schaltpläne in Prosa. Richtig
verständlich wird aber ein Schaltplan erst dann wenn er
vollständig gezeichnet ist und hier veröffentlicht wird.

[Helmut -. (dc3yc)]

Ach nochwas: bitte den GANZEN Code posten und nicht nur einen 
Ausschnitt. Und dann erhebt sich die Frage: hast du deine 
Schalter-Eingänge entprellt?

[Harald K. (kirnbichler)]

Michael schrieb:
> Ich hoffe ich bin hier richtig

Nein:

Forum: Projekte & Code

Hier könnt ihr Projekte, Schaltungen oder Codeschnipsel vorstellen. 
Projekte bitte nur mit Code oder Schaltplan posten (falls ihr nur Fotos 
vorstellen möchtet, bitte in "Zeigt her eure Kunstwerke"). Bitte hier 
keine Fragen posten.

Es heißt übrigens geschaltet, nicht "geschalten".

[Wastl (hartundweichware)]

Harald K. schrieb:
> Nein:

Doch! Sobald man eine Batterie und eine Lampe zusammenschaltet
hat man doch ein Projekt.

[Michael (micha1980)]

Anbei das Schaltbild und der Programmcode als .txt

[Michael (micha1980)]

Helmut -. schrieb:
> Ach nochwas: bitte den GANZEN Code posten und nicht nur einen
> Ausschnitt. Und dann erhebt sich die Frage: hast du deine
> Schalter-Eingänge entprellt?

Hmm bei mir sehe ich den gesamten Code. Der Tipp mit dem Entprellen- das 
werde ich mal weiterverfolgen. Soweit ich weis muss dazu ein weiterer 
Widerstand und ein Kondensator parallel zum Schalter installiert werden- 
richtig?

[Harald K. (kirnbichler)]

Michael schrieb:
> und der Programmcode als .txt

Wenn Du ihn als *.c oder *.ino angehängt hättest, würde die 
Forensoftware eine Codeansicht anbieten ...

[Michael (micha1980)]

Harald K. schrieb:
> Wenn Du ihn als *.c oder *.ino angehängt hättest, würde die
> Forensoftware eine Codeansicht anbieten ...

Eigentlich sollte es genau das tun, hier nochmal:

[Monk (roehrmond)]

Bei 10kΩ fließen nur 0,5mA. Die meisten Schaltkontakte brauchen mehr 
Strom, um langfristig zuverlässig zu funktionieren.

Dazu kommt, dass so hochohmig abgeschlossene Eingänge für Radiowellen 
empfänglich sind. Gehe ruhig auf 2,2kΩ runter - auch wenn das im Moment 
wahrscheinlich nicht die Problemursache ist.

Wenn eine Taste gedrückt wird, soll etwas aktiviert werden.
Wenn beide Tasten gedrückt werden, soll es aus gehen.

Du wirst aber wohl kaum beide Tasten exakt im gleichen Moment loslassen 
können, ergo geht das Gerät nach dem Ausschalten direkt wieder an.

[Loco M. (loco)]

Michael schrieb:
> Anbei das Schaltbild und der Programmcode als .txt

Aus der Arduino Nano Beschreibung:

How to power up the Arduino Nano?

There are a couple of ways in which you can power the Nano board. The 
first and easy way is using the mini-B type USB Connector. The next way 
is to provide a regulated 5V supply through the 5V pin (Pin number 27).

Finally, the Nano has an onboard regulator at the bottom (along with the 
USB – to – Serial Converter). To use, you can provide an unregulated 
supply in the range of 6V to 20V to VIN pin of the Nano (Pin number 30).

Du hast die 5V mit VIN statt dem 5V Pin verbunden. Damit sieht der 
ATMega328P nach dem Spannungsregler weniger als 5V, und wenn die 5V 
nicht stabil anstehen, was ich mir bei 66 WS2812B gut vorstellen kann, 
dann schlägt eventuell der Brown-out Detektor zu und löst einen Reset 
aus.

Also 5V PowerSupply und Spannungsabfall auf GND und 5V Leitung 
nachmessen.

[Falk B. (falk)]

Michael schrieb:
>> Ach nochwas: bitte den GANZEN Code posten und nicht nur einen
>> Ausschnitt. Und dann erhebt sich die Frage: hast du deine
>> Schalter-Eingänge entprellt?
>
> Hmm bei mir sehe ich den gesamten Code. Der Tipp mit dem Entprellen- das
> werde ich mal weiterverfolgen. Soweit ich weis muss dazu ein weiterer
> Widerstand und ein Kondensator parallel zum Schalter installiert werden-
> richtig?

Falsch. Eine Entprellung in Hardware geht anders.

https://www.mikrocontroller.net/articles/Entprellung#Einfacher_Taster

Deine Taster kann man so benutzen, ist aber unüblich. Üblich sind 
Schalter gegen GND und interne oder externe Pull-Up Widerstände. Das ist 
aber nicht das zentrale Problem.

Wenn man Taster abfragt, sollte man die meistens entprellen, entweder in 
Hard- oder Software. Außerdem sollte man für die meisten Aktionen die 
Flanke erkennen, damit eine dauerhaft (länger) gedrückte Taste die 
Aktion nur einmalig auslöst. Deine Abfrage der Taster in 
hyperschallschnell, das is nicht nur Unsinn, sondern auch 
kontraproduktiv.
Ein Schreibzugriff auf digitale Eingänge is Unfug im setup().
Und dein Programm musst du werder umkopiere noch in.txt umbenennen. Man 
kann einfach die .ino Datei anfügen.

Siehe Anhang. Es wird die Flanke der Signale ausgewertet. Damit wird nur 
einmalig die Tag- oder Nachtsequenz ausgeführt. Ebenso wird der andere, 
inaktive Eingang ignoriert, solange der andere aktiv bleibt. D.h. nach 
einer erkannten Flanken müssen beide Eingänge erstmal auf inaktiv gehen 
und damit die Ausschaltsequenz auslösen, damit eine neue 
Einschaltsequenz möglich ist. Wenn beide Eingänge aktiv sind, wird des 
"bunt", was hier aber nur pink bedeutet. Naja.

[Falk B. (falk)]

Loco M. schrieb:
> Also 5V PowerSupply und Spannungsabfall auf GND und 5V Leitung
> nachmessen.

Vor allem die 5V am Pin 5V einspeisen! NICHT an VIN, dort müssen 6,5-12V 
anliegen!

[Falk B. (falk)]

Moderation, bitte mal den Beitrag verschieben.

[Manfred P. (pruckelfred)]

Michael schrieb:
> Der Tipp mit dem Entprellen- das
> werde ich mal weiterverfolgen. Soweit ich weis muss dazu ein weiterer
> Widerstand und ein Kondensator parallel zum Schalter installiert werden-
> richtig?

Nein, Entprellen macht man per Software. Dein Ablauf ist nicht 
zeitkritisch, das würde ich mit "delay(25)" machen. Also bei erkannter 
Taste 25ms warten, nochmal abfragen und den Wert nur übernehmen, wenn 
beide identisch sind. Damit werden kurze Störimpulse ausgeblendet, die 
man bei Dir als Ursache annehmen darf.

Deine beiden
digitalWrite(SENSORPIN1, LOW);
digitalWrite(SENSORPIN2, LOW);
sind nicht ursächlich, aber sinnfrei - es sind Eingänge.

Wie Stefan Monk schrieb, würde ich die 10kOhm an den Tastern deutlich 
niederohmiger machen, der Strom für die kurze Betätigung tut nicht weh. 
1kOhm oder auch 500Ohm, das erhöht die Störsicherheit.

Auch der Hinweis von Loco passt,
> Du hast die 5V mit VIN statt dem 5V Pin verbunden.
klemme auf den 5V-Pin um.

Falk B. schrieb:
> Vor allem die 5V am Pin 5V einspeisen! NICHT an VIN, dort müssen 6,5-12V
> anliegen!

Ja, erst ab kurz über 6V kann der xx1117-5 die Spannung sauber halten. 
12V verträgt er garantiert, aber als ängstlicher Mensch vermeide ich 
gerne die Verlustleistung.

[Falk B. (falk)]

Manfred P. schrieb:
> Wie Stefan Monk schrieb, würde ich die 10kOhm an den Tastern deutlich
> niederohmiger machen, der Strom für die kurze Betätigung tut nicht weh.
> 1kOhm oder auch 500Ohm, das erhöht die Störsicherheit.

Nicht so viel wie die Meisten glauben. Der Störabstand wird deutlich 
mehr duch einen anschließenden RC-Tiefpass erhöht. Da sind auch 10k Pull 
Up kein Problem.

[Falk B. (falk)]

Uuups, kleiner Fehler beim Umstellen. Da fehlt ein

code = 0;

am Anfang von loop()!

[Michael B. (laberkopp)]

Michael schrieb:
> Anbei das Schaltbild und der Programmcode als .txt

Autsch, du schaltest VIN auf die Eingänge und gehst mit deiner 5V 
Versorgung nicht auf +5V ?

Monk schrieb:
> Dazu kommt, dass so hochohmig abgeschlossene Eingänge für Radiowellen
> empfänglich sind.

Oh je, Deutschlandfunk wurde aber abgeschaltet.

Prellen und Störungen sind NICHT dein Problem.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Michael schrieb:
> ABER immer öfter tritt das Problem auf, dass der Arduino die LOW bzw
> High-Signale falsch interpretiert und den Lichtschlauch falsch
> einschaltet
Dein Problem ist, dass der µC viel schneller ist, als du dir vorstellen 
kannst.

Denn stell dir mal vor, wie schnell der µC die loop() durchlaufen kann. 
Nehmen wir hier mal gemächliche 20ms an (aber als Tipp: dein Programm 
sollte sogar noch funktionieren, wenn die Durchlaufzeit 0 ist).

Und dann stellst du dir vor, wie schnell du die Tasten "gleichzeitig" 
drücken und später dann "gleichzeitig" loslassen kannst. Und was die 
Zustände sind, die durchlaufen werden, weil du die beiden Taster eben 
garantiert nicht jedesmal innerhalb von 20ms "gleichzeitig" drücken und 
loslassen kannst.

Und weil da eben Zeit vergeht, bis beide Tasten sicher gedrückt sind, 
musst du vor dem Start der jeweiligen "Programme" mindestens diese Zeit 
abwarten.

Falk B. schrieb:
> Der Störabstand wird deutlich mehr duch einen anschließenden
> RC-Tiefpass erhöht.
Vorrangig aber durch den C. Aber auch das wird hier das seltsame 
Verhalten nicht beheben, denn die Ursache ist ein logisches Problem in 
der Software.

[Michael B. (laberkopp)]

Lothar M. schrieb:
> denn die Ursache ist ein logisches Problem in der Software.

Wo findest du das ?

Ich sehe in allen loop-Verzweigungen ausreichend lang dauernde 
Operationen um nicht auf das Prellen von Kontakten reinzufallen.

Etwas blöd ist das raufzählen von a und b gemacht, da verliere ich den 
Überblick.

[Michael (micha1980)]

Manfred P. schrieb:
> Deine beiden
> digitalWrite(SENSORPIN1, LOW);
> digitalWrite(SENSORPIN2, LOW);
> sind nicht ursächlich, aber sinnfrei - es sind Eingänge.

In 1000 anderen Tutorials wird gesagt, man muss LOW und HIGH-Eingänge 
definieren, aber ich probiere auch mal deinen Tipp.

Manfred P. schrieb:
> Auch der Hinweis von Loco passt,
>> Du hast die 5V mit VIN statt dem 5V Pin verbunden.
> klemme auf den 5V-Pin um.

Mach ich

Allgemein:
Ich spreche von Schaltern, nicht von Tastern. Solange die Schalter 
geschalten sind, solange soll das Programm ablaufen.

Vielen Dank für Eure Tipps. Den Teil, den ich davon verstehe, werde ich 
definiert umsetzen. Habt einen schönen Freitag, ich werde berichten.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Michael B. schrieb:
> Wo findest du das ?
> Ich sehe in allen loop-Verzweigungen ausreichend lang dauernde
> Operationen um nicht auf das Prellen von Kontakten reinzufallen.
Ja, aber beim "gleichzeitigen" Drücken von 2 Tasten kommt garantiert 
immer 1 Taste zuerst. Und wenn dann grade die Mainloop durchläuft. Aber 
dank der klarifizierten Schalter ist das hier nicht das Problem...

Michael schrieb:
> Ich spreche von Schaltern, nicht von Tastern.
Wie wäre es, wenn du da zum Test einfach mal richtige Kippschalter 
einbaust, die für garantiert definierte Pegel an den Eingängen sorgen?

> Solange die Schalter geschalten sind
- 
https://www.spiegel.de/kultur/zwiebelfisch/zwiebelfisch-die-sauna-ist-angeschalten-a-339978.html

BTW: was soll denn durch die unteren beiden Code-Zeilen hier passieren?

  pinMode(SENSORPIN1, INPUT);
  pinMode(SENSORPIN2, INPUT);
  digitalWrite(SENSORPIN1, LOW); //10KOhm-R  
  digitalWrite(SENSORPIN2, LOW); //10KOhm-R

[Obelix X. (obelix)]

Wenn ein Programm nicht wie gewünscht läuft kann man es debuggen :

https://www.youtube.com/watch?v=MOJGBwsPD7I

[Rolf (rolf22)]

Michael schrieb:
>> Deine beiden
>> digitalWrite(SENSORPIN1, LOW);
>> digitalWrite(SENSORPIN2, LOW);
>> sind nicht ursächlich, aber sinnfrei - es sind Eingänge.

> In 1000 anderen Tutorials wird gesagt, man muss LOW und HIGH-Eingänge
> definieren

LOW- und HIGH-Eingänge gibt es nicht, es gibt nur Eingänge. Die 
Tutorials meinen auch nicht "definieren", sondern "für einen definierten 
Spannungspegel sorgen".
Das geht nur mittels einer externen Beschaltung. Per Programm wirksam 
auf Pins schreiben kann man logischerweise nur, wenn es Ausgänge sind.

[Arduino F. (Firma: Gast) (arduinof)]

Michael schrieb:
> In 1000 anderen Tutorials wird gesagt, man muss LOW und HIGH-Eingänge
> definieren,

1000 Fliegen können nicht irren ......

Du deaktivierst damit die Pullup!
Das ist aber nicht nötig, da sie per default deaktiviert sind und du sie 
nicht beim pinMode aktiviert hast.

Rolf schrieb:
> Per Programm wirksam
> auf Pins schreiben kann man logischerweise nur, wenn es Ausgänge sind.

Falsch.


pinMode(SENSORPIN1, INPUT);
digitalWrite(SENSORPIN1, 1); //Pullup aktivieren
Macht selten Sinn, aber kann man tun.
Es hat  Wirkung.

[Monk (roehrmond)]

Michael B. schrieb:
> Oh je, Deutschlandfunk wurde aber abgeschaltet.

Radiowellen strahlt auch der Staubsauger ab. Sie entstehen beim Schalten 
einer Lampe, und auch wenn das Smartphone aktiv wird. usw...

[Monk (roehrmond)]

Michael schrieb:
> In 1000 anderen Tutorials wird gesagt, man muss LOW und HIGH-Eingänge
> definieren, aber ich probiere auch mal deinen Tipp.

Kannst du mal auf ein Beispiel verweisen? Ich vermute ein 
Missverständnis, dass ich aufklären möchte.

[Arduino F. (Firma: Gast) (arduinof)]

Monk schrieb:
> Staubsauger

Nicht nur der....

Das gesamte Universum brüllt, mit all seiner Kraft, auf jedes Stückchen 
Draht ein. Das bringt so manches Elektron in Wallung.

[Manfred P. (pruckelfred)]

Lothar M. schrieb:
> Und dann stellst du dir vor, wie schnell du die Tasten "gleichzeitig"
> drücken und später dann "gleichzeitig" loslassen kannst. Und was die
> Zustände sind, die durchlaufen werden, weil du die beiden Taster eben
> garantiert nicht jedesmal innerhalb von 20ms "gleichzeitig" drücken und
> loslassen kannst.

Das ist nicht sein Problem:

Michael schrieb:
> mal gänzlich ohne Schalterdruck.

Lothar M. schrieb:
> BTW: was soll denn durch die unteren beiden Code-Zeilen hier passieren?

> pinMode(SENSORPIN1, INPUT);
> pinMode(SENSORPIN2, INPUT);
> digitalWrite(SENSORPIN1, LOW); //10KOhm-R
> digitalWrite(SENSORPIN2, LOW); //10KOhm-R

Ich erwähnte sie gestern, sie sind sinnlos. Allerdings werden sie keinen 
Schaden verursachen und nichts zu seinem Problem beitragen.

Monk schrieb:
>> In 1000 anderen Tutorials wird gesagt, man muss LOW und HIGH-Eingänge
>> definieren, aber ich probiere auch mal deinen Tipp.
> Kannst du mal auf ein Beispiel verweisen? Ich vermute ein
> Missverständnis, dass ich aufklären möchte.

Das ist eine sinnfreie Nebenbaustelle, die nicht hilft.

Deine Formulierung "Radiowellen" ist eher laienhaft, aber vermutlich 
sein Problem. Da strahlt irgendwas ein und bringt das Programm in eine 
andere Betriebsart.

Aus dem Grunde wurde Entprellung angesprochen. Ich habe kein Problem, 
wenn ich die Taste nach einer Weile erneut abfrage und nur für gültig 
erkläre, wenn beide identisch sind.

[Falk B. (falk)]

Arduino F. schrieb:
> pinMode(SENSORPIN1, INPUT);
> digitalWrite(SENSORPIN1, 1); //Pullup aktivieren
> Macht selten Sinn, aber kann man tun.
> Es hat  Wirkung.

Wirklich? Hast du in den Quelltext geschaut? (Ich nicht)
Die Arduino-Funktionen sind nicht das Gleiche wie der direkte Zugriff 
auf die Register, so daß ich vermuten würde, daß ein Schreibzugriff auf 
ein IO-Pin, welches vorher als Eingang definiert wurden, rein gar nichts 
bewirkt. Denn der Pull-Up wird mit der pinMode() Funktion eingeschaltet.
Alles andere wäre Murks.

[Arduino F. (Firma: Gast) (arduinof)]

Falk B. schrieb:
> Wirklich?
Ja!

Falk B. schrieb:
> Hast du in den Quelltext geschaut?
Das auch. Irgendwann mal.

Falk B. schrieb:
> (Ich nicht)
Schade!
Wirklich schade!
Noch nicht mal in die Doku geschaut!

> digitalWrite() will have enabled the internal pull-up
> resistor, which acts like a large current-limiting resistor.
https://www.arduino.cc/reference/en/language/functions/digital-io/digitalwrite/

Falk B. schrieb:
> so daß ich vermuten würde, daß ein Schreibzugriff auf
> ein IO-Pin, welches vorher als Eingang definiert wurden, rein gar nichts
> bewirkt.
Bla bla, ohne Fakten.
Reine Fantasie.

Falk B. schrieb:
> Alles andere wäre Murks.
Murks ist es, zu mosern, ohne Interesse sich kundig zu machen.

Jetzt darfst du noch über doe Doku mosern.
Nichts anderes erwarte ich von dir.

[Falk B. (falk)]

Arduino F. schrieb:
>> (Ich nicht)
> Schade!
> Wirklich schade!
> Noch nicht mal in die Doku geschaut!

Ok, mein Fehler. Trotzdem ist es Unfug, dieses Spezialverhalten des AVRs 
in diese Funktionen reinzufummeln. Denn bei andern CPUs, die auch 
"Arduino" sind, funktioniert es so nicht, es sei denn man frickelt das 
rückwirkend dort rein.

[Arduino F. (Firma: Gast) (arduinof)]

Falk B. schrieb:
> Trotzdem ist es Unfug,

Da kannst du ja froh sein!
Ein Grund zum Nörgeln, obwohl dich Arduino überhaupt nicht betrifft.
Offensichtlich gar nicht deine Baustelle ist.

Vergleichbar mit dem 1000 Bundestrainer Effekt alle paar Jahre.

Vielleicht hätte die Doku erwähnen können, dass es nur für AVR gilt. 
Aber ist halt etwas älter... aus der "vor SAM Zeit".

Du hast meinen Segen, wenn du diese reparieren möchtest.
Soweit mir bekannt, ist es jedem möglich, dieses zu tun.
So auch dir.

Aber vermutlich überfordert dich das.
Würde dir ja auch den Nörgelgrund nehmen.

[Falk B. (falk)]

Arduino F. schrieb:
> Würde dir ja auch den Nörgelgrund nehmen.

Du weißt doch, ich bin der Ketzer. Ein Scheißjob, aber einer muss ihn 
machen! ;-)

[Monk (roehrmond)]

Manfred P. schrieb:
> Deine Formulierung "Radiowellen" ist eher laienhaft

Ich habe den Begriff vor 30 Jahren in der Ausbildung zum 
Kommunkationserlektroniker so gelernt, wie in Wikipedia beschrieben:

"Radiowellen, auch Funkwellen, oder Hertzsche Wellen sind in ... der 
Internationalen Fernmeldeunion (ITU) als „elektromagnetische Wellen 
definiert, deren Frequenzen vereinbarungsgemäß unterhalb 3000 GHz 
liegen, und die sich ohne künstliche Führung im freien Raum 
ausbreiten.“"

https://de.wikipedia.org/wiki/Radiowelle

[Monk (roehrmond)]

Falk B. schrieb:
> Die Arduino-Funktionen sind nicht das Gleiche wie der direkte Zugriff
> auf die Register, so daß ich vermuten würde, daß ein Schreibzugriff auf
> ein IO-Pin, welches vorher als Eingang definiert wurden, rein gar nichts
> bewirkt.

Möp! Schau mal in den Quelltext:

void digitalWrite(uint8_t pin, uint8_t val)
{
  uint8_t timer = digitalPinToTimer(pin);
  uint8_t bit = digitalPinToBitMask(pin);
  uint8_t port = digitalPinToPort(pin);
  volatile uint8_t *out;

  if (port == NOT_A_PIN) return;

  // If the pin that support PWM output, we need to turn it off
  // before doing a digital write.
  if (timer != NOT_ON_TIMER) turnOffPWM(timer);

  out = portOutputRegister(port);

  uint8_t oldSREG = SREG;
  cli();

  if (val == LOW) {
    *out &= ~bit;
  } else {
    *out |= bit;
  }

  SREG = oldSREG;
}

> Denn der Pull-Up wird mit der pinMode() Funktion eingeschaltet.
auch
> Alles andere wäre Murks.

Arduino ist nur sehr knapp dokumentiert, deswegen kommt es Anfängern 
einfach vor. Es bietet dadurch  aber auch reichlich Gelegenheiten für 
Probleme, insbesondere was die Kompatibilität zwischen Bibliotheken und 
µC Modellen angeht, sowie negative Überraschungen nach Updates.

Wobei dieser konkreten Fall (nur auf der englischen Seite) doch 
dokumentiert ist:

"If the pin is configured as an INPUT, digitalWrite() will enable (HIGH) 
or disable (LOW) the internal pullup on the input pin."
https://www.arduino.cc/reference/en/language/functions/digital-io/digitalwrite/

Was dort nicht steht: Das gilt nur für die alten AVR Mikrocontroller.

Meiner Meinung nach sollte digitalWrite() keine Auswirkung auf Eingänge 
habe. Da dort eh schon gefühlt 100 Takte verplempert werden, könnte man 
das problemlos mit unterbringen. Das Framework soll schließlich die 
Hardware abstrahieren.

[Falk B. (falk)]

Monk schrieb:
> Falk B. schrieb:
>> Die Arduino-Funktionen sind nicht das Gleiche wie der direkte Zugriff
>> auf die Register, so daß ich vermuten würde, daß ein Schreibzugriff auf
>> ein IO-Pin, welches vorher als Eingang definiert wurden, rein gar nichts
>> bewirkt.
>
> Möp! Schau mal in den Quelltext:

OK, hab ich nicht getan und falscg geraten 8-0

> Meiner Meinung nach sollte digitalWrite() keine Auswirkung auf Eingänge
> habe.

Meine Rede!

> Da dort eh schon gefühlt 100 Takte verplempert werden, könnte man
> das problemlos mit unterbringen. Das Framework soll schließlich die
> Hardware abstrahieren.

Eben!

[Arduino F. (Firma: Gast) (arduinof)]

Monk schrieb:
> könnte man das problemlos mit unterbringen.
Mach doch!
Der Code liegt öffentlich aus.
Von jedem zu verändern.

Wirst du damit durchkommen?
Nein! Da bin ich mir recht sicher.

Warum:
Das kostet wertvolles RAM auf den kleinen AVR

Mit einer Doku Verbesserung, welches dieses "Feature" beschreibt, hast 
du mehr Chancen.

[Monk (roehrmond)]

Arduino F. schrieb:
> Der Code liegt öffentlich aus.
> Von jedem zu verändern.

Nein. Das Arduino Framework ist kein Community Projekt, wo jeder 
mitmachen kann.

Ich könnte höchstens meine eigene Kopie davon ändern. Das brauche ich 
aber  nicht, weil ich Arduino nur für den ESP8266 verwende, wo 
digitalWrite() schon jetzt nicht die Pull-Ups verändert.

Arduino F. schrieb:
> Warum:
> Das kostet wertvolles RAM auf den kleinen AVR

Wie braucht man dafür RAM? Die Konfiguration der Pins befindet sich in 
Registern, die man auslesen kann.

[Arduino F. (Firma: Gast) (arduinof)]

Monk schrieb:
> Wie braucht man dafür RAM? Die Konfiguration der Pins befindet sich in
> Registern, die man auslesen kann.

Den Registern kann man aber nicht ansehen, ob ein pinMode(x,INPUT) 
stattgefunden hat, was für euer Vorhaben unabdingbar ist.

Monk schrieb:
> Nein. Das Arduino Framework ist kein Community Projekt, wo jeder
> mitmachen kann.
>
> Ich könnte höchstens meine eigene Kopie davon ändern.

Du irrst.
Der Arduino Core liegt auf Github.
Da kannst du deine Kopie anlegen und anschließend einen Pullrequest 
durchführen.
Hier die liste der offenen: 
https://github.com/arduino/ArduinoCore-avr/pulls
Die Frage ist, ob der genehmigt/übernommen wird.

[Monk (roehrmond)]

Arduino F. schrieb:
> Den Registern kann man aber nicht ansehen, ob ein pinMode(x,INPUT)
> stattgefunden hat, was für euer Vorhaben unabdingbar ist.

Doch sicher. Das DDR Register zeigt an, welche Pins als Ausgang 
konfiguriert sind. Ich würde das PORT Register nur dann beschrieben, 
wenn das entsprechende Bit im DDR Register auf HIGH steht.

[Arduino F. (Firma: Gast) (arduinof)]

Monk schrieb:
> Doch sicher. Das DDR Register zeigt an, welche Pins als Ausgang
> konfiguriert sind. Ich würde das PORT Register nur dann beschrieben,
> wenn das entsprechende Bit im DDR Register auf HIGH steht.

Das geht nicht.

Damit handelst du dir ein Problem ein!
Das geht nicht durch! Keine Übernahme deiner Änderung.

Es ist etablierte Praxis folgendes zu tun:
digitalWrite(pin,HIGH);
pinMode(pin,OUTPUT);

Denn so hat man zwischen INPUT und HIGHoutput keinen Takt Low Phase.

Ein Umdrehen:
pinMode(pin,OUTPUT);
digitalWrite(pin,HIGH);

Hat einen Low Impuls zur Folge, in vielen Fällen will man das nicht.

Monk schrieb:
> Ich würde das PORT Register nur dann beschrieben,
> wenn das entsprechende Bit im DDR Register auf HIGH steht.
Das ist also zu kurz gedacht.
Denn tausende von gut getesteten Programmen werden nach dem "Update" 
versagen.


Monk schrieb:
> Doch sicher. Das DDR Register zeigt an, welche Pins als Ausgang
> konfiguriert sind.
Nein, das Register zeigt nicht, ob ein pinMode() Aufruf stattgefunden 
hat.

[Monk (roehrmond)]

Arduino F. schrieb:
> Hat einen Low Impuls zur Folge, in vielen Fällen will man das nicht.

Argument akzeptiert

[Rolf (rolf22)]

Arduino F. schrieb:
> Rolf schrieb:
>> Per Programm wirksam auf Pins schreiben kann man logischerweise nur,
>> wenn es Ausgänge sind.

> Falsch.

Siehe verlinkte Tabelle. (Im Thread-Titel steht übrigens "Arduino Nano", 
also ist es definitiv ein Atmega328x.)

 Man kann in die Register schreiben, ja. Unter "auf einen Pin schreiben" 
verstehe ich aber, dass man ihn beliebig auf HIGH oder LOW setzen kann. 
Das kann man aber ohne Berücksichtigung der externen Beschaltung nicht - 
sonst wäre es ja ein Ausgang. Man kann lediglich den internen Pullup 
aktivieren oder deaktivieren. Welcher Pegel sich dann am Pin einstellt, 
hängt von der Beschaltung ab.

> pinMode(SENSORPIN1, INPUT);
> pinMode(SENSORPIN1, INPUT);
> digitalWrite(SENSORPIN1, 1); //Pullup aktivieren
> Macht selten Sinn, aber kann man tun.
> Es hat  Wirkung.

Und wie schreibst du LOW auf den Pin? ;-)

Ich habe noch nie einer dieser Arduino-IO-Funktionen benutzt, die 
verstecken zu viel und verwirren teilweise ("DigitalWrite(PINxyz, LOW)" 
tut was??). Ich schreibe immer gemäß Datenblatt in die Register, da weiß 
ich, was passiert.

[Arduino F. (Firma: Gast) (arduinof)]

Rolf schrieb:
> Und wie schreibst du LOW auf den Pin? ;-)

Du bist verwirrt!
Drücke dich bitte klar aus, dann kann dir evtl. geholfen werden.

Rolf schrieb:
> Unter "auf einen Pin schreiben"
> verstehe ich aber,
Du sprachest von "wirksam"!
Und ja, das Aktivieren des Pullup ist eine Wirkung.
Ohne jeden Zweifel.

Rolf schrieb:
> ("DigitalWrite(PINxyz, LOW)" tut was??)
Der Code liegt öffentlich aus.
Die Doku eben so.
Wenn da noch Verwirrung bestehen bleibt, na, ich weiß nicht ....

Rolf schrieb:
> Ich schreibe immer gemäß Datenblatt in die Register, da weiß
> ich, was passiert.
Meinen Segen!

Aber dann sind wie wieder bei:
Arduino F. schrieb:
> Vergleichbar mit dem 1000 Bundestrainer Effekt alle paar Jahre.
Mein Vorschlag:
Wenn dir an Arduino was nicht gefällt, dann ändere es, oder beantrage 
wenigstens die Änderung.
Hier zu nörgeln bewirkt nix.

[Monk (roehrmond)]

Arduino F. schrieb:
> Hier zu nörgeln bewirkt nix.

Doch: Dass Anfänger mitbekommen, daß das Arduino Framework nicht der 
Weisheit letzter Schluss ist.

[Arduino F. (Firma: Gast) (arduinof)]

Fantastisch!

Du hast es geschafft ein "dokumentiertes Feature" als "Haar in der 
Suppe" zu identifizieren.

Mehr kann man als Arduino Basher sicherlich nicht erreichen.

Meinen Glückwunsch!

[Wastl (hartundweichware)]

Arduino F. schrieb:
> Du hast es geschafft ein "dokumentiertes Feature" als "Haar in der
> Suppe" zu identifizieren.

Charakteristisch für Herrn Frings ist dass er möglichst das
letzte Wort haben muss - wenn irgendwie möglich. Also das letzte
Quentchen (Quäntchen) Wahrheit aus der Schief- oder Falschlage
seiner Aussagen herauszuholen.

[Axel R. (axlr)]

Ich mach auch mal mit:
Wenn extern 10K als Pull-Down angeschlossen sind und die internen 
Pull-Ups aktiviert werden, hängt der Eingang elektrisch irgendwo bei 
einem Volt oder so (die externen 10K und die internen 60-80k(?) als 
Spannungsteiler) nicht ganz „in der Luft“, aber schonmal deutlich überm 
GND-Potenzial.
Daher -  also so kenne ich das - schaltet man im allegemeinen auch gerne 
mit den Tastern oder Schaltern gegen GND und verwendet externe Pull-Up 
Widerstände, wenn die internen einen wegen „Radiowellen“ zu hochohmig 
erscheinen. Dann macht es auch keinen Unterschied, ob man die internen 
(versehentlich) aktiviert oder nicht.
Somit ergibt es schon Sinn, die internen Pull-ups zu deaktivieren.

Darüber hinaus die statemaschine etwas zu erweitern, um Tastendrücke und 
deren Flanken zu erkennen, wurde ja schon Hinweislich erörtert.
Hab mir jetzt den Stand der Umsetzung noch nicht angeschaut.
Aber Taste einlesen, wert merken und bei nächsten durchlauf vergleichen, 
ist üblich. Beide Zustände lassen sich dann verUnden oder verOdern.
Dass man (im einfachsten Fall hier) 50ms wartet und die gleiche Taste 
nochmals abfragt wurde auch schon als praktikabler Ansatz genannt.
Man könnte auch PeDas „vertikalzähler“ als entprellroutine mit 
einbauen. Muss man aber nicht. 50ms oder sogar 100ms warten und erneut 
auf H(in diesem Fall hier) prüfen, reicht locker aus, einen ordentlichen 
Tastendruck zu erkennen, den man dann weglegt und beim nächsten 
Durchlauf der Loop() mit der Historie vergleicht.

Man muss das nicht auf Registerebene machen. Darf ab und an schon mal n 
Arduino sein.
(Wobei ich lieber VS-Code mit PlatformIO verwende)

Ich tät trotzdem gegen GND schalten und nicht gegen V_in oder gegen VCC.

[Manfred P. (pruckelfred)]

Monk schrieb:
> "If the pin is configured as an INPUT, digitalWrite() will enable (HIGH)
> or disable (LOW) the internal pullup on the input pin."
> https://www.arduino.cc/reference/en/language/functions/digital-io/digitalwrite/

Interessant. Ich kenne

 pinMode (Key1, INPUT);
 pinMode (Key1, INPUT_PULLUP);

und gehe davon aus, dass per default der PullUp aus ist.

Falls nicht, würde ich das kaum bemerken, weil ich Kontakte nach GND 
schalten lasse.

> Was dort nicht steht: Das gilt nur für die alten AVR Mikrocontroller.

Rein zufällig ist der in diesem Thread im Einsatz.

> Da dort eh schon gefühlt 100 Takte verplempert werden, könnte man
> das problemlos mit unterbringen.

Na und? Das wird im Setup einmal abgefahren, im laufenden Betrieb wird 
man die Betriebsart Eingang / Ausgang selten bis nie ändern.

Axel R. schrieb:
> Wenn extern 10K als Pull-Down angeschlossen sind und die internen
> Pull-Ups aktiviert werden, hängt der Eingang elektrisch irgendwo bei
> einem Volt oder so (die externen 10K und die internen 60-80k(?) als
> Spannungsteiler) nicht ganz „in der Luft“, aber schonmal deutlich überm
> GND-Potenzial.

Das wäre in der Tat eine Falle, die die Störsicherheit erheblich 
reduziert.

So gesehen gut, dass Stefan die Beschreibung ausgegraben hat und mit dem 
"digitalWrite(SENSORPIN2, LOW);" der Zustand sicher gesetzt wird.

> Darf ab und an schon mal n Arduino sein.

Ich habe mit Arduino einige Geräte aufgebaut, die vorzeigbar sind. Da 
steht nicht draußen drauf, mit welcher Umgebung die realisiert wurden.

[Monk (roehrmond)]

Manfred P. schrieb:
>> Da dort eh schon gefühlt 100 Takte verplempert werden, könnte man
>> das problemlos mit unterbringen.
>
> Na und? Das wird im Setup einmal abgefahren, im laufenden Betrieb wird
> man die Betriebsart Eingang / Ausgang selten bis nie ändern.

Ich meinte digitalWrite() mit den "gefühlt 100 Takten"

[Rolf (rolf22)]

Arduino F. schrieb:
>> Und wie schreibst du LOW auf den Pin? ;-)
>
> Du bist verwirrt!
> Drücke dich bitte klar aus, dann kann dir evtl. geholfen werden.

Ich hatte das bereits erklärt. Kleiner Tipp: Es gibt rhetorische Fragen, 
die die meisten Leser durch den Kontext verstehen. Manche lesen aber 
jeden Satz(teil) einzeln und verabsolutieren ihn - denen kann man 
erfahrungsgemäß nicht helfen.

>> ("DigitalWrite(PINxyz, LOW)" tut was??)
> Der Code liegt öffentlich aus.
> Die Doku eben so.
> Wenn da noch Verwirrung bestehen bleibt, na, ich weiß nicht ....

Zu rhetorischen Fragen siehe oben. Der zitierte Schnipsel lässt jeden 
Leser, der die Arduino-Eigenheiten nicht kennt, annehmen, dass man damit 
den Pin auf LOW setzt. Das ist aber nicht der Fall, das habe ich 
kritisiert.

(Vor Jahrzehnten in meinem ersten Job sollte ich einen Drucker 
ansteuern. Da gab es eine Doku zu dem Drucker, in der waren je ein 
Status- und ein Befehlsregister beschrieben. Nun hätte jeder vernünftige 
Leser gedacht, im Statusregister könne man den Status des Druckers 
auslesen (Busy, offline, Papier alle, ...) und über das Befehlsregister 
könne man dem Drucker Befehle erteilen (Schalte den Modus XY ein, drucke 
den Inhalt deines Puffers, ...). Eine absolut übliche Sache bei allen 
damaligen simplen Peripherie-Geräten unterhalb der Mainframe-Ebene.
Tatsächlich war es aber genau umgekehrt: Man las den Druckerstaus aus 
dem Befehlsregister und schrieb Druckbefehle in das Statusregister.

Auf meine Bemerkung hin, das sei unlogisch, deswegen sei die 
Dokumentation schwer verständlich, bekam der zuständige 
Senior-Programmierer, der die Schnittstelle definiert und dokumentiert 
hatte, sofort Schnappatmung und ein wutrotes Gesicht. Seine Replik: Man 
könne "Status" und "Befehl" natürlich beliebig definieren. Über das nur 
lesbare(!) Befehlsregister könne der Drucker der Software im Rechner 
befehlen, bestimmte Dinge zu tun, z. B. bei Papiermangel eine Meldung 
auszugeben.

Nun ja. Der anwesende Chef hat nicht widersprochen, mir aber nachher 
privat gesagt, ich hätte natürlich Recht. Dieser Senior-Programmierer 
sei sprachlich/kommunikativ auch sonst etwas schwierig, das wisse man. 
Aber man wolle/dürfe ihn nicht verärgern, weil man ihn noch brauche. Der 
habe das wichtige Systemprogramm XY geschrieben, von dem die Firma 
abhinge.)

> Mein Vorschlag:
> Wenn dir an Arduino was nicht gefällt, dann ändere es, oder beantrage
> wenigstens die Änderung.

Die alte Leier mit dem "Machs doch besser" im Hintergrund. Ich sag dir 
mal was: Wenn der Trompeter der Schützenfest-Kapelle nicht immer die 
richtigen Töne trifft, dann muss ich weder Noten kennen noch trompeten 
können, um das beurteilen zu dürfen. Punkt.

[Falk B. (falk)]

Rolf schrieb:

> Auf meine Bemerkung hin, das sei unlogisch, deswegen sei die
> Dokumentation schwer verständlich, bekam der zuständige
> Senior-Programmierer, der die Schnittstelle definiert und dokumentiert
> hatte, sofort Schnappatmung und ein wutrotes Gesicht.

Hehehe. Ein kleiner, leicht autistischer Choleriker. Solche Kollegen 
wünscht man sich . . .

> Seine Replik: Man
> könne "Status" und "Befehl" natürlich beliebig definieren.

Klar, Rot und Blau natürlich auch! Kirschen sind blau, Bananen rot!

> Über das nur
> lesbare(!) Befehlsregister könne der Drucker der Software im Rechner
> befehlen, bestimmte Dinge zu tun, z. B. bei Papiermangel eine Meldung
> auszugeben.

Da gab es wohl noch nicht die Konzepte Client/Server und der Drucker war 
der Chef, denn der macht immer Druck ;-)

[Karl B. (gustav)]

Rolf schrieb:
> Zu rhetorischen Fragen siehe oben. Der zitierte Schnipsel lässt jeden
> Leser, der die Arduino-Eigenheiten nicht kennt, annehmen,...

Yep. SCNR
Bevor man sich an schwierigere Programme ranwagt, wäre es vielleicht 
besser, erst einmal das Kärrnerhandwerk der ASM-Programmierung anhand 
von "LED an"- "LED aus" zu erlernen.
C ist schon ne Nummer zu groß, zu abstrakt und nicht direkt genug an der 
"Maschine" dran. Das "C" kommt erst später bei etwas mehr Erfahrung, 
wenn etwas umfangreichere Programme sonst drohen, syntaxmäßig ins 
"Spaghettihafte" auszuufern.
Und die Arduino-Freaks fallen auf die angeblich kinderleicht 
anzuwendenden "Sketche" herein. Ohne auch nur im Geringsten zu wissen, 
was da eigentlich so passiert. Das fängt schon beim Anschluss der 
Betriebsspannung an. Siehe oben. Wenn das schon schiefgeht, wundert mich 
garnichts mehr.
Einfach Copy & Paste
Passt schon.
Sorry SCNR

ciao
gustav

[Arduino F. (Firma: Gast) (arduinof)]

Karl B. schrieb:
> Siehe oben

2 Dinge scheinen dir nicht klar zu sein!

Erstens:
Arduino Sketche sind C++ und nicht C

Zweitens:
Die größten ASM Priester sind meist auch die größten C++ Versager


Dazu noch:
Wer einmal den Kopf tief in die prozedurale Programmierung gesteckt hat, 
ist (nahezu) für die OOP verloren.

Daraus folgt:
> Stop teaching C

[Roland F. (rhf)]

Hallo,
Arduino F. schrieb:
> Arduino Sketche sind C++ und nicht C

Nur sieht man bei gefühlt 90% aller im Internet gefundenen "Sketche" 
nichts von C++ und OOP.
Warum nur?

rhf

[Monk (roehrmond)]

Roland F. schrieb:
> Nur sieht man bei gefühlt 90% aller im Internet gefundenen "Sketche"
> nichts von C++ und OOP.
> Warum nur?

"Arduino programming language can be divided in three main parts: 
functions, values (variables and constants), and structure."
https://www.arduino.cc/reference/en/

Von OOP ist dort nicht viel zu sehen.

Am seltsamsten finde ich aber, dass die immer noch so tun, als hätten 
sie eine eigene "programming language" erfunden. Ich halte es für keine 
gute Idee, die Anfänger direkt am ersten Tag zu verarschen.

[Arduino F. (Firma: Gast) (arduinof)]

Roland F. schrieb:
> Warum nur?
Weil du blind bist.

z.B. häufig genutzt werden Serial, Wire und String.
Und schon bist du tief in C++ und OOP

Schade wenn du das übersiehst....
Ich glaube das sagt mehr über dich aus, als über Arduino.



---------------------------



Monk schrieb:
> Von OOP ist dort nicht viel zu sehen.
Weil du blind bist.

z.B. häufig genutzt werden Serial, Wire und String.
Und schon bist du tief in C++ und OOP

Schade wenn du das übersiehst....
Ich glaube das sagt mehr über dich aus, als über Arduino.


--------

[Wastl (hartundweichware)]

Arduino F. schrieb:
> z.B. häufig genutzt werden Serial, Wire und String.

Und ich dachte Herr Frings weiss was Objekte und Instanzen sind.

[Arduino F. (Firma: Gast) (arduinof)]

Wastl schrieb:
> Und ich dachte Herr Frings weiss was Objekte und Instanzen sind.

Nope!
Ihm ist mal wieder auf dem Arduino Basher Trip.
Damit ihm seine Selbstverarsche aufrecht halten kann, muss ihm einen 
großen Teil seines Gehirns deaktivieren.

[Simon R. (Gast)]

Monk schrieb:
> Von OOP ist dort nicht viel zu sehen.

Wahrscheinlich einfach deshalb, weil OOP nur auf Betriebssystemen 
richtig funktioniert, da man sonst einfach zu viel selber machen muss 
und ein OS dann einfach zu schwer wird für so eine Arduino-Mühle.

Wer soll da wozu ein komplexes SW-System entwerfen und dann auf einem 
Spielzeug laufen lassen?

[Veit D. (devil-elec)]

Hallo,

der Nächste der über OOP redet aber von OOP keine Ahnung hat. Hört das 
denn nie auf? OOP ist genauso MCU unabhängig wie es OS unabhängig ist. 
Aber dafür muss man eben wissen was OOP ist und was man damit alles 
machen kann.
Wer OOP nicht nutzen möchte okay, aber darüber immer wieder Blödsinn 
quatschen macht auch keinen Sinn.
Denn zwischen (OOP) Programm Code und der MCU sitzt immer noch die 
Toolchain.

[Roland F. (rhf)]

Hallo,
Arduino F. schrieb:
> Weil du blind bist.

Entschuldige meinen Beitrag, kommt nicht wieder vor (mir hätte klar sein 
müssen das du ihn nicht verstehst).

rhf

[Arduino F. (Firma: Gast) (arduinof)]

Roland F. schrieb:
> Entschuldige meinen Beitrag, kommt nicht wieder vor
Einverstanden.

Roland F. schrieb:
> (mir hätte klar sein
> müssen das du ihn nicht verstehst).

Alles klar, du siehst kein C++, obwohl doch alle Sketche durch einen C++ 
Compiler genudelt werden.
Nachweislich!
Und dann meinst du, dass ich das nicht verstehe...
Alles klar.
Keine Fragen mehr...
Alles klar!

Andererseits hast du allerdings wahr:
Denn so blöd/borniert bin ich nicht, dass ich solche absurden Phantasien 
verstehen könnte.

Merke:
Wenn du da kein C++ siehst, dann ist das nicht die Realität, sondern 
deine Projektion.

[Monk (roehrmond)]

Wastl schrieb:
> Und ich dachte Herr Frings weiss was Objekte und Instanzen sind.

Weiss ich auch, aber die Dokumentation verbirgt das weitgehend.

Sie vermeidet die etablierten Fachbegriffe der OOP konsequent und 
sämtliche Beispiele nutzen nur die wenigen vordefinierten Klassen des 
Frameworks. Nirgendwo in der Doku der "Arduino programming language" 
wird erwähnt, dass man eigene Klassen schreiben kann.

Auf diese Doku bezog ich mich mit der Aussage "Von OOP ist dort nicht 
viel zu sehen". Diese meine Meinung darf jeder für sich so verdrehen, 
wie er will und dann damit glücklich werden :-)

[Wastl (hartundweichware)]

Monk schrieb:
> Nirgendwo in der Doku der "Arduino programmin language" wird
> erwähnt, dass man eigene Klassen schreiben kann.

Warum sollte man das erwähnen? Jeder einigermassen "erwachsene"
Programmierer, der schon Klassen geschrieben hat, weiss das.

Das ist natürlich selbstredend. Man kann immer eine Klasse
schreiben und diese verwenden sobald man einen C++ Compiler
zur Verfügung hat. Weder ist dazu die Arduino IDE erforderlich
noch verhindert sie das. Klassenprogrammierung ist unabhängig
von irgendeiner IDE.

[Monk (roehrmond)]

Wastl schrieb:
> Warum sollte man das erwähnen?

Weil das als die "Arduino Programming language" verkauft wird. Nirgendwo 
ein Sterbenswörtchen davon, dass es sich um vollwertiges C++ handelt.

> Jeder einigermassen "erwachsene" Programmierer, der schon
> Klassen geschrieben hat, weiss das.

Arduino ist aber für den Einstieg gemacht. Es wird in Berufsschulen 
verwendet, um die Basics der Softwareentwicklung zu vermitteln. Da 
sollte man zumindest mal erwähnen, dass nach dem Einstieg das richtige 
C++ auf einen wartet.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Wastl schrieb:
> Monk schrieb:
>> Nirgendwo in der Doku der "Arduino programmin language" wird
>> erwähnt, dass man eigene Klassen schreiben kann.
> Warum sollte man das erwähnen?
Warum nicht, wenn man sich dazu versteigt, den Sourcecode nicht wie der 
Rest der Welt *.cpp und "Programm" zu nennen, sondern *.ino und 
"Sketch".

Arduino F. schrieb:
> Wenn du da kein C++ siehst, dann ist das nicht die Realität, sondern
> deine Projektion.
Wenn etwas aussieht wie Hase, riecht wie Hase und das selbe frisst wie 
ein Hase, dann wird es wohl ein Hase sein. Wenn auch alle "Nasenbär" 
dazu sagen.

Veit D. schrieb:
> OOP ist genauso MCU unabhängig wie es OS unabhängig ist.
Und sogar sprachunabhängig. Wie z.B. Java, Python, C#, Ruby, PHP auch 
objektorieentiert sind. Warum sollte also etwas, was mit Nachnamen INO 
heißt, sich automatisch wie C++ verhalten.

Und ja natürlich: man kann es ausprobieren und findet es dann heraus, 
dass der Nasenbär eigentlich ein Hase ist.

Aber auch die eigenartige Benamung und die Tatsache, dass es um 
objektorientoiertes C++ geht, hilft dem TO in seinem Problem nicht 
weiter.

[Arduino F. (Firma: Gast) (arduinof)]

Lothar M. schrieb:
> Wenn etwas aussieht wie Hase, riecht wie Hase und das selbe frisst wie
> ein Hase, dann wird es wohl ein Hase sein.

Dein Hase wird nicht durch einen C++ Compiler genudelt.
Und wenn du es versuchst .... wirste schon sehen ...

[Manfred P. (pruckelfred)]

Lothar M. schrieb:
> hilft dem TO in seinem Problem nicht weiter.

Der hat die Lust an diesem Thread verloren. Er hat seit 5 Tagen nichts 
mehr gesagt, was anhand des Verlaufs wohl niemanden wundern sollte.

[Veit D. (devil-elec)]

Lothar M. schrieb:
> Wastl schrieb:
>> Monk schrieb:
>>> Nirgendwo in der Doku der "Arduino programmin language" wird
>>> erwähnt, dass man eigene Klassen schreiben kann.
>> Warum sollte man das erwähnen?
> Warum nicht, wenn man sich dazu versteigt, den Sourcecode nicht wie der
> Rest der Welt *.cpp und "Programm" zu nennen, sondern *.ino und
> "Sketch".

Das ist jetzt irgendwie Kindergarten hoch 10. Wie alt bist du?
Wissen die Leute überhaupt wovon sie aktuell reden? Ich denke nämlich 
nicht.
https://www.arduino.cc/reference/en/
Das ist einfach nur die Referenz (steht auch groß darüber) für die 
vorhandenen Funktionen bzw. Methoden. Mehr ist das nicht. Das ist kein 
Versteckspiel. Jeder will eine Doku. Dort ist sie. Jeder der eine Lib 
einbindet und eine Instanz erstellt ist zack in OOP drin. Ich weiß nicht 
was daran versteckt ist.
Die .ino Dateien dienen ja noch für mehr. Es können mehrere Tabs/Reiter 
in der IDE zusammengeführt werden usw. und dann übersetzt. Es ist eine 
andere Art der Programmierung möglich. Ob euch das gefällt oder nicht 
ist dabei egal. Die Möglichkeit gibt es. Bringt eine Untergliederung auf 
andere Art und Weise. Man muss sie nicht nutzen. Man kann sie nutzen. 
Nur weil das nicht der Standard Gewohnheit entspricht muss das nicht 
automatisch schlecht sein. Außerdem ist es menschlich das einem das Lieb 
und Teuer ist was man gewohnt ist. Deswegen muss das andere nicht 
schlecht sein.
Und wer Arduino nicht nutzt, sich aber darüber künstlich aufregt, bei 
dem weiß ich dann auch nicht weiter. Ganz ehrlich.
Rege ich mich künstlich über Assembler Programmierung auf?
Rege ich mich künstlich über VHDL Programmierung auf?
Nur weil ich mich darin nicht auskenne.
Mach ich das? Nein, mach ich nicht.

> Veit D. schrieb:
>> OOP ist genauso MCU unabhängig wie es OS unabhängig ist.
> Und sogar sprachunabhängig. Wie z.B. Java, Python, C#, Ruby, PHP auch
> objektorieentiert sind. Warum sollte also etwas, was mit Nachnamen INO
> heißt, sich automatisch wie C++ verhalten.
>
> Und ja natürlich: man kann es ausprobieren und findet es dann heraus,
> dass der Nasenbär eigentlich ein Hase ist.
>
> Aber auch die eigenartige Benamung und die Tatsache, dass es um
> objektorientoiertes C++ geht, hilft dem TO in seinem Problem nicht
> weiter.

Ich habe das Gefühl auch du regst dich wie Monk nur künstlich auf. Kann 
das sein? Nur weil das gesamte Programm Sketch heißt und die Dateiendung 
.ino soll das nun automatisch alles schlecht sein? Obwohl man ganz 
normales Standard C/C++ programmiert. Man kann auch setup/loop weglassen 
und mit main loslegen unter Verzicht der Annehmlichkeiten.

Zudem habt ihr noch nicht verstanden das man mit Arduino ganz schnell 
irgendwas testen kann, ohne jedes mal beim Urschleim anfangen zu müssen. 
Ein paar Zeilen eigener Code und es kann losgehen, wo andere noch am 
debuggen sind.

Wie gesagt, wenn ihr das nicht nutzt, warum regt ihr euch auf?
Eigentlich regt man sich doch auf wenn man irgendwas benutzt und es 
funktioniert irgendwas nicht. Im Forum ist das komischerweise immer 
umgekehrt wie in der echten Welt.

So, genug geschrieben. Denkt was ihr wollt. Es ändert sich ja doch 
nichts.

[J. S. (jojos)]

Arduino hat ein Beispiel wie man eigene Klassen und eine eigene Lib 
baut:
https://docs.arduino.cc/learn/contributions/arduino-creating-library-guide/

ok, aber auch da wird nur von 'Arduino Language' gesprochen und nirgends 
das es ja C++ Features sind.

[Sebastian W. (wangnick)]

Arduino F. schrieb:
> z.B. häufig genutzt werden Serial, Wire und String.
> Und schon bist du tief in C++ und OOP

Ich hätte jetzt die Arduino-Klassen Print und vor allem Printable 
herangezogen. Das Konzept ist schon sehr schön.

Dass allerdings die Dokumentation bei Arduino unter aller Sau ist, ist 
glaube ich Konsens.

LG, Sebastian

[Arduino F. (Firma: Gast) (arduinof)]

Sebastian W. schrieb:
> Ich hätte jetzt die Arduino-Klassen Print und vor allem Printable
> herangezogen. Das Konzept ist schon sehr schön.

Naja...

Stream implementiert Print
Serial erbt von bzw. implementiert Stream,
Wire implementiert ebenfalls Print

Print ist also fett in meiner kurzen Liste enthalten, wenn auch 
verdeckt.
Print ist als abstrakte Klasse nicht direkt nutzbar, nur über Vererbung.
Somit: Print sieht man in den übliche Sketchen eher nicht.
Allerdings Serial durchaus.
Print er in den Libs.

Wie auch immer, jeder Arduino Krieger hat dauernd mit den OOP und 
sonstigen C++ Features zu tun.
Aber hier sehen manche nur Hasen.

[Manfred P. (pruckelfred)]

Arduino F. schrieb:
> Wie auch immer, jeder Arduino Krieger hat dauernd mit den OOP und
> sonstigen C++ Features zu tun.
> Aber hier sehen manche nur Hasen.

Ich finde diese Diskussion nur noch dämlich.

Das Ziel von Arduino ist, den Anwender nicht mit Details zu behelligen. 
Es ist doch scheißegal, dass A* nirgendwo auf C++ hinweist, obwohl es 
GCC unter dem Deckel hat, es funktioniert einfach.

Ob irgendwelche Dinge, die A* nicht an Bord hat, nun Library oder Klasse 
heißen, ist mir ebenso Wurst, wenn es spielt. Ich habe mit A* Dinge 
gemacht, die deutlich mehr als LED-blinken machen und muß dafür nicht im 
Detail wissen, was unter der Haube passiert.

[Roland F. (rhf)]

Hallo,
Arduino F. schrieb:
> Wie auch immer, jeder Arduino Krieger hat dauernd mit den OOP und
> sonstigen C++ Features zu tun.

Es ist wohl eher so das jeder Arduino Krieger dauernd OOP- und
sonstige C++ Features nutzt, ohne sich weder darüber klar zu sein noch 
wissen muss worum es sich dabei handelt.

rhf

[Spess53 .. (hardygroeger)]

Hi

Interessant wie hier das Recht der Arduinojunger auf Dummheit 
verteidigt wird. DA weiss man ja, woher die kommt.

Da kann man nur froh sein, das die Erfinder nicht Pascal für dieses 
Debakel gewählt haben.

MfG Spess

[Monk (roehrmond)]

Veit D. schrieb:
> Und wer Arduino nicht nutzt, sich aber darüber künstlich aufregt
> du regst dich wie Monk nur künstlich auf
> Eigentlich regt man sich doch auf wenn man irgendwas benutzt

Ich nutze Arduino.

Und ich rege mich nicht nicht auf. Mein Puls ist ganz unten. Ich übe 
lediglich Kritik and der Dokumentation von Arduino.

Sebastian W. schrieb:
> Dass allerdings die Dokumentation bei Arduino unter aller Sau ist, ist
> glaube ich Konsens.

Offenbar nicht. Das Thema wird kontrovers diskutiert, was auch völlig OK 
ist.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Veit D. schrieb:
> Nur weil das gesamte Programm Sketch heißt und die Dateiendung .ino
> soll das nun automatisch alles schlecht sein? ...
> Das ist jetzt irgendwie Kindergarten hoch 10.
Es ist aber eben auch Kindergarten hoch 100, wenn man nicht sagen darf, 
dass etwas eigenartig ist (= eine eigene Art hat), ohne dass einem dann 
gleich unterstellt wird, man habe gesagt, dass "alles schlecht" wäre.

> Wie alt bist du?
Alt genug um das Arduino-Environment mit einigen anderen 
Entwicklungsumgebungen vergleichen zu können.

> Und wer Arduino nicht nutzt, sich aber darüber künstlich aufregt, bei
> dem weiß ich dann auch nicht weiter. Ganz ehrlich.
Ganz ehrlich: ich selber verwende die Arduino auch. Im Schrank liegt 
eine Kiste mit 20-30 solcher Boards. Trotzdem finde ich auch einige 
Dinge daran schlecht. Schlecht ist es, dass da unbedingt von Anfang an 
eine "Insellösung" mit einer eigenen Arduino-Welt erzeugt werden musste 
(ich hätte z.B. einfach die erste vermurkste Charge Leiterplatten 
rausgeschmissen, die Pfostenleisten ins richtige Raster gesetzt und 
nicht einen saublöden Fehler zum "Standard" erklärt).

> Wie gesagt, wenn ihr das nicht nutzt, warum regt ihr euch auf?
> Eigentlich regt man sich doch auf wenn man irgendwas benutzt und es
> funktioniert irgendwas nicht.
Wirklich schlecht ist vor allem, dass nicht von Anfang an ein 
brauchbarer Debugger in den Designanforderungen gestanden hat. Genau das 
hat mich davon abgehalten, das Arduino-Environment tatsächlich produktiv 
für "richtige" Projekte einzusetzen. So dürfen letztlich dann eben die 
Praktikanten und Bacheloranden mit dem Ding herumspielen oder es werden 
lediglich irgendwelche Funktionsmodelle damit gebastelt.

BTW: versuche mal in der aktuellen Arduino IDE-Version 2.3.2 den 
Proxy-Port 80 zu setzen. Du wirst sehen: es geht nicht. Auch nicht 
direkt über die arduino-cli.yaml. Die Ports 79 und 81 können problemlos 
eingestellt werden, kommen aber natürlich nicht durch den Proxy, auf dem 
nur der Port 80 offen ist. Auch das finde ich schlecht, sehr schlecht 
sogar. So bleibt eben nur die Verwendung der alten Version 1.8.19 übrig. 
Da geht das problemlos.

[Karl B. (gustav)]

Michael schrieb:
> ABER immer öfter tritt das Problem auf, dass der Arduino die LOW bzw
> High-Signale falsch interpretiert

Nun ja, ich mach das immer mit wachsender Begeisterung und spielerisch 
so zwischen Mittagspause und Einschlafphase.
(Wozu gibt es eigentlich Atmel Studio. Fremdwort für Arduino-Fans.)
Mit Käsekästchen fällt Nachhilfeunterricht leichter.
Ahh. Eine Osram Lampenfabrik plötzlich aufgegangen. Oder?

ciao
gustav

[Arduino F. (Firma: Gast) (arduinof)]

Karl B. schrieb:
> Fremdwort für Arduino-Fans.
1: Da irrst du!
2: Die Arduino Welt besteht nicht nur aus AVR und SAM

Lothar M. schrieb:
> versuche mal in der aktuellen Arduino IDE-Version 2.3.2 den
> Proxy-Port 80 zu setzen.

Dann bist du das:
https://github.com/arduino/arduino-ide/issues/2336 ?
Schade, dass sich bisher scheinbar noch niemand drum gekümmert hat.

Und doch ist das der richtige Weg

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Arduino F. schrieb:
> Dann bist du das: https://github.com/arduino/arduino-ide/issues/2336
Ja.

> Schade, dass sich bisher scheinbar noch niemand drum gekümmert hat.
Ja, das finde ich auch. Aber wenn ich in den Issues dort nach "Proxy" 
suche, dann betrifft so ein Problem (erstaunlicherweise) nur relativ 
wenige User. Ich hätte gedacht, dass einige User in Firmen hinter Proxys 
sitzen...

[Arduino F. (Firma: Gast) (arduinof)]

Karl B. schrieb:
> Nun ja, ich mach das immer mit wachsender Begeisterung und spielerisch
> so zwischen Mittagspause und Einschlafphase.
> (Wozu gibt es eigentlich Atmel Studio. Fremdwort für Arduino-Fans.)
> Mit Käsekästchen fällt Nachhilfeunterricht leichter.
> Ahh. Eine Osram Lampenfabrik plötzlich aufgegangen. Oder?

Was möchtest du damit sagen?

Dein lustiger ASM Code lässt sich übrigens problemlos nach C++ portieren 
und das Kompilat ist identisch mit deiner Variante.

000000c4 <main>:

int main() 
{
  constexpr byte a {0x11};
  DDRB  = a;
  c4:  81 e1         ldi  r24, 0x11  ; 17
  c6:  84 b9         out  0x04, r24  ; 4
  PORTB = a;
  c8:  85 b9         out  0x05, r24  ; 5
  
  constexpr byte b {0x55};
  DDRB = b;
  ca:  85 e5         ldi  r24, 0x55  ; 85
  cc:  84 b9         out  0x04, r24  ; 4
  PINB = b;
  ce:  83 b9         out  0x03, r24  ; 3
  
  PINB  = 0x01;
  d0:  81 e0         ldi  r24, 0x01  ; 1
  d2:  83 b9         out  0x03, r24  ; 3
  PORTB = 0xAA;
  d4:  8a ea         ldi  r24, 0xAA  ; 170
  d6:  85 b9         out  0x05, r24  ; 5
  while(1){}
  d8:  ff cf         rjmp  .-2        ; 0xd8 <main+0x14>

[Manfred P. (pruckelfred)]

Lothar M. schrieb:
> (ich hätte z.B. einfach die erste vermurkste Charge Leiterplatten
> rausgeschmissen, die Pfostenleisten ins richtige Raster gesetzt und
> nicht einen saublöden Fehler zum "Standard" erklärt).

Das bezieht sich auf den Uno. Ich habe mir damals zwei Chinesen-Uno zum 
Spielen gekauft. Für tatsächliche Anwendungen verwende ich A*-Nano, der 
passt ins Raster und belegt keine unnötige Fläche.

Wenn ich Strom sparen will, dann eben ProMini.

Wenn man über modernere µCs spricht, kommen alle Boards im 
2,54er-Raster, der UNO ist nur noch für Shield-Kiddies.

[Arduino F. (Firma: Gast) (arduinof)]

Manfred P. schrieb:
> Das bezieht sich auf den Uno.

Das Steck Layout ist eine "Sicherung" gegen versehentliches falsch rum 
drauf stecken. Solche, oder ähnliche, Steckercodierungen sind in der 
Industrie und im KFZ Bereich allgegenwärtig-
Natürlich forcieren die Arduino Basher eine andere "Theorie", die "zu 
dumm zum zum" Theorie.

Auch wissen die  Arduino Basher meist nicht wo der Begriff Sketch der 
Arduino Welt her stammt. Oder auch das setup() und loop().

[Manfred P. (pruckelfred)]

Arduino F. schrieb:
> Manfred P. schrieb:
>> Das bezieht sich auf den Uno.
> Das Steck Layout ist eine "Sicherung" gegen versehentliches falsch rum
> drauf stecken.

Das bekommt man auch anders hin.

> Natürlich forcieren die Arduino Basher eine andere "Theorie", die "zu
> dumm zum zum" Theorie.

Du hast ein recht primitives Bild der Umgebung - Kritik und Bashing sind 
unterschiedliche Dinge.

> Auch wissen die  Arduino Basher meist nicht wo der Begriff Sketch der
> Arduino Welt her stammt. Oder auch das setup() und loop().

Und nochmal von Dir ein unqualifiziertes "Basher".

Falls es Dir entgangen sein sollte: Ich verwende Arduino, sowohl die 
Hardware als auch deren IDE. Lothar M., der (zu recht) das Layout 
beanstandet hat, ist aktiv dabei. Wenn wir A* richtig scheiße finden 
würden, hätten wir etwas anderes!

Also höre mit Deinen Unterstellungen auf und akzeptiere, dass es 
Kritikpunkte gibt.

Zu Sketch, setup() und loop() hätte ich gerne Deine Erklärung, 
tatsächlich weiß ich nicht, welcher Abstammung diese Begriffe sind.

Man könnte aber auch sagen, dass das egal ist, solange man sie zu 
benutzen weiß.

[Arduino F. (Firma: Gast) (arduinof)]

Manfred P. schrieb:
> Zu Sketch, setup() und loop() hätte ich gerne Deine Erklärung,
> tatsächlich weiß ich nicht, welcher Abstammung diese Begriffe sind.

Arduino ist u.A. aus der Beschäftigung mit Processing gewachsen.

setup() ist quasi übernommen
https://processing.org/reference/setup_.html

draw() war jetzt nicht gerade angemessen für die kleinen AVR ohne 
Display
Aber dennoch: https://processing.org/reference/setup_.html
(der Vollständigkeit zur Liebe)

loop() hat in einer Processing Welt eine etwas andere Aufgabe.
https://processing.org/reference/loop_.html

Daraus (aus draw() bzw. loop()) wurde dann das Arduino loop()
https://www.arduino.cc/reference/de/language/structure/sketch/loop/

Auch digitalWrite() und viel weiteres Dedönse kommt direkt aus genau 
dieser Ecke.
https://processing.org/reference/libraries/io/GPIO_digitalWrite_.html

[Arduino F. (Firma: Gast) (arduinof)]

Manfred P. schrieb:
> Kritik und Bashing sind
> unterschiedliche Dinge.

Die Steckleisten auf dem Uno sind wie sie sind.
Das kann man toll finden, oder hassen.
Oder irgendwo dazwischen.

Was die Faktenlage her gibt, ist dagegen Glasklar!

Die Leisten sind wie sie sind, und bleiben auch so.
Da beißt kein Basher mehr einen von ab.

Wer jetzt noch nach gefühlten 20 Jahren weiter darauf in der 
Öffentlichkeit rum hackt, hat ein mentales Problem. Evtl. eine 
neurotische Fehlanpassung.

Manfred P. schrieb:
> Bashing
Ob Bashing das richtige Wort ist?

KA!
Wie nennst du Leute, welche sich (gerne auch immer wieder) über Dinge 
Aufregen, diese anprangern, ohne dass irgendwer, z.B. Nobody, irgendwas 
dagegen unternehmen kann?

Klar kann es sein, dass einem Kind die Füße falsch gewachsen sind...
Aber muss man es wirklich dafür ein Jahrzehnt, oder zwei davon, mobben?


Leitsatz:
> Gott gebe mir Gelassenheit, hinzunehmen, was nicht zu ändern ist.
> Mut zu ändern, was ich ändern kann.
> Und die nötige Weisheit, zwischen beidem zu unterscheiden.

Manfred P. schrieb:
> Und nochmal von Dir ein unqualifiziertes "Basher".
Dann versuche ich das mal ein bisschen deutlicher zu "qualifizieren"

Ein Vollblut Basher interessiert sich nicht für die Geschichte dahinter.
Ihm wird auch die Doku nicht lesen.
Nicht in den Code schauen.

Es ist viel einfacher zu bashen, wenn der Geist nicht von Fakten und 
Wissen getrübt ist.

[Arduino F. (Firma: Gast) (arduinof)]

Arduino F. schrieb:
> draw() war jetzt nicht gerade angemessen für die kleinen AVR ohne
> Display
> Aber dennoch: https://processing.org/reference/setup_.html
> (der Vollständigkeit zur Liebe)

Sorry sollte natürlich
https://processing.org/reference/draw_.html
heißen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Arduino F. schrieb:
> Das Steck Layout ist eine "Sicherung" gegen versehentliches falsch rum
> drauf stecken.
1. Wenn das notwendig war, warum wurden dann spätere Boards völlig 
symmetrisch aufgebaut?
2. Ich hätte diese "Verdrehsicherung" auch ohne absurde Rasterung 
hinbekommen.
3. Es war tatsächlich ein Schlampigkeitsfehler, der hinterher zum 
"Kundennutzen" umgemünzt wurde:
- https://forum.arduino.cc/t/what-were-they-thinking/112911/4
- 
https://electronics.stackexchange.com/questions/940/arduino-pin-spacing

Arduino F. schrieb:
> Die Steckleisten auf dem Uno sind wie sie sind.
Und auch das umständliche Debugging ist so wie es ist und auch die IDE 
mit ihren Macken ist so wie sie ist.

> Das kann man toll finden, oder hassen.
> Oder irgendwo dazwischen.
Aber durchdacht und durchgängig geht eben anders.

[Arduino F. (Firma: Gast) (arduinof)]

Lothar M. schrieb:
> Arduino F. schrieb:
>> Die Steckleisten auf dem Uno sind wie sie sind.
> Und auch das umständliche Debugging ist so wie es ist und auch die IDE
> mit ihren Macken ist so wie sie ist.

Das Verfahren, welches du hier zur Anwendung bringst nennt sich
https://de.wikipedia.org/wiki/Whataboutism

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Arduino F. schrieb:
> Lothar M. schrieb:
>> Arduino F. schrieb:
>>> Die Steckleisten auf dem Uno sind wie sie sind.
>> Und auch das umständliche Debugging ist so wie es ist und auch die IDE
>> mit ihren Macken ist so wie sie ist.
> Das Verfahren, welches du hier zur Anwendung bringst nennt sich
> https://de.wikipedia.org/wiki/Whataboutism
Ganz im Gegenteil: ich habe nicht mit einer unzusammenhängenden 
Gegenfrage gekontert, sondern nur den von dir gespielten Ball in die 
selbe Richtung verlängert. Denn du sagst: das Pinout vom Arduino ist so 
wie es ist, wer das nicht gut findet, der soll irgendwas anderes nehmen. 
Und ich sage das auch vom Debugging und der IDE.

> Wer jetzt noch nach gefühlten 20 Jahren weiter darauf in der
> Öffentlichkeit rum hackt, hat ein mentales Problem.
> Evtl. eine neurotische Fehlanpassung.
Wer da nach echten 19 Jahren noch sensibel drauf reagiert, der aber 
auch.

Arduino F. schrieb:
> Klar kann es sein, dass einem Kind die Füße falsch gewachsen sind...
Die sind nicht zufällig falsch gewachsen, sondern sie wurden wie gesagt 
aus Versehen fehlerhaft platziert. Zitat von 
https://de.wikipedia.org/wiki/Arduino_(Plattform): "Die erste Auflage 
des Boards betrug 200 Stück, davon gingen 50 an eine Schule." Und dass 
diese offensichliche Fehlstellung der Füße nicht schon spätestens beim 
201. Board korrigiert wurde, dafür können "die vielen Shields am Markt" 
sicher nicht als Grund vorgehalten werden, denn die gab es da noch gar 
nicht.

Und solche Nachlässigkeiten sind für mich irgendwie der Grundtenor des 
gesamten Arduino-Environments.

Arduino F. schrieb:
> Leitsatz:

Gott gebe mir Gelassenheit, hinzunehmen, was nicht zu ändern ist.
Mut zu ändern, was ich ändern kann.
Und die nötige Weisheit, zwischen beidem zu unterscheiden.

Genau das Zweite fehlt dem Arduino-Team offenbar. Also gilt dieser 
"Leitsatz" (aka https://de.wikipedia.org/wiki/Gelassenheitsgebet) nur 
für die User.

Deshalb bleibt mir nur das Erste übrig: ich finde mich damit ab und 
verwende die alte IDE.

Und in diesem Sinne sei es wie es will, ich setze den Arduino weiterhin 
dort ein, wo der Entwickler ganz offensichtlich auch seinen Platz 
gesehen hat: bei irgendwelchen Basteleien und Funktionsmodellen, aber 
sicher nicht in einem produktiven Umfeld in einer Serie.

[Obelix X. (obelix)]

Lothar M. schrieb:
> Deshalb bleibt mir nur das Erste übrig: ich finde mich damit ab und
> verwende die alte IDE.

Oder man schaut mal über den Tellerrand und schaut sich z.B. mal 
PlatformIO (Visual Studio Code) an. Die Programme (Sketches) können 1:1 
weiter verwendet werden. Beim Programmieren muss man sich also nicht 
umgewöhnen.

[Loco M. (loco)]

Was hat eigentlich euer ganzes Gelaber noch mit dem eingangs 
beschriebenen Problem zu tun?

Ich finde die letzten 60 oder mehr Beiträge gehören gelöscht (auch die 
vom Moderator) und ein Schloss an den Thread.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Loco M. schrieb:
> ein Schloss an den Thread.
Geht nicht, denn der TO Michael hat vor einer Woche versprochen, von 
seinem Fortschritt zu berichten, denn

Michael schrieb:
> Habt einen schönen Freitag, ich werde berichten.

Damit er seinen Thread leicht wiederfindet, halten wir den aktiv oben in 
der Liste. Und so lange wir das tun, tun wir schon keinen anderen 
Blödsinn...  ;-)

[Arduino F. (Firma: Gast) (arduinof)]

Lothar M. schrieb:
> Denn du sagst: das Pinout vom Arduino ist so
> wie es ist, wer das nicht gut findet, der soll irgendwas anderes nehmen.
Das ist gelogen!
Das habe ich nicht gesagt!

Lothar M. schrieb:
> Die sind nicht zufällig falsch gewachsen,
Habe ich das behauptet?
Soweit ich weiß, nicht...
Wie auch immer, Mobbing und/oder dauerhaftes Nörgeln lässt sich nicht 
damit rechtfertigen. Vielleicht kannst du das. Ich nicht.

Loco M. schrieb:
> Ich finde die letzten 60 oder mehr Beiträge gehören gelöscht (auch die
> vom Moderator) und ein Schloss an den Thread.
Ich stimme zu!
Und damit endet es auch hier für mich.

[Karl B. (gustav)]

Arduino F. schrieb:
> Was möchtest du damit sagen?

Es ging doch um die Veranschaulichung mit den Kästchen im Debugger im 
ATMEL Studio.
Wenn man nicht weiß, was überhaupt passiert, hilft das vielleicht, erst 
einmal zu simulieren. Beitrag "MSF60 Dekoder AVR Teil_2"
Step by step mit F10
Dabei gilt die Einschränkung, dass Timings und Zeitschleifen 
zwangsläufig nicht stimmen können(ISRs). Und auf externe Abfragen kann 
natürlich nicht reagiert werden.
Aber Portzuweisungen etc., was im Thread ja das Kernproblem zu sein 
scheint, lassen sich gut darstellen.

ciao
gustav

[Monk (roehrmond)]

Arduino F. schrieb:
> Ein Vollblut Basher interessiert sich nicht für die Geschichte dahinter.
> Ihm wird auch die Doku nicht lesen.
> Nicht in den Code schauen.

Na dann hast du ja gleich drei Gründe genannt, die mich als "Basher" 
ausschließen.

[Arduino F. (Firma: Gast) (arduinof)]

Monk schrieb:
> Na dann hast du ja gleich drei Gründe genannt, die mich als "Basher"
> ausschließen.

Nein!

Unterscheide zwischen "Basher" und "Vollblut Basher".
Du und Lothar seid einfach nur Basher.
Euch beiden traue ich zu die Doku zu lesen und in den Code zu schauen.
Ob ihr das auch wirklich tut?
Naja, das ist nicht immer zu erkennen.

Nachdem ich dir über die letzten Jahre einige Dutzend mal den Kopf 
gewaschen habe, bist du ein Basher mit Erfahrung.
Klarer: Es kommen mittlerweile weniger Falschinformationen von dir.
Ein Schritt in die richtige Richtung, würde ich mal sagen.

[Monk (roehrmond)]

Arduino F. schrieb:
> Nachdem ich dir über die letzten Jahre einige Dutzend mal den Kopf
> gewaschen habe, bist du ein Basher mit Erfahrung.

Was stinkt hier so?
.
.
.
Schnüff schnüff
.
.
.
Es riecht nach Eigenlob. Ist ja ekelhaft.

[Michael (micha1980)]

Ich hab die Diskussion jetzt nicht durchgelesen, dafür reicht meine 
Lebenszeit nicht aus.
Also Eingang auf 5V gelegt und den erwähnten Eintrag entfernt.
Geändert hat sich aber nichts.

Nun die Frage zu dem Code
Falk B. schrieb:

>#define INPUT1 (1<<0)   // Bitmuster für Codeauswertung
>#define INPUT2 (1<<1)   // Bitmuster für Codeauswertung
>#define INPUT12 (INPUT1 | INPUT2)   // Bitmuster für Codeauswertung, beide 
>Eingänge
>Adafruit_NeoPixel pixels(NUMPIXELS, NEOPIXEL_PIN, NEO_GRBW + NEO_KHZ800);
>int code, flanke;
>int code_old;
>bool led_active = false;

Ich nutze nur Code, den ich verstehe, daher meine Frage:
-Was genau macht das Bitmuster für die Codeauswertung?
-Was bedeutet der senkrechte Strich
-was bedeutet code, flanke
-was bedeutet code_old
das bool bedeutet vermutlich, dass standardmäßig die LED aus sind.

Danke

[Wastl (hartundweichware)]

Michael schrieb:
> Ich nutze nur Code, den ich verstehe, daher meine Frage:

Na das wird noch lustig hier ....

[Falk B. (falk)]

Michael schrieb:
> Nun die Frage zu dem Code
> Falk B. schrieb:
>
>>#define INPUT1 (1<<0)   // Bitmuster für Codeauswertung
>>#define INPUT2 (1<<1)   // Bitmuster für Codeauswertung
>>#define INPUT12 (INPUT1 | INPUT2)   // Bitmuster für Codeauswertung, beide
>>Eingänge
>>Adafruit_NeoPixel pixels(NUMPIXELS, NEOPIXEL_PIN, NEO_GRBW + NEO_KHZ800);
>>int code, flanke;
>>int code_old;
>>bool led_active = false;
>
> Ich nutze nur Code, den ich verstehe, daher meine Frage:
> -Was genau macht das Bitmuster für die Codeauswertung?

Na es prüft, ob einer der beiden Eingänge aktiv ist oder beide, je nach 
dem, welches Muster man benutzt. Steht auch als Kommentar unten im Code.

> -Was bedeutet der senkrechte Strich

Ein binäres ODER, siehe Bitmanipulation.

> -was bedeutet code, flanke

Das sind Variablen, die ich defintiert habe.

> -was bedeutet code_old

Ebenso.

> das bool bedeutet vermutlich, dass standardmäßig die LED aus sind.

Stimmt.

[Arduino F. (Firma: Gast) (arduinof)]

Michael schrieb:
> Was bedeutet der senkrechte Strich
Suchtipp: "C++ operatoren"

[Falk B. (falk)]

  if (digitalRead(SENSORPIN1)) code |= INPUT1; // Eingang 1 einlesen und in Bit #0 von code speichern
  if (digitalRead(SENSORPIN1)) code |= INPUT2; // Eingang 2 einlesen und in Bit #1 von code speichern
  flanke = code & ~code_old;  // positive Flankenerkennung für beide Signale, Speicherung in flanke (auch was!)
  code_old = code;  // aktuellen Zustand von code für später speichern, damit dann wieder Flankenerkennung gemacht werden kann

[Michael (micha1980)]

Der Code funktioniert leider nicht richtig:
-hell geht an, schaltet dann aber sofort auf bunt
-beim Ausschalten bleibt der rote Kometenschweif stehen (quasi ein 
Nachtlicht ;))
-dunkel wird gänzlich ignoriert

Das habe ich doch richtig eingefügt oder?
void loop() {
  code = 0;

Danke für deine Mühe.

[Falk B. (falk)]

Michael schrieb:
> Der Code funktioniert leider nicht richtig:

Hmm.

> -hell geht an, schaltet dann aber sofort auf bunt

Das sollte nicht so sein.

> -beim Ausschalten bleibt der rote Kometenschweif stehen (quasi ein
> Nachtlicht ;))

Kann sein. Ich habe deine recht konfusen Schleifen aufgeräumt, da ist 
halt ein Fehler reingekommen.

> -dunkel wird gänzlich ignoriert
>
> Das habe ich doch richtig eingefügt oder?
> void loop() {
>   code = 0;

Ja.

Man muss eine systematische Fehlersuche durchführen.

1. Mit einem Multimeter messen, ob die beiden Eingänge einzeln sauber 
schalten.
2. Mit etwas Zusatzcode prüfen, ob die Logik richtig ist.

Huch, da war noch ein Kopierfehler drin!

  if (digitalRead(SENSORPIN1)) code |= INPUT1;
  if (digitalRead(SENSORPIN1)) code |= INPUT2;

Siehe Anhang, so sollte es funktionieren. Auf dem Arduino-Terminal 
sollte man das Umschalten der Zustände sehen.

[Michael (micha1980)]

Wastl schrieb:
> Na das wird noch lustig hier ....

Learning by doing, daher sollte man wissen, was man da eigentlich macht, 
anstatt blind Codeschnipsel zu kopieren.
Nur so kann man auch Fehler suchen und finden.

Falk B. schrieb:
> Ja.
> Man muss eine systematische Fehlersuche durchführen.

Ich hab "bunt" aus dem Programm geschmissen, zumindest läuft das 
Programm jetzt. Der Fehler tritt ja leider erst später auf und dann 
immer öfter, ich werde das beobachten.

[Arduino F. (Firma: Gast) (arduinof)]

Michael schrieb:
> void EinschaltsequenzTag() {
>   for(int i=-7; i<66; i++) {
>     pixels.setPixelColor(i, pixels.Color(100,100,200,250)); // weiß wird
> hell dargestellt

Manche Dinge verstehe ich nicht!
int i=-7; // ok, kann man tun

Aber dieses hier pixels.setPixelColor(i,
Auch pixels.setPixelColor(i+8, sieht komisch aus.
Das verstehe ich dann beides nicht mehr....
setPixelColor erwartet an der Stelle ein uint16_t von 0 bis NUMPIXELS
Also 0 bis 65, bekommt aber -7 bis 73


Selbst wenn solche Irrwitzigkeiten in der Lib geprüft werden sollten, 
haben wir hier einen offensichtlichen Unterlauf und einen Überlauf, der 
mir doch sehr verdächtig aussieht.
Ein Verstoß gegen die Regel:
> Programmiere immer gegen das Interface einer Methode
> und nie gegen die Implementierung.

[Karl B. (gustav)]

Michael schrieb:
> earning by doing, daher sollte man wissen, was man da eigentlich macht,
> anstatt blind Codeschnipsel zu kopieren.

Ich machs lieber von Grund auf anders. Erstmal in ASM.
Und zwar Portabfragen(ein/aus) separat. Und
Bildmuster in Arrays.
Die beiden Dinge überkreuzen sich in dem Programm oben.
Als Beispiel code im Anhang.
Die Entprellroutine gibt es auch in ASM, fehlt hier der Einfachheit 
halber.

ciao
gustav

[Falk B. (falk)]

Arduino F. schrieb:
> Michael schrieb:
>> void EinschaltsequenzTag() {
>>   for(int i=-7; i<66; i++) {
>>     pixels.setPixelColor(i, pixels.Color(100,100,200,250)); // weiß wird
>> hell dargestellt
>
> Manche Dinge verstehe ich nicht!
> int i=-7; // ok, kann man tun
>
> Aber dieses hier pixels.setPixelColor(i,
> Auch pixels.setPixelColor(i+8, sieht komisch aus.
> Das verstehe ich dann beides nicht mehr....

setPixelColor() ist eine Methode zum Setzen der Farbe eines Pixels. 
Dabei wird nicht der Pixel in Hardware beschrieben, sondern der interne 
Puffer(RAM).
pixels.Color() ist eine Methode, um aus RGBW Einzelwerten einen 
zusammengesetzten Wert zu erzeugen, den die Methode setPixelColor() 
haben will.
Erst die Methode show() schreibt die internen Daten auf die realen Pixel 
in Hardware.

> Selbst wenn solche Irrwitzigkeiten in der Lib geprüft werden sollten,
> haben wir hier einen offensichtlichen Unterlauf und einen Überlauf, der
> mir doch sehr verdächtig aussieht.

Ist er auch, deswegen hab ich das auch geändert. Aber der OP will halt 
einen Anlaufeffekt haben. Praktisch funktioniert es, denn die Methode 
prüft den Parameter und reagiert entsprechend.

> Ein Verstoß gegen die Regel:
>> Programmiere immer gegen das Interface einer Methode
>> und nie gegen die Implementierung.

Ja, aber ebenso sollte/muss jede Methode ihre Eingangsparameter auf 
einen gültigen Wertebereich prüfen.

[Falk B. (falk)]

Karl B. schrieb:
> Michael schrieb:
>> earning by doing, daher sollte man wissen, was man da eigentlich macht,
>> anstatt blind Codeschnipsel zu kopieren.
>
> Ich machs lieber von Grund auf anders. Erstmal in ASM.

Unsinn^3. Aber das haben wir schon dutzende Male diskutiert.

> Als Beispiel code im Anhang.

ASM ist hier gar nicht gefragt, schon gar nicht bei den VOraussetzungen 
des OPs.

[Falk B. (falk)]

Michael schrieb:
> Ich hab "bunt" aus dem Programm geschmissen, zumindest läuft das
> Programm jetzt. Der Fehler tritt ja leider erst später auf und dann
> immer öfter, ich werde das beobachten.

Du sollst MESSEN! Außerdem war in meiner 1. Version noch ein Fehler 
drin.

[Arduino F. (Firma: Gast) (arduinof)]

Falk B. schrieb:
> setPixelColor() ist eine Methode zum Setzen der Farbe eines Pixels.
> Dabei wird nicht der Pixel in Hardware beschrieben, sondern der interne
> Puffer(RAM).

Das musst du mir nicht erklären!

Falk B. schrieb:
> Ja, aber ebenso sollte/muss jede Methode ihre Eingangsparameter auf
> einen gültigen Wertebereich prüfen.

Ich halte es es für etwas schlampig, Methoden mit kaputten Werten 
aufzurufen.
Und schon gar nicht, sollte sich das zu einer Grundeinstellung 
entwickeln.

Es bieten sich einfach zu viele Wege, in  C++ in ein UB zu stolpern.
Pointer/Array Unter- Überläufe stehen da ganz weit oben, auf der Liste.

Die Sorgfalt eines Lib Programmierers kann kein Freibrief für eigene 
Schlampigkeiten sein.

Falk B. schrieb:
> Praktisch funktioniert es,
Möglich... habe nirgendwo das Gegenteil behauptet.
Das macht es aber nicht schön.

Und das nächste mal, bei der nächsten Lib, kann man damit auf die Nase 
fallen.

[Falk B. (falk)]

Arduino F. schrieb:
> Falk B. schrieb:
>> setPixelColor() ist eine Methode zum Setzen der Farbe eines Pixels.
>> Dabei wird nicht der Pixel in Hardware beschrieben, sondern der interne
>> Puffer(RAM).
>
> Das musst du mir nicht erklären!

Ja warum schreibst du dann sowas?

>>Auch pixels.setPixelColor(i+8, sieht komisch aus.
>>Das verstehe ich dann beides nicht mehr...."

Vielleicht mal versuchen, weniger lässig zu sein und dafür klar 
kommunizieren.

> Falk B. schrieb:
>> Ja, aber ebenso sollte/muss jede Methode ihre Eingangsparameter auf
>> einen gültigen Wertebereich prüfen.

> Ich halte es es für etwas schlampig, Methoden mit kaputten Werten
> aufzurufen.
> Und schon gar nicht, sollte sich das zu einer Grundeinstellung
> entwickeln.

Stimmt, aber der OP ist Lichtjahre davon entfernt, ein Entwickler zu 
sein.
Er ist der Hobbybastler der Hobbybastler.

[J. S. (jojos)]

An solchen UB Fällen verzweifelt ein Anfänger aber noch mehr. Wir hatten 
hier schon mehr als einmal Fälle wo der Compiler Code der nicht 
durchlaufen werden muss wegoptimiert. Dazu die Einstellung von Arduino 
wo man den User lieber nicht mit zu vielen Meldungen (Warnungen) 
belästigt.

[Falk B. (falk)]

J. S. schrieb:
> An solchen UB Fällen verzweifelt ein Anfänger aber noch mehr. Wir hatten
> hier schon mehr als einmal Fälle wo der Compiler Code der nicht
> durchlaufen werden muss wegoptimiert.

Was ist daran undefiniertes Verhalten?

> Dazu die Einstellung von Arduino
> wo man den User lieber nicht mit zu vielen Meldungen belästigt.

Ist halt so. Man kann die Meldungen des Compiler ja aktivieren, auch als 
Noob. Ist ein Häkchen in den Einstellungen.

Die meisten Libs von Arduino sind schon relativ defensiv und 
idiotensicher programmiert, damit eben solche Parameterfehler von 
Anfängern abgefangen werden.

[Karl B. (gustav)]

Arduino F. schrieb:
> Es bieten sich einfach zu viele Wege, in  C++ in ein UB zu stolpern.
> Pointer/Array

Yes sir.
Deutete ich oben schon an.
Aber was die einen als Unsinn titulieren, wird anderen schnell deutlich, 
wie man am effektivsten zum Ziele kommt.
Ob ASM oder C++ spielt doch keine Rolle.

Nochmals: Die Schalter haben mit der Lauflichtfunktion zunächst 
garnichts zu tun.
Die ursprüngliche Frage bezog sich auf die "Schalter".
Und wieso die einmal funktionieren, dann wieder nicht.
Falk B. schrieb:
> Aber der OP will halt
> einen Anlaufeffekt haben.
Das kann man mit Array machen. Und die Timerwerte als solche ebenfalls
in ein Array schreiben.
Zur Sichrheit noch einen Watchdog aktivieren. Falls es zu:

Arduino F. schrieb:
> Unter- Überläufe stehen da ganz weit oben, auf der Liste.

uerwartetem Verhalten kommt.

ciao
gustav

[Falk B. (falk)]

Karl B. schrieb:
> Falk B. schrieb:
>> Aber der OP will halt
>> einen Anlaufeffekt haben.
> Da kann man mit Array machen. Und die Timerwerte als solche ebenfalls
> in ein Array schreiben.
> Zur Sichrheit noch einen Watchdog aktivieren. Falls es zu:

Geh einfach woanders labern. Danke!

[Arduino F. (Firma: Gast) (arduinof)]

Karl B. schrieb:
> wie man am effektivsten zum Ziele kommt

Wenn das das einzige Ziel ist.....

Wenn man den ganzen anderen Kram/Beiwerk mal weglässt kommt man im Kern 
auf sowas:
unsigned i = -7;
Was auf den ersten Blick schon arg unlogisch erscheint.
Das geht dennoch durch, wohl ein Relikt aus der C Zeit.

C++ bietet da schon einiges mehr, um solche "Versehen" wenigstens zu 
bemerken:
unsigned i {-7};

Wird angemeckert:
warning: narrowing conversion of '-7' from 'int' to 'unsigned int' 
[-Wnarrowing]

Karl B. schrieb:
> Ob ASM oder C++ spielt doch keine Rolle.
Dein Assembler hat keine Chance überhaupt irgendeine Schlampigkeit 
solcher Art zu bemerken.

Natürlich liefert "unsigned i = -7;" auch unterschiedliche Werte in i, 
in Abhängigkeit davon wieviel Bit ein unsigned hat.
Könnte ein Problem mit der Portierung geben. Aber mit Portierungen haben 
ASM Leute ja sowieso nix am Hut, ganz im Gegensatu zu den Arduino 
Leuten.

[Falk B. (falk)]

So, jetzt hab ich es mal real aufgebaut und getestet, DOH! Da war noch 
ein kleiner Fehler drin, darum wurde es sofort pink. Siehe Anhang, jetzt 
funktioniert alles korrekt!

[Falk B. (falk)]

Ahhhhhhh, in meiner letzten VErsion sind noch Testeinstellungen drin! 
Oder anders formuliert, bau deine Schaltung auf Pull-Up Widerstände um, 
wie es der Rest der Welt macht. Dann funktioniert die Software ohne 
Änderungen.

[Karl B. (gustav)]

Arduino F. schrieb:
> Dein Assembler hat keine Chance überhaupt irgendeine Schlampigkeit
> solcher Art zu bemerken.

Weil ich dabei auch keinen C oder sonstwas Compiler brauche, der mir 
Mist macht.
Der "Assembler" macht nur 0 erros 0 warnings.
Ob das Programm etwas Sinnvolles macht oder nicht ist dem egal.
Hauptsache die Syntax stimmt.
Und wenn Dein schlauer C++-Compiler dem Mist nicht merkt, taugt der 
genausowenig.

ciao
gustav

[Arduino F. (Firma: Gast) (arduinof)]

Karl B. schrieb:
> wenn Dein

Verstehe mich bitte falsch!

Das Eingangsprogramm ist eine Arduino Anwendung.
ASM ist in der Arduino Anwendungsentwicklung nicht sehr verbreitet.
Und das aus guten Gründen.

Es ist an dir das zu akzeptieren.

[Karl B. (gustav)]

"Assembler" ist nicht die ASM Programmiersprache hier, sondern das 
Programm, dass "assembliert", also aus Mnemonik dann umsetzt.
Warum man bei C und Derivaten nicht auch "Assembler" sagt, sondern 
"Compiler" ist nicht so ganz klar.
So könnte man bei ASM den "Assembler" durchaus auch "Compiler" nennen.
Afaik wurde früher der Unterschied so erklärt, dass ein Assembler 
übersetzt und zwar Schritt für Schritt, wobei ein Compiler alles in 
einem Rutsch übersetzt. Stimmt wohl nicht mehr ganz definitionsmäßig.

ciao
gustav

[Arduino F. (Firma: Gast) (arduinof)]

Karl B. schrieb:
> dass ein Assembler
> übersetzt und zwar Schritt für Schritt, wobei ein Compiler alles in
> einem Rutsch übersetzt.

Du bist verwirrt!
> Abgrenzung zu Hochsprachencompilern
https://de.wikipedia.org/wiki/Assembler_(Informatik)

Vielleicht solltest du mal mit dem Onkel Doktor sprechen

[Karl B. (gustav)]

Erkläre den Unterschied:
https://t2informatik.de/wissen-kompakt/compiler/
Vielleicht solltest Du erstmal Deine Froschpillen nehmen, bevor Du hier 
herumpöbelst.

ciao
gustav

[Jens G. (jensig)]

Karl B. schrieb:
> Erkläre den Unterschied:
> https://t2informatik.de/wissen-kompakt/compiler/

Da steht:
"Ein Compiler ist ein Programm, das den in einer höheren 
Programmiersprache geschriebenen Quellcode in die maschinenlesbare, 
binäre Sprache übersetzt."

Das ist ein wesentlicher Unterschied zu einem Assembler, der mehr oder 
weniger nur ein 1:1-Übersetzer ist.

[Arduino F. (Firma: Gast) (arduinof)]

Jens G. schrieb:
> ....

Bemerke:
Das Gustav ist nicht an Compilern interessiert.
Es macht hier den ASM Priester.
Ungefragt und unerwünscht. Weit abseits vom Threadthema.

Meine vorläufige Diagnose:
Threadhijacker und Troll
Uneinsichtig, einsam  und verloren


Arduino F. schrieb:
> Zweitens:
> Die größten ASM Priester sind meist auch die größten C++ Versager
Ich schätze, dass wir mit dem Gustav Dingen ein feines Beispiel für 
diese Hypothese vor uns haben.