Forum: Compiler & IDEs wie bekommt man die avr-gcc 4.3.2 auf den raspberry PI


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
sudo apt-get install arduino installiert nur die 4.9.2 und die ist 
inkompatibel zu meinen Programmen, am PC nutze ich avr-gcc 4.3.2

von Kolja (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> sudo apt-get install arduino installiert nur die 4.9.2
                       -------

Ich denke, du willst GCC installieren?

von Helmut H. (helmuth)


Bewertung
0 lesenswert
nicht lesenswert
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: 
Beitrag "AVR - GCC 4.3.3 / LIBC 1.6.5 build - komplett"

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von wendelsberg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter II (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Chris F. (chfreund) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Harry L. (mysth)


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> cross compiling auf dem PI vergessen!

broken by design....

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Da Performance anscheinend keine Rolle spielt, bekommt man die 
Windows-Entwicklungstools auf den Pi wie auf alle Linuxoiden: Mit wine.

Oliver

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.
2
prog_char mo0[] PROGMEM = "   "; prog_char mo1[] PROGMEM = "Jan"; prog_char mo2[] PROGMEM = "Feb"; 
3
prog_char mo3[] PROGMEM = "Mar"; prog_char mo4[] PROGMEM = "Apr"; prog_char mo5[] PROGMEM = "May"; 
4
prog_char mo6[] PROGMEM = "Jun"; prog_char mo7[] PROGMEM = "Jul"; prog_char mo8[] PROGMEM = "Aug"; 
5
prog_char mo9[] PROGMEM = "Sep"; prog_char mo10[] PROGMEM = "Oct"; prog_char mo11[] PROGMEM = "Nov";
6
prog_char mo12[] PROGMEM = "Dec";

hier meckert der Compiler unnötig über fehlende const
konnte ich beheben
1
// Then set up a table to refer to your strings.
2
//const char* const string_table[] PROGMEM = {string_0, string_1, string_2, string_3, string_4, string_5};
3
const char* const mo_table[] PROGMEM = { mo0, mo1, mo2, mo3, mo4, mo5, mo6, mo7, mo8, mo9, mo10, mo11, mo12 };

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?

: Bearbeitet durch User
von Peter II (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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
1
#if defined(__AVR_ATmega1284P__) && (F_CPU==14400000)
2
#include "nimm_das_UNDEF_und_DEF14400000_raus.h"
3
#endif
4
#if defined(__AVR_ATmega1284P__)
5
  #define NS(_NS) ( (_NS * ( (F_CPU*9L/10L) / 1000000L))) / 1000
6
  #define CLKS_TO_MICROS(_CLKS) ((long)(_CLKS)) / ((F_CPU*9L/10L) / 1000000L)
7
#else
8
  #define NS(_NS) ( (_NS * (F_CPU / 1000000L))) / 1000
9
  #define CLKS_TO_MICROS(_CLKS) ((long)(_CLKS)) / (F_CPU / 1000000L)
10
#endif

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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:
1
const char mo0[] PROGMEM = "   "; const char mo1[] PROGMEM = "Jan";
2
const char mo2[] PROGMEM = "Feb";
3
const char mo3[] PROGMEM = "Mar"; const char mo4[] PROGMEM = "Apr";
4
const char mo5[] PROGMEM = "May";
5
const char mo6[] PROGMEM = "Jun"; const char mo7[] PROGMEM = "Jul";
6
const char mo8[] PROGMEM = "Aug";
7
const char mo9[] PROGMEM = "Sep"; const char mo10[] PROGMEM = "Oct";
8
const char mo11[] PROGMEM = "Nov";
9
const char mo12[] PROGMEM = "Dec";
10
11
// Then set up a table to refer to your strings.
12
13
const char* const mo_table[] PROGMEM = { mo0, mo1, mo2, mo3, mo4, mo5,
14
mo6, mo7, mo8, mo9, mo10, mo11, mo12 };

Allerdings kannst du auch einfach
1
const char mo_table[][4] PROGMEM =
2
{
3
    "   ",
4
    "Jan", "Feb", "Mar", "Apr", "May", "Jun",
5
    "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"
6
};

Was dir im Code dann eine Indirektion spart.

Oder ganz ohne pgm_read_xxx Geraffel per
1
const __flash char mo_table[][4] =
2
{
3
    "   ",
4
    "Jan", "Feb", "Mar", "Apr", "May", "Jun",
5
    "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"
6
};

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von Matthias H. (hallamen)


Bewertung
0 lesenswert
nicht lesenswert
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:
1
char *f() {
2
    return "slkdfj";
3
}

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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:
1
File:       E:\arduino-1.8.2_PORTABEL_win\meine\ReceiveDemo_Advanced_3\ReceiveDemo_Advanced_3.ino
2
kompiliert: 2017/05/03_18:05:42
3
Version:    4.9.2

mit meiner Standardinstallation 1.0.5-r2, komischerweise ohne Pfadangabe
1
File:       ReceiveDemo_Advanced_3.ino
2
kompiliert: 2017/05/03_18:09:20
3
Version:    4.3.2

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> er bemeckerte in einer Funktion
>
>
1
> char *func(char* var)
>
> tatsächlich ein
>
1
> return "fehler";

Die Funktion sollte also einen const char* returnen:
1
const char* func (char *var)

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Die Funktion sollte also einen const char* returnen:
>
1
const char* func (char *var)

nein nur im Fehlerfall

deswegen darf die Func nicht const sein, nur die Rückgabe im Fehlerfall!

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
puh geht doch

arduino IDE 1.8.2 auf dem PI3
LIBs nachinstalliert
erste Fehlermeldungen ausgebügelt

erster Compilerlauf erfolgreich
1
Der Sketch verwendet 13920 Bytes (43%) des Programmspeicherplatzes. Das Maximum sind 32256 Bytes.
2
Globale Variablen verwenden 876 Bytes (42%) des dynamischen Speichers, 1172 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.

nun noch proggen versuchen

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
so, proggen klappt auch, nur verhält sich Linux etwas anders mit Serial 
in

ich glaube ich muss noch flush bemühen!

von MaWin (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Karl Käfer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
-1 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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_t Monat )
2
{ 
3
// Der Sketch verwendet 25132 Bytes (81%), 1774 Bytes (86%) des dynamischen Speichers, 274 Bytes für lokale Variablen verbleiben
4
/*
5
  const char* const mo_table2[] PROGMEM = {"", "Januar", "Februar", "Maerz", "April", "Mai", "Juni", "Juli", "August", "September", "Oktober", "November", "Dezember"};
6
  if(0<Monat && Monat<13)
7
    return mo_table2[Monat];
8
  else
9
    return"ERROR";
10
*/  
11
// Der Sketch verwendet 25092 Bytes (81%), 1772 Bytes (86%) des dynamischen Speichers, 276 Bytes für lokale Variablen verbleiben
12
  switch (Monat)
13
  { case 1:
14
      return"Januar";
15
    case 2:
16
      return"Februar";
17
    case 3:
18
      return"Maerz";
19
    case 4:
20
      return"April";
21
    case 5:
22
      return"Mai";
23
    case 6:
24
      return"Juni";
25
    case 7:
26
      return"Juli";
27
    case 8:
28
      return"August";
29
    case 9:
30
      return"September";
31
    case 10:
32
      return"Oktober";
33
    case 11:
34
      return"November";
35
    case 12:
36
      return"Dezember";
37
    default:
38
      return"ERROR";
39
  } // switch (Monat)
40
// * /
41
} // char* strMonatsname( uint8_t Monat )

kein Gemecker, auf dem PI3 läuft selbiges

und .....
1
....nan_RTC_OLE_PT2258_NOK_World2_OK2/s_tools.ino:602:13: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
2
       return"Januar";

ist ja nett von der IDE auf dem PI, muss mal suchen wo ich das abstellen 
kann oder was ich noch am Code ändern muss.

von Skippy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>> -Wwrite-strings
..
>> ist ja nett von der IDE auf dem PI, muss mal suchen wo ich das abstellen kann 
oder was ich noch am Code ändern muss.

;)

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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....

von In C programmieren aber richtig (Gast)


Bewertung
4 lesenswert
nicht lesenswert
Joachim B. schrieb:
> irre werden

Das bist du längst! @Moderatoren: Bitte diesen Thread nach /dev/null 
verschieben. Danke.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von wendelsberg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Chris F. (chfreund) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
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

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Oliver S. (oliverso)


Bewertung
1 lesenswert
nicht lesenswert
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

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wegen Zeile 42?

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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

von Stefan E. (sternst)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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!

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
WIN
File: R:\atmel
PI
File: /mnt/Qnap453a/atmel

Differenz 10 Byte da sind sie!

wow und ich habe gegrübelt!

Danke!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.