Kolja schrieb:> Joachim B. schrieb:> Ich denke, du willst GCC installieren?
nein, in der Arduino IDE austauschen von 4.9.2 zu 4.3.2
Helmut H. schrieb:> Die gewünschte Version ist vom August 2008, siehe> https://gcc.gnu.org/releases.html> Da bleibt also nur selbst bauen, das scheint aber nicht trivial zu sein:
genau deswegen frage ich ja hier, bin kein Softie und will mich nicht
ständig auf Nebenschauplätzen verzetteln.
Joachim B. schrieb:> genau deswegen frage ich ja hier, bin kein Softie und will mich nicht> ständig auf Nebenschauplätzen verzetteln
Dann update den PC und gut.
wendelsberg
Joachim B. schrieb:> nur die 4.9.2 und die ist> inkompatibel zu meinen Programmen
ist es nicht sinnvoller das Programm anzupassen, vermutlich sind es
sogar Bugs die der neue Compiler in findet.
Vielleicht mal probieren eine alte Version zu verwenden. Also gezielt
alte Pakete besorgen und diese dann nicht mehr zu aktualisieren.
Das kann aber zu einer Downgradeorgie führen wo man von Höckschen auf
Stöcksken hüpft.
Oder eine separate Raspbianinstallation mit altem Stand auf einer
separaten Partition oder SDKarte?
Wenn es wirklich den Aufwand wert ist würde ich persönlich versuchen in
einem chroot die GCC-Version zu bauen und mit dieser dann ein
gleichaltes "arduino"-paket und was dazugehört. Wenn Du sowas schonmal
gemacht hast ist das in einem Tag erledigt.
Peter II schrieb:> ist es nicht sinnvoller das Programm anzupassen, vermutlich sind es> sogar Bugs die der neue Compiler in findet.
könnte man denken, aber es ist ja nicht nur ein Programm und das nervt,
Coder der seit Jahren in allen Programmen einwandfrei ist soll nun
plötzlich wegen Krümelka**erei der des gcc fehlerhaft sein?
Pointer auf Array von Array of Chars wird nun angemeckert weil char_var
=! &char_var[0] uvam.
Das war ja noch verständlich, aber wenn
"error: a function-definition is not allowed here before '{' token"
im 4.9.2 kommt und der Code in 4.3.2 funktioniert
Das nervt mich etwas.
Chris F. schrieb:> Wenn es wirklich den Aufwand wert ist würde ich persönlich versuchen in> einem chroot die GCC-Version zu bauen und mit dieser dann ein> gleichaltes "arduino"-paket und was dazugehört. Wenn Du sowas schonmal> gemacht hast ist das in einem Tag erledigt.
ja muss ich wohl, oder cross compiling auf dem PI vergessen!
Harry L. schrieb:> Joachim B. schrieb:>> cross compiling auf dem PI vergessen!>> broken by design....
hat schon Gründe nur verstehe ich deine Antwort nicht, Hauptsache drüber
geredet :)
Joachim B. schrieb:> könnte man denken, aber es ist ja nicht nur ein Programm und das nervt,> Coder der seit Jahren in allen Programmen einwandfrei ist soll nun> plötzlich wegen Krümelka**erei der des gcc fehlerhaft sein?
Das ist zwar sicher ärgerlich, kommt trotzdem vor.
> im 4.9.2 kommt und der Code in 4.3.2 funktioniert> Das nervt mich etwas.
Und statt Deinen Code zu korrigieren, möchtest Du Dich für den Rest
Deines Lebens an eine uralte Version genau eines einzigen Compilers
binden? Das erscheint mir keine sehr zielführende Strategie zu sein.
> ja muss ich wohl, oder cross compiling auf dem PI vergessen!
Warum willst Du denn auf einem leistungsschwachen Pi crosscompilen? Dein
PC kann das doch wesentlich schneller. Sogar, wenn er genauso alt ist
wie die Compilerversion, die Du darauf benutzt.
Joachim B. schrieb:> Pointer auf Array von Array of Chars wird nun angemeckert weil char_var> =! &char_var[0] uvam.>> Das war ja noch verständlich, aber wenn "error: a function-definition is> not allowed here before '{' token"> im 4.9.2 kommt und der Code in 4.3.2 funktioniert> Das nervt mich etwas.
Zeig' mal Codebeispiele für beides.
Manches lässt sich durch Compileroptionen abklemmen, manches ist ...
vielleicht auch wirklich falsch, und wurde nur bislang toleriert?
Joachim B. schrieb:> am PC nutze ich avr-gcc 4.3.2
Ist vermutlich ein WinAVR, und kein avr-gcc, der direkt aus den Quellen
erzeugt ist. Damals[tm] gab es einen Zoo foll Patches, um alle
möglichen Probleme, Bugs, etc, zu beheben.
Die 4.9.2 hat hingegen bereits alle verfügbaren Bugfixes in den
GNU-Quellen.
Wenn du also wirklich die 4.3.2 zu brauchen glaubst und verwenden willst
-- wovon ich abrate -- solltest du dir zunächst alle Patches besorgen
und anwenden bevor du mir der Generierung anfängst.
Sheeva P. schrieb:> Warum willst Du denn auf einem leistungsschwachen Pi crosscompilen? Dein> PC kann das doch wesentlich schneller. Sogar, wenn er genauso alt ist> wie die Compilerversion, die Du darauf benutzt.
Auf einem PC ist es aber kein einfacher Cross-Build, sondern ein
Canadian Cross: Build-Plattform (PC), Host-Plattform (Pi) und Target
(AVR) sind alle verschieden.
Zunächst braucht man also einen Build->Host Umgebung und zusätzlich eine
Build->Target Umgebung (letztere für die Target-Libs). Wenn man diese
hat, kann man an Generierung von Host->Target auf Build anfangen.
Sheeva P. schrieb:> Und statt Deinen Code zu korrigieren, möchtest Du Dich für den Rest> Deines Lebens an eine uralte Version genau eines einzigen Compilers> binden?
ja lieber als den Rest meines Lebens immer nur alten Code zu
korrigieren!
> Das erscheint mir keine sehr zielführende Strategie zu sein.
nun ja jeder mit begrenzter (Restlebens)Zeit mag das anders sehen.
> Warum willst Du denn auf einem leistungsschwachen Pi crosscompilen? Dein> PC kann das doch wesentlich schneller. Sogar, wenn er genauso alt ist> wie die Compilerversion, die Du darauf benutzt.
der PI ist 24/7 on bei geringem "Stromverbrauch" den PC aus der Ferne
hochzufahren ist zwar möglich aber das Umstecken vom USB ist
schwieriger.
Rufus Τ. F. schrieb:> Zeig' mal Codebeispiele für beides.
Einen Fehler konnte ich ja schon korrigieren, aber nerven tuts trotzdem
1
// prog_char string_0[] PROGMEM = "String 0"; // "String 0" etc are strings to store - change to suit.
hier nicht, alle Arten von const versucht zu casten aber wohl nie
richtig.
> Manches lässt sich durch Compileroptionen abklemmen, manches ist ...> vielleicht auch wirklich falsch, und wurde nur bislang toleriert?
mag sein, aber z.B. ein array of array of chars ist einfach nur ein
Array von Chars und zweidimensional immer noch ein Array von Bytes
und wenn der in einer Funktion char charvar[irgendwas]; char*
myfunc(char* charvar) ein Problem mit return charvar; hat ist das eher
sein Problem als meines.
Ich weiss besser wäre es es richtig zu machen, nur warum haben die
Programmiergötter es vorher zugelassen und nun nicht mehr?
Und wer wie ich gerne LIBs nutzt, muss ich die auch alle korrigieren
wenn sie vorher funktionierten?
Joachim B. schrieb:> Ich weiss besser wäre es es richtig zu machen, nur warum haben die> Programmiergötter es vorher zugelassen und nun nicht mehr?
sie haben es nicht zugelassen, nur der Compiler hat noch nicht gewarnt.
Peter II schrieb:> Joachim B. schrieb:>> Ich weiss besser wäre es es richtig zu machen, nur warum haben die>> Programmiergötter es vorher zugelassen und nun nicht mehr?>> sie haben es nicht zugelassen, nur der Compiler hat noch nicht gewarnt.
dann haben die Compilerprogrammiergötter schlicht versagt
LIBs interessieren mich nur im Detail wenn ich sie nutzen will und es
klemmt, z.B. fastled auf dem ATmega 1284p, dort dauerte ein
Adresszugriff 10% mehr weil nun 3 Adressbytes im Spiel sind statt 2 ergo
musste ich dem in der LIB in delay.h ein #if defined ATmega1284p zufügen
Joachim B. schrieb:> ja lieber als den Rest meines Lebens immer nur alten Code zu> korrigieren!
als der avr-gcc noch neu war war viel Bewegung drin, mittlerweile hat
sich das gesetzt. Ich glaube nicht daß jetzt wo der letzte Abschnitt der
AVR-Ära beginnt (der Teil in dem er nur noch altert und Staub ansetzt)
noch jemand auf die Idee kommt den avr-gcc samt seiner libs erneut von
Grund auf umzukrempeln. Also bring Deinen Code noch ein letztes Mal auf
den aktuellen Stand und das sollte dann reichen bis ans Ender aller
Tage.
Bernd K. schrieb:> Also bring Deinen Code noch ein letztes Mal auf> den aktuellen Stand und das sollte dann reichen bis ans Ender aller> Tage.
wie denn?
nicht gelesen?
Joachim B. schrieb:> Einen Fehler konnte ich ja schon korrigieren, aber nerven tuts trotzdem> // prog_char string_0[] PROGMEM = "String 0"; // "String 0" etc are> strings to store - change to suit.> prog_char mo0[] PROGMEM = " "; prog_char mo1[] PROGMEM = "Jan";> prog_char mo2[] PROGMEM = "Feb";> prog_char mo3[] PROGMEM = "Mar"; prog_char mo4[] PROGMEM = "Apr";> prog_char mo5[] PROGMEM = "May";> prog_char mo6[] PROGMEM = "Jun"; prog_char mo7[] PROGMEM = "Jul";> prog_char mo8[] PROGMEM = "Aug";> prog_char mo9[] PROGMEM = "Sep"; prog_char mo10[] PROGMEM = "Oct";> prog_char mo11[] PROGMEM = "Nov";> prog_char mo12[] PROGMEM = "Dec";>> hier meckert der Compiler unnötig über fehlende const
konnte ich beheben!
> // Then set up a table to refer to your strings.> //const char* const string_table[] PROGMEM = {string_0, string_1,> string_2, string_3, string_4, string_5};> const char* const mo_table[] PROGMEM = { mo0, mo1, mo2, mo3, mo4, mo5,> mo6, mo7, mo8, mo9, mo10, mo11, mo12 };
konnte ich NICHT beheben
alle Arten von const versucht zu casten aber wohl nie richtig.
und das hält mich von den eigentlichen Programmfortschritten ja ab.
Aus dem Bauch raus würde ich mal sagen daß mo0 (undsoweiter)
wahrscheinlich keine wirklichen char* sind sondern irgend was anderes,
versteckt hinter dem PROGMEM-Hokuspokus. Harvard lässt grüßen.
und "meckert über const" und "kann ich nicht beheben" sind natürlich
unglaublich aussagekräftige Fehlermeldungen, was hast Du am Compiler
eingestellt daß er solche umgangssprachlichen Unmutsbekundungen anstelle
der normalerweise recht präzisen Fehlermeldungen ausspuckt?
Bernd K. schrieb:> und "meckert über const" und "kann ich nicht beheben" sind natürlich> unglaublich aussagekräftige Fehlermeldungen, was hast Du am Compiler> eingestellt
kann ich später ausführlich zeigen, gerade keinen PI zur Hand.
Eingestellt habe ich am Compiler nichts, nur sudo apt-get install
veranlasst und dann die IDE gestartet.
Joachim B. schrieb:> Joachim B. schrieb:>> Einen Fehler konnte ich ja schon korrigieren, aber nerven tuts trotzdem>> // prog_char string_0[] PROGMEM = "String 0"; // "String 0" etc are>> strings to store - change to suit.>> prog_char mo0[] PROGMEM = " "; prog_char mo1[] PROGMEM = "Jan";>> prog_char mo2[] PROGMEM = "Feb";>> prog_char mo3[] PROGMEM = "Mar"; prog_char mo4[] PROGMEM = "Apr";>> prog_char mo5[] PROGMEM = "May";>> prog_char mo6[] PROGMEM = "Jun"; prog_char mo7[] PROGMEM = "Jul";>> prog_char mo8[] PROGMEM = "Aug";>> prog_char mo9[] PROGMEM = "Sep"; prog_char mo10[] PROGMEM = "Oct";>> prog_char mo11[] PROGMEM = "Nov";>> prog_char mo12[] PROGMEM = "Dec";>>>> hier meckert der Compiler unnötig über fehlende const>> konnte ich beheben!>>> // Then set up a table to refer to your strings.>> //const char* const string_table[] PROGMEM = {string_0, string_1,>> string_2, string_3, string_4, string_5};>> const char* const mo_table[] PROGMEM = { mo0, mo1, mo2, mo3, mo4, mo5,>> mo6, mo7, mo8, mo9, mo10, mo11, mo12 };>> konnte ich NICHT beheben> alle Arten von const versucht zu casten aber wohl nie richtig.
Das schaff sogar ich:
Bernd K. schrieb:> Also bring Deinen Code noch ein letztes Mal auf> den aktuellen Stand und das sollte dann reichen bis ans Ender aller> Tage.
vielleicht sollte ich das mal tun,
bin ja schon etwas weiter:
er bemeckerte in einer Funktion
1
char*func(char*var)
tatsächlich ein
1
return"fehler";
mit
1
return(char*)"fehler";
ist der Compiler wieder glücklich
dann passte dem Herrn Compiler nicht das man eine lokale Var zurück gibt
die nicht static ist, klar da bin ich auch öfter reingefallen weil sie
nach dem Verlassen der func nicht mehr existierte.
Normalerweise versuche ich ja sauber zu programmieren, aber nun in jeder
LIB Fehler zu bereinigen macht keinen Spass, erst recht nicht wenn ich
die gesamte Programmierung der LIB nicht mehr überblicke.
Manchmal möchte man LIBs nur benutzen und nicht korrigieren :)
Schon mal -fpermissive beim Kompilieren versucht?
Aus dem Handbuch:
-fpermissive
Downgrade some diagnostics about nonconformant code from
errors to warnings. Thus, using -fpermissive allows some nonconforming
code to compile.
Edit:
Folgendes schluckt avr-gcc (6.3.0) übrigens ganz ohne Fehler oder
Warnung:
Matthias H. schrieb:> Schon mal -fpermissive beim Kompilieren versucht?
kenne ich noch nicht, weiss nicht mal wo ich da ändern müsste.
aber momentan meldet der Compi mit meiner Portabelinstallation 1.8.2:
Joachim B. schrieb:> dann passte dem Herrn Compiler nicht das man eine lokale Var zurück gibt> die nicht static ist, klar da bin ich auch öfter reingefallen weil sie> nach dem Verlassen der func nicht mehr existierte.
Du solltest froh sein, dass der neue GCC diesen eindeutigen
Programmierfehler nicht mehr zulässt. Dein Programm hat schon immer nur
durch Zufall funktioniert.
MaWin schrieb:> Du solltest froh sein, dass der neue GCC diesen eindeutigen> Programmierfehler nicht mehr zulässt. Dein Programm hat schon immer nur> durch Zufall funktioniert.
wieso kommst du aus dem Mustopp?
ach ja du bist alt oder ein Troll, dieser sogenannte "Fehler" ist doch
längst Geschichte, die Version 4.9.2 ist installiert und funktioniert.
Ich muss halt entweder den Warninglevel herabsetzen oder viel casten.
Ein bissl blöd finde ich beides, weil Pointer auf Char immer Pointer auf
Bytes sind oder gibt es heute char mit 16/32 Bytes?
Vor allem ob Char und unsigned Char verschiedene Dinge sind, die einen
sagen so, die anderen anders.
Wie kann ein Char überhaupt ein Vorzeichen haben und warum stören sich
STR Funktionen daran?
Joachim B. schrieb:> MaWin schrieb:>> Du solltest froh sein, dass der neue GCC diesen eindeutigen>> Programmierfehler nicht mehr zulässt. Dein Programm hat schon immer nur>> durch Zufall funktioniert.>> wieso kommst du aus dem Mustopp?> ach ja du bist alt oder ein Troll, dieser sogenannte "Fehler" ist doch> längst Geschichte, die Version 4.9.2 ist installiert und funktioniert.
Ich bin sicherlich der Letzte, der MaWin gerne zustimmt, aber in diesem
Fall hat er ausnahmsweise Recht.
> Ich muss halt entweder den Warninglevel herabsetzen oder viel casten.
Viele Typecasts sind nach meiner persönlichen Erfahrung häufig ein
Hinweis auf ein verkorkstes Design. Daß man es man als Entwickler
natürlich nicht gerne hört, daß man Fehler gemacht oder sein Design
verkorkst hat, ändert leider auch nichts an der Tatsache.
Karl Käfer schrieb:> Ich bin sicherlich der Letzte, der MaWin gerne zustimmt, aber in diesem> Fall hat er ausnahmsweise Recht.
womit denn?
MaWin schrieb:> Du solltest froh sein, dass der neue GCC diesen eindeutigen> Programmierfehler nicht mehr zulässt.
darüber bin ich froh!
MaWin schrieb:> Dein Programm hat schon immer nur> durch Zufall funktioniert.
ist eine schamlose Lüge weil ich solche Fehler nicht mehr drin habe,
denn sie wurden schon vor Urzeiten beseitigt. (woher solltest du auch
alle meine Codes kennen?)
Also worin in welchem Unfug stimmst du MaWin also zu?
Warum beantwortet mir keine die Frage warum str Funktionen char oder
unsigned char sein können?
Wie kann ein char signed sein? und warum meckern Compiler im einen oder
anderen Fall?
so nun wirds lustig
auf dem win Rechner läuft nun Arduino 1.8.2 mit avr-gcc 4.9.2
File: Y:\gemeinsame\projects\BG
Unterlagen\atmel\__ARDUINO__\nan_RTC_OLE_PT2258_NOK_World2_OK2\nan_RTC_O
LE_PT2258_NOK_World2_OK2.ino
kompiliert: 2017/00/04_15:12:48
Version: 4.9.2
und stört sich kein bischen an
1
char*strMonatsname(uint8_tMonat)
2
{
3
// Der Sketch verwendet 25132 Bytes (81%), 1774 Bytes (86%) des dynamischen Speichers, 274 Bytes für lokale Variablen verbleiben
das abzustellen war einfach
const char* strMonatsname( uint8_t Monat ) muss die func heissen
ist sauberer als die #warnings abzustellen.
nun muss ich mich aber entscheiden, sauber weiter, dann auf dem win den
warninglevel einschalten und irre werden oder auf dem PI ausschalten....
es gab ja hilfreiche Kommentare, leider helfen nicht alle, anonym lässt
es sich prima stänkern.
Immer diese Nebenschauplätze, helfen würde statt dusslich quatschen zu
verraten wo in der Arduino IDE die Compileroptionen versteckt sind auf
dem PI.
Joachim B. schrieb:> verraten wo in der Arduino IDE die Compileroptionen versteckt sind auf> dem PI.
Warum fragst Du das nicht in einem der gefuehlt Millionen Arduino-Foren?
Wer hier schon laenger aktiv ist, sollte mitbekommen haben, dass 1.
"arduino" hier negativ besetzt ist und 2. dazu hier nur wenige
Kenntnisse vorhanden sind.
Die allermeisten hier arbeiten nunmal einen oder mehrere Level hoeher.
Logisch betrachtet allerdings sehe ich keinen Grund, warum diese auf dem
Pi in einem anderen Pfad sein sollten als auf dem PC.
wendelsberg
nicht jeder sieht Arduino negativ.
Es gibt hier schon hilfreiche Menschen und auch welche die Arduino
nutzen und die tiefer in der Linux Materie stecken.
wendelsberg schrieb:> Logisch betrachtet allerdings sehe ich keinen Grund, warum diese auf dem> Pi in einem anderen Pfad sein sollten als auf dem PC.
logisch? na da sehe ich bei selbst zusammengebauten Install Scripts erst
mal nichts ausserdem hat Linux einen anderen Aufbau, es gibt keine
Registry :)
Ich habe ja auch schon selber gesucht, aber da in den Makefiles nur noch
Verweise stehen und für jede Plattform eigene ist es eben mühsam.
Make hatte ich zuletzt vor Jahrzehnten genutzt und da war es noch
überschaubarer und die Abhängigkeiten halt kleiner.
Ich nehms sportlich, es gibt ja immer mehrere Lösungen.
Momentan habe ich mir vielleicht unnötig den Gleichlauf zwischen win und
PI im Compiler gewünscht.
Kann klappen würde mich freuen, aber wenn nicht auch nicht wild.
Arduino ist auch nicht prinzipiell negativ.
Leider hat der Hofnarr aber recht, wenn man schlechten Code herstellt,
dann darf man nicht auf den Compiler schimpfen oder erwarten, dass jede
Version genauso gutmütig ist und zufällig die Fehler so ausgleicht, dass
es noch gut geht.
Joachim B. schrieb:> warum str Funktionen char oder unsigned char sein können?
Wenn du String-Verarbeiting betreibst, dann nimm char bzw. char* oder
adäquat qualifizierte Typen wie const char* bei Literalen.
Wenn du 8-Bit Arithmetik betreiben willst, dann nimm [u]int8_t aus
stdint.h (C99).
> Wie kann ein char signed sein?
Die Signedness von char ist Implementation defined. Unabhängig von der
Sinedness sind char, signed char und unsigned char drei
unterschiedliche Typen. Entsprechend sind die abgeleiteten
Zeiger-Typen ebenfalls unterschiedlich.
> und warum meckern Compiler im einen oder anderen Fall?
Siehe oben.
Außerdem meckert char*c="x" etc. an weil das impliziert, qua c auf das
Literal schreiben zu können => const char* für Literals.
Joachim B. schrieb:> nicht jeder sieht Arduino negativ.
Du brauchst aber kein Arduino. Wenn Du genauer hingeschaut hättest, dann
wäre Dir aufgefallen, daß Arduino von gcc-avr abhängig und dieser daher
durch die Arduino-Installation automatisch mit installiert worden ist.
> logisch? na da sehe ich bei selbst zusammengebauten Install Scripts erst> mal nichts ausserdem hat Linux einen anderen Aufbau, es gibt keine> Registry :)
Ja, zum Glück!
Ehrlich gesagt verstehe ich auch nicht ganz, warum Du jedesmal so
kindisch, rechthaberisch und patzig reagierst, sobald jemand etwas
äußert, das auch nur ansatzweise so etwas wie den leisesten Hauch einer
Kritik an Dir oder Deiner Vorgehensweise enthalten könnte. Immerhin bist
es Du, der hier Hilfe sucht, weil offenbar irgend etwas nicht so
funktioniert, wie Du es gerne hättest. Aber sobald jemand versucht, Dir
zu helfen und Dir Vorschläge zur Verbesserung Deiner Strategie gibt,
wirst Du pampig, weißt alles besser, und insistierst auf irrelevantem
Quatsch wie "signed char".
Aber um den irrelevanten Quatsch kurz zu klären: es gibt eigentlich gar
keinen dedizierten Typ für Zeichen in C, char ist ein Integertyp ähnlich
short oder int. char ist einfach nur der kleinste Integertyp, und wie
jeder andere Integertyp kann er vorzeichenbehaftet (signed) oder eben
nicht vorzeichenbehaftet (unsigned) sein.
Es ist zwar richtig, daß -- wie der Name bereits vermuten läßt -- char
hauptsächlich dafür gedacht ist, Zeichen zu repräsentieren, aber in C
werden Zeichen nunmal durch ihren Integer-Code repräsentiert und
deswegen ist es natürlich nicht ungewöhnlich, daß char ein Integer-Typ
ist. Der einzige Unterschied zu anderen Integer-Typen ist, daß char
üblicherweise implizit unsigned ist, auch wenn der Standard das nicht
festlegt.
So, jetzt kannst Du mich anpampen, wenn Dir das was gibt. Ich bin 'raus.
Johann L. schrieb:> Wenn du 8-Bit Arithmetik betreiben willst, dann nimm [u]int8_t aus> stdint.h (C99).
mache ich doch längst, habe nur noch nicht alles an Sourcen angepasst,
das ist wie auch bei anderen historisch gewachsen, vom ersten C auf dem
286er mit #defines von BYTE, UBYTE über WORD bis DWORD sowie deren
unsigned Versionen.
Irgendwann kamen noch QWORD dazu und nun schreibe ich halt alles um von
uint8_t bis uint64_t und deren signed Varianten.
> Die Signedness von char ist Implementation defined. Unabhängig von der> Sinedness sind char, signed char und unsigned char drei> unterschiedliche Typen. Entsprechend sind die abgeleiteten> Zeiger-Typen ebenfalls unterschiedlich.
damit habe ich ja kein Problem nur wegen der verschiedenen Definitionen
gibts ja den Compilerstress weil wie mans macht ist falsch, man muss nur
an den anderen Compiler kommen.
> Außerdem meckert char*c="x" etc. an weil das impliziert, qua c auf das> Literal schreiben zu können => const char* für Literals.
ich verstehe zwar nur die Hälfte, aber ich danke für deine Auskünfte,
wäre schön wenn mehrere das leisten würden.
Sheeva P. schrieb:> Du brauchst aber kein Arduino. Wenn Du genauer hingeschaut hättest, dann> wäre Dir aufgefallen, daß Arduino von gcc-avr abhängig und dieser daher> durch die Arduino-Installation automatisch mit installiert worden ist.
auf dem AvrStudio habe ich aber leichter Zugriff auf die Optionen, wäre
schön wenn man den Zugriff auch auf die Arduino IDE bekäme
Ich habe absolut keine Probleme mich da umzustellen aber schöner wäre es
wenn sich gleiche Versionsnummern auf allen Systemem gleich verhalten
würden.
>> logisch? na da sehe ich bei selbst zusammengebauten Install Scripts erst>> mal nichts ausserdem hat Linux einen anderen Aufbau, es gibt keine>> Registry :)>> Ja, zum Glück!
OK keinen Einspruch von mir, ich habe durchaus die Vorzüge von Linux
gesehen, nur leider auch je nach Distri und Programme auch mal
Nachteile.
> Ehrlich gesagt verstehe ich auch nicht ganz, warum Du jedesmal so> kindisch, rechthaberisch und patzig reagierst, sobald jemand etwas> äußert, das auch nur ansatzweise so etwas wie den leisesten Hauch einer> Kritik an Dir oder Deiner Vorgehensweise enthalten könnte.
Du hattest doch kaum was geschrieben und was du schriebst war im großen
ganzen OK, zu dem einen komme ich noch.
> es Du, der hier Hilfe sucht, weil offenbar irgend etwas nicht so> funktioniert, wie Du es gerne hättest. Aber sobald jemand versucht, Dir> zu helfen und Dir Vorschläge zur Verbesserung Deiner Strategie gibt,> wirst Du pampig, weißt alles besser, und insistierst auf irrelevantem> Quatsch wie "signed char".
kann an meinem Unverständnis liegen weil ich ja kein guter
Programmmierer bin, es gibt halt so viele die sich für begnadete
Programmierer halten und dann kommt so ein Definitionswirrwar raus.
> Aber um den irrelevanten Quatsch kurz zu klären: es gibt eigentlich gar> keinen dedizierten Typ für Zeichen in C, char ist ein Integertyp ähnlich> short oder int. char ist einfach nur der kleinste Integertyp, und wie> jeder andere Integertyp kann er vorzeichenbehaftet (signed) oder eben> nicht vorzeichenbehaftet (unsigned) sein.
hatte schon jemand erklärt.
> Es ist zwar richtig, daß -- wie der Name bereits vermuten läßt -- char> hauptsächlich dafür gedacht ist, Zeichen zu repräsentieren, aber in C> werden Zeichen nunmal durch ihren Integer-Code repräsentiert und> deswegen ist es natürlich nicht ungewöhnlich, daß char ein Integer-Typ> ist. Der einzige Unterschied zu anderen Integer-Typen ist, daß char> üblicherweise implizit unsigned ist, auch wenn der Standard das nicht> festlegt.
ist geklärt
> So, jetzt kannst Du mich anpampen, wenn Dir das was gibt. Ich bin 'raus.
ist gar nicht mein Ziel, aber wenn du von anpampen schreibst:
Sheeva P. schrieb:> Und statt Deinen Code zu korrigieren, möchtest Du Dich für den Rest> Deines Lebens an eine uralte Version genau eines einzigen Compilers> binden? Das erscheint mir keine sehr zielführende Strategie zu sein.
ich habe auf 2 Systemen die neuen Compiler mit gleicher Versionsnummer
und gleicher IDE Version installiert und es würde mich freuen wenn beide
auf gleichen Compileroptionen wären!
> Warum willst Du denn auf einem leistungsschwachen Pi crosscompilen? Dein> PC kann das doch wesentlich schneller. Sogar, wenn er genauso alt ist> wie die Compilerversion, die Du darauf benutzt.
Mein PI läuft 24/7 der kann sich Zeit lassen und ich kann es aus der
Ferne erledigen, den PC dafür hochzufahren ist nicht immer sinnvoll.
Warum reagierst du so negativ auf den PI, der PI3 ist nicht mal so lahm
als das der Compilerlauf für einen nano über Gebühr dauern würde.
Auf konstuktive Bemerkungen hoffe ich reagiere ich nicht pampig, aber
hier war auch härteres geschrieben worden von Leuten die das Thema oder
gar Hilfe nicht die Bohne interessiert, da gehts oft nur um ich schreibs
mal freundlich "rumalbern" oder jemanden einen reinzuwürgen, kann man
machen wenn der Frust tief sitzt und an die die ich verletzt haben
sollte mein tiefstes Bedauern, die anderen bedauere ich nur.
update,
auf dem win PC die IDE 1.8.2 installiert, die bringt avr-gcc 4.9.2 mit
dito auf dem PI B alt und PI3
Korrekturen am Sourcecode eingefügt damit die neuen Compiler zufrieden
sind.
Die größte "Falle" war in der Testphase der Haken bei
[] Aggressively cache compiled core
der hatte immer noch alte Objectfiles dazugelinkt, Haken raus und nun
läuft alles wie gewünscht.
Ich könnte ja mal prüfen ob ein clean der build dirs dann den Haken
wieder setzen erlaubt.
Klar ist man zuerst genervt, von Nebenbaustellen, aber es stimmt schon
es ist besser mal alles neu aufzusetzen als ewig dem Alten
hinterherzurennen.
Wenn du es jetzt schon bis in die Nähe der Compile- und Buildoptionen
deiner IDE geschafft hast, dann ist es bis zum Thema signed/unsigned
char auch nicht mehr weit.
Oliver
Oliver S. schrieb:> dann ist es bis zum Thema signed/unsigned> char auch nicht mehr weit.
Kann man das in der Arduino-"IDE" überhaut einstellen? Die ist doch
angeblich für Anfänger geeignet denen man keine Einstellungen zutraut,
damit erhebt sie ja implizit den Anspruch bereits out-of-the-box perfekt
für jeden denkbaren Einsatzzweck (eines Anfängers) konfiguriert zu sein
so daß niemals Probleme oder Wünsche auftreten können die ein Ändern
irgendwelcher Compilerflags nötig machen.
Außerdem würde das Erlauben des Schraubens an den Einstellungen doch
auch die einfache Austauschbarkeit der "Sketche" beeinträchtigen wenn zu
jedem "Sketch" oder zu jeder "Library" noch separat die passenden
Compilerflags an andere Personen weitergereicht werden müssten und das
würde ja dem Anspruch aus 1 direkt entgegenwirken.
Compilerflags für eine bestimmte Quelle gehören ja normalerweise zum
jeweiligen Quelltext (in Form von Projektdateien, Makefiles oder
ähnlichem die zum Projekt dazugehören) und NICHT zur globalen
Einstellung der IDE. Wenn eine einzelne .ino-Datei aber ausreichen soll
um ein Projekt samt Code komplett zu beschreiben (und überall zu
funktionieren, zumindest scheint so eine Philosophie hinter dem Design
gestanden zu haben) dann ist da kein Platz mehr für änderbare
Compileroptionen. Bestenfalls noch für Pragmas in der .ino selbst.
Anspruch und Wirklichkeit klaffen halt öfter mal weit auseinander.
Das Problem wird zwar nicht ursächlich von Arduino verursacht, sondern
vom gcc, weil der arm-gcc defaultmässig char als unsigned ansieht, der
x86-gcc dagegen als signed (warum auch immer), aber die Arduinisten
hätten das ihrem Anpruch gemäß in den versteckten Compileroptionen
korrigieren können.
Das haben die halt übersehen, und daher gibts das Durcheinander.
Oliver
Oliver S. schrieb:> Das Problem wird zwar nicht ursächlich von Arduino verursacht, sondern> vom gcc, weil der arm-gcc defaultmässig char als unsigned ansieht, der> x86-gcc dagegen als signed (warum auch immer)
danke für deine Worte, ich habe ja hier für meine Gedanken Schelte
einstecken dürfen
Joachim B. schrieb:> Vor allem ob Char und unsigned Char verschiedene Dinge sind, die einen> sagen so, die anderen anders.> Wie kann ein Char überhaupt ein Vorzeichen haben und warum stören sich> STR Funktionen daran?
PS. das signed und unsigned Durcheinander gibt es ja schon länger, ist
keine Erfindung der neuen Compilerbauer.
Egal es ist lösbar und gelöst.
nachdem die IDE 1.8.2 und gcc 4.9.2 nun auf win und PI gleich läuft
(fast) fällt folgendes auf:
auf win
Der Sketch verwendet 15790 Bytes
Globale Variablen verwenden 1471 Bytes
auf PI
Der Sketch verwendet 15800 Bytes
Globale Variablen verwenden 1481 Bytes
warum diese Unterschiede?
Johann L. schrieb:> Wegen Zeile 42?
starke Antwort, aber bei gleicher IDE und gleichem GCC und gleichen LIBs
und demselben source Code hat 42 eigentlich keinen Sinn, am Arduino
sollte sich derselbe Ramverbrauch und dieselbe Codegröße einstellen
Dass sich bei Flash und RAM die gleiche Differenz zeigt, legt die
Vermutung nahe, dass es ein String ist, der auf dem PI länger ist (oder
mehrere). Wird vielleicht _FILE_ (oder Ähnliches) verwendet?
Stefan E. schrieb:> Dass sich bei Flash und RAM die gleiche Differenz zeigt, legt die> Vermutung nahe, dass es ein String ist, der auf dem PI länger ist (oder> mehrere). Wird vielleicht _FILE_ (oder Ähnliches) verwendet?_DATE__TIME_
sollte gleich sein
hmmm FILE (Pfade) könnte sein -> NASPfad PI & LW Buchstabe win! da muss
ich suchen, danke für den Hinweis!
Thread beobachten
Seitenaufteilung abschalten