Tasterverarbeitung mit ARDUINO-C

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.

1

#include <Arduino.h>

2

3

/************************************************************************/

4

/*                                                                      */

5

/*                      Debouncing 8 Keys                               */

6

/*                      Sampling 4 Times                                */

7

/*                      With Repeat Function                            */

8

/*                                                                      */

9

/*              Author: Peter Dannegger                                 */

10

/*                      danni@specs.de                                  */

11

/*                                                                      */

12

/************************************************************************/

13

14

#include <stdint.h>

15

#include <avr/io.h>

16

#include <avr/interrupt.h>

17

18

#ifndef F_CPU

19

#define F_CPU           1000000                   // processor clock frequency

20

#warning kein F_CPU definiert

21

#endif

22

23

#define KEY_DDR         DDRB

24

#define KEY_PORT        PORTB

25

#define KEY_PIN         PINB

26

#define KEY0            0

27

#define KEY1            1

28

#define KEY2            2

29

#define ALL_KEYS        (1<<KEY0 | 1<<KEY1 | 1<<KEY2)

30

31

#define REPEAT_MASK     (1<<KEY1 | 1<<KEY2)       // repeat: key1, key2

32

#define REPEAT_START    50                        // after 500ms

33

#define REPEAT_NEXT     20                        // every 200ms

34

35

#define LED_DDR         DDRA

36

#define LED_PORT        PORTA

37

#define LED0            0

38

#define LED1            1

39

#define LED2            2

40

41

volatile uint8_t key_state;                                // debounced and inverted key state:

42

                                                  // bit = 1: key pressed

43

volatile uint8_t key_press;                                // key press detect

44

45

volatile uint8_t key_rpt;                                  // key long press and repeat

46

47

void setup() {

48

  // put your setup code here, to run once:

49

}

50

51

ISR( TIMER0_OVF_vect )                            // every 10ms

52

{

53

  static uint8_t ct0 = 0xFF, ct1 = 0xFF, rpt;

54

  uint8_t i;

55

56

  TCNT0 = (uint8_t)(int16_t)-(F_CPU / 1024 * 10e-3 + 0.5);  // preload for 10ms

57

58

  i = key_state ^ ~KEY_PIN;                       // key changed ?

59

  ct0 = ~( ct0 & i );                             // reset or count ct0

60

  ct1 = ct0 ^ (ct1 & i);                          // reset or count ct1

61

  i &= ct0 & ct1;                                 // count until roll over ?

62

  key_state ^= i;                                 // then toggle debounced state

63

  key_press |= key_state & i;                     // 0->1: key press detect

64

65

  if( (key_state & REPEAT_MASK) == 0 )            // check repeat function

66

     rpt = REPEAT_START;                          // start delay

67

  if( --rpt == 0 ){

68

    rpt = REPEAT_NEXT;                            // repeat delay

69

    key_rpt |= key_state & REPEAT_MASK;

70

  }

71

}

72

73

///////////////////////////////////////////////////////////////////

74

//

75

// check if a key has been pressed. Each pressed key is reported

76

// only once

77

//

78

uint8_t get_key_press( uint8_t key_mask )

79

{

80

  cli();                                          // read and clear atomic !

81

  key_mask &= key_press;                          // read key(s)

82

  key_press ^= key_mask;                          // clear key(s)

83

  sei();

84

  return key_mask;

85

}

86

87

///////////////////////////////////////////////////////////////////

88

//

89

// check if a key has been pressed long enough such that the

90

// key repeat functionality kicks in. After a small setup delay

91

// the key is reported being pressed in subsequent calls

92

// to this function. This simulates the user repeatedly

93

// pressing and releasing the key.

94

//

95

uint8_t get_key_rpt( uint8_t key_mask )

96

{

97

  cli();                                          // read and clear atomic !

98

  key_mask &= key_rpt;                            // read key(s)

99

  key_rpt ^= key_mask;                            // clear key(s)

100

  sei();

101

  return key_mask;

102

}

103

104

///////////////////////////////////////////////////////////////////

105

//

106

// check if a key is pressed right now

107

//

108

uint8_t get_key_state( uint8_t key_mask )

109

110

{

111

  key_mask &= key_state;

112

  return key_mask;

113

}

114

115

///////////////////////////////////////////////////////////////////

116

//

117

uint8_t get_key_short( uint8_t key_mask )

118

{

119

  cli();                                          // read key state and key press atomic !

120

  return get_key_press( ~key_state & key_mask );

121

}

122

123

///////////////////////////////////////////////////////////////////

124

//

125

uint8_t get_key_long( uint8_t key_mask )

126

{

127

  return get_key_press( get_key_rpt( key_mask ));

128

}

129

130

void loop() {

131

  // put your main code here, to run repeatedly:

132

}

133

134

int main( void )

135

{

136

  LED_PORT = 0xFF;

137

  LED_DDR = 0xFF;

138

139

  // Configure debouncing routines

140

  KEY_DDR &= ~ALL_KEYS;                // configure key port for input

141

  KEY_PORT |= ALL_KEYS;                // and turn on pull up resistors

142

143

  TCCR0 = (1<<CS02)|(1<<CS00);         // divide by 1024

144

  TCNT0 = (uint8_t)(int16_t)-(F_CPU / 1024 * 10e-3 + 0.5);  // preload for 10ms

145

  TIMSK |= 1<<TOIE0;                   // enable timer interrupt

146

147

  sei();

148

149

  while(1){

150

    if( get_key_short( 1<<KEY1 ))

151

      LED_PORT ^= 1<<LED1;

152

153

    if( get_key_long( 1<<KEY1 ))

154

      LED_PORT ^= 1<<LED2;

155

156

    // single press and repeat

157

158

    if( get_key_press( 1<<KEY2 ) || get_key_rpt( 1<<KEY2 )){

159

      uint8_t i = LED_PORT;

160

161

      i = (i & 0x07) | ((i << 1) & 0xF0);

162

      if( i < 0xF0 )

163

        i |= 0x08;

164

      LED_PORT = i;

165

    }

166

  }

167

}

Bernd_Stein

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!

1

Groß- und Kleinschreibung verwenden

2

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

Schon etwas älter aber vielleicht hilft es. Beitrag "Entprellung von Tastern"

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:

1

[env:attiny84]

2

platform = atmelavr

3

board_build.mcu = attiny84

4

board_build.f_cpu = 8000000L

5

upload_protocol = custom

6

upload_flags =

7

    -C

8

    ${platformio.packages_dir}/tool-avrdude/avrdude.conf

9

    -v

10

    -p

11

    attiny84

12

    -P 

13

    usb

14

    -c

15

    avrispmkii

16

upload_command = avrdude $UPLOAD_FLAGS -U flash:w:$SOURCE:i

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.

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 TCCR0B und TIMSK in TIMSK0, 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.

So geht es. Getestet auf Arduino UNO, sollte aber auf allen anderen AVR-Typen auch laufen.

@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!

Merkwürdig, die Funktion Debounce() fehlt immer noch.

https://www.arduino.cc/reference/en/

Georg M. schrieb:

fehlt

https://www.arduino.cc/en/Tutorial/BuiltInExamples/Debounce

Arduino F. schrieb:

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!

Danke, da habe ich wohl eine unbrauchbare Vorlage genutzt. Nun muss ich allerdings mit zwei Vorlagen arbeiten, um zu sehen dass z.B. :

PE0 = Pin 2 des µC ist, welcher unter anderem den USART0-RxD nutzt und auf dem Arduino Mega 2560-Board die Buchsenbezeichnung D0, was sich wohl als

pinMode(0, OUTPUT); digitalWrite(0, HIGH);

zu einem leuchten der Rx-LED überreden läßt. Ganz schön komplex um nicht zu schreiben kompliziert.

https://europe1.discourse-cdn.com/arduino/original/4X/f/0/c/f0c0a5f45d082fd079296c238e2fdea720884696.jpeg

https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-schematic.pdf

Ach, digitalWrite() ist also normales C++ ?

Arduino F. schrieb:

Georg M. schrieb:

fehlt

https://www.arduino.cc/en/Tutorial/BuiltInExamples/Debounce

Genau diesen 50ms-Quatsch habe ich in meinem Eröffnungsthread gemeint !

Bernd_Stein

Bernd S. schrieb:

Ach, digitalWrite() ist also normales C++ ?

Natürlich. Es ist eine ganz normale C++ Funktion.

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 ?

Stichwort : digitalWriteFast

https://forum.arduino.cc/t/geschwindigkeit-digitalread-digitalwrite/242012

https://github-com.translate.goog/NicksonYap/digitalWriteFast?_x_tr_sl=en&_x_tr_tl=de&_x_tr_hl=de&_x_tr_pto=sc

https://www.stummiforum.de/t174458f7-Projektvorstellung-Low-Cost-Eigenbau-S-mit-Atmega-Arduino.html

Bernd_Stein

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".

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

6

; und CKDIV8-FUSE werksseitig programmiert ( = 0 ) => 9,6MHz / 8 = 1,2MHz.

7

;

8

; Muss also im Auslieferungszustand ein Rechtecksignal von 150kHz ausgeben

9

;

10

;SBI => 2Takte, RJMP => 2T usw. ergibt eine Frequenz von 150kHz

11

;mal die 8Takte pro Periode = 1,2MHz

12

;

13

;                   SBI 2T RJMP 2T

14

;    ______________                ___

15

;___|SBI 2T RJMP 2T|______________|

16

;

17

;

18

;.def LED = Bit vom jeweiligen PORT

19

;

20

 sbi  DDRB, LED

21

_TEST:

22

 sbi  PINB, LED ; Portpin toggeln ( 2 Takte )

23

 rjmp _TEST     ; 2 Takte

Bernd_Stein

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

Bernd S. schrieb:

wie im Schaltplan,

Wo hast du denn einen Schaltplan für den Clon gefunden?

Arduino F. schrieb:

Bernd S. schrieb:

wie im Schaltplan,

Wo hast du denn einen Schaltplan für den Clon gefunden?

Hatte ich zwar schon verlinkt, aber dann halt nochmal. Der vermeintliche Quarz kann aber auch ein Resonator sein !

https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-schematic.pdf

Bernd_Stein

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:

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.

Stimmt leider. Der Schaltplan ist der Falsche aber dieses Pinout-Bild dass Richtige.

https://europe1.discourse-cdn.com/arduino/original/4X/f/0/c/f0c0a5f45d082fd079296c238e2fdea720884696.jpeg

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.

Bernd S. schrieb:

Ok, irgendwie aufgebläht ohne Ende

Dann benutz halt nicht das Arduino-Framework sondern schreib dir deine Funktionen selbst

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

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...

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=7wx27FcluMg

Peter 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

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-IDE https://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-1 https://draculatheme.com/arduino-ide https://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

Arduino F. schrieb:

Tipp: ALLE Arduino Mega Nachbauten, werden wie die originalen, mit 16MHz ausgeliefert.

Glück gehabt. Bei anderen sieht das anders aus. Den Pro Mini gibt es bspw. mit 8 oder 16MHz. Die Welt ist vielfältig. https://www.sparkfun.com/search/results?term=ARDUINO+PRO+MINI

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.

Rainer W. schrieb:

Den Pro Mini gibt es bspw. mit 8 oder 16MHz.

Die Klone, genau wie die originalen! Also auch hier keine Überraschung.

Wenn eine abweichende Borddefinition nötig ist, dann geben die Hersteller/Verkäufer das in aller Regel, in den Beschreibungen, kund.. Beispiel: http://www.inhaos.com/product_info.php?products_id=157

Hier im Download Bereich, das user manual http://www.inhaos.com/uploadfile/otherpic/UM-MASSDUINO-V3.0-EN.pdf

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

Huch, ich sehe meine Verehrerstatistik ja gar nicht mehr :-D

Hier lesen :

Beitrag "Re: Bewertungsfunktion mit uBlock-Origin entfernen"

und

Linksklick auf Icon, Linksklick auf Zahnrädchen-Symbol ...

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.

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 ;-)

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). ;-)

Falk B. schrieb:

Bei dem sind die wesentlichen Zutaten des Bierbrauprozesses verloren ;-)

Wasser und Hefe???

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.

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

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 :

1

if(bitRead(r5,0)) == 1 digitalWrite(LED0, !digitalRead(LED0));

AVR8ASM

1

sbrs r5,0 ;Bit0 im GPR 5 gesetzt? falls ja naechsten Befehl ueberspringen

2

rjmp Nein ;Bit0 ist nicht gesetzt, also zu Nein springen

Bernd_Stein

Warum sollte man sowas in C++ tun?

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 im Beitrag #7398636:

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:

Die Punkte kann man an einer Hand abzählen, man sollte also in der Lage sein, bis fünf zählen zu können.

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"

Arduino F. schrieb:

Aber der Orbit

Nennt man die Bahnen, welche unterhalb der Grasnarbe verlaufen, "Orbit"? :-)

Innenweltorbit.

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.

Beitrag "Re: Mit dem ATMEL STUDIO 7 klarkommen" Beitrag "Re: Mit dem ATMEL STUDIO 7 klarkommen"

Nuff said.

Hallo, Arduino F. schrieb im Beitrag #7398921:

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

Hallo, Falk B. schrieb im Beitrag #7399002:

Beitrag "Re: Mit dem ATMEL STUDIO 7 klarkommen" Beitrag "Re: Mit dem ATMEL STUDIO 7 klarkommen"

Blödsinn.

Du solltest wirklich mal was dagegen unternehmen überall bewusstes destruktives Verhalten zu sehen und hinter allem Trolle zu vermuten.

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.

1

#include "Arduino.h"

2

#include <avr/interrupt.h>

3

//------------------------------------------------------------------------------

4

// 16-bit Timer/Counter 1 Overflow Interrupt alle 4ms (16Mhz/2^16)

5

//------------------------------------------------------------------------------

6

ISR( TIMER1_OVF_vect )

7

{

8

 // r1 = interrupt Arbeitsregister

9

10

 // r2 = key_state ;Entprellter Tasterzustand invertiert

11

 // r3 = key_ct0   ;2-Bit Abwaertszaehler Bit0

12

 // r4 = key_ct1   ;2-Bit Abwaertszaehler Bit1

13

 // r5 = key_press ;Taster entprellt gedrueckt gespeichert

14

  asm volatile

15

      (

16

        "in  r1,0x0C ;PINE      \n\t"

17

        "com r1      ;low activ \n\t"

18

        "eor r1,r2   ;          \n\t"

19

        "and r3,r1   ;          \n\t"

20

        "com r3      ;          \n\t"

21

        "and r4,r1   ;          \n\t"

22

        "eor r4,r3   ;          \n\t"

23

        "and r1,r3   ;          \n\t"

24

        "and r1,r4   ;          \n\t"

25

        "eor r2,r1   ;          \n\t"

26

        "and r1,r2   ;          \n\t"

27

        "or  r5,r1   ;          \n\t"

28

      );  

29

} // Ende ISR ( TIMER1_OVF_vect ) Timer1 Overflow Interrupt

Dann die dort speziell hierfür benötigen 4 unteren Register, reserviere ich extra nur für diese Aufgabe. Was ja offensichtlich nicht geht, ohne sich evtl. später ein Problem einzufangen, welches sehr, sehr schwierig auszumachen sein wird.

https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Speichern_von_globalen_Flags

1

Warnung !!!

2

3

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.

1

if(bitRead(r5,0)) == 1 digitalWrite(LED0, !digitalRead(LED0));

AVR8ASM

1

sbrs r5,0 ;Bit0 im GPR 5 gesetzt? falls ja naechsten Befehl ueberspringen

2

rjmp Nein ;Bit0 ist nicht gesetzt, also zu Nein springen

Bernd_Stein

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.

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 im Beitrag #7400066:

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

Roland F. schrieb:

Du bist nicht der Einzige, dem es schwer fällt die Gedankengänge von Bernd nachzuvollziehen.

"Bernd" ist ChatGPT 0.0815 ;-)

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!

Gerhard O. schrieb:

Bei mir haben Peters Routinen immer so schön auf jeden meiner uC funktioniert. Ein wahrer Traum:-)

+1 auf AVR und ESP32

Peter D. schrieb:

Leider überhitzen meine Finger dabei.

https://www.youtube.com/watch?v=cVWaJFjMEqA :-)