Siehe Anhang. Damit kann man eigene Projekte mit den bekannten und bewährten Methoden hier aus dem Forum ausstatten. Viel Spaß damit.
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".
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
:
Bearbeitet durch User
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.
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!
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.
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.
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.
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
1 | uint8_t newPhase {0}; |
2 | |
3 | if (phaseA.isOn()) { newPhase |= 0b01; } |
4 | 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.
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.
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.
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
1 | O1 O2 Os O3 |
2 | PeDa: 352 346 346 368 |
3 | Veit: 914 1574 552 1566 |
4 | Wilhelm: 352 342 342 342 |
2) ohne ISR, Pins unterschiedlicher Ports
1 | O1 O2 Os O3 |
2 | PeDa: 376 362 362 362 |
3 | Veit: 914 1574 552 1566 |
4 | 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.
:
Bearbeitet durch User
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
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.
:
Bearbeitet durch User
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.
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.
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.
:
Bearbeitet durch User
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.
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".
:
Bearbeitet durch User
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.
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.
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.
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.
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.
:
Bearbeitet durch User
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.
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.
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
1 | if(strlen_P(MainName)) { |
2 | uint16_t c_count2=strlen_P(MainName); |
3 | String Ausgabe_pfad_String=""; |
4 | Ausgabe_pfad_String.reserve(c_count2+2); |
5 | char *c_home2=(char*)MainName; |
6 | Serial.println(c_count2); |
7 | Serial.println(c_count2+2); |
8 | |
9 | c_home2=(char*)MainName; |
10 | while(pgm_read_byte(c_home2)) Ausgabe_pfad_String += (char)pgm_read_byte(c_home2++); |
11 | if( (Ausgabe_pfad_String.lastIndexOf('/')) >0 ) // raspi buster |
12 | Ausgabe_pfad_String.remove(Ausgabe_pfad_String.lastIndexOf('/')); // Remove from from index=7 through the end of the string |
13 | if( (Ausgabe_pfad_String.lastIndexOf('\\')) >0 ) // windows backslash |
14 | Ausgabe_pfad_String.remove(Ausgabe_pfad_String.lastIndexOf('\\')); // Remove from from index=7 through the end of the string |
15 | Serial.print(F("Pfad: ")); Serial.print(Ausgabe_pfad_String); |
16 | if(Ausgabe_pfad_String.substring(0,2) == "A:") |
17 | Serial.println(F("\\, auf win7 kompiliert")); |
18 | if(Ausgabe_pfad_String.substring(0,4) == "/mnt") |
19 | Serial.println(F("/, auf PI3 mit buster kompiliert")); |
20 | //Ausgabe_pfad_String.lastIndexOf('/');
|
21 | }
|
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.
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.
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?
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.
:
Bearbeitet durch User
Joachim B. schrieb: > Quellen und LIBs liegen auf dem NAS. Gerade deswegen erscheint mir das recht "strange", was Du da machst.
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.
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
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, ...
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.
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
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 ;-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.