¿Hay problemas de 'read-modify-write' en funciones de CCS?

[Abril]

Hola a todos.

He estado leyendo un par de cosas sobre los problemas de ‘read-modify-write’ que pueden dar algunas funciones en ensamblador (BSF, BCF y otras). En todos sitios se aconseja no mandar nada directamente al puerto sino a los registros LATx o a una variable intermedia que llaman ‘shadow register’. Mi pregunta es: ¿sabéis si las funciones equivalentes en CCS (output_high, output_low, output_bit, output_X…),  están implementadas de esta forma? Es decir, ¿se pueden usar sin temor a que den errores de tipo ‘read-modify-write’?

Muchas gracias y perdón si esto lo había planteado alguien antes (he usado el buscador y me parece que no).

Saludos desde Granada.

[manex_1987]

Prueba a crear un programa solo con esas 3 sentencias, compilalo y luego mira el listing de ensamblador para saber en qué registros inciden esas ordenes. Yo no tengo CCS en este ordenador, sino ya te lo miraria.

salu2!!

[Abril]

Muchas gracias por la rapidez en tu respuesta, manex. Lo que me dices ya lo he hecho, pero no tengo muy claro el resultado. Por ejemplo, para el programa:

void main(void)
{ 
   output_low(PIN_A4);
}

en la ventana 'disassembly listing' muestra esto:

6:                 void main(void)
7:                 { 
  0004    6AF8     CLRF 0xff8, ACCESS
  0006    9ED0     BCF 0xfd0, 0x7, ACCESS
  0008    6AEA     CLRF 0xfea, ACCESS
  000A    6AE9     CLRF 0xfe9, ACCESS
  000C    80C1     BSF 0xfc1, 0, ACCESS
  000E    82C1     BSF 0xfc1, 0x1, ACCESS
  0010    84C1     BSF 0xfc1, 0x2, ACCESS
  0012    96C1     BCF 0xfc1, 0x3, ACCESS
  0014    0E07     MOVLW 0x7
  0016    6EB4     MOVWF 0xfb4, ACCESS
  0018    0E19     MOVLW 0x19
  001A    6EAF     MOVWF 0xfaf, ACCESS
  001C    0E22     MOVLW 0x22
  001E    6EAC     MOVWF 0xfac, ACCESS
  0020    0E90     MOVLW 0x90
  0022    6EAB     MOVWF 0xfab, ACCESS
8:                    output_low(PIN_A4);
  0024    9892     BCF 0xf92, 0x4, ACCESS

En principio me daba la sensación de que las primeras líneas eran inicializaciones del PIC o de alguna librería y de que la función output_low correspondía tan solo a una instrucción BCF, pero no puede ser porque el registro 0xF92 es el TRISA, no el PORTA ni el LATA. Así que supongo que las líneas de antes de la etiqueta 8: también corresponden a esa función. Sigo investigando y te cuento.

Saludos

[manex_1987]

Me da que no has elegido el mejor ejemplo... porque los PICs al menos (y los 8051 tambien), inicializan todos sus pines como entradas. Y los registros LAT por defecto estan a 0 en la inicializacion. Luego el compilador, en tu ejemplo, no tiene mas que configurar el pin como salida para obtener un cero logico.

Prueba:

void main(void)
{
TRISB=0x00;
output_high(PIN_B3);
output_low(PIN_B3);
}

Por cierto, cuidado con el pin RA4, recuerda que es colector abierto. Ademas, no se si tambien es entrada analogica, la cual debe ser configurada.

[PalitroqueZ]

hola

por defecto el acceso a los pines es "estandar", esto quiere decir que cada vez que hagas uso de un puerto, en ensamblador, configurará el tris, y volverá al PORT o al LAT, a menos que uses #use fast_io (port)

[Abril]

Tienes razón, manex, el ejemplo que había puesto era el más confuso. Con el tuyo, o simplemente con un output_high, cambia primero el registro TRIS y luego pone a uno el bit correspondiente del LAT. El hecho de que use este último registro y no el PORT me lleva a pensar que no debe haber problemas de 'read-modify-write'. Muchas gracias, me has abierto los ojos.
En cuanto a lo del PIN RA4, te agradezco el aviso. Desgraciadamente, me llega unos días tarde. Una pena, porque la semana pasada me pasé unas cuantas mañanas echándole la culpa al emulador, a la tarjeta y a los micros antes de entrar en el foro y descubrir que es un problema bastante comentado.
Palitroquez, gracias también por tu comentario, lo tendré en cuenta.

Saludos