Estoy leyendo recursos relacionados con las optimizaciones de PIC y he encontrado el documento llamado TIPOS 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 la necesidad de usar el registro de acceso bancario y que permite un acceso más rápido a las variables almacenadas en él, pero todavía no está muy claro cómo debo usarlo manualmente. y cuando debería esperar que el compilador lo rellene con variables.
Las direcciones RAM en un PIC 18 tienen 12 bits de ancho. Eso es demasiado para incluir en instrucciones de una sola palabra, que solo tienen 16 bits de ancho. Para usar menos bits de dirección en las instrucciones que la memoria realmente tiene, 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 la 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 el estado que se puede establecer en el tiempo de ejecución, que se denomina registro BSR.
Para permitir un acceso más eficiente a una parte seleccionada de esta memoria de 4096 bytes o 16 bancos, las instrucciones realmente 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 definidos 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 algunos RAM generales al inicio del banco 0. Cuando esta división es, significa cuántos bytes del banco de acceso están en el banco 0 y cuántos en el banco 15 varían entre los modelos de la familia PIC 18.
El propósito del banco de acceso en general es el 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 ESTADO, PRODH, PRODL, etc. Las ventajas de esto deberían ser obvias, ya que ese código no es necesario 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 de nuevo tampoco corrompe la configuración del banco actual. Dado que la cantidad de memoria de acceso disponible para los registros es limitada, debe considerar cuidadosamente qué desea colocar allí y qué se coloca mejor en la memoria almacenada para que otra cosa pueda beneficiarse del acceso rápido del banco de acceso. Por ejemplo, el banco de acceso es generalmente inadecuado para grandes almacenamientos intermedios. Un solo búfer podría ser fácilmente más grande que la parte de RAM general del banco de acceso, y es probable que se dirija indirectamente a través de los registros FSR de todos modos. 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 globales y globales de uso frecuente en el banco de acceso. Hay mucho espacio si lo está utilizando solo un byte a la vez. En mi sistema, de forma predeterminada, uso los primeros 16 bytes como registros generales que se usan con frecuencia como local scratch 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, por lo general, coloco variables globales individuales en el banco de acceso y el estado local privado de cada módulo en un solo banco cuando sea 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 que son solo guías generales. Cada proyecto es diferente y tienes que pensar en lo que tiene sentido.
Para asignar memoria en el banco de acceso en el ensamblador, use la directiva UDATA_ACS en lugar de solo UDATA para la memoria almacenada. Creo que el compilador tiene un mecanismo de sonido similar. Consulte 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. Teóricamente, los compiladores pueden juzgar cuánto código se guardaría al colocar variables particulares o combinaciones de ellas en la RAM de acceso, pero nunca he visto a nadie hacer 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 que los programadores designen ciertas variables para su ubicación en Access RAM. La colocación de tantas variables como sea posible en Access RAM generalmente no se verá afectada, siempre que haya espacio en Access RAM para todas las variables designadas. Intentar colocar más variables en Access RAM de las que caben generalmente causará un error de vinculador.