Estoy leyendo recursos relacionados con optimizaciones de PIC y encontré un documento llamado CONSEJOS DE OPTIMIZACIÓN DE MPLAB® C18 . Una de las cosas que menciona es Access RAM. Sé que es la parte de la RAM que se puede usar sin necesidad de usar el registro de acceso bancario y que permite un acceso más rápido a las variables almacenadas en ella, pero todavía no me queda muy claro cómo exactamente debo usarla manualmente. y cuándo debo esperar que el compilador lo complete con variables.
Las direcciones de RAM en un PIC 18 tienen 12 bits de ancho. Eso es demasiado para incluirlo en instrucciones de una sola palabra, que tienen solo 16 bits de ancho. Para usar menos bits de dirección en las instrucciones de los que realmente tiene la memoria, el PIC 18 usa una arquitectura segmentada. Esto significa que la RAM se divide en segmentos que la documentación de PIC llama bancos . Cada banco tiene 256 bytes. Una memoria completa contiene 4096 bytes, por lo que hay 16 bancos. El desplazamiento de dirección de 8 bits dentro de un banco se especifica en las instrucciones y el número de banco de 4 bits se especifica con un estado que se puede configurar en tiempo de ejecución, que se denomina registro BSR.
Para permitir un acceso más eficiente a una porción seleccionada de esta memoria de 4096 bytes o 16 bancos, las instrucciones en realidad contienen un bit de dirección más. Este banco selecciona entre uno de dos bancos, el banco identificado por BSR y el banco de acceso , que es un conjunto fijo de 256 bytes definido para ese PIC. Los 256 bytes del banco de acceso se dividen entre algunos de los registros de funciones especiales al final del banco 15 y algo de RAM general al comienzo del banco 0. Dónde está esta división, es decir, cuántos bytes del banco de acceso hay en el banco 0 y cuántos en el banco 15 varía entre los modelos de la familia PIC 18.
El propósito del banco de acceso en general es un acceso rápido a cualquiera de las 256 ubicaciones seleccionadas, independientemente de la configuración actual de BSR. Ciertos registros centrales siempre están en la parte del banco de acceso en el banco 15, como STATUS, PRODH, PRODL, etc. Las ventajas de esto deberían ser obvias, ya que no se necesita código para configurar BSR, y el acceso a estos registros puede preservar BSR.
La ventaja en general RAM es similar. El código de la aplicación puede acceder a las variables en esa parte del banco de acceso sin la sobrecarga de tener que configurar el banco actual, lo que nuevamente, por lo tanto, tampoco corrompe la configuración del banco actual. Dado que la cantidad de memoria de acceso disponible para registros es limitada, debe considerar cuidadosamente qué desea colocar allí y qué es mejor colocar en la memoria almacenada para que otra persona pueda beneficiarse del acceso rápido del banco de acceso. Por ejemplo, el banco de acceso es generalmente inapropiado para grandes buffers. Un solo búfer fácilmente podría ser más grande que la parte RAM general del banco de acceso, y de todos modos es probable que se dirija indirectamente a través de los registros FSR. Estos contienen la dirección completa de 12 bits, por lo que la banca no se aplica a las referencias indirectas.
En general, mantenga las variables individuales y generalmente globales de uso frecuente en el banco de acceso. Hay mucho espacio si lo usa solo un byte a la vez. En mi sistema, por defecto, uso los primeros 16 bytes como registros generales que se usan con frecuencia como borrador local y para pasar parámetros dentro y fuera de la subrutina. Estos se golpean mucho, por lo que se benefician del fácil acceso. Después de eso, normalmente pongo las variables globales individuales en el banco de acceso y el estado local privado de cada módulo por completo en un banco cuando esto es posible y razonable. Eso significa que el código en cualquier módulo solo necesita acceder a los datos en un banco y las pocas variables globales en el banco de acceso.
Por supuesto, esas son solo pautas generales. Cada proyecto es diferente y hay que pensar en lo que tiene sentido.
Para asignar memoria en el banco de acceso en ensamblador, usa la directiva UDATA_ACS en lugar de solo UDATA para la memoria almacenada. Creo que el compilador tiene un mecanismo de sonido similar. Vea el manual del compilador para más detalles.
Según el PIC y el conjunto de instrucciones que esté utilizando, puede haber entre 0 y 128 bytes de "RAM de acceso". Se puede acceder a las variables ubicadas dentro de la RAM de acceso más rápidamente y con menos código que a las variables en otros lugares, pero a menos que un programa sea bastante simple, no será posible colocar todas las variables en la RAM de acceso. En teoría, los compiladores pueden juzgar cuánto código se guardaría colocando variables particulares o combinaciones de las mismas en la memoria RAM de acceso, pero nunca he visto que una haga un buen trabajo. Además, los compiladores generalmente no pueden decir qué aceleraciones pueden ser importantes o no importantes. En consecuencia, a veces es útil para los programadores designar ciertas variables para colocarlas en Access RAM. Colocar tantas variables como sea posible en la RAM de Access generalmente no hará daño, siempre que haya Hay espacio en Access RAM para todas las variables así designadas. Intentar colocar más variables en Access RAM de las que caben generalmente causará un error del enlazador.
EnojadoEE