TODOPIC

Microcontroladores PIC => - Niple - => Mensaje iniciado por: pic_es en 30 de Julio de 2006, 17:38:05

Título: Mejorando a NIPLE_BETA
Publicado por: pic_es en 30 de Julio de 2006, 17:38:05
 :2]

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.
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 31 de Julio de 2006, 13:31:15
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.
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 01 de Agosto de 2006, 11:16:07
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
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 03 de Agosto de 2006, 02:32:49
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.
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 03 de Agosto de 2006, 07:55:14
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
Título: Re: Mejorando a NIPLE_BETA
Publicado por: cchhaa en 03 de Agosto de 2006, 12:08:22
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
Título: Re: Mejorando a NIPLE_BETA
Publicado por: jorgecano en 04 de Agosto de 2006, 09:22:25
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


Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 07 de Agosto de 2006, 16:12:16
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
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 07 de Agosto de 2006, 16:18:47
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.
Título: Re: Mejorando a NIPLE_BETA
Publicado por: jorgecano en 07 de Agosto de 2006, 17:28:08
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.
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 08 de Agosto de 2006, 00:59:55
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
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 08 de Agosto de 2006, 06:47:24
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.
Título: Re: Mejorando a NIPLE_BETA
Publicado por: jorgecano en 08 de Agosto de 2006, 09:01:54
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.
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 08 de Agosto de 2006, 14:32:36
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
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 09 de Agosto de 2006, 23:48:44
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
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 10 de Agosto de 2006, 23:09:11
He aqui una inquietud, para NIPLE

En ocasiones tengo que cargar un valor en "w" EL ACUMULADOR para pasarle una variable y/o compararlo por ejemplo si es CERO despues de un retorno de funcion, pero NIPLE no incorpora el "w" en los registros que se acceden en los bloque de asignar valor a registro o en funciones logicas comparar registro, por lo que debo de hacerlo atraves de comandos asm.

Tambien debiera de implementar o incorporar en el retorno la funcion de debolver una funcion boleana verdadero o falso por ejemplo V=>0xFF, F=>0x00
afectando los bits del "estatus" de forma automatica para teclear menos, jejeje, con un simple click

asi solo debiera de probarse el estado de "z=0" para evaluar el resultado de la funcion o probar el "w=0" despues de llamarla.

Saluditos a todos
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 14 de Agosto de 2006, 01:57:17
Hola Don Jorge, y a todos.

Tengo una rutina en ASM y deseo usarla en NIPLE,  me pregunto si es posible que la declare y agrege el codigo ASM en una ventana y de este modo poder llamarla en NIPLE.

En la red encontramos muchos ejemplos de rutinas y si fuera facil de añadilas a niple con solo el hecho de agregarla en una ventana para este proposito ( COPIAR Y PEGAR ) y ya tenemos una rutina agregada con sus respectivos registros SERIA GENIAL !!!!!!, es obio que no se verificaria si esta bien configurada o tiene errores QUE SERIAN DE NUESTRA RESPONSABILIDAD EL REVISAR previa advertencia o si no estan declarados los registros que usa.

PD: Yo he creado una rutina con el mismo nombre de la rutina en ASM y no he puesto codigo alguno escepto un NOP, luego de ensamblar le pego las declaraciones de los registro que usa y pego la RUTINA ASM en vez del NOP.-

ALGO ENGORROSO NO CREEN, pero no conosco otra solucion, agradecere cualquier sugerencia.

Saludos a todos.
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 20 de Agosto de 2006, 18:08:14
Hola a todos, Don Jorge tengo una preguntita, ¿Seria posible que se pudiera seleccionar el orden en que se atenderan las interrupciones?.-

Por ejemplo seleccionar que se verifique por interrupcion por cambio de bit en PORTB antes que TMR0. esa es la idea, ya que una ves creado el entorno no se puede cambiar el orden en que se verifican las interrupciones en NIPLE.

NOTA: Agradecere cualquier comentario, GRACIAS.
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 24 de Agosto de 2006, 02:09:46
Hola de nuevo, parece que solito estoy en esto de reportar dudas o mejoras que pudieran hacerle al NIPLE, pero a mi parecer debo continuar.

Estoy programando un PIC16F872 con un programa que hice para el PIC16F876 que tiene un USART y el pic..872 NÓ, Le cambie a NIPLE que transmita por codigo pero como es el pin del USART lo configura automaticamente usando el USART y no genera el codigo de transmision por codigo, PERO SI LE CAMBIO DE PIN SI LO HACE.

Me parece que se les olvido que generara por codigo la transmision en el pin que por defecto es del USART tx, No  siempre es posible usar el mismo PIC en mi caso e cambiado el PIC16F876 por el PIC16F872 que es el unico que encontre de venta en mi ciudad, ya que se agoto el otro y tienen los mismos pines por lo que me encontre con que no transmitia nada al revisar el datashet es que no trae USART y lo quise cambiar la tranasmision por codigo pero no funciona, al revisar el codigo generardo por NIPLE no era por codigo sino por funcion del USART.

PD. Lo hice haciendo otro programa de transmision por codigo para otro pin y copiando el codigo en la funcion que se genero por USART.

Saludos a todos desde El Salvador
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 04 de Septiembre de 2006, 22:51:22
Hola.

Don Jorge , estoy programando un 16f877 y en el sof usamos el puerto paralelo esclavo (Parallel Slave Port  PORT D + PORT E) del pic

Este se usa con una interrupcion que no esta implementada en NIPLE

Agradeceria que lo tome en cuenta para agregarla en una actualizacion futura

Gracias
Título: Re: Mejorando a NIPLE_BETA
Publicado por: jorgecano en 05 de Septiembre de 2006, 08:13:31
Hola pic_es,

Muchas gracias por tus valiosos aportes.
Todas estas cuestiones estaran solucionadas a la brevedad.

Un saludo
Jorge.
Título: Re: Mejorando a NIPLE_BETA
Publicado por: cchhaa en 13 de Septiembre de 2006, 08:03:37
en casi la totalidad de proyectos que he realizado con LCDs nunca he necesitado tener conectada la patilla r/w al pic, sin enbargo con niple es obligatorio configurarla y tenerla conectada, creo que es un desperdicio y que muchas veces una sola patita de un pic es decisiba a la hora de escoger un uno para un proyecto, hay alguna forma de no utilizar la patilla r/w?

un saludo
cchhaa
Título: Re: Mejorando a NIPLE_BETA
Publicado por: cchhaa en 15 de Septiembre de 2006, 14:25:55
porque no se pueden modificar las tablas? una vez creada y grabada no es posible modificar una tabla por lo que si hay algun error al hacerla no se puede modificar, hay que empezar de cero o modificarla en el archivo de ensamblador con el consiguiente peligro en caso de modificarla mal.


un saludo
cchhaa
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 18 de Septiembre de 2006, 17:15:05
Deseo usar un teclado del que leere los datos que ingrese pero en mi programa e usado las interrupciones del PUERTO B para leer el estado del un encoder por lo que no las tengo disponible para que NIPLE las use el la lectura del teclado.

Mi consulta es don Jorge, o quien me pueda dar una alternativa.

Se puede configurar a niple para que lea el teclado cuando yo se lo indique pero sin usar las interrupciones del puerto B, por ejemplo llamo a la funcion de leer el teclado y me debuelva el dato en W u otro registro.

Los pines que se usen para el teclado serian otros que (RB 4-7 )

Saludos a todos
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 19 de Septiembre de 2006, 01:22:41
Estoy usando les funciones de conversion analogico a digital y en NIPLE e configurado la conversion por interrupcion
pero no tengo la oportunidad de iniciarla automaticamente de nuevo el los bloque de niple o un bloque en NIPLE que inicie una nueva cinversion

por ejemplo bsf adcon0,go_done               ;iniciar la siguiente convercion

Ya que al buscala e tenido que ver el datasheet del pic para saber como iniciarla

Para que sea mas amigable de lo que es NIPLE y teniendo en cuenta que este es el lugar mas adecuado para dar nuestras opiniones en las mejoras que quisieramos en futuras versiones e desidido que es propio el publicarla.

Saluditos
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 19 de Septiembre de 2006, 06:06:37
Don Jorge.

Estoy programando con RS485 y se me presento un error en el programa se colgaba  ????
Al revisar la tarjeta y con las lecturas descubri que una linea de TX del maestro no se conectaba bien con RX del esclavo (soldadura fria) por lo que este se quedaba esperando los datos y al no llegar pues no salia de la intruccion (btfsc portb,5                    ;esperar el byte de checksum 1)

me pregunto si pudiera implementar un temporizador que haga salir de la funcion al NO RECIVIR  los datos que se esperan.

Me parecio que algo asi tenia en una vercion anterior?.

Que tengan un muy lindo Dia
Saluditos a todos los foreros
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 02 de Octubre de 2006, 01:27:40
Hola a todos

E aqui otras quejas de Niple en
http://www.todopic.com.ar/foros/index.php?topic=14013.0
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 02 de Octubre de 2006, 01:38:40
Hola a todos

Estoy progamando y uso un display de 3x4 y en niple se usan las interrupciones del (puerto B 4-7)
para el teclado y al usarlo e notado que si se asignara los pines del puerto (B  4-7) para las filas en vez de las columnas se ahorraria un pin del PIC
al usar el teclado 3x4, ya que el pin del puerto B7 se deja sin conectar lo que nos da un circuito que desperdicia dicho pin  que de otra forma nos serviria para otra cosa en nuestros proyectos

Saludos a todos
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 17 de Octubre de 2006, 19:40:30
Hola a todos

Don jorge estoy usando la transmision por rs485
la pregunta es si pudiera dar la opcion de elejir un rs482 ya que es el que usamos en la fabrica y niple usa un pin para direccionar si esta transmitiendo o reciviendo datos por el rs485.
Ya que el pin que niple ocupa para esta lavor no es necesario en una coneccion de punto a punto con rs482 y seria de gran ayuda el poder usarlo para otras funciones en el proyecto

Un saludo a todos los lectores y le agradeceria que dieran sus opiniones.
Título: Re: Mejorando a NIPLE_BETA
Publicado por: ChóN en 18 de Octubre de 2006, 21:46:18
Hola, yo también he tenido varios problemas con errores en la generación del código asm con niple, para lo cual, he tenido que terminar corrigiendo a "mano" en MPLAB. La pregunta es, (para Canito), si saldrá alguna especie de "service pack" gratuito para los usuarios que ya lo han adquirido. Yo poseo la versión 3, para el 16F62X, 16F8X y 16F87X, que viene con la llave electrónica.
Salu2!


P.D.: Nunca me acuerdo de mandar la planilla de registro que viene en la caja...  :?
Título: Re: Mejorando a NIPLE_BETA
Publicado por: jorgecano en 19 de Octubre de 2006, 21:39:13
Hola Chon,

En este momento esta la versión 4 y la actualizacion es gratis para los usuarios registrados.
Cada vez que sale una nueva version, se informa y actualiza a todos los usuarios y se les envia las actualizaciones gratis.

Seguramente no te ha llegado la información de las actualizaciones porque no has enviado tus datos y por esto no hay forma de ponerse en contacto contigo para hacerte llegar informacion.

Saludos
Canito
Título: Re: Mejorando a NIPLE_BETA
Publicado por: ChóN en 21 de Octubre de 2006, 21:13:43
Gracias por la respuesta Jorge, te mando la planilla de registro entonces.
Salu2!
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 07 de Noviembre de 2006, 01:28:22
Hola

Don Jorge estoy usando el niple para programar un 12f675 y no pude usar las funciones de cambio de estado en los pines ya que el sof de NIPLE no genera las respectivas instrucciones para activarlas y al intentar crear un entorno de interrupcion para el cambio de los pines me dice que no he configurado la interrupcion, me pregunto si alguno de los compañeros del foro ya utlizo estas funciones en NIPLE que post un ejemplito._ si no talvez usted Don Jorge nos comenta si ya esta corregido el errorcito...

Tambien quisiera saber si no seria posible que se pudiera elejir cual interrupcion es de mayor ponderancia o el orden de ellas para atenderlas, asi como el poder generar codigo desde NIPLE que se insertara en la INTERRUPCION despues de guardar el estado y el registro W etc, y poder llamar a una "rutina_x" por ejemplo.

Gracias por atender

Saludos a todos
Título: Re: Mejorando a NIPLE_BETA
Publicado por: jorgecano en 07 de Noviembre de 2006, 12:38:35
Hola pic_es,

¿A que te refieres con "funciones de cambio de estado"?,
¿Te refieres a los comparadores?

saludos
jorge.
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 07 de Noviembre de 2006, 18:56:27
Hola don Jorge

Me refiero a la funcion de cambio de estado en GPO-5 como en RB4-7 para otros pics, me explico??
Le adjunto la imagen de la pagina del datasheet.


Nota Ademas estoy usando el A/D y no funciona en modo de interrupcion, al generar las instrucciones de configuracion define un dato con 6 bits??
Le adjunto la imagan donde he configurado a pie el A/D.

Saludos
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 07 de Noviembre de 2006, 18:59:53
Aqui tiene la otra imagen
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 15 de Noviembre de 2006, 03:01:08
Saludos a todos
Don Jorge le dejo la imagen de la rutina que no pude hacer en NIPLE porque no tiene incorporada la istruccion "RETLW  ", y el archivo en asm como lo edite para que lo compare si existe alguna forma de hacerlo en niple me agradaria que la pusiera en el foro o agregarla en proximas verciones de NIPLE

Gracias por su respuesta.

Un saludito a todos en el foro
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 15 de Noviembre de 2006, 03:02:23
El asm de la imagen editada es esta
Título: Re: Mejorando a NIPLE_BETA
Publicado por: pic_es en 19 de Noviembre de 2006, 00:06:43
Hola

Don Jorge le dejo la imagen de la rutina que no pude hacer en NIPLE porque no tiene incorporada la istruccion "RETLW  "

la he editado como creo debiera de verse en caso de agregar la instruccion "RETLW 0x--

Si se pudiera ademas seleccionar el origean de la rutina o que se agregara despues del bloque principal del programa "MAIN" seria de gran ayuda ya que no funcionara bien si se coloca en bloque  en banco diferente del cero sin odificarla.

Saludos a todos
Título: Sensor con SRF10
Publicado por: Ojos_de_luna en 02 de Diciembre de 2006, 03:26:54
Hola!  :)
   
     Hace tiempo veo lso foros de aqui y dan unas ideas muy originales en programacion en niple y en asm, sin embargo tengo un pequeño problema...basicamente es con un sensor ultrasonico que deseo agregarle a un robot, es un sensor SRF10 el cual es un dispositivo I2C y pues tengo un problema que en el niple no se puede escribir o leer en I2C pues tiene opciones para memorias y mi sensor no lo se, tiene opcion en comunicaciones y dentro de esta se halla el modulo master de I2C sin embargo sucede el siguiente problema:

*como no existe modulo precargado de sensor ultrasonico debo de hacer uno nuevo.
*doy la direccion del modulo en binario que es (default por fabrica) 11100000 (E0 hex)
 -----> marca error pk solo se admiten direcciones de 7 bits...
 -----> entonces introduzco los 7 primeros bits y el octavo lo uso como el numero de dispositivo al cual deseo dirigirme, dando la posibilidad de solo 
           dirigirme a 2.
 ----->conf velocidad a 22Khz
 ----->cargo la direccion 0 con el valor 51 en hex para pedir al sensor que haga un sensado en cm

Cuando presiono "enter" me manda el error de "numero demasiado grande"...pk sale esto? es un error de niple o estoy haciendo algo mal?, pk el mismo error sale si uso un ADC y doy de num de dispositivo el num 8...sale el mismo msj...me podrian aclarar esto el pk de este mensaje y como hacer para que deje de salirme...otro dato curioso..niple apesar de este error genera el archivo asm y mas curioso..si se compila en MPLAB pero...no corre bien el programa en el PIC16F877A a 20 Mhz. :(

PD el modulo que uso es el siguiente: http://www.superrobotica.com/S320114.htm la pagina esta en español y muy bien descrita, de antemano agradesco su ayuda :)
Título: Re: Mejorando a NIPLE_BETA
Publicado por: cchhaa en 30 de Diciembre de 2006, 09:21:25
estoy realizando un proyecto con el pic 16f876 y por desgracia he tenido que abandonar el proyecto que estaba realizando en niple, llevaba mas de dos semanas de trabajo y he tenido que empezar de nuevo programando en C, (no sabia y ahora estoy aprendiendo) las razones son las siguientes:
- nesecitaba multiplicar 16x16 bits y dicha rutina no funcionaba
- necesitaba temporizaciones variables y tampoco funcionaba

estos dos inconvenientes los cosegui solucionar adaptando rutinas de ensamblador y creando subrutinas de usuario en niple, algo muy laborioso cuando se trata de hacer una subrutina a base de comando de ensamblador

pero ya tube que desistir cuando el programa crecio y llego a ocupar mas de un banco de los cuatro que tiene el pic 16f876, dejo de funcionar tal y como debia funcionar el programa y como habia hecho hasta entonces, el solito se pasaba de una subrutina a otra sin presionar botones y yo ya no llego a tanto con ensamblador para poder solucionarlo a mano. Es mas, no quiero ni pensar lo que pasaria si hiciera un programa que ocupara toda la memoria del pic (los cuatro bancos)

Bueno un saludo y espero que estos fallos los puedan solucionar en proximas versiones, aunque he probado la version 5 beta y por lo menos a mi me funciona peor que la 4 ya que ni un solo codigo creado se puede transformar en .hex con el MPLAB.


cchhaa
Título: Re: Sensor con SRF10
Publicado por: blackcat en 04 de Enero de 2007, 16:39:25
Hola!  :)
   
     Hace tiempo veo lso foros de aqui y dan unas ideas muy originales en programacion en niple y en asm, sin embargo tengo un pequeño problema...basicamente es con un sensor ultrasonico que deseo agregarle a un robot, es un sensor SRF10 el cual es un dispositivo I2C y pues tengo un problema que en el niple no se puede escribir o leer en I2C pues tiene opciones para memorias y mi sensor no lo se, tiene opcion en comunicaciones y dentro de esta se halla el modulo master de I2C sin embargo sucede el siguiente problema:

*como no existe modulo precargado de sensor ultrasonico debo de hacer uno nuevo.
*doy la direccion del modulo en binario que es (default por fabrica) 11100000 (E0 hex)
 -----> marca error pk solo se admiten direcciones de 7 bits...
 -----> entonces introduzco los 7 primeros bits y el octavo lo uso como el numero de dispositivo al cual deseo dirigirme, dando la posibilidad de solo 
           dirigirme a 2.
 ----->conf velocidad a 22Khz
 ----->cargo la direccion 0 con el valor 51 en hex para pedir al sensor que haga un sensado en cm

Cuando presiono "enter" me manda el error de "numero demasiado grande"...pk sale esto? es un error de niple o estoy haciendo algo mal?, pk el mismo error sale si uso un ADC y doy de num de dispositivo el num 8...sale el mismo msj...me podrian aclarar esto el pk de este mensaje y como hacer para que deje de salirme...otro dato curioso..niple apesar de este error genera el archivo asm y mas curioso..si se compila en MPLAB pero...no corre bien el programa en el PIC16F877A a 20 Mhz. :(

PD el modulo que uso es el siguiente: http://www.superrobotica.com/S320114.htm la pagina esta en español y muy bien descrita, de antemano agradesco su ayuda :)


Yo tambien tuve los mismos problemas con el sensor SRF08 ... lo que hice fue utilizar los modulos para lectura y escritura de memoria RAM que incluye el niple 4 .. una vez compilado el proyecto se ingresa a MPLAB y se modifican las direcciones desde el esamblador ... me imagino que utilizas la que viene de fabrica que es E0 por lo que debes cambiar la direccion A0 que pone el niple a E0 y listo ...
Título: Re: Mejorando a NIPLE_BETA
Publicado por: blackcat en 04 de Enero de 2007, 16:52:14
estoy realizando un proyecto con el pic 16f876 y por desgracia he tenido que abandonar el proyecto que estaba realizando en niple, llevaba mas de dos semanas de trabajo y he tenido que empezar de nuevo programando en C, (no sabia y ahora estoy aprendiendo) las razones son las siguientes:
- nesecitaba multiplicar 16x16 bits y dicha rutina no funcionaba
- necesitaba temporizaciones variables y tampoco funcionaba

estos dos inconvenientes los cosegui solucionar adaptando rutinas de ensamblador y creando subrutinas de usuario en niple, algo muy laborioso cuando se trata de hacer una subrutina a base de comando de ensamblador

pero ya tube que desistir cuando el programa crecio y llego a ocupar mas de un banco de los cuatro que tiene el pic 16f876, dejo de funcionar tal y como debia funcionar el programa y como habia hecho hasta entonces, el solito se pasaba de una subrutina a otra sin presionar botones y yo ya no llego a tanto con ensamblador para poder solucionarlo a mano. Es mas, no quiero ni pensar lo que pasaria si hiciera un programa que ocupara toda la memoria del pic (los cuatro bancos)

Bueno un saludo y espero que estos fallos los puedan solucionar en proximas versiones, aunque he probado la version 5 beta y por lo menos a mi me funciona peor que la 4 ya que ni un solo codigo creado se puede transformar en .hex con el MPLAB.


cchhaa



Desde hace tiempo vengo criticando los mismos problemas con la version 4 pero el señor Cano no me da pelota de seguro porque esta mejorandolos en su nueva version 5 de niple ... ese problemilla del salto de rutinas siempre es un dolor de cabeza y lo he solucionado tratando de ubicar en la pagina 0 las rutinas de que tienen accesos a interrupciones o a otras rutinas ... y las rutinas que solo incluyen algun procedimiento tales como mostrar en LCD o la de multiplicacion 16x16 ( que tuve que hacer en ensamblador!!!! ) ubicarlas en las otras paginas ... sino aun no funciona lo que hago es ir ubicando las rutinas en varias paginas hasta que funcione ... tambien he notado que cuando el pic debe atender varias interrupciones al mismo tiempo como el puerto serie, la interrupcion externa RB0 y el teclado, sencillamente se vuelve loco y salta a otras rutinas !!! lo que he hecho es deshabilitar interrupciones en partes de codigo donde no son necesarias por ejemplo, si tenes un proyecto que el pic atiende comandos por pc y teclado .. lo que se puede hacer es que mientras se atiende el teclado desactivar el serial y viceversa...       
Título: Re: Mejorando a NIPLE_BETA
Publicado por: Radiotecnico en 12 de Enero de 2007, 12:19:24
Los efuersos por mejorar el NIPLE continuan. Por parte de Jorge
Aun con los detalles, que estan por superarse, se pueden construir programas de alta complegidad, en tiempo recor. :)
Solo se tiene que encontrar la via o el modo de hacerlo, con lo que ya esta implementado.
Este programa, es muy prometedor , no lo pierdan de vista. Será uno de los programas de mayor demanda, para el futuro inmediato.
Título: Re: Mejorando a NIPLE_BETA
Publicado por: ChóN en 18 de Enero de 2007, 01:56:03
Hola, yo obtuve la actualización a la versión 4, pero la verdad es que tampoco me ha dado resultados, por lo que sigo utilizando la 3. Los problemas en la 4 estan fundamentalmente en las interrupciones, en varios casos, niple las declara en el código de fuente, pero no genera la rutina correspondiente, dando un error del compilador (obvio), MPLAB en mi caso.
Saludos.
Título: Re: Mejorando a NIPLE_BETA
Publicado por: blackcat en 20 de Enero de 2007, 23:15:10
La verdad  8) yo no he tenido problemas con la compilacion en MPLAB con niple 4 y ya he probado todas las interrupciones y todas funcionan correctamente .. a mi parecer y despues de tantas criticas considero el NIPLE como un excelente programa y siempre lo recomiendo .. aunque todavia falta por corregir ciertos detalles el programa es muy funcional ... felicitaciones don Cano y a sus colaboradores y les deseo que 2007 este lleno de exitos!!      :-/
Título: Re: Mejorando a NIPLE_BETA
Publicado por: ChóN en 07 de Febrero de 2007, 01:46:30
Alguien sabe cómo lograr que el pcf8583 genere una interrupción con el timer en un tiempo distinto a 1 segundo? He probado de todas formas, y el muy choto sigue dando siempre 1 segundo. Por otra parte, necesito saber como lograr configurar los años en un valor mayor a 3. Ya tengo en cuenta que el integrado lo hace para considerar años bisiestos, pero no logro acomodarlo para que me de el valor deseado (por ejemplo 2007, donde los últimos 2 dígitos son del año a configurar). Llevo 415 bloques y no logro terminar por este tema!!!
Saludos.
Título: Re: Mejorando a NIPLE_BETA
Publicado por: blackcat en 09 de Febrero de 2007, 01:25:35
Hola .. yo utilize el pcf8583 en un proyecto y me funciono genial pero el problema que tuve fue que niple no configuraba bien las alarmas ( nada raro!!! ), recalco que el ajuste de fecha y hora si funciona correctamente!! , revisé un poco el codigo en ASM que este generaba y al parecer la parte de las alarmas estaba incompleta .. por eso decidí configurar yo mismo las alarmas utilizando la hoja de datos y para aprovechar el niple y no hacerlo en ASM utilize los modulos de escritura en memorias RAM por I2C, claro, despues debes ingresar el MPLAB y corregir la direccion de escritura del dispositivo en el codigo ASM por la direccion que configuraste para el pcf8583; ahora para configurar las alarmas debes configurar 4 registros del pcf8583, has lo siguiente utilizando las escritura en memoria RAM:

Paso 1 - Direccion: 0     Valor a grabar: 04h                 Este es el registro de control/status
Paso 2 - Direccion: 8     Valor a grabar: 11000XXXb      Activamos el timer y que genere interrupciones, las XXX significan si
                                                                                es por segundos, minutos, horas, nose cual será la opcion que deseas
Paso 3 - Direccion: 15   Valor a grabar: XXXXAAAAb     Este valor es el tiempo que quieras si vas a poner 15 segundos debes
                                                                                ponerlo en BCD y NO en binario, es decir 15h y no 0Fh
Paso 4 - Direccion: 7     Valor a grabar: 00h                 Inicializa el registro timer y empieza el conteo

  Ahora cuando el dichoso timer genere la interrupcion, solo debes repetir los pasos 1 y 4, pero te recomiendo que hagas una rutina de usuario y que lo ejecutes todo para ahorrar espacio en el pic ... Respecto a los años; el bendito pcf8583 no se le puede programar los años a como te entendi, por ejemplo, si estamos en 1999 NO podes poner 99 ... el pcf entiende 00h para año bisiesto y 01h, 02h y 03h para los años siguientes y como los años bisiestos se repiten cada 4 años este vuelve a empezar en 00h, es por eso que solo utiliza 2bits para el año ... el año 2004 fue bisiesto esto seria 00h, 2005 seria 01h,  ahora 2007 seria 03h y si tu proyecto sigue funcionando hasta el proximo año el pcf volveria a comenzar en 00h donde 2008 es bisiesto por ello debes idear un algoritmo que almacene "como todos los humanos entendemos" los años ... Espero que te sirva!

Título: pcf8583
Publicado por: panchito24 en 25 de Noviembre de 2009, 23:58:31
hola amigos:
yo hace un mes que estoy con el mismo problema, necesito que el pic 16f84a lea el mes, dia, hora y minuto, pero no logro hacerlo funcionar. Me dice error en los puertos.
si alguien me podria ayudar a programar el pcf 8583 en hora y poder leerlo estaria muy agradecido. desde ya muchas gracias.