Mejorando a NIPLE_BETA

[pic_es]

 

Saludos:

Creo que podriamos poner en este foro las mejoras que NIPLE debiera de implementar en las nuevas verciones
y seria estupendo que los que tenemos el sof nos dieramos un tiempito para probar los cambios, tambien que si fuera posible que Don Jorge Cano (CANITO)
nos pusiera un beta para poder bajarlo los que tenemos licencias con llave por RS232.

NOTA: Las interrupciones tienen la instruccion de "bcf intcon,gie"  "bsf intcon,gie"que debe de borrarse o se actiban las interrupcines
antes de completarse la que esta en curso.
EJEMPLO:

;------------------------------------------------------------
;                      inicio de la interrupción por gp2
;------------------------------------------------------------
interrupcion_gp2_salir
   bcf intcon,intf
   goto salir_interrupcion
interrupcion_gp2
   bcf status,rp0                   ;cambiar a banco 0
   bcf status,rp1
   bcf intcon,gie                   ;desactivar habilitador general de interrupciones.
   bcf gpio,gp1                     ;apagar opto para siguiente semi-ciclo
.
.

salir_interrupcion
   bcf status,rp0                   ;cambiar a banco 0
   bcf status,rp1
   bsf intcon,gie   
bsf _np_banderas2,sub_inte       ;activar la bandera de rutina cancelada por interrupcion
   movf _np_status,w
   movwf status
   swapf _np_w,w
   retfie


CUANDO ENTRAS A UNA INTERRUPCION EL PIC AUTOMATICAMENTE DIRECCIONA LA MEMORIA 0x04 Y GUARDA EN LA PILA LA DIRECCION DE RETORNO,
Y LO MAS IMPORTANTE DESHABILITA DE FORMA AUTOMATICA LAS INTERUPCIONES.

LUEGO AL EJECUTAR UN "RETFIE" RETORNO DE INTERUPCCION SE RECUPERA LA DIRECCION DE LA PILA Y HABILITA LAS INTERRUPCIONES DE FORMA AUTOMATICA

oJo :  BORRA LAS INSTRUCCIONES QUE AFECTEN A intcon,gie

SALUDOS DESDE MI PEQUEÑO PAIS
El Salvador.

[pic_es]

Hola a todos

aqui tienen una funcion para controlar los motores de pasos

http://www.todopic.com.ar/foros/index.php?topic=1081.0

la funcion recive en "w" el paso actual en nible bajo y en el bit7 la direcciondel giro
devuelve en "w" el paso siguiente.

Ageguemos funciones que nos faciliten el trabajo a todos, porfa don jorge si le es posible que la incorpore en los ejemplos de NIPLE
seria de gran ayuda a los novicios.

Hasta luego.

[pic_es]

Un saludito antes.

Si en las rutinas de usuario guardadas se referencian bits, estos no se guardan
por ejemplo si importas la siguiente rutina:

usr_full_step.rut

Al importar en un proyecto para usarla nos da error (NO SE DECLARA EL REGISTRO NIPLE LO DECLARA AUTOMATICAMENTE EN UNA DIRECCION SIN USAR)
Pero no los bits de este ejemplo.
Por lo que pienso debiera de declararlos de forma automatica, pues si este ejemplo usa un bit en otras funciones podria complicarse al usar muchas declaraciones de bits y realizarlas con ese error significa que el progama se este cerrando a cada momento que queremos editar los bloques que contiene declaracion de bits.
Otra solucion fuera que NIPLE se pudiera declarar los bits por su numero de bits, en modo de EXPERTO por ejemplo, de este modo no fuera necesario que se declararan ya que estan por defecto en las posiciones de (CERO al SIETE).

Me gustaria que las funciones como la anterior que usan un registro y ya no se usara en el resto de la ejecusion fueran registros predefinidos para ahorrar memoria ya que lo usarian todas las funciones para pasar VARIABLES a macros o funciones y devuelvan en ellas el resultado.
por ejemplo: _VAR_MCR_1; _VAR_MCR_2;  ETC


Ademas de las funciones de usuario que son rutinas que se llaman con un CALL RUTINA, se nesecitan poder declarar macros que se inserte el codigo en el punto de llamada en vez de una llamada, lo que tambien hace mas rapido el programa aunque a costa de memoria.

me gustaria que participen con sus dudas o ideas.

Saludos a todos.
desde el pulgarcito de america
El Salvador

[pic_es]

Hola

Me supongo les ha tocado hacer una rutina con temporizador de UN SEGUNDO por lo menos y la grabaron en el pic con el WDT activo por lo que se reinicia cotinuamente, pero al querer agregar el reset del PERRO GUARDIAN "CLRWDT" en niple no funcionó porque el temporizador es mas largo que el tiempo de espera del refresco de CLRWDT y niple no incorpora esto al sof de forma automatica en los temporizadores, SI SOLO DEBE DE CAMBIAR LAS NOP por CLRWDT y listo.

Es mi opinon que debiera agrarlas, ¿No les parece?

Saludos a todos.

[pic_es]

Denuevo aqui...

estoy usando la funcion del A/D y niple genera un retardo en la lectura del puerto que no tiene funcion alguna, sino perder tiempo que necesito para hacer la convercion._ Aqui tienen parte del codigo generado:

leer_ad
   ;realizar conversion a/d
   movlw .200
   movwf _np_temp1
leer_ad_esperar
   decfsz _np_temp1,1
   goto leer_ad_esperar
   bsf adcon0,go_done
   nop
   nop
leer_ad_esperar_fin
   btfsc adcon0,go_done
   goto leer_ad_esperar_fin
   return

oJo::  Deben borrarlo si no quieren el retardo extra.

Que cosas, bueno todos tenemos fallas, pero si colaboramos tendremos un mejor sof y lo mejor en español.


NOTA: Don Jorge,
Debiera poderse configurar la fuente del clk del conversor A/D, por defecto se configura en NIPLE con "32 TOSC 010 1.6 μs 6.4 μs 8.0 μs(3) 25.6 μs(3)"
le dejo estos datos tomados del DATASHEET de microchip


A/D Clock Source (TAD) Device Frequency
Operation ADCS2:ADCS0 20 MHz 5 MHz 4 MHz 1.25 MHz
2 TOSC 000 100 ns(2) 400 ns(2) 500 ns(2) 1.6 μs
4 TOSC 100 200 ns(2) 800 ns(2) 1.0 μs(2) 3.2 μs
8 TOSC 001 400 ns(2) 1.6 μs 2.0 μs 6.4 μs
16 TOSC 101 800 ns(2) 3.2 μs 4.0 μs 12.8 μs(3)
32 TOSC 010 1.6 μs 6.4 μs 8.0 μs(3) 25.6 μs(3)
64 TOSC 110 3.2 μs 12.8 μs(3) 16.0 μs(3) 51.2 μs(3)
A/D RC x11 2 - 6 μs(1,4) 2 - 6 μs(1,4) 2 - 6 μs(1,4) 2 - 6 μs(1,4)
Legend: Shaded cells are outside of recommended range.
Note 1: The A/D RC source has a typical TAD time of 4 μs for VDD > 3.0V.
2: These values violate the minimum required TAD time.
3: For faster conversion times, the selection of another clock source is recommended.
4: When the device frequency is greater than 1 MHz, the A/D RC clock source is only recommended if the
conversion

[cchhaa]

hola pic_es, sin duda este hilo esta interesante, yo tambien uso niple y desde luego una de los fallos mas graves es el de las flechecitas del diagrama de flujo, cuando te juntas con mas de 100 bloques, con diferentes flechecitas para todos los sitios colocadas para que se vea lo mas claro posible y grabas el proyecto, al abrirlo de nuevo las flechecitas estan totalmente descontroladas y no hay forma humana de seguir el flujo del programa, y si es un proyecto antiguo ya olvidate, algunas veces es mejor empezar uno nuevo.

Al final he tenido que ir modularizando al maximo para hacer bloques lo menos numerosos posible pero aun asi cuando se abre un proyecto es complicado de seguir por culpa de las flechecitas, tienen muchas opciones y esta muy bien la idea, pero no se guarda la configuracion con la que se ponen.


un saludo
cchhaa

[jorgecano]

Hola a todos,

Estos comentarios estan iteresantes.
Les comento porque las cosas estan diseñas de esta manera y vemos como podemos mejoralas.

Con respecto a la inactivacion del "GIE" al ingresar a una interrupcion y a la activacion al salir de la inte. Esto ya esta incorporado. Niple ya no agrega estas lineas.


Con respecto al tiempo de espera antes de realizar la conversion AD.
En la hoja de datos del pic (datasheet) se expresa que es necesario esperar un tiempo entre una conversion AD de un canal y otro.
Este tiempo es, como minino, de 2 TAD.  (Nota 4. correspondiente a la figura 11-5: "ANALOG INPUT MODEL").

Hemos realizado muchas pruebas respetando este tiempo y teniamos errores en las mediciones.
El problema que teniamos era que la medicion de un canal afectaba la medicion del canal siguiente.

Por ejemplo, configuramos 2 canales AD. Al realizar una variacion en el canal 1, tambien se modificaba (muy levemente) la medicion del canal 2.

Esto nos trajo mucho dolores de cabeza y lo solucionamos aumentando el tiempo entre la medición de un canal AD y otro. (seguramente el capacitor interno del conv AD tiene que ver con esto).

Por esto, como medida de seguridad, Niple espera unos microsegundos (200 decrementos de un registro) de manera automatica para garantizar que este grave problema no se presente en sus proyectos.

Si alguien tien algún aporte u otra solución, cualquier sugerencia será bienvenida.


Con respecto WDT, les comento.
Estamos trabajando en este tema (ya lo tenemos listo para implementarlo en Niple) y el problema que tenemos para un rapida implementacion es el siguiente (y tenganlo en cuenta por si implementan el WDT de manera "manual"):

El WDT reinicia el pic con una configuración del hardware predertenimada (Pines IO, conv AD, CCP, TMR's, etc) y no reinicia el estado de los registros de usuario.

Esto significa que cuando diseñan una rutina que detecte el reinicio por WDT deben tener en cuenta este punto porque el hardware NO ESTARA configurado como estaba hasta el momento en que se produjo el reset por WDT.

Por esto, los procedimientos para procesar correctamente un reinicio del pic por WDT deben tener en cuenta estos 2 puntos:

1) que la configuracion del hard esta cambiada
2) que los valores de los registros de usuario no estan cambiados

Ademas hay otro punto que estamos analizando para implementar el WDT al niple de manera totalmente automatica:

¿que es lo que "normalmente" deberia hacer un sistema al detectar un reinicio por WDT?

Es decir, cuando el pic esta funcionando en la aplicacion final y se produce un reinicio por WDT:
 - ¿el pic deberia seguir funcionando a pesar el error?
 - ¿el pic deberia enviar señales de alarma por falla del sistema y a la vez seguir trabajando?
 - ¿como evaluar la criticidad de la falla?

Me gustaria conocer su opinion para poder implementar el modulo WDT para que funcione de manera totalmente automatica (e intregada con el resto del proyecto que se esta diseñando) y ajustandose lo mas posible a la aplicación real de este modulo.
 
Como ven, hay cosas que parecen faciles, pero para integrarlas a un sistema tan complejo y que funcionen de manera totalmente automatica y de manera "transparente al usuario" (es decir, que el usuario no se preocupe por estos "detalles") debemos tener en cuenta muchas cosas y por eso a veces algunas soluciones que a primera vista parecen faciles de solucionar, demoran un poco en llegar.

En breve estara inplementado el WDT.

Saludos a todos.
Jorge

[pic_es]

Hola
 Don Jorge, la cuestion no es ¿Que hacer si se reinicia por el WDT?, sino como hacer que el CLRWDT se genere de forma automatica por NIPLE ya que si no se refresca el WDT se generará un reset del pic, lo que se deba de hacer con el reset depende del sof que programemos.

Por ejemplo si mi rutina se cuelga y no se refresca el WDT, se reinica el pic con lo que garantizo que el pic siempre estara operando en el prorama y si se reiniciara me lo advierte de la forma que y lo programe.

A mi parecer lo que debiera NIPLE de hacer es cambiar las instrucciones de NOP por CLRWDT en las rutinas de tiempo por bucle, generar una CLRWDT en cada llamada a sub_rutina al retornar.

Yo de esta forma en frento el problema.

Saludos a todos

[pic_es]

Hola.

Cuando usamos el USART  integrado en el pic tenemos una condicion de error por sobre flujo y otro por encuadre lo que deshabilita el usar a seguir funcionando, por ejemplo si lo programo a 2400 y recivo datos a 9600 hay un sobre flujo y el usart solo recivira el primer byte con error de encuadre y se deshabilita para futuras recepciones, es por esto que niple debiera de agregar los bloques necesarios para verificar tal condicion y reiniciar el USART.

Saludos de El Salvador.

[jorgecano]

Hola a todos,

Tenemos claro que el Niple debe reemplazar todos los NOP por CRLWDT e incluso agregar los CLRWDT en todas las partes de programa donde no hay NOP.
Eso ya esta resuelto, el Niple ya lo hace (en una version de desarrollo que no esta disponible al publico aun).

Nos interesaba conocer opiniones sobre lo que deberia realizar un "sistema profesional desarorllado con PIC" para poder implementar estas opciones en el modulo de WDT y ofrecer el maximo de confiabilidad para proyectos de usuarios no experimentados.

Con respecto al USART, esa opcion tenemos que incorporarla.

Gracias por sus comentarios y aportes.

Un saludo
Jorge.

[pic_es]

Auqi les dejo una imagen de como configuro las interrupciones por USART para corregir por error de encuadre y/o sobreflujo.

Sus comentarios son bienvenidos.

Saludos

El Salvador

[pic_es]

hola Don Jorge.

El pic siempre inicia en la direccion CERO de memoria en cualquier reinicio, por ejemplo al encenderlo o al salir de SLEEP.

por lo que se me ocurre que seria de interes que se iniciara con la prueba si esta saliendo de la funcion SLEEP al leer los bits (POR, BOD, TO Y PD) o un reinicio por desbordamiento del perro guardian WDT, al colgarse el programa o por error de programacion al no poner las instrucciones CLRWDT en el flujo del programa antes del tiempo de 18 milisegundos tipicos o mas si se incrementa con prescalar.

STATUS/PCON BITS AND THEIR SIGNIFICANCE
___________________________________________
POR BOD TO PD
0  X  1  1   Power-on Reset
0  X  0  X   Illegal, TO is set on POR
0  X  X  0   Illegal, PD is set on POR
1  0  X  X   Brown-out Detect Reset
1  1  0  u   WDT Reset
1  1  0  0   WDT Wake-up
1  1  u  u   MCLR Reset during normal operation
1  1  1  0   MCLR Reset during SLEEP

Saludos a todos.

[jorgecano]

Hola,

Gracias por el aporte.

La version de desarrollo de Niple ya detecta automaticamente si el inicio del pic se produce porque se ha desbordado el WDT o no y la unica manera de determinar esto es evaluando estos bits.

Esto estará pronto disponible a los usuarios.

Un saludo
Jorge.

[pic_es]

me he puesto a revisar los datasheet de MICROCHIP Y LA VERDAD QUE ESTA BIEN JODIDO ESTO DEL REINICIO.

estoy en verificar muy bien la documentacion para ver si es posible generar alguna rutina que lo evalue facilmente

estare en esto un rato y luego les dejo conocer mis deducciones al respecto

Saluditos a todos

[pic_es]

Aqui tienen otra fallita del niple, nada del otro mundo, pero al seleccionar una resolucion mayor de 1024x768 en el monitor, ya no se pueden ver las declaraciones de los bits, se ve en gris la ventana.

Queja de http://www.todopic.com.ar/foros/index.php?topic=13355.0

Saluditos a todos