mikrocontroller.net

Forum: Compiler & IDEs GPIOR0 als globale volatile Variable


Autor: OlliW (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

ich komme nicht dahinter und/oder bin zu dumm die Lösung im Netz zu 
finden:
ich will eines der SFRs beim AVR wie z.B. das GPIOR0 als globale 
Variable (keine Bits bzw. Flags) zum Austausch zwischen main und 
Interrupt-Routinen benutzen.

Als Ansätze für Lösungen habe ich z.B. gefunden #define variablennamen 
GPIOR0, oder die Lösung hier 
Beitrag "variable/zeiger in GPIOR0 fest registrieren", die ich allerdings 
nicht verstehe (was mich ärgert :-)).

Tut's #define variablename (* (*((volatile unsigned char**) (&GPIOR0))) 
)?

Was das tut verstehe ich wie gesagt nicht, aber es kompiliert zumindest, 
ergibt bei mir mit -Os allerdings 2 Byte grösseren Code als volatile 
unsigned char variablename und scheint also nichts zu bringen.

Wie ginge es richig?


Danke schon mal,
  Olli

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GPIOR0 ist quasi bereits eine globale volatile Variable und kann 
direkt als solche verwendet werden. Wenn du der Variable einen eigenen 
Namen geben willst, dann reicht ein einfaches #define.
#define SomeVar GPIOR0

main () {

    while(SomeVar < 10) {}
}

ISR () {

    SomeVar++;
}

Autor: OlliW (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

ja, das hatte ich ja auch schon geschrieben (:-)), aber wie sag ich's 
dem Compiler das die auch noch volatile ist?

Danke trotzdem,
  Olli

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sind die SFRs doch per Deklaration sowieso schon alle.

Autor: OlliW (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AHA... das war ein nützlicher Hinweis. Tatsächlich, in sfr_defs.h steht 
was ähnliches wie in dem zitierten Beitrag oben:

#define _MMIO_BYTE(mem_addr) (*(volatile uint8_t *)(mem_addr))
#define _SFR_IO8(io_addr) _MMIO_BYTE((io_addr) + __SFR_OFFSET)

Cool, das hätte ich nie gefunden weil ich gar nicht auf die Idee 
gekommen wäre da zu suchen... DANKE!

Olli

PS: ich finde ja das es sehr nützlich ist wenn gerade auch solche 
"Kleinigkeiten" im Tutorial stehen, jetzt würde ich mich aber in 
Anbetracht meines Nichtprofistatus nie trauen da selber etwas 
reinzueditieren. Wie ist das eigentlich, könnte oder sollte ich z.B. das 
ins Tutorial schreiben, kann ich dabei etwas "kaput" machen, und kann 
man damit rechnen dass es "Korrektur gelesen wird", also wenn es nicht 
ganz richtig oder gar falsch dargestellt wäre schon von "irgendjemanden" 
auskorrigiert werden würde?

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OlliW schrieb:

> man damit rechnen dass es "Korrektur gelesen wird", also wenn es nicht
> ganz richtig oder gar falsch dargestellt wäre schon von "irgendjemanden"
> auskorrigiert werden würde?

Ja, davon kannst du ausgehen.
Ich z.B. sehe die Änderungen dort relativ regelmäßig durch, und ich bin 
sicher auch nicht der einzige, der das macht.

Autor: Oliver W. (olliw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super. Dann hoffe ich mal dass du oder sonstwer über den Absatz 
Speichern von globalen volatilen Variablen auf der avr-gcc 
Codeoptimierungsseite stolpert... war aufregend da zum erstenmal was 
reinzuschreiben... :-)

DANKE nochmals zusammen!

(mein ca. 1k grosser Code mit 3 globalen volatilen Variablen ist mit den 
GPIROs um 70bytes geschrumpft (-Os)... lohnt sich also ziemlich... :-))

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver W. schrieb:
> (mein ca. 1k grosser Code mit 3 globalen volatilen Variablen ist mit den
> GPIROs um 70bytes geschrumpft (-Os)... lohnt sich also ziemlich... :-))

Das sind 35 Instruktionen.
Ich vermute mal, daß die Funktion zum Datenaustausch mit dem Interrupt 
mehrmals ge-inlined wird und daher die Einsparung.
Nochmehr spart das Inlining abschalten: -fno-inline-small-functions


Peter

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver W. schrieb:
> Super. Dann hoffe ich mal dass du oder sonstwer über den Absatz
> Speichern von globalen volatilen Variablen auf der avr-gcc
> Codeoptimierungsseite stolpert... war aufregend da zum erstenmal was
> reinzuschreiben... :-)

Bevor ich da was ändere, möchtest du es ja vielleicht selbst machen. Ich 
hätte da nämlich 3 Sachen:

1) Der erste Satz suggeriert, dass man auch für die Kommunikation 
zwischen 2 Interrupt-Funktionen grundsätzlich eine volatile Variable 
braucht. Dem ist nicht so. Außer in dem seltenen Fall, dass man ihnen 
erlaubt, sich gegenseitig zu unterbrechen. Ich würde z.B. einfach dieses 
Stück Text "z.B. Interruptroutinen oder" entfernen.

2) Du hast nur dann mit der Methode einen nennenswerten Vorteil 
gegenüber einer normalen Variable, wenn das SFR in dem Bereich liegt, 
der per IN/OUT erreichbar ist. Andernfalls spart man lediglich ein Byte 
SRAM. Codegröße und Geschwindigkeit sind dann ansonsten identisch zur 
normalen Variable. Ich denke, diese Einschränkung sollte mit einfließen, 
z.B. dort wo du ein paar mögliche SFRs auflistest.

3) Beim Source-Code unbedingt das Semikolon hinter GPIOR0 entfernen.
(und ein paar Leerzeilen wären auch nicht schlecht)

Ansonsten ist es für einen ersten Beitrag zum Wiki nicht so schlecht. 
;-)

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, es gibt da zwei Grundsätze beim Optimieren:
Regel 1: Tu es nicht.
Regel 2: Tu es noch nicht.

Ich nehme mal nicht an, dass du auf nem Tiny mit 1kB Programmspeicher 
arbeitest oder? Leeren Programmspeicher kannst du später nämlich nicht 
mehr umtauschen...

Autor: OlliW (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan: Tausend Dank für die Hinweise.
1) hätte ich eigentlich gewusst und verstehe es, habe aber nicht genau 
genug beim schreiben nachgedacht. Ändere ich.
2) ich glaube zu ahnen was du meinst, bin mir aber nicht sicher ob ich 
das 100% verstehe (ich kenne den Unterschied mit dem bit setzen, dachte 
aber das alle SFRs nur mit IN/OUT erreichbar sind). Kurz, da fühle ich 
mich gerade nicht kompetent und es wäre mir ehrlich gesagt lieber wenn 
das jemand kompetenter ändern würde...
3) jo, das war schlampig, ändere ich.

@Sven: ne, Platzmangel war nicht wirklich der ausschlaggebende Faktor, 
die Preisunterschiede bei 1k-8k kann ich bei meinen kleinen Stückzahlen 
verschmerzen (gibt's halt mal ein Eis weniger...). Bei diesem Beispiel 
war es allerdinsg so dass der Code zunächst knapp über 1k war und ich 
zwei ATtiny13A rumliegen habe und mir so gedacht habe, mal sehen ob 
ich's kleiner bekomme, schon auch nur um dazuzulernen und auch mal zu 
sehen was was wie in der .lss ändert. Es hat mich einfach interessiert, 
und ich habe ja auch einiges dazugelernt. Auch wenn es jetzt in einen 
ATtiny13 passt, werde ich die Schaltung trotzdem mit nem ATtiny45 bauen 
(man weis ja nie was man nicht noch alles implementieren will).

@Peter: bei dem speziellen Beispiel habe ich 3 ISRs und eine main, mehr 
nicht. Habe es gerade noch bei einem anderen Code ausprobiert, und da 
ist der Platzspaareffekt geringer.

Olli

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.