SoloCodigo

Puedes crear otro pwm por codigo, uno por cada timer y mas de uno asignados a un timer si son multiplos entre si, por ejemplo que vaya a la mitad de frecuencia o de ciclo en alto, mediante una variable contadora de temporizaciones.

En español van a encontrar poca cosa, yo no he buscado a fondo pero no he encontrado nada.
Yo no soy nadie aqui, pero que tal si antes de pedir las cosas nos esforzamos un poco por nosotros mismo y mas si eres un profesor pues ese es tu trabajo y no el de otro; siento ser grosero pero me cansa ver como la gente recurre a los foros no buscando ayuda sino que les hagan el trabajo

A mi particularmente me gusta mas el asm, tambien es que he usado poco el C, pues tampoco llevo en esto de los pics mucho. Para aprender a usarlos creo que es mejor el asm que te permite ver como se debe configurar el pic para cada proposito y para el uso de los perifericos.

Una de las grandes pegas es que el codigo te llena mucho espacio (en cantidad de codigo escrito me refiero), y es mas dificl, a priori, llevar una idea de todo lo que se va haciendo; ademas en assembler es mas facil cometer errores pues tienes que ir configurando todos los bits y registros, y es facil que se te pase alguno o que intercambies el orden de las acciones que a veces da igual pero otras no. como ventajas, el codigo resultante es mas compacto y por tanto tardara menos en ejecutarse y un control total sobre el pic

La "pega" de C,a mi forma de ver, es esa que las aplicaciones ocupan mas espacio y tardan ams en ejecutarse cosa que en la mayoria de los procesos no es muy relevante, y el problema del tamaño esta solucionado debido al aumento de la capacidad de memoria de los pics que se hacen para facilitar su programacion en C. Por otra parte, la programacion en C es mas simple y facil de llevar, ademas de ser mas legible a simple vista por el usuario. Tambien los compiladores mejoran cada vez permitiendo codigos mas compactos

Como conclusion, para empezar con los pics recomendar el assembler si se quiere paralelamente con c, pero creo que todo el que programe pics deberia pasar por assembler. Y para grandes funcionalidades, como por ejemplo teclado que permita configuara parametros a usar en el programa, sacar datos por lcd conversiones adc y comunicaciones pues la resolucion desde c parece mas viable, aunque con assembler se pueda aunque quedara un tocho considerable de codigo

Los procesadores tipo Risc como los Pics se caracterizan por optimizar codigo por dos
caminos (Tamaño o Tiempo de ejecucion).Caso curioso que para lograr la mayor velocidad hay que evitar compactar codigo, si no crees revisa los ejemplos de Microchip
para tamaño y velocidad,te daras cuenta que para velocidad no escatiman en el gasto de memoria.Asi que no va lo de mas compacto = mas velocidad por el contrario.

A ver, yo no soy el master de los pics, pero si no me equivoco segun los datasheet las instrucciones solo gastan 1 o 2 ciclos de reloj, dependiendo de cual sea. Por tanto a mas instrucciones, mas tiempo eso no tiene vuelta de hoja

No es cierto por que el Hardware que estas programando lo diseñaste y construiste tu mismo por tanto estas siempre ligado a su esencia.

Y luego lo que se pierde de vista el hardware es inevitable, digas lo que digas de todas formas yo no voy a discutir mas este tema. Exite una regla en programacion, y es que a mayor nivel en el lenguaje, mayor facilidad de programacion y menor dominio del hardware y optimizacion, cada vez esto va a menos pero sigue estando ahi. Aunque a lo mejor eso solo pasa en el resto del mundo excepto en tu caso.

Durante años programe para varios micros (Z80,8031,68000,6800,Pics,ARM) en asembler se lo que es lidiar con asemblers de diferente tipo pasando horas revisando rutinas que parecian optimas y que no funcionaban por que colocates datos en un registro o memoria ya ocupada del cual no te diste cuenta.

En ese caso no es assembler quien falla, es el programador


Para Jaumegs en la seccion de soluciones de hard y de soft puse un ejemplo de como usar la uart y de como use el adc

Si el problema es por la tension negativa del sensor otra opcion es emplear un amplificador operacional sumandole una tension positiva cuyo valor sea igual a la que genera el sensor a la temperatura minima de trabajo, asi para la temperatura negativa mayor tendras 0 voltios a la salida del amplificador, pero ya tendras que variar el programa, la solucion de usar el 335 me parece mas razonable, pues simplifica el diseño pero si quieres o necesitas usar el 35 esa es una solucion

A lo mejor me equivoco, pero el 16f877 solo tiene un conversor que se puede configurar a 8 ó 10 bits, y tiene 8 entradas ( no recuerdo los puertos, creo que el puerto A y el puerto E, 5+3) posibles al conversor que se van multiplexando segun programa. Si quieres conectar 14 necesitas multiplexar a cada entrada 2 posibles por ejemplo, o usar 2 pic comunicados, no se cuanto puede costar 1 multiplexor analogico por eso te digo lo de los dos pics.

Esos reguistros los debes declarar al inicio del programa, despues de declarar el dispositivo, por ejemplo:

;dispositivo
   LIST P=PIC16F876
   INCLUDE <P16f876.INC>
;el include sirve para que cargue un archivo que declara los registros del sistema
;status,trisb,intcon,option_reg...(todos en mayusculas)
;variables necesarias
PDe10 EQU 20H
PDe11 EQU 21H 

Esto asigna tus variables a los registros determinados por esas direcciones, lo unico que debes tener en cuenta es no hacerlo sobre registros del sistema, en el pic16f84 creo que es a patir de la direccion 0C, eso lo puedes mirar en el datasheet
EDITO>> Para el 16f874 no los conozco, si es como el 876 sera a partir de la direccion 20

Lo he intentado recargando y activando el timer antes de retornar de la interrupcion y tampoco me funciona, es decir antes de retornar, desactivo el timer cargo los valores de timer1h/l y vuelvo a activarlo

 
  ;ISR
  ORG  04H
  BCF    PIR1,0;Borro bandera
  DECFSZ  CONTADOR
  GOTO   RETORNA;Va a retornar de la int,
  BSF    TRANSICION,0
  GOTO  VERSAL
VERSAL
  MOVLW  0C8H;realiza 200 temporizaciones antes de variar salida
  MOVWF  CONTADOR
  BTFSS  PORTB,0;Analiza la salida
  GOTO   ACTIVAR;Va a activar salida
  BCF    PORTB,0;DESACTIVA
  GOTO RETORNA
ACTIVAR
  BSF    PORTB,0;activa
RETORNA
 BCF    T1CON,0;desactivo el temp
  MOVLW  0DCH
  MOVWF  TMR1L;CARGA TIMER1BAJO
  MOVLW  0BH
  MOVWF  TMR1H;CARGA TIMER1ALTO
  MOVLW  31H
  MOVWF  T1CON;PRESCALER 8 Y ACTIVA
 RETFIE

Rutina para la transmision, transmite un dato realiza un retardo y manda otro dato, es un bucle infinito


Este programa puede modificarse para mandar un dato de cualquier tipo en el momento deseado sin retardos, el que yo realice era solo a modo de prueba

Pues esta rutina esta preparada para configurar el conversor y sacar el resultado por los puertos B y C del micro, esta diseñada para el 16f876


La rutina de retardo depende del cristal, se utiliza para que se estabilice el convertidor y para un cristal de 4 Mhz bastara con 20 microsegundos
Alguna modificacion interesante es en lugar de justificar a la derecha,llenando de ceros los bits mas sifnificativos del registro ADRESH justificar a izquierda(llena de ceros los bits menos significativos de ADRESL), asi los 8 bits mas significativos estan en un mismo registro ADRESH, y podemos usar el convertidor como si fuera de 8 bits, mejorando la respuesta ante el ruido(al tener menos sensibilidad) y facilitando el manejo de la conversion, siempre que no sea critica la precision en la conversion

Pues muchas gracias, ahora estoy con el ccp1 y con el timer1, el timer creo que se usarlo pero se me presenta un problema al recargarlo, si me tienes algo de informacion te lo agradeceria. Tambien si lo creeis conveniente se podia abrir un hilo sobre el 16f876 con ejemplos de sus nuevas funciones con respecto al f84, yo tengo rutinas para usar el adc y la usart

Entiendo lo que dices, y  es bueno experimentar y seguir aprendiendo sobre este gran mundo de los pic's, ademas me parece una buena salida en el caso de no disponer de ningun pic con modulo usart.
Para casos que requieran seguridad y velocidad en el envio, estos modulos permiten al micro hacer otras tareas durante la comunicacion mientras tambien se encargan de la recepcion, transmision y de verificar si existieron errores,todo ellos solitos lo que si se hace por software nunca se conseguira al 100% o complicara demasiado y limitara el software.
El F84 ha sido y será mitico, ese cacharrito sigue dando guerra y creo que casi todos hemos pasado por el para el aprendizaje; y en casos en lo que no se requieran conversores ni comunicaciones o muy poca comunicacion, sigue siendo un gran pic. Yo he empezado hace poco en esto de los pic's y empece con el, y ahora estoy peleandome con el 16F876 que presenta nuevos modulos y tipos de comunicaciones