Drehgeber und Tastenentprellung für Arduino

[Falk B. (falk)]

Siehe Anhang. Damit kann man eigene Projekte mit den bekannten und 
bewährten Methoden hier aus dem Forum ausstatten. Viel Spaß damit.

[Wilhelm M. (wimalopaan)]

Falk B. schrieb:
> Siehe Anhang. Damit kann man eigene Projekte mit den bekannten und
> bewährten Methoden hier aus dem Forum ausstatten. Viel Spaß damit.

Mmh, das ist ja aus

Beitrag "Peter Dannegger´s ( PeDa ) Entprellroutine in ein Arduino Sketch einbinden"

entstanden, nach meiner Bemerkung, dass eine C++ Version des zugehörigen 
Artikels fehlt (v.a. weil in der C-Version der Variablenname "new" 
auftaucht, was in C++ ein Schlüsselwort ist).

Diese Version hier vermeidet zwar das o.g. Problem, und gibt den 
Anschein von C++ (v.a. durch die Dateinamen), jedoch ist es das 
mitnichten: es ist C-Code ohne Verwendung des Variablennamens "new".

[Falk B. (falk)]

Wilhelm M. schrieb:
> Diese Version hier vermeidet zwar das o.g. Problem, und gibt den
> Anschein von C++ (v.a. durch die Dateinamen), jedoch ist es das
> mitnichten: es ist C-Code ohne Verwendung des Variablennamens "new".

Nichts anderes habe ich behauptet ;-) Mit "Methode" meinte ich eher 
Konzept, nicht Methode im Sinne von C++. 8-0

[Wilhelm M. (wimalopaan)]

Falk B. schrieb:
> Wilhelm M. schrieb:
>> Diese Version hier vermeidet zwar das o.g. Problem, und gibt den
>> Anschein von C++ (v.a. durch die Dateinamen), jedoch ist es das
>> mitnichten: es ist C-Code ohne Verwendung des Variablennamens "new".
>
> Nichts anderes habe ich behauptet ;-)

Ok, ich hatte wie gesagt aus den Dateinamen und "Arduino" auf C++ 
geschlossen: offenbar falsch.

[Falk B. (falk)]

Wilhelm M. schrieb:
> Ok, ich hatte wie gesagt aus den Dateinamen und "Arduino" auf C++
> geschlossen: offenbar falsch.

Der du des C++ mächtig bist, kanst es ja in echtes C++ umschreiben. Aber 
denk an deine Zielgruppe! Das sind keine C++ Cracks! KISS!

[Veit D. (devil-elec)]

Hallo,

wo ich das las dachte ich auch zuerst an C++, auch wegen Arduino. Es 
stecken mir ehrlich gesagt zu viele versteckte defines drin. Vorbelegte 
Variablennamen die Redefinitionen provozieren. Gefällt mir so nicht. Ein 
Bsp. für meinen Nano Every.

[Michael B. (laberkopp)]

Falk B. schrieb:
> Aber denk an deine Zielgruppe! Das sind keine C++ Cracks

Arduino ist C++, der Übersicht wegen. Dafür versteckt sich manches (zu) 
gut.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> Hallo,
>
> wo ich das las dachte ich auch zuerst an C++, auch wegen Arduino. Es
> stecken mir ehrlich gesagt zu viele versteckte defines drin. Vorbelegte
> Variablennamen die Redefinitionen provozieren. Gefällt mir so nicht. Ein
> Bsp. für meinen Nano Every.

Und dies geht nur für den 4809, oder? Wie ist es bspw. mit dem 
AVR128DA28? Was muss ich ändern?

Ich nehme an, dass sonst nicht vom Arduino-Zeug gebraucht wird für Deine 
"Bibliothek"?

Geht das Update auch mit einem Interrupt? Zumindest sehe ich da weder 
vorlatile noch ein disable-interrupts.

[Veit D. (devil-elec)]

Hallo,

du müßtest nur das Headerfile "NanoEveryRegister.h"
libraries\NanoEveryPin\src\include\
abändern bzw. austauschen.

'struct Offset' sollte passen nehme ich an, dass sind die Offsets für 
die Adressenberechnung

Die Basisadressen stehen im Array 'baseAddr'.
Die Reihenfolge der Einträge entspricht der Pinnummerierung des Arduino 
Nano Every.
Die Reihenfolge kannste beim AVRxDA deinen eigenen Wünschen anpassen 
bzw. DxCore kompatibel.

Von Arduino wird nur 'Serial' verwendet.

encode() wird mittels updateEncoder() gepollt.

Wenn man das im Interrupt machen möchte, müßte man encode() zerlegen und 
das hier

uint8_t newPhase {0};                 
                            
if (phaseA.isOn()) { newPhase |= 0b01; }
if (phaseB.isOn()) { newPhase |= 0b10; }

laut erster Überlegung im Interrupt machen und newPhase "zurückgeben". 
Oder gar nur die Pins phaseA.isOn(), phaseB.isOn() einlesen. Ob das 
wirklich was spart müßte man austesten.

Vielleicht ist die Anpassung an AVRxDA mit meiner AVRxDB Pin Lib 
schneller fertig. Ich weiß nicht was du genau vor hast bzw. alles 
umbaust.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> Ich weiß nicht was du genau vor hast bzw. alles
> umbaust.

Ich möchte einfach nur ein laufendes Beispiel mit Deiner Variante auf 
dem DA.

[Veit D. (devil-elec)]

Hallo,

dann nimm die DB Pin Lib, davon das AVRxDB32_PinRegister.h File und 
passe das auf deinen AVRxDA28 an. Bei Bedarf noch ein 
AVRxDA28_PinNamen.h erstellen. Zum Schluss in der zu inkludierenden 
AVRxPin.h entsprechenden define Eintrag ergänzen. Dann sollte das 
laufen.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:

> dann nimm die DB Pin Lib, davon das AVRxDB32_PinRegister.h File und
> passe das auf deinen AVRxDA28 an.

Ich habe mir das mal kurz angesehen, einiges aus dem .ino weggelassen 
(nur ein Encoder benutzt) und eine simple Ausgabe (8 Leds für die 
unteren 8Bit des Zählers) hinzugefügt.

Dabei habe ich natürlich auch in Deine Header reingeschaut, soweit das 
notwendig war. Dabei sind mir die folgenden Dinge aufgefallen:

* Pfadnamen: "/" statt "\\"
* xxxPinRegister.h: es fehlt: #include <stdint.h>
* xxxPin.h: es fehlt #include <avr/io.h>
* self-contained header files (s.o.)
* DA-Series: PORT_INLVL_bm nicht vorhanden
* C-Declaration: z.B. updateEncoder(void)
* fehlende Deklaration: updateEncoder(void)

Aber das war jetzt seeeehr flüchtig.

Dann: wenn schon das für Arduino ist, warum dann nicht auch die 
Funktionen zum Lesen von Pins: digitalRead()?

Mit den Änderungen (wahrscheinlich habe ich in der obigen Liste was 
vergessen) lief das dann auf einem AVR128DA28. Als ich mir jedoch die 
Größe anschaute, traute ich meinen Augen nicht: 1566 text-segment und 18 
bss-segment. Der Grund war hier, dass ich mit O3 kompiliert habe. Ein Os 
brachte dann: 552 text-segment. Das ist schon ein krasser Unterschied 
zwischen Os und O3. Normalerweise ist das für mich ein Indiz, dass der 
Code irgendwelche Leichen im Keller hat. Ein Grund könnte bspw. sein, 
dass Du vor fast jeder Funktion ein  attribute((always_inline)) drin 
hast. Das ist natürlich sehr krass. So etwas macht man nur in gaaanz 
großen Ausnahmefällen, sonst lässt man das den Compiler entscheiden.

Leider ist Deine Version auch nicht für die Verwendung in ISRs 
instrumentiert.

Folgender Vergleich (jeweils text-segment als Indikator):

1) ohne ISR, Pins desselben Ports

          O1    O2    Os    O3
PeDa:     352   346   346   368
Veit:     914   1574  552   1566
Wilhelm:  352   342   342   342

2) ohne ISR, Pins unterschiedlicher Ports

          O1    O2    Os    O3
PeDa:     376   362   362   362
Veit:     914   1574  552   1566
Wilhelm:  374   356   358   356

Die Zahlen mit ISR spare ich mir, weil das mit Deiner Version nicht 
möglich ist.

Angehängt ist meine Version: die habe ich jetzt aus den notwendigen 
Headern einfach zusammen in eine Datei kopiert. Die Version von PeDa aus 
dem Wiki, angepasst auf den DA habe ich jetzt nicht angehängt. 
Allerdings habe ich die Funktionen übersetzungeinheit-global deklariert 
(static), damit bessere Optimierung möglich ist, sonst wäre bspw. in Os 
bei PeDa: 398 text-segment.

Compiliert mit avr-g++-13.2.0, der 14.0.0 schmiert bei Deinem Code mit 
einem ICE ab.

[Gerhard O. (gerhard_)]

Hallo Wilhelm,

Ich bin etwas überrascht, daß Du in Deiner Implementation von pedas 
Encoder Lösung solch extensiven Gebrauch von C++ templates machst.

Pedas brilliantes Beispiel ist ja sehr stark an eine uC HW gekoppelt. 
Man sollte meinen, daß templates Gebrauch hier eigentlich keine 
wesentlichen Vorteil schafft. Das Schreiben der templates headers dürfte 
bestimmt (auch mit copy und paste) einige Zeit benötigt haben.

Sicherlich, der main() code ist dadurch sehr einfach geworden, aber der 
Gesamteindruck ist von hoher Gesamtkomplexität. Irgendwie finde ich das 
aus meiner Sicht etwas Overkill. Ferner glaube ich dann nicht, daß sich 
z.B. Bernd da leicht tun würde.

Ich finde eigentlich, daß pedas Original Lösung wesentlich leichter zu 
überblicken ist. Was mich betrifft, finde ich pedas Programmierlösung 
viel "magerer" und "to the point". Nichts für ungut hier; Deine Lösung 
sieht im Vergleich "ultrakompliziert" aus.

Allerdings muß ich Dir fairerweise (und vll. zähneknirschend:-) ) 
zugestehen, daß Dein Vorschlag platzmässig gewinnt.

Was mich betrifft, finde ich templates etwas gewöhnungsbedürftig, auch 
wenn sie in anderen Situationen recht nützlich sein können. Aber hier?

Wie gesagt, ich bin eher verwundert, um diesen Ansatz. Aber es ist 
sicherlich interessant als Vergleich und Studium. Performant gesehen 
scheint Deine Lösung der klare Gewinner zu sein; zumindest platzmässig.


VG,
Gerhard

[Veit D. (devil-elec)]

Hallo,

Die Antwort an sich ist okay, aber ich weiß gerade nicht wie ich damit 
hier umgehen soll.

> Dabei sind mir die folgenden Dinge aufgefallen:
> * Pfadnamen: "/" statt "\\"
> * xxxPinRegister.h: es fehlt: #include <stdint.h>
> * xxxPin.h: es fehlt #include <avr/io.h>
> * self-contained header files (s.o.)
> * DA-Series: PORT_INLVL_bm nicht vorhanden
> * C-Declaration: z.B. updateEncoder(void)
> * fehlende Deklaration: updateEncoder(void)

Wenn die Zeile
> * DA-Series: PORT_INLVL_bm nicht vorhanden
nicht vorhanden wäre, könnte ich damit auch locker umgehen und es 
erklären. Nur diese Zeile bringt meinen Puls in Wallung. Ich weiß gar 
nicht was mir diese Zeile sagen soll. Du musst doch mitbekommen haben 
das ich keinen DA haben. Ich habe dir extra meine ATmega4809 und AVRxDB 
Pin Lib gegeben damit du es leichter für deinen AVRxDA anpassen kannst. 
Und jetzt stellst du den Vorwurf in den Raum da fehle für deinen DA ein 
Define? Das ist jetzt nicht dein ernst? Das hast du jetzt nicht wirklich 
geschrieben oder?
Außerdem fehlt das bei mir nicht.
void INLINE enableTTL()
void INLINE disableTTL()

Wenn ich das INLINE weglasse wurde glaube ich der Code größer. Irgendwas 
war da und hatte seinen Grund.

digitalRead() ist ggf. zu langsam. Dauert ca. 4µs. Deswegen die eigene 
Pin Lib.

> * Pfadnamen: "/" statt "\\"
Verstehe ich nicht. Ich habe den Backslash überall im Pfad drin.

> * xxxPinRegister.h: es fehlt: #include <stdint.h>
> * xxxPin.h: es fehlt #include <avr/io.h>
> * self-contained header files (s.o.)
Bei Arduino immer dabei bzw. automatisch inkludiert

> * C-Declaration: z.B. updateEncoder(void)
> * fehlende Deklaration: updateEncoder(void)
Erzeugt Arduino automatisch.

> * self-contained header files (s.o.)
Was ist das?

Du verwendest
#include <std/array> und Type Traits
Sollte das Programm nicht ohne C++STL auskommen?

Alle 3 Programme sind nun leider überhaupt nicht vergleichbar. Weil die 
Encoderauswertung unterschiedlich realisiert ist. Ich habe bspw. 
serielle Ausgaben du nicht usw. Deswegen ist der Vergleich mit der 
Codegröße schlichtweg unfair.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> Hallo,
>
> Die Antwort an sich ist okay, aber ich weiß gerade nicht wie ich damit
> hier umgehen soll.
>
>> Dabei sind mir die folgenden Dinge aufgefallen:
>> * Pfadnamen: "/" statt "\\"
>> * xxxPinRegister.h: es fehlt: #include <stdint.h>
>> * xxxPin.h: es fehlt #include <avr/io.h>
>> * self-contained header files (s.o.)
>> * DA-Series: PORT_INLVL_bm nicht vorhanden
>> * C-Declaration: z.B. updateEncoder(void)
>> * fehlende Deklaration: updateEncoder(void)
>
> Wenn die Zeile
>> * DA-Series: PORT_INLVL_bm nicht vorhanden
> nicht vorhanden wäre, könnte ich damit auch locker umgehen und es
> erklären. Nur diese Zeile bringt meinen Puls in Wallung.

Du brauchst gar nicht in Wallung zu kommen. Die Aufzählung beschreibt 
nur die Änderungen, damit Du weißt, was ich gemacht habe.
Bleibt cool ;)

> Wenn ich das INLINE weglasse wurde glaube ich der Code größer. Irgendwas
> war da und hatte seinen Grund.

Mag sein, aber wenn Du das brauchst, damit Dein Code überhaupt in eine 
akzeptable Größenordnung kommt, dann ist irgendwas faul.

>
> digitalRead() ist ggf. zu langsam. Dauert ca. 4µs. Deswegen die eigene
> Pin Lib.

Also doch nicht ganz Arduino.

>
>> * Pfadnamen: "/" statt "\\"
> Verstehe ich nicht. Ich habe den Backslash überall im Pfad drin.

Andersrum: portable-path-names bitte.

>
>> * xxxPinRegister.h: es fehlt: #include <stdint.h>
>> * xxxPin.h: es fehlt #include <avr/io.h>
>> * self-contained header files (s.o.)
> Bei Arduino immer dabei bzw. automatisch inkludiert
>
>> * C-Declaration: z.B. updateEncoder(void)
>> * fehlende Deklaration: updateEncoder(void)
> Erzeugt Arduino automatisch.

Na dannn ...

>
>> * self-contained header files (s.o.)
> Was ist das?

Google mal wieder kaputt?
Headerfiles sollen alles includeren, was sie benötigen, und nicht darauf 
bauen, das der Programmierer sie in der richtigen Reihenfolge 
inkludiert.

> Du verwendest
> #include <std/array>
> Sollte das Programm nicht ohne C++STL auskommen?

Wir haben doch erst kürzlich festgestellt, dass die STL auch für AVR nun 
für jeden verfügbar ist. Also, kein Thema.

Wird aber auch nur für einen Test benötigt ...

> Alle 3 Programme sind nun leider überhaupt nicht vergleichbar. Weil die
> Encoderauswertung unterschiedlich realisiert ist.

Nein, soweit habe ich mir Deine Realisierung schon angesehen: ist 
jedesmal ein gray/binary-Wandler.

> Ich habe bspw.
> serielle Ausgaben du nicht usw. Deswegen ist der Vergleich mit der
> Codegröße schlichtweg unfair.

Och Veit, natürlich habe ich das entfernt - und Dein main() nun 
angehängt.

[Michael B. (laberkopp)]

Veit D. schrieb:
> Ein Bsp. für meinen Nano Every.

Boh ey, Obfurscation ist für dich Sport in dem du Weltmeister werden 
willst. Wohl damit du im Job unkündbar wirst.

Nein, ich überblicke es nicht in der Zeit die es mir wert ist (in jede 
Quelldatei nur ein Mal reingucken, dann die nächste), aber mir scheint, 
um minimalen Geschwindigkeitsgewinn durch templates mit ihren statischen 
Vordefinitionen zu erreichen, opferst du die Flexibilitât einen Pin im 
Programmlauf von Output nach Analog nach Input umzuschalten, dazu muss 
er wohl 3-fach instantiiert werden mit entsprechend aufgeblähtem code.

Und Arduino-typisch favorisierst du Einzelbitzugriff und trotz des 
immensen Definitionsaufwandes gelingt es nicht, effizient byteweisen 
oder mehrbitweisen Zugriff mit deiner Library zu machen.

[Wilhelm M. (wimalopaan)]

Gerhard O. schrieb:
> Hallo Wilhelm,
>
> Ich bin etwas überrascht, daß Du in Deiner Implementation von pedas
> Encoder Lösung solch extensiven Gebrauch von C++ templates machst.

Warum überrascht Dich das. Es ist ein Weg, um zur Compilezeit möglicht 
viel zu erledigen (neben constexpr-Kontexten).

> Pedas brilliantes Beispiel ist ja sehr stark an eine uC HW gekoppelt.

Genau das ist das Problem. Man muss schon recht viel ändern, um bspw. 
zwei Encoder zu verwenden, oder auch einen Encoder mit den Pins an 
unterschiedlichen Ports.

> Man sollte meinen, daß templates Gebrauch hier eigentlich keine
> wesentlichen Vorteil schafft.

template, TMP und compile-time-computation sind gerade im 
Embedded-Bereich sehr wertvoll, weil erstens Testen teuer ist und 
zweitens die Ressourcen knapp sind.

> Das Schreiben der templates headers dürfte
> bestimmt (auch mit copy und paste) einige Zeit benötigt haben.

Das copy: war ja alles schon vorhanden.

> Sicherlich, der main() code ist dadurch sehr einfach geworden, aber der
> Gesamteindruck ist von hoher Gesamtkomplexität.

Veits Lösung hat insgesamt mehr Zeilen.

> Irgendwie finde ich das
> aus meiner Sicht etwas Overkill.

Zwei Sachen sind nicht wirklich nötig: der Gray-Decoder kann nicht nur 
zweistellige Gray-Codes, sondern N-stellig.

Die PinGroup kann auch mehr als zwei Pins und optimiert für Pins an 
demselben Port: muss man nicht machen.

> Ferner glaube ich dann nicht, daß sich
> z.B. Bernd da leicht tun würde.

Für den war das auch nicht gemeint.

> Ich finde eigentlich, daß pedas Original Lösung wesentlich leichter zu
> überblicken ist. Was mich betrifft, finde ich pedas Programmierlösung
> viel "magerer" und "to the point". Nichts für ungut hier; Deine Lösung
> sieht im Vergleich "ultrakompliziert" aus.

Es war auch nicht dafür gedacht, die C-Lösung von PeDa einfacher zu 
machen. C wird erst dann kompliziert, wenn die Programm größer werden. 
Das kann man in diesem Mini-Beispiel nicht erkennen.
Bis auf die Klasse RotaryEncoder ist alles in Bibliotheken versteckt, 
wie bei Arduino. Von daher ist es recht einfach alles.
Das Ziel ist allerdings, schon zur Compilezeit möglichst viele Fehler 
aufzudecken und nicht erst zur Laufzeit.

> Was mich betrifft, finde ich templates etwas gewöhnungsbedürftig, auch
> wenn sie in anderen Situationen recht nützlich sein können. Aber hier?

Gerade hier. Denn µC-Programme lösen oft statische Probleme: der Encoder 
wechselt nicht so oft den Pin zur Laufzeit. Alles, was schon zur 
Compilezeit bekannt ist, sollte man auch so dem Compiler mitgeben. Das 
erleichtert dem Optimizer die Arbeit.

> Wie gesagt, ich bin eher verwundert, um diesen Ansatz.

Mag sein, viele andere nicht.

> Aber es ist
> sicherlich interessant als Vergleich und Studium.

Nur dafür ist es gedacht.

> Performant gesehen
> scheint Deine Lösung der klare Gewinner zu sein; zumindest platzmässig.

[Veit D. (devil-elec)]

Hallo,

wegen dem INLINE schaue ich nochmal nach wie sich das auswirkte, dann 
können wir nochmal darüber reden.

>>> * self-contained header files (s.o.)
>> Was ist das?

> Google mal wieder kaputt?
> Headerfiles sollen alles includieren, was sie benötigen, und nicht darauf
> bauen, das der Programmierer sie in der richtigen Reihenfolge
> inkludiert.

Der Münzautomat ist kaputt.  ;-)

Wie man es macht ist es falsch. Im Arduino Forum bekam ich auf die 
Fresse, weil ich alles jeweils benötigte in den Headerfiles stehen hab - 
quasi versteckt. Vorwurf, niemand kann sehen was alles an Libs benötigt 
wird. Du möchtest es anders herum haben. Ich kann es niemanden recht 
machen.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> Im Arduino Forum bekam ich auf die
> Fresse, weil ich alles jeweils benötigte in den Headerfiles stehen hab -
> quasi versteckt.

Hier geht es aber um die Dinge, die immer das sind wie stdint.h oder 
avr/io.h.
Wenn Du abhängig von anderen 3rd-party libs ist, ist das eine andere 
Sache.

Und wie gesagt: ein Code, der so "atmet" beim Ändern der Optimierungen, 
ist für mich sehr "verdächtig".

[Veit D. (devil-elec)]

Hallo,

wegen dem Pfad nochmal. Ich komme noch nicht mit was du genau möchtest. 
Du möchtest relative Pfade?
Backslash nutze, sollte auch für Linux passen.
Relativen Pfad habe ich für meines Erachtens auch.
Bsp.:  #include "include\AVRxDB64_PinRegister.h"
Ich weiß aktuell nicht was genau falsch ist?
Falls du verlangen solltest das ich alles noch für Linux teste wäre das 
etwas zu viel verlangt.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> wegen dem Pfad nochmal. Ich komme noch nicht mit was du genau möchtest.

Ich möchte gar nichts: der Compiler möchte ;-)

Backslashes sind in Pfadnamen in C++ implementation-defined, die meisten 
interpretieren das als escape-sequence, mit der Folge, dass die DAtei 
natürlich mit dem gescrambelten Namen nicht gefunden wird.

Also: forslash "/", sollte gcc auf Windoofs auch verstehen.

[Veit D. (devil-elec)]

Hallo,

ach so, ne, mit dem Compiler hat das nichts zu tun. Das ist so ein 
Windows <> Linux Ding mit der Pfadschreibweise. Das Problem taucht immer 
wieder einmal auf wenn man nicht daran denkt. Ich ändere das.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> ach so, ne, mit dem Compiler hat das nichts zu tun. Das ist so ein
> Windows <> Linux Ding mit der Pfadschreibweise.

Doch. Schau in den C/C++-Standard, habe ich oben aus dem Gedächtnis 
zitiert. Zwischen dem Text und der Plattform Windows/*nix ist halt noch 
der Compiler dazwischen.

[Veit D. (devil-elec)]

Hallo,

wenn dem so wäre könnte ich mit meiner falschen Pfadschreibweise unter 
Windows nichts kompilieren. Ich kann aber unter Windows mit / und \ 
meine Libs kompilieren. Wir müssen das aber nicht weiter ausufern 
lassen. / und gut ist.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> wenn dem so wäre könnte ich mit meiner falschen Pfadschreibweise unter
> Windows nichts kompilieren.

Nein, es ist halt implementation-defined. Und das heißt nicht, dass es 
nicht geht. Schau in der Doku Deines Compilers für Dein Plattform nach.

[Veit D. (devil-elec)]

Hallo,

rein meine Logik sagt mir was anderes. Wenn es implementation-defined 
ist und wir den gleichen avr-gcc verwenden und der Einzigste Unterschied 
zwischen uns Windows vs. Linux ist, woran wird es dann wohl liegen? Wenn 
implementation-defined vom OS abhängt bin ich auch wieder beim 
Unterschied Windows vs. Linux. Kann man drehen wie man will. Man landet 
immer beim OS.

[Joachim B. (jar)]

Veit D. schrieb:
> Ich kann aber unter Windows mit / und \
> meine Libs kompilieren. Wir müssen das aber nicht weiter ausufern
> lassen. / und gut ist.

ich kann es auch

    if(strlen_P(MainName)) {
      uint16_t c_count2=strlen_P(MainName);
      String Ausgabe_pfad_String="";
      Ausgabe_pfad_String.reserve(c_count2+2);
      char *c_home2=(char*)MainName;
Serial.println(c_count2);
Serial.println(c_count2+2);
      
      c_home2=(char*)MainName;
      while(pgm_read_byte(c_home2)) Ausgabe_pfad_String += (char)pgm_read_byte(c_home2++);
      if( (Ausgabe_pfad_String.lastIndexOf('/')) >0 ) // raspi buster
        Ausgabe_pfad_String.remove(Ausgabe_pfad_String.lastIndexOf('/'));   // Remove from from index=7 through the end of the string
      if( (Ausgabe_pfad_String.lastIndexOf('\\')) >0 ) // windows backslash
        Ausgabe_pfad_String.remove(Ausgabe_pfad_String.lastIndexOf('\\'));   // Remove from from index=7 through the end of the string
      Serial.print(F("Pfad:     ")); Serial.print(Ausgabe_pfad_String);
      if(Ausgabe_pfad_String.substring(0,2) == "A:")
        Serial.println(F("\\, auf win7 kompiliert"));
      if(Ausgabe_pfad_String.substring(0,4) == "/mnt")
        Serial.println(F("/, auf PI3 mit buster kompiliert"));
      //Ausgabe_pfad_String.lastIndexOf('/');
    }

[Wilhelm M. (wimalopaan)]

Joachim B. schrieb:
> ich kann es auch

Naja, was Du beschreibst ist der Umgang mit Escape-Sequenzen in 
String-Literalen (s-char-sequence). Dort ist \ der escape-char, und die 
Bedeutung des folgenden Zeichens wird umgeschaltet.

Hier ging es aber um Header-Namen, das ist was anderes.

In q-char- oder h-char-sequence (Namen von Header-Files) ist das aber 
anders.

Etwas verkürzt:
- die Bedeutung des \ kann unterstützt sein mit implementation-defined 
behaviour.
- die Auflösung der q-char oder h-char-sequence in einen Pfadnamen ist 
ebenfalls implementation defined.

[Joachim B. (jar)]

Wilhelm M. schrieb:
> Hier ging es aber um Header-Namen, das ist was anderes.

mag sein aber trotzdem gut zu wissen ob ein Arduino unter Raspbian/Linux 
oder unter windows PC kompiliert wurde.

[Wilhelm M. (wimalopaan)]

Joachim B. schrieb:
> aber trotzdem gut zu wissen ob ein Arduino unter Raspbian/Linux
> oder unter windows PC kompiliert wurde.

Und wozu brauchst Du das?

[Joachim B. (jar)]

Wilhelm M. schrieb:
> Joachim B. schrieb:
>> aber trotzdem gut zu wissen ob ein Arduino unter Raspbian/Linux
>> oder unter windows PC kompiliert wurde.
>
> Und wozu brauchst Du das?

um die Librarys kompatibel zu halten und um zu sehen wann ich wann wo 
die letzte Version kompiliert hatte.
Es ist ein wenig nervig seine eigenen Programme unter den vorhandenen 
Rechnern immer kompilierbar zu halten.
Man lernt ja immer mehr dazu und es kommen noch neue Ideen und manchmal 
streikt ein Rechner und man hat andere Baustellen zu bedienen.
Wenn eine neue Idee reift will man die auch gleich umsetzen bevor sie 
wieder aus den Augen aus dem Sinn ist.

Quellen und LIBs liegen auf dem NAS.

[Wilhelm M. (wimalopaan)]

Joachim B. schrieb:
> Quellen und LIBs liegen auf dem NAS.

Gerade deswegen erscheint mir das recht "strange", was Du da machst.

[Joachim B. (jar)]

Wilhelm M. schrieb:
> Gerade deswegen erscheint mir das recht "strange", was Du da machst.

och was soll mich das stören?

Ich verstehe auch nicht ALLE andere Menschen, jeder Jeck tickt anders 
oder jedem Tierchen sein Pläsierchen.

Es nervt mich auch wenn die Arduino IDE und der GCC immer neu umgestellt 
wird so das LIBs nicht mehr laufen wie bei der Erstinstallation nach 3 
Jahren und man immer in den LIBs rumwühlen muss warum sie nun genau 
nicht mehr laufen.

[Gerhard O. (gerhard_)]

Joachim B. schrieb:
> Wilhelm M. schrieb:
>> Gerade deswegen erscheint mir das recht "strange", was Du da machst.
>
> och was soll mich das stören?
>
> Ich verstehe auch nicht ALLE andere Menschen, jeder Jeck tickt anders
> oder jedem Tierchen sein Pläsierchen.
>
> Es nervt mich auch wenn die Arduino IDE und der GCC immer neu umgestellt
> wird so das LIBs nicht mehr laufen wie bei der Erstinstallation nach 3
> Jahren und man immer in den LIBs rumwühlen muss warum sie nun genau
> nicht mehr laufen.

Moin,

Ich hatte dasselbe Problem, daß neuere Versionen des Compilers alte 
Projekte "brechen". Z.B. die schlanke ASM I2C Soft Master Lib, lässt 
sich in der aktuellen Version nicht mehr richtig kompilieren.

Um das Problem zu lösen fertigte ich eine "Portabel Version" des IDEs an 
(V1.8.9) und archivierte dieses Package. Das läuft nun auf einem USB 
Stick auf jedem Windows PC ohne Schwierigkeiten. Dieses Package 
verwendet nun nur noch GCC V5.4.0 mit einer bestimmten Bord Package 
Version.

Man kann dieses Problem auch auf eine andere Weise lösen. Man darf nicht 
die Bord Package Version ohne triftigen Grund aktualisieren, weil dieses 
BordPackage auch die Compiler Version bestimmt. Wenn man also vor Jahren 
z.B. Bordversion XYZ verwendet mit GCC V5.4.0., dann muß man sich in der 
Source notieren, welche Bordvesion danals gesetzt war.

Wenn man ein neueres Bord Package einstellt, dann wird auch der neueste 
offizielle GCC bestimmt, z.B. V7.0.0. Das bricht dann unter Umständen 
die alten Projekte. Um das zu verhindern braucht man nur das  Bord 
Package mit dem Bord Manager zurückstellen. Dann funktioniert es wieder.

Unter den Compiler Versionen im IDE Baum findet nan nun GCC V7.0.0 und 
V5.4.0.

Ich habe mich aber für die aktuelle Version und eine zweite installierte 
Portable Version entschieden, anstatt andauernd das Bord Package hin und 
her zu installieren.

Aber vielleicht gibt es bessere Lösungen dazu. Für mich funktioniert es 
aber immer noch so wie vor vielen Jahren.

Gerhard

[Wilhelm M. (wimalopaan)]

Gerhard O. schrieb:
> Ich hatte dasselbe Problem, daß neuere Versionen des Compilers alte
> Projekte "brechen". Z.B. die schlanke ASM I2C Soft Master Lib, lässt
> sich in der aktuellen Version nicht mehr richtig kompilieren.

Weil hier ja die Rede von "Arduino" ist, denke ich, dass es sich dabei 
um den gcc (avr-gcc ?) handelt. Normalerweise wird der gcc (die 
Compiler) im Laufe der Zeit immer "standard-konformer" und findet auch 
mehr Fehler. Insgesamt also ein Indiz dafür, dass nicht der Compiler das 
Problem ist, sondern diese Bibliothek. Gut, da es ASM ist, ist es eh 
neben dem Standard. Gibt es nichts vernünftiges in C / C++ / Arduino? 
Wenn Du deswegen Deine Compiler alt halten musst, würde ich mir mal 
Gedanken machen.

Gerhard O. schrieb:
> Man kann dieses Problem auch auf eine andere Weise lösen. Man darf nicht
> die Bord Package Version ohne triftigen Grund aktualisieren, weil dieses
> BordPackage auch die Compiler Version bestimmt.

Die Compiler-Version festzulegen, ist Aufgabe des Projektes, also der 
Config des verwendeten Build-Tools wie make, cmake, ninja, b2, ...

[Wilhelm M. (wimalopaan)]

Joachim B. schrieb:
> och was soll mich das stören?

Am besten: gar nicht.

Aber warum machst Du denn diese Ganze Pfad-Akrobatik auf dem Arduino. 
Dies notwendige Info (verwendeter Compiler, Bibliotheksversionen, ...) 
kannst Du doch in ein / paar Bytes codieren.

[Gerhard O. (gerhard_)]

Wilhelm M. schrieb:
> Gerhard O. schrieb:
>> Ich hatte dasselbe Problem, daß neuere Versionen des Compilers alte
>> Projekte "brechen". Z.B. die schlanke ASM I2C Soft Master Lib, lässt
>> sich in der aktuellen Version nicht mehr richtig kompilieren.
>
> Weil hier ja die Rede von "Arduino" ist, denke ich, dass es sich dabei
> um den gcc (avr-gcc ?) handelt. Normalerweise wird der gcc (die
> Compiler) im Laufe der Zeit immer "standard-konformer" und findet auch
> mehr Fehler. Insgesamt also ein Indiz dafür, dass nicht der Compiler das
> Problem ist, sondern diese Bibliothek. Gut, da es ASM ist, ist es eh
> neben dem Standard. Gibt es nichts vernünftiges in C / C++ / Arduino?
> Wenn Du deswegen Deine Compiler alt halten musst, würde ich mir mal
> Gedanken machen.
>
> Gerhard O. schrieb:
>> Man kann dieses Problem auch auf eine andere Weise lösen. Man darf nicht
>> die Bord Package Version ohne triftigen Grund aktualisieren, weil dieses
>> BordPackage auch die Compiler Version bestimmt.
>
> Die Compiler-Version festzulegen, ist Aufgabe des Projektes, also der
> Config des verwendeten Build-Tools wie make, cmake, ninja, b2, ...

Hallo Wilhelm,

Ich mache das nur, wenn ich in der Arduino IDE die ASM Bibliothek aus 
anwendungsbedingten Gründen verwenden will. Für alles Andere, schreibe 
ich meine Projekte so, um konform mit dem aktuellen Tools zu sein. Das 
andere ist also alles nur "Legacy".

Diese ASM Bib ist sehr schlank und erlaubt andere IO-Pins anstatt der 
üblichen HW I2C Pins zu wählen. Ich machte mit dieser bis jetzt sonst 
sehr gute Erfahrungen.

Es kommt vor, daß hin und wieder an älteren Projekten weitergearbeitet 
wird um an neuen Funktionen oder Bugfixes zu arbeiten. Da hat es mehr 
Sinn mit den Original konfigurierten Werkzeugen mit denen Entwicklung 
begonnen wurde zu arbeiten.

Wenn ich nicht mit avr-gcc arbeite, verwende ich übrigens CVAVR.

Da ich auch mit anderen uC diverser Hersteller hin und wieder arbeite, 
die ihre eigenen Werkzeuge haben und schon betagt sind, beschränke ich 
mich nach Möglichkeit deshalb auf reines C, um so weit wie möglich 
Portabel zu sein. Deshalb vermisse ich C++ nicht zu sehr, auch wenn 
Manches in C++ eleganter verwirklichbar ist.

Ich arbeite hin und wieder noch mit PICs, Z8 Encore! und moderneren 
8051ern. Auch mit MSP430 gibt es ab und zu noch Projekte durchzuziehen. 
In meinem Umfeld müssen ältere Designs von Zeit zu Zeit noch gepflegt 
werden.

Ich bin leider beruflich nur kommerzielle Entwicklungswerkzeuge gewöhnt 
und schlage Hobbymässig eigentlich nur mit Arduino und sein avr-gcc aus 
der Art, obwohl STM32 mit dem Atollic Tools natürlich auch gcc verwandt 
ist. Aber mit dem machte ich schon 10 Jahre kaum noch etwas. Und wenn, 
dann heutzutage mit Cube IDE . In der Arbeit muß ich an den ARM7 Cortex 
Projekten mit IAR arbeiten. Deshalb kenne ich die besonderen 
Fähigkeiten von gcc nur in beschränkten Umfang.

Die Natur meiner Hobby Projekte ist im Allgemeinen so, daß ich mit 
Acht-Bittern generell gut auskomme, und wenn nicht, es mit STM32ern 
löse.

Ich bin eben ein ganz schwieriger, ausgefallener Fall:-)

Gerhard

[Wilhelm M. (wimalopaan)]

Gerhard O. schrieb:
> Diese ASM Bib ist sehr schlank und erlaubt andere IO-Pins anstatt der
> üblichen HW I2C Pins zu wählen.

Wohl doch aber nur auf µC, die kein Port-Mux / Alternate-Function haben, 
oder? Denn so stark kann der Raumdruck kaum sein.

Gerhard O. schrieb:
> Es kommt vor, daß hin und wieder an älteren Projekten weitergearbeitet
> wird um an neuen Funktionen oder Bugfixes zu arbeiten. Da hat es mehr
> Sinn mit den Original konfigurierten Werkzeugen mit denen Entwicklung
> begonnen wurde zu arbeiten.

Klaro. Das machen wir mit docker.

Gerhard O. schrieb:
> Deshalb vermisse ich C++ nicht zu sehr, auch wenn
> Manches in C++ eleganter verwirklichbar ist.

Bei mir ist es genau anders herum ;-) Frei nach dem Motto "Stop using 
C", wobei dieser Spruch von K. Gregory ja so gemeint ist, das man 
aufhören sollte, "konzeptionell" so wie in simpelstem C zu 
programmieren.

Gerhard O. schrieb:
> Ich arbeite hin und wieder noch mit PICs, Z8 Encore! und moderneren
> 8051ern. Auch mit MSP430 gibt es ab und zu noch Projekte durchzuziehen.

Zum Glück bin ich die los ;-)
Neben den Miniprojekten auf AVR ist es nur noch ARM als STM (wobei die 
CPU-Architektur natürlich unwichtig ist). Und so ist es auch privat ;-)

Gerhard O. schrieb:
> Ich bin eben ein ganz schwieriger, ausgefallener Fall:-)

Schaut so aus, wie wir alle hier ;-)