Publicado por: tornar en 18 de Diciembre de 2004, 07:01:00
Saludos.
Publicado por: oshow en 18 de Diciembre de 2004, 09:45:00
De cualquier manera, el compilador de ccs no es tan standard como pueda ser un compilador de c para hacer programas para un PC, por ejemplo no permite recursividad ni otro tipo de operaciones que se pueden realizar en ese tipo de compiladores.
No sé, quizas el compilador de www.htsoft.com o el de www.iar.com, te permitan realizar esas operaciones que comentas (como puede ser la recursividad o concurrencia). Yo reconozco que uso el ccs por la cantidad de cosas implemtadas que trae, pero nunca he visto eso que comentas.
Estaría bien que comentases en que consisten eso de los semaforos o en que pueden ser útiles para la programación de microcontroladores (para los que como yo no tenemos ni idea de lo que es o en lo que se puede usar).
Un saludo.
Publicado por: Modulay en 18 de Diciembre de 2004, 10:25:00
No sé si esto es simplemente cuestión de software o depende también de la arquitectura del procesador.Si lo vemos desde ese punto de vista,es dificil imaginar a un pic actuando de forma concurrente,aunque si pensamos en un proceso que se está ejecutando hasta que en un momento dado para de hacerlo para que se ejecute una rutina de interrupción,esto bien podría considerarse como un programa que se ejecuta con un cierto nivel de concurrencia.
Publicado por: oshow en 18 de Diciembre de 2004, 10:36:00
Pero supongo que hacer un sistema operativo para el pic no es nada fácil, yo he visto uno comercial que posteó Marqués hace tiempo, tiene una versión demo.
http://www.pumpkininc.com/
Mira a ver si es eso a lo que te referias, y lo dicho, perdonad que confundiera la concurrencia con la recursividad, soy un metepatas, jejej.
Un saludo.
Publicado por: Modulay en 18 de Diciembre de 2004, 11:28:00
Publicado por: pocher en 18 de Diciembre de 2004, 11:38:00
Un saludo
Publicado por: Modulay en 18 de Diciembre de 2004, 12:21:00
Publicado por: pocher en 18 de Diciembre de 2004, 12:25:00
Publicado por: pacalaconcurso en 18 de Diciembre de 2004, 12:36:00
si te refieres a usar un RTOS tambien es posible hacerlo (existen varios por ahi rulando, basados en el standart OSEK/VDX para la industria de automocion) el tema es que el CCS no maneja bien punteros a funciones asi que debes migrar a C18 o HT.
no creo que realmente necesites un RTOS, si tu programa lo estructuras de forma correcta puedes (yo lo tengo en varias aplicaciones) varias tareas (mas de 10 en mi caso) con tu tiempo de scan por debajo de 50 ms.
dale un vistazo al graftcet que te anota pocher, el tener tu programa estructurado en papel es imprescindible... el teclear es menos del 10% del tiempo que se emplea en el desarrollo de un programa.
saludos
Publicado por: pocher en 18 de Diciembre de 2004, 12:40:00
El ejemplo no es de secuencias simultaneas, es muy simple para que la gente se entere. Para secuencias simultaneas es lo mismo pero llevando varias ramas activas al mismo tiempo.
La teoria del GRAFCET es sencillisima, son 6 o 7 hojas muy faciles de entender. Lo inventaron los franceses para aplicarlo a un automata, creo que era el de Telemecanique. Si os interesa buscar en Google, hay mucha informacion.
Un saludo
Publicado por: pocher en 18 de Diciembre de 2004, 12:56:00
Publicado por: Modulay en 18 de Diciembre de 2004, 13:57:00
Echaré un vistazo a eso de los autómatas tiene q estar muy pero que muy interesante
Publicado por: Modulay en 18 de Diciembre de 2004, 19:49:00
Publicado por: pocher en 19 de Diciembre de 2004, 04:12:00
Publicado por: pocher en 19 de Diciembre de 2004, 13:11:00
De todas formas lo he redibujado para un 876, he cambiado el PIC en el codigo y tambien va. Como es una simulacion y no esta inicializada a 0 la posicion 0x00 de la EEPROM se disparan las dos salidas simultaneamente (el PROTEUS creo que no dejaba inicializar posiciones de la EEPROM, el MPLAB creo que si). En caso de montaje real con el programa grabador se debe inicializar esta posicion a 0.
Este ultimo es el que te mando para que lo incluyas en la carpeta de proyectos. Te lo mando al correo.
Un saludo
Publicado por: tornar en 19 de Diciembre de 2004, 13:23:00
X cierto, tambien seria interesante saber si existe algun metodo para sincronizar procesos o programas ejecutados cada uno en un PIC, para poder realizar concurrencia real.
Respecto a La teoria del GRAFCET, me la voy a imprimir y echarla un vistazo, que suena bastante interesante.
Un saludo
Publicado por: Modulay en 19 de Diciembre de 2004, 14:03:00
http://personal.auna.com/asencio5/Ejemplos%20C/PROYECTOS/
Con respecto a lo de inicializar la eeprom,no se si se tratará de lo mismo,pero el ejemplo i2c de migsantiago carga un archivo .bin de datos iniciales en la eeprom:
http://personal.auna.com/asencio5/Ejemplos%20C/I2C/
Publicado por: pocher en 20 de Diciembre de 2004, 02:56:00
Se puede hacer con el programa grabador o bien por software en el mismo programa, pensando un poquito.
En el programa de la memoria I2C de migsantiago no se enciende la barra de LEDs porque esta puesta al reves. En versiones anteriores para que funcionara era necesario meterle PULLUPs, en la SP5 con RES tambien funciona.
Un saludo
PD. Estoy vaguete, ¿como se hacia en XP para que aparecieran los acentos y los Alt Gr?
Publicado por: Nocturno en 20 de Diciembre de 2004, 04:31:00
Tienes que entrar en panel de control, escoger la opción Opciones regionales, de idioma y de fecha y hora, luego escoges Configuración regional y de idioma, y por último en el desplegable escoge el idioma que corresponda a tu teclado.
Publicado por: tornar en 20 de Diciembre de 2004, 08:49:00
Ademas, tambien hay algo que odio de windows Xp, y es lo relacionado con la tecla SHIFT, que no se pq algunas veces al pulsarla una vez, se kedan activados los caracteres secundarios de cada tecla (p.ej. si pulsas el 1, te sale !).
Espero haber sido de ayuda, un saludo
Publicado por: pocher en 20 de Diciembre de 2004, 09:38:00
No me pregunteis porqué, pero lo he solucionado cambiando de Español(alfabetización tradicional) a Español(alfabetización internacional). No sé porqué con la primera opción no salía bien. Enfin.
Saludos
Publicado por: tornar en 21 de Diciembre de 2004, 05:12:00
Saludos
Publicado por: Modulay en 21 de Diciembre de 2004, 08:24:00
Qué les parece
Publicado por: Nocturno en 21 de Diciembre de 2004, 09:42:00
En cualquier caso, creo que es un tema con interés suficiente como para "saturar" el foro, así que yo votaría porque se siga discutiendo aquí.
¿Un PIC con mucha memoria?, pues no sé si será necesario. Supongo que dependerá del proyecto que se acometa ¿no?.
Publicado por: pacalaconcurso en 21 de Diciembre de 2004, 12:52:00
no os metais en el diseño de un kernel del copon.... pensad que las cosas cuanto mas sencillas mejor....
por partes, por ejemplo, vamos a hacer un par de tareas que se deben ejecutar de forma paralela:
un led debe hacer una intermitencia de 1 segundo y otro led debe hacer una intermitencia de 300 milisegundos, ademas si pulso una entrada se debe activar un tercer led
...solo se puede usar un timer (ya vereis por que....) y no usar interrupcion para la entrada (esto es para joder un poco la cosa
).si pongo directamente el codigo greo que no tiene gracia
saludossssssss
Publicado por: Modulay en 21 de Diciembre de 2004, 13:00:00
Con un solo timer se me ocurre utilizar el "tiempo de proceso" como base de tiempos para generar los retardos,incrementando dos variables,una por cada led,en cada desbordamiento del timer,y comprobando cada vez si la variable ha alcanzado un valor concreto para prender su led.Aunque no estoy muy seguro de que esto sea concurrente
Publicado por: pocher en 22 de Diciembre de 2004, 00:18:00
Publicado por: Nocturno en 22 de Diciembre de 2004, 05:48:00
http://miarroba.com/foros/ver.php?foroid=348538&temaid=2665537
Este es el código:
Codigo:
#include <16F876.h>
#fuses XT,NOWDT,NOPROTECT
#use delay(clock=4000000)
#byte port_b = 6
#define INTS_POR_50ms 49 // (4000000/(4*4*256))/20
#define PASOS_LED1 20 // 1 seg = 50 ms * 20 pasos
#define PASOS_LED2 6 // 300 ms = 50 ms * 6 pasos
BYTE ms50; // Contador de tramos de 50ms
BYTE cuenta_ints; // Contador de interrupciones
BYTE cuenta_led1; // Contador ciclos LED1: 1 segundo
BYTE cuenta_led2; // Contador ciclos LED2: 300 ms
#int_rtcc
void interrupcion() { // aquí entra 49 veces cada 50ms
if(--cuenta_ints==0) { // decrementamos el contador y si es 0 entramos
cuenta_ints=INTS_POR_50ms; // volvemos a setear el contador
if (--cuenta_led1==0) { // decrementamos el contador de LED1 y si es 0 entramos
cuenta_led1=PASOS_LED1; // volvemos a setear el contador de LED1
output_bit (PIN_B0,!bit_test(port_b,0)); // e invertimos su estado
}
if (--cuenta_led2==0) { // decrementamos el contador de LED2 y si es 0 entramos
cuenta_led2=PASOS_LED2; // volvemos a setear el contador de LED2
output_bit (PIN_B1,!bit_test(port_b,1)); // e invertimos su estado
}
output_bit(PIN_B2,!bit_test(port_b,3)); // si se ha pulsado, encendemos LED3
}
}
void main() {
cuenta_ints=INTS_POR_50ms; // se inicializan los contadores
cuenta_led1=PASOS_LED1;
cuenta_led2=PASOS_LED2;
set_timer0(0); // se arranca el timer
setup_counters( RTCC_INTERNAL, RTCC_DIV_4 | RTCC_8_BIT);
enable_interrupts(INT_RTCC);
enable_interrupts(GLOBAL);
while (TRUE){}; // y se deja el micro rulando
}
Pocher, le he hecho usando una base de tiempos de 50ms siguiendo tu sugerencia, pero no entiendo porque esa base de tiempos es clave. Creo que también podría funcionar con cualquier divisor de ambos periodos: 1000ms y 300ms
Publicado por: tornar en 22 de Diciembre de 2004, 06:00:00
Como dice pacala, deberiamos ir por partes, lo primero en lo que estoy trabajando es en ejecutar interrupciones por desbordamiento del TIMER0 cada pocos micro-segundos, para ello uso un divisor de frecuencias=1, y en la salida de la interrupcion pongo el timer0 a 255, ya que el desbordamiento se produce cuando pasa de 255 a 256. Haciendo esto, consigo que se ejecute la interrupcion cada 15-20 instrucciones con un reloj a 4 MHz.
Anoche hice un programa muy simple, que realizaba siempre la misma instruccion (sumar 1 a un contador) en un bucle infinito, y la interrupcion cuando se ejecutaba ponia dicho contador a 0, asi podiamos ver en un LCD (este ejercicio en Proteus funcionaba bastante bien y era bastante explicativo) el numero de instrucciones que se ejecutaban antes de llegar a una interrupcion.
Todo se basa en la siguiente formula:
Temporizacion=4 * Tosc *(256 - valor inicial del Timer)*Divisor de Frecuencia
Y con las variables que jugamos principalmente son "valor inicial del Timer" y "Divisor de Frecuencia", ya que el periodo del oscilador (Tosc), al ser el inverso de la frecuencia, creo que si le bajamos, disminuye nuestra temporizacion, pero subimos la frecuencia, por lo que se ejecutarian las instrucciones mas rapido, y por tanto no adelantamos nada.
A menor temporizacion del TIMER0, se podria obtener una mayor concurrencia SIMULADA (puesto que estamos trabajando solo con un micro).
El siguiente paso a mi juicio, seria hacer que con cada interrupcion se vaya modificando el vector de interrupcion, para conseguir tener en vez de rutinas de interrupcion, procesos que se ejecutan de forma concurrente. Es decir, usar como rutina de interrupcion, algo tan simple como un ORG(usando directivas de ensamblador) hacia la direccion de memoria del siguiente proceso, y a la vez una modificacion de la direccion de memoria 004 donde se encuentra el vector de interrupcion con el ORG al proximo proceso que se debera ejecutar concurrentemente, y por ultimo inicializacion del TIMER0 a 255,y otro cambio del vector, y todo esto de manera ciclica para conseguir la concurrencia. Es decir, nuestro proceso de interrupcion kedaria asi:
#INT_RTCC
void cambio_proceso()
{
uso de una sentencia ORG para tras la interrupcion dirigirnos al siguiente proceso ;
modificacion de la sentencia anterior, para que el ORG apunte al proceso que se ejecutara cuando se produzca la siguiente interrupcion;
Inicializacion del TIMER0 a 255 para conseguir una mayor concurrencia SIMULADA;
}
Una vez que tuvieramos concurrencia simulada, pasariamos a implementar los semaforos, para sincronizar los procesos concurrentes
Todo esto lo he pensado, leyendo unos pocos libros, y haciendo 20 o 30 programas en C, asi que no soy ni mucho menos un experto en el tema, es simplemente una idea que puede no llevar a ninguna parte.
Un saludo
Publicado por: Nocturno en 22 de Diciembre de 2004, 06:52:00
Codigo:
#include <16F876.h>
#fuses XT,NOWDT,NOPROTECT
#use delay(clock=4000000)
#byte port_b = 6
#define INTS_POR_50ms 49 // (4000000/(4*4*256))/20
#define PASOS_LED1 20 // 1 seg = 50 ms * 20 pasos
#define PASOS_LED2 6 // 300 ms = 50 ms * 6 pasos
BYTE ms50; // Contador de tramos de 50ms
BYTE cuenta_ints; // Contador de interrupciones
BYTE cuenta_led1; // Contador ciclos LED1: 1 segundo
BYTE cuenta_led2; // Contador ciclos LED2: 300 ms
#int_rtcc
void interrupcion() { // aquí entra 49 veces cada 50ms
--cuenta_ints; // decrementamos el contador y si es 0 entramos
}
void main() {
cuenta_ints=INTS_POR_50ms; // se inicializan los contadores
cuenta_led1=PASOS_LED1;
cuenta_led2=PASOS_LED2;
set_timer0(0); // se arranca el timer
setup_counters( RTCC_INTERNAL, RTCC_DIV_4 | RTCC_8_BIT);
enable_interrupts(INT_RTCC);
enable_interrupts(GLOBAL);
while (TRUE){
if(cuenta_ints==0) { // decrementamos el contador y si es 0 entramos
cuenta_ints=INTS_POR_50ms;
if (--cuenta_led1==0) { // si es 0 entramos
cuenta_led1=PASOS_LED1; // volvemos a setear el contador de LED1
output_bit (PIN_B0,!bit_test(port_b,0)); // e invertimos su estado
}
if (--cuenta_led2==0) { // si es 0 entramos
cuenta_led2=PASOS_LED2; // volvemos a setear el contador de LED2
output_bit (PIN_B1,!bit_test(port_b,1)); // e invertimos su estado
}
}
output_bit(PIN_B2,!bit_test(port_b,3)); // si se ha pulsado, encendemos LED3
};
}
Editado: se reduce aún más la carga de la interrupción
Publicado por: pocher en 22 de Diciembre de 2004, 09:02:00
500us=0,5ms -----> 0,5·2=1ms ---> 0,5·3=1,5ms ---> 0,5·4=2ms ... etc
Nocturno el output_bit(PIN_B2,!bit_test(port_b,3)); último ¿no estaría mal? eso estaría contínuamente oscilando, le haría falta delante un if ¿no?
Se podía también, haber hecho sin interrupción detectando la subida de T0IF (así no se gasta tiempo en entrar en la interrupción, aunque en este caso no es crítico).
Tornar cuando tengas un trocito de código muestralo, haz el favor.
Un saludo
Publicado por: Nocturno en 22 de Diciembre de 2004, 09:31:00
Ahora entiendo lo de los 50ms. Vamos, que también lo podría haber hecho con una base de tiempos de 25, 10, 5, 2 o 1ms por ejemplo.
Publicado por: pocher en 22 de Diciembre de 2004, 10:44:00
Lo del 0,5 (o 50) es porque multiplicando esta cantidad por un número entero consigues todas las temporizaciones de números enteros. Si utilizaras como base un 2 y quisieras conseguir un total de 13 o 17, por ejemplo, no hay ningún entero que multiplicado por 2 dé 13 o 17.
Publicado por: pacalaconcurso en 22 de Diciembre de 2004, 13:20:00
unas cosillas:
lo de la base de tiempo dependera de la exactitud que necesitemos en nuestro programa. hablamos de silmutanear procesos en los que la exactitud no es critica (para esas tareas tenemos otras interrupciones) por lo que una base de tiempo de 50 ms esta bien, el error maximo que tendremos sera el correspondiente al SCAN de nuestro programa, por eso los programas deben estar optimizados... ni un delay por encima de 50 ms...
.ojo, andamos buscando una solucion generica, esto es que se pueda usar para temporizar 10 led con cambios minimos o ir añadiendo tareas sin tener que tocar lo ya terminado... eso de rutinas gigantes dentro del codigo de la interrupcion no es buena idea para muchas tareas, aunque funciona muy bien con pocas tareas, como Manolo demuestra con su ejemplo.
saludos
Publicado por: tornar en 23 de Diciembre de 2004, 07:28:00
http://miarroba.com/foros/ver.php?foroid=348538&temaid=2669749
Ahora el siguiente paso seria conseguir una rutina de interrupcion que en vez de devolvernos siempre al mismo proceso, nos cargase en la pila (donde esta cargado el valor de la direccion de memoria desde la que se produjo la interrupcion), el valor de memoria del siguiente proceso.
Mi idea es tener un array de enteros de una longitud igual al nº de procesos que keramos ejecutar concurrentemente, donde almacenemos la direccion siguiente de cada proceso. Ejemplo:
long int s[10]; //para ejecutar un maximo de 10 procesos concurrentemente
s[0]=xxxxx; //Inicializamos todos los procesos con la direccion de su 1ª instruccion
s[1]=xxxxx;
.......
....
s[9]=xxxxx;
Ahora en la rutina de interrupcion, si el proceso que ha realizado la interrupcion es s[0], guardamos la direccion de memoria de la ultima instruccion de nuestro proceso (dicha direccion estara en la pila) en s[0], y cargamos el valor que haya en s[1] a dicha pila; luego cuando se produzca la interrupcion en s[1], guardamos el valor de la pila en s[1] (ese valor, sera la direccion de la ultima instruccion de proceso 1 ejecutada),y cargamos el valor que haya en s[2] en nuestra pila, y asi sucesivamente, luego cuando lleguemos a s[9], volvemos a refererirnos a los valores almacenados en s[1], y de esta forma realizamos concurrencia simulada, teniendo cada proceso una cantidad de tiempo el control del micro.
Si alguien me ayuda para crear esta rutina de interrupcion se lo agradeceria, una vez que tengamos hecho esto, el siguiente paso es crear el tipo abstracto de datos semaforo, que ya le tengo practicamente implementado en casa, para conseguir la comunicacion entre procesos.
Publicado por: pacalaconcurso en 25 de Diciembre de 2004, 15:20:00
tratar de ejecutar los procesos uno detras de otro pero sin interrumpir el micro con delays... basicamente la forma de trabajar de un PLC. para cada tarea tenemos una estructura con sus datos y si otra tarea los necesita simplemente se usan, como las tarea se ejecutan de forma integra antes de iniciar la siguiente los datos en las estructuras son correctos.
claro, hablamos de procesos en los que el tiempo de scan no es critico.. si existe una tarea critica la metes en una interrupcion.
basicamente es realizar un programa en state machine....
si necesitas realmente un rtos mejor usar el picos18 o el salvo... ademas ccs ya incorpora un multitasking pero quien se atreve
saludos
Publicado por: tornar en 27 de Diciembre de 2004, 03:08:00
Pq respecto a lo que postee anteriormente, el principal problema seria que solo se podria usar con micros PIC18xxxx ya que son los unicos que permiten cierto manejo en la pila de interrupciones, puesto que en los demas PIC"s el control de la pila es totalmente invisible al usuario y no se puede ni si kiera meter o sacar valores de la pila.
Publicado por: tornar en 28 de Diciembre de 2004, 03:59:00
Aki teneis la noticia de CCS:
CCS is also testing our new RTOS and our new linker this month. If you would like to participate in testing either of these features AND you have active PCW maintenance e-mail support@ccsinfo.com.
Y aki el enlace a las News de CCS, por si kereis verificar la notica por vosotros mismos:
http://www.ccsinfo.com/news.shtml
Publicado por: Tec_Claudio_Perez en 29 de Diciembre de 2004, 08:13:00
Fijense en este tema sobre la implementación de multitarea aun en micros pequeños, sin acceso a la pila.
http://miarroba.com/foros/ver.php?foroid=6510&temaid=1416423
Está pensado en assembler, pero no sería dificil hacerlo en CSS (En esa epoca solo programaba en ASM).
Algo interesante para agregar son las prioridades.
Supongamos un proceso que sea un led que tiene que titilar a una frecuencia exacta, y otro proceso no tan critico que sea leer el estado de un pulsador.
Como los procesos no tienen la misma prioridad sería interesante poder ejecutarlas con mayor o menor frecuencia de acuerdo a su importancia.
Por supuesto que si la tarea es crítica, lo mejor es usar una interrupcion.
No hace falta que los dos procesos se ejecuten con la misma velocidad. Por lo que se puede agregar un contador adicional que se decremente cada vez que se entra a la rutina. Si el contador llego a 0, se ingresa y se ejecuta el estado correspondiente, sino se sale, y se pasa a ejecutar la siguiente rutina. De esta forma se puede hacer con un contador en 10 para el pulsador, por cada diez veces que se ejecute la rutina del led, se ejecute una vez la lectura del pulsador.
Saludos.
Téc. Claudio J. Pérez
Ciberar-Sistemas & Desarrollos
Jujuy-Argentina
Publicado por: tornar en 03 de Enero de 2005, 05:04:00
El numero de procesos que he puesto es 5 (procesos 0..4), aunke se pueden añadir mas, simplemente modificando las partes pertinentes del codigo y añadiendo el nuevo proceso, podemos trabajar con cualquier numero de procesos, siempre que no nos comamos toda la memoria de nuestro PIC.
Otro apunte, el codigo que va entre los WHILE (1) { printf(lcd_putc,"x"
; } puede ser modificado a gusto del usuario, ya que es el codigo de cada proceso, esos printf solo estan puestos ahi, para realizar pruebas a la hora de programar. Todos los fallos que encontreis ir posteandolos aki, a ver si entre todos podemos hacer una herramienta de concurrencia simulada que sea eficiente y sencilla, ya que creo que es algo muy interesante para cualquiera que este interesado en el mundillo de los microcontroladores. Se pueden aplicar a campos de I.A., para ejecutar varias tareas mientras esperamos el fin de una espera activa, etc.Este es el link, he subido tanto el codigo, como su compilacion y su simulacion en Proteus.
http://miarroba.com/foros/ver.php?foroid=348538&temaid=2706546
Agradeceria de veras cualquier sugerencia, Saludos.
Publicado por: Nocturno en 03 de Enero de 2005, 05:21:00
De todas formas, he estado mirando por encima el código y tiene una pinta acojonante, enhorabuena.
Publicado por: tornar en 03 de Enero de 2005, 05:26:00
Has probado al seleccionar con Proteus en el PIC la nueva ubicacion donde esta el archivo .HEX una vez descomprimido el archivo .RAR?
Saludos.
Publicado por: Modulay en 03 de Enero de 2005, 05:31:00
Por ejemplo,el "if" que te hace volver al primer proceso tras ejecutar el último podrías implementarlo en el código de ese último proceso.
Saludos
Publicado por: tornar en 03 de Enero de 2005, 10:38:00
Antes de implementar los semaforos para la sincronizacion de los procesos, me pasare 2 semanas, probando este codigo y mezclando diversos procesos de manejo de Led"s, LCD, motores, etc. Si alguien me puede ayudar a detectar fallos se lo agradeceria.
Publicado por: tornar en 04 de Enero de 2005, 04:41:00
Aki esta el codigo:
#include <18f452.h>
#fuses NOWDT,NOPROTECT,XT
#use delay (clock=4000000)
#include <LCD.C>
#byte TOSU = 0xFFF
#byte TOSH = 0xFFE
#byte TOSL = 0xFFD
#byte STATUS = 0xFD8
#byte BSR = 0xFE0
#byte STKPTR = 0xFFC
int cola_proc[5][3]; //Concurrencia para 5 procesos
int W_temp[5];
int BSR_temp[5];
int STATUS_temp[5];
int save_W;
int save_STATUS;
int save_BSR;
int i=0;
// ----------------Rutina de interrupcion para cambio de proceso----------------
#INT_RTCC FAST //FAST - para controlar nosotros mismos SAVE,RESTORE(BSR,W,etc.)
void cambio_proceso ()
{
//Almacenamos estado actual del procesador
#asm
MOVWF save_W
MOVFF STATUS, save_STATUS
MOVFF BSR, save_BSR
#endasm
W_temp=save_W;
STATUS_temp=save_STATUS;
BSR_temp=save_BSR;
cola_proc[0]=TOSU; //Salvamos la direccion de la ultima sentencia
cola_proc[1]=TOSH; //ejecutada del proceso i
cola_proc[2]=TOSL;
lcd_putc("f");
i+=1;
IF (i>4) i=0; //Cuando hemos ejecutado todos los procesos, volvemos al primero
TOSU=cola_proc[0]; //Cargamos en la cima de la pila, la direccion de la
TOSH=cola_proc[1]; //siguiente instruccion a ejecutar del proceso i
TOSL=cola_proc[2];
//Restauramos estado del procesador para el proceso i
save_W=W_temp;
save_STATUS=STATUS_temp;
save_BSR=BSR_temp;
#asm
MOVF save_W, W
MOVFF save_STATUS, STATUS
MOVFF save_BSR, BSR
#endasm
}
// -----------------------------------------------------------------------------
main()
{
BOOLEAN proceso=FALSE; //Deshabilitamos entrada a procesos
int x;
lcd_init();
setup_counters(rtcc_internal,rtcc_div_1);
enable_interrupts(INT_TIMER0);
enable_interrupts(GLOBAL);
set_rtcc(0);
// --------------------PROCESO 0--------------------
#asm
push
#endasm
cola_proc[0][0]=TOSU; //Salvamos la 1ª sentencia del proceso 0
cola_proc[0][1]=TOSH;
cola_proc[0][2]=TOSL;
WHILE (proceso)
{
printf(lcd_putc,"0");
}
// -----------------------------
// --------------------PROCESO 1--------------------
#asm
push
#endasm
cola_proc[1][0]=TOSU; //Salvamos la 1ª sentencia del proceso 1
cola_proc[1][1]=TOSH;
cola_proc[1][2]=TOSL;
WHILE (proceso)
{
printf(lcd_putc,"1");
}
// -----------------------------
// --------------------PROCESO 2--------------------
#asm
push
#endasm
cola_proc[2][0]=TOSU; //Salvamos la 1ª sentencia del proceso 2
cola_proc[2][1]=TOSH;
cola_proc[2][2]=TOSL;
WHILE (proceso)
{
printf(lcd_putc,"2");
}
// -----------------------------
// --------------------PROCESO 3--------------------
#asm
push
#endasm
cola_proc[3][0]=TOSU; //Salvamos la 1ª sentencia del proceso 3
cola_proc[3][1]=TOSH;
cola_proc[3][2]=TOSL;
WHILE (proceso)
{
printf(lcd_putc,"3");
}
// -----------------------------
// --------------------PROCESO 4--------------------
#asm
push
#endasm
cola_proc[4][0]=TOSU; //Salvamos la 1ª sentencia del proceso 4
cola_proc[4][1]=TOSH;
cola_proc[4][2]=TOSL;
WHILE (proceso)
{
printf(lcd_putc,"4");
}
// -----------------------------
proceso=TRUE; //Habilitamos entrada a procesos
FOR (x=1;x<5;x++) //Cargamos la direccion del primer proceso y limpiamos pila
{
#asm
pop
#endasm
}
goto_address(*STKPTR); //Ejecutamos proceso 0,que se encuentra en cima de pila
}
Publicado por: tornar en 24 de Marzo de 2005, 06:35:00
1º
No es posible usar delay_ms, solo delay_us hasta un cierto limite, de lo contrario, siempre ejecutara esa sentencia cuando vuelva de nuevo al proceso que la contenia.2º
No es posible usar llamadas a funciones externas grandes, o de lo contrario si se realiza el cambio de proceso en medio de una funcion, tendras problemas luego a la hora de volver al mismo proceso.Un saludo a todos, espero vuestras sugerencias.
Publicado por: Nocturno en 16 de Abril de 2006, 02:31:15