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
Die 16-bit Beschraenkung erlaubt mittels BSRR Register atomar Bits zu setzen und rueckzusetzen.
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.
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 ;)
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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 ;-)
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.
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.
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.
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.
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.
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.
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?
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).
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.
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
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
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).
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.
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
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 ?
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
>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.
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.
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.
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.
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.
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?
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...
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.
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
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.