PIC 18f4550 y CCS compiler

[navegante 420]

Bueno empecemos con un repertorio de cagadas habituales al programar este poderoso pic.

En primer lugar, Oscar pedirte disculpas por abusar de ti tan vilmente. Pero es que el profe que tengo, ayer, aludiendo que el no conocia este pic, se lavo las manos y sutilmente dijo que nos buscasemos la vida, y en ello estoy, he ido a la libreria y estoy a la espera que me llege un libro que me ayude, pero mientras haber si me puedes ayudar con este esquema y programa.


41197

me encuentro con que el led rojo que se encuentra en RA4, El led verde de RA6 y el bit 3 del dysplay 2 que esta en RE3 no consigo que se encienda.

Te agradeceria que le hecharas si puedes un vistazo, nosotros pensamos que son fuses que no hemos puesto, pero no se.

#include <18f4550.h>
#fuses XT,NOWDT,NOPUT,NOPROTECT,BROWNOUT,NOMCLR,NOLVP

#include <float.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#use delay(clock=8000000)


void main()
{

setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_CLOCK_DIV_2);
setup_psp(PSP_DISABLED);
setup_spi(SPI_SS_DISABLED);
setup_wdt(WDT_OFF);
setup_timer_0(RTCC_INTERNAL);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_timer_3(T3_DISABLED|T3_DIV_BY_1);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
setup_oscillator(OSC_8MHZ|OSC_TIMER1|OSC_31250|OSC_PLL_OFF);

// TODO: USER CODE!!
output_high(PIN_D0);
output_low(PIN_D1);
output_high(PIN_D2);
output_low(PIN_D3);
output_low(PIN_D4);
output_high(PIN_D5);
output_low(PIN_D6);
output_low(PIN_D7);

output_high(PIN_E0);
output_low(PIN_E1);
output_low(PIN_E2);
output_low(PIN_E3);
output_high(PIN_A0);
output_low(PIN_A1);
output_low(PIN_B3);
output_low(PIN_B2);

output_high(PIN_C0);
delay_ms(1000);
output_high(PIN_A4);
delay_ms(1000);
output_high(PIN_C4);
delay_ms(1000);
output_high(PIN_C5);
delay_ms(1000);
output_high(PIN_C6);
delay_ms(1000);

output_low(PIN_C0);
output_low(PIN_A4);
output_low(PIN_C4);
output_low(PIN_C5);
output_low(PIN_C6);
output_high(PIN_A6);
}

muchas gracias

[Aunolose]

No puedo entretenerme mucho en el código, pero todo me suena a configuración de los bits necesarios para que estos pines funcionen como entrada/salida digital, y es que RA4 y RA6 se usan para varias cosas, que se deben configurar para que funcione bien, RE3 por ejemplo se puede gastar como entrada de reset, si en algún registro (que no recuerdo) no pones nada, se usa para este fin, no para salida.

Esto que te digo es independiente del registro TRISX, primero configuras el pin para que se use como Digital I/O y después con el TRIS configuras si entrada o salida.

Revisad el datasheet y una sugerencia, si no vas a usar nada, mejor "ni lo menciones" veo que tienes muchos "disable", quitalos todos y añádelos solo si tienes problemas, me parece que solo es obligado el de los convertidores A/D, pero hasta eso creo que no hace falta. Te lo digo porque estas funciones hacen cosas que interfieren con otras y puede que sea eso lo que te está pasando.

Resumiendo, para lo que quieres hacer, quita todas las funciones y deja solo los output_bit() a medida que vayas haciendo cosas, añades funciones, pero por defecto, todo viene "quitado", no hace falta que los quites tu.

Veo también un "TODO" (para hacer) eso puede ser porque has generado el código anterior con el wizard que trae el CCS, pero eso solo lo genera si le dices "esto no, esto tampoco", mientras que si no le dices nada, pues no pone nada, con lo cual lo deja todo en "entrada/salida digital", que es lo que buscas.

Edito, el bit RE3 se configura con los "Configuration bits", quizá tengas que poner algo de código para ello, o se pueda configurar aparte, tratándose del CCS, seguramente lo hará con código.

[navegante 420]

Pues para no poderte entretener, ya me has dedicado mas tiempo que el que dice ser mi profe de sist. micro-programables y electrónica de sistemas.... hay que joerse....

ok, empezare de 0 sin usar el wizard, haber si soy capaz. Porque voy un poco justo de tiempo y no creo que me de tiempo de leerme el libro que me ha llegado, como deberia, "Copilador C CCs y simulador proteus para microcontroladores PIC" de la editorial marcombo. si no lo tienes y quieres hecharle un vistazo dimelo que te paso un pdf. A mi me ha gustado mucho y creo que gracias a él no te machacaré tanto. :;

[Aunolose]

No hace falta que empieces de cero, o que no uses el wizard, simplemente, no marques nada que no vayas a usar, es decir, si no vas a usar el SPI, ni entres en esa ventana, y lo mismo con los otros dispositivos.

RE3 si tienes que cambiarlo, porque si no, lo toma como reset y no podrás usarlo ni como salida, ni como entrada.

El programa lo puedes dejar como está, borrar o comentar todas las funciones y añadir lo relativo a RE3.

[navegante 420]

¡¡¡ Dios existe!!! .....

¡¡¡ Siempre hay una luz al final del tunel!!!

ETC, ETC.....

Para que RE3 no actue de reset y lo configuremos como Entreda (esta mal el grafico que nos dice como E/S) hay que modificar manualmente el registro CONFIG3H y poner a 0 el bit MCLRE.

La duda que me queda es porque RC4 y 5 me funcionaban si segun en data solo pueden actuar como entradas. (otra cosa que esta mal en el gráfico)

Creo que con el data completo que encontré, el pdf que encontre y me pasastes de la UPV más el libro que te dige que me hiba a comprar, al final seré capaz de conseguir que este potentisimo pic empiece a hacer lo que yo quiero, y no lo que a él le de gana. Aunque el programa duele a la vista, combinando parte en ensamblador y partes en C, jejejejeje



PD. Cuando puedas vaciate un poco el buzón que lo tienes a rebentar, jejejeje

[Aunolose]

Ya está vacío, pero usa el otro, "el de verdad"...

[navegante 420]

Ya, ya oscar, pero era para contestarte el tuyo.

Porcierto solo me falta RC0 por configar... Si esta tarde me dejan y no me molestan los compis, creo que ta podré empecezar a encender los 2 display dobles y la secuencia de leds.

Y ponerme de una vez con los dos comparadores, las interrupciones de RB4-7, y la comunicación I2C, Casi na, jejejeje

[Aunolose]

Poquito a poco, las interrupciones, y más en los PIC, son un pelín peliagudas, hasta que le coges el truco, que básicamente consiste en salvar todo el estado de la maquina, esto es para ensamblador, sabes que cuando se produce una interrupción, el procesador deja lo que está haciendo y pasa a atender otra cosa, pero a lo mejor estabas sumando, con lo cual no puedes usar el acumulador, porque lo borras, así que tienes que salvarlo primero, para recuperarlo después, en el PIC esto no es algo intuitivo... por eso digo que cuesta, lo mismo debes hacer para cualquier registro que quieras conservar, o que vayas a modificar, cuando acabes de hacer lo que toque, recuperas lo que hayas que grabado y vuelves a donde estabas, si era la suma, pues sigues sumando.

Si lo haces en C es mucho más fácil, ya que el compilador se encarga de salvar todo lo importante, salvo las variables de usuario, pero esas son fáciles de ver. En este caso el truco es averiguar como leches se le indica al compilador que es una rutina de interrupción, y de qué interrupción en concreto se trata (serie, externa,...) recuerdo que en el CCS no era muy difícil.

Y por ultimo, esto ya para aplicaciones críticas en el tiempo, averiguar que partes del código del programa principal se pueden interrumpir y cuales no, por ejemplo, calculas lo que tienes que poner en el display de cuatro dígitos, antes era "10" y ahora "9", primero calculas uno de los y después el otro, si a medias te interrumpen y en la interrupción es donde lo escribes, puede que ponga "19" o "0", esto se evita haciendo que en ese trozo de código no se pueda interrumpir, y acordándose de volver a activar las interrupciones al acabar...

Esto suele ser lo que más cuesta, averiguar los trozos de código que se pueden y cuales no, por que no siempre se ve a simple vista.

[navegante 420]

Leches, no habia caido en ese pequeño detalle de evitar las interupciones cuando escribo, gracias.

Como has podido ir viendo mi problema ahora mismo no es de programación sino de configuración, Pasar del 16f84 al 18f4550 esta siendo un suicidio, y más cuando el profe (con el argumento de "a mi me han bajado el sueldo" como diciendo me pe pregunteis nada que no sea del temario) no es que me ayude demasiado, sino mas bien pone trabas pues esta muy negativo.

Ahora te preparo un word con el asunto y te lo paso haber si me puedes ayudar con la cabecera para configurar el pic.

[Aunolose]

Miraré las configuraciones, pero ya te digo que no cambies nada que no utilices, por ejemplo, por defecto todo son entradas digitales (salvo la del reset), las patas que uses así, no las toques.

El CCS tiene un asistente (wizard) que te ayuda a configurarlo todo ¿está disponible para ese PIC?

Como ultima opción (o primera) puedes pasarte al MCC18, de microchip, gratuito para educacional, programas desde el MPLAB, que ya conoces, con su simulador y tal.

Si el CCS tiene el asistente para ese PIC puedes configurar por ejemplo el reloj, y que te ponga las instrucciones en ensamblador, luego las copias al otro y ya lo tienes.

Para usar el USB posteriormente te hace falta un oscilador interno, tenlo en cuenta por si es más fácil empezar ya con él.

Para funcionar con 8 Mhz interno, por ejemplo, estas instrucciones funcionarían en el MCC18, es decir, estos bits los que debes configurar de la manera necesaria en el CCS.

#pragma config FOSC = INTOSC_EC // Frecuencia con oscilador interno, alta velocidad
#pragma config PLLDIV = 2 // dividido por 2 (8Mhz) (Sería para USB, pero con el cristal de 8Mhz externo)
#pragma config CPUDIV = OSC1_PLL2 // interno /1 y el PLL x2

[navegante 420]

Ya he usado el wizard, pero tres que he hecho, tres que me ha hecho cabezeras diferentes, y claro lo que me mosquea, es que no se donde ver lo que modifica, o escribe.

eso de no controlar yo el pic bit a bit, lo llevo muy mal, y claro, manejar un 18 bit a bit creo que puede ser una locura.

[Aunolose]

Hace tiempo que no lo gasto, pero ¿no hay un botón donde puedes ver lo que va a poner antes de que lo ponga? a mi me suena que si, así lo hacía yo...

Ahh, una cosa, se puede integrar el CCS en el MPLAB, y allí ya sabes usar el simulador, es lo que yo hacía cuando lo gastaba, el wizard para lo básico, lo copiaba al otro y a funcionar...

[navegante 420]

Eso de intregrar el ccs en el mplab me lo tienes que explicar un dia como hacerlo, que estoy hasta los guews del comparador y del i2c, no no ver donde falla.

[Aunolose]

Prueba aquí:

http://www.ccsinfo.com/downloads/setup_mplab_plugin.exe

sacado de esta pagina.

CCS, Inc. - Downloads (http://www.ccsinfo.com/downloads.php)

[navegante 420]

Thanks, Thanks y muchas gracias, siendo un ejecutable, supongo que teniendo los dos programas instalados lo ejecuto y ya ta., no????

[Aunolose]

Supongo que si, aunque recuerdo que según la versión que utilizabas de MPLAB y/o de CCS había que cambiar también la ruta del compilador en la pestaña Projet-> Set Languaje Toolsuite, allí debes seleccionar el CCS y donde está.

También recuerdo que a veces dan problemas algunas librerías y tal, es más raro, pasa sobre todo cuando no has tenido cuidado en poner la ruta del proyecto correcta, entonces la situación de los directorios se dice en Project-> Build Options-> Project -> Directories allí decides el lugar donde están las librerías que vas a usar, que pueden ser del propio proyecto (tipo user.h) o del compilador (tipo stdio.h)
Esto ultimo cuando más problemas da es cuando estas trabajando con varias versiones del mismo programa, si el compilador coge la librería del proyecto anterior, ya tienes el lío, por eso es importante tener el proyecto "limpio" desde el principio, colocando todo lo necesario en un solo lugar, y dejando los comunes siempre en el mismo sitio.

Con el tiempo puedes tener tus propias librerías, por ejemplo para controlar un LCD, lo puedes colocar dentro del directorio del compilador "para siempre" y no tienes que moverlo de un sitio para otro, pero esto ya es cuando ya has trabajado tanto con esa librería que la controlas 100% y sabes que funciona también al 100%

[navegante 420]

Pues haciendo caso a tus recomendaciones. empeze paso a paso con este potentisimo pic.

1º configurar los puertos de salida. ok
2º configurar y probar las interrupciones de RB4-RB7 ok
3º Configuarar comunicacion I2C con saa 1064. TRas volverme loco con el proteus de los "collons" resulta que lo estaba haciendo bien. Era el proteus el que no lo simula
4º configuara el comparador analogico, que me volvi loco pero al final lo consegui. Tambien gracias el proteus, y un poco a mi error de confindir conparacion analogica con digital, y que supuse erroneamente que tenia que configurar el puerto como entradas analogicas para hacer la conversion.

Aqui te dejo un video de pruebras con el saa1064


http://www.youtube.com/watch?v=oac0v8yGEIs


http://www.youtube.com/watch?v=BoXQlBZFPdI

[Aunolose]

No veo nada, ni un enlace...

[Gerard-2]

Un saludo, hacia dias que no miraba esto, vaya nivel!
Me hareis mirar estos escarabajos mas de cerca jaja

Aunolose, no se si navegante ha reparado los enlaces, pero en este momento si veo dos youtubes incrustados del saa1064.

Voy a ver si me pongo a rueda estudiando estos hilos :) , tengo el tema muy abandonado desde hace años.

Saludos

[navegante 420]

Cagon to lo que se menea, Ahora que tenia todo funcionando por separado, al probarlo todo junto, resulta que las interrupciones de funcionan, si que llega bien la señal a los puertos, pero no me activa ninguna,

Sabeis si por un casual si, cuando se activan 2 o mas interrupciones hay que hacer algo mas que declararlas????, no se como darles prioridades, o ordenarlas..... no se algo?????

muchas gracias.

[Gerard-2]

De mientras aparece algun MAESTRO he leido :) que el bit GIE en el INTCON.7 se deshabilita en el reset en la gama del 16FXXX, es supone que hay que forzar la activacion.

Del tema pic no tengo ni idea, pero por lo que leo...tendras que insertar Enable_Interrupts GLOBAL que te va a poner GIE y PEIE a 1, el PEIE es la habilitacion de int's de perifericos, o sea INTCON se cargara con C0h, no estaria de mas que verificaras si en el codigo en asm lo esta haciendo realmente.

Supongo que es un Global Interrup Enable y hace falta que dentro del codigo se fuerce la activacion de las int's, no se si ya lo tenias controlado.
Cuando indicas 'declarar' entiendo que solo es pseucodigo para el C, eso no es realmente ninguna ejecucion.

[Gerard-2]

En main ademas de habilitar las int's hay que añadir ext_int_edge xxx correspondiente segun el tipo de flanco a detectar.

Algunas dudas en voz alta respecto al compilador Ccs:

GIE se inhabilita ante la respuesta a una int para evitar responder a nuevas int's, supongo que el codigo C se encarga de restaurar GIE al salir igual que el resetero del flag correspondiente a la int activa ¿?

No veo prioridades por hard o programables de int's, supongo que tienen una prioridad secuencial todas al mismo nivel .

Al salir de una sbr de la int, respeta o borra los flags de llamadas de otras int's ocurridas durante el proceso de la anterior sbr ? esto hace referencia al tema de 'coincidencia de int's '

Me extraña que no haya un reg de prioridades ¿?

Dentro de la #INT_RB habra que descubrir que pin ha desencadenado la INT de entre todos ellos ?

[Gerard-2]

mirando un poco mas en el data sheet del 16f4550....hay dos niveles de prioridad, el superior 'pisa' al inferior en ejecucion (normal !)
Vectores de prioridad sup en 8h y la prioridad inf en 18h, habra que mirar el ccs como se lo monta para gestionar los niveles de prioridad.

[Aunolose]

Joe, entro ahora que me tengo que marchar.

En el 4550 hay dos niveles, como dice Gerard, pero dentro de esos dos niveles no hay prioridad como tal, ahora lo explico. Hasta que domines el tema te sugiero que mandes las interrupciones a la misma rutina, aunque sea con una llamada desde otra.
En esa rutina es donde le darás prioridad a las interrupciones que quieras ¿como? tan sencillo como mirar primero las más prioritarias, es decir lo que quieres es que sea la del puerto serie la primera, pones un "if (es la serie)" primero, y así con todas, recuerda que algunas flags de interrupción se deben desactivar "a mano", en la rutina, para evitar problemas yo lo suelo hacer en todas, si no lo haces, esa interrupción se produce cada vez que salgas de la interrupción, entrando en un bucle infinito.

quedaría algo así:
if (la que quiero primero)
{
...
}

if (la que quiero después)
{
...
}

if (la siguiente)
{
...
}

if (la ultima)
{
...
}

Fíjate que no son if-else, pues podría ser entonces que alguna no se atendiera nunca.

Puesto que las de mayor nivel interrumpen a las de bajo nivel, puede ser que dentro de la rutina llegue una interrupción más prioritaria, así que mientras controlas el tema, lo mejor es desactivarlas todas al entrar en ella y volverlas a activar todas después. Ahora no estoy seguro de que si no tocas nada, todas tienen el mismo nivel, pero me parece que si, así que no creo que esto sea prioritario pero haciéndolo pierdes muy pocos ciclos de reloj y puedes evitar problemas.

Una vez tengas claro cual debe ir la primera y cual la ultima es cuando pasas unas al de más prioridad y otras las dejas en el de menos, recuerda que en este caso una de más prioridad puede saltar cuando estés atendiendo una de menos prioridad.

Lo que no pasa es que estando tratando una de un nivel, te interrumpa una del mismo nivel, aunque si dentro de los if que pongas, se produce la ultima a medias, se tratará cuando acabe la anterior y todos felices, si es al revés, pues se espera a que acabe y después vuelve a entrar. Esto ya es lo ultimo a mirar.

Lo de gerard lo he leído muy por encima, creo que en algunas cosas decimos lo mismo.

[Aunolose]

ah, que ahora puedo ver los enlaces, pero no me da tiempo, a ver esta noche.

[navegante 420]

Pordonad, es que estoy tan agoviado con esto que ya pierdo el oremus, teoricamente deveria de funcianar el miercoles y veo que no me va a ser posible.....

Lo de los dos niveles lo tenia claro, pero al usar dos interrupciones lo que no tenia nada es donde manda cada una, y claro si no os pongo el texto poco podeis ver, XD.

Os dejo el texto y haber si puedes oscar ponerme eso que dices de dedactivar las interrupciones manualmente, o si por el contrario esta to mal, que no me extrañaria lo mas minimo.


#include "F:\puente definitivo\gestorcarreras.h"
#use fast_io(D)


#int_RB
void RB_isr(void)
{
if(input(pin_B4)==0) //Botón de programación
{
output_high (pin_D2);
delay_ms(500);
output_low (pin_A4);
}
if(input(pin_B5)==0) //botón inicio de carrera
{
output_high (pin_D3);
delay_ms(500);
output_low (pin_D3);
}
if(input(pin_B6)==0) //cuenta vueltas coche 1
{
output_high (pin_D4);
delay_ms(500);
output_low (pin_D4);
}
if(input(pin_B7)==0) //cuentavueltas coche 2
{
output_high (pin_D5);
delay_ms(500);
output_low(pin_D5);
}
}

#int_COMP
void COMP_isr(void)
{
if (C1OUT==0) output_high (pin_D0); Seguidor de tension coche1
if (C1OUT==1) output_low(pin_D0);

if (C2OUT==0) output_high (pin_D1); seguidor de tension coche 2
if (C2OUT==1) output_low(pin_D1);
}



void main()
{
set_tris_D(0x1F);
setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_CLOCK_DIV_2);
setup_psp(PSP_DISABLED);
setup_wdt(WDT_OFF);
setup_timer_0(RTCC_INTERNAL);
setup_timer_1(T1_INTERNAL|T1_DIV_BY_1);
setup_timer_2(T2_DISABLED,0,1);
setup_timer_3(T3_DISABLED|T3_DIV_BY_1);
setup_vref(VREF_LOW|15);
setup_comparator(A0_VR_A1_VR);
enable_interrupts(GLOBAL);
enable_interrupts(INT_RB);
enable_interrupts(INT_COMP);
setup_oscillator(OSC_8MHZ|OSC_TIMER1|OSC_31250|OSC_PLL_OFF);

// TODO: USER CODE!!

[Aunolose]

Bueno, con algo más de tiempo.

Resulta que estas haciéndolo con el CCS, no me acordaba... y mira el titulo del hilo :oops: , con este hace tiempo que no trabajo, pero creo que el orden de prioridad será el que orden en que pongas las rutinas de interrupción, también me suena algo de poner números para hacerlo pero mejor que lo mires antes.

Las interrupciones del puerto B se activan por cambio de nivel, es decir, que se activan tanto cuando suben como cuando bajan, lo del flanco, si no recuerdo mal, es para las interrupciones-interrupciones, es decir, INT0 e INT1. Como tu solo haces caso cuando el nivel es 0, es como si solo hicieras caso del flanco de bajada. Poner retardos de 500ms (medio segundo) dentro de una interrupción es eliminar la filosofía de las interrupciones, pues durante ese tiempo nadie podrá interrumpir, si da la casualidad que son las cuatro, estás dos segundos sin que se pueda hacer nada en el programa principal, aunque es muy sencillo decirlo y no tanto cambiarlo...

No veo el bucle principal, supongo que lo tendrás en el "todo"... (que para los ajenos al tema es "to do", "por hacer")


Dices que antes funcionaba, pero ahora no, ¿te pasa con las interrupciones del puerto B? lo digo porque son las prioritarias y las que, aunque lento por los 500ms, deberían encender y apagar los bits que tocan. ¿lo hacen? prueba bit por bit, dándole tiempo a los 500ms.

[Aunolose]

Para desactivar todas las interrupciones seguramente tendrás un disable_interrupts(GLOBAL) y para desactivar una en concreto será igual, pero en vez de GLOBAL, la que toque. pienso que esto debería hacerlo el compilador, pero lo puedes poner al principio de cada rutina de interrupción, recuerda activarla después al final del cada una también. Como tienes mucho tiempo, no influirá ese poquito que pierdes en hacerlo.

[Aunolose]

Las interrupciones del comparador ¿cuando se producen? ¿al cambiar también?

aquí en vez de

if (C2OUT==0) output_high (pin_D1); seguidor de tension coche 2
if (C2OUT==1) output_low(pin_D1);

podrías poner

if (C2OUT==0) output_high (pin_D1)
else output_low(pin_D1 ; seguidor de tension coche 2

lo digo por evitar una comparación, también sirve para C1OUT

en otros compiladores esto también serviría.

pin_D1= !C2OUT;

pero es mejor no jugársela hasta comprobar que todo funcione... además que pierde claridad.

[navegante 420]

Jejeje, pues si, vaya, poner delays en interrupciones, jejejeje,

Se trata solo de estructura básica, osea, de ver si las interrupciones las detecta o no, y en este caso es que no.

Obviamente la estrucctura del programa, en caso de que consiga que funcione, no incluye delays en la interupccion, si no una serie de comprobaciones para saber de donde viene y que es lo que ha pasado, para modicar el valos del swicth.


El programa principal sera swich (select) con todos los case que tengamos.

LAs interrupciones de rb efectivamente soloo me interesan en el franco de bajada, ya que no dejan de ser interruptores que estan a 1 y que cuando se activan pasa a 0.

El comparador efectivamente me interesa saber tanto el franco de subida como el de bajada, ya que es el seguidor de tension de los coches y me indican si estan moviendose o no.

[Gerard-2]

FLANCOS: Si, solo para RB0(Int0) y RB1(Int1).
-------------------------------

Cualquier modificacion sobre los pines RB7:4 -> pone RBIF a 1 en el reg INTCON.0

Su posterior lectura lo resetea. Se entiende que se va a leer para procesar que bit a sido afectado y proceder con la isr.

- - - - - - - - - - - --

Permiso de int sobre RB7:4 en RBIE de INTCON.3

[Gerard-2]

Continuo a nivel de asm, por si hay que revisar el codigo generado o monitorizar paso a paso.
La prioridad se determina por el bit RBIP sobre el reg INTCON".0
---------
Respecto al C, aunque solo sea a nivel 'formal' no me gusta ver que se configura algo de un osc despues !!! de configurar el timer ¿?
mucho menos que se habilite la int GLOBAL !!! antes de que se habiliten las ints individuales, nos puede dar problemas a la primera vuelta de prog. por ejemplo, no lo haria en asm, mucho menos compilando C.

[Gerard-2]

Interrupcion del comparador segun el man:

The comparator interrupt flag is set whenever there is
a change in the output value of either comparator.
Software will need to maintain information about the
status of the output bits, as read from CMCON<7:6>, to
determine the actual change that occurred

Dejo este apunte respecto a forzar la isr del comparador escribiendo un 1 en el flag CMIF en PIR2.6, para forzar una actualizacion desde la primera vuelta de programa, por ejemplo.

The CMIF bit (PIR2<6>) is the Comparator Interrupt Flag. The CMIF bit must be reset by clearing it. Since it is also possible to write a ‘1’ to this register, a simulated interrupt may be initiated.
_________________

Recordar, para afinar posteriormente ,que se dispone de:


INT_COMP
INT_COMP FAST



INT_COMP HIGH

igual que para las otras int's.
______________________

Como siempre si las int's de RB vienen de interruptores, los rebotes pueden durar mas que la misma isr.
Y puestos a reflexionar hacemos la accion ... al pulsar?, ...al soltar ? o solo activo un flag y una sbr controlada por un timer 50 veces por segundo se encarga de hacer cada una de las acciones finales y borrar los flags dejados por la isr de los pulsadores...
Nos acercamos al rtos :sad4:

[Aunolose]

En el PIC la gestión de las interrupciones en ensamblador no son tan fáciles como con el 8051, no hay una pila para guardar cosas, y es complicado guardar hasta la palabra de estado. En C el compilador lo hace todo, incluso puedes usar el ensamblador ya en la rutina de interrupción, pero esa parte te la ahorras (la de guardar el estado). Otro problema es que solo hay dos niveles de interrupción (en estos PIC, en otros ni eso) entonces todas van a parar al mismo sitio y tienes que averiguar cual es la que se ha producido, con C solo tienes que colocar donde toca la rutina y él lo gestiona, el compilador debe incluso borrar el bit asociado, aunque si el tiempo no es crítico, prefiero borrarlo yo para no dejar cabos sueltos.

Ya me costó que navegante se pasará al C, no me lo líes ahora otra vez :D

Otro detalle importante es que un buen compilador de C genera el mismo o mejor código que un programador mediocre de ensamblador, aunque eso aquí no lo podemos aplicar porque no somos mediocres, si no "la leche de güenos" :D


Lo que comentas de activar las interrupciones, antes o después no creo que sea mucho problema, pues cuando se active la global, saltará primero la de más prioridad y después la otra, para estos casos ni usaría los niveles, pues el tratamiento no es crítico, da igual cual se trate primero, lo que es importante es que todo esté en su sitio antes de que se pueda producir una.

En lo de los rebotes si tienes mucha razón, quizá por eso puso los 200 ms, para eliminarlos :D, también pienso que los pulsadores normales se pueden mirar perfectamente en el bucle principal, siempre es más lento el dedo que el programa... y a poco que sea lento, él solo se carga los rebotes. Si hay algún pulsador crítico, tipo "reset software", se le puede dedicar una patilla de interrupción, y si no, una resistencia y condensador adecuado en cada uno.

Lo que has puesto en ingles quiere decir que sí es necesario por software el bit de interrupción del comparador

[navegante 420]

En el PIC la gestión de las interrupciones en ensamblador no son tan fáciles como con el 8051, no hay una pila para guardar cosas, y es complicado guardar hasta la palabra de estado. En C el compilador lo hace todo, incluso puedes usar el ensamblador ya en la rutina de interrupción, pero esa parte te la ahorras (la de guardar el estado). Otro problema es que solo hay dos niveles de interrupción (en estos PIC, en otros ni eso) entonces todas van a parar al mismo sitio y tienes que averiguar cual es la que se ha producido, con C solo tienes que colocar donde toca la rutina y él lo gestiona, el compilador debe incluso borrar el bit asociado, aunque si el tiempo no es crítico, prefiero borrarlo yo para no dejar cabos sueltos.

pues no se porque me da a mi que por ahi van los tiros con mi programa.


me costó que navegante se pasará al C, no me lo líes ahora otra vez :D

Oscar no te hagas ilusiones, que en cuanto acabe con esto, me vuelvo a mi ensambler. :)


detalle importante es que un buen compilador de C genera el mismo o mejor código que un programador mediocre de ensamblador, aunque eso aquí no lo podemos aplicar porque no somos mediocres, si no "la leche de güenos" :D

Yo si soy la leche en ensambler, en C no tengo ni P idea


que comentas de activar las interrupciones, antes o después no creo que sea mucho problema, pues cuando se active la global, saltará primero la de más prioridad y después la otra, para estos casos ni usaría los niveles, pues el tratamiento no es crítico, da igual cual se trate primero, lo que es importante es que todo esté en su sitio antes de que se pueda producir una.

En lo de los rebotes si tienes mucha razón, quizá por eso puso los 200 ms, para eliminarlos :D, también pienso que los pulsadores normales se pueden mirar perfectamente en el bucle principal, siempre es más lento el dedo que el programa... y a poco que sea lento, él solo se carga los rebotes. Si hay algún pulsador crítico, tipo "reset software", se le puede dedicar una patilla de interrupción, y si no, una resistencia y condensador adecuado en cada uno.

Lo que has puesto en ingles quiere decir que sí es necesario por software el bit de interrupción del comparador

[Gerard-2]

Entiendo perfectamente lo del asm, nos ha pasado a todos los que hemos empezado desde abajo, a los informaticos de gestion, que estan en la nube, y nunca mejor dicho, no los pasa, les pasa otras cosas por que no bajan al hardware.

A lo que iba, que cuesta mucho empezar con el C, pero luego te das cuenta que para mover mucha info, o prog complejos en asm no terminas nunca, es imposible, reaprovechar, repasar y depurar codigo no es tan complicado, y lo digo yo que en esto voy justito. Pasar del asm al C NO TIENE VUELTA ATRAS !!! lo siento navegante :) no te resistas, siempre queda paris, alguna rutinita superrapida en asm para quitar el quoquilleo, es muy raro que haga falta en un micro rapido.

____________________

Lo de la gestion de las INT, ya lo tengo claro, hay dos vectores en la 8 y 18h, tambien he visto que por defecto, un bit a cero de reset, quedan todas al mismo nivel para compatibilidad descendente, si se quieren dos niveles hay que forzar un bit de config para ello.
_______________________

Respecto al manual de microchip, The comparator interrupt flag is set whenever there is a change
entiendo que decimos lo mismo: Se activa el flag de la INT del COMP cuando hay un cambio, este flag desencadena la llamada de la int a nivel de hard si esta permitida a todos los niveles, si queremos supervisar por soft, podemos consultar como esta el flag en cuestion, si queremos forzar la INT, es mas elegante poner el flag a 1 y dejar que se genere la INT solita.

[Aunolose]

Me comí una palabra, puse "es necesario por software el bit..." y debería poner "es necesario borrar por software el bit..." vamos que si se activa la interrupción (de una manera u otra) y no borras el bit correspondiente antes de salir de la rutina, en cuanto salgas, se vuelve a producir y ya tienes el lío.

[Gerard-2]

Vale, es que no estaba seguro de entenderte el sentido. Si, segun el man indica que 'debe borrarse el bit' , que lo deja a cargo del programa. Queda la duda de si el compilador tendra la gentileza de ahorrarnos este paso o mejor, lo que dices de forzarlo a reset y olvidarse del problema.

[Aunolose]

Exacto, eso es lo que quería decir.

Mirad lo que he encontrado en el MCC18


When an interrupt occurs, a low priority interrupt saves only the PC (Program Counter
register). For high priority interrupts, the PIC18XXXX core automatically saves the PC,
WREG, BSR and STATUS registers.
6.8 MATH


Cuando ocurre una interrupción, una interrupción de baja prioridad solo salva el PC (Contador de Programa)
Con interrupciones de alta prioridad el núcleo de los PIC18 salva automáticamente el PC y los registros WREG, BSR y STATUS.


Esto es nuevo para mi, se ve que espabilaron de anteriores modelos, el caso es que el compilador tiene menos que hacer, voy a seguir leyendo.

[navegante 420]

Eso, Oscar, haber si una vez que he salido de mi error, crei que el miercoles que viene era 25, consigo que funciones este programa, si hace falta te pago una comida el sabado donde me dias.

[navegante 420]

Bueno vamos por faena seria, que me queda 1 semana para solucioner el tema.

Este es el último codigo que he montado.

#include <18F4550.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES INTRC_IO //Internal RC Osc, no CLKOUT
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOBROWNOUT //No brownout reset
#FUSES BORV20 //Brownout reset at 2.0V
#FUSES NOPUT //No Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES IESO //Internal External Switch Over mode enabled
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES PBADEN //PORTB pins are configured as analog input channels on RESET
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOCPB //No Boot Block code protection
#FUSES MCLR //Master Clear pin enabled
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES PLL12 //Divide By 12(48MHz oscillator input)
#FUSES CPUDIV4 //System Clock by 4
#FUSES USBDIV //USB clock source comes from PLL divide by 2
#FUSES VREGEN //USB voltage regulator enabled
#FUSES ICPRT //ICPRT enabled

#use delay(clock=8000000)
#use i2c(Master,Fast,sda=PIN_B0,scl=PIN_B2)
#use fast_io (A)
#use fast_io (B)
#use fast_io (C)
#use fast_io (D)

int configsaa[7];

void write_saa1064 ()
{
i2c_start();
i2c_write(configsaa[0]); //direccion
i2c_write(configsaa[1]); //registro de control
i2c_write(configsaa[2]); //luminosidad,funcionamiento
i2c_write(configsaa[3]); //display 4
i2c_write(configsaa[4]); //display 3
i2c_write(configsaa[5]); //display 2
i2c_write(configsaa[6]); //display 1
i2c_stop();
}

#int_RB
void RB_isr(void)
{
if(input(pin_B4)==0)
{
output_high (pin_D0);
delay_ms(500);
output_low (pin_D0);
}
if(input(pin_B5)==0)
{
output_high (pin_D1);
delay_ms(500);
output_low (pin_D1);
}
if(input(pin_B6)==0)
{
output_high (pin_D2);
delay_ms(500);
output_low (pin_D2);
}
if(input(pin_B7)==0)
{
output_high (pin_D3);
delay_ms(500);
output_low(pin_D3);
}
}

/*#int_COMP
void COMP_isr(void)
{
if(C1OUT==1)output_high (pin_D4);
else output_low (pin_D4);
if(C2OUT==1)output_high (pin_D5);
else output_low (pin_D5);
}*/



void main()
{
set_tris_D (0b11000000);
set_tris_A (0b11111111);
set_tris_B (0b11111100);

setup_timer_0(RTCC_INTERNAL);
setup_timer_1(T1_INTERNAL|T1_DIV_BY_1);



//setup_vref(VREF_LOW|15);
//setup_comparator(A0_VR_A1_VR);

enable_interrupts(GLOBAL);
enable_interrupts(INT_RB);
//enable_interrupts(INT_COMP);

setup_oscillator(OSC_8MHZ|OSC_TIMER1|OSC_31250|OSC_PLL_OFF);

// TODO: USER CODE!!

}

en el que el comparador pasa de mi, no hace na de na. Buen si me pasa la tension de un lado al otro.

las interrupciones de rb, van, bueno van pero con pequeños saltos, y algun que otro error de detección,

Para solucioner esto ultimo, habia pensado que en vez de que compruebe puerto por puerto en busca de com estan, hacer una captura de los 4 bits y ver lo que ha paso desde esa captura, que os parece?????

lo del comparador, no tengo ni idea, y eso que he probado un monton de convinaciones.

[Aunolose]

A ver lo que te puedo decir,
-es normal que "vayan a saltos", has puesto 500 ms de retardo, es decir, cuando pulsas uno, hasta medio segundo después no mira el siguiente, y si en ese tiempo pulsas, no hará caso, pues cuando salga, borra la interrupción, pulsa los botones cada ¿2 segundos? y comprueba si se enciende y apaga el led correspondiente

-supongo que sabes que tienes comentado el tema del comparador, pero cuando lo "descomentes" recuerda borrar el bit de interrupción del comparador, que ahora no sé cual es, pero que debes hacerlo por software, como hemos dicho por arriba, justo antes de salir de la rutina de interrupción, antes del corchete "}"

[Gerard-2]

solo es una pregunta, te han impuesto la condicion de poner las int sobre la botonera?

No me gusta que los programas se detengan en algun proceso, incluso para ver si el pulsador realmente se ha pulsado, por descontado que los delays hay que hacerlos con una base de tiempos generada desde un timer y quiza una isr asociada de conteo sobre un byte o word si es demasiado rapido. Si el t no es critico el prog principal puede gestionar estos tiempos supervisando un reg descontador precargado. Con un timer de 10mS +1 Byte tengo para 2,5 seg, i con el mismo timer y otro byte tengo otro retardo de 2,5 seg. Si es distinto de 0 esta haciendo un retardo, si ha alcanzado le 0 ya ha finalizado, de cero no tiene que bajar, la gestion la lleva la int del timer, main secuencialmente solo verifica como esta y actua si hace falta.

Cuando pueda me miro las configs, que voy colgado en ese tema.
Donde estan declarados los 7 valores de configsaa? o viene en otro fichero?

[navegante 420]

A ver lo que te puedo decir,
-es normal que "vayan a saltos", has puesto 500 ms de retardo, es decir, cuando pulsas uno, hasta medio segundo después no mira el siguiente, y si en ese tiempo pulsas, no hará caso, pues cuando salga, borra la interrupción, pulsa los botones cada ¿2 segundos? y comprueba si se enciende y apaga el led correspondiente

-supongo que sabes que tienes comentado el tema del comparador, pero cuando lo "descomentes" recuerda borrar el bit de interrupción del comparador, que ahora no sé cual es, pero que debes hacerlo por software, como hemos dicho por arriba, justo antes de salir de la rutina de interrupción, antes del corchete "}"

Ok ahora miro lo del comparador.

en cuanto a lo de los saltos de las interrupciones de RB solo me pasa con los detectores de paso de los coches.
Si solo funciona el coche 2 va de PM,
Si funciona solo el coche 1 alguna vez se despista y me cuenta como si pasara el coche 2.
Si corren los dos, lio, aveces detecta bien a los dos coches, aveces detecta a los cos como si fueran el coche 2 y habeces sin pasar ninguno, cuenta como si pasara el coche 2.

[navegante 420]

solo es una pregunta, te han impuesto la condicion de poner las int sobre la botonera?

No me gusta que los programas se detengan en algun proceso, incluso para ver si el pulsador realmente se ha pulsado, por descontado que los delays hay que hacerlos con una base de tiempos generada desde un timer y quiza una isr asociada de conteo sobre un byte o word si es demasiado rapido. Si el t no es critico el prog principal puede gestionar estos tiempos supervisando un reg descontador precargado. Con un timer de 10mS +1 Byte tengo para 2,5 seg, i con el mismo timer y otro byte tengo otro retardo de 2,5 seg. Si es distinto de 0 esta haciendo un retardo, si ha alcanzado le 0 ya ha finalizado, de cero no tiene que bajar, la gestion la lleva la int del timer, main secuencialmente solo verifica como esta y actua si hace falta.

Cuando pueda me miro las configs, que voy colgado en ese tema.
Donde estan declarados los 7 valores de configsaa? o viene en otro fichero?

Supongo que lo de la botonera como interrupciones es cuestion de mania mia, seguramente por falta de practica, que se supone que tendria que haber cogido en clase. Lo cierto es que no me fio de hacer un bucle en el programa principal, porque tengo la sensacion de que algun cambio de estado se le puede escapar, sobre todo el contador de paso de vueltas. Y si lo pongo en interrupciones, pues eso, ya no se escapan.

[navegante 420]

Os subo un esquemita del tema para que lo veais.

46711

[navegante 420]

Oscar tienes un e-mail,

[Aunolose]

Ok ahora miro lo del comparador.

en cuanto a lo de los saltos de las interrupciones de RB solo me pasa con los detectores de paso de los coches.
Si solo funciona el coche 2 va de PM,
Si funciona solo el coche 1 alguna vez se despista y me cuenta como si pasara el coche 2.
Si corren los dos, lio, aveces detecta bien a los dos coches, aveces detecta a los cos como si fueran el coche 2 y habeces sin pasar ninguno, cuenta como si pasara el coche 2.

Antes de nada, bucle tienes que hacer, si no ¿que va a hacer cuando acabe las instrucciones del main? :D si vas mal de tiempo (para hacer el proyecto), mira allí los botones de programación y de inicio por lo menos.

Lo que cuentas tiene toda la pinta de ser lo que te digo, los 500ms, imagina que pasa el coche 1, se activa la interrupción enciende el led y se espera medio segundo, en ese tiempo pasa el coche 2, pero no hace ni caso, por que está en la interrupción... hasta el bit estará aún activo, cuando acaban los 500ms, sale del retardo, el coche dos ya ha pasado y la pata está a 1, no se activa, cuando acaba la rutina, si el compilador la borra (y parece que si, o tendrías un bucle infinito) el coche dos ha pasado y no se ha enterado...

Lo mismo pasa si el primer coche que pasa es el 2, solo funcionará bien si los coches pasan con más de 500ms de diferencia o si da la casualidad de que, justo cuando lo mira, es cuando está a nivel bajo.


¿Has mirado lo del comparador?

¿Por separado todo-todo funciona bien, incluido el comparador? esto sería raro, ya que el problema de no borrar la interrupción también lo tienes cuando está ella sola, aunque como no tienes bucle principal (puedes ponerlo vacío) no sabemos si se reinicia el solo...

Revisa el correo...

[navegante 420]

ya esta visto y contestado

[Gerard-2]

mañana me lo miro un poco, pero una cosa son pulsadores manuales y otra los de paso de vehiculos con acionamientos y gestion mucho mas rapida.

Me gustaria saber que tiempo puede estar accionado un detector como minimo, tienes alguna idea? velocidad maxima (+/-) de los vehiculos y longitud real de acionamiento sobre el detector? hay que dar un toque de seriedad al tema, no? jaja eso permite evaluar el tiempo minimo de ciclo de la vuelta del programa por ejemplo y justificar el algoritmo escogido.

Por los comentarios de Aunolose, tendrias que activar la temp desde la int y liberar las interrupciones, pero la temp tiene que ir por otro lado, la int no puede esperar a que acabe la temp.
Cuando se acaba la temp puede llamar su propia int para ejecutar lo que sea, si el ciclo de main es rapido este podria hacerse cargo y no sobrecargar gratuitamente la gestion de int's---------parece un telegrama, no? jaja supongo que se entiende la idea, hablo a nivel abstracto por que no me quiero mojar con concreciones, que no controlo el pic y seria peor.

[navegante 420]

Pues si, la deteccion es otra cosa, Ayer tras varias pruebas, forzar la desabilitacion y habilitacion de las interrepciones, poner un delay para los rebotes, ponerle imanes a los coches mas bajo de lo normal para augmentar el campograbitatorio, para mejorar la captacion, poner un condensador de 200nf en paralelo al captador. Conseguimos, sobre todo con el concensador, que la captacion fuera como un clavo, con un coche, ha la que volvemos a poner los dos, mierda, si solo fuera al pasar por meta estaria claro que la respuesta no es lo suficientemente rapida, pero en ocasiones el coche uno me activa el paso 2 o sin pasar ninguno por meta, se me activa el paso 2.

Así que decidimos mirar hoy con un oscilo que es lo que pasa, y que señal hay. Así que esta tarde os lo digo.

Os dejo el codigo con el que estado trasteando ayer.

YA no hay delays largos, jejejejeje


#include <18F4550.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES INTRC_IO //Internal RC Osc, no CLKOUT
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOBROWNOUT //No brownout reset
#FUSES BORV20 //Brownout reset at 2.0V
#FUSES NOPUT //No Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES IESO //Internal External Switch Over mode enabled
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES PBADEN //PORTB pins are configured as analog input channels on RESET
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOCPB //No Boot Block code protection
#FUSES MCLR //Master Clear pin enabled
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES PLL12 //Divide By 12(48MHz oscillator input)
#FUSES CPUDIV4 //System Clock by 4
#FUSES USBDIV //USB clock source comes from PLL divide by 2
#FUSES VREGEN //USB voltage regulator enabled
#FUSES ICPRT //ICPRT enabled

#use delay(clock=8000000)
#use i2c(Master,Fast,sda=PIN_B0,scl=PIN_B2)
#use fast_io (A)
#use fast_io (B)
#use fast_io (C)
#use fast_io (D)



#int_RB
void RB_isr(void)
{
disable_interrupts(GLOBAL) ;
if(input(pin_B4)==0)
{
output_bit(PIN_d0,~input(pin_d0));
}
if(input(pin_B5)==0)
{
output_bit(PIN_d1,(~input(pin_d1)));
}
if(input(pin_B6)==0)
{
output_bit(PIN_d2,(~input(pin_d2)));
}
if(input(pin_B7)==0)
{
output_bit(PIN_d3,(~input(pin_d3)));
}
delay_ms(20);
enable_interrupts(GLOBAL);
}

/*#int_COMP
void COMP_isr(void)
{
if(C1OUT==1)output_high (pin_D4);
else output_low (pin_D4);
if(C2OUT==1)output_high (pin_D5);
else output_low (pin_D5);
}*/



void main()
{
set_tris_D (0b11000000);
set_tris_A (0b11111111);
set_tris_B (0b11111100);

setup_timer_0(RTCC_INTERNAL);
setup_timer_1(T1_INTERNAL|T1_DIV_BY_1);



//setup_vref(VREF_LOW|15);
//setup_comparator(A0_VR_A1_VR);

enable_interrupts(GLOBAL);
enable_interrupts(INT_RB);
//enable_interrupts(INT_COMP);

setup_oscillator(OSC_8MHZ|OSC_TIMER1|OSC_31250|OSC_PLL_OFF);
output_D(0);
// TODO: USER CODE!!
while(1);
}

[navegante 420]

Oscar mirate el correo dentro de spam, es posible que mi respuesta se te haya ido allí por el link que te he puesto, pues el que me mandastes tu ayer a las 20:46 se me ha metido en la carpeta de posible spam.

[navegante 420]

Joer con el puñetero comapardor......

Aun ha riesgo de parecerme a cierto entrenador de futbol...... PORQUE??????????????? no entiendo PORQUE??????????????????? Alguein me podria decir PORQUE?????????

Me explico. Ayer ademas de probar las interrupciones, cuando estamos espesos, nos pusimos el profe y yo a diseñar las funciones, y esta mañana por indicacion del profe, si, si oscar, el profe, ahora se acuerda de que tiene un alumno....., he montado un sencillo programa para el pic16f627, y mira tu por donde...... finciiona to, almenos en proteus.....

Os pongo el código.


/*
RB1 <- RX
RB2 -> TX
RB3 -> CCP1
RB4 <- BUTTON_ON
RB5 <- BUTTON_OFF
*/

#include <16f627a.h>

#fuses NOWDT,NOPROTECT,NOPUT
#fuses NOBROWNOUT,NOMCLR,NOLVP,INTRC_IO,NOCPD

#use delay (clock=4000000)
//#use fast_io(a)
//#use fast_io(b)

#use standard_io(a)
#use standard_io(b)


#use i2c(master,sda=pin_b1,scl=pin_b2)

int dec7[10]={0b0111111, //0
0b0000110, //1
0b1011011, //2
0b1001111, //3
0b1100110, //4
0b1101101, //5
0b1111101, //6
0b0100111, //7
0b1111111, //8
0b1101111}; //9

void saa1064_putc(int,int,int,int);
char buffer_car[5];
int vueltas_car1;
int vueltas_car2;

#INT_RB
int1 int_rb_rb4()
{
if(input(pin_b5)==0){
vueltas_car1++;
if(vueltas_car1==100) vueltas_car1=0;
sprintf(buffer_car,"%02u%02u",vueltas_car2,vueltas_car1);
saa1064_putc(buffer_car[0]-0x30,buffer_car[1]-0x30,buffer_car[2]-0x30,buffer_car[3]-0x30);

//if(input(pin_b5)==0){
output_high(pin_a3);
delay_ms(150);
output_low(pin_a3);
}
}

#INT_COMP
void int_comp_a0_a1()
{
if(c1out==1){
output_high(pin_a3);
delay_ms(1000);
output_low(pin_a3);
}
}

void main()
{
//set_tris_a(0b11110111);
//set_tris_b(0b11101100);

enable_interrupts(GLOBAL);
enable_interrupts(INT_RB);
enable_interrupts(INT_COMP);

setup_vref(VREF_HIGH|8);
setup_comparator(A0_VR_A1_VR);

output_low(pin_a3);
vueltas_car1=0;
vueltas_car1=0;

saa1064_putc(0,0,0,0);


//sleep();
while(1);
}

void saa1064_putc(int d4,int d3,int d2,int d1)
{
i2c_start();
i2c_write(0b01110000); //dirección
i2c_write(0x00);
i2c_write(0b1000001); //modo dinámico, sin parpadeo, 12mA

i2c_write(dec7[d1]);
i2c_write(dec7[d2]);
i2c_write(dec7[d3]);
i2c_write(dec7[d4]);

i2c_stop();
}

Si os fijais las lineas de configuracion son igules, entonces PORQUE???? este si hace lo que tiene que hacer y el 18 no?????

Lstima que este pic solo tenga 4k de memoria y la i2c se la tengamos que hacer por sofware, con lo que problablemente no tenga suficiente memoria, por que sino este finde tendria liquidado el gestor, y tendria una semana pal box.

P.D. Oscar visto que nuestros correos no pitan muy bien, nos vemos a las 18:30 en el chat?????

[Aunolose]

Bueno, leí esta mañana los otros mensajes y ahora este ultimo.

¿Cual es el compilador del Proteus? ¿es el CCS? eso es una diferencia importante. aparte, ya se sabe que en el simulador todo funciona y luego...

Ya tengo instalado el CCS 4 no se qué, a ver si así puedo comparar.
He mirado por encima y he visto una directiva noclear si es lo que pienso, es decir, que no borre la interrupción, es que las borra él solo, pero por si acaso, echo en falta la instrucción que borra la interrupción en el comparador, sería algo así:



#INT_COMP
void int_comp_a0_a1()
{
.....if(c1out==1)
.....{
........output_high(pin_a3);
........delay_ms(1000); // esto es 1 segundo, en este tiempo,
.........................// como pase un coche por el detector,
.........................// no le hará ni caso.
........output_low(pin_a3);
.....}
.....clear_interrupt(INT_COMP); //esta es nueva, por si acaso
}

lo mismo se puede hacer con RB.

También has puesto en la referencia 8 y en el otro 15.


Me llaman, luego vuelvo...

[navegante 420]

Pues no oscar, creo que el tema esta en el hard, o en la configuracion incorrecta. el esquema lo tienes arriba.

Te cuento lo que me pasa, poniendo el tester sobre las resistencia del coche1, si el coche 1 circula en el tester tengo la tension, Si el coche 1 no circula pero si lo hace el 2 el tester me hace una lectura de 4,85 a 5,65 v, de donde viene este voltaje??????

[Aunolose]

Un momento...

Los círculos que hay encima de los detectores ¿son los motores?, pues ahí hay algo raro, por un lado conectas el positivo de la batería a una pata del PIC (en el de la derecha) y por otro conectas el negativo (masa, en el de la derecha)

¿Esto lo dices por que en el proteus funciona?... ya sabes lo que opino de los simuladores... aparte, en el proteus no hay problemas de tensiones ni nada de eso.

Ya sabes donde estoy, por si te pasas...

[navegante 420]

aqui una imagen que vale mas que mil palabras.
46746

[navegante 420]

no en proteus no puedo simular los comparadores internos, sopena no carges la libreria del 6.

Haber el esquema me he ahorrado un par de cosas, como la resistencia variable que hay en el mando que transfiere la tension al motor, jejeje

que yo vea ambas estan sacadas del positivo, o almenos en la realidad ambas son positivas.

en el código, ya esta puesta tu última recomendación, pero creo que el tema del comparador esta en solucionar este reflujo.

[Aunolose]

Ahora si, pero en el esquema anterior no... por cierto, le pondría un zener de 5V1 de la pata del PIC a masa, los 5.36 son por que está actuando el diodo de protección del PIC...

Lo que pones que pasa se parece más a un fallo del PIC que del circuito... ¿como si no llegan los 5V a la pata del PIC? (suponiendo que el cableado real sea como el esquema que pones)

[Aunolose]

¿te pasas por el chat, o no puedes?

[navegante 420]

estoy alli, en 1c1, no????

[navegante 420]

Aqui el esquema con los zeners.

46749

[Aunolose]

Así es como debe ir.

[navegante 420]

pues entonces ya es tema de soft, porque no va, como bien dices ahora esta bien protegido, ya no tengo el reflujo raro de antes, cuando uno corre el otro es 0 en todos los puntos.

[Aunolose]

Aaaaahora caigo, tal y como lo tenías antes, no tenías referencia a negativo, es decir, la pata, o estaba al aire (un uno, o ruido) o estaba a positivo a través del d1 y d2, ahora al poner el zener no solo lo has protegido si no que le has metido una tensión negativa (bueno, 0V) cuando no hay tensión. no es una buena referencia, pero debe funcionar, ahora te sobran D1 y D2, el zener también se come los picos negativos, si los hubiera, y tendrías mejor la referencia (0V) a través del motor.

[Aunolose]

Pero el problema del software creo que sigue estando, por lo menos en el comparador... ¿no?

PD: vuelve al chat...

[Gerard-2]

Lo siento, reedito-- lo tenia abierto desde hace rato y me habia tirado del server, me he perdido las ultimas entredas
---------------------------
Navegante,

ya te han comentado lo de las entradas del comp sobre RA...lo mismo para los circulos y la BAT1

El valor de las R de pull-up es un poco alto,no? eso puede hacer que sean demasiado sensibles frente a interferencias...si el cableado esta bien probaria 10K con 100nF, da una tau sobradamente rapida, si el cableado es largo hay que apantallar el cable y mejor poner condensadores tambien en las entradas de la pcb, pero que vayan a una "buena masa corta"
--------------
Entiendo que pasas de las resistencias internas de pull-up de RB del 18F por tanto no activas RBPU, correcto?
-------------
Tienes un condensador de desacoplo entre las patas de alimentacion del micro?, imprescindible que sea lo mas proximo posible al chip y es obligatorio que esté puesto !!!
-------------
La fuente que alimenta el chip es la misma que alimenta los motores de los coches ?, tienen la masa comun? ....de los +12V sacas +5V con un 7805 o parecido?

No se corresponden los pines definidos para i2c, pero no es el problema.
O si?, I2C usa int's? espera el ack y no llega? no se....

[navegante 420]

sep, estoy en el chat

[Aunolose]

me pone que no :scratch:

[Aunolose]

¿donde andáis los dos?

[navegante 420]

Lo siento, reedito-- lo tenia abierto desde hace rato y me habia tirado del server, me he perdido las ultimas entredas
---------------------------
Navegante,

ya te han comentado lo de las entradas del comp sobre RA...lo mismo para los circulos y la BAT1

El valor de las R de pull-up es un poco alto,no? eso puede hacer que sean demasiado sensibles frente a interferencias...si el cableado esta bien probaria 10K con 100nF, da una tau sobradamente rapida, si el cableado es largo hay que apantallar el cable y mejor poner condensadores tambien en las entradas de la pcb, pero que vayan a una "buena masa corta"
--------------
Entiendo que pasas de las resistencias internas de pull-up de RB del 18F por tanto no activas RBPU, correcto?

Ahora miro esto del cable y las resistencias.
-------------

un condensador de desacoplo entre las patas de alimentacion del micro?, imprescindible que sea lo mas proximo posible al chip y es obligatorio que esté puesto !!!

Ok que valor le pongo?????
-------------

fuente que alimenta el chip es la misma que alimenta los motores de los coches ?, tienen la masa comun? ....de los +12V sacas +5V con un 7805 o parecido?

Los coches usan su fuente y el pic otra, pues inytente aprovechar la de los coches y el pic se volvia loco, asi que muerto el perro, muerta la rabia, la masa es comun.


se corresponden los pines definidos para i2c, pero no es el problema.
O si?, I2C usa int's? espera el ack y no llega? no se....

por lo que he leido ACK.

[Gerard-2]

Con la tension en la ventana de 5V a 0V no va a hacer nada, presenta muy alta impedancia y representa que no esta conectado.

Si lo que queremos es tener una tension proporcional a los 14V escalada a 5V, entonces lo que hay que poner es un divisor de tension con resistencias.

En plan simple hacemos un divisor 3:1, es decir 15V/5V, lo mas facil es coger tres resistencia iguales por ejemplo 4k7 o 3k3 y conectarlas en serie, entre los 15V (14) y masa, la segunda pata de la R conectada a masa tiene Xv/3, o sea si la entrada a la serie oscila entre 0 y 15V sobre la primera R oscilara entre 0V y 5V

En el segundo nodo no se utiliza, no olvidar los condensadores.

En plan fino se pone un R de ajuste multivuelta cermet y se calibra sobre esa proporcion al gusto.

[Gerard-2]

ya se me hace tarde, el ack es el Acknowledgement, es el bit de respuesta que espera el master del slave del I2C para saber que esta alli y le esta haciendo caso. eso lo hace a cada final de byte que le envia.

Si no le responde por que las lineas estan equivocadas de scl y sda anem malament, pero no se si solo es error de proteus o de hard real.

[Gerard-2]

insisto, con int's es imprescindible que las señales sean limpias, con els osc no veras picos esporadicos que te volveran loco,
es imprescindible el condensador de desacoplo sobre el chip, las masa comunes pueden dar problemas, per es complicado medir V de forma optoacoplada, las masas de los condensadores de desacoplo de las entradas tienen que ser cortas respecto a la pata negativa del chip y de su condensador, las otras patas tambien, claro.

[Aunolose]

Toma, me había saltado el mensaje gordo de Gerard

Gerard, si no recuerdo mal, lo que quiere medir es el momento en que arranca el coche, en ese momento tal y como está hecho el sistema del excalectric la tensión en el motor cae un poco y creo que es lo que quiere medir, entonces no hace falta el divisor, salvo que la tensión de arranque esté por encima de 5V o tenga una tabla con la tensión de arranque de cada motor.

Si falla el ACK del I2C, el problema está en el otro PIC...

[navegante 420]

Bueno el pick no esta jodio, acabos de probar con uno virgen y tampoco anda.

[navegante 420]

Sorry, creo que os he liado, la i2c anda, ahora mismo solo me queda por configuara el comparador analógico, para poder dar por liquidado, el gestor, y tener algo para presentar.

[Aunolose]

A ver si nos centramos
Creo que aún no has contestado a la pregunta principal:

El hardware por separado ¿funciona? quiero decir, el I2C, solo él, ¿funciona? el comparador solo él ¿funciona? y así, asegurate que funcionan uno a uno y después los juntas, si no lo haces así corres el riesgo de confundir un problema hard con uno soft.

Como pones los esquemas así, sin oscilador, sin masas conectadas, no sabemos si pones condensadores de desacoplo, etc, pero si no lo haces, haz caso de Gerard. 10k para las resistencias de pull up, 100nF multicapa para los condensadores de desacoplo son un compromiso bueno.

[Aunolose]

Vale, se ha colado el mensaje anterior mientras escribía, entonces ¿solo falta eso? ¿el comparador?

¿has probado a comentar todo lo demás e intentarlo solo con el comparador? con el hard que toque.

[navegante 420]

El tema esta que cuando me funciono, vino el que que teoricamente es mi compi, al cual no veo hace una semana y me la lio, y entre el cansancio que acumule, el estres ya no me acuerdo de que configuración, y que esquemas hice.

condensadores de desacoplo no tengi ni uno, solo el que te comente que he puesto al cuentavuentas.

entonces al seguidor de tension tambien le pongo un condensador?????? de que valor??????

y al pic tambien???? de que valor????

[Aunolose]

A ver, entre positivo y negativo uno multicapa o cerámico de 100nF, en las patas de los pulsadores, las resistencias de 10k, y si tienes problemas con los rebotes, en paralelo con el pulsador, otro condensador de entre 10 y 100nF, cuanto menos mejor, pues lo notan los contactos del pulsador.

Un detalle, ¿lo haces con el oscilador interno? si lo haces con un cristal externo, ponle también condensadores a masa en cada pata del cristal, de 15pF los pongo yo, para 20Mhz.

Los condensadores lo más cercanos posible al chip, sobre todo el de alimentación.

En el I2C ningún condensador, o te cargas las señales.

Esto que me acuerde...

[Aunolose]

¿estas probando en una placa board? también suelen dar problemas cuando tienen un tiempo...

[navegante 420]

Ahora estoy en protoboard, y tiene poco uso, con lo que podemos decir que esta nuevecita.

ok marchando tres condensadores de 100 nF

en el seguidor de tension del comparador no pongo na mas, verdad?????


Pd. y el chat que paso?????? jejejeje

[Aunolose]

¿para que se usa el comparador? si se usa para detectar la tensión de arranque, no servirá de mucho, incluso molestará, pero en el detector de paso si puede ayudar.

¿por que pasas del chat? es que por aquí es un poco lento-lio. ¿no?

[Aunolose]

gerard, que encontré una ventana de chat por ahí suelta...

Los zener ideales polarizados al revés son un circuito abierto, pero los de verdad no, tienen mucha impedancia, pero sirven para "mandar a masa" (y dar un cero) la entrada del PIC, por eso pueden arreglar algunos problemas ocultos, aunque esto me hace pensar que con el divisor que comentas ese problema también se soluciona (por si acaso, mantendría los zener)

[Gerard-2]

ya he vuelto, son casi la 1h jejej, el reloj sale mal.

A ver si nos aclara para que sirve el comparador analogico, tampoco se si es que hay prevision de hacer mas cosas mas adelante.....es que no lo pillo.

Los zeners polarizados por debajo de la tension zener trabajando como pull-down? bufff no me fiaria nada de nada, sobre una int de hard ? y sin ser entradas trigger? ummm, yo no usaria un pulldown de mas de 2k2 o 3k3 en una linea que va a quedar al aire con cables largos, motores de escobillas, escobllas de los coches sobre pistas radiando como locas...que miedo :)

Segun lo que se persiga , si se pudiera optoacoplar con separacion de masas seria ideal, ya nos explicará que busca, pero si no, el zener es casi obligado.

Placa protoboard? jaja haber empezado por aqui... :) si es lo que hay, que se le va a hacer.
______________________________________________
Simulador? el otro dia, un multisim me llama la atencion, es que me gritaba al pasaaaar, un decoder 7segmentos anodo comun 7447 sobre un display Catodo comun con el K a una bateria del reves !!! y funcionaba correctamente *** es decir, los tr de salida, open colector npn conduciendo del reves con el Emisor a la masa interna del 74 y la salida, Col. a tension negativa a traves de los segmentos del display---oleeeee
________________________________________________

Del chat, es que no habia entrado nunca, solo me ha aceptado a aunolose pero no he visto respuesta, se me ha hecho tarde y he cerrado.

Respecto al soft, pàso a paso, rutina a rutina, eso lo tengo tambien muy claro, incluso soy un poc exagerado en los detalles.

[Aunolose]

Gerard, los zener no se deben usar como pull down por lo que dices, pero el error que tenía, de darle 5V aún sin conectar, era debido a que no había pull down, al poner los zener, estos lo hacen, estamos hablando de que todavía no está el motor en marcha, no hay ruido, y así la entrada se pone a cero, de mala manera, pero lo detecta como cero, y averigua un fallo que se le había escapado, ahora que lo sabe puede poner el divisor resistivo y lo que haga falta.

Los optoacopladores, y precisamente para aplicaciones lineales, no son "llegar y besar el santo", a estas alturas de proyecto, no sé si le dará tiempo.

Los ruidos de escobillas se pueden quitar con algún condensador pequeño, no puede ser muy grande para que la interrupción se produzca cuando toca y no "un rato después".

navegante, una duda que tengo (estoy en casa y aquí no tengo el CCS) ¿se pueden usar las dos entradas como comparadores independientes? luego lo miraré, que ahora me reclaman...

[Gerard-2]

de acuerdo, si, los optos en lineal es complicado.

He mirado en la seccion de 18F donde el comparador analogico y pone que hay DOS comparadores, sus entradas se pueden seleccionar entre RA0 hasta 5 y que las salidas normal o invertida son accesibles exteriormente.

Tambien aparece un modulo detector de alto/voltage. Permite al usuario definir un umbral y direccion de flanco para activar una INT. No se si es de aplicacion en este proyecto.

Segun el libro de CCS+proteus pag 239 !!! advierte que "hay un error de asignacion en el fichero de cabezera del 18F4520.h (solo en este?) al usar la funcion setup_comparator(), sugieren asignar directamente el valor que corresponda al byte de config CMCON, Lo apunto para verificar....

[navegante 420]

Que edicion tienes?????? yo en la 239 tengo el bootloader?????

El comaprador lo uso con un valor de ref interno que le asigno, sin zener los coches arrancan a 3, 22V con el zener lo estoy acabando de ajustar, pero rondan los 2,49V con lo que comparando los dos valores de la pista con este valor de ref. se si el coche esta corriendo o parado, durante el procedimento de salida controlo si el coche se sale antes de tiempo, durante la carrera controlo si hace la penalización, o si se ha salido de pista.

Entonce si el fallo esta en el archivo cabezera como lo arreglo?????, que hago??? donde has encontrodado esa info?????


Y ya puestos, no viviras muy lejos de la plaza de toros de Tarragona?????

[navegante 420]

Este es el esquema que mne interesa.
46775

YA vi lo del registro cmcon, Asi pues si sustituyo la directriz setup_comparador() por:

_asm
movlw 0xa5
movwf cmcon,0
_endasm

por ejemplo????, el valor lo he puesto a voleo.

las interupciones como has visto me interesa en los dos sentidos. Como y ahora me lo miro todo bien,


Que contento empiezo ha estar..... al final, gracias a vosotros, sin duda alguna, y tendreis vuestra mencion el dia de la presentación, voy a conseguir que funcione. Muchisimas gracias. Os podeis imaginar lo agradecedido que estoy....



Bueno gerarad, que sepas que te grabo ese primer pic cuando quieras, y que las cervezas las pago yo, jejejejeje

[navegante 420]

Segun el libro de CCS+proteus pag 239 !!! advierte que "hay un error de asignacion en el fichero de cabezera del 18F4520.h (solo en este?) al usar la funcion setup_comparator(), sugieren asignar directamente el valor que corresponda al byte de config CMCON, Lo apunto para verificar....

Ya esta, Pag, 268 en la 2º edicion.... No se puede ir tan de culo, teniendo la solucion delante de mis narices, y tengo a dos personas perdiendo el tiempo abriendome los ojos.

Os pido disculpas.


Y el codigo es el siguiente:

#byte CMCON 0xFB4

CMCON= 0b00000110;

Supongo que cmcon esta en la misma direccion en el 18f4550 que en el 18f4520.



Por cierto advierte que en proteus no simula el comparador en el 18 y te digo que en el 16 tampoco. para hacer la prueba con el 16f627 tube que cargar la libreria del proteus 6 para que funcionara....

Lastima que el en 6 faltan un monton de pics, por ejemplo el que estoy usando.

[navegante 420]

Si es la misma dirección, pg 68 de data tabla 5.1

Monto programa y os cuento.

[navegante 420]

pues no ha habido suerte. este es el codigo que estoy usando.


#include <18F4550.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES INTRC_IO //Internal RC Osc, no CLKOUT
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOBROWNOUT //No brownout reset
#FUSES BORV20 //Brownout reset at 2.0V
#FUSES NOPUT //No Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES IESO //Internal External Switch Over mode enabled
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES PBADEN //PORTB pins are configured as analog input channels on RESET
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOCPB //No Boot Block code protection
#FUSES MCLR //Master Clear pin enabled
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES PLL12 //Divide By 12(48MHz oscillator input)
#FUSES CPUDIV4 //System Clock by 4
#FUSES USBDIV //USB clock source comes from PLL divide by 2
#FUSES VREGEN //USB voltage regulator enabled
#FUSES ICPRT //ICPRT enabled

#use delay(clock=8000000)
#use i2c(Master,Fast,sda=PIN_B0,scl=PIN_B2)
#use fast_io (A)
#use fast_io (B)
#use fast_io (C)
#use fast_io (D)
#byte CMCON=0xFB4

#int_COMP
void COMP_isr(void)
{
if(C1OUT==1)output_high (pin_D4);
else output_low (pin_D4);
if(C2OUT==1)output_high (pin_D5);
else output_low (pin_D5);
clear_interrupt(INT_COMP);
}



void main()
{
set_tris_D (0b11000000);
set_tris_A (0b11111111);
set_tris_B (0b11111100);

setup_timer_0(RTCC_INTERNAL);
setup_timer_1(T1_INTERNAL|T1_DIV_BY_1);

enable_interrupts(GLOBAL);
//enable_interrupts(INT_RB);
enable_interrupts(INT_COMP);
setup_vref(VREF_LOW|5|VREF_F5);
CMCON=0b00000110;


setup_oscillator(OSC_8MHZ|OSC_TIMER1|OSC_31250|OSC_PLL_OFF);
output_D(0);

veias algo raro, o alguna cagada mia?????

[navegante 420]

Señores, no pierdan mas el tiempo conmigo, enserio, no lo merezco.......

se acuerdan de este trozo de codigo:

if(C1OUT==1)output_high (pin_D4);
else output_low (pin_D4);
if(C2OUT==1)output_high (pin_D5);
else output_low (pin_D5);

Y saben que el puerto d en este pic no es correlativo, verdad??????

d0 en la 19
d1 en la 20
d2 en la 21
d3 en la 22
pero d4 no esta en la 23
ni de d5 en la 24.....


Asi podia yo esperar que se encendiaran......

os estareis partiendo el culo de mi, pero si os digo que llevo parte de la tarde cambiado cables, resistencias, leds, comprobando continuidades y na. deios que vergüenza :oops::oops::oops: y al final ha sido porque harto de que no se encieran he dicho por mis guews que se encienden,

While (1)
output_high (pin_d4);
output_high (pin_d5);

y claro al no encenderse, me he dicho, algo pasa, y he caido en mio error:banghead::banghead::banghead:

Ahora solo por gusto se van a tirar to la noche encendidos :D

Ahora ha probar el bloque completo, y montarle el programa. programar Timer O y Timer 3 y gestor listo, con un poco de suerte el martes empiezo con el box.

Pic esclavo, dependiente del gestor.
4 interupciones, 2 lcd, y bootloader, y por lo menos llevaremos unos minimos del proyecto para el concurso.

[Gerard-2]

Tranquilo que eso nos ha pasado a todos 15 veces. Hay cosas que solo se ven despues de dejarlas por que incluso nos engaña la vista! para empezar las imagenes se ven dentro del ojo del reves :) y las celulas de la retina sensibles a la luz son los bastones, quien le puso este nombre era un cachondo, los vería blancos?

Ayer me estube peleando buscando un proteus +|- actual y al final consegui el 7.7 medicarlo etc,al final funcionó, espero que bien pero eso ya se verá.

Mas complicado fue lo del ccs, tambien lo mas actual posible, por aquello de los errores, v4.107, tambien veremos como, y vaya follon para que se tome la pildora en win7, aqui no quiero... no es un dir valido... aqui no te dejo :bounce:...al final pinta bien. He configurado proteus para que enlace con ccs...poco a poco.

:banghead: Luego he visto el enlace al proteus que ya tenias puesto por aqui :) , eso me pasa por no mirar ! pero hay que tener cuenta en taringa, o no te deja entrar en esa pagina.

Lo del plugin al mplab ya veremos, supongo que lo necesito si compilo y debugo con el C de microchip, no quiero cerrarme ninguna puerta a pesar del riesgo de pillar un catarro por la corriente de aire, y acabar no concretando en nada.

Siento no poder ayudarte con todas las configs del pic, osc, timers y toda la montaña de flags me va grande, voy mirando.
_____

Por las cervezas no será :) , y no vivo por ese lado, mas bien en el contrario, donde el nastic (cuando eras muy pequeño jaja), pero que Tarragona a pie es pequeña.

A ver si puedo verificar los detalles de tu prog, pero tengo un pc con millones de fotos familiares y he de clonar el win a otro disco mas grande, QUE MIEDO!

Voy a pedir consejo de disco nas con dlna al foro informatico jeje a ver que me dicen.

[Aunolose]

jejeje, pozi, eso pasa, y por si te sirve de consuelo, no será la ultima vez :D

Un fallo por adelantado, lo que en otros PIC es RC2 (¿?, la pata 14), en el 2550 es vusb, y si no pones un condensador de entre 220nF y 470nF el USB no funciona... tal vez Gerard tenga ganas de averiguar porque, yo cuando me cansé de buscar el motivo, lo puse como un acto de fe y a rodar... :dontknow: a lo mejor es que la función de ese pin está mal explicada, o que mi ingles no es lo suficientemente bueno para entenderlo :(


Al grano, tanta directiva me pone un poco nervioso... creo que quitaría todas las que no voy a gastar, por ejemplo ¿que eso de el timer1 y el low power? pero ojo, también te digo que si te funciona lo otro, no las cambies, salvo que alguna afecte al comparador, aunque sospecho que tienes algún problema hard...

Ya no sé si fue aquí o en el chat donde puse lo de la resistencia de 100k para pobrar si llegan los 12V al lugar correcto, el PIC lo pones después, junto con el zener, puedes dejar la resistencia de 100k, para fijar un poco el cero cuando no hay coche, incluso ponerla más baja (menos ruido) pero entonces calcula el divisor, que 100k es 50 veces más grande de 2k2, pero 10k solo son 5 veces. no sé si me explico.

Cuando pruebes una parte y funcione, no la desmontes, solamente comentas la parte de software correspondiente y pasas a la siguiente parte, cuando funcionen las tres por separado, juntas dos y te pegas para que funcione, es poco provable que tengas que cambiar el hard si funciona por separado. Haciendo esto te aseguras que el hard está bien y puedes pasar al soft, que es más pijotero.

¿En el CCS no se puede ver el código desensamblado? aunque intento no tocar el ensamblador, en el MMC18 tengo/tenemos detectados algunos fallos en las librerías, o fallos o que no sabemos llamarlas como esperan, entonces nos vamos al código ensamblador, vemos lo que hace, vemos si coincide con lo que esperamos que haga y si no lo hace, nos construimos nosotros una, copiando lo bueno de la otra si hace falta.

[Gerard-2]

Segun los fuses, podemos utilizar la fuente interna u otra externa, en ese caso no hara falta el condensador. Supongo que el condensador hace falta si se usa la fuente interna de 3,3V que la dejan mal filtrada. Es la alimentacion del transceiver y tambien referencia para las R de pullup que definen el modo de trabajo de la com del Usb.

Vusb es la patilla 18 para el 4550

The PIC18FX455/X550 devices have a built-in 3.3V regulator
to provide power to the internal transceiver and
provide a source for the internal/external pull-ups. An
external 220 nF (±20%) capacitor is required for stability.
The regulator is enabled by default and can be disabled
through the VREGEN Configuration bit. When enabled,
the voltage is visible on pin VUSB. When the regulator
is disabled, a 3.3V source must be provided through
the VUSB pin for the internal transceiver. If the internal
transceiver is disabled, VUSB is not used.

[Gerard-2]

Al ser un simple filtro por descontado que a partir de 220nF funciona bien , mucha gente usa 470nF para curarse en salud, hasta varios microFs. Yo no lo pondria, durante la desconexion nos podemos encontrar que se descargue antes la Vcc que la Vusb por exceso de capacidad, polarizando de forma inversa algun transistor interno del chip. Los problemas llegan solos....no hay que buscarlos.

[Gerard-2]

Miraba donde esta el bit CIS, estoy con la config del COMP, es un pequeño lio.

ya lo tengo, jaja, es que escribo sobre la marcha

[Gerard-2]

espero que tengas la referencia de tension bien configurada, vaya lio, lo mismo que los osciladores del pic, de los timers ya se ha comentado.

[navegante 420]

Si el osacilador de momento es el interno, no me he complicado.

Osacar esto el bootloader que usas tu Bootloader USB para PIC18F4550 a full. (http://www.todopic.com.ar/foros/index.php?topic=23135.0) o usas el wizard del ccs????? Esque yo he probado el wizar del ccs y me dice que active configuracion de rs232, pero si lo quiero por usb????

En cuanto a comunicacion i2c ya encontre algo.

me fata el manejo de lcd.

Joer que agobio, esto de andar a ciegas, siendo la primera vez que programos estas cosas y encima contrareloj.......

Gane algo o no, voy a pillarme una cogorza el dia 25.....

[Aunolose]

Al ser un simple filtro por descontado que a partir de 220nF funciona bien , mucha gente usa 470nF para curarse en salud, hasta varios microFs. Yo no lo pondria, durante la desconexion nos podemos encontrar que se descargue antes la Vcc que la Vusb por exceso de capacidad, polarizando de forma inversa algun transistor interno del chip. Los problemas llegan solos....no hay que buscarlos.


Pues si no lo pones, te aseguro que no funciona, o funciona de vez en cuando, lo dicho, al final, acto de fe y a ponerlo (yo soy de los de, si tengo, 470nf)



Navegante, si, el bootloader que tengo yo es un derivado de ese, convenientemente modificado (aunque no mucho) para que pueda trabajar directamente en las placas en las que lo pongo, ten en cuenta que a veces tardamos en programarlo, durante ese tiempo las salidas deben estar configuradas correctamente, o te puedes cargar algo, si controlan un puente en H que controla un motor (no sé si viste un vídeo que puse hace tiempo de un "helicoptero") por ejemplo, debes ponerlo todo "apagado" o puedes hacer un corto.

Bueno, que me enrollo, si, es ese, por cierto que el programa del PC también lo modifiqué... (está escrito en C++ Builder, "una pasada", "C tipo delphi") para quitar la parte de demo y que no se queje cuando le pones un cristal que no es el suyo.




Una cosa que se me ocurrió del comparador, ¿a qué tensión interna tienes el comparador? lo pregunto por lo que dices de que en la pata te daba 2,65V, ¿es esa la tensión o parecida?
A ver lo que opináis, en un operacional (y un comparador es eso "potenciado" ¿no?) las dos patas de entrada "deben tener" siempre la misma tensión, internamente lo intentará por lo menos, quizá por eso te salga esa tensión, y si intentas que suba demasiado, quizá tengas un problema (te lo cargues) no lo creo, no me suena haber roto ninguno por eso, pero bueno, puede ser eso que te cuento, lo puedes comprobar si ves que tanto si subes como si bajas la tensión, la pata no sube ni baja mucho (esto con una resistencia de pull down)

Por cierto que entendí que eso del LCD y el I2C ya te funcionaba... ¿el SAA ese no lo controlabas ya?

Del LCD hay montones de librerías, seguro que en el CCS también, úsalas.

[Aunolose]

Ah, que se me olvida, para hacer fácil la comunicación a través de USB lo que hacen muchos proyectos es emular un puerto serie, así puedes controlarlo con cualquier programa que pueda controlar el puerto serie, que suelen ser todos los lenguajes de programación. ¿tiene que ver con lo que dices?
El bootloader del CCS debe hacer algo parecido, y utiliza el SIOW para programarlo, una opción que se llama "Download Software" y creo que tienes un tiempo para hacerlo, esto lo recuerdo del PIC16F875 y demás, ya hace que no trabajo con él.

[Gerard-2]

Yo no lo pondria jaja

hasta varios microFs. Yo no lo pondria, durante la desconexion nos podemos encontrar que se descargue antes la Vcc que la Vusb por exceso de capacidad no pondria esa capacidad exagerada porque tal y tal....

[navegante 420]

Pues no me entendistes bien, jejejeje

Gestor de carreras es lo que hemos hecho hasta ahora,
Cominicacion i2c para manejar los saa
comparador
interrupciones de rb
todo esto ok
lo que me falta por hacer, es lo que es mi cruz, el puñetero c, pero con buenos diagramas de fujos, creo que me saldré.

Ahora para el box, que es lo que me falta hacer, y que no tengo ni idea, pues nunca he hecho nada, es el bootloader, control de moteres paso a paso, y manejo de dos lcd para mostrar info. y lo que mas complicado es la i2c entre pic, que no tengo ni idea.

[Gerard-2]

aclaracion de los anteriores comentarios, si la nota de aplicacion dice 220nF, se ponen, si se entiende el por que, mejor, y si la gente dice que alguien tiene problemas pero que poniendo 470nF nadie se queja, pues con 470nF, microF es lo que no pondria.
____________________________

Si el ampli no trabaja en la zona de amplificacion lineal, no se puede asegurar que esten al mismo nivel, y en este caso ademas es que el circuito que nos pintas parece bastante simbolico, vete a saber. Lo que es seguro es que hay que revisar el hard por que tambien me extraña lo que explica de las tensiones.

Preferiria hacer pruebas simples paso a paso de este modulo COMP+Vref, seguro que poco a poco se llega a la cima.

De entrada, en el manual que tengo de microchip, en la pag 279, se ve como la Vref sale por RA2, eso no se si es incompatible con el modo 6 del COMP (dos comparadores con 4 entradas multiplexadas), ya he comentado lo de la config de la Vref, mejor probar y verificar si se puede acceder a ella por RA2 (previa config) directamente con un voltimetro, imagino que con el proteus tambien se tendria que poder verificar virtualmente.

Para que no se me olvide, hay que configurar las entradas del COMP como analogicas, supongo que ya se hace.

[Gerard-2]

...ni idea, pues nunca he hecho nada, es el bootloader,... no lo entiendo :(, pero no lo tienes ya? y si no como programas ese pic? o es un bootloader para algo especial, acaso cargar algun parametro concreto de la carrera...
___________________________

control de motores paso a paso, mas :(, que motores? para que sirven? esto es un mundo...simplificando se trata de guardar en una matriz (array) las combinaciones de las salidas de cada paso, despues por medio de un puntero se van sacando secuencialmente controlando la cantidad de pasos que sera el giro angular conseguido por el eje...mas o menossss-------estoooo, no sera control pwm de los motores? (ya no borro la explicacion anteior que ha quedado muy chula :) jaja
___________________________

MAnejo de 2 LCD con la misma info? no, lo sabia ! para eso tienen el Enable no? hay dos modos a 4 y a 8 bits mas alguno de control, habrá librerias espero
____________________________

I²C entre dos pics jajaja es que me da la risa, joer con el proyecto!
Lo que yo se, el protocolo es (puede ser) multimaster, oleeeee, supongo que hay verificacion de colisiones etc, en todo caso si se puede programar que haya un unico master supongo que sera mas facil.
Significado: el master es el unico que puede solicitar dialogo al slave, es el unico que toma la iniciativa, los slaves responden a la solicitud del master.
Es otro mundo con sus 'bibliotecas' . A cada byte del master el esclavo direccionado devuelve un bit de reconocimiento llamado ACK (ya ha salido antes), eso evita que el master hable ' con las paredes' como les suele pasar a los profes muchas veces :), vigilar que el master no se quede colgado ante la falta de respuesta de un slave, esperando el dichoso bit ACK.
Por cierto, que se tienen que 'explicar' los dos pic?
[Otro detalle, el I²C no es el bus mas recomendado para sacarlo a pasear fuera de la pcb, ya se entiende que las condiciones no las pones tu]
Añado: que no se desconfigure lo del SAA1064, que esto ya iba,no?,

[Aunolose]

Si controlas el SAA con el I2C es que el maestro ya lo tienes, el problema entonces es el esclavo.

Los motores paso a paso es otro cantar... de los problemas que planteas a mi me parece el más complicado, por lo menos hasta entender las señales que tienes que generar, ya te digo, si eso lo tienes claro, lo demás coser y cantar :D

¿tienes ya los drivers para los paso a paso?

De todas maneras esto no será para el viernes ¿no?... centrémonos en lo del viernes...

[navegante 420]

aclaracion de los anteriores comentarios, si la nota de aplicacion dice 220nF, se ponen, si se entiende el por que, mejor, y si la gente dice que alguien tiene problemas pero que poniendo 470nF nadie se queja, pues con 470nF, microF es lo que no pondria.
____________________________



Bueno poneos deacuerdo, que me estais volviendo loco con tanto cambio de condensador, jejejejejeje que asta el profe ya me ha dado la llave del cuartillo, jejejejeje.

[navegante 420]

Si controlas el SAA con el I2C es que el maestro ya lo tienes, el problema entonces es el esclavo.

Los motores paso a paso es otro cantar... de los problemas que planteas a mi me parece el más complicado, por lo menos hasta entender las señales que tienes que generar, ya te digo, si eso lo tienes claro, lo demás coser y cantar :D

¿tienes ya los drivers para los paso a paso?

De todas maneras esto no será para el viernes ¿no?... centrémonos en lo del viernes...

Pues si es pal viernes, jejejeje ya se que me espera una semana de insomnio, ademas finalmente acabo de mandar a la mierda al impresentable que decia hacer el proyecto conmigo.

[Aunolose]

Otia... :(

Los condensadores (el condensador) de que hablamos son solo para funcionamiento del USB, si no lo usas, ni caso.


Pufff, me has desarmado, ¿a que le das prioridad? lo de los paso a paso para el viernes no lo veo, pero te puedo pasar el código que tengo del tema, un poco liado y simple (nada de tablas) por que lo estoy cambiando, pero bueno, algo hará...

[navegante 420]

no lo entiendo :(, pero no lo tienes ya? y si no como programas ese pic? o es un bootloader para algo especial, acaso cargar algun parametro concreto de la carrera...

de momento lo estoy haciendo a base de quemador, por eso mi duda, no se como tiene que ser la estructura del programa en CCS. Ya que usando el wizard me doce que tengo que activar el rs232.


, mas :(, que motores? para que sirven? esto es un mundo...simplificando se trata de guardar en una matriz (array) las combinaciones de las salidas de cada paso, despues por medio de un puntero se van sacando secuencialmente controlando la cantidad de pasos que sera el giro angular conseguido por el eje...mas o menossss-------estoooo, no sera control pwm de los motores? (ya no borro la explicacion anteior que ha quedado muy chula :) jaja

jejeje, se trata simplemente de accionar el cambio de pista, aunque dado tanta complicación estoy pensando de hacerlo con un rele bobinado.



con la misma info? no, lo sabia ! para eso tienen el Enable no? hay dos modos a 4 y a 8 bits mas alguno de control, habrá librerias espero
____________________________
jajaja es que me da la risa, joer con el proyecto!
Lo que yo se, el protocolo es (puede ser) multimaster, oleeeee, supongo que hay verificacion de colisiones etc, en todo caso si se puede programar que haya un unico master supongo que sera mas facil.
Significado: el master es el unico que puede solicitar dialogo al slave, es el unico que toma la iniciativa, los slaves responden a la solicitud del master.
Es otro mundo con sus 'bibliotecas' . A cada byte del master el esclavo direccionado devuelve un bit de reconocimiento llamado ACK (ya ha salido antes), eso evita que el master hable ' con las paredes' como les suele pasar a los profes muchas veces :), vigilar que el master no se quede colgado ante la falta de respuesta de un slave, esperando el dichoso bit ACK.
Por cierto, que se tienen que 'explicar' los dos pic?
[Otro detalle, el I²C no es el bus mas recomendado para sacarlo a pasear fuera de la pcb, ya se entiende que las condiciones no las pones tu]
Añado: que no se desconfigure lo del SAA1064, que esto ya iba,no?,

[Aunolose]

¿estáis en el chat?

[Aunolose]

El tema de los LCD es más simple de lo que parece, el CCS tiene librerías para ello, podrías compartir todas las lineas salvo la de la enable.

[navegante 420]

Que te parece si en vez de liarme al tema de los motores, me mato con la mecanica, y pongo un rele bobinado????? con un transistor, y va que arde??????

[Aunolose]

Me parece muuuucho más sencillo y viable, además si es para "cambio de vía" más... ¿normal...? lo otro son matar moscas a cañonazos ¿no? ¿como son las vías de grandes? :D

Me llaman, me tengo que ir :bangehead:

[navegante 420]

eso de las lcd me lo suponia pero no tengo ni idea de na mas, jejejeje

y no no estamos en el chat. pero podriamops ir par discutir mas de tu a tu este seguindo modulo y poor lo menos tener mañana la estructura del programa.

[Aunolose]

Ya estoy, voy p'al chat.

[navegante 420]

Del programa que me he bajado, hay un ejemplo de programa base, como este.
/*********************************************************************
*
* Microchip USB C18 Firmware Version 1.0
*
*********************************************************************
* FileName: main.c
* Dependencies: See INCLUDES section below
* Processor: PIC18
* Compiler: C18 2.30.01+
* Company: Microchip Technology, Inc.
*
* Software License Agreement
*
* The software supplied herewith by Microchip Technology Incorporated
* (the “Company”) for its PICmicro® Microcontroller is intended and
* supplied to you, the Company’s customer, for use solely and
* exclusively on Microchip PICmicro Microcontroller products. The
* software is owned by the Company and/or its supplier, and is
* protected under applicable copyright laws. All rights are reserved.
* Any use in violation of the foregoing restrictions may subject the
* user to criminal sanctions under applicable laws, as well as to
* civil liability for the breach of the terms and conditions of this
* license.
*
* THIS SOFTWARE IS PROVIDED IN AN “AS IS” CONDITION. NO WARRANTIES,
* WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING, BUT NOT LIMITED
* TO, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
* PARTICULAR PURPOSE APPLY TO THIS SOFTWARE. THE COMPANY SHALL NOT,
* IN ANY CIRCUMSTANCES, BE LIABLE FOR SPECIAL, INCIDENTAL OR
* CONSEQUENTIAL DAMAGES, FOR ANY REASON WHATSOEVER.
*
* Author Date Comment
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Rawin Rojvanit 11/19/04 Original.
********************************************************************/

/** I N C L U D E S **********************************************************/
#include <p18cxxx.h>
#include "system\typedefs.h" // Required
#include "system\usb\usb.h" // Required
#include "io_cfg.h" // Required

#include "system\usb\usb_compile_time_validation.h" // Optional
#include "user\user.h" // Modifiable

/** V A R I A B L E S ********************************************************/
#pragma udata

/** P R I V A T E P R O T O T Y P E S ***************************************/
static void InitializeSystem(void);
void USBTasks(void);

/** V E C T O R R E M A P P I N G *******************************************/

extern void _startup (void); // See c018i.c in your C18 compiler dir
#pragma code _RESET_INTERRUPT_VECTOR = 0x000800
void _reset (void)
{
_asm goto _startup _endasm
}
#pragma code

#pragma code _HIGH_INTERRUPT_VECTOR = 0x000808
void _high_ISR (void)
{
;
}

#pragma code _LOW_INTERRUPT_VECTOR = 0x000818
void _low_ISR (void)
{
;
}
#pragma code

/** D E C L A R A T I O N S **************************************************/
#pragma code
/******************************************************************************
* Function: void main(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: Main program entry point.
*
* Note: None
*****************************************************************************/
void main(void)
{
InitializeSystem();
while(1)
{
USBTasks(); // USB Tasks
ProcessIO(); // See user\user.c & .h
}//end while
}//end main

/******************************************************************************
* Function: static void InitializeSystem(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: InitializeSystem is a centralize initialization routine.
* All required USB initialization routines are called from
* here.
*
* User application initialization routine should also be
* called from here.
*
* Note: None
*****************************************************************************/
static void InitializeSystem(void)
{
ADCON1 |= 0x0F; // Default all pins to digital

#if defined(USE_USB_BUS_SENSE_IO)
tris_usb_bus_sense = INPUT_PIN; // See io_cfg.h
#endif

#if defined(USE_SELF_POWER_SENSE_IO)
tris_self_power = INPUT_PIN;
#endif

mInitializeUSBDriver(); // See usbdrv.h

UserInit(); // See user.c & .h

}//end InitializeSystem

/******************************************************************************
* Function: void USBTasks(void)
*
* PreCondition: InitializeSystem has been called.
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: Service loop for USB tasks.
*
* Note: None
*****************************************************************************/
void USBTasks(void)
{
/*
* Servicing Hardware
*/
USBCheckBusStatus(); // Must use polling method
if(UCFGbits.UTEYE!=1)
USBDriverService(); // Interrupt or polling method

}// end USBTasks

/** EOF main.c ***************************************************************/

pero claro como que leñe es to eso????? y donde pongo yo mi programa?????

[Aunolose]

En el main, esto es para convertir el PIC en un CDC (un emulador de puerto serie), lo que va dentro del main es lo que se ejecuta, tienes que poner dentro del bucle, lo que tenga que ir dentro del bucle, ojo, si pones esto y quieres que funcione, olvídate de retardos de 200ms o 1 segundo, porque el USBTask se debe ejecutar cada cierto o pincha, te lo dice uno que lo está sufriendo con el CNC :(

¿esto también es para el viernes? joe macho...

[navegante 420]

yo siempre el mas dificil todavia. jejejejeje

[Aunolose]

He encontrado el trozo de código que hay que poner en el compilador del CCS para que desplace el código a un lugar seguro.

Esto es necesario para no chafar el bootloader, pues todo es memoria de programa (lo explicamos en otro hilo)



#define LOADER_END 0x8FF
#define LOADER_SIZE 0x7FF

#ifndef _bootloader

#build(reset=LOADER_END+2, interrupt=LOADER_END+8)

#org 0, LOADER_END {}

#endif

Lo que hay que cambiar es lo del 0x8FF y el 7FF, para no chafar el bootloader, fíjate que cambian las interrupciones, este código debe ir antes de cualquier otro

[navegante 420]

he encontrado esto sobre el usb del pic.
Aqui, Todo en Microcontroladores Pic - Libreria CCS para USB (18F2550-18F4550) - lenguaje C para microcontroladores (http://todopic.mforos.com/46840/3768612-libreria-ccs-para-usb-18f2550-18f4550/)

LA lineas que me pones intuyo que son para aprovechar el bootloader de microcrip'???

[Aunolose]

Si, son para aprovechar el bootloader de MicroChip (y el programa del PC, recuérdalo)

Pongo aquí por escrito, para que no se pierda con el chat.

Para cambiar la frecuencia del reloj y que siga funcionando el USB basta con modificar los "Configurations bits", quizá haya que hacerlo en el código con alguna directiva, pero es sencillo. También hay que cambiar el PLL para el USB. Hay que hacerlo en MPLAB, con el MCC18 instalado, claro... se compila todo y ya está.

EL bootloader se puede activar de varias maneras, una de ellas, la más común es con un pata, asociada a un pulsador o un jumper, por lo tanto esa pata debe ser una entrada y, si quieres que se active el bootloader (se activa al arrancar) debes mantener pulsado (a 0) ese pulsador/entrada si se quiere cambiar la pata, buscar una instrucción del tipo:
if (RA0==0) o if (!RA0)
Recordad cambiar también el TRIS correspondiente.
También puede ir por tiempo, si no le llega nada por usb en un tiempo, salta al programa de usuario

Otra cosa, el programa del PC es un poco viejuno, hay que ejecutarlo en modo windows95 y como administrador (sobre todo en windows 7) le oí decir a un profe que lo había hecho de otra manera, pero ahora no tengo el profe a mano, y así funciona así que así lo tengo...

Si tienes otro reloj, como el programa está hecho para 20Mhz en una placa de microchip, se queja, pero ni caso, le dais "pon lo que yo diga" y arreando. (Eso fue lo que modifiqué) hablamos otro día de posibles envíos...


Y ahora ya lo dejo...

[navegante 420]

Muchisimas gracias por el tiempo dedicado, y por ponerlo aqui otra vez, pero que sepas que ya habia hecho capturas de pantalla para tener esa informacion guardadita.

Voy con el programa del gestor en c y luego me pongo un rato con el bootloader que ya estoy espeso con este. Pues por lo que veo lo que me baje me sirve mas bien poco.

[Aunolose]

Bueno, no sé si está en la otra pagina o lo puse en el chat, así que lo repito y aclaro mejor.

Los Bootloader se limitan a copiar lo que viene por el puerto serie en la memoria de programa, como ellos (los bootloader) están en la memoria de programa, hemos de tener cuidado y "avisar" de que lo copie "más allá" para no chafarlo. (cosa muy habitual hasta que lo consigues) si lo chafas, has de reprogramar el PIC, esta vez con un programador de verdad.
La información de "echarlo más p'allá" viaja en el .hex, es decir: la genera el compilador, y para desplazar las direcciones (en CCS) son necesarias esas lineas que pongo antes, sobre todo la de #org esas lineas debes ponerlas en todos los programas que quieras cargar con el bootloader, antes de cualquier linea que genere código, y solo una vez (o te machacas a ti mismo)

¿que pasará cuando se arranque un PIC que tiene bootloader y un programa de usuario? lo primero que se ejecutará siempre es el bootloader, que decidirá (con una pata, o por tiempo, o por recepción) si entra en modo programación o no, si es que no, salta al programa de usuario (que debe estar en la dirección correcta).
Con las interrupciones pasa lo mismo, la primera rutina de interrupción la tiene el bootloader (es el que está en esa dirección de memoria) que lo que hará será saltar inmediatamente a la dirección del programa de usuario, y que, debe estar en la dirección correcta.

Con estas lineas que he puesto el código de usuario se pone a partir de la dirección 0x800, ese será su dirección de "reset" y los vectores de interrupción en el 0x808 y 0x818, que corresponden a los vectores de alta y baja prioridad respectivamente.

Todo este rollo para decirte que te asegures de que el hex que generas empieza en la dirección adecuada para no chafar el bootloader (si lo chafas, toca reprogramar y no ganamos nada) ojo con los vectores de interrupción.
Al usar un compilador diferente entre el bootloader y el programa de usuario, hay que saber como lo hace uno y otro, el bootloader del MCC18 (de microchip) salta a la dirección 0x800 con los vectores como he dicho, si quieres que tus programas generados con el CCS se coloquen ahí, pues eso, las instrucciones que pongo antes, aunque ahora sospecho que me falta lo de las interrupciones...

Si se puede hacer, mira el código generado por el CCS en ensamblador, allí tienes las direcciones donde va a parar cada cosa, si está por debajo de 0x800, no te servirá para el bootloader de microchip...

[navegante 420]

Una pregunta rapida, estoy haciendo la placa del gestor y, el pic tiene varias vcc y vdd, las conecto todas???? es que hasta ahora en proto solo conectaba una. gracias.

[Aunolose]

Me pillas, porque trabajo con el de 28 patas, que solo tiene dos masas y un Vcc, en ese no es necesario conectar una de las VCC, pero yo lo haría, cuanto más patas de masa, más inmunidad al ruido, solo será peor si le das muuuucha vuelta a la pista. Recuerda el condensador de desacoplo lo más cerca posible de Vcc y Vdd

[navegante 420]

si, si , no esta mas cerca porque sino compartirian "hole" jejeje

[Aunolose]

joe, puse que no es necesario alimentar una de las Vcc y solo tiene una... me refería a vdd, que no hace falta, pero como digo, yo lo hago y haré siempre.


Hoy tengo que entrar y salir muchas veces, ¿como lo llevas?

[navegante 420]

Mal, solo dormi 2 horas. Voy con sobre dosis de cafeina, Y he pasado por todos los estados, Venga va que llegamos, Va que yo puedo, mierda que me falta tiempo, que le den al proyecto que estoy hasta mas alla, etc, etc....

Ahora solo tengo ganas que llege el miercoles y que se lo que dios quiera, jejejeje.

[Gerard-2]

Voy retrasado, a ver si me pongo al dia!
Ayer tuve un lio con la maquina, en arreglar el sistema se tarda un rato, pero intentar hacerlo 50 veces te lleva 300 ratos, ahora ya está.

Como está el tema, era para hoy? ya anda? todo? no puede ser.

[Gerard-2]

Por si le interesa a Navegante, aun que sea para aclarar alguna idea para el futuro, hay una página de un tal Chiculita que tiene un bootloader de la minima expresion, creo que es interesante. Tambien tiene el prog terminal para la comunicacion sobre el PC con varias opciones de interpretacion de datos.



TyniPic (http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm)

Se ofrece el asm y una comparativa de diferentes bootloaders. Explica el tema de posicion del codigo para no interferir con el nuevo codigo cargado.

[navegante 420]

Gracias gerard, hoy tube un mal dia, empeze con un cuadro de ansiedad y hasta que no me hizo efecto el valium y el diazepan, apenas podia respirar.

Ahora ya estoy mas tranquilo, ya he hecho la placa del gestor, luego os subo unas fotos,

[Gerard-2]

Caramba, me iba a dormir y me encuentro esto!, si que lo siento, espero que a estas horas ya este todo olvidado.
Cuidate, que queda mucho por aprender :)

[Aunolose]

Ostras, venga anímate, lo siento por la parte que me toca... ¿quedamos esta tarde?

[navegante 420]

mucho por aprender, mucho por hacer y poco tiempo, jejejeje,

toy por aquí Oscar, haciendo los diagramas del gestor para pasrlos al c, haber si mañana tengo esto listo y el viernes hago el bootloader y lcd graficas, el finde monto y el lunes lo pruebo y el martes pa gerona.

si me da muchos problemas el bootloader, he pensado utilizar lo que tengo, en un pics y hacer la demo de que funciona el USB y en otro pic monto la comunicacion i2c y las lcds con los 4 cambios del box.

[navegante 420]

Bueno os las subo cuando llege a casa, que a qui no puedo.

[navegante 420]

Y a mi que no me gustaba el C.....


/*==============================================================================================

GESTOR DE CARRERAS EVO2
por
Jaime Roman
Oscar
Gerard
================================================================================================*/
#include <18F4550.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES INTRC_IO //Internal RC Osc, no CLKOUT
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOBROWNOUT //No brownout reset
#FUSES BORV20 //Brownout reset at 2.0V
#FUSES NOPUT //No Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES IESO //Internal External Switch Over mode enabled
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES PBADEN //PORTB pins are configured as analog input channels on RESET
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOCPB //No Boot Block code protection
#FUSES MCLR //Master Clear pin enabled
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES PLL12 //Divide By 12(48MHz oscillator input)
#FUSES CPUDIV4 //System Clock by 4
#FUSES USBDIV //USB clock source comes from PLL divide by 2
#FUSES VREGEN //USB voltage regulator enabled
#FUSES ICPRT //ICPRT enabled

#use delay(clock=8000000)
#use i2c(Master,Fast,sda=PIN_B0,scl=PIN_B1)
#use fast_io (A)
#use fast_io (B)
#use fast_io (C)
#use fast_io (D)
#byte CMCON=0xFB4


int1 penalty1=0,penalty2=0,cuentavueltas=0,carrera=0,programar=0,tempo1=0;
int8 display1=0,display2=0,vueltas_coche1=0, vueltas_coche2=0,vueltas=0, vueltas_penalty1=3,vueltas_penalty2=3,select=1;


#int_RB
void RB_isr(void)
{
disable_interrupts(GLOBAL) ;
//cuentavueltas coche 1
if(input(pin_B4)==0)
{
if(penalty1==1)
{
if(select!=5)
{
if(select==7)
{
vueltas_penalty1--;
if(tempo1==1)
{
//activar timer3
}
else
{
tempo1=1;
//activar timer0
}
}
else
{
vueltas_penalty1=3;
if(penalty2==1)select=7;
else select=5;
}
}
else
{
vueltas_penalty1--;
//activar timer0
}
}
if(cuentavueltas==1)
{
vueltas_coche1--;
if(vueltas_coche1==0)
{
if(vueltas_coche2!=0) select=9;
}
else
{
if(penalty2=0)select=8;
}
}
else vueltas_coche1++;
}

//Cuenta vueltas coche2
if(input(pin_B5)==0)
{
if(penalty2==1)
{
if(select!=6)
{
if(select==7)
{
vueltas_penalty2--;
if(tempo1==1)
{
//activar timer3
}
else
{
tempo1=1;
//activar timer0
}
}
else
{
vueltas_penalty2=3;
if(penalty1==1)select=7;
else select=6;
}
}
else
{
vueltas_penalty2--;
//activar timer0
}
}
if(cuentavueltas==1)
{
vueltas_coche2--;
if(vueltas_coche2==0)
{
if(vueltas_coche1!=0) select=9;
}
else
{
if(penalty1=0)select=8;
}
}
else vueltas_coche2++;
}

//Boton de programación
if(input(pin_B6)==0)
{
output_bit(PIN_d2,(~input(pin_d2)));
}

//boton inicio
if(input(pin_B7)==0)
{
output_bit(PIN_d3,(~input(pin_d3)));
}
delay_ms(20);
enable_interrupts(GLOBAL);
}

#int_COMP
void COMP_isr(void)
{
if(C1OUT==1)output_high (pin_D4);
else output_low (pin_D4);
if(C2OUT==1)output_high (pin_D5);
else output_low (pin_D5);
clear_interrupt(INT_COMP);
}



void main()
{
set_tris_D (0b11000000);
set_tris_A (0b11111111);
set_tris_B (0b11111100);

setup_timer_0(RTCC_INTERNAL);
setup_timer_1(T1_INTERNAL|T1_DIV_BY_1);

enable_interrupts(GLOBAL);
enable_interrupts(INT_RB);
enable_interrupts(INT_COMP);
setup_vref(VREF_LOW|5|VREF_COMP);
CMCON=0b00000110;


setup_oscillator(OSC_8MHZ|OSC_TIMER1|OSC_31250|OSC_PLL_OFF);
output_D(0);
// TODO: USER CODE!!

while(1);

switch(select)
{
case 1:

break;

case 2:

break;





}

}

pedazo codigo que me esta saliendo. jejejeje

[Aunolose]

Veo que ya desactivas la interrupción del comparador ¿lo has probado así?

Como veo que has cambiado algo del comparador, puedes hacer esto:

en vez de
if(C1OUT==1)output_high (pin_D4);
else output_low (pin_D4);

puedes poner
output_pin(pin_D4, C1OUT);


Será aún más rápido.

¿porque sigues metiendo un retardo de 20ms en la interrupción de RB?

¿has probado primero una cosa y después otra?

[navegante 420]

jejeje, es que a esa parte todavia no habia llegado, jejeje, los rebotes los hago con hard, ya veras que placa mas chula cuando pueda subir las fotos, asi que va fuera. y al comparador todavia no he llegado, estoy con su diagrama de flujo.

Con el miedo que me daba el puto C,y ahora, hasta me esta gustando y todo.

[Aunolose]

Animo, aunque mejor que empieces poco a poco, primero un bloque, por ejemplo el cuanta vueltas, después otro bloque, el comparador, después otro... así te aseguras que un bloque funciona, cuando todos los bloques funcionen por separado, los juntas de dos en dos, y después todos.

[navegante 420]

nos echan pa casa, en 20 min subo fotos.

[Aunolose]

Dentro de 20 minutos no tendré mucho tiempo de contestar...

[navegante 420]

lo prometido es deuda, una parte del gestor.

47016

Y este es le box, lo que tenemos que hacer con el bootloader, lcd, etc.

47017

47018

En cuanto a tu sugerencia, ya lo tenia previsto, pero un profe hoy me ha fastidiado un poco el planing, no haciendsome las placas que me faltaban, asi que mañana a saco, Probaré suerte, y si pita, eso que me llevo. Sino pos por partes.

[navegante 420]

Joer con el programita...... no me estraña que me estresara,:D:D


/*==============================================================================================

GESTOR DE CARRERAS EVO2
por Jaime, Oscar y Gerard
================================================================================================*/
#include <18F4550.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES INTRC_IO //Internal RC Osc, no CLKOUT
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOBROWNOUT //No brownout reset
#FUSES BORV20 //Brownout reset at 2.0V
#FUSES NOPUT //No Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES IESO //Internal External Switch Over mode enabled
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES PBADEN //PORTB pins are configured as analog input channels on RESET
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOCPB //No Boot Block code protection
#FUSES MCLR //Master Clear pin enabled
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES PLL12 //Divide By 12(48MHz oscillator input)
#FUSES CPUDIV4 //System Clock by 4
#FUSES USBDIV //USB clock source comes from PLL divide by 2
#FUSES VREGEN //USB voltage regulator enabled
#FUSES ICPRT //ICPRT enabled

#use delay(clock=8000000)
#use i2c(Master,Fast,sda=PIN_B0,scl=PIN_B1)
#use fast_io (A)
#use fast_io (B)
#use fast_io (C)
#use fast_io (D)
#byte CMCON=0xFB4

//flags
int1 penalty1=0,penalty2=0,cuentavueltas=0,carrera=0,programar=0,tempo1=0,tempo2=0,tempo3=0,tempo4=0;

//datos
int8 display1=0,display2=0,vueltas_coche1=0, vueltas_coche2=0,vueltas=0, vueltas_penalty1=3,vueltas_penalty2=3,select=1;

//Tabla bin a 7seg
int dec7[12]={0b0111111, //0
0b0000110, //1
0b1011011, //2
0b1001111, //3
0b1100110, //4
0b1101101, //5
0b1111101, //6
0b0100111, //7
0b1111111, //8
0b1101111, //9
0b1110011, //P(10)
0b1010000}; //r(11)
char buffer_car[5];
void saa1064_putc(int,int,int,int);
#int_RB
void RB_isr(void)
{
disable_interrupts(GLOBAL) ;
//cuentavueltas coche 1
if(input(pin_B4)==0)
{
if(penalty1==1)
{
if(select!=5)
{
if(select==7)
{
vueltas_penalty1--;
if(tempo2==1)
{
tempo3=1;
//activar timer3
}
else
{
tempo1=1;
//activar timer0
}
}
else
{
vueltas_penalty1=3;
if(penalty2==1)select=7;
else select=5;
}
}
else
{
vueltas_penalty1--;
tempo1=1;
//activar timer0
}
}
if(cuentavueltas==1)
{
vueltas_coche1--;
if(vueltas_coche1==0)
{
if(vueltas_coche2!=0) select=9;
}
else
{
if(penalty2=0)select=8;
}
}
else vueltas_coche1++;
}

//Cuenta vueltas coche2
if(input(pin_B5)==0)
{
if(penalty2==1)
{
if(select!=6)
{
if(select==7)
{
vueltas_penalty2--;
if(tempo1==1)
{
tempo4=1;
//activar timer3
}
else
{
tempo2=1;
//activar timer0
}
}
else
{
vueltas_penalty2=3;
if(penalty1==1)select=7;
else select=6;
}
}
else
{
vueltas_penalty2--;
tempo2=1;
//activar timer0
}
}
if(cuentavueltas==1)
{
vueltas_coche2--;
if(vueltas_coche2==0)
{
if(vueltas_coche1!=0) select=9;
}
else
{
if(penalty1=0)select=8;
}
}
else vueltas_coche2++;
}

//Boton de programación
if(input(pin_B6)==0)
{
if(carrera==0)
{
if(programar==0)
{
programar=1;
select=2;
}
else
{
if(vueltas>=99)
{
vueltas=0;
select=2;
}
else
{
vueltas++;
select=2;
}
}

}
else
{
if(cuentavueltas==0)
{
if(C1OUT==0&&C2OUT==0)
{
programar=1;
vueltas=0;
carrera=0;
select=2;
}
}
}

}

//boton inicio
if(input(pin_B7)==0)
{
if(programar==1)
{
programar=0;
if(vueltas==0)
{
cuentavueltas=0;
select=1;
}
else
{
cuentavueltas=1;
select=1;
}
}
else select=3;
}
enable_interrupts(GLOBAL);
}

#int_COMP
void COMP_isr(void)
{
//seguidor de tension1
if(C1OUT==0)
{
if(select=3) penalty1=1;
else
{
if(penalty1=0)
{
if(penalty2=0)
{
if(C2OUT=0)select=8;
else select=4;
}
}
}
}
else
{
if(select=8)
{
select=4;
}
else
{
if(tempo1=1)
{
if(penalty1=1)
{
select=11;
}
}
}
}

//segudor tension coche2
if(C2OUT==0) {
if(select=3) penalty1=1;
else
{
if(penalty2=0)
{
if(penalty1=0)
{
if(C1OUT=0)select=8;
else select=4;
}
}
}
}
else
{
if(select=8)
{
select=4;
}
else
{
if(tempo2=1)
{
if(penalty2=1)
{
select=11;
}
}
}
}
clear_interrupt(INT_COMP);
}



void main()
{
set_tris_D (0b11111101);
set_tris_A (0b11111111);
set_tris_B (0b11111100);

setup_timer_0(RTCC_INTERNAL);
setup_timer_1(T1_INTERNAL|T1_DIV_BY_1);

enable_interrupts(GLOBAL);
enable_interrupts(INT_RB);
enable_interrupts(INT_COMP);
setup_vref(VREF_LOW|5|VREF_COMP);
CMCON=0b00000110;


setup_oscillator(OSC_8MHZ|OSC_TIMER1|OSC_31250|OSC_PLL_OFF);
output_D(0);
// TODO: USER CODE!!

while(1);

switch(select)
{
case 1://modo stanby
i2c_start();
i2c_write(0b01110110);
i2c_write(0x00);
i2c_write(0x40);
i2c_write(0x1f);
i2c_write(0x00);
i2c_stop();
vueltas_coche2=vueltas;
vueltas_coche1=vueltas;
sprintf(buffer_car,"%02u%02u",vueltas_coche2,vueltas_coche1);
saa1064_putc(buffer_car[0]-0x30,buffer_car[1]-0x30,buffer_car[2]-0x30,buffer_car[3]-0x30);
break;

case 2://Modo Programación
i2c_start();
i2c_write(0b01110110);
i2c_write(0x00);
i2c_write(0x40);
i2c_write(0x00);
i2c_write(0x00);
i2c_stop();
sprintf(buffer_car,"%02u%02u",vueltas,vueltas);
saa1064_putc(dec7[10],dec7[11]-0x30,buffer_car[2]-0x30,buffer_car[3]-0x30);
break;

case 3://modo inicio de carrera
i2c_start();
i2c_write(0b01110110);
i2c_write(0x00);
i2c_write(0x40);
i2c_write(0x00);
i2c_write(0x00);
i2c_stop();
delay_ms(500);
//1 rojo
i2c_start();
i2c_write(0b01110110);
i2c_write(0x00);
i2c_write(0x40);
i2c_write(0x01);
i2c_write(0x00);
i2c_stop();
output_high (pin_D1);
delay_ms(500);
output_low (pin_D1);
delay_ms(500);
//2 rojo
i2c_start();
i2c_write(0b01110110);
i2c_write(0x00);
i2c_write(0x40);
i2c_write(0x03);
i2c_write(0x00);
i2c_stop();
output_high (pin_D1);
delay_ms(500);
output_low (pin_D1);
delay_ms(500);
//3 rojo
i2c_start();
i2c_write(0b01110110);
i2c_write(0x00);
i2c_write(0x40);
i2c_write(0x07);
i2c_write(0x00);
i2c_stop();
output_high (pin_D1);
delay_ms(500);
output_low (pin_D1);
delay_ms(500);
//4 rojo
i2c_start();
i2c_write(0b01110110);
i2c_write(0x00);
i2c_write(0x40);
i2c_write(0x0f);
i2c_write(0x00);
i2c_stop();
output_high (pin_D1);
delay_ms(500);
output_low (pin_D1);
delay_ms(500);
//5 rojo
i2c_start();
i2c_write(0b01110110);
i2c_write(0x00);
i2c_write(0x40);
i2c_write(0x1f);
i2c_write(0x00);
i2c_stop();
output_high (pin_D1);
delay_ms(500);
output_low (pin_D1);
delay_ms(1000);
//apagado
i2c_start();
i2c_write(0b01110110);
i2c_write(0x00);
i2c_write(0x40);
i2c_write(0x00);
i2c_write(0x00);
i2c_stop();
select=13;
break;

case 4://modo precaución
i2c_start();
i2c_write(0b01110110);
i2c_write(0x00);
i2c_write(0x40);
i2c_write(0x60);
i2c_write(0xe0);
i2c_stop();
sprintf(buffer_car,"%02u%02u",vueltas_coche2,vueltas_coche1);
saa1064_putc(buffer_car[0]-0x30,buffer_car[1]-0x30,buffer_car[2]-0x30,buffer_car[3]-0x30);
break;

case 5://modo penalty1



break;

case 6://modo penalty2



break;

case 7://modo penalty1y2



break;

case 8://modo carrera ok
i2c_start();
i2c_write(0b01110110);
i2c_write(0x00);
i2c_write(0x40);
i2c_write(0x00);
i2c_write(0x1f);
i2c_stop();
sprintf(buffer_car,"%02u%02u",vueltas_coche2,vueltas_coche1);
saa1064_putc(buffer_car[0]-0x30,buffer_car[1]-0x30,buffer_car[2]-0x30,buffer_car[3]-0x30);

break;

case 9://modo gana coche1



break;

case 10://modo gana coche2



break;

case 11://modo realizacion penalty1



break;

case 12://modo realizacion penalty2



break;

case 13://modo intermedio
delay_ms (500);
if(select==13)select=8;
break;

}

}
void saa1064_putc(int d4,int d3,int d2,int d1)
{
i2c_start();
i2c_write(0b01110000); //dirección
i2c_write(0x00);
i2c_write(0b1000001); //modo dinámico, sin parpadeo, 12mA

i2c_write(dec7[d1]);
i2c_write(dec7[d2]);
i2c_write(dec7[d3]);
i2c_write(dec7[d4]);

i2c_stop();
}

Espero y rezo por que ande, por que si me toca ir probandolo por partes, no acababo en todo el finde.

Haber con un poco de suerte este finde podré hacer la demos del box, aunque sea sin bootloader.

[Aunolose]

Bueno, no cuentas nada más, ayer por la mañana tuve que hacer un viaje relámpago al pueblo y pensé que podría entrar por la tarde, pero no pudo ser, no me acabo de enterar la vida tan ajetreada que llevan las niñas cuando yo no estoy... hoy por la mañana tampoco he podido por que tenía que llevar a la mayor a un maratón de gimnasia rítmica y por fin pude entrar.

A ver, leído por encima y suponiendo que i2c funcione, tiene buena pinta, no acabo de entender lo que es cada "penalty", supongo que el uno y el dos son por cada coche, pero me pierdo con lo que es cada uno, te sugiero que pongas más comentarios, para que podamos enterarnos y al mismo tiempo veas si lo que estás diciendo que es, es en realidad lo que es :scratch: quiero decir que hay veces que estás poniendo una cosa y al escribirlo te das cuenta de que no es así.

[navegante 420]

Pues si tienes razon, esta vez esta muy poco comentado, para lo que estoy acostumbrado, pero comparto de unos diagramas de flujo muy, pero que muy estudiados, cuando lo paso al c entre que no se, y que no quiero cagarla, en vez de comentarlo, lo que hago es repasarlo una y otra vez....:) pero si ahora lo comentaré.

Bueno hoy me he dedicado al maquetismos y ha falta de colocar las placas, los sensores, la trencilla conductora, y una mano de pintura blanca, esto es como esta quedando el box.

47069
47070
47071

[Gerard-2]

Que chulo te esta quedando todo esto! has fresado las ranuras de las pistas? las pistas las sacaras de otros tramos comerciales? para cuando en el montilivi?

No queria marear con el tema del programa, pensaba que Oscar ya estaba al tanto de los detalles...la verdad es que no podia seguir el codigo y pensaba que era culpa mia :)

Con el follon de If then else me he perdido, yo tambien empezaba por los diagramas, luego los adaptaba al lenguaje o a las intrucciones disponibles. Conoces el prog DIA? para presentar diagramas creo que esta bien y es gpl.

Animo, que ya lo tienes casi a punto.

[navegante 420]

Que chulo te esta quedando todo esto! has fresado las ranuras de las pistas? las pistas las sacaras de otros tramos comerciales? para cuando en el montilivi?

Si, he fresado todas las ranuras de las pistas, con fresa de 3mm y una profundidad de 6mm, porque asi tambien pueden pasar sin problemas los coches de otras casas comerciales.
Si a pistas te refieres a la parte metalica de conduccion, no, lo hago con muchos metros de trencilla, que pacientemente tengo que pegar.

Montilivi?????? Gerard, me tienes descolocado totalmente...... Como sabes lo de Montilivi?????? por si he dicho que es un concurso y que lo tengo que presentar en Gerona, pero no dije donde...... Como has sabido que es allí????


No queria marear con el tema del programa, pensaba que Oscar ya estaba al tanto de los detalles...la verdad es que no podia seguir el codigo y pensaba que era culpa mia :)

Con el follon de If then else me he perdido, yo tambien empezaba por los diagramas, luego los adaptaba al lenguaje o a las intrucciones disponibles. Conoces el prog DIA? para presentar diagramas creo que esta bien y es gpl.

Es lo que pasa cuando no conoces el lenguaje, Yo con bits me manejo, con lotes tambien, pero con el C ni P.I. Asi que abuso del If que digamos que es lo mas parecido al tan recurrido goto/return del ensambler.

y si conozco el dia, el año pasado le dimos buena cuenta de él en c-7 Tecnicas de programacion.


Animo, que ya lo tienes casi a punto.

Muchas gracias, por los animos, Ya sabeis que os debo mucho, y que si no fuera por vosotros, no hubiese llegado hasta aquí. Así que por vosotros, voy a ir a por todas, hasta el final, aunque me cueste una parte de mi salud.

[Gerard-2]

hasta el final, aunque me cueste una parte de mi salud.

Tampoco hay que pasarse! ademas lo unico que hago por aqui es aprender, que nunca se sabe lo suficiente.

Vaya curro con la fresa, en otro momento ya me explicaras como se hacen las curvas enlazadas con los tramos rectos, no tengo ni idea de todo esto.

No pretendia mosquearte con el tema del concurso, aparte de que hay documentacion por google, estaba al tanto del acuerdo con Toy y es un acuerdo entre varios ies, el año pasado fue en casa, ahora toca ser 'visitante' no?

Te mando un mensaje.

[navegante 420]

Tampoco hay que pasarse! ademas lo unico que hago por aqui es aprender, que nunca se sabe lo suficiente.

Ya pero yo soy asi, aunque decirte que ya no puedo más.... ayer eran las 5 de la madrugada cuando me fui a la cama buscando un corto en una placa, y a las 9 ya estaba otra vez.



Vaya curro con la fresa, en otro momento ya me explicaras como se hacen las curvas enlazadas con los tramos rectos, no tengo ni idea de todo esto.

El secreto es una regla, un compas para dibujarlo, y a la hora de fresar, una buena fresadora, con una buena fresa, si es posible un guador, y mucho, pero que mucho, pulso y pacienecia, si te enseño mis primeras prubas........ jejejeje


No pretendia mosquearte con el tema del concurso, aparte de que hay documentacion por google, estaba al tanto del acuerdo con Toy y es un acuerdo entre varios ies, el año pasado fue en casa, ahora toca ser 'visitante' no?

Te mando un mensaje.

Si si , semos visitantes, pero tenemos el honor de inagurar el certamen, el miercoles 25 a las 9:20 se acabo este estres.

A partir del jueves a acabarlo, pero disfrutando, para mi y por gusto. (y de paso me quito esta espinita.)

Tras los inconvenientes de este finde, se presenta maqueta, y primera fase del proyesto sobre proto, ya que no hay tiempo de repetir placa.

Asi podre descansar un poco,para poder hacer una buena presentación, que visto lo visto el año pasado, la presentación es un 90% de la opinion del jurado. Y esperar que suene la flauta.

[Aunolose]

Joe que pasada, yo pensé que el tema del escalectric ya lo tenías solucionado comercialmente, madre mía que curro te has pegao...

Me siento muy culpable por estos últimos días en los que no he podido entrar a ayudarte, ayer domingo tenía presidencia de mesa, osea que el día "perdido".

Dinos que es cada "penalty" y el sentido de la palabra "penalty" y no ¿choque?

[navegante 420]

jejejej, na tranqui, ayer fue el cumple de mi madre y aprenas pude estar con ella, pero por lo menos tengo el box para presentar el miercoles.

porcieto gerard, un placer haber compartido un rato esta tarde en clase.

Oscar no te has de sentir culpable, todo lo contrario, os estare eternamente agradecido por el tiempo que me habeis dedicado, y por acabar el bos no te preocupes, teniendo hecho, ahora poco a poco, ya iremos haciendo, para que vaya de pm.

Yo aprendiendo y aportando ideas, gerard con la parte mecanica, y tu con la programacion.jejejejeje

Porcierto los tan comentandados penaltys. Penalty1, coche 1 se escapa al procedimiento de salida. penalty2 coche dos se escapa al procedimiento de salida. y estos marcan un case.


Para que esto funcione (a nivel personal) he pensado hacerlo con un solo pic. Asi que ya os iré informando de mi idea. que ahora me voy a preparar la presentación oral para el miercoles.



Lo dicho, muchas pero que muchas gracias a los dos.

[navegante 420]

Oscar mira lo que he encontrado referente al bootloader del ccs para usb, Haber si me traduces las primeras explicaciones.

Puerto com virtual??????

eso que es lo que es???? y com se hace?????


http://www.youtube.com/watch?v=L1K5TKjMJCw&feature=related

[Aunolose]

A ver, lo primero es decir que lo de menos es como sea el bootloader, COM, CDC u otra cosa, lo importante es el detalle del cablecillo que pone a cero (el cablecillo es RB0), eso es lo que determina que se ejecute el bootloader y no la aplicación de usuario.
¿Lo tienes claro? bien.
Como programar el acceso al hardware en Windows cada vez está más chungo por temas de permisos y tal (es para evitar los cuelgues de antaño) lo que se hace es acceder al puerto serie "de toda la vida", que esto lo sabe hacer "cualquiera" y el lenguaje de programación que uses (Delphi, Visual C, Java, C++ Builder...) tienes librerías que lo ponen todo muy fácil, sin tener que andar programando drivers ni historias.
¿Vamos bien?
Pero ahora ya casi no tenemos puertos serie en el PC, lo que se usa son los puertos USB, y lo que hacen los CDC (Comunication Device Classes) es convertir un puerto USB en un puerto serie "de toda la vida", usando el driver adecuado, claro, pero ese te lo da CCS, microchip o quien toque, a veces ni eso, pues la clase CDC está en muchos dispositivos baratos convertidores de USB a COM (puerto serie)
Es decir, este bootloader, el del vídeo, que dice que usa CDC, hace eso, se mete como un puerto serie, así la aplicación que descarga el programa solo tiene que usar el puerto que toque, a la velocidad que toque, y listo, pero eso a ti no te tiene que importar, lo importante es que funcione.

Resumen.
El bootloader que uses y como funcione (COM, USB, propia) es lo de menos, siempre que funcione.
El bootloader necesita una manera de decidir si "entra" él, o "entra" la aplicación, en el vídeo es a través de la pata RB0, puede ser otra, pero hay que saberlo, también puede hacerse por tiempo y no gastar ninguna pata, el caso es que "algo debe haber".
Lo que te pasará más veces al principio es que se te olvide desplazar el programa a las direcciones correctas, en ese caso te tocará reprogramar el PIC por métodos tradicionales, pues machacarás el bootloader, se nota enseguida por que deja de funcionar..., solo en el hipotético caso de que tu aplicación sea tan pequeña que no machaque el código restante de bootloader parecería que todo ha ido bien al programarlo, pero en cuanto quisieras hacerlo otra vez, no podrías, pues "ahí" ya no está el bootloader, si no tu programa.
Como el cristal no lo puedes cambiar del bootloader a la aplicación, debes tener un bootloader adaptado para que funcione con el cristal que quieras, o al revés, adaptar la aplicación al cristal del bootloader, pero lo lógico es al revés. Dudo que con USB haya bootloader con el oscilador interno, por la precisión, pero quien sabe... lo que si se puede hacer (me parece) es usar el cristal para el bootloader y luego pasarte al oscilador interno, para consumir menos, por ejemplo, lo que está claro es que no tiene sentido cambiar la placa a medias, si se trata de hacer un circuito en el que no sea necesario tocar el hardware.

A ver si esto va quedando claro, yo creo que, de todo lo quieres hacer, es lo más sencillo, pero bueno..., ca uno es ca uno...

[Gerard-2]

Navegante, tambien fue un placer para mi conocerte, siento haber tenido que compartir el tiempo con 'el resto de personal' , es lo que tiene conocer a la gente, piensa que hablamos de mas de 20 años coincidiendo en cursillos y otras historias, por cierto , no preguntes por el bootloader que parece que no estan puestos...
Me hice el loco con el proyecto por que no queria 'pasarles por delante' ... me entiendes, se supone que es tuyo. Independientemente de esto yo no te podia ayudar en tu programa por que ni se lo suficiente ni tenemos la concrecion de los datos e ideas que hace falta para entender lo que quieres hacer y haces con todo el box. A estas horas ya estaras a punto de llegar a Girona, que tengas suerte!

Gracias por lo de la ayuda que te he prestado pero no creo que te haya solucionado mucho, de todas formas se agradece.
Me voy a estudiar el comentario anterior de Oscar, a ver si aprendo algo mas sobre el bootloader del pic, a estas horas tenia que estar hecha la placa del pickit y no ha podido ser, mañana sera difícil, ya veremos si para el jueves...

Aunolose, si instalas el proteus veras un ejercicio de los ejemplos que lleva un pic con un microlinux programado y hace cosas jaja, me he quedado de piedra. Hay que decir que al ser un ejemplo estará super estudiado, pero funciona!

[Aunolose]

Puf, vaya resumen, si ocupa más que lo anterior...

Entendido lo de los penaltys, ahora ¿que son los select? :D

Normalmente viene bien poner una explicación breve en cada declaración de variable, si es necesario. una variable "iva_soportado" es bastante significativa,

[Aunolose]

Tengo el proteus instalado, ahí, esperando... http://l.yimg.com/us.yimg.com/i/mesg/emoticons7/65.gif

[Gerard-2]

Lo he mirado otra vez y no es un pic, es un ARM7, ademas tiene truco, hay un sub esquema que encierra otro sub-esquema, hay bastantes mas componentes de los esperados.
Tarda algo en cargar el sistema, cuando esta listo le puedes pedir el help y tu mismo, es un uCLinux.

He mirado el bootloader con USB del CCs y 'hay muchas cosas' :) , no se ni por donde empezar...a ciegas no se me ocurre meterme con el, siempre hay mil problemas y los encontraria todos a la vez. Lo ire mirando con calma para ver que ficheros hay que añadir al compilar, ya te preguntare las dudas.

De momento a ver si mañana puedo hacer la placa del programador pickit clone de felixls, eso ya sera mucho, el chip ya lo tengo, los otros componentes parece mas sencillo de conseguir.

[Aunolose]

El bootloader lo puedes plantear como un simple programador, aunque sé que eres de los que revisan todo :D, el del CCS no puede ser mucho mayor que el de Microchip, pero si no te atreves con él, hazlo con el de Microchip, lo programas como puedas y ya lo tienes, solo tienes que tener en cuenta lo de desplazar todos los programas que hagas, lo suficiente para no chafar el bootloader, ni los vectores de interrupción (que también ocupa el bootloader)

[Aunolose]

Un detalle para el diseño de las placas, si se puede, dejar acceso a los 5 pines de programación que usa el PICkit2, así se podrá programar "en bruto" sin sacarlo de placa, no es necesario dejar libres esas patas (solo son dos en este pic), en el programa de navegante, lo único necesario sería que retirara los coches, así las patas quedan libres y se puede programar directamente. Desde que lo aplico me he ahorrado montones de quita-pon

Edito, con esos pines también se puede usar el JDM, pero ojo, que no os pase como a mi, no debe compartir masa con el PC, por ejemplo a traves del USB, porque entonces no funciona, no usan la misma masa, creo que hasta me cargue un chip por hacerlo así.

Me explico un poco más, si usas el JDM, la única conexión entre el PC y el circuito debe ser el JDM,
En este caso el problema es la alimentación, pues como el PIC se alimenta a través del JDM, si no tiene "chicha" para soportar todo el circuito, puede fallar (no se estropeará nada) es el momento de probar con la alimentación a parte (que no venga de un USB...) así puede funcionar.

[navegante 420]

Bueno ya estoy de vuelta de gerona, Al final septimo de doce, y eso que no estaba acabado.....

os cuelgo la entrevista que me han hecho para tv3, esta en catalan por eso, apartir del minuto 4:47.


http://www.tv3.cat/videos/3544911/Telenoticies-comarques---Girona

Me voy pa la cama, mañana os leo y me pongo al dia, que ahora tenemos que acabar esto, pero traigo, nuevas ideas y soluciones, muy guapas.

[Aunolose]

Jo, que poquito rato, pero alumnos solo habéis salido dos, eso ya dice algo :D

[Gerard-2]

Pues muy bien, que al final se complicaron las cosas y no se pudo hacer mas.
Ademas aquello del viaje a Itaca...

Me gusta entender las cosas por que si no los problemas se hacen irresolubles, ademas no se si la comunicacion se hace a ciegas o hay feedback con el terminal, si es asi pensaba aprovechar las rutinas de visualizacion y captura de teclado para las pruebas y debugs posteriores. Con el rs232 del 8051 lo hacia asi y me iba bien, ademas añadia provisionalmente algun volcado hex de zonas de memoria, del contenido de algun reg. dentro del programa en pruebas llamando esas sbr. sobre la marcha.

[Aunolose]

Ya sabía yo :D

¿Podéis ponerme un enlace al Bootloader del CCS? es que el de Microchip es casi todo de código abierto, entonces puedes ver lo que hace, y si, tienen los dos feedback con el terminal, por eso hace falta un programa "especial" que sepa lo que devuelve y demás.

[Gerard-2]

Huy, no se si lo entiendo, por que eso de "si, los dos tienen feedback con el terminal" ... me confunde.

Te voy a comentar antes de nada, por aclarar lo que yo pienso:

La programacion de microchip mediante el ICSP no usa un bootloader 'normal' viene asi de fabrica y hay que seguir su protocolo de hard y soft, Rb6 Clk y RB7 dat de conexion + tensiones de programacion, por eso hay que usar un interface 'raro'.

Cuando decimos que queremos programar con un bootloader, es una comunicacion 'normal' por rs232 o com virtual usb y un API que puede ser cualquier terminal, nos enseña un menu de opciones y escojemos una mediante alguna tecla etc. Se envia el programa con las opciones normales del terminal, supongo que en formato intel-hex (texto), es asi? sobre las patas de comunicacion desde su UART o como la quieran llamar, pero que no son las RB6 y 7, si lleva usb, será por estas.

Me queda una duda, la tension de 13V Vpp es un incordio o la tengo que introducir artificialmente al sistema¿?

NO se si me he explicado bien, si me confundo en algo me lo comentas, ok?
_____________________

Mas tarde, si puedo subo el bootloader de ccs, ya te mandare el link, no he visto que este colgado en la web de forma libre.

[Aunolose]

Vale, tienes razón, lo aclaro, el feedback que tiene el bootloader es de protocolo debe decir "estoy aquí" y poco más, el caso es que si lo quitas a medias, el programa lo detecta, cuando digo los dos, me refiero al del CCS y al de Microchip.

Es como lo cuentas, el ICSP son los pines que sugiero "dejar libres" en un mensaje anterior, normalmente no hacen falta los 13V, y si hacen falta, los genera el programador, no te preocupes tampoco, ¿has visto el JDM? se aprovecha de las tensiones "elevadas" del RS232, o las genera con un oscilador.
El bootloader hace uso de "algún puerto serie", puede ser 232, USB, pero también I2C, CAN, SPI... usará los pines correspondientes a ese bus.
En el PC suelen usarse el 232 o el USB (puede "generar" un COM virtual, pero también puede no hacerlo) y normalmente, debido al feedback, no funciona con cualquier terminal, sino con un programa "ex proceso".

El formato es hex, pero me pillas con lo de intel.

[Gerard-2]

Al decir 'los dos' no lo habia entendido, de acuerdo. Lo de la tension de 13V... pensaba que la aplicacion podia ser practicamente definitiva, sin añadidos extras, solo el firm-bootloader que en el ultimo momento se sustituye si se quiere dejar el pic limpio de polvo y paja. Ya no me gusta tanto añadir hard extra y ademas necesitar un programador especial, tambien un soft especial -> vamos para atras? no se...

El Jdm usa las tensiones del 232 que se supone van a ser de +/-12Vminimo, claro que si es un max232 ya son menos ,10V y si es 'una patata' igual se queda en casi TTL, pero el JDM es un programador, no usa bootloader, vale que sale por el 232 pero nisiquiera envia los datos por TX/RX lo hace por lineas auxiliares de control en un uso totalmente libre. Luego tienes el problema de la GND y el tierra del PC, por eso el pollo de las masas.

Veo que hay mucha variedad de buses para el boot, tendre que olvidar compartir rutinas del bootloader, no vale la pena, pero me gustaba usar solo un cable limpio y cualquier terminal simple, tiene su encanto.
Lo del formato HEX, lo implanto INTEL, aunque microchip usa una variante aprovechando el vacio en el byte de 'tipo de registro'. 00 es linea de datos y 01 linea final de codigo, usan las siguientes para sus necesidades.
Si quieres consultar la wiki, lo tienes todo, el byte record type es el que usan de forma especial con el pic, puedes seguir con el enlace PIC LIST, era aquello que comente en su momento que no entendia, no se si son zona de fuses, flash, eeprom u otra zona especial de config.

El contrincante es el S19 de motorola, para el 68000, en su momento importantisimo. Nada que ver con el 19, significa: registros desde S1 al S9 y evolucionó asi -> S1-S9 -> S 1-9 -> S19
del mismo modo que el I2C que viene de Intercom. entre IC(circuitos integrados) -> IIC -> I²C -> I2C , me hacia gracia explicarlo :bounce: seguramente ya lo sabias.

Mañana subire los ficheros del boot, hoy ya me he puesto muy tarde.

Una ultima cosa, el bootloader de microchip, ¿por que lineas se comunica? por las mismas de programacion RB6-7 ? y el API es el MPLAB? entonces no veo diferencia a programar el chip virgen ¿?

[Aunolose]

Lo del S19 no lo conocía, el resto si, :oops: el 68000 que es más parecido al 8086 que a los PIC y el I2C, concretamente Intercom Inter Circuits... IIC de philips...

Pero no he sabido explicarte el rollo del bootloader y el programador :banghead:

Un programador es un programador, lo programa aunque esté vacío, si hace falta, genera los 13V, pero no siempre hacen falta. Cada programador tiene su propio programa detrás, hasta ahí, igual que cualquier otro programador de cualquier otro chip.
El PIC puede usar estos programadores vía ICSP a través de RB6, RB7 la pata de reset y en algunos casos RB5, es por eso que si tienes suerte (y picardia) puedes dejar estos pines accesibles en un conector aparte, como si fuera un JTAG (por si lo conoces) y podrás programarlo con estos programadores sin quitar el PIC de la placa, incluso estando vacío. (ICSP= In Circuit Serial Programming, Programación Serie en Circuito)

Pero el ICSP no es para que esté accesible "al usuario", para eso están los bootloader. Los bootloader son programas, programas que debes programar siempre con los programadores anteriores. Lo que hacen es que se ejecutan siempre al encender el PIC, y deciden lo que tienen que hacer, o entran en modo "programación" para actualizar el firmware, o entran en modo "aplicación", como lo deciden, luego lo explico.

Si se ejecuta el bootloader lo que hace es esperar a que vengan los datos "por donde esté programado que vengan", que puede ser, 232, USB, I2C... los primeros router se actualizaban a través de un 232, eso era un bootloader a través de 232 (y no hacía falta destapar nada) los nuevos TDT se actualizan a través de USB (y no hace falta desmontar nada), en aplicaciones "comunitarias" un PIC maestro (u otro chip) puede actualizar todos los firmwares del resto a través de I2C, en un coche, vía CAN, pero la idea es que no hay que desmontar nada de nada, ni hacen falta "cacharros" especiales, cosa que con los programadores tradicionales, si. Por supuesto en este caso, tampoco hacen falta los 13V.
Con el bootloader también hacen falta programas especiales, para que el protocolo sea el mismo, me refiero a que uno diga "¿te mando datos?" y el otro diga "si".

Lo que da igual es como se genere el hex, siempre y cuando deje libres lo que ocupa el bootloader y programes correctamente los vectores de interrupción, es decir, puedes usar un bootloader del CCS y el programa generarlo en ensamblador con el MPLAB y al revés también.


Compartir rutinas de los bootloader... eso se puede, pero solo las rutinas que se pueden compartir :scratch: quiero decir, la rutina de programación es la misma para todos, pues se hace lo mismo en todos, lo que no puedes compartir es la rutina de recepción de datos, que no cambiaran mucho, pero no es lo mismo para I2C que para USB que para CAN...

Se te nota que vienes de los tiempos en los que había que aprovechar memoria, tiempo de procesador y recursos en general :D ahora hay memoria para el bootloader y mucho más... y hablamos de simples PIC, la "buena programación" prácticamente se ha perdido con las nuevas bestias que manejan Gigas de memoria a velocidades de vertigo...

[Aunolose]

Me falta por explicar como decide el (programa) bootloader si debe entrar en modo "programación" o en modo "aplicación", en los TDT es muy fácil, si en el pendrive hay un fichero llamado "firmwareXXX.hex" (o .bin, o lo que sea) entonces entra en modo programación y lo actualiza. en los routers es también sencillo, si viene lo que quiero oír por el 232, es que me quieren actualizar...

En el caso de las aplicaciones que hacemos nosotros se puede hacer con uno o varios de los botones, por tiempo, por una posición de un potenciómetro, por que reciba algo por donde toca nada más empezar, lo más sencillo es hacerlo con un botón "si cuando arrancas está pulsado el botón de prog, entras en modo programación.
Así de simple ¿? funciona el bootloader...

[Gerard-2]

Gracias por aclararme las ideas, empecé a toquetear en serio cuando el 8085, fue la primera placa que monté de verdad, la mem era la 2716 de uva con 2KB y la ram tenia 256Bytes, no kas, en un chip combinado de ports timers ram e interrupciones 8156 (http://www.datasheetarchive.com/pdf-datasheets/Databooks-2/Book261-962.html) , toda una maravilla de la tecnica.

Es verdad que los 'antiguos' interfaces clasicos de bootloader con dialogo traves de terminal son poco atractivos, ahora se lleva lo 'visual', sin ventanas llenas de botones ya no eres nada! se pudia llegar a confundir con una ventana de msdos.....YUYU

Concretando, si pongo el bootloader de CCs con que programa lo intercomunico desde el lado PC, tienes idea?

Si miro el bootloader de microchip, cual es el programa que usan ellos? supongo que el mismo IDE MPLAB, no? y este bootloader 'entra por el USB de la aplicacion? o por las lineas serie del pic, o por las del ICSP ? si fuera por icsp no veo diferencias con el programador.

te mando un msg.

[Aunolose]

Hola, me he entrenido y ahora tengo que recoger, pero te puedo pasar el programa, el del CCS no sé muy bien como va, creo que tiene un programa aparte del entorno, pero para el de microchip sé seguro que no es con el MPLAB, si no con el MCHPFSUSB que lleva los drivers y el programa.

Si no lo encuentras te lo paso de este lo tengo todo.

[Gerard-2]

EL CCs tiene un entorno pero no me lo he mirado, igual se envia desde alli mismo. Ya me lo mirare y te comento.
ahora no tengo tiempo, sigo en otro momento.

[Gerard-2]

He visto que el CCs tiene una opcion para cargar el programa, no se si es con su bootloader o que, en el manual que tengo no habla de ello.
Mañana preparare el revelador para la pcb, el que corria por alli estaba mal, igual lo habian neutralizado con los restos de la bandeja del atacado, no se.
A ver si consigo sacar la pcb de una vez.

[Aunolose]

Pues si tiene esa opción es muy probable que así sea.

[Aunolose]

Estoy buscando en el CCS y no encuentro lo de "descargar programa", solo lo veo en el Siow, que es otro programa aparte... ¿donde lo has visto?

Edito, lo que si tiene es la opción de hacerlo con ICD, eso es un cacharrito como el PICkit2, un programador, no es un bootloader y solo funciona con él, claro, no con el PICkit...

[Gerard-2]

Donde las pestañas para las distintas acciones , igual es lo que dices. Ahora estoy con linux y no lo puedo mirar. Imagino que si es un bootloader normal se podra 'enviar' desde un prog terminal por usb sobre un com virtual.

Lo del Siow he leido que es como un monitor serie, no se si incluye el usb.

[Aunolose]

Donde las pestañas para las distintas acciones , igual es lo que dices. Ahora estoy con linux y no lo puedo mirar. Imagino que si es un bootloader normal se podra 'enviar' desde un prog terminal por usb sobre un com virtual.

Lo del Siow he leido que es como un monitor serie, no se si incluye el usb.

Con un programa terminal normal y corriente, seguro que no, como te digo, hace falta que se entiendan, no es solo enviar, si fuera así, serviría el hiper terminal de windows, por ejemplo, y no sirve.

El siow es como dices un monitor serie, "algo" más avanzado que el hiperterminal, pero añade la característica de entenderse con el bootloader del CCS (para eso viene con el compilador...) aún así, no se entiende con otros bootloaders.



Tal vez te he liado al decir que muchos controladores USB usan la librería CDC para convertirse en un puerto serie normal y corriente, esto es cierto, de esta manera el programa que controla el puerto serie desde el PC será mucho sencillo, pues solo tiene que usar las funciones de acceso al puerto serie que traen todos los compiladores, ahora bien, detrás del puerto serie hay una aplicación, no es lo mismo un ratón serie, un escaner, que un bootloader, entonces, de la misma manera que no puedes controlar un ratón con la rutina de un escaner o con el hiperterminal, no puedes controlar un bootloader con la rutina de un ratón o un hiperterminal, aunque todo sea "serie" (a este nivel da igual que sea COM virtual que real)




Esto es muuuuuuy aparte, en el hipotético caso de que lo espere el bootloader sea una "impresión" por el puerto serie (como antiguamente se imprimía "print talfichero.hex com1" en ese caso se podría, incluso no sería necesario un programa "terminal" pero la verdad es que lo dudo...

[Gerard-2]

He leido algo sobre el USB, pero no lo suficiente, entiendo que hay 'servicios' o modos , no se, que requieren mas atencion que otros segun necesidades . Pensaba que el com virtual era parecido a un rs232, enviando byte a byte, abriendo y cerrando al comunicacion cada vez.
Este tambien es el motivo por el que me interesa saber programar pics con com. usb, a ver si empiezo a acercarme a este mundo escondido que es el USB

De momento tengo el lio con la placa, espero conseguir un par de horas de tranquilidad 'TOTAL'.solo me faltaba lo del revelador! tendre que tantear la medida, me suena unos 10gr/1L Me he metido en fechas 'calientes' y la faena se multiplica dia a dia, en todo caso tengo la esperanza de que cada dia 'queda un dia menos' :) y esto ya se acaba, despues tendre todo el 'tiempo del mundo' aunque tambien van quedando cosas pendientes.

[Aunolose]

Joer, me explico como el culo :banghead:

A ver, primero vamos a separar el bootloader del 232.

Hablemos del 232 virtual, eso es lo que se suele hacer con el PIC y otros controladores para las aplicaciones de usuario, de cara al PC y al programa que programes es un puerto serie normal, y podrás hacer todo eso que dices, abrir, enviar un byte, cerrar... ¿ok? eso a nivel de programación, un programa de hace tiempo para el puerto serie tiene muchas posibilidades de funcionar con este puerto. Pero...

...En realidad es un COM virtual,
primera pega: la velocidad, si no la cambias es de 921600 baudios, por encima del estandar 115000 que pillarán los programas viejos,
segunda pega, y mayor, el USB funciona a tramas, si vas a enviar algo byte a byte es muuucho más rápido un puerto serie normal, aunque la velocidad sea de 921600, pues tiene que enviar una trama cada vez y toda la velocidad se va en el protocolo.
tercera pega, el tiempo de latencia, así como en RS232 puedes hacer que se mande un byte cada cierto tiempo periódico y exacto (dentro de sus limites) con el USB no se puede asegurar esa periodicidad, salvo que sea muy lenta.

Así pues, este modo de usar el USB no sirve para aplicaciones donde la sincronización y la velocidad es crítica, para eso hay otros modos de hacer funcionar el USB, pero ya requieren otro programa, con otro driver en el PC, normalmente más complicados que manejar "un puerto serie"

Y ahora hablemos del Bootloader... no hay nada que decir, que no se haya dicho, como la aplicación no es crítica en tiempo ni en velocidad, pues que se puede hacer usándolo como si fuera un puerto serie virtual, la ventaja de hacerlo así es que el programador del programa bootloader puede aprovechar las rutinas archiconocidas de dicho puerto serie.

Joe, es que no sé como explicarlo para que se entienda.

[Gerard-2]

Creo que ya te comenté que no se como van los modos de servicio del USB, de todos modos gracias por la explicacion.
Ya mirare de espavilarme como pueda y cuando tenga alguna duda concreta la comento.
Saludos

[Aunolose]

¿sabes algo de navegante? no nos cuenta nada.

[Gerard-2]

No, lo vi antes del concurso, estaba agobiado despues de tantos dias de preparar la maqueta. Creo que dijo que iba a descansar y recuperar la normalidad :) a mi tambien me extraña que no diga nada.

[XCL328]

Buenas noches:
Yo ando un poquito salido del tema, pero estoy trabajando tambien con el 18f4550 y no he podido hacer funcionar el puerto serie. No se si alguno de uds me puede ayudar este es el codigo que tengo que entre 16f877a funcionan perfectamente, pero en los 4550 parece que no estuviera haciendo nada. Agradeceria su ayuda.



#include <18f4550.h>
#fuses hs,nowdt
#use delay(clock=20000000)
#use standard_io(b)
#use rs232(baud=9600, xmit=pin_c6, rcv=pin_c7, stream=pc)

#define emi 1


void main(){

set_tris_b(0);
output_b(0);
while(true){
if (input(pin_b0)==1)
fputc(64,emi);

if (input(pin_b1)==1)
fputc(128,emi);

else
fputc(0,emi);
}
}

[Aunolose]

Hola XCL328, bienvenido.

En el código que pones hay algunos fallos de sintaxis y de funcionamiento, aunque debería enviar ceros a "emi".

Me explico, primero declaras todo el puerto B como salida lo pones a cero y después lees del puerto, que te dará 0, esté como este la pata (o tendrás un corto) por eso los dos if no mandan nada, aclarado esto, si la llave que falta { está en el primer if, pues no mandará nada de nada, y si está en el segundo, en el ultimo fputc(0,emi) debería enviarlos todo el rato. por cierto ¿no es solo putc, sin la f?

Edito: emi debería ser el puerto serie para usar fputc, prueba a usar putc para que lo mande al serie por defecto.

[XCL328]

Ya hice los cambios dejandolo de putc, tampoco funciona. Lo raro es que si los simulo o los monto con 877a funcionan a la perfeccion. ¿sera que posee el 4550 una configuracion diferente?
La verdad ya no se que mas hacerle, cualquier otra sugerencia sera bien recibida. Gracias.

[Aunolose]

¿quieres decir que este mismo código funciona en el 877A y no lo hace en el 4550? :scratch:

Mirando en la ayuda del CCS pone que stream debe ser igual al que uses en los fputc, aquí tienes pc y emi ¿funciona así en el 877A? prueba a quitarlo en el #USE y pon putc a ver que pasa.