mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik STM32F103 Wann GOIO_ODR,PIOBSRR und BRR?!


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.
Autor: kein gast (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wann benutzt man was und wieso soll das andere nicht genutzt werden laut 
Datenblatt...ist aber dennoch vorhanden!?!
GPIO_ODR
PIO_BSRR
PIO_BRR


Wo ist der Unterschied bei
PIO_BSRR
PIO_BRR?

Autor: Gerd P. (litart)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo Unbekannter,

es wäre nett wenn Du uns nicht groß suchen lässt sondern uns einen Teil 
der Arbeit abnimmst Dir zu helfen.

Bitte einen Link auf das Datenblatt auf das Du Dich beziehst und einen 
Hinweis auf die entscheidenden Textpassagen (wie Seitenzahl, 
Kapitel.Unterpunkt).
Ich habe z.B. das DAtenblatt "DocID13587 Rev 17" vom August 2015.

Gruß
Gerd

Autor: RTFM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
siehe Referenzmanual RM0008 s. 159
"Each I/O port bit is freely programmable, however the I/O port 
registers have to be
accessed as 32-bit words (half-word or byte accesses are not allowed). 
The purpose of the
GPIOx_BSRR and GPIOx_BRR registers is to allow atomic read/modify 
accesses to any of
the GPIO registers. This way, there is no risk that an IRQ occurs 
between the read and the
modify access."

und s. 173 für die Register

Autor: kein gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich war davon ausgegangen das der Controller so bekannt ist, das das Ref 
nicht erforderlich ist..
Ich war auch davon ausgegangen das es bei allen oder vielen STM32 gleich 
ist
https://www.st.com/resource/en/reference_manual/cd00171190.pdf

Autor: RTFM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kein gast schrieb:
> Ich war auch davon ausgegangen das es bei allen oder vielen STM32 gleich
> ist

Ja ist auch so, und die Antwort auf deine Fragen findest du auch u. a. 
in dem von dir verlinkten Dokument

Autor: kein gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
da ich es aber offenbar nicht oder falsch verstehe..Frage 
ich..verstehste?!
Vielleicht kommen ja noch hilfreiche Antworten von anderen.

Autor: RTFM (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
kein gast schrieb:
> da ich es aber offenbar nicht oder falsch verstehe..Frage
> ich..verstehste?!

Was genau denn an der oben zitierten Passage verstehst du nicht?

Auf das OutputDataRegister(ODR) kann 32-Bit-Word weise lesend und 
schreibend zugegriffen werden. Wenn du jetzt ein einzelnes Bit hier 
ändern willst, musst du das Register ins RAM kopieren, das Bit ändern 
und das modifzierte Wort zurück in das Register schreiben. Wenn jetzt 
genau nach dem kopieren des Registers ins RAM ein Interrupt ausgelöst 
wird, in dessen Routine z.B. ein anderer Output-Pin gesetzt wird, ist 
nach der Interruptroutine die Sicherung des ODR im RAM nicht mehr 
aktuell und würde dann den Output-Pin wieder zurücksetzen.

Daher setzt man Bits über das BitSetResetRegister (BSRR). Damit kann das 
nicht passieren. Welches Bit hier welche Bedeutung hat um den Pin zu 
setzten oder zu löschen ist dem Referenzmanual zu entnehmen.
Mit dem BitResetRegister (BRR) funktioniert im Prinzip genauso wie das 
BSRR, nur das hier nur gelöscht werden kann und die indizierung im 
Register eine andere ist.

Autor: kein gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und wofür benutze ist dann BSRR wenn es mit BRR auch geht?

Bei den meisten Beispielen finde ich immer ODRB != ODRB, nie BRRB != 
BRRB
um Leds zu toggeln z.B.

Autor: NichtWichtig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kein gast schrieb:
> Wo ist der Unterschied bei
> PIO_BSRR
> PIO_BRR?

Das S nicht gesehen ?

Autor: RTFM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kein gast schrieb:
> und wofür benutze ist dann BSRR wenn es mit BRR auch geht?

Schaue dir im RM die Register an. Das BSRR kann setzten und löschen, das 
BRR kann nur löschen. Beim BSRR löscht man jedoch z.B. Port 0 mit Bit 
16, beim BRR Port 0 mit Bit 0.

kein gast schrieb:
> Bei den meisten Beispielen finde ich immer ODRB != ODRB, nie BRRB !=
> BRRB

BRRB != BRRB würde auch nicht funktionieren. Lese im RM wie der Zugriff 
funktioniert. Für "sauberes" Toggeln müsst man sowas machen
GPIOX->BSRR = (GPIOX->ODR ^ GPIO_PIN_xx) | (GPIO_PIN_xx << 16);

Autor: RTFM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RTFM schrieb:
> GPIOX->BSRR = (GPIOX->ODR ^ GPIO_PIN_xx) | (GPIO_PIN_xx << 16);

oder auch nicht. Naja so ähnlich

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kein gast schrieb:
> und wofür benutze ist dann BSRR wenn es mit BRR auch geht?

In BRR muss man etwas anderes reinschreiben um den "S" Effekt zu haben.

> Bei den meisten Beispielen finde ich immer ODRB != ODRB, nie BRRB !=
> BRRB
> um Leds zu toggeln z.B.

BRR und BSRR lässt sich nicht lesen, das ist dazu da, atomar Bits zu 
setzen oder zu löschen. Atomar heisst, dass nichts dazwischenfunken 
kann.

In Wirklichkeit passiert etwas in der Art wenn man BRR schreibt:

* ODR wird eingelesen
* die Bits die man in BRR in den unteren 16 Bit gesetzt hat werden 
gesetzt, die Bits die in den oberen 16 Bit gesetzt hat werden gelöscht
* Neuer Wert wird nach ODR zurückgeschrieben.

Führt man das in Software aus benötigt man da gut und gerne 5-10 
Maschinenbefehle je nach dem was man genau macht. Diese Sequenz kann 
durch einen Interrupt unterbrochen werden. Wird im Interrupt dann der 
selbe Port benutzt (sprich Pins getoggelt o.ä.) gehen diese Änderungen 
verloren wenn die Sequenz nach Ende des Interrupts fortgesetzt wird.

Daher müsste man korrekterweise immer die Unterbrechungsanforderungen 
sperren, dann ODR manipulieren, dann die Unterbrechungsanforderungen 
wieder zulassen bzw. den vorherigen Zustand restaurieren. Das ist recht 
aufwändig und kostet auch einiges an Rechenzeit, darum gibt es den BRR 
uns BSRR Mechanismus, der das in Hardware erledigt, und nicht 
unterbrochen werden kann.

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:
> kein gast schrieb:
>> und wofür benutze ist dann BSRR wenn es mit BRR auch geht?

möglicherweise habe ich BSRR und BRR vertauscht. sorry.

Autor: kein gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also entspricht das schalten der Pins bei einem ATmega eher den GPIO_ODR 
Befehl?
Und das BSRR und BRR ist eher eine verbesserte Variante? Ähnlich wie bei 
der ATXMega Serie?

Autor: kein gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
???

Autor: Stefan F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kein gast schrieb:
> also entspricht das schalten der Pins bei einem ATmega eher den GPIO_ODR
> Befehl?

Die GPIO_ODR Register entsprechen den PORT Registern der AVR 
Mikrocontroller.

> Und das BSRR und BRR ist eher eine verbesserte Variante? Ähnlich wie bei
> der ATXMega Serie?

"Verbessert" ist relativ. Damit kannst du einzelne Bits ändern, ohne das 
GPIO_ODR Register vorher lesen zu müssen. Dadurch entfällt die sonst 
notwendige UND bzw ODER Verknüpfung mit dem alten Zustand.

Die AVR können das mit ihren CBI und SBI Befehlen auch, welche der 
C-Compiler automatisch einsetzt. Die brauchen dafür keine extra 
speziellen Register.

Kennst du diese Seite schon?: http://stefanfrings.de/stm32/stm32f1.html

Autor: W.S. (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Stefan F. schrieb:
> Die GPIO_ODR Register entsprechen den PORT Registern der AVR
> Mikrocontroller.

Nicht so ganz. Man hat hier GPIO_IDR und GPIO_ODR - und das ist nicht 
exakt dasselbe.

Generell muß man sagen, daß es bei den meiten Cortexen weitaus mehr 
Möglichkeiten gibt, mit den Portpins umzugehen als bei den kleineren 8 
Bit Controllern.

Das sind bei manchen Typen eben W/O-Register zum selektierten 
Setzen/Rücksetzen von Pins und bei anderen eben auch Arrays von Bools 
als Bytes bis hin zu LongBools, um separat auf Portbits zugreifen zu 
können. Sowas schafft bei gezieltem Einsatz in den Lowlevel-Treibern 
einiges an Effizienz.

OK, es gibt aber auch taube Nüsse unter den Cortexen. Darf man auch 
nicht vergessen.

W.S.

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit BSRR kann man auch wunderbar "Bitfields" auf IO-Ports legen. Der 
Trick ist, daß Set Prio über Reset hat.
Wenn z.B. Bit5..2 einen 4-Bit Wert darstellen sollen,
kann man damit:
for(int i=0;i<16;i++) {
  GpioA->BSRR = 0b1111<<(16+2)     // Pin5..2 löschen
              | ((i & 0b1111)<<2); // Pin5..2 In i gesetzte Bits setzen
}
die IO-Pins "hochzählen", bzw. auf einen beliebigen (Variablen) Wert 
setzen, wenn diese 4Bit z.B. D3..7 eines typischen LCD darstellen 
sollen.

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan F. schrieb:
> kein gast schrieb:
>> also entspricht das schalten der Pins bei einem ATmega eher den GPIO_ODR
>> Befehl?
.
> Die GPIO_ODR Register entsprechen den PORT Registern der AVR
> Mikrocontroller.
.
>> Und das BSRR und BRR ist eher eine verbesserte Variante? Ähnlich wie bei
>> der ATXMega Serie?
.
> "Verbessert" ist relativ. Damit kannst du einzelne Bits ändern, ohne das
> GPIO_ODR Register vorher lesen zu müssen. Dadurch entfällt die sonst
> notwendige UND bzw ODER Verknüpfung mit dem alten Zustand.
>
> Die AVR können das mit ihren CBI und SBI Befehlen auch, welche der
> C-Compiler automatisch einsetzt. Die brauchen dafür keine extra
> speziellen Register.
so man sich auf einzelne Bits beschränkt.

Autor: Stefan F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Nicht so ganz. Man hat hier GPIO_IDR und GPIO_ODR - und das ist nicht
> exakt dasselbe.

Dementsprechend haben AVR PIN und PORT Register. Das war schon richtig.

> Das sind bei manchen Typen eben W/O-Register zum selektierten
> Setzen/Rücksetzen von Pins
> Sowas schafft bei gezieltem Einsatz in den Lowlevel-Treibern
> einiges an Effizienz.

AVR sind beim Setzen, Löschen und Abfragen einzenler Bits effizienter, 
weil sie dafür besondere CPU Befehle haben.

Die "kleinen" Aufgaben erfüllen AVR mit halber Taktfrequenz und nur 
einem Bruchteil des Speicher genau so schnell - teilweise sogar 
schneller.

Carl D. schrieb:
> so man sich auf einzelne Bits beschränkt.

Ja, dieser Vorteil gilt nur für einzelne Bits.

: Bearbeitet durch User
Autor: W.S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Stefan F. schrieb:
> AVR sind beim Setzen, Löschen und Abfragen einzenler Bits effizienter,
> weil sie dafür besondere CPU Befehle haben.

Sieht bei den PIC's genauso aus: BSF, BCF, BTFSZ usw.

Der Grund hinter sowas ist, daß die Architektur anders ist, nämlich 
Harvard. Bei v.Neumann kann man sich sowas ohne Verrenkungen nicht 
leisten.

W.S.

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.

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