Ich lese Ressourcen im Zusammenhang mit PIC-Optimierungen und habe ein Dokument namens MPLAB® C18 OPTIMIZATION TIPS gefunden . Eines der Dinge, die es erwähnt, ist Access RAM
. Ich weiß, dass es der Teil des RAM ist, der verwendet werden kann, ohne dass das Bankzugriffsregister verwendet werden muss, und dass es einen schnelleren Zugriff auf darin gespeicherte Variablen ermöglicht, aber es ist mir immer noch nicht ganz klar, wie genau ich es manuell verwenden soll und wann ich erwarten sollte, dass der Compiler es mit Variablen füllt.
RAM-Adressen auf einem PIC 18 sind 12 Bit breit. Das ist zu viel, um es in Einzelwortbefehle aufzunehmen, die nur 16 Bit breit sind. Um weniger Adressbits in Befehlen zu verwenden, als der Speicher tatsächlich hat, verwendet der PIC 18 eine segmentierte Architektur. Das bedeutet, dass RAM in Segmente unterteilt ist, die die PIC-Dokumentation Banken nennt . Jede Bank hält 256 Bytes. Ein voller Speicher fasst 4096 Bytes, also gibt es 16 Bänke. Der 8-Bit-Adressoffset innerhalb einer Bank wird in Befehlen angegeben, und die 4-Bit-Banknummer wird mit einem Zustand angegeben, der zur Laufzeit eingestellt werden kann und als BSR-Register bezeichnet wird.
Um einen effizienteren Zugriff auf einen ausgewählten Teil dieses 4096-Byte- oder 16-Bank-Speichers zu ermöglichen, enthalten Befehle tatsächlich ein weiteres Adressbit. Diese Bank wählt zwischen einer von zwei Bänken aus, der durch BSR identifizierten Bank und der Zugriffsbank , die ein fester Satz von 256 Bytes ist, die für diesen PIC definiert sind. Die 256 Bytes der Zugriffsbank sind zwischen einigen der Spezialfunktionsregister am Ende von Bank 15 und einem allgemeinen RAM am Anfang von Bank 0 aufgeteilt. Wo diese Aufteilung ist, was bedeutet, wie viele Bytes der Zugriffsbank sich in Bank 0 befinden und wie viele in Bank 15 variieren zwischen den Modellen in der PIC 18-Familie.
Der Zweck der Zugriffsbank besteht allgemein im schnellen Zugriff auf jeden der ausgewählten 256 Orte, unabhängig von der aktuellen BSR-Einstellung. Bestimmte Kernregister befinden sich immer im Zugriffsbankteil in Bank 15, wie STATUS, PRODH, PRODL usw. Die Vorteile davon sollten offensichtlich sein, da kein Code zum Setzen von BSR benötigt wird und dass der Zugriff auf diese Register BSR erhalten kann.
Der Vorteil im allgemeinen RAM ist ähnlich. Der Anwendungscode kann auf Variablen in diesem Teil der Zugriffsbank zugreifen, ohne dass die aktuelle Bank eingestellt werden muss, wodurch wiederum die aktuelle Bankeinstellung nicht beschädigt wird. Da der für Register verfügbare Zugriffsspeicher begrenzt ist, müssen Sie sorgfältig überlegen, was Sie dort platzieren möchten und was besser in Bankspeicher platziert wird, damit etwas anderes vom schnellen Zugriff der Zugriffsbank profitieren kann. Beispielsweise ist die Zugriffsbank im Allgemeinen für große Puffer ungeeignet. Ein einzelner Puffer könnte leicht größer sein als der allgemeine RAM-Teil der Zugriffsbank, und er wird wahrscheinlich ohnehin indirekt über die FSR-Register adressiert. Diese enthalten die vollständige 12-Bit-Adresse, sodass das Banking nicht für indirekte Referenzen gilt.
Bewahren Sie im Allgemeinen die häufig verwendeten individuellen und allgemein globalen Variablen in der Zugriffsbank auf. Es gibt viel Platz, wenn Sie es jeweils nur ein Byte verwenden. In meinem System verwende ich standardmäßig die ersten 16 Bytes als allgemeine Register, die häufig als lokaler Scratch und zum Übergeben von Parametern in und aus Subroutinen verwendet werden. Diese werden viel herumgeknallt und profitieren so von der leichten Zugänglichkeit. Danach lege ich normalerweise einzelne globale Variablen in die Zugriffsbank und den privaten lokalen Status jedes Moduls vollständig in eine Bank, wenn dies möglich und sinnvoll ist. Das bedeutet, dass der Code in einem beliebigen Modul nur auf Daten in einer Bank und auf die wenigen globalen Variablen in der Zugriffsbank zugreifen muss.
Das sind natürlich nur allgemeine Richtlinien. Jedes Projekt ist anders und man muss überlegen, was Sinn macht.
Um Speicher in der Zugriffsbank in Assembler zuzuweisen, verwenden Sie die UDATA_ACS-Direktive anstelle von nur UDATA für Bankspeicher. Ich denke, der Compiler hat einen ähnlich klingenden Mechanismus. Einzelheiten finden Sie im Compiler-Handbuch.
Je nachdem, welchen PIC und Befehlssatz Sie verwenden, kann es zwischen 0 und 128 Bytes "Zugriffs-RAM" geben. Auf Variablen im Zugriffs-RAM kann schneller und mit weniger Code zugegriffen werden als auf Variablen an anderer Stelle, aber wenn ein Programm nicht ziemlich einfach ist, ist es nicht möglich, alle Variablen in den Zugriffs-RAM zu stellen. Compiler können theoretisch beurteilen, wie viel Code eingespart werden würde, indem sie bestimmte Variablen oder Kombinationen davon im Zugriffs-RAM platzieren, aber ich habe noch nie gesehen, dass einer dies gut gemacht hat. Darüber hinaus können Compiler im Allgemeinen nicht sagen, welche Beschleunigungen wichtig oder unwichtig sind. Folglich ist es für Programmierer manchmal hilfreich, bestimmte Variablen für die Platzierung im Zugriffs-RAM festzulegen. Das Platzieren so vieler Variablen wie möglich im Access-RAM schadet im Allgemeinen nicht, vorausgesetzt, es gibt ' s Raum im Zugriffs-RAM für alle so bezeichneten Variablen. Der Versuch, mehr Variablen im Access-RAM zu platzieren, als passen, führt im Allgemeinen zu einem Linker-Fehler.
WütendEE