Hallo zusammen,
habe extra Arduino-C geschrieben, da es ja kein " sauberes C " ist bzw.
C++. Aber da habe ich ehrlich geschrieben, nicht wirklich Ahnung von,
denn ich bin ja der ewige AVR8ASM-Übende ;-)
Da mir ASM ja nicht so liegt, dachte ich mir, ich probiers mal mit einer
leichteren, weitverbreiteten Programmiersprache.
Diese ganze Arduino-Sache ist ja nicht für die Profiprogrammierer
gemacht, deshalb werde ich wahrscheinlich auch nicht die Aufmerksamkeit
erlangen, wie sie z.B. hier vorzufinden ist :
Beitrag "Wie lange prellt ein Taster in der Regel?"
Da ich mich aber bei meinen AVR8ASM-Bemühungen intensiv mit dem Problem
befasst hatte, bin ich natürlich in dieser Sache nicht mehr
unvoreingenommen und sehe es evtl. zu kritisch, aber ich finde, erst
50ms nach dem Tastendruck, diesen weiterzuverarbeiten nicht sinnvoll, da
ich auch dieses mit dem Google-Translater gelesen habe :
https://www-ganssle-com.translate.goog/debouncing.htm?_x_tr_sch=http&_x_tr_sl=en&_x_tr_tl=de&_x_tr_hl=de&_x_tr_pto=sc
Wie in der Vergangenheit halt auch intensiv mit PeDa's (Peter Dannegger)
genialen Lösung :
Beitrag "Universelle Tastenabfrage nach PeDa in AVR Assembler"
Deshalb finde ich es sehr verwunderlich, dass so etwas noch immer nicht
wirklich bei den Programmierern angekommen ist.
Die elektronische Welt mit Arduino entdecken - Erik Bartmann in der
4.ten Auflage Kapitel 5, Der störrische Taster, Seite 137 & 138 (
Anti-Prell-Lösung #2 ).
Würde gerne PeDa's C-Lösung, als Arduino-C Lösung mal sehen wollen !
https://www.mikrocontroller.net/articles/Entprellung#Komfortroutine_(C_f%C3%BCr_AVR)
Bernd_Stein
Bernd S. schrieb:> habe extra Arduino-C geschrieben, da es ja kein " sauberes C " ist bzw.> C++.
Du irrst!
Bernd S. schrieb:> Würde gerne PeDa's C-Lösung, als Arduino-C Lösung mal sehen wollen !
Was hindert dich?
Sollte 1:1 laufen, auch unter C++
Arduino F. schrieb:>> Würde gerne PeDa's C-Lösung, als Arduino-C Lösung mal sehen wollen !> Was hindert dich?> Sollte 1:1 laufen, auch unter C++
Tut es auch! Aber der Op ist ein Meister im Verkomplizieren der
einfachsten Dinge, wie er mit hunderten Beiträgen bewiesen hat!
Arduino F. schrieb:> Bernd S. schrieb:>> habe extra Arduino-C geschrieben, da es ja kein " sauberes C " ist bzw.>> C++.> Du irrst!>
Ich weiß nicht - dies habe ich ja auch zu Anfang geschrieben, es sieht
halt immer anders aus wie die "normalen" C-Programme.
Arduino F. schrieb:>> Was hindert dich?> Sollte 1:1 laufen, auch unter C++>
Sollte, hätte, Fahrradkette !
Wahrscheinlich, dass ich mich mit zu vielen neuen Dingen befasse.
Ich benutze Platform IO, weil mir die Arduino-IDE zu lange zum
Kompilieren brauchte.
Beitrag "Platform IO: Serial Monitor"
Wenn du alles im ersten Posting aufmerksam gelesen hast, würde dir evtl.
in Erinnerung geblieben sein, dass ich Arduino-C erst neu für mich
entdeckt habe und bei dem genannten Buch mich auf den Seiten 137 & 138
befinde.
Ihr seid einfach nicht auf meinem Niveau ;-)
Ihr versteht einfach nicht, dass man bei neuen Dingen schnell
Überfordert sein kann.
Was habe ich hier falsch gemacht bzw. vergessen, denn paste & copy
funktioniert doch nicht so einfach mit PeDa's C-Code ( siehe auch
Screenshot ) ?
Falk B. schrieb:> Arduino F. schrieb:>>> Würde gerne PeDa's C-Lösung, als Arduino-C Lösung mal sehen wollen !>> Was hindert dich?>> Sollte 1:1 laufen, auch unter C++>> Tut es auch! Aber der Op ist ein Meister im Verkomplizieren der> einfachsten Dinge, wie er mit hunderten Beiträgen bewiesen hat!>
Ah, einer meiner Verehrer. Dann wirst du mir auch sicherlich bei meinem
lächerlichem Problem einfach helfen können !
Also, ab jetzt bitte nur konstruktive Kritik !
Wie wärs mit den fünf universellen Forumsregeln ?
Beitrag "Die fünf universellen Forenregeln ;-)"
1. Threadüberschrift lesen
2. Evtl. Datum beachten
3. Posting verstehen
4. Falls nicht 3., dann nachfragen oder Klappe halten.
5. Auf die Fragen eingehen und / oder Alternativen bzw. Verbesserungen
nennen.
Die Punkte kann man an einer Hand abzählen und deshalb evtl. gut merken,
wenn nicht dann nur Punkt 3 und Punkt 4 merken.
Und nun zum Code und meinem Problem welches im Screenshot zu sehen ist.
Bernd S. schrieb:> Und nun zum Code und meinem Problem welches im Screenshot zu sehen ist.
Welchen Arduino hast du in deiner IDE eingestellt? Der hat die beiden
Register nicht, die heißen anders.
Bernd S. schrieb:> Beitrag "Die fünf universellen Forenregeln ;-)"
Ich hätte noch eine wichtige Regel für dich: Hinweise beim
Posten von Beiträgen lesen und verinnerlichen.
----------------------------------------------
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
----------------------------------------------
Falls du es nicht kapierst: dein Sourcecode ist länger!
Bernd S. schrieb:> Ich weiß nicht - dies habe ich ja auch zu Anfang geschrieben, es sieht> halt immer anders aus wie die "normalen" C-Programme.
Die main() von Arduino hast du dir anscheinend gar nicht angeguckt und
überschreibst sie als erstes mit deinem Code.
Und den Hinweis/Kommentar in setup() hast du gelesen und deinen Punkt 3
dabei beherzigt?
Falk B. schrieb:> Welchen Arduino hast du in deiner IDE eingestellt? Der hat die beiden> Register nicht, die heißen anders.>
Dachte so etwas wird automatisch erkannt bzw. umbenannt.
Es heisst doch das C-Programme für einen µC, einfach auf andere µC
übertragbar sind. Wenn ich da jedesmal gucken bzw. überlegen muss, wie
das Register nun in diesem µC heisst oder heissen könnte, dann hab ich
ja viel zu tun.
Es ist ein ATmega 2560-Board.
Müsste dies nicht in der <avr/io.h> stehen ?
Und warum tauchen diese dann nicht im Verzeichnis -> include auf ?
(siehe Screenshot)
1
#include<Arduino.h>
2
#include<stdint.h>
3
#include<avr/io.h>
4
#include<avr/interrupt.h>
Wastl schrieb:> Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang>
Ok, ich guck mal, ob es so geht, wenn ich es per Copy & Paste erst in
den
Windows-Editor kopiere und dann hier mittels "Durchsuchen..." hochlade.
Rainer W. schrieb:> Bernd S. schrieb:>> Ich weiß nicht - dies habe ich ja auch zu Anfang geschrieben, es sieht>> halt immer anders aus wie die "normalen" C-Programme.>> Die main() von Arduino hast du dir anscheinend gar nicht angeguckt und> überschreibst sie als erstes mit deinem Code.>
Was willst du von mir - B A H N H O F ? ? ?
Bernd_Stein
Bernd S. schrieb:> Falk B. schrieb:>> Welchen Arduino hast du in deiner IDE eingestellt?
Diese halt nicht.
> Dachte so etwas wird automatisch erkannt bzw. umbenannt.
Nö. Diese Funktionen werden von der Arduino-IDE nicht abgedeckt, da muss
man praktisch das Gleiche tun wie im normalen C. Das läuft auch nur auf
den AVR-basierten Arduinos. Alles anderen (ESP32 etc.) brauchen anderen
Konstruktionen zur Nutzung der Timer.
> Es heisst doch das C-Programme für einen µC, einfach auf andere µC> übertragbar sind.
Das sind sie in Grenzen auch. Aber nicht die hardwarespezifischen
Module. Das ist so eins.
> Wenn ich da jedesmal gucken bzw. überlegen muss, wie> das Register nun in diesem µC heisst oder heissen könnte, dann hab ich> ja viel zu tun.
Solltest du dir nicht besser ein anderes Hobby suchen, wenn dich das
alles so belastet?
> Es ist ein ATmega 2560-Board.
Gut. Und da du die Arduino-IDE benutzt, kannst du Timer0 nicht direkt
nutzen, denn den nutz Arduino schon. Kann man aber mit nutzen, wenn man
weiß was man tut.
> Müsste dies nicht in der <avr/io.h> stehen ?
Jain. io.h ruft nur die hardwarespezifische inlcude-Datei auf.
> Und warum tauchen diese dann nicht im Verzeichnis -> include auf ?> (siehe Screenshot)#include <Arduino.h>
Keine Ahnung.
> #include <stdint.h>> #include <avr/io.h>> #include <avr/interrupt.h>>> Wastl schrieb:>> Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang>>> Ok, ich guck mal, ob es so geht, wenn ich es per Copy & Paste erst in> den> Windows-Editor kopiere und dann hier mittels "Durchsuchen..." hochlade.
Was soll der Scheiß? du kannst eine Datei mit dem Quelltext DIREKT an
Anhang senden! TU DAS!
> Was willst du von mir - B A H N H O F ? ? ?
Tja, dein altes Problem. Anstatt einfach mal die Standardlösung zu
nutzen, die MILLIONEN von Anwendern ohne Probleme nutzen, bastelst du
ohne Sinn und Verstand an deinen Sonderlösungen. Bravo! Genau der
richtige Weg, um maximalen Stress bei minimalem Ergebnis zu erreichen!
Bernd S. schrieb:> Was willst du von mir - B A H N H O F ? ? ?
Dein oben geposteten Code enthält eine eigene main(). Damit
überschreibst du die main() vom Arduino-Framework. Arduino besitzt eine
main(), die setup() und loop() aufruft. Mit der main() hast du bei
Arduino nichts zu tun, wenn du das Arduino Framework benutzt. Dein Code
liegt bei Arduino in setup() und loop().
Guck dir einfach mal die mit der Arduino IDE mitgelieferten
Codebeispiele an.
Bernd S. schrieb:> Dachte so etwas wird automatisch erkannt bzw. umbenannt.
Der Weg in die Hölle ist mit falschen Annahmen gepflastert.
Weiterhin sprichst du von Arduino C.
Warum tust du das?
AVR-gcc ist auf C++11 eingestellt
Die ESP sind bei C++17 angekommen.
Frage den Compiler, wenn du mir nicht glaubst, er wird es dir sagen.
Beobachte die Meldungen, beim kompilieren. Darin steht es geschrieben.
Natürlich kann man mit Arduino auch C und ASM Dateien übersetzen.
Aber die *.ino und *.cpp Dateien sind C++.
Bei den *.ino läuft nur ein Präprozessor drüber, dann wird kompiliert.
Ich rate dir, dich mit den Konzepten vertraut zu machen.
Du machst es dir selber schwer, wenn du dagegen arbeitest.
Natürlich kann man auch Timer0 verwenden um eine ISR anzuregen, z.B. in
dem man einen der PWM Kanäle dazu benutzt einen Interrupt auszulösen
Oder eben wie Arduino üblich millis() verwenden.
Bernd S. schrieb:> Falk B. schrieb:>> Welchen Arduino hast du in deiner IDE eingestellt? Der hat die beiden>> Register nicht, die heißen anders.>>> Dachte so etwas wird automatisch erkannt bzw. umbenannt.> Es heisst doch das C-Programme für einen µC, einfach auf andere µC> übertragbar sind. Wenn ich da jedesmal gucken bzw. überlegen muss, wie> das Register nun in diesem µC heisst oder heissen könnte, dann hab ich> ja viel zu tun.
Du verwendest eine „Klasse“, die nicht für Arduino geschrieben wurde und
gehst jetzt davon aus, dass die Arduino-IDE das selbstständig erkennt
und für dich anpasst? In welchem Universum soll denn das passieren?
Ja, du musst dich ein bisschen mit der Materie beschäftigen, einfach
Copy&Paste in solchen Sachen funktioniert halt nicht, das hat es noch
nie. Man, auch du, musst halt nicht nur etwas Gehirnschmalz da rein
stecken sondern auch etwas Fleißarbeit. Millionen von Programmierern
haben das schon hinbekommen und ich bin zuversichtlich, du schaffst das
auch noch ;)
Mi N. schrieb:> Schon etwas älter aber vielleicht hilft es.> Beitrag "Entprellung von Tastern">
Danke, aber ich denke ich habe selbst schon viel zu viele Links bzw.
Informationen zum Thema hier angeboten.
Will mich auf PeDa's Code konzentrieren und ihn evtl. Arduino-C tauglich
machen.
Falk B. schrieb:>> Es ist ein ATmega 2560-Board.>> Gut. Und da du die Arduino-IDE benutzt, kannst du Timer0 nicht direkt> nutzen, denn den nutz Arduino schon. Kann man aber mit nutzen, wenn man> weiß was man tut.>
Tu ich dass ?
Ich meine ich benutzte Platform IO ( PIO ), ist dies trotzdem die
Arduino-IDE ?
Nicht wieder aufregen, ich bin halt nur Hobbyprogrammierer und raffe
nicht alles vollständig.
>> Müsste dies nicht in der <avr/io.h> stehen ?>> Jain. io.h ruft nur die hardwarespezifische inlcude-Datei auf.>
Wie kann ich da mal reinschauen, kann dies evtl. dass Problem der
Fehlermeldung sein, dass diese gar nicht eingebunden wurde, da ich sie
in dem wahrscheinlich dafür vorgesehenen PIO-Ordner -> include nicht
finde ?
Falk B. schrieb:>> Wastl schrieb:>>> Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang>>>>> Ok, ich guck mal, ob es so geht, wenn ich es per Copy & Paste erst in>> den>> Windows-Editor kopiere und dann hier mittels "Durchsuchen..." hochlade.>> Was soll der Scheiß? du kannst eine Datei mit dem Quelltext DIREKT an> Anhang senden! TU DAS!>
Ach, komm Falk, dreh nicht wieder durch, es hat doch eigentlich gut
angefangen. Da steht doch deutlich " Datei " und im Link ist es ja nicht
als Datei vorhanden. Wie soll ich es sonst machen ? :
https://www.mikrocontroller.net/articles/Entprellung#Komfortroutine_(C_f%C3%BCr_AVR)>> Was willst du von mir - B A H N H O F ? ? ?>> Tja, dein altes Problem. Anstatt einfach mal die Standardlösung zu> nutzen, die MILLIONEN von Anwendern ohne Probleme nutzen, bastelst du> ohne Sinn und Verstand an deinen Sonderlösungen. Bravo! Genau der> richtige Weg, um maximalen Stress bei minimalem Ergebnis zu erreichen!>
Falk, lass es doch besser mir helfen zu wollen, jetzt mischt du dich
schon in Angelegenheiten von Anderen und mir ein, die evtl. besser
verstehen was ich meine.
Tut mir leid für meine klaren Worte an dich, aber besser ist es wohl für
uns beide, wenn du dich ab jetzt hier raushälst.
Bernd_Stein
PlatformIO unterstützt natürlich generische Boards, man sollte aber env
richtig einstellen. Ich habe schon einige meiner Projekte aus Microchip
Studio auf PlatformIO rübergezogen und erfolgreich kompiliert.
Hier ein Beispiel für einen generischen ATTiny84 und Programmierung
mittels AVR ISP MkII aus der platformio.ini:
Man sieht, das hier schon keine Rede mehr von Arduino ist, ich benutze
in diesem Projekt reines C.
Wirklich ärgerlich ist bei PlatformIO für mich, das es Netzwerklaufwerke
nicht unterstützt, das müssen sie dringend ändern. Für das Microchip
Studio hingegen ist das überhaupt kein Problem.
Bernd S. schrieb:> Will mich auf PeDa's Code konzentrieren und ihn evtl. Arduino-C tauglich> machen.
Zum dritten mal: Arduino ist üblicherweise C++
Zudem gibt es kein Arduino C, sondern nur das C, was der GCC mitbringt.
Auch gibt es kein Arduino C++, sondern nur das C++, was der GCC
mitbringt.
Bernd S. schrieb:> habe extra Arduino-C geschrieben, da es ja kein " sauberes C " ist bzw.> C++.
Arduino Code wird von ganz normalen C/C++ Compilern übersetzt. Wenn es
kein "sauberer" Code wäre, würden die Compiler ihn abweisen. Die
Mischung von C und C++ innerhalb eines Programmes mögen manche
Entwickler nicht gerne sehen, aber bei Mikrocontrollern ist das
unumgänglich, alleine schon wegen der ISR. Außerdem ist die Mischung im
C++ Standard schon immer vorgesehen gewesen und das wird mit Sicherheit
auch so bleiben.
> es sieht halt immer anders aus wie die "normalen" C-Programme.
Es ist ja auch kein C, sondern primär C++.
Bernd S. schrieb:> Deshalb finde ich es sehr verwunderlich, dass so etwas noch immer nicht> wirklich bei den Programmierern angekommen ist.
Wen steckst du da in eine Schublade? Die Methode von Peter ist durchaus
gängig. Es ist auch nicht seine Erfindung.
Rainer W. schrieb:> Bernd S. schrieb:>> Was willst du von mir - B A H N H O F ? ? ?>> Dein oben geposteten Code enthält eine eigene main(). Damit> überschreibst du die main() vom Arduino-Framework. Arduino besitzt eine> main(), die setup() und loop() aufruft. Mit der main() hast du bei> Arduino nichts zu tun, wenn du das Arduino Framework benutzt. Dein Code> liegt bei Arduino in setup() und loop().> Guck dir einfach mal die mit der Arduino IDE mitgelieferten> Codebeispiele an.>
Ok, habe in meinem schlauen Buch mal nachgesehen :
Framework = Programmiergerüst
Dort auf der Seite 168 steht auch etwas da zu.
Also, habe ich einfach die Zeile und die Klammern rausgenommen und das
zwischen diesen, in die
void loop() {
...
}
gepackt, obwohl ich nach dem umbennen von TCCR0 in TCCR0*B* und TIMSK in
TIMSK*0*, die ganze Sache dann kompilieren konnte.
( siehe hier den Dateianhang ...txt. )
Beitrag "Tasterverarbeitung mit ARDUINO-C : ATmega 2560"
Dies rausgenommen :
int main( void )
{
...
}
Bernd_Stein
Arduino F. schrieb:> Zum dritten mal: Arduino ist üblicherweise C++> Zudem gibt es kein Arduino C, sondern nur das C, was der GCC mitbringt.> Auch gibt es kein Arduino C++, sondern nur das C++, was der GCC> mitbringt.
Man kann nicht mit Arduino alle möglichen talent- und kompetenzlosen
Spaten anziehen und sich dann beschweren wenn die einfachste Dinge nicht
kapieren.
Bernd S. schrieb:> Dachte so etwas wird automatisch erkannt bzw. umbenannt.
Nicht denken, Doku lesen. Wobei *.h Dateien Bestandteil der Doku sind.
Die Namen der ISR Handler entnehme ich in der Regel
https://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html
Die gesamte Webseite ist sehr lesenswert, wenn du AVR programmierst. Das
Arduino Markting lenkt gerne davon ab, um so zu tun, als hätte Arduino
eine eigene Sprache erfunden.
> Es heisst doch das C-Programme für einen µC, einfach auf andere µC> übertragbar sind.
Nö, wer sagt das denn? Jeder Mikrocontroller hat andere Hardware. Sobald
man diese anspricht, muss man hardware spezifisch programmieren. Der
Compiler abstrahiert nur RAM und CPU. Ein Mikrocontroller besteht aus
mehr als das.
> Wenn ich da jedesmal gucken bzw. überlegen muss, wie> das Register nun in diesem µC heisst oder heissen könnte,> dann hab ich ja viel zu tun.
Ach was! So ist das eben. Wenn du das nicht willst, musst du auf Systeme
mit Betriebssystem setzen (wie die zahlreichen Linux Boards), wo die
gesamte Hardware durch Treiber mit einheitlicher API abstrahiert wird.
Doch auch da wirst du dich früher oder später mit Hardwaredetails
auseinander setzen müssen, insbesondere wenn du mehr nutzen willst, als
die Standard Schnittstellen eines Linux PC (Speichermedien, Netzwerk,
Tastatur, Maus, ...).
>> Die main() von Arduino hast du dir anscheinend gar nicht angeguckt und>> überschreibst sie als erstes mit deinem Code.> Was willst du von mir - B A H N H O F ? ? ?
Er wollte dich darauf hinweisen, dass in einem Arduino Sketch keine
main() Funktion existieren sollte, weil diese vom Arduino Framework
bereit gestellt wird. Wenn du sie durch eine eigene Funktion ersetzt,
funktionieren weite Teile von Arduino nicht mehr. (Doku lesen)
@Arduino F.
@M.K.
@Matthias S.
@Steve van de Grens
Ihr überfordert mich mit eurem detailiertem Fachwissen.
Konzentriert euch bitte auf mein(e) geschriebenes Problem.
Konnte mein anfängliches Problem dank Falk's Hilfe ja lösen
( Registernamen anpassen ). Trotzdem möchte ich in diesem Thread auf
seine weitere Hilfe verzichten.
Ihr wisst gar nicht wie kompliziert die ganze Sache für mich ist.
Habe also den Code auf das Board geflasht und durch Nutzung von
Gehirnschmalz bermerkt, dass dieses Board ( China Klon, benutzt einen
12MHz Quarz ), PORT A und B gar nicht rausführt und mit Hilfe des Links
:
https://images.theengineeringprojects.com/image/webp/2021/01/introduction-to-arduino-mega-2560-rev3.png.webp?ssl=1
bin ich auf PORT E UND K umgestiegen.
Jetzt wundere ich mich, dass Key0 ( E0 ) die Tx-LED aufleuchten läßt und
Key1 ( E1 ) die Rx-LED.
Die sind doch eigentlich am ATmega 16u2 ( PD 5 & 4 ) angeschlossen ?
Bernd_Stein
Bernd S. schrieb:> ( China Klon, benutzt einen 12MHz Quarz ),
Dann: Für den CH340, nicht für den ATMega
Bernd S. schrieb:> Die sind doch eigentlich am ATmega 16u2 ( PD 5 & 4 ) angeschlossen ?
Dein Mega hat keinen 16U2 , sondern einen CH340
Bernd S. schrieb:> Ihr überfordert mich mit eurem detailiertem Fachwissen.
Du möchtest lieber im Irrtum verharren.
Bernd S. schrieb:> Konzentriert euch bitte auf mein(e) geschriebenes Problem.
Du möchtest lieber im Irrtum verharren.
Bernd S. schrieb:> Jetzt wundere ich mich, dass Key0 ( E0 ) die Tx-LED aufleuchten läßt und> Key1 ( E1 ) die Rx-LED.
Die beiden Pins werden für Serial genutzt.
Eine Doppelnutzung zeigt u.A. auch solche Effekte.
Also: Lass das!
Bernd S. schrieb:> Cyblord -. schrieb:>> Bernd S. schrieb:>>> Ach, digitalWrite() ist also normales C++ ?>>>> Natürlich. Es ist eine ganz normale C++ Funktion.>>> Und warum muss man dann noch eine andere Version haben, ist es nicht> grundsätzlich besser, wenn I/O-Ports " schnell " sind ?
Ich glaube du verwechselt die Sprachdefinition mit der Funktionalität
eines Programmes.
Das eine hat mit dem anderen wirklich wenig zu tun.
Die Funktionen die du da verwendest gehören zum Arduino Framework.
Wenn du den Unterschied zwischen beiden Funktionen wissen willst, schaue
in die Doku oder in den Quellcode.
Beide Funktionen sind jedenfalls in normalem C++ implementiert.
Cyblord -. schrieb:> Beide Funktionen sind jedenfalls in normalem C++ implementiert.
digitaWrite(), das originale, ist in C geschrieben, findet sich also
auch in einer C Datei.
https://github.com/arduino/ArduinoCore-avr/blob/master/cores/arduino/wiring_digital.c
Spielt aber alles überhaupt keine Rolex.
digitalRead() gehört zum Framework und nicht zum Kompiler.
Bernd S. schrieb:> Und warum muss man dann noch eine andere Version haben, ist es nicht> grundsätzlich besser, wenn I/O-Ports " schnell " sind ?
digitalWrite() schaltet zusätzlich PWM auf dem Pin ab. Und schlüsselt
von Arduino Pin zu Port-Bit um.
Es ist eben so, wie es ist!
Es gibt Vor- und Nachteile.
Verbesserungsvorschläge bitte ans Arduino Team, das ist hier die falsche
Adresse.
Bernd S. schrieb:> Genau diesen 50ms-Quatsch habe ich in meinem Eröffnungsthread gemeint !
Die Entprellzeit muss abgewartet werden!
Denn ohne, ist ein Störimpuls nicht von einem Tastendruck zu
unterscheiden.
Die 50ms Verzögerung kannst du nicht wahrnehmen.
Das wäre "unmenschlich".
Bernd S. schrieb:> Und warum muss man dann noch eine andere Version haben, ist es nicht> grundsätzlich besser, wenn I/O-Ports " schnell " sind ?
Weil diese Funktionen bequem und Deppensicher sein sollen. Sie beenden
z.B. ein vorher gestartetes PWM Signal auf den Pins.
Wer es schnell haben will, kann ja ganz herkömmlich auf die PORTx
Register zugreifen.
Cyblord -. schrieb:> Die Funktionen die du da verwendest gehören zum Arduino Framework.
Genau genommen wurden sie vom Vorgänger "Processing" abgekupfert. Die
Ähnlichkeit zu Processing war den Arduino Entwicklern damals wichtig.
Steve van de Grens schrieb:> Nicht denken, Doku lesen. Wobei *.h Dateien Bestandteil der Doku sind.> Die Namen der ISR Handler entnehme ich in der Regel> https://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html
Leider, leider, leider sind auf der Seite "nur" die Interruptvektoren
der "normalen" und klassischen AVR-Controller gelistet.
Ärgerlich, dass auf dieser Seite die Vektoren für AVR-Series-0, -1 und
-2 nicht mitgelistet sind.
Cyblord -. schrieb:>> Und warum muss man dann noch eine andere Version haben, ist es nicht>> grundsätzlich besser, wenn I/O-Ports " schnell " sind ?>> Ich glaube du verwechselt die Sprachdefinition mit der Funktionalität> eines Programmes.> Das eine hat mit dem anderen wirklich wenig zu tun.>> Die Funktionen die du da verwendest gehören zum Arduino Framework.>> Wenn du den Unterschied zwischen beiden Funktionen wissen willst, schaue> in die Doku oder in den Quellcode.>> Beide Funktionen sind jedenfalls in normalem C++ implementiert.>
Ok, irgendwie aufgebläht ohne Ende, aber wenn so gewünscht ist ...
Da fiehl mir doch gerade ein : " Ich weiß ja gar nicht mit welcher
Frequenz jetzt das ATmega-2560-Board läuft ? ".
Mal sehen, ob ich hiermit was anfangen kann und meine alte Routine dazu
in das Arduino-Framwork einzubinden :
https://forum.arduino.cc/t/ist-assembler-in-der-ide-moglich/322581/31
1
;
2
; Internen CPU-Takt ermitteln
3
;
4
; ATtiny 13 im Auslieferungszustand.
5
; mit internen kalibrietem RC-Oszillator von 9,6MHz
Bernd S. schrieb:> Da fiehl mir doch gerade ein : " Ich weiß ja gar nicht mit welcher> Frequenz jetzt das ATmega-2560-Board läuft ? ".
Doch das weißt du! (Kompilermeldungen beobachten, boards.txt lesen)
16MHz, wie alle Arduino Mega Boards und ihre Klone.
Deine 12MHz sind nur eine Nebelkerze um dich selber zu verwirren.
Du verwirrst dich offensichtlich gerne, warum auch immer.
Arduino F. schrieb:> Doch das weißt du! (Kompilermeldungen beobachten, boards.txt lesen)> 16MHz, wie alle Arduino Mega Boards und ihre Klone>
Ah, hab das Krümmelchen gefunden. Der zugehörige Widerstand heißt zwar
nicht R1, wie im Schaltplan, aber ...
Bernd_Stein
Ralph S. schrieb:> Ärgerlich, dass auf dieser Seite die Vektoren für AVR-Series-0, -1 und> -2 nicht mitgelistet sind.
Weil die verlinkte Bibliothek diese neuen Serien nicht unterstützt. Wer
das braucht, muss sich eine passende Bibliothek herunter laden und dann
in deren Doku oder wie gesagt in die *.h Dateien schauen.
Bernd S. schrieb:> Der zugehörige Widerstand heißt zwar nicht R1
Da steht R14
Bernd S. schrieb:> Hatte ich zwar schon verlinkt,
Nein, das ist der originale mit 16U2!
Du hast ein Board mit CH340.
Eben ein kein originalgetreuer Nachbau.
Stefan F. schrieb:> Bernd S. schrieb:>> Der zugehörige Widerstand heißt zwar nicht R1>> Da steht R14>
Bitte ordentlich zitieren :
> Bernd S. schrieb:> Ah, hab das Krümmelchen gefunden. Der zugehörige Widerstand heißt zwar> nicht R1, wie im Schaltplan, aber ...>
Bernd_Stein
Arduino F. schrieb:> Du hast ein Board mit CH340.> Eben ein kein originalgetreuer Nachbau.
Das ist für das eigentliche Problem, nämlich die Tastenentprellung,
vollkommen egal. Der UART mit der USB-Verbindung ist so oder so
transparent, egal was für ein IC das macht.
Falk B. schrieb:> egal was für ein IC das macht.
Eins der Probleme/Verwunderlichkeiten war, dass die Tx und Rx LEDs mit
zappeln.
Das tun sie nur beim CH340, nicht beim 16U2
Moin,
Falls von Interesse, die Tasten Routinen von Peter funktionierten bei
mir auf allen möglichen uC, einschließlich Arduino AVRs. Von STM32,
DSPIC, MSP430, PIC, AVR, Z8 und 8051 und man muß nur die HW und Timer
ISR Zugänge entsprechend anpassen. Das Design von Peter ist "Rock Solid"
und hat sich hier bei immer bestens bewährt.
Gerhard
Bernd S. schrieb:> Ihr überfordert mich mit eurem detailiertem Fachwissen.> Konzentriert euch bitte auf mein(e) geschriebenes Problem.
Dein Problem, dass du beschreibst, ist, dass du eklatante Lücken in den
Grundlagen von C/C++ hast und darauf konzentrieren wir uns auch. Meinst
du nicht, dass es nicht sinnvoll wäre, das Fundament zu festigen? Ich
meine, darauf baut später alles auf und nur weil du jetzt eine
Musterlösung hast muss das nicht heißen, dass du jetzt was gelernt hast
und nicht mit der nächste Klasse, die du nutzen willst, nicht wieder auf
die genau selben Probleme stoßen wirst. Ich kann dir nur raten dich noch
mal ausgiebig mit den Grundlagen zu beschäftigen. Dass dir schon zu
beginn nicht klar war, dass Framework ein Programmiergerüst ist...uff.
Bernd S. schrieb:> Ach, digitalWrite() ist also normales C++ ?
Fast, das ist eine astreine-C-Methode die aber auch in C++ genutzt
werden kann. Wüsstest du, wenn du dir mal die Definition von
digitaWrite() ansehen würdest. Wie das geht fragst du? Ganz einfach: Im
Code in der Arduino-IDE rechtsklick auf die Funktion und Gehe zu
Definition anklicken. Das bringt dich direkt zur wiring_digital.c und
springt direkt zur Methode/Funktion. Deklariert wird die Funktion in der
Arduino.h, eine C-Header. Ich hoffe grade inständig, dass du wenigstens
weißt, was eine Deklaration ist und was eine Definition, ich fürchte
aber ehrlich gesagt, dass auch das bei dir eher im Nebel liegt. Aber das
sind dann halt wieder Grundlagen von C/C++. Vielleicht aber irre ich
mich und du kennst den Unterschied und vielleicht weißt du auch, warum
diese C-Funktion auch in C++ genutzt werden kann. Ich sags mal so,
normal ist das eigentlich nicht, dass man C-Funktionen in C++-Programmen
nutzen kann.
M. K. schrieb:> Bernd S. schrieb:>> Ihr überfordert mich mit eurem detailiertem Fachwissen.>> Konzentriert euch bitte auf mein(e) geschriebenes Problem.>> Dein Problem, dass du beschreibst, ist, dass du eklatante Lücken in den> Grundlagen von C/C++ hast
Nicht nur dort. Wer 10 Jahre über AVR Assembler philosophiert und am
Ende immer noch nicht auf einem grünen Zweig angekommen ist, macht was
falsch.
Naja, auch ein Hobby . . .
> und darauf konzentrieren wir uns auch. Meinst> du nicht, dass es nicht sinnvoll wäre, das Fundament zu festigen?
Mit nichten! Dann wäre das g anze Aufregen, Reden und "Maken" am Ende.
Man würde TATSÄCHLICH mal ein Projekt einfach so fertig stellen, ohne
viel Aufsehen. NEIN!
>> Ach, digitalWrite() ist also normales C++ ?>> Fast, das ist eine astreine-C-Methode
Nö. Eine einfache Funktion. Methoden gibt es in C gar nicht und die
haben, soweit mit bekannt, immer was mit Klassen zu tun. digitalWrite()
gehört nicht zu einer Klasse, das ist eine alleinstehende Funktion.
> Arduino.h, eine C-Header. Ich hoffe grade inständig, dass du wenigstens> weißt, was eine Deklaration ist und was eine Definition, ich fürchte> aber ehrlich gesagt, dass auch das bei dir eher im Nebel liegt.
Perlen vor die Säue.
Der gute Bernd ist ein Frickler und wird es immer bleiben. Sowas wie ein
digitaler Sisyphos ;-)
https://de.wikipedia.org/wiki/Sisyphos
Oder das Software-Gegenstück zum Alten Knacker. Der kann nicht löten,
wird es auch nie mehr lernen. Beim Bernd ist es die Software, egal ob
ASM oder C oder wasweißich.
Falk B. schrieb:> Nö. Eine einfache Funktion. Methoden gibt es in C gar nicht
Stimmt, ich benutze für C die Bezeichnung Funktion - Methode
gleichermaßen, wohlweislich, dass eine Funktion etwas anderes als eine
Methode ist.
Moin,
Ich kann nicht ganz nachvollzuziehen, warum Manche diese "Arduino Hang
Ups" haben. Was mich betrifft, verwende ich die Arduino Infrastruktur
sehr gerne.
Für die meisten Projekte stört mich etwas "Arduino" Startup Code nicht.
Bin ganz froh, daß die gepufferten Seriell Routinen schon
"gebrauchsfertig" sind und T1 Unterstützung auch. Alles weitere HW
Zugriffe programmiere ich "nicht-Arduino gerecht" mit direkten SFR
Zugriffen wie in in nicht Arduino uC Projekten auch und komme damit ganz
gut zurecht. Man hat ja schließlich einen "full blown" GCC Compiler zur
Verfügung. Manche Arduino Funktionen sind ja ohnehin recht nützlich und
ersparen einen viel Zeit.
Man sollte dankbar sein, dass es für viele interessante Special Funcrion
ICs schon fix und fertige Bibliotheken gibt und man solche Ressourcen
ohne grosses "Hoopla" sofort erproben kann.
Es ist nicht meine Absicht zu "missionieren", aber meiner Meinung nach
ist man ein Narr, wenn man die Bequemlichkeiten von Arduino
Infrastruktur nicht ausnützen will, nur weil man sich zu gut dafür hält.
Im semi-professionellen- und Hobbybereich, lässt sich durchaus Vieles
Nützliches anstellen. Man muß halt wissen was man tut, um die Vor- und
Nachteile einschätzen zu können.
Ich finde, wir sollten endlich mal unsere Vorurteile aus dem Bahnfenster
werfen. Oh, das ist verbottten und darf man ja nicht:-)
Gruß,
Gerhard
Gerhard O. schrieb:> Ich kann nicht ganz nachvollzuziehen, warum manche diese "Arduino Hang> Ups" haben. Was mich betrifft, verwende ich die Arduino Infrastruktur> sehr gerne.
Ist bei mir ähnlich. Ich nutze die Arduino Infrastruktur für meine
Projekte gar nicht, finde sie aber auch echt nicht schlecht. Dass da der
ein und andere immer wieder mal drauf rumhackt kann ich auch nicht
nachvollziehen. Ja, auch die Arduino-Infrastruktur hat ihre Schwächen
aber auch ihre Stärken. Der Erfolg gibt dem System recht auf dem
richtigen Weg zu sein. Mir gefällt das auf jeden Fall und ich schau mir
immer wieder gerne Projekte aus der Arduino-Welt auch an.
M. K. schrieb:> Mir gefällt das auf jeden Fall und ich schau mir> immer wieder gerne Projekte aus der Arduino-Welt auch an.>
Und ich würde gerne beide Welten bestmöglich verheiraten.
Ich liebe diesen Threadbeitrag von Hannes Luxx zur Tasterentprellung
einfach :
Beitrag "Re: Wie lange prellt ein Taster in der Regel?"
Bernd_Stein
M. K. schrieb:> Gerhard O. schrieb:>> Ich kann nicht ganz nachvollzuziehen, warum manche diese "Arduino Hang>> Ups" haben. Was mich betrifft, verwende ich die Arduino Infrastruktur>> sehr gerne.>> Ist bei mir ähnlich. Ich nutze die Arduino Infrastruktur für meine> Projekte gar nicht, finde sie aber auch echt nicht schlecht. Dass da der> ein und andere immer wieder mal drauf rumhackt kann ich auch nicht> nachvollziehen. Ja, auch die Arduino-Infrastruktur hat ihre Schwächen> aber auch ihre Stärken. Der Erfolg gibt dem System recht auf dem> richtigen Weg zu sein. Mir gefällt das auf jeden Fall und ich schau mir> immer wieder gerne Projekte aus der Arduino-Welt auch an.
Wenn Einem eine Bibliothek nicht so richtig gefällt, kann man ja einen
Fork machen und es eigenen Wünschen anpassen.
Ja. Hier sind Links zu einigen Arduino Forums Beispielen aus meiner
Projektgeschichte:
Beitrag "Re: Zeigt her eure Kunstwerke (2015)"Beitrag "Re: Zeigt her eure Kunstwerke (2015)"Beitrag "Re: Zeigt her eure Kunstwerke (2017)"Beitrag "Re: Zeigt her eure Kunstwerke (2020)"Beitrag "Re: Zeigt her eure Kunstwerke (2020)"Beitrag "Re: Zeigt her eure Kunstwerke (2020-2022)"Beitrag "Re: Zeigt her eure Kunstwerke (2020-2022)"
Ich arbeite mit den "Kleinen" ganz gerne, wie man daraus ersieht. Alles
wurde im IDE programmiert. Besonders gerne "integriere" ich Nanos oder
Pro-Minis in selbstgefertigten LP. Mir machen diese niedlichen Gesellen
viel Spass. Für Steueranwendungen tun es auch 8-Bitter noch ganz gut.
Gerhard O. schrieb:> Ja. Hier sind Links zu einigen Arduino Forums Beispielen aus meiner> Projektgeschichte:>
Danke, wirklich schön anzusehen und zu sehen, was alles mit diesem
Arduino-Zeugs machbar ist.
Wie bist du zum programmieren gekommen, beruflich oder als Hobby ?
Bernd_Stein
Bernd S. schrieb:> Gerhard O. schrieb:>> Ja. Hier sind Links zu einigen Arduino Forums Beispielen aus meiner>> Projektgeschichte:>>> Danke, wirklich schön anzusehen und zu sehen, was alles mit diesem> Arduino-Zeugs machbar ist.>> Wie bist du zum programmieren gekommen, beruflich oder als Hobby ?>> Bernd_Stein
Hallo Bernd,
Danke fürs Interesse:-)
Was das Projekt "Embedding" betrifft, muß man meistens durch angebrachte
Expansion den IO vergrößern. Dazu kommt, daß ich mir die wichtigen
Alternativ Funktions Pins freihalten will. So hat so ziemlich alles
meiner Projekte entsprechende zusätzliche IO ICs.
Beruflich, hauptsächlich. Vorher übte ich an 6802 und HC11 in ASM.
Später mit PICs.
Gerhard
M. K. schrieb:> Gerhard O. schrieb:>> Ich kann nicht ganz nachvollzuziehen, warum manche diese "Arduino Hang>> Ups" haben. Was mich betrifft, verwende ich die Arduino Infrastruktur>> sehr gerne.>> Ist bei mir ähnlich. Ich nutze die Arduino Infrastruktur für meine> Projekte gar nicht, finde sie aber auch echt nicht schlecht.
Fuer mich ist es ein wenig zu sehr abstrahiert, aber wenn man sich die
Zielgruppe anguckt (Bastler, Kuenstler) hat Massimo Banzi 2005 einen
genialen Job gemacht: Es ist sehr einfach den uC zu programmieren, es
gibt einfache billige Boards.
Gruesse
Th.
Thomas W. schrieb:> M. K. schrieb:>> Gerhard O. schrieb:>>> Ich kann nicht ganz nachvollzuziehen, warum manche diese "Arduino Hang>>> Ups" haben. Was mich betrifft, verwende ich die Arduino Infrastruktur>>> sehr gerne.>>>> Ist bei mir ähnlich. Ich nutze die Arduino Infrastruktur für meine>> Projekte gar nicht, finde sie aber auch echt nicht schlecht.>> Fuer mich ist es ein wenig zu sehr abstrahiert, aber wenn man sich die> Zielgruppe anguckt (Bastler, Kuenstler) hat Massimo Banzi 2005 einen> genialen Job gemacht: Es ist sehr einfach den uC zu programmieren, es> gibt einfache billige Boards.>> Gruesse>> Th.
Über den Grad der Abstrahierung hat man ja freie Wahl. Als CPP Projekt
ohne INO hat man ja alle GCC Ressourcen zur Verfügung. Aber dann kann
man gleich andere Werkzeuge wählen und nur die Bords nutzen.
Für die meisten Projekte fühle ich keine nennenswerten Beschränkungen
von der Infrastruktur her. Auch wenn professionelle Entwickler die IDE
hassen; ich finde sie komfortabel genug. In der Arbeit verwende ich
meist CUBE IDE Eclipse und ja, es hat Vieles Nützliche. Aber die
einfacheren AVR Projekte lassen sich mit dem Arduino IDE immer noch
bequem genug bearbeiten. Ich könnte ja auch mit CodevisionAVR arbeiten
oder Notepad++ und GCC. Das Schöne an der Arduino Portable Installation
aber ist, dass es auf allen Rechnern ohne zu Mucken funktioniert. Ich
weiß das genauso wie die Schüler und Studenten zu schätzen, weil ich
damit sofort produktiv sein kann. Kabel einstecken, Arduino IDE starten
- loslegen. Alle meine gezeigten Projekte waren damit entwicklungsmässig
machbar. Den GDB Debugger vermisse ich allerdings hier und da ein
bisschen...
Gerhard O. schrieb:> Den GDB Debugger vermisse ich allerdings hier und da ein bisschen...
Oh ja. Ich hatte am 16-OCT-2015 auf der MakerFaire in Rom einen Genino
ZERO gekauft (das Ding mit dem Atmel Embedded Debugger [EDBG]). Der Zero
war gerade veroeffentlicht wurden, genau zusammen mit dem Streit ueber
die Namensrechte :-(
Das Debugging war noch sehr unangenehm, aber jetzt mit der aktuellen IDE
2.0 geht das wirklich gut (Breakpoint setzen, Step in/out).
Gruesse
Th.
Thomas W. schrieb:> Gerhard O. schrieb:>> Den GDB Debugger vermisse ich allerdings hier und da ein bisschen...>> Oh ja. Ich hatte am 16-OCT-2015 auf der MakerFaire in Rom einen Genino> ZERO gekauft (das Ding mit dem Atmel Embedded Debugger [EDBG]). Der Zero> war gerade veroeffentlicht wurden, genau zusammen mit dem Streit ueber> die Namensrechte :-(>> Das Debugging war noch sehr unangenehm, aber jetzt mit der aktuellen IDE> 2.0 geht das wirklich gut (Breakpoint setzen, Step in/out).>> Gruesse>> Th.
Unter Eclipse IDEs funktionierte das Debuggen immmer recht komfortabel
und half mir aus zwickrigen Situationen. Das funktionierte vor 14 Jahren
auch noch gut unter Coocox und später mit Atollic.
Den Genino kenne ich momentan nicht. Ich baute mir damals einige
STM32FMini Bords für F103/407 und verwendete JLINK V2. Aber für die
kleineren Steuerungs Projekte ziehe ich aktuell wieder die 8-Bitter vor.
Für Fernsteuerung hat man ja noch die ESP WLAN Bords Module die man
zusammenschalten kann. Mir ist 5V lieber als 3.3V.
Bernd S. schrieb:> Und nun zum Code und meinem Problem welches im Screenshot zu sehen ist.
Da mußt Du Dich bei Atmel beschweren, daß die unfähig waren, eine
einheitliche Namenskonvention über die verschiedenen Derivate zu
schaffen.
In Assembler solltest Du das Namenswirrwarr von Atmel ja schon kennen
gelernt haben. Daher wundert es mich doch, daß Dir das in C plötzlich
Probleme bereitet.
Auch sind die Fehlermeldungen in Klartext, d.h. zeigen genau auf, was
der Fehler ist. Oder ist Dein eigentliches Problem etwa, daß Du kein
Englisch kannst?
Gerhard O. schrieb:> Beruflich, hauptsächlich. Vorher übte ich an 6802 und HC11 in ASM.> Später mit PICs.>
6802 ?
ist das nicht der Commodore C64 Chip ?
Damit fing meine unglückliche ASM-Liebe an ;-)
Ah - MC68HC11 - wie schön " einfach " der noch war.
ASM noch schöner, das bzw. nur "AVR8ASM", übe ich immer noch hin und
wieder ;-)
Bist wahrscheinlich Berufsschullehrer oder ähnliches nicht wahr ?
Thomas W. schrieb:> Fuer mich ist es ein wenig zu sehr abstrahiert, aber wenn man sich die> Zielgruppe anguckt (Bastler, Kuenstler) hat Massimo Banzi 2005 einen> genialen Job gemacht: Es ist sehr einfach den uC zu programmieren, es> gibt einfache billige Boards.>
Sehe ich überwiegend auch so, mit dem programmieren tu ich mich leider
noch ein wenig schwer, dass einfache, einfach so hinzunehmen ;-)
Gerhard O. schrieb:> Den GDB Debugger vermisse ich allerdings hier und da ein> bisschen...>
Vielleicht ist dies eine Alternative zum AVR-Arduino-Debugging.
https://www.youtube.com/watch?v=7wx27FcluMgPeter D. schrieb:> Oder ist Dein eigentliches Problem etwa, daß Du kein> Englisch kannst>
Dies sicherlich auch.
Finde es immer wieder schade, dass nicht die für mich "präzisere"
Sprache öffters genutzt wird, dann würde ich sicherlich so tolle
Berichte, wenn sie denn von Leuten in meiner Muttersprache verfasste
wurden, viel besser verstehen.
Der Verfasser in diesen Threadbeitrag verlinktem Bericht, ist leider
nicht meiner Muttersprache mächtig, aber Google-Translate gibt sein
bestes ;-)
Beitrag "Einzelnen Taster entprellen ASM : Niemals ein IRQ-Pin nehmen"
Bernd_Stein
Gerhard O. schrieb:> Ich kann nicht ganz nachvollzuziehen, warum Manche diese "Arduino Hang> Ups" haben.M. K. schrieb:> Ist bei mir ähnlich. Ich nutze die Arduino Infrastruktur für meine> Projekte gar nicht, finde sie aber auch echt nicht schlecht.
Der Einzige, der sich hier einmal kurz negativ kritisch geäußert hat,
ist der TO. Für mich hat seine Meinung kein Gewicht.
In den vergangenen Monaten haben sich hier mehr Leute darüber beschwert,
dass andere sich über Arduino beschweren, als die Anzahl der Leute, die
sich tatsächlich über Arduino beschweren. Was habt ihr für ein Problem?
Steve van de Grens schrieb:> Was habt ihr für ein Problem?
Wahrscheinlich, dass wir zu viel im Forum lesen und du ganz
offensichtlich weniger als wir ;)
Bernd S. schrieb:> Finde es immer wieder schade, dass nicht die für mich "präzisere"> Sprache öffters genutzt wird
Was ist die "für dich präzisere Sprache"? Sächsisch bestimmt nicht. Es
gibt mittlerweilen sehr gute Online-Übersetzer. Da lese ich sogar ein
Chinesisches Datenblatt!
Bernd S. schrieb:> 6802 ?> ist das nicht der Commodore C64 Chip ?
Nö. Soweit mir bekannt ist, wurde mit dem 6802 kein Homecomputer gebaut,
er war aber ein Arbeitspferd der Industrie. Aus dem 6800er wurde von
Motorola dann der 6809 und später der 16/32 Bitter 68000er entwickelt.
Der 6802 hatte zwei Akkus, A und B, und hat in ASM eigentlich recht viel
Spaß gemacht.
Im C64 war eine von MOS modifizierte Variante des 6502 verbaut, wimre
hiess der 6510.
Helmut -. schrieb:> Bernd S. schrieb:>> Finde es immer wieder schade, dass nicht die für mich "präzisere">> Sprache öffters genutzt wird>> Was ist die "für dich präzisere Sprache"? Sächsisch bestimmt nicht. Es> gibt mittlerweilen sehr gute Online-Übersetzer. Da lese ich sogar ein> Chinesisches Datenblatt!>
Vielleich hätte ich schreiben sollen, der detailierteren Beschreibung
der Ding oder sowas in der Richtung.
https://www.helpster.de/land-der-dichter-und-denker-begriffserklaerung_215159
Bernd_Stein
Matthias S. schrieb:> Nö. Soweit mir bekannt ist, wurde mit dem 6802 kein Homecomputer gebaut,> er war aber ein Arbeitspferd der Industrie. Aus dem 6800er wurde von> Motorola dann der 6809 und später der 16/32 Bitter 68000er entwickelt.> Der 6802 hatte zwei Akkus, A und B, und hat in ASM eigentlich recht viel> Spaß gemacht.
Der 6802 war ein Prozessor auf Basis des 6800. Das Programmiermodell war
identisch, aber es waren bereits 128 Bytes RAM enthalten, davon sogar 32
mit einer eigenen Stromversorgungsleitung pufferbar.
Ein Microcontroller war das trotzdem nicht, denn es fehlten sowohl
Peripherie als auch Programmspeicher. Das gab es beim 6801, der mit 2 kB
maskenprogrammiertem(!) ROM und je nach Betriebsart mehreren I/O-Ports
daherkam. Zu Entwicklungszwecken gab es eine (teure) EPROM-Version mit
UV-löschbarem EPROM, das war der 68701.
Der 6809 war source-, aber nicht binärkompatibel, und hatte etliche
Erweiterungen gegenüber dem älteren Programmiermodell des 6800, die
beiden 8-Bit-Akkus A und B konnten zu einem 16-Bit-Akku D
zusammengefasst werden. Es gab einen zusätzlichen Stackpointer U und ein
zusätzliches Indexregister Y (beide 16 Bit breit), und ein Register, um
den Basisoffset der "direct page" einzustellen, die bei den anderen
Familienmitglieder fest auf 0 lag (dort "zero page" genannt). Auch
konnten PC-relative Adressierungen mit 16-Bit-Offset erfolgen, womit
erstmalig vollständig relokatibler Code möglich wurde. Zudem war der
6809 der erste Prozessor, der eine Multiplikation kannte (A * B -> D).
Durch die leistungsfähigen Adressierungsarten machte die
Assemblerprogrammierung auf diesem Prozessor richtig Spaß.
Steve van de Grens schrieb:> Bernd S. schrieb:>> Ich weiß ja gar nicht mit welcher Frequenz jetzt das ATmega-2560-Board läuft ?>> Wie gesagt: Doku lesen.
Papier ist geduldig. Die IDE zeigt nur den im Konfigurationsfile
eingetragenen Wert an. Wenn die HW damit nicht übereinstimmt, ist der
Wert in der IDE einfach nur falsch.
Rainer W. schrieb:> Wenn die HW damit nicht übereinstimmt, ist der> Wert in der IDE einfach nur falsch.
Das Blink Beispiel und eine Stoppuhr zeigen fix, wie und ob das falsch
ist.
Aber wer da nicht selber drauf kommt....
Tipp:
ALLE Arduino Mega Nachbauten, werden wie die originalen, mit 16MHz
ausgeliefert.
Arduino F. schrieb:> Rainer W. schrieb:>> Wenn die HW damit nicht übereinstimmt, ist der>> Wert in der IDE einfach nur falsch.>> Das Blink Beispiel und eine Stoppuhr zeigen fix, wie und ob das falsch> ist.> Aber wer da nicht selber drauf kommt....>> Tipp:> ALLE Arduino Mega Nachbauten, werden wie die originalen, mit 16MHz> ausgeliefert.
Moin,
"boards.txt" definiert Bord und Projekt bezogene Einstellungen.
https://www.arduino.cc/en/uploads/Main/boards.txt
Hier folgt ein Auszug für den 2560 Mega Eintrag:
...
mega2560.name=Arduino Mega 2560
mega2560.upload.protocol=stk500v2
mega2560.upload.maximum_size=258048
mega2560.upload.speed=115200
mega2560.bootloader.low_fuses=0xFF
mega2560.bootloader.high_fuses=0xD8
mega2560.bootloader.extended_fuses=0xFD
mega2560.bootloader.path=stk500v2
mega2560.bootloader.file=stk500boot_v2_mega2560.hex
mega2560.bootloader.unlock_bits=0x3F
mega2560.bootloader.lock_bits=0x0F
mega2560.build.mcu=atmega2560
mega2560.build.f_cpu=16000000L
mega2560.build.core=arduino
...
Infos:
https://support.arduino.cc/hc/en-us/articles/360016119519-Add-boards-to-Arduino-IDEhttps://docs.arduino.cc/software/ide-v2/tutorials/ide-v2-board-manager
Das Arduino IDE ist nicht wirklich eine "Black Box" und es gibt viele
nützliche Informationsquellen für die Details "unter der Motor Haube".
Auch hier im Forum wurde mir schon mehrfach geholfen (Danke). Z.B. ist
es möglich einen LST File zu erstellen oder zu wissen wo sich die HEX
files aufhalten wie bei direkten Gebrauch von GCC.
Wenn man sich ein bisschen mit den Designdetails und Hintergründe von
Arduino befasst, wird Einem Vieles klarer. Nichts ist wirklich
verborgen. Man muß nur lernen und suchen, alles zu finden.
Man kann z.B. auch das IDE "Thema" individuell anpassen, um im IDE
angenehmere Text Farben zu haben. Die Default Wahl finde ich teilweise
grässlich.
https://support.arduino.cc/hc/en-us/articles/4408893497362-Use-a-custom-theme-for-Arduino-IDE-1https://draculatheme.com/arduino-idehttps://www.instructables.com/IDE-Arduino-With-Dark-Theme/
Man kann auch Arduino "zwingen" eine bestimmte GCC Version verwenden zu
müssen, wenn das aus speziellen Gründen notwendig wäre.
Gerhard
Gerhard O. schrieb:> Man kann z.B. auch das IDE "Thema" individuell anpassen
Mich stört die K&R Formatierung und habe auf Allman umgestellt.
Nutze mittlerweile C++20 für meine Projekte und einige Teile der
Libstdc++
Zudem habe ich längst nicht alle Boards. Drum die überflüssigen
ausgeblendet.
Es kann über Pid/Vid das Board beim Port anzeigen. Leider nicht beim
z.B. CH340, aber das am COM Port ein CH340 steckt, das kann man zur
Anzeige bringen, mildert das COM Chaos ein wenig.
usw. usw.
Gerhard O. schrieb:> Wenn man sich ein bisschen mit den Designdetails und Hintergründe von> Arduino befasst, wird Einem Vieles klarer.
Das ist aber nicht der Ansatz für Anfänger und Leute, die bei vielen
anderen, EINFACHEN Dingen schon ins Schwimmen geraten! Arduino ist auf
maximale Anfängerfreundlichkeit getrimmt! Und der OP gehört dazu! Er
hätte sich einen originalen Arduino Mega kaufen sollen, die paar Euro
mehr hat er sicher. Dann muss man sich nicht mit dem ganzen Kram
rumplagen und kann sich auf das Wesentliche konzentrieren. Aber das kann
und will er anscheinend nicht.
Falk B. schrieb:> Er hätte sich einen originalen Arduino Mega kaufen sollen,
Vielleicht....
Bringt nur nix bei seinen Grundlagenproblemen.
Sein Board läuft ja, er weiß nur nicht was er da tut.
Bis zum Haaransatz aufgefüllt, mit irrigen Vorstellungen/Fantasien
Richtig Arduino like wäre ja nur das Arduino API zu benutzen. Zum
Einlesen eines Pins also digitalRead(), nur Timer gibt es leider nicht.
Um Taktfrequenz muss man sich nicht kümmern, für Timing gibt es nur die
millis(), micros() oder das blockierende delay().
Wenn man jetzt maschinennah an die Register und Inline Assembler geht,
dann opfert man die Portabilität der Performance. Ich würde das wegen
ein paar gesparter µs auf 10 ms nicht machen.
Den Algorithmus von PeDa kann man mit Arduino Mitteln umsetzen,
allerdings muss man in der mainloop zyklisch die Pins abfragen, und da
muss alles brav kooperativ laufen. Ein langes delay oder eine lange
Operation verbietet sich, sonst werden keine Tasten abgefragt. Das
passiert aber auch bei Auswertung in der ISR, da will man ja auch nicht
direkt auf den Tastendruck reagieren.
Und wenn man faul ist, dann nimmt man z.B. Bounce2 oder besser
OneButton, das wertet auch Doppelklicks oder lange Tastendrücke aus und
arbeitet mit Callbacks.
J. S. schrieb:> Den Algorithmus von PeDa kann man mit Arduino Mitteln umsetzen,> allerdings muss man in der mainloop zyklisch die Pins abfragen, und da> muss alles brav kooperativ laufen. Ein langes delay oder eine lange> Operation verbietet sich, sonst werden keine Tasten abgefragt. Das> passiert aber auch bei Auswertung in der ISR, da will man ja auch nicht> direkt auf den Tastendruck reagieren.
Genau deshalb habe ich es auch nicht so gemacht.
Die Arduino-Lib benutzt nur T0, daher sind andere Timerinterrupts frei
verfügbar. Der kurze Code sorgt dafür, daß andere Interrupts kaum
ausgebremst werden.
Die Auswertung in der Mainloop sorgt wiederum dafür, daß Tasks nicht in
mehreren Instanzen laufen, z.B. LCD-Ausgabe der Uhrzeit und LCD-Ausgabe
bei Tastendruck. Das geht nämlich schief (LCD-Ausgaben sind nicht
reentrant).
Falk B. schrieb:> Er> hätte sich einen originalen Arduino Mega kaufen sollen, die paar Euro> mehr hat er sicher. Dann muss man sich nicht mit dem ganzen Kram> rumplagen und kann sich auf das Wesentliche konzentrieren. Aber das kann> und will er anscheinend nicht.>
Halt dich doch einfach mit deiner schlechten Laune oder generellen
Lebensunzufriedenheit raus, bis es dir besser geht, um mal noch
deutlicher zu werden.
Arduino F. schrieb:> Sein Board läuft ja, er weiß nur nicht was er da tut.> Bis zum Haaransatz aufgefüllt, mit irrigen Vorstellungen/Fantasien>
Das Selbe gilt für dich auch Arduino-Fanboy.
Bernd_Stein
Peter D. schrieb:> ...> Die Arduino-Lib benutzt nur T0, daher sind andere Timerinterrupts frei> verfügbar.> ...
Ich habe gelesen dass der zweite 8-Bit Timer2, für z.B die tone-Funktion
benutzt wird, ist es auch deshalb nicht besser, die schon vorhandene
millis-funktion und der Gleichen zu nutzen, um dass Abtastinterval zu
bestimmen ?
> ...> Die Auswertung in der Mainloop sorgt wiederum dafür, daß Tasks nicht in> mehreren Instanzen laufen, z.B. LCD-Ausgabe der Uhrzeit und LCD-Ausgabe> bei Tastendruck. Das geht nämlich schief (LCD-Ausgaben sind nicht> reentrant).> ...
Meine Vorstellung ist dass in der Mainloop, also der Arduino
loop-Funktion,
ich irgendwann zu dem Programmteil(en) komme, wo etwas passieren soll,
wenn der entsprechende Portpin-Taster in bestimmter Weise ( kurz, lang,
wieder losgelassen ) betätigt wurde. Dann wird der entsprechende
Programmteil bearbeitet und die entsprechende Portpin-Taster-Flagge
wieder gelöscht.
Was läuft da wie in mehreren Instanzen - B A H N H O F ?
Bernd_Stein
So ich hab das Ding mal noch weiter in Richtung Arduino-Stil angepaßt.
Keine direkten Hardwarezugriffe mehr, alles über digitalRead() und
digitalWrite(). Auch die Definition der IOs erfolgt 100% gemäß
Arduinokonvention. Nur die ISR ist noch direkt kodiert, das kann man
nicht umgehen und muss es auf Nicht-AVR Arduinos anpassen.
Bernd S. schrieb:> Meine Vorstellung ist dass in der Mainloop, also der Arduino> loop-Funktion,> ich irgendwann zu dem Programmteil(en) komme, wo etwas passieren soll,> wenn der entsprechende Portpin-Taster in bestimmter Weise ( kurz, lang,> wieder losgelassen ) betätigt wurde. Dann wird der entsprechende> Programmteil bearbeitet und die entsprechende Portpin-Taster-Flagge> wieder gelöscht.
Informiere Dich bitte ueber (finite) state Machinen (Zustandsmaschine
oder endlicher Automat). Nach dem Du Dich informiert hast, berichte
hier, in Deinen eigenen Worten, was Du gelernt hast.
Dann koennen wir diskutieren. Sonst ist das nur Gerede (und das meine
ich nicht wie Heidegger, Sinn und Zeit, 5. Kap, §§28-38).
Gruesse
Th.
Thomas W. schrieb:> Ach Falk, ->> Du bist dabei einem Blinden Farben zu erklaeren.
Nicht wirklich. Mein Beitrag zielt eher auf den Rest der Bastler in
diesem Univerum ab, nicht den OP. Bei dem sind die wesentlichen Zutaten
des Bierbrauprozesses verloren ;-)
Falk B. schrieb:> Thomas W. schrieb:>> Ach Falk, ->>>> Du bist dabei einem Blinden Farben zu erklaeren.>> Nicht wirklich. Mein Beitrag zielt eher auf den Rest der Bastler in> diesem Univerum ab, nicht den OP. Bei dem sind die wesentlichen Zutaten> des Bierbrauprozesses verloren ;-)
Ich gehe davon aus, dass der TO jetzt sich ueber FSM informiert und
einen kleinen Essay mit ca. 500 Worten (zwei Seiten) produziert :-) Gern
auf Deutsch.
So wie in der Schule.
Gruesse
Th.
Thomas W. schrieb:> Ich gehe davon aus, dass der TO jetzt sich ueber FSM informiert und> einen kleinen Essay mit ca. 500 Worten (zwei Seiten) produziert :-) Gern> auf Deutsch.
Na dann aber eher über EZA (Endlicher Zustandsautomat). ;-)
Bisher 89 Beiträge in 3 Tagen, doch mehr als ich zu diesem Thema
erwartet hätte, weil es ja für die Meisten gar kein Thema ist, aber dass
Stichwort ARDUINO hat wohl sein übriges getan.
Nur wie immer läßt es dieser Forumskeim irgendwie nicht zu, dass die
Leute sich auf den Kern des Threads konzentrieren können. Auch scheint
die Laune der Leute zur Zeit, wie dass Wetter zu sein.
War in der letzten Zeitspanne nicht mehr so intensiv hier im Forum tätig
und bin jetzt erstaunt, dass kein einziger GAST dabei ist, was ich gut
finde.
Somit kann ich in etwa abschätzen mit wem ich es hier zu tun habe.
Leider, dies mein ich jetzt nicht biederernst, denn ich habe Verständnis
für die Launen der Leute, ist der Einzige, der sich dem Kernproblem
angenommen hat, Falk B..
Ich habe hier verschiedene Geräte und auch wo anders schon erlebt, wo es
einfach nervig ist, wenn diese auf Tastendruck nicht richtig reagieren.
Mein Wasserkocher mit Temperaturanzeige z.B.
Ich drück auf die ON-Taste, hör und spür das klicken des Tasters, aber
die Anzeige bleibt dunkel. Meistens geht es wie es soll, aber eben nicht
immer.
Oder andere Temperatur wählen :
ON-Taste, geht, auch wenn nicht immer, Temperauturtaste geht, auch wenn
nicht immer und noch scheiße programmiert, denn es dauert 3 Sekunden,
bis das Ding durch blinken der Temperaturanzeige anzeigt, dass es seinen
Dienst aufnimmt.
Viel schlimmer mein chinesischer Küchentimer. Dunkel, klick, auch
Klickgeräusch, sowie Quittungston, Display an, noch mal klick, auch
wieder akustische Rückmeldung, aber läuft nicht an. Bermerke dies aber
erst nicht, weil sich mein Blick abwendet, bevor die erste Sekunde
heruntergezählt wird. Also erstmal kein Tastenerkkennungsproblem,
sondern scheisse programmiert. Nicht immer, aber immer nervig.
Oder, die Zeit ist abgelaufen, dass Ding nervt akkustisch wie es soll,
will es vorzeitig still machen, was durch den Tastendruck und
Quittungston auch passiert, aber dass Ding startet wieder ungewollt.
Dies auch wieder nicht immer, aber auch hier - immer nervig. Hierbei
scheint es den Tastendruck nicht richtig zu bearbeiten.
Oder, die Zeit läuft, da ich aber unterbrochen werde, drücke ich die
Taste, was eigentlich dazu führen sollte, dass die Zeit pausiert, was
passiert aber, wenn auch nicht immer ? Quittungston ertönt, aber die
Zeit läuft weiter.
Ich hab jetzt nur ein paar Dinge genannt und möchte selber nicht solche
scheiss Bedienungsroutinen schreiben, denn so etwas sollte heut zu Tage
doch wirklich kein Problem, in keinem Gerät mehr sein. Also ist es für
mich immer noch kein Standard geworden. ( Zumindest bei den chinesen ;-)
).
Aber wenn ich noch mal auf dass Buch im Eröffnungsthread erinnern darf
und die Routine, die sich auf die 50ms-Debounce-Routine der
Arduino-Gemeinde bezieht, dann sind es nicht nur die Chinesen, sondern
auch wir Hobbybastler, was ja nicht so schlimm wäre, aber wenn mir in
diesem folgenden Thread, Niemand wirklich funktionieren AVR8ASM-Code,
der angeblich Industriestandard sein soll, präsentieren kann, sondern
nur Stümmel davon, dann sieht es anscheined in D auch nicht besser aus :
Beitrag "Tater entprellen: Der Standard ?"
Bernd_Stein
Hallo, naja „Ich verlass mich da mal lieber auf Profis.“ Sagt schon
viel. Tastenentprellung ist eigentlich kein großes Ding und sollte so
nebenbei laufen. Es macht schon einen Unterschied, ob Du eine Taste für
z.B. sofortigen „Notstopp“ brauchst oder nur eine Lampe einschalten
möchtest. Dann kommt es darauf an, welche Eingänge frei sind und ob noch
ein freier Timer vorhanden ist und ob zeitkritische Aufgaben ein INT
erlauben. Danach entscheidet sich, welche Möglichkeiten man wählen
sollte. Ich programmiere gerne in AVR-Assembler und finde, das es
wirklich kein Problem ist, eine oder mehrere Tasten zuverlässig zu
entprellen.
Gruß
Carsten
Carsten-Peter C. schrieb:> Ich programmiere gerne in AVR-Assembler und finde, das es> wirklich kein Problem ist, eine oder mehrere Tasten zuverlässig zu> entprellen.> Gruß> Carsten>
Sag mal Carsten, hast du wirklich hier ( unten im Link ) alles gelesen
oder kommst du aus dem dort verlinkten Link zu diesem Thread hier ?
Es kommt mir vor, als ob du jetzt hier quereingestiegen bist und gar
nicht verstanden hast, wo ich das Problem sehe. Sicherlich hast du dir
den ganzen Thread, mit seinen 89 Antworten, nicht durchgelesen. Und
deiner Antwort nach, mach es auch gar keinen Sinn, sich hier mit
einzuklinken, denn für dich ist dass Thema doch abgehakt oder etwa nicht
?
Beitrag "Tasterverarbeitung mit ARDUINO-C : Bisheriges Fazit"
Bernd_Stein
Die 50 ms aus dem denounce Beispiel kann man auch auf 10 oder 20 ms
verkürzen, dafür braucht man doch jetzt nicht viel Phantasie.
Und das es hier keine Gäste mehr gibt scheint nur dem Al.K. und dir
entgangen zu sein :)
Und die OneButton Lib dürfte in den meisten Fällen reichen.
Bernd S. schrieb:> Ich habe hier verschiedene Geräte und auch wo anders schon erlebt, wo es> einfach nervig ist, wenn diese auf Tastendruck nicht richtig reagieren.
Ja, das ist leider schon der Normalzustand geworden. Wenn ich mal zurück
denke, wie blitzschnell mein erster Videorekorder auf Eingaben reagiert
hat. Heutzutage merkt man, wie im Hintergrund erstmal ein riesiges und
träges RTOS angeschmissen wird. Es würde mich nicht wundern, wenn
irgendwann bei jedem Tastendruck das Deckenlicht flackert wegen der
hohen CPU-Last in einem Gerät.
Man spart vielleicht wenige Minuten bei der Programmkonzeption ein und
der Kunde muß es um ein Vielfaches ausbaden.
Es ist ja nichtmal so, daß die Geräte zuverlässiger werden. Im
Gegenteil, die ganzen mehrfachen Instanzen, Deadlocks, Race Conditions
usw. kann keiner mehr überblicken.
Bernd S. schrieb:> Bisher 89 Beiträge in 3 Tagen, doch mehr als ich zu diesem Thema> erwartet hätte...> War in der letzten Zeitspanne nicht mehr so intensiv hier im Forum tätigBernd S. schrieb:> Nur wie immer läßt es dieser Forumskeim irgendwie nicht zu, dass die> Leute sich auf den Kern des Threads konzentrieren können.
Wenn du eine Horde Leute zum Diskutieren einlädst, und sie dann nicht
leitest, dann passiert das überall. Ist völlig normal. Hier ist es so,
dass der Thread-Ersteller (also du) für die Leitung verantwortlich ist.
Ich habe Firmen erlebt, die holen sich bei schwierigen Themen sogar
Externe Diskussionsleiter hinzu, damit das Thema effizient bearbeitet
wird.
Im Übrigen möchte ich dich darauf hinweisen, dass du selbst ebenfalls
vom Thema abgedriftet bist:
> Mein Wasserkocher mit Temperaturanzeige...> mein chinesischer Küchentimer...
Das sind nette Anekdoten, kennen wir alle, jedoch zur Klärung deiner
Eingangsfrage kein bisschen hilfreich. Wollen wir jetzt über
Wasserkocher diskutieren? Da kann ich auch einen Schwank aus meinem
Leben beitragen, der mich bewegt. Mache ich aber jetzt nicht.
Bernd S. schrieb:> Aber wenn ich noch mal auf dass Buch im Eröffnungsthread erinnern darf> und die Routine, die sich auf die 50ms-Debounce-Routine der> Arduino-Gemeinde bezieht, dann sind es nicht nur die Chinesen, sondern> auch wir Hobbybastler
Das führ doch zu nichts gutem. Nachdem du schlechte Aspekte dieser
Diskussion kritisiert hast, scheißt du nun selbst nochmal auf den Haufen
drauf. Du willst uns hier dazu anstiften, gemeinschaftlich über ein Buch
abzulästern, das wir alle nicht einmal gelesen haben. Und diese Nummer,
alle Menschen in wenige Schubladen zu stecken, kannst du auch gerne für
dich behalten. Das ist einfach nur dumm.
Am ärgerlichsten finde ich, dass du auf die hilfreich gemeinten
Antworten n nicht mehr eingegangen bist. Es scheint, dass du gar kein
Problem lösen wolltest, sondern nur über dein Buch und deine Geräte
ablästern wolltest. Warum hast du das Zeug denn gekauft? Ärgert es dich,
denn Schrott nicht vor dem Kauf als solchen erkannt zu haben, oder worum
geht es hier wirklich?
Ich warte ja noch auf den Essay des TO ueber den FSM (oder auf deutsch
"endlicher Zustandsautomat") und ich moechte dann auch mit dem TO ein
Kolloquium durchfuehren. Sonst lernt er ja nichts.
Gruesse
Th.
Stefan F. schrieb:> Wenn du eine Horde Leute zum Diskutieren einlädst, und sie dann nicht> leitest, dann passiert das überall. Ist völlig normal. Hier ist es so,> dass der Thread-Ersteller (also du) für die Leitung verantwortlich ist.>
Im normalem Leben, magst du recht haben, aber hier in der virtuellen
Welt gelten andere Regeln. Hier kann ich niemanden rausschmeissen, also
bin ich auch nicht der Jenige der diese große Party (
Mikrocontroller.net ), veranstalltet hat. Leider bin also immer dem
Gutdünken der Moderatoren hier unterworfen.
Wenn du mal die ersten Antworten, die auf meine Kernforderung kamen,
lesen würdest, dann ...
Bernd S. schrieb:> Würde gerne PeDa's C-Lösung, als Arduino-C Lösung mal sehen wollen !>
... dann würdest du auch erkennen, dass es in der virtuellen Welt sehr
schwierig ist, ein paar sich angepinkelt fühlende Leute, wieder los zu
werden. Dafür ist es zu einfach, bei jeder Party dabei zu sein, und an
den dortigen Gesprächen teilzunehmen. Diese Leute haben einfach zu viel
Zeit,
da sie sich in Probleme einmischen, die es in ihren Augen gar nicht gibt
und dementsprechend werden diese Leute natürlich auch gar nichts zur
Problembehebung beitragen, sondern nur irgendwelches Zeugs schreiben,
was meistens zeigen soll, was sie alles wissen und können.
Stefan F. schrieb:> Im Übrigen möchte ich dich darauf hinweisen, dass du selbst ebenfalls> vom Thema abgedriftet bist:>>> Mein Wasserkocher mit Temperaturanzeige...>> mein chinesischer Küchentimer...>> Das sind nette Anekdoten, ...>
Nö, es sind nervige Dinge, die höchstwahrscheinlich keine Hobbybastler
programmiert haben, sondern welche, die zumindest so tun, als ob sie
ihren Job beherrschen würden. Und das ist keines Falls vom Thema
abgedrifftet sondern, genau mit dem Finger in die Wunde gedrückt.
So, Stefanus jetzt kannst du ja mal zeigen, wie man diese Leute wieder
los wird und sich nur noch Leute bei diesem Partygespräch beteiligen,
die auch der Meinung sind, das PeDa's 8-Tasten-Routine, als eine weitere
Arduino-Bibliothek angeboten werden sollte.
Dies geht natürlich nur, wenn man bereit ist etwas dafür zu tun und auch
die entsprechenden Fähigkeiten und dass Wissen hat.
Also bitte verabschiedet euch doch langsam von diesem Thread, wenn ihr
dabei nicht mitwirken wollt. Wie gesagt Mikrokontroller.net ist eine
riesige Party, mit einer riesen Auswahl an Gesprächsthemen, dort könnt
ihr quatschen so viel ihr wollt, aber hier würde ich gerne Lösungen
sehen !!!
Bernd_Stein
Moin,
Was mich betrifft, ist das Thema schon ausreichend behandelt worden.
Peters brilliante Lösung konnte ich bis jetzt w.g. auf jeden von mir
eingesetzten Mikrocontroller erfolgreich einsetzen, einschließlich im
Arduino Ökusystem. In keinen Fällen mußte lang Fehler gesucht werden und
es funktionierte fast immer auf Anhieb in perfekter Weise.
Man kann davon ausgehen, daß Peters Lösung eine defacto Taster
Erfassungslösung für 1-8 Taster ist. Ich habe auch schon mehr als 8
Taster gehabt.
Warum sich also nicht freuen, daß Peter der Welt gut funktionierende
Problemlösungen geschenkt hat und es weisungsgemäß und dankbar
einzusetzen? Auch seine QE Lösungen funktionierten immer super
zuverlässig.
In der Zeit, die in diesem Thread schon akkumuliert wurde, hätte man
schon alles fertig programmiert und könnte sich im Sessel
zurücklehnen:-)
Obwohl ich niemanden von Euch sehr fest auf die Zehen steigen will,
erschließt sich mir also das häufige forumstypische Nörgeln nicht ganz.
Seid doch glücklich, daß es hilfsbereite Leute wie Peter gibt die ihre
fundierte Erfahrungen weitergeben willens sind, anstatt immer erst
krampfhaft die fiktiven Haare in der Suppe finden zu wollen. Also da
verstehe ich viele Leute hier nicht ganz.
OK, OK, ich renne ja schon...
VG,
Gerhard
Bernd S. schrieb:> Hier kann ich niemanden rausschmeissen,
das sollst du auch nicht, sondern die Diskussion dahin leiten, wo du hin
willst. Sonst leiten andere sie dahin wo sie hin wollen.
Als AVR8ASM-Geschädigter tue ich mich total schwer mit der
Arduino-Programmierung.
Wie kann ich in C bzw. C++ testen, ob im Arbeitsregister ( GPR ) r5,
dass Bit0 gesetzt ist ?
bitRead(); Funktioniert ja nur mit einem Wert bzw. einer Variablen.
Deshalb geht es ja so schon mal nicht :
Bernd S. schrieb:> Wie kann ich in C bzw. C++ testen, ob im Arbeitsregister ( GPR ) r5,> dass Bit0 gesetzt ist ?
Nur mit Inline-Assembler.
Aber das ist eine komplett widersinnige Fragestellung, wenn man in einer
Hochsprache programmiert, dann genau nicht, um in irgendwelchen
Prozessorregistern Bits abzufragen.
Arduino F. schrieb:> Warum sollte man sowas in C++ tun?>
So lautete meine Frage jedoch nicht.
Sondern :
Bernd S. schrieb:> Wie kann ich in C bzw. C++ testen, ob im Arbeitsregister ( GPR ) r5,> dass Bit0 gesetzt ist ?>
Falls du oder sonst irgendeiner hier dies nicht weiß oder für unnötig
hält
gibt es bestimmt jede Menge anderer Threads, wo ihr Euch auslassen
könnt.
Falls es gar nicht geht, dann am besten schreiben und evtl. auch
erklären.
Und immer schön hierdrann denken, so wie in diesem Fall, an Punkt 5.
"Die fünf universellen Forenregeln ;-)"
1. Threadüberschrift lesen
2. Evtl. Datum beachten
3. Posting verstehen
4. Falls nicht drittens, dann nachfragen oder Klappe halten.
5. Auf die Fragen eingehen und / oder Alternativen bzw. Verbesserungen
nennen.
Die Punkte kann man an einer Hand abzählen, man sollte also in der Lage
sein, bis fünf zählen zu können.
Deshalb sind sie evtl. gut zu merken, falls nicht dann nur Punkt 3 und
Punkt 4 merken.
Bernd_Stein
Ich sach nur: Hybris
Es ist nicht schlimm, wenn man den Unterschied zwischen Assembler und
C++ nicht kennt.
Aber der Orbit, da wo du kreist, das ist schon irgendwie bedenklich.
Bernd S. schrieb:> Wie kann ich in C bzw. C++ testen, ob im Arbeitsregister ( GPR ) r5,> dass Bit0 gesetzt ist ?
Einfach die Adresse des Arbeitsregisters abfragen und schauen ob das
Bit0 gesetzt ist sollte eigentlich kein Hexenwerk sein. Die Frage ist
eher: Wenn ich in einer Hochsprache programmiere, warum sollte mich
interessieren was soo tief unten in den Registern los ist? Kein
Vertrauen in Compiler und Co?
M. K. schrieb:> Kein Vertrauen in Compiler und Co?
Ich vermute eher, dass ihm nicht von seinen alten Denkweisen lassen
kann.
Und jetzt die alte ASM Denke auf C++ projiziert.
Das klappt so nicht. Soll es auch gar nicht. Ist es doch der Zweck,
einer der Aufgaben, einer Hochsprache, sich gerade von solchen Details
möglichst weit zu lösen.
Um den Sprung von ASM zu einer Hochsprache, hier C++, zu machen bedarf
es eines umfangreichen Umdenkens.
Paradigmenwechsel. Mehrere.
Das ist eine Hürde!
Für manche eine große Hürde.
DigitalWriteFast ist doch eigentlich nur erleichtern von Schreibarbeit.
Es werden für die Pins Bit und Port masken als Konstanten angelegt, das
meiste hat die IDE schon drin.
Dann hat man nur noch 2 Funktionen für Lesen und Schreiben die diese
nutzen.
Hallo,
Arduino F. schrieb:> Ich vermute eher, dass ihm nicht von seinen alten Denkweisen lassen> kann.> Und jetzt die alte ASM Denke auf C++ projiziert.
Du hast es genau auf den Punkt gebracht.
> Um den Sprung von ASM zu einer Hochsprache, hier C++, zu machen bedarf> es eines umfangreichen Umdenkens.> ...> Das ist eine Hürde!> Für manche eine große Hürde.
Und für Bernd ein zu große Hürde, schade.
rhf
Roland F. schrieb:> Du solltest wirklich mal was dagegen unternehmen überall bewusstes> destruktives Verhalten zu sehen und hinter allem Trolle zu vermuten.
Wenn sich Leute derart beratungsresistent und starrsinnig
anstellen muss man als Beobachter leider so denken.
Wastl schrieb:> Wenn sich Leute derart beratungsresistent und starrsinnig> anstellen muss man als Beobachter leider so denken.
Nicht unbedingt!
z.B.
Einem Blinden zu sagen: Jetzt schau doch mal richtig hin.
... dürfte recht nutzlos sein ...
So ist es offensichtlich nutzlos dem Bernd zu sagen, dass C++ gerade mit
seiner OOP, ca 2 Abstraktionsstufen höher angesiedelt ist.
Scheinbar kann er diese Stufen nicht mitgehen.
Vielleicht will ihm auch nicht.....
Von mir aus...
Aber aussehen, tuts nicht so.
@Falk B. (falk)
Dass du dich hier noch zu Wort meldest, zeigt mir dass du ernste
Probleme hast.
Lass dir helfen !
@Thomas W. (dbstw)
Du must hier nicht schreiben, oder ist das eine Art innerer Zwang ?
@Arduino F. ( Firma: Gast )
Sei doch bitte wo anders zu Gast, aber nicht auf dieser Party hier
oder leidest du auch an etwas ?
@Wastl. (hartundweichware)
Auch du scheinst eine unerkannte Krankheit zu haben.
Denn auch für dich besteht kein Zwang dich hier zu beteiligen.
Hugo H. schrieb:> ...> Wenn Du bis 5 zählen kannst kannst Du ggf. ja auch Lesen:>> https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Speichern_von_globalen_Flags>> Damit kannst Du Dir ein Register "reservieren" und jeder Zeit den> Zustand ändern / abfragen (mit kleinen Risiken). Basta.>> Und wenn Du DIch schon mal warmgelesen hast kannst Du ja im Forum auch> weiterstöbern, z.B.:>> Beitrag "Register reservieren in avr-gcc">
Ich denke dies Überfordert mich zu sehr.
Ich Dachte, ich packe PeDa's 12Takte-Code, als Inline-Assembler in eine
Timer Overflow ISR. Dies klappte ja anscheined auch so.
Dieses Vorgehen verändert das ABI! Um dieses Feature fehlerfrei anzuwenden, ist einiges an Wissen über die Interna vom GCC notwendig[3]. Auch ein korrekt funktionierendes Programm ist keine Garantie dafür, daß die globalen Register fehlerfrei implementiert wurden. Unter Umständen bringen erst spätere Codeänderungen/-erweiterung den Fehler zum Vorschein, und weil der Fehler vorher nicht akut war, sucht man sich den Wolf an der falschen Stelle im Code anstatt bei der globalen Registern. Siehe auch Globale Register.
Und Schlußendlich werte ich die einzelnen Bits von key_press ( GPR 5 )
und evtl. von key_state ( GPR 2 ) in der Mainloop aus. Auch dies scheint
ja nicht zu funktionieren
da mein Code-Vorschlag in dieser Form nicht geht und Niemand mir
AVR8ASM-Geschädigten gezeigt hat, wie es richtig in C++ auszusehen hat
bzw. hätte.
Bernd S. schrieb:> Ich Dachte, ich packe PeDa's 12Takte-Code, als Inline-Assembler in eine> Timer Overflow ISR.
Und warum schreibst Du das, was da geschieht, nicht einfach in C? Nichts
und niemand zwingt Dich, so etwas banales wie das timergesteuerte
Auslesen von Portpins unbedingt krampfhaft in Assembler zu machen.
Denn ganz offenbar bereitet Dir das Mischen von Assembler und C große
Probleme, vor allem, weil Du zu ignorieren scheinst, daß dabei der
C-Compiler vorgibt, wie der Assemblercode aufzubauen ist (eben das
"ABI", das aussagt, welche Register genutzt werden können, und von
welchen man die Finger zu lassen hat).
Du versuchst das andersrum, Du versuchst das ABI des Compilers zu
verbiegen, indem Du ihm vorschreiben willst, welche Register er zu
nutzen hat. Das ist die falsche Herangehensweise.
Aber für so eine triviale Aufgabe wie das prellfreie Abfragen von ein
paar Tastern ist der ganze Aufriss eh' nicht nötig. Da kommt es auch
nicht auf ein paar Taktzyklen mehr oder weniger an.
Harald K. schrieb:> Aber für so eine triviale Aufgabe wie das prellfreie Abfragen von ein> paar Tastern ist der ganze Aufriss eh' nicht nötig. Da kommt es auch> nicht auf ein paar Taktzyklen mehr oder weniger an.
Vor allem hat/gibts Peters Version da auch in C für, die mindestens
genauso gut ist. Der ASM-Kram kommt ja anscheinend nicht mal von Bernd,
wie kann man in so einer Situation für sowas Banales nur so stur an ASM
festhalten wenn man anscheinend eh in C/C++ unterwegs sein will verstehe
ich auch nicht. Uff.
Harald K. schrieb:>> Ich Dachte, ich packe PeDa's 12Takte-Code, als Inline-Assembler in eine>> Timer Overflow ISR.>> Und warum schreibst Du das, was da geschieht, nicht einfach in C?
Weil er ne Macke und Null Plan hat.
> Aber für so eine triviale Aufgabe wie das prellfreie Abfragen von ein> paar Tastern ist der ganze Aufriss eh' nicht nötig. Da kommt es auch> nicht auf ein paar Taktzyklen mehr oder weniger an.
Sysiphos 2.0
Na das Problem kennt doch jeder: ständig zu wenig Platz im Flash und CPU
überlastet. Da ist das erste was man macht die Tasterabfragen zu
verschlanken und möglichst nach handoptimierten Assemblercode
umzuschreiben.
J. S. schrieb:> Na das Problem kennt doch jeder: ständig zu wenig Platz im Flash und CPU> überlastet. Da ist das erste was man macht die Tasterabfragen zu> verschlanken und möglichst nach handoptimierten Assemblercode> umzuschreiben.
Stimmt, man ist ja immer besser als der Compiler. Da kann man richtig
was raus holen :D
Pack doch einfach alle Funktionen, die im timer interrupt aufgerufen
werden in ein "Blink without delay" Konstrukt und fertig ist der Lack.
Das geht dann auch auf jedem anderen Board mit Arduino.
Bernd S. schrieb:> Ich Dachte, ich packe PeDa's 12Takte-Code, als Inline-Assembler in eine> Timer Overflow ISR
Ohne die verwendeten Register zu sichern?
> Dann die dort speziell hierfür benötigen 4 unteren Register,> reserviere ich extra nur für diese Aufgabe.
Ist das überhaupt möglich in C?
Siehe dazu
https://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage
"r1 - assumed to be always zero in any C code"
Ich bin ziemlich sicher, dass der C Compiler das genau so benötigt.
Sonst werden zahlreiche von ihm generierten Codes etwas völlig anderes
machen, als erwartet.
J. S. schrieb:> Da ist das erste was man macht die Tasterabfragen zu> verschlanken und möglichst nach handoptimierten Assemblercode> umzuschreiben.
Ja, ich drücke auch immer die Tasten im 100kHz Takt, da hat es die CPU
schwer. Leider überhitzen meine Finger dabei.
Peter D. schrieb:>> Da ist das erste was man macht die Tasterabfragen zu>> verschlanken und möglichst nach handoptimierten Assemblercode>> umzuschreiben.
Irgendwie komme ich da nicht ganz mit, daß es so ein Zähne-ziehen
geworden ist. Bei mir haben Peters Routinen immer so schön auf jeden
meiner uC funktioniert. Ein wahrer Traum:-)
Warum sich also nicht einfach etwas anpassen und man hat gut
funktionierenden Code? Die Hauptsache ist, immer schön brav nicht
blockierenden Code zu schreiben. Dann funktioniert es auch wie erhofft.
Ich habe übrigens den Taster Code auch schon mit einem SPI
MUX-LED/Schrittmotor Treiber Code integriert, so daß drei Fliegen
gleichzeitig gefangen werden. Dann ist nur noch ein einzelner digitaler
Porteingang notwendig für 4 Taster-Eingänge. Die Tasten werden zwischen
den LED/Motor Impulsen abgetastet. (Beim Wasserstandmesser habe ich es
so gemacht und es funktioniert vorzüglich).
Hallo,
Gerhard O. schrieb:> Irgendwie komme ich da nicht ganz mit, daß es so ein Zähne-ziehen> geworden ist.
Du bist nicht der Einzige, dem es schwer fällt die Gedankengänge von
Bernd nachzuvollziehen.
rhf
Falk B. schrieb:> "Bernd" ist ChatGPT 0.0815 ;-)
Selbst ChatGPT 0.00042 würde nicht auf die Idee kommen eine komplette
ISR in inline Assembler in C++ zu bauen.
Es macht einfach keinen Sinn.
Kann man doch problemlos eine ISR in reinem Assembler als *.S anlegen
und linken.
Egal welche IDE. Selbst die älteste Arduino IDE kann das.
Auch würde ChatGPT 0.00042 erst alle C++ Sprachmittel ausschöpfen, bevor
es überhaupt anfängt mit inline Assembler. Und dann auch nur an den
absolut notwendigen Stellen.
Niemand (wirklich Niemand?) kommt auf die absurde Idee, zu versuchen dem
Compiler irgendwelche Register unter dem Arsch weg zu klauben. Auch
ChatGPT 0.00042 nicht.
Die Vereinbarung lautet stattdessen: Man legt eine Variable an, und der
Compiler hält sie solange in Registern, wie er kann. Das macht er gut.
Es ist ok, wenn Bernd in C++ einsteigt.
Es ist aber dumm, die Sprache nicht zu lernen, welche man da verwendet.
Ein dickes und modernes C++ Grundlagenbuch ist da sicherlich hilfreich.
Es ist auch dumm, die ASM Denke über C++ stülpen zu wollen.
C++ ist eine Multiparadigmen Sprache.
Wem das nicht schmeckt oder dieses ignoriert, buddelt offensichtlich auf
der falschen Baustelle.
Vergleich:
Da hat man eine bestens ausgestattet Werkstatt, mit allem, aber versucht
den Nagel mit einer Tasse in die Wand zu kloppen.
Zum Fremdschämen!
Bernd S. schrieb:> Anderen
das wird klein geschrieben :-)
und
es heißt "einen"...
Mehr habe ich zu dieser ganzen Nummer hier leider nicht beizutragen.
M.
Bernd S. schrieb:> Da gibt es tatsächlich doch noch ein Anderen CPU-Takt-Fuchser :
Wie dieser und Deine verschiedenen anderen Thread zum hochkomplexen
Thema "Tastenabfrage" sehr, sehr deutlich vorgeführt haben:
premature optimization is the root of all evil
(Verfrühte Optimierung ist die Wurzel allen Übels)
Selten bekommt man das klarer vorgeführt als in Deinen Beiträgen. Und Du
machst das ja schon seit mehreren Jahren so.
Bernd S. schrieb:> Da gibt es tatsächlich doch noch ein Anderen CPU-Takt-Fuchser
Das musste man früher(tm), als man grade so aus der Assembler-Höhle
gekrochen ist, evtl. noch machen, aber heute kauft man sich einfach den
nächst leistungsfähigeren µC, wenn die Rechenzeit oder der Speicher
knapp wird. Denn wenn es in einem Programm auf 14 Maschinentakte = <1µs
(@16MHz AVR) bei einem Interruptzyklus von 10ms (also weniger als 0,01%
der Gesamtrechenleistung) ankommt, dann darf man sowieso nichts mehr
dazuprogrammieren.
Oder andersrum: wenn die komplette Tasterabfrage 160 Maschinenzyklen
braucht und man lässt sie komplett weg, dann hat man nur 0,1% der
Rechenleistung "eingespart".
Und der logische Schluss: wenn dir die Rechenzeit knapp wird, dann
sicher nicht wegen der Tasterabfrage.
Lothar M. schrieb:> also weniger als 0,01% der Gesamtrechenleistung) ankommt, dann darf man> sowieso nichts mehr dazuprogrammieren.
Oder anders ausgedrückt: dann hat man vorher (beim Systemdesign) schon
etwas falsch gemacht.
Ich bin allerdings auch der Meinung, das man effizienten Code schreiben
sollte aber es muss sinnvoll sein und bleiben.
Die Tastenabfrage optimieren kann man ja machen, so als letztes
Quäntchen...wenn man am Ende des Projekts noch so viel Zeit übrig hat
die noch verbraucht werden muss, weil der Kunde sie ja bezahlt
hat...meiner Erfahrung nach ist es aber idR anders rum: Am Ende der Zeit
hat man noch so viel Projekt übrig... ;)
Ich habe daraus mal eine Klasse für Arduino gebaut, wenn du wirklich so
hilflos bist, wie du vorgibst, dann kann ich das heute Abend mal hier
reinstellen.
Ich mach das dabei über millis(), und du hast xxx.loop und xxx.setup
Funktionen wenn ich mich recht erinnere.
Wilhelm M. schrieb:> Wow, 139 Beiträge zu einer Tasten-Entprellung, für die es ziemlich gute> dokumentierte Vorlagen gibt. Bin gespannt, was jetzt noch so kommt ;-)
Das zeigt schön die allgemeine Programmier-Kompetenz im Forum.
Cyblord -. schrieb:> Das zeigt schön die allgemeine Programmier-Kompetenz im Forum.
Nicht nur hier.
Gestern musste ich einer Dame mit 5 Jahren Programmiererfahrung
erklären, warum man Arrays von größeren Strukturen besser mit Zeigern
(oder Referenzen) abarbeitet, anstatt jedes Element mehrfach zu
kopieren.
Steve van de Grens schrieb:> Cyblord -. schrieb:>> Das zeigt schön die allgemeine Programmier-Kompetenz im Forum.>> Nicht nur hier.>> Gestern musste ich einer Dame mit 5 Jahren Programmiererfahrung> erklären, warum man Arrays von größeren Strukturen besser mit Zeigern> (oder Referenzen) abarbeitet, anstatt jedes Element mehrfach zu> kopieren.
Dann würde ich ihr sehr schnell einen Grundkurs-C++ (Annahme C++, weil
Du oben von Referenzen geschrieben hast, und ich annahm, dass Du keine
abstrakte Referenzen sondern das technische C++-Konstrukt meinst)
angedeihen lassen.
Wilhelm M. schrieb:> Dann würde ich ihr sehr schnell einen Grundkurs-C++ (Annahme C++, weil> Du oben von Referenzen geschrieben hast, und ich annahm, dass Du keine> abstrakte Referenzen sondern das technische C++-Konstrukt meinst)> angedeihen lassen.
Oder in die Küche schicken . . . duckundweg ;-)
Wilhelm M. schrieb:> Dann würde ich ihr sehr schnell einen Grundkurs-C++ (Annahme C++, weil> Du oben von Referenzen geschrieben hast, und ich annahm, dass Du keine> abstrakte Referenzen sondern das technische C++-Konstrukt meinst)> angedeihen lassen.
Ind em Fall war es Golang, aber das ist ein grundsätzliches Thema
unabhängig von der Programmiersprache. Leider hat Go einen Iterator, der
so etwas provoziert:
1
varaddresses[]AddressType
2
...
3
fori,address:=rangeaddresses{
4
err:=verarbeite(address)
5
iferr!=nil{
6
logger.Errorf("Cannot process address %d: %w",i,err)
7
}
8
}
Range liefert Kopien der Adressen zurück. Und bei der Übergabe an die
Funktion, wird jede Adresse erneut kopiert. Natürlich gibt es eine
bessere Weise, range zu benutzen.
M. K. schrieb:> DU verwendest millis() in nem Interrupt? :o
Kann man doch tun!
In wie weit das sinnvoll ist kann man der konkreten Situation
überlassen.
Aber dagegen sprechen, in einer so allgemeinen Form, wie du es tust, tut
da nix.
Oder: Nenne einen Grund!
(aber lasse dabei bitte die Haare im Dorf)
Arduino F. schrieb:> Kann man doch tun!> Oder: Nenne einen Grund!
Millis hängt vom Systemtimer ab, der aber still steht, solange eine
andere ISR ausgeführt wird.
Steve van de Grens schrieb:> Millis hängt vom Systemtimer ab, der aber still steht, solange eine> andere ISR ausgeführt wird.
Ich bezweifel, dass ein Funktionsaufruf und ein return so viel Zeit in
Anspruch nimmt, dass dies Auswirkungen hätte.
Davon abgesehen, schaltet millis() eh die Interrupts aus, bevor der Wert
gelesen wird. Somit kommts irgendwie aufs gleiche.
1
unsignedlongmillis()
2
{
3
unsignedlongm;
4
uint8_toldSREG=SREG;
5
6
// disable interrupts while we read timer0_millis or we might get an
7
// inconsistent value (e.g. in the middle of a write to timer0_millis)
Steve van de Grens schrieb:> Millis hängt vom Systemtimer ab, der aber still steht, solange eine> andere ISR ausgeführt wird.
Das ist allgemein bekannt!
millis() liefert in einer ISR immer den gleichen Wert.
Sollte aber kein Problem sein, da man ISR kurz halten sollte.
Nein, das ist kein Grund millis() nicht zu nutzen!
Ihr meint bestimmt delay()....
Arduino F. schrieb:> millis() liefert in einer ISR immer den gleichen Wert.
Darauf wollte ich hinaus. Wenn das zum Anwendungsfall passt: fein.
Innerhalb einer ISR darauf warten, dass n Milliskunden verstreichen,
wird aber nicht gehen. Allerdings sind Warteschleifen innerhalb einer
ISR meistens eh eine blöde Idee.
Steve van de Grens schrieb:> Innerhalb einer ISR darauf warten, dass n Milliskunden verstreichen,> wird aber nicht gehen. Allerdings sind Warteschleifen innerhalb einer> ISR meistens eh eine blöde Idee.
Da kann ich dir zustimmen.
Wobei man in seiner ISR durchaus Interrupts erlauben kann.
Aber das ist wieder eine ganz andere Baustelle, mit ganz neuen Sorgen.
Arduino F. schrieb:> Aber dagegen sprechen, in einer so allgemeinen Form, wie du es tust, tut> da nix.
Stimmt, es war zu allgemein. Es ging hier ja um das Entprellen von
Tasten und das Warten und das, so wurde es suggeriert, wurde mit Hilfe
von millis() in einem Interrupt gelöst. Klingt jetzt nicht nach einer
guten Lösung aber die Lösung, die ja eigentlich längst vorliegen sollte,
sehen wir ja bis jetzt noch nicht :)
Ach, hier was zum drehbaren China-Küchentimer :
Wer mir die Frage dort beantworten kann, soll dies bitte auch dort in
diesem Thread machen.
Ansonsten wisst ihr es ja schon, denkt an die 5 universellen
Forumsregeln ;-)
Beitrag "Chinaschrott mit Typ und Verkäufer : Küchentimer mit Drehring"
Bernd_Stein
Ich finde das faszinierend!
Ist ein bisschen morbide, wie "Ruinenlust".
Ich weiß nicht genau, wie lange ich mich mit Tasterabfragen beschäftigt
habe...
Aber länger als jeweils 1/2H mag ich nicht glauben.
Dieses hier hält schon min. 8 Jahre an.
Woran das liegt, ist nicht leicht zu diagnostizieren. Nach meinen
bisherigen Erkenntnissen scheint das eine Art Innenwelt Orbit zu sein.
Wohl eine massive neurotische Fehlanpassung.
Warum hat man sich bei µC.net und nicht bei PsychischeErkrankungen.de
angemeldet ?
Naja - Einige hier wohl bei beiden.
Nun, ich denke weil einem das interessiert.
Warum antwortet man auf Tasterentprellen oder ähnlichen
Threadübeschriften ?
Leider wohl einige auf der Grundlage von anderen Interessen, die ich
nicht verstehen kann und will, da ich kein Artzt bin und deshalb wenig,
bis gar keine Ahnung von dieser Materie habe.
Das Interesse von den µC-Betreibern und Unterstützern, scheint ein hohes
Aufkommen von Beiträgen zu sein, wo ruhig die Qualität leiden darf.
Die Möglichkeit Beiträge zu bewerten, zieht natürlich ein bestimmtes
Klientel an, aber schlecht beeinflussbare Leute interessiert dies
natürlich nicht und diese bilden sich ihre Meinung selbst.
In der Realität würde man sich natürlich in seiner Freizeit nicht mit
solchen Leuten abgeben, aber hier in der virtuellen, wird man sie
einfach nicht los.
Da hilft wohl ein blick in die Tierwelt und dass dortige Verhalten, um
hier besser mit diesen Leuten zurecht zu kommen. Glücklicherweise gibt
es dieses Gastkonstrukt ja nicht mehr und man kann sich die Namen
erstmal merken, bis sie sich einen neuen zulegt haben und sieht quasie,
was bzw. wer, einen da anklefft besser.
Nun ja, ich sehe es jetzt mal so wie ein Schäferhund der von so einem
Handtaschenköter angeklefft wird. Er guckt mal kurz hin und geht seinen
Weg weiter. Wie eine echte Konfrontation der beiden, sehr wahrscheinlich
ausgehen würde, ist wohl jedem der seine eigene Meinung bilden kann
klar.
Wem dass hier interessiert braucht also nur meinen Namen als
Suchfunktion zu benutzen und erspart sich in Zukunft den ganzen
Datenmüll. Ob es dann,wie so oft in den Threads hier, in einer
Informationleiche endet, weiß ich leider nicht, da ich nur selten die
Probleme löse und man hier eigentlich nur Hilfe erwarten kann, wenn es
einfach zu lösen ist.
In diesem Sinne - Noch viel Spaß beim interessierten Lesen meiner
Beiträge ;-)
Bernd_Stein
Bernd S. schrieb:> Nun, ich denke weil einem das interessiert.Bernd S. schrieb:> Wem dass hier interessiert braucht
Ich würde mal sagen: dem Dativ ist den Akkusativ sein Feind ;-)
Bernd S. schrieb:> In diesem Sinne - Noch viel Spaß beim interessierten Lesen meiner> Beiträge ;-)
Sicher, sowohl fachlich wie auch grammatikalisch bleiben wir amüsiert.
Bernd S. schrieb:> Warum antwortet man auf Tasterentprellen oder ähnlichen> Threadübeschriften ?
Ursprünglich haben darauf Leute geantwortet, die Dir helfen wollten. So
nämlich funktioniert dieses Forum hier.
Allerdings haben Deine fortgesetzten Reaktionen und Deine komplette
Weigerung, auf Hilfsangebote einzugehen, die Stimmung allmählich
verändert.
Ein Fakt ist, dass Taster prellen.
Wie lange ist individuell, wie die akribische Fleißarbeit dieses Mannes
zeigt :
https://www-ganssle-com.translate.goog/debouncing.htm?_x_tr_sch=http&_x_tr_sl=en&_x_tr_tl=de&_x_tr_hl=de&_x_tr_pto=sc
Als Fazit daraus :
Die meisten Prellzeiten liegen unter 10ms.
Es gab aber auch Taster die brauchten nur *6,2ms*, aber ein besonders
schlechter hatte beim Öffnen, also loslassen, ca. 157ms lang geprellt.
Und während dieser Prellzeit ist es halt schlecht zu sagen, welcher
Pegel vorherrschen wird, also muss man versuchen das Ende des Prellens
zu erkennen und erst hiernach den Taster verarbeiten.
Dass tolle an PeDa´s Routine ist zum einen, dass sie sich der jeweiligen
Prellzeit des Tasters anpasst. Wie schnell wird durch dass
Timer/CounterX- Interruptintervall bestimmt. Weitere Vorteile sind, die
ziemlich zuverlässige Erkennung des Prellendes, sowie die zeit,- und
resourcenschonende Programmierung dieser Erkennung. Nebenbei werden 8
Eingabetaster oder Endschalter auf einmal erfasst und auch dass
Loslassen, also Öffnen entprellt.
Jetzt könnte man annehmen, dass ein idealer, also prellfreier Taster
entweder gedrückt oder losgelassen ist. Aber eine genauere Betrachtung
die auch im folgenden Link unter Entprellung per Software angestellt
wird, ist dass es hierzu auch eine gedrückt,- und loslass-Flanke gibt.
Kurz gesagt gesagt es gibt vier Zustände, die ich dem Link entnehme.
1
Bei einem Taster gibt es insgesamt 4 theoretische Zustände:
2
3
war nicht gedrückt und ist nicht gedrückt
4
war nicht gedrückt und ist gedrückt (steigende Flanke)
5
war gedrückt und ist immer noch gedrückt
6
war gedrückt und ist nicht mehr gedrückt (fallende Flanke)
https://elektro.turanis.de/html/prj059/index.html
*PeDa´s C-Komportroutine* verarbeitet diese 4 Zustände.
Nun ist es bei einem Eingabetaster meist so, dass er von einem
Menschen bedient wird und dieser besitzt eine Reaktionszeit zwischen
ca. 200 - 400ms. Eine Verzögerung wird bereits nach ca. 100ms bemerkt
und 50ms gelten noch als Augenblicklich.
Die Zeit, die der Mensch zwischen drücken und loslassen so benötigt,
liegt ca. bei 30 - 40ms. Bei Spielekonsolenspielern sind auch <10ms
möglich.
Die Pause zwischen zwei Betätigungen, kann jedoch ca. 80 - 100ms
betragen.
Wenn ich einen Taster betätige, wünsche ich eine sofortige Rückmeldung,
also etwas, dass am besten *innerhalb von <50ms* geschieht und dies auch
noch zuverlässig, deshalb ist für mich diese " standard "
Arduino-Debounce-Geschichte mit seinen 50ms nicht vereinbar.
https://www.arduino.cc/en/Tutorial/BuiltInExamples/Debounce
Was da wohl bei dem 157ms lang prellenden Taster herauskommt ?
Bei PeDa´s Routine kann man es sehr gut abschätzen. Die zuverlässige
Reaktion auf die Tasterbetätigung dauert ungewöhnlich lange, also
tauscht man den Taster aus.
Bernd_Stein
Bernd S. schrieb:> Was da wohl bei dem 157ms lang prellenden Taster herauskommt ?>> Bei PeDa´s Routine kann man es sehr gut abschätzen.
Daraus lese ich:
Du bist mit dem Beispiel überfordert. Kannst den Code nicht
lesen/verstehen, so dass es dir nicht möglich ist, das Verhalten
vorherzusagen.
wow!