Forum: Compiler & IDEs HINWEIS: abgekündigte Funktionen/Makros verschwinden bald

Hallo Jörg,

Wodurch sind die in avr/timer.h enthaltenen Routinen denn zu ersetzen?
Workaround? Oder muß ich das jetzt selber definieren?

Und wann wurde das denn deprecated erklärt?

ciao, Stefan.

Na das mit dem kopieren ist mir ja nix. Da würde ich lieber den
Quellcode mit Präprozessoranweisungen verändern. Aber das ist ja
Geschmackssache. Ich verändere ungern Standard-Libraries, weil ein
Update dann umso schwieriger wird.

Die Makros und Konstanten habe ich mir jetzt in meinem eigenen
Quelltext definiert.

ciao, Stefan.

Doch, ich habe es genauso verstanden. :-)

Ich entwickle aber kaum für unterschiedliche Mikrocontroller. Insofern
tritt das Problem bei mir nicht so stark auf.

Daß der I2C-Teil bei Atmel und Philips gleich ist, wundert mich nicht
so sehr. Fertige I2C-Controller kann man als IP-Core kaufen und dann in
eigenen Chips einsetzen.

ciao, Stefan.

> Wodurch sind die in avr/timer.h enthaltenen Routinen denn zu
> ersetzen?

Die Dinger haben nie wirklich richtig funktioniert.  Das Setzen der
TCNT-Register startet oder stopt den Timer in keiner Weise, das war
schon immer Unfug.  Die Bitdefinitionen stimmen nur für einige AVRs,
andere wie z. B. der ATmega128 brauchen für die gleiche Funktion
andere Bitwerte (bzw. implementieren gänzlich andere Vorteilerwerte).

Da das Ganze schließlich nur für den Timer 0 überhaupt da drin stand,
war es zudem noch so unvollständig, dass es keinen Sinn hatte, sowas
überhaupt noch weiter als Bestandteil der Bibliothek pflegen zu
wollen.

Letztlich wird sich jeder für die entsprechende Funktionalität seine
eigenen Makros oder (inline) Funktionen schreiben (müssen).

@peter dannegger:
wie kannst du denn die dateien von "...AVR/INCLUDE/AVR" nach
"...AVR/INCLUDE" kopieren (z.B. stdio.h) die stdio.h is doch im
verzeichniss AVR/INCLUDE schon drinne....?????

Die Trennung wurde übrigens sehr bewusst vorgenommen.  Wenn in
irgendwelchem Code ein

#include <signal.h>

stehen sollte, dann meint der Autor dieses Codes garantiert nicht
das, was er unter

#include <avr/signal.h>

finden kann.  <signal.h> ist vom C-Standard gesetzt, hat aber im
AVR-Kontext zumindest ohne Betriebssystem keinen Sinn.  Andersrum,
sollte ein Betriebssystem existieren und <signal.h> implementieren, so
wären plötzlich <signal.h> und <avr/signal.h> existent und zwei sehr
verschiedene Dinge.

Die Motivation, warum einer das Subdir in #include <avr/...> nicht
schreiben will, verstehe ich nicht (sorry Peter), aber wenn das schon
sein muss, dann nehmt bitte -I Compiler-Optionen dafür.  (Die sollte
wohl auch jeder Compiler verstehen, ältere Compiler nur ohne
Leerzeichen nach dem -I.)

Hallo Jörg,

wann wirds denn die neue WinAVR Version geben?

Gruß und guten Rutsch 2 all.

Marcus

Das musst Du Eric fragen -- ich mache ja WinAVR nicht selbst.

Da er es aber auch als reine Freizeitarbeit macht, einen Job hat und
nicht wenige Kinder :), zieht sich sowas immer ein wenig länger hin,
als man ursprünglich beabsichtigt.

Hallo,

erstmal allseits ein gesundes Neues Jahr.

An dieser Stelle möcht ich mal meinen Senf dazugeben:Ich entdecke
langsam AVRGCC für mich (schon ca. ein Jahr lang). Ja! ich bin kein
professioneller Programmierer, ich hab C nie gelernt, ich hab auch
nicht die Zeit um mich täglich mit C zu beschäftigen. Ich versuche
einfach
viel zu lesen und dann zu probieren. Im Netz gibt es verschiedene Kurse
und Infos zu dem Thema. Wenn dann Beispiele nicht mehr funktionieren,
weil GCC irgendwelche Befehle nicht mehr kennt, find ich das nicht
gut.
Neu eingeführte Makros sind in ihrer Schreibweise nicht unbedingt
verständlicher. Jedenfalls aus der Sicht eines Anfängers. Meine Frage
ist: warum muss überhaupt ständig irgendwas geändert werden? Stichwort
Abwärtskompatibilität! Warum kann GCC nicht (SBI) UND (_BV) verstehen
und verarbeiten?
Das Ganze kommt mir so wie die Diskussion um Eagle vor: Version 4.13
kann keine Bibliothek mehr von Version 4.xy lesen. Willst Du das musst
Du über irgendwelche Scriptfunktionen ex- und importieren oder Hex Wert
ABC ändern - echt SCH...

Gruss Holger

Für C-Anfänger ist der Wegfall von Funktionen/Makros wie inb/outb/sbi
etc. und BV eigentlich von Vorteil (_BV gibt's sogar scheinbar
weiterhin). Man kann in jedem C-Buch nachlesen, wie Bits
gesetzt/gelöscht werden und muss sich nicht noch zusätzlich mit avrgcc
oder libc "Extrawürsten" auseinandersetzen. Das einige alte
Beispielcodes dann nicht mehr ohne weiteres compiliert werden können,
ist vielleicht etwas störend, aber immer noch besser, als ständig
irgendwelche Altlasten mitzuschleppen. Die Möglichkeit die
"entrümpelten" Makros durch selbtdefinierte zu ersetzen, wurde ja
schon erwähnt. Als Vorteil lassen sich viele Beispielcodes von Atmel
(Datenblätter/AppNotes meist für IAR) inzwischen deutlich leichter an
avrgcc/avr-libc anpassen. Nicht das jeder Atmel-Code immer die beste
Lösung ist, aber fast immer Informativ.

Auch, wenn ich's schon x-mal vorgekaut habe:

Die historischen Makros sind zu einer Zeit entstanden, da der AVR-GCC
einfach noch nicht in der Lage war, sowas wie

PORTB = 42;

DDRB |= (1 << 4);

zu verarbeiten.  Als Krücke, damit man überhaupt auf die IO-Ports
sinnvoll zugreifen kann, entstanden dann diese Makros (die damals
reine inline-Assembler-Hacks waren).

Seit geraumer Zeit kann AVR-GCC (+ avr-libc) diese Funktionalität, und
dies ist (wie Martin bemerkt) erstens die Standard-C-Methode (wie man
sie also auch beispielsweise in einem Unix-Kernel massig findet,
wenn dort irgendwo ein Bit in einem Port-Register geändert werden
muss) und stimmt zweitens vor allem mit der Atmel-Schreibweise
überein.

Für eine Übergangszeit wurden zur Erleichterung der Umgewöhnung die
alten Makros noch bereitgestellt -- übrigens nicht mehr als
inline-asm-Hacks, sondern sbi(r, b) war halt wirklich weiter nix als
(r) |= (1 << (b)), mit allen Seiteneffekten (erweiterter Wertebereich
gegenüber dem Hardware-SBI, Hardware-SBI wurde nur generiert, wenn
auch die Optimierung eingeschaltet ist).

Diese Übergangszeit ist nun einfach mal vorbei.  Die Abkündigung liegt
zweieinhalb Jahre zurück.  Die Umstellung des entsprechenden
historischen Ballasts ist mit einem geeigneten Editor eine Sache von
wenigen Minuten pro Datei.

Neben der Rückkehr zu Standards möchten wir damit übrigens auch die
Leute zum Nachdenken anregen über ihren Code.  Ich habe schon genügend
Beispiele gesehen der Art:

sbi(DDRB, 0);
sbi(DDRB, 1);
sbi(DDRB, 2);
sbi(DDRB, 3);

wo es beim Hinschreiben von

DDRB |= (1 << 0);
DDRB |= (1 << 1);
DDRB |= (1 << 2);
DDRB |= (1 << 3);

vielleicht manch einem ja dämmert, dass es einfacher und schneller
sein könnte, gleich

DDRB |= (1 << 0) | (1 << 1) | (1 << 2) | (1 << 3);

oder ggf. gar (je nach Ausgangszustand von DDRB)

DDRB = (1 << 0) | (1 << 1) | (1 << 2) | (1 << 3);

zu schreiben.  Schon wird der generierte Code kürzer und schneller.

Gleichermaßen bin ich überzeugt, dass nach einer Übergangszeit all die
__attribute__((progmem)) Hacks verschwinden werden, wenn der GCC denn
endlich mal multiple memory spaces kann, sodass man den ROM ordentlich
mit Standard-C-Syntax explizit angeben kann.  Aber da reden wir über
einen Zeitraum von Jahren.

@Jörg:

Nicht böse sein! Ja hast Du schon zig mal geschrieben. Aber kann man
nicht mal eine andere Meinung haben? Ich kann's Dir nicht erklären!!!
Wirklich nicht! aber:

sbi(DDRB, 0);
sbi(DDRB, 1);
sbi(DDRB, 2);
sbi(DDRB, 3);

liest sich für mich einfacher und verständlicher(Alles klar: setze Bit
in I/O Register DDRB,0 ...) als:

DDRB |= (1 << 0) | (1 << 1) | (1 << 2) | (1 << 3);

Hie wird was verodert und Bits werden geschoben. Ich nehm Dir mal
ungesehen ab, das das Gleiche wie oben passiert.

>Schon wird der generierte Code kürzer und schneller.

Ja , das Argument verstehe ich - ist OK!

>Gleichermaßen bin ich überzeugt, dass nach einer Übergangszeit all
die
__attribute__((progmem)) Hacks verschwinden werden, wenn der GCC denn
endlich mal multiple memory spaces kann, sodass man den ROM ordentlich
mit Standard-C-Syntax explizit angeben kann.  Aber da reden wir über
einen Zeitraum von Jahren.

Diese Ausführungen sind Böhmische Dörfer für mich!

Im Endeffekt ist GCC ja nur ein Werkzeug. Ich würde zum Blech biegen
auch den Hammer mit dem krummen 30cm Stiel nehmen. Mit dem kann ich
eben gut. Auch wenn die EU "Normgerechte Hämmer mit 20cm Stiel, rot
lackiert" vorschreibt.

Ich will ja auch bitte keine Diskussion entfachen, ich weiss nur zu gut
wie viel Arbeit(kann es mir wenigstens vorstellen) in so einem Projekt
steckt. Das die Macher vom AVRGCC diesen bereitstellen ist nicht mit
Gold aufzuwiegen!! Euch für Eure unermüdliche Arbeit vielen Dank!

Eigentlich wollte ich nur noch sagen, ich wünsche mir eine
"oldstyle.h" oder "kompat.h". Oben mit include eingebunden und ALLE
alten Code gehen - ohne Nachdenken, ohne Änderungen im Quellcode.

Vielleicht bin ich ja auch der Einzige, der so denkt.

Und GUT jetzt.

Grüsse Holger

Damit wirst Du den alten Schrott aber nie los.  Es ist eine Last, wenn
man ewig zu 300 % rückwärtskompatibel bleiben muss.

Erkenntnis aus 12 oder so Jahren Opensource-Arbeit: neue Dinge musst
Du den Leuten aufdrängeln.  Danach finden sie's dann irgendwann ganz
gut.

sbi(foo, bar) liest sich nur solange besser, solange Du beim AVR bist,
weil Du es ganz zufällig mit seinem natürlichen SBI-Befehl verknüpfst.
Spätestens, wenn Du mal Code lesen musst, der für einen anderen
Prozessor geschrieben worden ist oder Deinen eigenen Code gar
irgendwann auf einen anderen Prozessor portierst, liest es sich gar
nicht mehr so natürlich.

Wie gesagt, Unix-Kernelprogrammierer (die bereits seit vielen Jahren
Bitmanipulationen in C schreiben müssen) haben Null Probleme, Code wie

foo |= BAR;
foo &= ~BAR;

zu verstehen, weil es halt generisches C ist.  Wenn AVR-GCC nicht
irgendwann mal die Krücke mit sbi und cbi und so gebraucht hätte,
hätte die AVR-GCC-Gemeinde sicher auch gar keine Probleme damit, weil
sie sich von vornherein an die natürliche C-Schreibweise gewöhnt
hätte.

Wenn Du's unbedingt brauchst, ist es Dir ja unbenommen, Dein eigenes
Headerfile damit zu pflegen.