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 {}
}
```
:
Verschoben durch Moderator
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:
1 | Wichtige Regeln - erst lesen, dann posten! |
2 | ............ |
3 | 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.
Und ein Schaltplan deines Projekts wäre auch ganz gut. Aber bitte kein Fritzing-Wimmelbild!
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.
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?
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".
:
Bearbeitet durch User
Harald K. schrieb: > Nein: Doch! Sobald man eine Batterie und eine Lampe zusammenschaltet hat man doch ein Projekt.
Angehängte Dateien:
-
HIGH_LOW_Schaltbild.png
130 KB -
HIGH_LOW_Schaltbild.png
130 KB
Anbei das Schaltbild und der Programmcode als .txt
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?
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 ...
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:
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.
:
Bearbeitet durch User
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.
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.
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!
Moderation, bitte mal den Beitrag verschieben.
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.
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.
Uuups, kleiner Fehler beim Umstellen. Da fehlt ein code = 0; am Anfang von loop()!
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.
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.
:
Bearbeitet durch Moderator
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.
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.
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?
1 | pinMode(SENSORPIN1, INPUT); |
2 | pinMode(SENSORPIN2, INPUT); |
3 | digitalWrite(SENSORPIN1, LOW); //10KOhm-R |
4 | digitalWrite(SENSORPIN2, LOW); //10KOhm-R |
:
Bearbeitet durch Moderator
Wenn ein Programm nicht wie gewünscht läuft kann man es debuggen : https://www.youtube.com/watch?v=MOJGBwsPD7I
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.
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.
:
Bearbeitet durch User
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...
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.
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.
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?
1 | > pinMode(SENSORPIN1, INPUT); |
2 | > pinMode(SENSORPIN2, INPUT); |
3 | > digitalWrite(SENSORPIN1, LOW); //10KOhm-R |
4 | > 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.
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.
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.
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
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! ;-)
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
:
Bearbeitet durch User
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:
1 | void digitalWrite(uint8_t pin, uint8_t val) |
2 | {
|
3 | uint8_t timer = digitalPinToTimer(pin); |
4 | uint8_t bit = digitalPinToBitMask(pin); |
5 | uint8_t port = digitalPinToPort(pin); |
6 | volatile uint8_t *out; |
7 | |
8 | if (port == NOT_A_PIN) return; |
9 | |
10 | // If the pin that support PWM output, we need to turn it off
|
11 | // before doing a digital write.
|
12 | if (timer != NOT_ON_TIMER) turnOffPWM(timer); |
13 | |
14 | out = portOutputRegister(port); |
15 | |
16 | uint8_t oldSREG = SREG; |
17 | cli(); |
18 | |
19 | if (val == LOW) { |
20 | *out &= ~bit; |
21 | } else { |
22 | *out |= bit; |
23 | }
|
24 | |
25 | SREG = oldSREG; |
26 | }
|
> 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.
:
Bearbeitet durch User
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!
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.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
Arduino F. schrieb: > Hat einen Low Impuls zur Folge, in vielen Fällen will man das nicht. Argument akzeptiert
Angehängte Dateien:
-
Unbenannt.PNG
41 KB
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.
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.
Arduino F. schrieb: > Hier zu nörgeln bewirkt nix. Doch: Dass Anfänger mitbekommen, daß das Arduino Framework nicht der Weisheit letzter Schluss ist.
:
Bearbeitet durch User
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!
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.
:
Bearbeitet durch User
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.
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
1 | pinMode (Key1, INPUT); |
2 | 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.
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"
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.
:
Bearbeitet durch User
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 ;-)
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
:
Bearbeitet durch User
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
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
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.
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. --------
Arduino F. schrieb: > z.B. häufig genutzt werden Serial, Wire und String. Und ich dachte Herr Frings weiss was Objekte und Instanzen sind.
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.
:
Bearbeitet durch User
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?
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.
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
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.
:
Bearbeitet durch User
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 :-)
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
Beitrag #7727873 wurde von einem Moderator gelöscht.
Beitrag #7727878 wurde von einem Moderator gelöscht.
Beitrag #7727898 wurde von einem Moderator gelöscht.
Beitrag #7727899 wurde von einem Moderator gelöscht.
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.
:
Bearbeitet durch Moderator
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 ...
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.
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.
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.
:
Bearbeitet durch User
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
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.
:
Bearbeitet durch User
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.
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
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
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.
:
Bearbeitet durch User
Angehängte Dateien:
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.
:
Bearbeitet durch Moderator
Angehängte Dateien:
-
Debug_Ports_-_Kopie.jpg
12 KB
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
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
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...
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.
1 | 000000c4 <main>: |
2 | |
3 | int main() |
4 | {
|
5 | constexpr byte a {0x11}; |
6 | DDRB = a; |
7 | c4: 81 e1 ldi r24, 0x11 ; 17 |
8 | c6: 84 b9 out 0x04, r24 ; 4 |
9 | PORTB = a; |
10 | c8: 85 b9 out 0x05, r24 ; 5 |
11 | |
12 | constexpr byte b {0x55}; |
13 | DDRB = b; |
14 | ca: 85 e5 ldi r24, 0x55 ; 85 |
15 | cc: 84 b9 out 0x04, r24 ; 4 |
16 | PINB = b; |
17 | ce: 83 b9 out 0x03, r24 ; 3 |
18 | |
19 | PINB = 0x01; |
20 | d0: 81 e0 ldi r24, 0x01 ; 1 |
21 | d2: 83 b9 out 0x03, r24 ; 3 |
22 | PORTB = 0xAA; |
23 | d4: 8a ea ldi r24, 0xAA ; 170 |
24 | d6: 85 b9 out 0x05, r24 ; 5 |
25 | while(1){} |
26 | d8: ff cf rjmp .-2 ; 0xd8 <main+0x14> |
:
Bearbeitet durch User
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.
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().
:
Bearbeitet durch User
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ß.
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
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.
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch Moderator
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
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:
1 | Gott gebe mir Gelassenheit, hinzunehmen, was nicht zu ändern ist. |
2 | Mut zu ändern, was ich ändern kann. |
3 | 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.
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
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.
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... ;-)
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.
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
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
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.
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
:
Bearbeitet durch User
Michael schrieb: > Ich nutze nur Code, den ich verstehe, daher meine Frage: Na das wird noch lustig hier ....
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.
1 | if (digitalRead(SENSORPIN1)) code |= INPUT1; // Eingang 1 einlesen und in Bit #0 von code speichern |
2 | if (digitalRead(SENSORPIN1)) code |= INPUT2; // Eingang 2 einlesen und in Bit #1 von code speichern |
3 | flanke = code & ~code_old; // positive Flankenerkennung für beide Signale, Speicherung in flanke (auch was!) |
4 | code_old = code; // aktuellen Zustand von code für später speichern, damit dann wieder Flankenerkennung gemacht werden kann |
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.
:
Bearbeitet durch User
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!
1 | if (digitalRead(SENSORPIN1)) code |= INPUT1; |
2 | if (digitalRead(SENSORPIN1)) code |= INPUT2; |
Siehe Anhang, so sollte es funktionieren. Auf dem Arduino-Terminal sollte man das Umschalten der Zustände sehen.
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.
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.
:
Bearbeitet durch User
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
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.
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.
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.
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.
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.
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.
:
Bearbeitet durch User
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.
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
:
Bearbeitet durch User
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!
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.
:
Bearbeitet durch User
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!
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.
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
:
Bearbeitet durch User
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.
"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
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
Erkläre den Unterschied: https://t2informatik.de/wissen-kompakt/compiler/ Vielleicht solltest Du erstmal Deine Froschpillen nehmen, bevor Du hier herumpöbelst. ciao gustav
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.
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.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.