Webcampista.com

mucho más que un foro

PIC 18f4550 y CCS compiler

hasta el final, aunque me cueste una parte de mi salud.
Haz clic para expandir...

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.
 
Gerard-2 dijo:
Tampoco hay que pasarse! ademas lo unico que hago por aqui es aprender, que nunca se sabe lo suficiente.
Haz clic para expandir...

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.


Gerard-2 dijo:
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.
Haz clic para expandir...

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

Gerard-2 dijo:
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.
Haz clic para expandir...

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.
 
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?
 
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.
 
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?????

 
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...
 
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!
 
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,
 
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.
 
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)
 
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.
 
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.

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

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.
 
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.
 
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.
 
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.
 
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.
 
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 ¿?
 
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...
 
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...
 
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 , 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.
 
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.
 
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.
 
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.
 
Debes iniciar sesión o registrarte para responder aquí.
Arriba
© 2004-2024 Webcampista.com