http://ww1.microchip.com/downloads/en/DeviceDoc/40001908A.pdf S.136 Eigentlich bin ich drüber gestolpert, weil OCR1A/OCR1B PD4/5 vertauscht zu sein scheinen, aber das will ich erst mal genauer überprüfen. Könnte ja auch an der header-Datei oder am Board (324PB Xplained) liegen - sowas gravierendes hätte ja schon lange einer bemerken müssen. Da denke ich mal dass der Fehler hier irgendwo liegt.
Angehängte Dateien:
-
324PB.PNG
19 KB
Und was soll da jetzt falsch sein? Das ist schon seit AVR-Urzeiten so. In C sieht man das gar nicht, wenn man die passenden 16Bit Registernamen nutzt.
Richtig, in C merkt man das nicht. Seit Urzeiten ist es aber so: "To do a 16-bit write, the high byte must be written before the low byte". So stehts zumindest in den anderen Datenblättern, und so habe ich es in Assemblerzeiten gemacht.
Hallo H.Joachim S. schrieb: > "To do a 16-bit write, the high byte must be written before the low > byte". > So stehts zumindest in den anderen Datenblättern, und so habe ich es in > Assemblerzeiten gemacht. Volle Zustimmung.
Ist bei den neueren ATtinys auch lt. Datenblatt, z. B. ATtiny1614 S. 53, 8.5.6: For a write operation, the low byte of the 16-bit register must be written before the high byte. The low byte is then written into the temporary register. When the high byte of the 16-bit register is written, the temporary register is copied into the low byte of the 16-bit register in the same clock cycle. For a read operation, the low byte of the 16-bit register must be read before the high byte. When the low byte register is read by the CPU, the high byte of the 16-bit register is copied into the temporary register in the same clock cycle as the low byte is read. When the high byte is read, it is then read from the temporary register. Fehler in den Datenblättern gibt es aber außerdem mehr als genug.
:
Bearbeitet durch User
Hm, haben die das jetzt wirklich geändert?? Muss ich gleich mal ausprobieren. 324PB 8.6 Accessing 16-bit RegistersThe AVR data bus is 8 bits wide, and so accessing 16-bit registers requires atomic operations. Theseregisters must be byte-accessed using two read or write operations. 16-bit registers are connected to the8-bit bus and a temporary register using a 16-bit bus.For a write operation, the low byte of the 16-bit register must be written before the high byte. The low byteis then written into the temporary register. When the high byte of the 16-bit register is written, thetemporary register is copied into the low byte of the 16-bit register in the same clock cycle.For a read operation, the low byte of the 16-bit register must be read before the high byte. When the lowbyte register is read by the CPU, the high byte of the 16-bit register is copied into the temporary registerin the same clock cycle as the low byte is read. When the high byte is read, it is then read from thetemporary register.This ensures that the low and high bytes of 16-bit registers are always accessed simultaneously whenreading or writing the register. edit: So, zumindest beim Mega324PB ist alles beim gewohnten alten geblieben, erst High- dann Lowbyte schreiben.
:
Bearbeitet durch User
Ich tippe ein auf ein Copy & Paste Problem. Der Text wird ja nicht dauernd neu geschrieben sondern auf einer Datenbank rauskopiert. Dort hat sich scheinbar ein Fehler eingeschlichen, der dann kopiert wurde. Denn der 324PB ist ja binärkopatibel zu seinem nicht-PB Bruder, das würde mit einem veränderten Zugriff nicht funktionieren.
:
Bearbeitet durch User
Ja, buntes Durcheinander, gehört aufgeräumt. Tiny441 - korrekt Tiny202/402 - falsch
:
Bearbeitet durch User
H.Joachim S. schrieb: > Tiny202/402 - falsch Warum soll das falsch sein? Der Compiler findet es so richtig.
Passiert auch den besten mal. Schreib denen doch ne nette E-Mail :).
> Der Compiler
Was is'n das? Schmeckt das?
Im Datenblatt vom ATmega328PB Stand Oktober 2015 steht: "To perform a 16-bit write operation, the high byte must be written before the low byte." Im Datenblatt vom Atmega324PB Stand Oktober 2016 steht: "For a write operation, the low byte of the 16-bit register must be written before the high byte." Beide Datenblätter sind (noch) von Atmel. Es scheint hier einen gravierenden leicht übersehbaren Unterschied zwischen den AVR Serien zu geben. Da bin ich echt baff!
Im Silizium gibts keinen Unterschied. Irgendwann hat mal jemand gepfuscht und der Fehler ist nun in etliche Datenblätter gerauscht.
Stefanus F. schrieb: > Im Datenblatt vom ATmega328PB Stand Oktober 2015 steht: > > "To perform a 16-bit write operation, the high byte must be written > before the low byte." Vielleicht kann man das als canonical nehmen: AVR072: Accessing 16-bit I/O Registers http://ww1.microchip.com/downloads/en/AppNotes/doc1493.pdf leo
Nur mal so am Rande, wo liegt der unterschied zwischen dem 328PB und dem 324PB ?
Angehängte Dateien:
-
tiny48.png
8,2 KB -
mega324.png
9,3 KB -
tiny861_wtf.png
10 KB
Bei den neuen Tinys ist das ja andersrum, wie oben geschrieben. Offensichtlich schnallt das der GCC (noch?) nicht. Daher sieht man in den C Beispielen das gleiche Bytegefummel wie in asm. Wollen die einen ver*rschen? (Beweisbilder im Anhang) Aber zum Glück mach ich mit AVRs nix mehr, bin komplett auf ARM ungestiegen. Jedesmal wenn ich noch was an nem alten projekt fixen/erweitern muss komme ich mir vor wie in der Steinzeit. Beim Tiny1614 gibts übrigens auch schon 24Bit Register! 8.5.6.1 Accessing 24-bit Registers For 24-bit registers, the read and write access is done in the same way as described for 16-bit registers, except there are two temporary registers for 24-bit registers . The least-significant byte must be written first when doing a write, and read first when doing a read.
H.Joachim S. schrieb: > Im Silizium gibts keinen Unterschied. Irgendwann hat mal jemand > gepfuscht und der Fehler ist nun in etliche Datenblätter gerauscht. Meinst du keinen Unterschied überhaupt oder nur nicht zwischen verschiedenen ATMegas? Wie ich weiter oben schon schrieb, generiert der GCC-Compiler bei ATtiny Serie 0/1 den korrekten Code lt. Datenblatt. Für andere habe ich es nicht überprüft. Aus aktuellem Code rauskopiert: TCA0.SINGLE.CMP0BUF = TCA_dim2_cmp0; 928: 80 91 0a 38 lds r24, 0x380A ; 0x80380a <TCA_dim2_cmp0> 92c: 90 91 0b 38 lds r25, 0x380B ; 0x80380b <TCA_dim2_cmp0+0x1> 930: 80 af std Z+56, r24 ; 0x38 932: 91 af std Z+57, r25 ; 0x39 Adresse 930/932: Erst low, dann high. @Mw E. (Firma: fritzler-avr.de) (fritzler): wo ist da Gefummel? Ist doch ganz einfach, beide Bytes nacheinander raus mit minimalem Code-Aufwand.
:
Bearbeitet durch User
Wenn ATmega324p und ATmega328p genau umgekehrt funktionieren, dann erzeugt der avg-gcc (Version 5.4.0) aber falschen Code, denn in beiden Fällen beschreibt er zuerst das obere Byte. test.c:
1 | #include <avr/io.h> |
2 | |
3 | int main() |
4 | {
|
5 | OCR1A = 0xAFFE; |
6 | }
|
avr-gcc -O1 -mmcu=atmega328p test.c avr-objdump -h -S a.out
1 | 00000080 <main>: |
2 | 80: 8e ef ldi r24, 0xFE ; 254 |
3 | 82: 9f ea ldi r25, 0xAF ; 175 |
4 | 84: 90 93 89 00 sts 0x0089, r25 ; 0x800089 <__TEXT_REGION_LENGTH__+0x7e0089> |
5 | 88: 80 93 88 00 sts 0x0088, r24 ; 0x800088 <__TEXT_REGION_LENGTH__+0x7e0088> |
6 | 8c: 80 e0 ldi r24, 0x00 ; 0 |
7 | 8e: 90 e0 ldi r25, 0x00 ; 0 |
8 | 90: 08 95 ret |
avr-gcc -O1 -mmcu=atmega324p test.c avr-objdump -h -S a.out
1 | 00000094 <main>: |
2 | 94: 8e ef ldi r24, 0xFE ; 254 |
3 | 96: 9f ea ldi r25, 0xAF ; 175 |
4 | 98: 90 93 89 00 sts 0x0089, r25 ; 0x800089 <__TEXT_REGION_LENGTH__+0x7e0089> |
5 | 9c: 80 93 88 00 sts 0x0088, r24 ; 0x800088 <__TEXT_REGION_LENGTH__+0x7e0088> |
6 | a0: 80 e0 ldi r24, 0x00 ; 0 |
7 | a2: 90 e0 ldi r25, 0x00 ; 0 |
8 | a4: 08 95 ret |
Dieter R. schrieb: > Meinst du keinen Unterschied überhaupt oder nur nicht zwischen > verschiedenen ATMegas? Ich meine bis jetzt nur den 324PB, der verhält sich entgegengesetzt zu den Angaben im Datenblatt so wie es bisher immer war. Bei den series0/1 scheint es tatsächlich genau andersherum zu sein, zumindest meint das auch der Compiler: ; 0003 002D // Set the Timer Counter register ; 0003 002E TCA0.SINGLE.CNT=0x1234; 0000bb e3e4 LDI R30,LOW(4660) 0000bc e1f2 LDI R31,HIGH(4660) 0000bd 93e0 0a20 STS 2592,R30 0000bf 93f0 0a21 STS 2592+1,R31 Halleluja.
H.Joachim S. schrieb: > Halleluja. Ja echt. Und da soll nochmal einer sagen, dass die ARM Controller mehr Fallstricke haben. So langsam beginne ich, daran zu zweifeln.
ATmega48PB/88PB/168PB Bei denen steht auch L/H drin - mit an Sicherheit grenzender Wahrscheinlichkeit kann angenommen werden, dass es nicht so ist.
Marc V. schrieb: > Oder DaBla lesen: Welches von den beiden? Das, welches zuerst low und dann high behauptet, oder das andere? >:-)
Jörg W. schrieb: > Welches von den beiden? Das, welches zuerst low und dann high behauptet, > oder das andere? >:-) Wo wird etwas Gegenteiliges behauptet?
H.Joachim S. schrieb: > ATmega48PB/88PB/168PB > Bei denen steht auch L/H drin - mit an Sicherheit grenzender > Wahrscheinlichkeit kann angenommen werden, dass es nicht so ist. Uff, was für ein Scheiß. Ist hier jemand, der viele AVR's verbaut und das mal wirksam melden kann?
Stefanus F. schrieb: > Ist hier jemand, der viele AVR's verbaut und das mal wirksam melden > kann? Habe ich schon gemacht. Klar ist das alles ziemlich blöd, aber der Hochsprachenprogrammierer merkt davon ja erst mal gar nichts, zumindest wenn der Compilerbauer es richtig macht. Bleibt die Frage ist: wonach richtet sich der? Ich bin da jetzt etwas misstrauisch geworden. Und es ist mir heute erst aufgefallen, dass das bei den neuen Typen tatsächlich andersherum ist. Ist mir jetzt völlig entgangen... Den Assembleranfänger (und letztendlich auch den fortgeschrittenen) trifft so ein Mist natürlich ungebremst.
Also ich hab hier 2 DB aus 2011 von 4er und 8er. 48/88/168 To do a 16-bit write, the high byte must be written before the low byte. For a 16-bit read, the low byte must be read before the high byte. 164/324/644/1284 To do a 16-bit write, the high byte must be written before the low byte. For a 16-bit read, the low byte must be read before the high byte. So, beides gleich ;) Im Makefile gibt man doch den AVR Typ genau an, also der Compiler wirds schon wissen.
Ist das jetzt so, dass die Entwicklungstools und Frameworks zunehmend korrekte Angaben im Datenblatt ersetzen? Ich will zurück in die 80er, wäääääääh.
Mw E. schrieb: > Im Makefile gibt man doch den AVR Typ genau an, also der Compiler wirds > schon wissen. Das hoffst du. Atmel Start sollte z. B. auch wissen, wie man korrekten Initialisierungs-Code generiert. Dafür wird es ja propagiert. Darüber, dass dies bedauerlicherweise nicht immer zutrifft, führe ich derzeit mehrere angeregte Diskussionen mit Microchip. "Ist das jetzt so, dass die Entwicklungstools und Frameworks zunehmend korrekte Angaben im Datenblatt ersetzen?" Ja, schon länger. Dokumentation ist sowas von eighties.
:
Bearbeitet durch User
Dieter R. schrieb: > Atmel Start Ist das so etwas wie Cube MX? Das tut auch oft nicht, was es soll. Warum sollte man auch besser sein, als die (ehemalige) Konkurrenz. Die anderen kochen auch alle nur mit Wasser.
H.Joachim S. schrieb: > Den Assembleranfänger (und letztendlich auch den fortgeschrittenen) > trifft so ein Mist natürlich ungebremst. Jein. Da ist es noch schlimmer. Der Text ist falsch, das Assembler-Beispiel darunter ist noch aus der alten Version und richtig. Man kann es sich aussuchen.
@Dieter R: Ach SO heist dieses Müffelstück was einem erlaubt den UART auf 115200Baud bei 1MHz Sysclk zu setzen? Da gabs ja nen Problem in nem Nachbarfred. Aber jetzt verwechsel mal den GCC nicht mit irgendwelchen Basteltools der Hersteller. (Der GCC hat zwar auch Bugs aber nicht so schlimme) ST CubeMX is nu auch nich so geil, aber das hab ich bei dem auch mal so eingetippt und er hats angemeckert. @Stefanus Bisher sind diese Frameworks ja noch schlimmer. Wenn man nichtmal den DB/RefMan trauen kann, dann wirds auch langsam echt übel. Ich hab heute auf Arbeit nen Bug in einem Devicetreiber vom Hersteller fixen müssen. Der hat auf dem SDIO Blockmodecommandos gesendet, aber im Argument des SDIO Kommandos stand noch Bytemode: Kopf -> Tisch (Dieses gerät ist so komplex, dass es keine Registerbeschreibung gibt, sondern man MUSS deren Treiber nutzen)
Marc V. schrieb: > Ben B. schrieb: >> Ausprobieren. > > Oder DaBla lesen: > > Read: > Low zuerst. > > Write: > High zuerst. Schlaukeks. Es gibt hier sich widersprechende Datenblätter. Bitte lies nochmal genauer nach.
Beitrag #5967086 wurde von einem Moderator gelöscht.
Beitrag #5967119 wurde von einem Moderator gelöscht.
Dieter R. schrieb: > Der Text ist falsch, das > Assembler-Beispiel darunter ist noch aus der alten Version und richtig. Der aktuelle IAR-Compiler erzeugt für 324P und 324PB den gleichen Code. Bei neueren Typen (z.B. ATtiny817) muß jeweils zuerst immer das low-byte angesprochen werden. Aber da ist ja sowieso alles anders.
Beitrag #5967153 wurde von einem Moderator gelöscht.
Beitrag #5967158 wurde von einem Moderator gelöscht.
Marc V. schrieb: > Jörg W. schrieb: >> Welches von den beiden? Das, welches zuerst low und dann high behauptet, >> oder das andere? >:-) > > Wo wird etwas Gegenteiliges behauptet? Lies einfach den Thread, komplett. Mw E. schrieb: > also der Compiler wirds schon wissen. Meinst du, Compiler würden immer wieder mal Datenblätter lesen? ;-) Die derzeitige Reihenfolge ist vor Jahrzehnten in den GCC eingegossen worden, und seither hat da niemand einen Grund gehabt, etwas zu ändern. Dass Microchip nun plötzlich widersprüchliche Datenblätter rausgibt, hat den GCC-Entwicklern (zum Glück :) noch keiner gesagt. (Dass es bei den neuen Tinys andersrum ist, betrifft ein komplett anderes Stück im Compiler. Da war es aber eben auch von Anbeginn so.) Ich habe hier übrigens auch noch ein Datenblatt von 2016 für die PB, noch im Atmel-Outfit, da steht es wie gewohnt (high vor low beim Schreiben). Alles Neuere ist also wohl nur eine Fehlinformation, die da vermutlich jemand von den neueren Serien (vermutlich neben ATtiny ja auch ATmega0) reinkopiert hat.
Jörg W. schrieb: > Mw E. schrieb: >> also der Compiler wirds schon wissen. > > Meinst du, Compiler würden immer wieder mal Datenblätter lesen? ;-) Ich hoff doch, dass unser Johann das richtige DB gelesen hat :) Oder die anderen AVR-GCC Entwickler.
S. R. schrieb: >> >> Read: >> Low zuerst. >> >> Write: >> High zuerst. > > Schlaukeks. Es gibt hier sich widersprechende Datenblätter. Bitte lies > nochmal genauer nach. Nix Schlaukeks. Ich habe mit so ziemlich allen MEGAs gearbeitet, bei allen ist es so, wie oben angegeben. Was der MicroChip jetzt in seinen DaBlas schreibt, ist einfach ein Copy & Paste Fehler. Oder vielleicht Absicht?
Mw E. schrieb: > Ich hoff doch, dass unser Johann das richtige DB gelesen hat Wo steht denn im Datenblatt, ob es das richtige oder falsche ist?
Marc V. schrieb: > Was der MicroChip jetzt in seinen DaBlas schreibt, ist einfach ein Copy > & Paste Fehler. Genau darum geht's ja in dem ganzen Thread, sonst nichts. Dann hilft nur der Verweis "Schau doch ins Datenblatt!" rein gar nichts … und ja, Microchip hat den Salat übernommen, also sind sie auch für korrekte Informationen verantwortlich.
H.Joachim S. schrieb: > weil OCR1A/OCR1B PD4/5 vertauscht > zu sein scheinen Erstmal solltest du deine DATEN sortieren!!!! 1. OCRxy ist Nirgends rausgeführt da diese Register inside der AVR's sind!!! Deshalb auch OutputCompareRegister = OCR 2. PD4/5 war und ist schon immer, mit dem ersten AtMega8 Derivaten, XCK/T0 bzw nur T1 gewesen !!! https://cdn-reichelt.de/documents/datenblatt/A300/ATMEGA8xxx.pdf 3. Diese System wurde nie geändert denn dafür hätte die Hardware geändert werden müssen und es würde 0 Kompatibilität herschen vom Ur-Atmega8 mal abgesehen. Ab hier wurde der AtMega8 aufgebohrt bzw auch bei der Entwicklung vorher schon mit einbezogen was wann mal wie erweitert werden kann/soll. 4. AtMega4 8/8 8/16 8/32 8 sind nur mit den OC-Ausgängen/PCINT für die jeweiligen Timer erweitert worden. PD4 = XCK/T0 zusätzlich PCINT20 PD5 = T1 zusätzlich PCINT21/OC0B/ 5. Was stellt man fest ? Auf PD4 war nie ein OC-Ausgang gelegt worden! https://www.sparkfun.com/datasheets/Components/SMD/ATMega328.pdf 6. PD5 hat T1/OC0B deshalb auf dem gleichen Pin damit man sich gewissen Aufwand in der Verdrahtung sowie CamptureEvents besser Hand haben kann in der Paarung mit dem ADC! 7. OCR1A/B findest du auf PB1/2 vergleiche AtMega8 und AtMegaX8 8. Grundsätzlich müssen immer ZUERST LOWBYTEs gelesen ZUERST HIGHBEYTEs geschrieben werden Beispiel ADC ohne Synchronisation des High/LowBytes wird während des Zugriff vom Low auf das High eine Wandlung beendet können, nein, werden die Bytes verändert!! mit Synchronisation des High/LowBytes wird während des Lesezugriff vom Low auf das High eine Wandlung beendet kann der ADC die neuen Wandlungsdaten NIEMALS NICHT NIE in die ADC-Bytes übertragen! Solange nur das LOW-Byte gelesen wird, sind die Register zum schreiben blockiert. Ergebnis Daten sind konsistent! 9. Die Anzahl derer die sich als Hochsprachler auch mit der Einzelperpherie wird immer weniger. Würde ihr dies mal öfter tätigen würde diese Frage/Anaomalie sich selber in Wohlgefallen auflösen. Aber statt dessen greift man zu nem 128ig bittigen Controller der zwar moderner ist, trotzdem auch nur mit 0 und 1 sein code schreibt. Rev. 2486M–AVR–12/03 Atmega 8 S.77 https://cdn-reichelt.de/documents/datenblatt/A300/ATMEGA8xxx.pdf 8025I–AVR–02/09 AtmegaX8 S.115 https://www.sparkfun.com/datasheets/Components/SMD/ATMega328.pdf http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf S.122 *To do a 16-bit write, the High byte must be written before the Low byte. For a 16-bitread, the Low byte must be read before the High byte* MMMHHH Microchip hatte da wohl nen Fehler drine der nachweislich im neuem DB nict mehr gegenwärtig ist !!!!
Beitrag #5967194 wurde von einem Moderator gelöscht.
Beitrag #5967218 wurde von einem Moderator gelöscht.
chris schrieb: > Erstmal solltest du deine DATEN sortieren!!!! Manche Leute sind tatsächlich lästig, blubbern um des blubbern um des Blubberns willen, schau doch mal die Pinbelegung beim Mega324 (oder alternativ ATmega164/644) an, agal ob P oder PB... Und dabei keine Ahnung, Mega8 als allegemeingültige Referenz, Reichelt und Sparkfun als Datenquellen - Hut ab. Und wie schon von anfang an vermutet, das Problem lag hier bei mir (Chip nicht geflasht und so nur die Init-Werte gesehen und nicht die, die vonder Software aus anliegen sollten). chris schrieb: > 8. Grundsätzlich müssen immer > ZUERST LOWBYTEs gelesen > ZUERST HIGHBEYTEs geschrieben > werden Eben das ist ja nicht mehr gültig, und genau darum gehts hier - wo und wann wurde der Schnitt gemacht, welche Doku ist richtig und welche falsch. Hast aber trotzdem meine Hochachtung für deine Inbrunst. Fachlich dünn.
:
Bearbeitet durch User
Beitrag #5967227 wurde von einem Moderator gelöscht.
Stefanus F. schrieb: > Mw E. schrieb: >> Ich hoff doch, dass unser Johann das richtige DB gelesen hat > > Wo steht denn im Datenblatt, ob es das richtige oder falsche ist? Anscheinend sind das diejenigen vor dem Atmelkauf und ohne viele bunte Farben.
Wollen wir mal abwarten, was Microchip dazu sagt und ob und wann es korrigiert wird. Nach allem, was bisher bekannt ist, scheint der Schnitt in der Realität genau beim Wechsel auf series 0/1, egal ob die vielen neuen Tinys oder die wenigen neuen Megas (3208/09 und 4808/09) zu sein.
Beitrag #5967352 wurde von einem Moderator gelöscht.
Beitrag #5967362 wurde von einem Moderator gelöscht.
Beitrag #5967364 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
328PB.PNG
130 KB
https://www.mikrocontroller.net/topic/480738 Vielleicht kann einer das an den gesperrten threat anhängen? Sie haben es tatsächlich geändert.
Beitrag #6038523 wurde von einem Moderator gelöscht.
Beitrag #6038773 wurde von einem Moderator gelöscht.
War es nicht so, daß die neueren ATMegas irgendwas von den XMegas mitbekommen haben? Bei denen ist seit Anfang an das Low-Byte vor dem High-Byte zu schreiben/lesen gewesen.
Mw E. schrieb: > Ich hoff doch, dass unser Johann das richtige DB gelesen hat :) > Oder die anderen AVR-GCC Entwickler. Der Xmega-Support im avr-gcc ist ursprünglich von Atmel. Welcher Code im Detail generiert wird, kann man sich hier aus den out[put]_movhi* Funktionen zusammensuchen: http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/avr/avr.c?revision=277908&view=markup Für 16-Bit Les/Schrieb gilt folgendes: 1) Strikte Regeln wie in den folgenden Punkten gelten nur für volatile-Zugriffe. Für nicht-volatile wird u.U. eine andere Reihenfolge gewählt da günstiger, das kann z.B. bei pre-/post-Modify geschehen. 2) Lesen: Low/High. 3a) Schreiben, non-Xmega: High/Low. 3b) Schreiben, Xmega: Low/High. "Xmega" bezeichnet dabei genau die Devices, für die der Pfad von `avr-gcc -print-multi-directory -mmcu=<Devixe>` ein "avrxmega" enthält. ad 3b) Folgt aus der atomic-Eigenschaft beim Schreiben von SPL. Um diese auszunutzen, muss SPL vor SPH geschrieben werden.
:
Bearbeitet durch User
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.