:: prioridad INTERRUPCIONES ::

[pajaro]

Hola
¿Que calor que hace , ganas tengo que vuelva mi querido invierno!...

¿Me ronda una duda?

1.- los retardos del ccs usan algun tipo de timer?
2.- de ser asi  cual usan?
3.- ¿como se puede consultar esto?


De necesidad de uso de interrupciones,
si necesitamos que unas veces una tenga prioridad sobre las otras
pero en otros casos la prioridad se intercambie como se resuelve esto?

Si se esta ejecuntando una interrupcion y necesitamos que esta se interrumpa
temporalmente para atender a otra quien lleva la "varita de mando" quien albitra ?


¿Es posible implementar timer por software?
como de eficiente es con respecto a los propios del pic que tiene implementados?.


Espero que el foro me ampare en estas dudas que me corroen.


sigo con del depurador ...

[MerLiNz]

si con retardos te refieres a los delays estos van unicamente por un bucle calculado, si tu quieres 10ms y cada Tcy ocurre en 1ms entonces lo que haces es repetir la rutina 10 veces y asi obtienes 10ms de retardo.

los pics16 solo tienen un tipo de prioridad, los pics18 tienen 2 prioridades (high y low), la high interrumpe a la low, en CCS es algo complicado utilizar las prioridades ya que el mismo compilador crea el sistema de interrupciones, son faciles de usar, pero a su vez el usuario no tiene el 100% de control de ellas, creo que se podia definir de una manera segun lei en un post para utilizar ambas, seguro que por el manual de CCS vendra algo.

Un timer por software no es posible, bueno posible seguro que es, pero no sera nada eficiente, los timers van en paralelo independientes del procesado de codigo, es decir, un timer se incrementa automaticamente sin necesidad de incrementarlo por el procesador, esto no se podria hacer por software ya que no es posible incrementar un registro sin que el procesador lo haga. Lo unico que se me ocurre es coger un timer y hacer que incremente varios registros en su interrupcion, cuando uno llege a 5 ejecuta X instruccion, cuando el otro llege a 20 ejecute Y instruccion, por poner un ejemplo.

[MGLSOFT]

Para administrar las prioridades de interrupcion el CCS usa #priority.
Aqui la ayuda para ella:

#PRIORITY

--------------------------------------------------------------------------------
Syntax:
 #PRIORITY ints


Elements:
 ints is a list of one or more interrupts separated by commas.

export makes the functions generated from this directive available to other compilation units within the link.

 
Purpose:
 The priority directive may be used to set the interrupt priority. The highest priority items are first in the list. If an interrupt is active it is never interrupted. If two interrupts occur at around the same time then the higher one in this list will be serviced first. When linking multiple compilation units be aware only the one in the last compilation unit is used. 

 Examples:
 #priority rtcc,rb
 
Example Files:
 None
 
Also See:
 #INT_xxxx

[MerLiNz]

el unico problema es que usando este metodo la prioridad es unicamente por banderas, no es como el high-low del pic18 de toda la vida.

[Suky]

Purpose:
 These directives specify the following function is an interrupt function. Interrupt functions may not have any parameters.   Not all directives may be used with all parts.  See the devices .h file for all valid interrupts for the part or in PCW use the pull down VIEW | Valid Ints

The compiler will generate code to jump to the function when the interrupt is detected.  It will generate code to save and restore the machine state, and will clear the interrupt flag.  To prevent the flag from being cleared add NOCLEAR after the #INT_xxxx.  The application program must call ENABLE_INTERRUPTS(INT_xxxx) to initially activate the interrupt along with the ENABLE_INTERRUPTS(GLOBAL) to enable interrupts.

The keywords HIGH and FAST may be used with the PCH compiler to mark an interrupt as high priority. A high-priority interrupt can interrupt another interrupt handler. An interrupt marked FAST is performed without saving or restoring any registers. You should do as little as possible and save any registers that need to be saved on your own. Interrupts marked HIGH can be used normally. See #DEVICE for information on building with high-priority interrupts.

A summary of the different kinds of PIC18 interrupts:

       #INT_xxxx

           Normal (low priority) interrupt.  Compiler saves/restores key registers.
           This interrupt will not interrupt any interrupt in progress.

       #INT_xxxx FAST

           High priority interrupt.  Compiler DOES NOT save/restore key registers.
           This interrupt will interrupt any normal interrupt in progress.
           Only one is allowed in a program.

       #INT_xxxx HIGH

           High priority interrupt.  Compiler saves/restores key registers.
           This interrupt will interrupt any normal interrupt in progress.

       #INT_GLOBAL

           Compiler generates no interrupt code.  User function is located
           at address 8 for user interrupt handling.
 

Some interrupts shown in the devices header file are only for the enable/disable interrupts. For example, INT_RB3 may be used in enable/interrupts to enable pin B3. However, the interrupt handler is #INT_RB.
 
Similarly INT_EXT_L2H sets the interrupt edge to falling and the handler is #INT_EXT. 

Eso si, CCS solo acepta una sola interrupción de este tipo  Por lo menos hace unos dos años cuando quise usarlo fue así 


Saludos!

[pajaro]

Hola
De donde has sacado este cachito de informacion
quiero ver el resto, me puedes indicar la fuente.

que diferencia hay entre usar esto y el #priority.

Un saludo.

[Suky]

En la ayuda de CCS 

#priority es prioridad por bandera, y lo otro es prioridad vectorizada.

[pajaro]

Hola Suky

parace que la clave esta en la prioridad
pero a quien le poner la alta prioridad
al timer0, al timer1 o al ssp?..

si pones #INT_SSP HIGH

te tira el error que directiva incorrecta que requiere un parametro,

#device_high_ints=true

alguna idea,

[Suky]

Yo se los pondría a el timer0 y timer1 

[AngelGris]

  Definitivamente coincido con Suky, yo ya he hecho la prueba con SDCC y la prioridad deben tenerla los timers

[pajaro]

Hola
muy bien de ponerse la prioridad al timer0 y al timer 1 la ultima prioridad sera para SSP
pero ¿como consigues que el ssp pueda recibir y mas aun que no se quede cortado?

y otra cosa eso de la prioridad es solo con


#PRIORITY TIMER0, TIMER1, SSP

y se combina con..
 #INT_TIMER0 HIGH
o
#INT_TIMER0FAST

si tenemos timer 1 y timer0 y ambos son high

la recepcion de ssp lo va a tener dificil, pero my dificil...
aun si la comunicacion i2c sea por harware..

[MerLiNz]

el i2c no se cortara si es por hardware, mas que nada porque este modulo funciona paralelo a la cpu, es decir, mientras la cpu ejecuta el codigo el ssp puede recibir datos y una vez los reciba se activa un flag en este caso lo detectas (ya sea por interrupcion o por lectura de bits) y lees el dato recibido. El unico problema seria por que envies los datos demasiado rapido y antes de leer un dato recibido ya se este recibiendo otro, asi provocaras un overflow del registro y perderas algunos datos.

[Suky]

Varias veces se te comento que #PRIORITY solo es prioridad por banderas, o sea si ocurren dos a la vez por cual pregunta primero. Acá no se habla de eso, sino de prioridad vectorizada, si has leído el datasheet del PIC18 (Y sino hay que leerlo! ) sabrás que dispone de dos vectores de interrupciones. A los dos timers los tratas de alta prioridad y al MSSP de baja. O sea:

#INT_TIMER0 HIGH

#INT_TIMER1 HIGH

#INT_SSP

Si CCS no te lo permite, es porque es un compilador de mier... 



Saludos!

[pajaro]

Hola MerLiNz

Eso que dice se aproxima mucho al comportamiento que me esta dando esta pesadilla,
resulta que la comunicación la tenia sin (FORZAR_XX) ahora se lo puse pero da lo mismo,
el problema persiste  ...

 Cuando envio datos del master al esclavo, el master si que los envia
 (los veo printear en terminal virtual) pero cuando los
recibe el esclavo y le puse un printf dentro de la interrupcion del  ssp ..
(ya se que esta mal ...o no se debe de hacer.. pero asi por terminal virtual veo que hace..)

pues en ese caso el debug i2c del proteus si que muestra que despues de cada dato llega
un A ACK si no imprimo (imprime la direcion del esclavo (state) y el dato enviado)
el debug de i2c me manda despues de cada dato N  nack y como  no tengo el printf

no le veo por pantalla si imprime, le puse un led que parpadea al entrar en la funcion de escribir
y resulta que parpadea al inico cuando el master aun no envio dato y el debug i2c dice que NOISE(ruido SCL)
pero despues de un rato intenta volver a enviar y envia el dato pero solo el priero.

la unica diferencia entre ambos casos es que si envia y se printean el dato en el esclavo, llega (debug i2c da ack),
si comento el printeo los datos no llegan.

Es como si el printeo hiciera de delay,
lo malo es que si printeo el pwm (rebresca cada 20ms ) cae en todas los servos



Suky
si lei el data pone que tenia una alta interrupcion en la direcion 8h y una baja en la 18h
y la alta puede interrumpir a la baja y otras cosas mas, me gusta cotejas varias fuentes
ambos sabemos que los datas tambien tienen errores los cuales solo los podemos detectar
preguntando, ademas dos personas diferentes pueden hacer dos interpretaciones distintas
de un mismo problema, lo cual es bueno para un bien comun.

Agradezco tus consejos y comentarios.
por cierto has cambiado de logo, me gustaba mas el anterior.
quien es?