Hallo Ich habe ein Verständnisproblem was die Vports besonders macht. Also was man mit denen mehr/anders machen kann als mit den regulären Ports. "Writing to the Virtual PORT registers has the same effect as writing to the regular registers, but allows for memory-specific instructions, such as bit-manipulation instructions, which are not valid for the extended I/O memory space where the regular PORT registers reside." Man kann doch in den regulären Ports die Bits ändern wie man lustig ist. Wenn ich diese irgendwie manipuliere findet die Rechnerei/Bit schubsen doch im Speicher statt und erst das Ergbnis wird wieder in den regulären Port geschrieben. Worauf bezieht sich obige Aussage der besonderen Manipulationsfähigkeit mit Vports?
Veit D. schrieb: > Also was man mit denen mehr/anders machen kann als mit den regulären > Ports. Dass sie im unteren Adressbereich liegen, in dem IN, OUT, SBI und CBI funktionieren.
PS: So benötigt zum Beispiel in nur einen Takt und ist also dreimal schneller als das lds mit seinen drei Takten.
S. Landolt schrieb: > So benötigt zum Beispiel in nur einen Takt und ist also dreimal > schneller als das lds mit seinen drei Takten. Wieso dauert lds/sts eigentlich neuerdings drei Takte? bei den klassischen Mega waren's normalerweise zwei, nur beim Zugriff auf externen RAM waren's (mindestens) drei. Vermutlich eine (eher unerwünschte) Erbschaft vom XMega-Core?
PS: Auch bei den AVR128DA, bei diesen bin ich vor kurzem drüber gestolpert.
> Wieso dauert lds/sts eigentlich neuerdings drei Takte?
Nee, nur lds; sts benötigt wie früher zwei.
S. Landolt schrieb: > Nee, nur lds; sts benötigt wie früher zwei. Da wurde also ein 16Bit-Buffer für den Prefetch und ein wenig Logik eingespart. Schon zu XMega-Zeiten. Und diese damalige Fehlentscheidung wird jetzt an die neuen Generationen vererbt. Nicht wirklich schön. Naja, ein Teil des Nachteils wird ja durch die potentiell höheren Taktfrequenzen geschluckt. Muß man halt im Einzelfall sehen, ob's insgesamt noch passt oder zumindest passend gemacht werden kann.
Veit D. schrieb: > Ich habe ein Verständnisproblem was die Vports besonders macht. Nichts. Ist wohl nur Werbegeschwurbel. Die Ports waren schon in den classic AVRs bitweise setzbar. Nur bei den großen ist im unteren IO-Bereich kein Platz mehr, z.B. für Port H, J, K, L im ATmega2561. Neu ist an den megaAVR0 nur, daß die Ports noch zusätzlich in den Memorybereich gespiegelt sind. Welchen Nutzwert das haben soll, erschließt sich mir nicht.
Peter D. schrieb: > Neu ist an den megaAVR0 nur, daß die Ports noch zusätzlich in den > Memorybereich gespiegelt sind. Welchen Nutzwert das haben soll, > erschließt sich mir nicht. Dann solltest du mal ein paar Antworten lesen. Beitrag "Re: megaAVR0 - Was ist die VPORT Besonderheit?"
Falk B. schrieb: > Dann solltest du mal ein paar Antworten lesen. > > Beitrag "Re: megaAVR0 - Was ist die VPORT Besonderheit?" Eine Begründung für das zusätzlich Mapping in dem MEM-Bereich finde ich dort aber nicht. Da steht auch nur, daß sie das können, was bereits die classic ATmega konnten: "Dass sie im unteren Adressbereich liegen, in dem IN, OUT, SBI und CBI funktionieren."
:
Bearbeitet durch User
Peter D. schrieb: > Eine Begründung für das zusätzlich Mapping in dem MEM-Bereich finde ich > dort aber nicht. Die neuen IO-Ports belegen deutlich mehr Adressen als zuvor, sodaß diese den kleinen unteren Adressbereich "verstopfen" könnten.
Peter D. schrieb: > Da steht auch nur, daß sie das können, was bereits die classic ATmega > konnten: Der Unterschied: bei Xmega und Mega0 können nur noch die Vports das, alle anderen sind zu groß und zu weit weg. Damit nun nicht die Situation entsteht wie in den von dir genannten ATmegas, bei denen du auf den "oberen" PIOs gar keine Chance mehr hast auf die schnellen IO-Befehle, hat man das beim Xmega flexibel gemacht: standardmäßig liegt keine einzige PIO mehr im "günstigen" Bereich, aber dafür eben die Vports, die du als Alias auf eine beliebige, dir in deinem Kontext wichtige PIO mappen kannst. Dass die Vports auch über MMIO noch erreichbar sind, ist einfach nur ein Artefakt der Architektur: IO-Ports waren beim AVR ja grundsätzlich auch alternativ über MMIO erreichbar.
Hallo, habe mich heute nochmal mit Ports befasst. :-) Man hat mit den vielen Registern viel mehr Möglichkeiten zur Auswahl. Ob das immer sinnvoll ist waage ich auch langsam zu bezweifeln, da sich manche Möglichkeiten überschneiden und keinen Vorteil bieten. Aber was solls, die Register sind nun einmal da. Dafür kann man schön mit den Offsets zur Base rechnen. "langsam" takten auf 4MHz Niveau kann man mittels OUTSET/OUTCLR oder OUTGL oder IN. Effekt ist bei allen der Gleiche. Nimmt man die VPORTS mittels OUT (0/1) oder IN ist man wieder auf 8MHz Speed. Alles mit Clock 16MHz. Cool finde ich das SlewRate Feature was in allen Fällen funktioniert. Ich messe 10-12ns Rise/Falltime. Einstellung gilt immer für den kompletten Port. PORTx_PORTCTRL = PORT_SRL_bm;
> VPORTS mittels OUT (0/1) oder IN ... 8MHz
Und auch bei cbi und sbi mit einem Takt, früher waren es zwei.
Wie man überhaupt das Instruction-Set-Manual genauer anschauen sollte
(z.B. rcall mit zwei Takten statt drei).
Da die Core Independant Peripherals wesentlich mehr Adressen brauchen gibt es die VPORTs damit man für die GPIO auf allen Ports die Instruktionen benutzen kann die nur die untersten 32 bytes ansprechen können. Die wurden sogar noch etwas aufgepeppt (mich hat schon immer gestört das cbi/sbi 2 Cyklen brauchen). Das steht so auch im Datenblatt. Ich muss ehrlich sagen ich bin von den neuen Atmega und AVR-DA begeistert. Wenn sie jetzt noch die Hardwarebugs ausbügeln würden wäre es noch besser.
Wichtiger ist m.E. an der Sache, dass man Atomarität bekommt. (BTW: man hat jetzt ja auch immer 4 GPIOR in dem Bereich), Wenn die jetzt noch eine atomares swap() zweier Bytes in den Core einbauen würden ...
eor rq,rp eor rp,rq eor rq,rp reicht völlig so oft kommt das nicht vor
Peter S. schrieb: > eor rq,rp > eor rp,rq > eor rq,rp > > reicht völlig so oft kommt das nicht vor ... ähm, und wo ist das jetzt atomar????
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.