Forum: Mikrocontroller und Digitale Elektronik Warum sind STM32 I/Os auf 16 Bit kastriert?


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 Marko R. (dr_marko_rocznik) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Die STM32-Kontroller sind 32Bit.
Ihre I/O-Ports aber nur 16 Bit breit.
Wieso?

Der ARM-Core hat ganz normal die 32 Bit, an dem liegt es nicht. Wenn man 
in die Register-Map reinschaut, dann kann man sogar die für die Bits 
hoch bis zum 32ten die "GPIO alternate function" setzen, beim GPIO port 
output data register wurde dann aber auf 16 kastriert.

Gibt es da irgend eine Logik dahinter?

Marko

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Bewertung
0 lesenswert
nicht lesenswert
Die 16-bit Beschraenkung erlaubt mittels BSRR Register atomar Bits zu 
setzen und rueckzusetzen.

von Thorsten S. (thosch)


Bewertung
0 lesenswert
nicht lesenswert
Das vereinfacht atomische Zugriffe zum gleichzeitigen Setzen, und 
Löschen von Portbits via BSRR Register und ermöglicht einen einfachen 
Zugriffsschutz z.B. im LCKR via Bit 16.

von Bauform B. (bauformb)


Bewertung
1 lesenswert
nicht lesenswert
Uwe B. schrieb:
> Die 16-bit Beschraenkung erlaubt mittels BSRR Register atomar Bits zu
> setzen und rueckzusetzen.

Kein Nachteil ohne Vorteil :) Mit zwei BSRR könnte man das auch für 
32-Bit-Ports haben; o.k., nur für jeweils den halben Port, aber für alle 
anderen Zwecke wären es 32 Bit.

Thorsten S. schrieb:
> ermöglicht einen einfachen Zugriffsschutz z.B. im LCKR via Bit 16.

und das eine Bit könnte man nirgendwo anders unterbringen?

Gibt es eine Logik dahinter,
warum viele Register neuerdings nicht mehr im BitBand-Adressraum liegen,
warum das Lockup Signal der CPU ignoriert wird,
warum Bits und Register beim F2 und L4 unterschiedliche Namen haben,
warum die Hälfte der Pins verschoben wird, wenn man Pins für die 
externe Core-Versorgung frei macht,
warum das FlashSize Register diverse Adressen hat oder ganz fehlt,
warum die Flash-Größe so kodiert ist: 0=A, 8K=3, 16K=4, 32=6, 64=8, 
128=B, 192=Z, 256=C, 384=D, 512=E, 640=Y, 768=F, 1024=G,

Franzosen und Italiener kennen sich eben mit Essen und Trinken aus. 
Dafür sind die STM32 doch relativ gut gelungen ;)

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Uwe B. schrieb:
> 16-bit Beschraenkung erlaubt mittels BSRR Register atomar Bits zu setzen

Die LPC können auch mit 32-bit I/O atomar Bits setzen

Der tatsächliche Grund dürfte darin liegen dass die STM32 I/O IP vom 
STM8 abgeleitet wurde.

von Gerd E. (robberknight)


Bewertung
1 lesenswert
nicht lesenswert
Lothar schrieb:
> Die LPC können auch mit 32-bit I/O atomar Bits setzen

Und wie soll das bei einem 32-Bit-Prozessor funktionieren?

Du brauchst entweder ein set-bit und ein reset-bit pro io-pin oder ein 
mask-bit und ein value-bit pro io-pin. Wenn Du aber nur 32 bit 
gleichzeitig in ein Register schreiben kannst, bekommst Du so nur 16 
io-pins bedient.

Man könnte jetzt natürlich ein separates Register einführen und dort die 
Mask ablegen, aber das widerspricht ja genau dem Gedanken des atomaren 
Zugriffs.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Du brauchst entweder ein set-bit und ein reset-bit pro io-pin

Das ist das, was andere machen: ein BITSET-Subregister und ein 
BITCLR-Subregister.

Das Einzige, was mit dieser (außerhalb der STM-Welt recht eigenwillig 
anmutenden) BSRR-Mimik geht und mit den anderen Varianten nicht ist, 
dass man atomar im Port gleichzeitig einzelne Bits setzen und andere 
löschen kann. Dürfte allerdings ein eher selten genutztes Feature sein.

Bauform B. schrieb:
> warum viele Register neuerdings nicht mehr im BitBand-Adressraum liegen,

Nun ja, beim Cortex-M7 (und neuer) hat man das Bitbanding gleich ganz 
weggelassen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Lothar schrieb:
> Der tatsächliche Grund dürfte darin liegen dass die STM32 I/O IP vom
> STM8 abgeleitet wurde.

Klingt plausibel.

Was außerdem gegen die These spricht, man hätte das nur wegen BSRR 
gemacht: es betrifft ja alle Peripherals, auch bspw. Timer, die 
durchaus von einem zusammenhängenden 32-bit-Zählregister profitieren 
würden.

Selbst Atmel hat bei den Timern aber einen ziemlichen Mischmasch, obwohl 
sie generell auf ARM 32-bit-IO-Register unterstützen. Teilweise muss man 
da 16-bit-Timer kaskadieren, teilweise gibt es echte 32-bit-Timer.

von Hermann K. (r2d2)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Lothar schrieb:
>> Der tatsächliche Grund dürfte darin liegen dass die STM32 I/O IP vom
>> STM8 abgeleitet wurde.
>
> Klingt plausibel.

Klingt für mich überhaupt nicht plausibel. Der STM8 ist ein 8-Bitter und 
kann mit 16 Bit breiten Ports nicht viel anfangen. Außerdem sind die 
IO-Funktionen beim STM8 wesentlich eingeschränkter als bei STM32.

Die werden sich einfach überlegt haben was ihnen sinnvoller erscheint: 
32 Bit breite Ports und dafür die oben genannten Zusatzfunktionen nicht 
oder nur 16 Bit breite Ports. Mir persönlich fallen außer ein paar ganz 
exotischen Sachen keine wirklichen Anwendungen für 32 Bit ein. Breite 
parallele Datenbusse sind ja heutzutage doch sehr außer Mode. In 
einzelnen Bereichen (z.B. LCDs) wo das tatsächlich mal Verwendung findet 
läuft die Ansteuerung üblicherweise über spezielle Funktionsblöcke und 
nicht über GPIOs.

Vielleicht kann ja mal jemand der sich einen 32 Bit Port wünscht sagen 
wofür er ihn gerne hätte.

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Und wie soll das bei einem 32-Bit-Prozessor funktionieren?

Die LPC haben wie 8051 einen bitaddressierbaren Speicherbereich - kein 
Bitbanding Read-Modify-Write auf dem Bus - wo jeder Pin auf ein Byte 
gemappt ist und mit MOV#1STRB und MOV#0STRB atomar auf high und low 
gesetzt werden kann.

Das geht dann auch in C ähnlich 8051 also P0_0=1 oder P0_31=0

von drm (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Der Speicherbus/die Registerbreite des Cortex-M steht in keiner 
logischen Verbindung mit der Organisation der IO-Pin Funktion. Da der 
Prozessor mit Vielfachen von 8Bit bevorzugt rechnen kann ist es logisch, 
auch für jede Peripherie ebenfalls ein Vielfaches von 8 Bit zu benutzen.

Beim STM32 gibt es genug uC Varianten, wo ein IO-Port keine 16 Bit hat 
sondern weniger, je nach Anzahl der Pins des uC-Gehäuses.

Da alle Pins am uC Mehrfachbelegungen hat macht es keinen Sinn, einen 
32bit IO-Port zu definieren, da die Wahrscheinlichkeit hoch ist, das ein 
IO-Port dann nur noch teilweise frei ist.

Wer einen schnellen Zugriff auf externe Komponenten haben will über den 
uC-Bus muss einen uC wählen, bei dem man externen Speicher anbinden 
kann. Die Pins für Daten-/Addressbus sind dann aber meist wild über alle 
IO-Ports verstreut.

Es gibt viele Beispiele wo man mit schnellen IO-Port Zugriffen einen 
Daten-/Adressbus simuliert, z.B. bei Displaycontroller mit eigenem 
Speicher, aber das ist meistens nur dem persönlichen Geiz geschuldet, 
einen preiswerten uC zu verwenden oder dem Ehrgeiz zu zeigen das mit 
Timinggenauer Programmierung die Einschränkungen des uC umgehen zu 
können.

von Axel S. (a-za-z0-9)


Bewertung
2 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Lothar schrieb:
>> Die LPC können auch mit 32-bit I/O atomar Bits setzen
>
> Und wie soll das bei einem 32-Bit-Prozessor funktionieren?
>
> Du brauchst entweder ein set-bit und ein reset-bit pro io-pin oder ein
> mask-bit und ein value-bit pro io-pin.

Ja. Aber die müssen ja nicht im gleichen Register liegen. Du könntest 
z.B. je ein 32-Bit Register für SET, RESET und TOGGLE vorsehen. Dann 
kannst du 1..32 Bit atomar setzen, rücksetzen oder togglen. Das dürfte 
alles sein, was man braucht.

von Walter T. (nicolas)


Bewertung
2 lesenswert
nicht lesenswert
Axel S. schrieb:
> Dann
> kannst du 1..32 Bit atomar setzen, rücksetzen oder togglen. Das dürfte
> alles sein, was man braucht.

Einen X Bit breiten Bereich auf ein bestimmtes Bitmuster zu setzen ist 
auch nicht verkehrt.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Axel S. schrieb:
> Das dürfte alles sein, was man braucht.

Man kann noch eins vorsehen, mit dem die Portpins absolut auf einen 
neuen Wert festgesetzt werden. Ja, das ist dann alles.

TOGGLE braucht man nicht einmal unbedingt, haben bspw. größeren SAMs von 
Atmel/Microchip nicht. Macht es nur etwas umständlicher, wenn man 
wirklich toggeln will, weil man erst den aktuellen Zustand abfragen 
muss.

drm schrieb:
> Da alle Pins am uC Mehrfachbelegungen hat macht es keinen Sinn, einen
> 32bit IO-Port zu definieren, da die Wahrscheinlichkeit hoch ist, das ein
> IO-Port dann nur noch teilweise frei ist.

Seltsam, dass das offenbar nur STM so sieht. Andere Hersteller haben 
32-bit-Ports im Angebot, und bei STM zieht sich das ja auch in andere 
Peripherals weiter, für die "echte" 32-bittige Register schon Sinn 
hätten. Timer nannte ich bereits. (Mit "echte" meine ich jetzt nicht 
sowas wie das Zählerregister, bei dem die unteren 16 Bits der Zählerwert 
sind und in Bit 31 dann noch das Interruptflag gemappt ist.)

: Bearbeitet durch Moderator
von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Man kann noch eins vorsehen, mit dem die Portpins absolut auf einen
> neuen Wert festgesetzt werden. Ja, das ist dann alles.

Das ist alles, was es ursprünglich gab, sei es 8051, AVR, PIC & Co. Ein 
einfaches Register, mit welchen durch Read-Modify-Write die IOs 
geklimmpert wurden. Erst mit den "neumodischen" 32 Bit ARM kamen die 
SET/CLEAR/TOGGLE Register auf, eben weil die ARMs durch ihr Pipelining 
sowie die bisweilen langsame Busanbindung der IO-Register und was weiß 
ich plötzlich sehr lahmarschig beim IO-Klimpern (aka Bit Banging) waren.

> TOGGLE braucht man nicht einmal unbedingt, haben bspw. größeren SAMs von
> Atmel/Microchip nicht. Macht es nur etwas umständlicher, wenn man
> wirklich toggeln will, weil man erst den aktuellen Zustand abfragen
> muss.

Eben das will man nicht, siehe oben!

> Seltsam, dass das offenbar nur STM so sieht. Andere Hersteller haben
> 32-bit-Ports im Angebot, und bei STM zieht sich das ja auch in andere
> Peripherals weiter, für die "echte" 32-bittige Register schon Sinn
> hätten. Timer nannte ich bereits.

Also ich halte 32 Bit IO-Register für eher nachteilig, denn bei den 
Zugriffen braucht es größere oder mehr Befehle als bei 16 Bit Zugriffen, 
was die ganze Sache wieder langsamer macht. Wie schon jemand schrieb, 
ist eine Anwendung mit 32 Bit Datenbus, welche mit einer Anweisung ggf. 
atomar geschrieben werden soll oder muss extrem exotisch. Das einfache, 
schnelle Bitgeklimper ist da DEUTLICH öfter anzutreffen, wenn gleich das 
nicht die Kernkompetenz hochgetakteter ARM-Boliden ist. Für sowas gibt 
es ja 8 Bit Fußvolk ;-)

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> TOGGLE braucht man nicht einmal unbedingt, haben bspw. größeren SAMs von
> Atmel/Microchip nicht.

Was hat die Größe damit zu tun? :-)
Du meinst sicher die x70/x71, nur sind die vergleichsweise alt und 
ziemlich seltsam.

Die neueren E5x/D5x haben set, clear, toggle, genau wie die C2x.
Und die noch neueren L1x mit Cortex-M23 haben das auch.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Rudolph schrieb:
> Was hat die Größe damit zu tun? :-)

"Groß" im Sinne von "Dinosaurier". :) Sind halt die alten Peripherals, 
wie es sie schon bei SAM3 und SAM4 gab.  SAMD und dessen Nachkömmlinge 
haben eine deutlich andere Peripherie, aber zumindest anfänglich waren 
das vergleichsweise kleine Controller (verglichen mit den Dinosauriern).

Ich finde SAMD & Co. da auch angenehmer.

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> sei es 8051, AVR, PIC & Co. Ein einfaches Register,
> mit welchen durch Read-Modify-Write

Der 8051 hat im Gegensatz zu AVR, PIC einen bitaddressierbaren 
Speicherbereich und braucht kein Read-Modify-Write. Und die ARM mit 
bitaddressierbaren Speicherbereich auch nicht. Die aktuellen 8051 
brauchen dafür nur 1 Zyklus. Die ARM 2 Zyklen.

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also ich mag das BSRR ausgesprochen gerne, und das geht so atomar halt 
nur mit 16 Pins und Registern mit 32 bit. Mehr als 16 Pins mußte ich 
noch nie auf einmal wackeln.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Nop schrieb:
> und das geht so atomar halt nur mit 16 Pins und Registern mit 32 bit.

Diese Aussage wurde weiter oben bereits widerlegt, andere ARMs haben da 
kein Problem damit, das auch 32bittig zu machen.

> Mehr als 16 Pins mußte ich noch nie auf einmal wackeln.

Das ist 'ne andere Sache.

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:

> Diese Aussage wurde weiter oben bereits widerlegt

Nein, wurde sie nicht. Entweder braucht man dann zwei Register (hallo, 
atomarer Zugriff?), oder man muß read-modify-write machen (auch nicht 
atomar).

> Das ist 'ne andere Sache.

Das ist genau dieselbe Sache, weil man so prinzipbedingt nicht mehr als 
16 Pins auf einmal handhaben kann. Aber 32 Pins auf einmal habe ich noch 
nicht gebraucht.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Falk B. schrieb:
>> sei es 8051, AVR, PIC & Co. Ein einfaches Register,
>> mit welchen durch Read-Modify-Write
>
> Der 8051 hat im Gegensatz zu AVR, PIC einen bitaddressierbaren
> Speicherbereich und braucht kein Read-Modify-Write.

Dafür sind die Standard 8051 mit 12:1 Quarz / Maschinentakt 
schnachlangsam. Jaja, es gibt modernere Typen mit besserem Verhältnis.

> Und die ARM mit
> bitaddressierbaren Speicherbereich auch nicht.

Stimmt so allgemein nicht, zumindest war das von >10 Jahren nicht so.

> Die aktuellen 8051
> brauchen dafür nur 1 Zyklus. Die ARM 2 Zyklen.

Ja sicher, und wozu dann der "Luxus" mit den SET/RESET Registern, wenn 
das die CPU doch in Null-Komma-Nix kann?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Nop schrieb:
> Entweder braucht man dann zwei Register

Wann musst du schon mal in einem Portregister Bits gleichzeitig setzen 
und löschen? Nur für diesen Fall würde das 2x16bittige BSRR einen 
Vorteil bringen.

Ja, zwei Register, natürlich. Eins zum Setzen, eins zum Löschen von 
Bits. (Und ein drittes zum Toggeln, wurde erwähnt; das passt in das 
BSRR-Konzept dann auch nicht mehr rein.)

>> Das ist 'ne andere Sache.
>
> Das ist genau dieselbe Sache,

Nein, weil sich die 16-bitterei bei STM32 halt durch alle Peripherals 
zieht, nicht nur durch die für die IO-Pins.

Es gibt da ein paar künstlich zusammengepfropfte Peripherieregister (wie 
BSRR ja auch eins ist), aber weitgehend durchgängig 32-bittige 
Peripherieregister hat STM nicht (die Konkurrenz sehr wohl).

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:

> Wann musst du schon mal in einem Portregister Bits gleichzeitig setzen
> und löschen?

Was ist mit parallel IO?

> Nein, weil sich die 16-bitterei bei STM32 halt durch alle Peripherals
> zieht, nicht nur durch die für die IO-Pins.

Ja, das ist ein gültiger Punkt.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Nop schrieb:
>> Wann musst du schon mal in einem Portregister Bits gleichzeitig setzen
>> und löschen?
>
> Was ist mit parallel IO?

Dafür würde ich eher ein Register brauchen, bei dem ich alle Bits 
gleichzeitig überschreiben kann. Mit BSRR muss man ja dann den 
16-Bit-Wert nochmal negieren und in die andere Hälfte schieben, damit 
man sicherstellen kann, dass alle Bits passend gleichzeitig gesetzt bzw. 
gelöscht werden.

So hat ein SAMD (und seine Nachfolger) halt ein OUT, OUTSET, OUTCLR und 
OUTTGL, jedes davon 32bittig. Natürlich betrifft es nur die Portpins, 
die auch wirklich auf Ausgang stehen und die nicht für periphere 
Sonderfunktionen umgelenkt worden sind.

Versteh mich nicht falsch: STM32 hat viele schöne Features, und an 
manchen Stellen haben sie die Nase vor der Konkurrenz vorn (bzw. waren 
jeweils früher damit auf dem Markt), aber die 16-Bit-Peripherie gehört 
eher nicht zu den starken Seiten.

: Bearbeitet durch Moderator
von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Mit BSRR muss man ja dann den
> 16-Bit-Wert nochmal negieren und in die andere Hälfte schieben, damit
> man sicherstellen kann, dass alle Bits passend gleichzeitig gesetzt bzw.
> gelöscht werden.

Zum Glück nicht. Da Setzen eine Prävalenz gegenüber löschen hat, reicht 
es aus, in die vorderen 16 Bit eine konstante Maske zu schreiben.

(" If there is an attempt to both set and reset a bit in GPIOx_BSRR, the 
set action takes priority.")

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Walter T. schrieb:
> Da Setzen eine Prävalenz gegenüber löschen hat, reicht es aus, in die
> vorderen 16 Bit eine konstante Maske zu schieben.

OK, alle löschen und nur die Setzen, die man braucht. ;-) Ist trotzdem 
irgendwie von hinten durch die Brust ins Auge …

Aber letztlich, wie Falk schon schrieb, die großartigen Bitbanger sind 
ARMs sowieso nicht. Das wird sich also eher in Grenzen halten, was man 
damit in der Praxis anstellt (und hat sich auch bei all meinen 
bisherigen Projekten, egal ob privat oder dienstlich).

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:

> Dafür würde ich eher ein Register brauchen, bei dem ich alle Bits
> gleichzeitig überschreiben kann.

Das könntest Du dafür nicht nutzen, denn wenn Du 32 Pins in einem 
Register haben willst, aber ja wohl kaum 32-bittig PIO machst, dann 
läuft es doch wieder auf read, modify, write hinaus.

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> die großartigen Bitbanger sind ARMs sowieso nicht

LPC810 - atomic 1 cycle wenn man 0 und 1 vorher vorhält:

        LDR  R1, PIN0BASE       ; R1=PIN0BASE=0xA0000000

        MOVS R2, #0
        MOVS R3, #1

        STRB R2, [R1, #4]       ; clear P0_4
        STRB R3, [R1, #4]       ; set P0_4

von KM (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Dafür würde ich eher ein Register brauchen, bei dem ich alle Bits
> gleichzeitig überschreiben kann. Mit BSRR muss man ja dann den
> 16-Bit-Wert nochmal negieren und in die andere Hälfte schieben, damit
> man sicherstellen kann, dass alle Bits passend gleichzeitig gesetzt bzw.
> gelöscht werden.

Na wenn man alle 16Bit gleichzeitig beschreiben will nimmt man doch das 
ODR Register, oder ?

von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
KM schrieb:
> Na wenn man alle 16Bit gleichzeitig beschreiben will nimmt man doch das
> ODR Register, oder ?

Manchmal willst Du nur 4 oder 8 Bit beschreiben und die restlichen in 
Ruhe lassen. Über ODR benötigst Du eine read-modify-write-Operation. Mit 
BSSR musst Du zwar auch ein paar Bit vorher sortieren, aber die 
eigentliche Schreiboperation ist atomar.

: Bearbeitet durch User
von KM (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Manchmal willst Du nur 4 oder 8 Bit beschreiben ...

Schon klar, aber Jörgs Wunsch bezog sich doch auf die vollen 16Bit ohne 
das
BSRR gefummel.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Walter T. schrieb:
> Manchmal willst Du nur 4 oder 8 Bit beschreiben und die restlichen in
> Ruhe lassen.

4 Bit ist so ziemlich das Einzige, wo BSRR wirklich im Vorteil ist.

Bei 8 Bit muss man bei Konzepten wie beim SAMD nur zusehen, dass man 
halt die 8 Bits eines Bytes zusammenhängend benutzt (also 0 bis 7 oder 
24 bis 31, aber nicht sowas wie 4 bis 11), dann darf man dort auf das 
OUT-Register auch mit einem 8-Bit-Zugriff schreiben, der ist dann wieder 
atomic.

von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> 4 Bit ist so ziemlich das Einzige, wo BSRR wirklich im Vorteil ist.

2, 3, 5, 6, 7, 9, 10, 11, 12, 13, 14 und 15 Bit auch. :-)

Spaß beiseite: Ich kenne SAMD nicht, habe dazu also keine qualifizierte 
Meinung. Ich gehe davon aus, dass man mit allen Plattformen sinnvoll 
arbeiten kann, sonst wären sie schon längst in der Vergessenheit 
verschollen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Walter T. schrieb:
> Ich gehe davon aus, dass man mit allen Plattformen sinnvoll arbeiten
> kann, sonst wären sie schon längst in der Vergessenheit verschollen.

Sehe ich genauso.

Die 16-bit-Peripherals des STM32 sehen auf den ersten Blick etwas 
gewöhnungsbedürftig aus, wenn man von anderen Plattformen kommt, aber 
natürlich kann man damit genauso arbeiten wie mit den anderen. Die von 
mir genannten "Dinosaurier"-SAMs muten an anderen Stellen manchmal etwas 
eigenwillig an, wenn man beispielsweise die (eigentlich schon üppigen) 4 
CS-Leitungen eines SPI-Peripherals auch noch alternativ so verschalten 
kann, dass sie einen externen 1-aus-16-Decoder ansteuern …

Irgendwelche Ecken und Kanten gibt's bei jeder Designentscheidung 
sowieso.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Die 16-bit-Peripherals des STM32 sehen auf den ersten Blick etwas
> gewöhnungsbedürftig aus, wenn man von anderen Plattformen kommt, aber
> natürlich kann man damit genauso arbeiten wie mit den anderen.

Ihr habt jetzt ne Menge über die Ports als solche (GPIO) diskutiert. Da 
sehe ich das auch so, daß man mit 16 Bit Ports durchaus zurechtkommt.

Was mir bei einigen älteren STM-Chips sauer aufgestoßen ist, sind all 
die anderen Peripherien: nur 16 Bit Counter/Timer (dafür aber mit 
Prescaler), simplere I2S/SPI-Cores, die pro Frame dann 4 Zugriffe 
benötigen (aber nicht am Stück, so daß man zusätzlich noch DMA bemühen 
muß) und so weiter.

W.S.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Was mir bei einigen älteren STM-Chips sauer aufgestoßen ist

Ich finde das Memory Mapping der USB Einheit gruselig. Du kennst das 
doch auch, sind andere Mikrocontroller in dieser Hinsicht handlicher?

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Bewertung
1 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> W.S. schrieb:
>> Was mir bei einigen älteren STM-Chips sauer aufgestoßen ist
>
> Ich finde das Memory Mapping der USB Einheit gruselig. Du kennst das
> doch auch, sind andere Mikrocontroller in dieser Hinsicht handlicher?

USB bei STM ist zugekaufte IP. Die Registeraufteilung sollte dan auch 
bei anderen Inkarnationen der IP zu finden sein...

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Ich finde das Memory Mapping der USB Einheit gruselig. Du kennst das
> doch auch, sind andere Mikrocontroller in dieser Hinsicht handlicher?

Haha, genau DAS Thema hatten wir doch bis zum Abwinken schon mal. 
Natürlich ist das gruselig, insbesondere solange, wie man den ganzen 
Kram nicht selbst ausprobiert hat, um zu kapieren, was das Geschwurbel 
im RefMan eigentlich rüberbringen wollte. Aber wenn man das erledigt und 
in einen LL-Treiber gepackt hat, ist die Sache ausgestanden.

Und andere µC sind halt anders, insbesondere beim USB-Core. Streß mit 
dem Mapping im Pufferbereich gibt es da zumeist nicht, allerdings ist 
bei Cores, die tatsächlich auf Durchsatz getrimmt sind, das Hampeln 
zwischen zwei im Wechsel zu betreibenden Puffern eine Unannehmlichkeit, 
der man sich nur dann unterzieht, wenn es z.B. ein Audio-Streaming oder 
Massenspeicher sein soll. Für den simplen virtuellen COM Port kann man 
sich das sparen. Dort ist es eher notwendig, daß das Schalten des NAK-BI 
sauber funktioniert, um die Stoßstelle zwischen dem block-synchronen 
Betrieb am USB und dem asynchronen Betrieb des COM-Ports in den Griff zu 
kriegen. Ich hatte vor einiger Zeit das große Kopfschütteln gekriegt, 
als da jemand partout dem USB-Core bei meinem Treiber für die F103 
zwischen die Rippen grabschen wollte, bloß weil ein Esel auf der 
PC-Seite den Kanal µC-->PC hat überlaufen lassen. Die Folge war, daß 
seine Version nun den Fifo im Treiber quasi überbrückt und unwirksam 
macht, bloß um bei jeder Gelegenheit die Restbestände (die fast immer 
nur 1 Byte sind) mitgewalt zu "flushen". Damit muß sich nun die 
UART-Seite um die inneren Befindlichkeiten des USB scheren. Nun, das ist 
ne Folge der beim F103 fehlenden Möglichkeit, per Programm die 
Flußkontrolle zu lenken. Sowas hatte ich übrigens beim Core des LPC2478 
und des LPC4088 gemerkt: Beim älteren LPC2478 funktioniert die 
Flußkontrolle per NAK-BI tadellos, aber bei den Exemplaren des LPC4088, 
der den gleichen USB-Core benutzt, kriegt man NAK-BI nur einmal 
umgeschaltet und dann ist es fixiert bis zum nächsten Reset. Ich hatte 
das dort dann per Software-Flag erledigt. Ist etwas weniger nett, geht 
aber.

Und die Cores bei Nuvoton sind noch um einiges anders.

Die USB-Cores bei anderen µC sind an manchen Stellen handlicher, an 
anderen Stellen aber nur anders gestrickt und die zugehörigen Kapitel in 
den RefMan's sind oft genug unverständlich und teilweise grob 
fehlerhaft. Manchmal stößt an auch auf ne üble Firmenpolitik: bei den 
LPC11Uxx gibt es im RefMan (UM10462) ein deutlich abgemagertes Kapitel 
für den eigentlichen USB-Core, weil diese Chips ja im ROM bereits einige 
Hersteller-Routinen haben, auf die sicherlich LpcXpresso aufsetzt und 
das wollen sie befördern. Also wird im Kapitel davor lang und breit über 
eben diese Rom-Routinen gelabert, aber eben nur gelabert und fast nichts 
gesagt.

Kann mich noch entsinnen, daß beim LPC2478 die Kommandos für SIE-RD und 
SIE-WR im Manual vertauscht waren und ich mir fast den Wolf gesucht 
hatte. Antwort vom Kundendienst von NXP war: "och, der 2478 ist ja nun 
schon alt, da korrigieren wir das Manual nicht mehr, ist zu mühsam und 
die Jungs von der Doku haben alle Hände voll mit was anderem zu tun." Da 
kommt Freude auf bei unsereinem, kannste wissen!

Fazit:
Man stößt häufiger als einem lieb ist, auf Firmenpolitik in den Manuals 
und jede Chipsorte birgt andere Abenteuer. Was beim einen krötig ist, 
ist beim anderen gut, dafür ist dort was anderes krötig.

W.S.

von Lothar (Gast)


Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> USB-Cores bei anderen µC

Auch wenn Du 8-Bit nicht magst, schau Dir mal EFM8UB3 an. Es ist die 3. 
Revision und es wurde alles optimal gelöst. Und gibt ein billiges Eval 
Board mit J-Link:

https://www.silabs.com/documents/public/reference-manuals/efm8ub3-rm.pdf

https://www.silabs.com/development-tools/thunderboard/thunderboard-ub3-kit

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Auch wenn Du 8-Bit nicht magst

Ach nö, das ist eine Unterstellung deinerseits. Allerdings hab ich keine 
wirkliche Lust mehr, auf allzu vielen Baustellen herumzuhopsen.

W.S.

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Bewertung
-2 lesenswert
nicht lesenswert
Jörg W. schrieb:
> dass man atomar im Port gleichzeitig einzelne Bits setzen und andere
> löschen kann. Dürfte allerdings ein eher selten genutztes Feature sein.

Aus der Steuerung von schnellen ereignis-diskreter Prozesse 
(Mealy/Moore-Automaten) als historische Vergangenheit kam das her.

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.