Cargar un firmware a un PIC18f2550 de forma inalambrica ?

[deadsistem]

Hola a todos, disculpen un poco el desconocimiento del tema y si uso mal algunos terminos ya que soy nuevo en esto pero tengo todo el interes y las ganas de aprender al respecto... estoy utilizando un pic18f2550 y compilando código en PICC (CCS) y para cargar el programa creado utilizo el programador MASTER PROG conectado al puerto ICSP del pic... ahora bien, se que se puede utilizar el USB del pic (cargando previamente un bootloader) conectado a una PC (previamente instalados los drivers) para que mediante el PICC (CCS-SIOW) le pueda cargar cualquier programa al pic. Sin necesidad de usar el MASTER PROG, ni el ICSP.

Pero mi duda es si le puedo conectar al pic, mediante su puerto USB, un convertidor de USB a UART-TTL para que luego le ponga un bluetooh (con UART) o un modulo de RF (con UART), y del lado de la PC en su puerto USB, le puedo conectar un convertidor USB a UART TTL y tambien un modulo bluetooth (con UART) o un modulo RF (con UART). Ambos convertidores transceivers ... para hacer un puente inalámbrico y así programar el PIC sin la necesidad de usar cables... les dejo un tipo de diagrama:

PC<-->USB to UART-TTL<-->bluetooth o RF...(sin cables)...bluetooth o RF<-->UART-TTL to USB<-->USB del pic

ya que tengo la necesidad de programar muchos pics en diferentes lugares, y que no estarán al alcance tan facil como para conectarle un cable, mi idea es que desde mi lap pueda programar aunque sea de uno en uno pero remotamente o a menos de 10M... o si tienen otra idea se los agradecería mucho. reciban un cordial saludo y espero sus respuestas. gracias por la atención.

 

[Daniel Meza]

No creo que sea posible como tal porque el PIC debe de incializar el módulo Bluetooth antes de recibir datos de él, además de que sería muy engorroso tener tantos módulos Bluetooth, eso sin contar las posibles interferencias.

¿Tan inaccesibles son esos PIC's?

 

[Nuyel]

que yo sepa no soporta la función USB host (requerida para operar el USB como dices) pero sí puedes usar un bootloader basado en UART como el que se empleaba en el PIC16F877A

 

[deadsistem]

No creo que sea posible como tal porque el PIC debe de incializar el módulo Bluetooth antes de recibir datos de él, además de que sería muy engorroso tener tantos módulos Bluetooth, eso sin contar las posibles interferencias.

¿Tan inaccesibles son esos PIC's?

si, se instalaran dentro de unos gabinetes y esos gabinetes estaran en lo alto de los postes de alumbrado... y con un modulo de RF? esos no necesitan inicializarce.

que yo sepa no soporta la función USB host (requerida para operar el USB como dices) pero sí puedes usar un bootloader basado en UART como el que se empleaba en el PIC16F877A

cual es ese bootloader? quieres decir que utilizando la UART del pic, puedo cargarle un firmware desde la PC? entonces si uso modulos de radiofrecuencia con puertos UART que no necesitan inicalizarce, es posible que le pueda cargar un firmware de manera remota?

hay algo de info que me puedas proporcionar?

 

[Daniel Meza]

Pero los RF necesitan de una especie de modulación para prevenir fallos por ruidos (nuevamente interferencias).
Lo que creo dice el compañero nuyel es hacer una especie de extensión de puerto COM mediante el módulo inalámbrico.

¿Los PIC's tomarán energía de los postes?, claro con su previa fuente y ¿que tan altos son?

 

[deadsistem]

Pero los RF necesitan de una especie de modulación para prevenir fallos por ruidos (nuevamente interferencias).
Lo que creo dice el compañero nuyel es hacer una especie de extensión de puerto COM mediante el módulo inalámbrico.

¿Los PIC's tomarán energía de los postes?, claro con su previa fuente y ¿que tan altos son?

estan a 9 metros de altura, y si se alimentaran de la energia de los postes.... entonces en teoría si funcionaría por lo que veo... ya he leido unas publicaciones de otros compañeros acerca de un
bootloader por UART para pics... probare para el pic18f2550 con el convertidor de USB to SERIAL que mencionas y si funciona le agregare los modulos de RF para probar lo inalambrico y publicare mis resultados... unicamente espero encontrar el bootloader por UART para pic18f2550 y que no sea necesaria la opcion del pulsador para modo bootloader o modo normal como menciona el compañero ByAxel en esta publicacion: [Tutorial] y manejo de proton IDE del apartado de microcontroladores

espero me puedan ayudar con mas informacion al respecto ya que no se como hacer un bootloader o si ya hay uno para UART del pic18f2550...

la respuesta a: porque quiero un bootloader por UART del pic18f2550 si ya hay uno para USB?.. pues que en el de usb no tiene la opcion de HOST para controlar un dispositivo inalambrico como me comentan antes... pero por UART si se puede conectar un dispositivo externo como un modulo de RF...

espero comentarios gracias

 

[Daniel Meza]

¿pero esos micros que están en los postes ya están programados?, es que no termino de entender, ¿porque poner un sistema con un micro sin grabar?, ¿o es que te refieres a solamente la transferencia de datos de manera bidireccional entre el poste y tu laptop?

 

[deadsistem]

¿pero esos micros que están en los postes ya están programados?, es que no termino de entender, ¿porque poner un sistema con un micro sin grabar?, ¿o es que te refieres a solamente la transferencia de datos de manera bidireccional entre el poste y tu laptop?

los micros ya estaran programados... pero la programacion será modificada, actualizaciones y demas... no es transferencia de datos de la PC al pic.. es cargar nuevos firmwares en tiempos diferentes es decir tal vez al mes salga una actualizacion del firmware y se necesita reprogramar... y eso de subirse a mas de 50 postes esta cañon... y no me gustaria dejar un cable dentro del poste

 

[Nuyel]

Eso me recuerda mi reloj con un MSP430F6137, tiene RFBSL un cargador que le permite actualizarse inalambricamente supongo es lo que quieres implementar con el PIC, solo que este MSP430 ya posee un transreceptor de radio integrado.

 

[deadsistem]

Eso me recuerda mi reloj con un MSP430F6137, tiene RFBSL un cargador que le permite actualizarse inalambricamente supongo es lo que quieres implementar con el PIC, solo que este MSP430 ya posee un transreceptor de radio integrado.

NETA? y seria mucho mas barato ya que el MSP sale como 6 dolares ... yo tengo el MSP-EXP430G2... pero tengo que cambiar algunos jumpers para debug y luego para el modo normal? le puedo conectar un modulo RF o que es el transreceptor de radio? donde optengo mas info?

 

[Nuyel]

Pues el Ez430-Chronos es el que viene programado con rfbsl, pero el CC430F6137 que usa tiene integrado el modulo de radios, osea, solo necesitas agregar algunos inductores y la antena, el chip tiene lo necesario para operar en bandas sub-1GHz como la ISM de 915MHz que es abierta en México.

 

[deadsistem]

Pues el Ez430-Chronos es el que viene programado con rfbsl, pero el CC430F6137 que usa tiene integrado el modulo de radios, osea, solo necesitas agregar algunos inductores y la antena, el chip tiene lo necesario para operar en bandas sub-1GHz como la ISM de 915MHz que es abierta en México.

nuyel ya lo has desarrollado antes? sabes de algún tema referente?...o alguien que haya echo algo parecido?.. saludos y gracias

 

[Nuyel]

Con el PIC o el CC430?

En cualquier caso no he tenido tiempo, aunque tengo el reloj y he probado esa función al cargar firmware,

 

[deadsistem]

ok. muchas gracias por su ayuda, me he decidido a hacerlo mediante un cable USB, es mas economico y no hay problemas de comunicación, dejare un cable por fuera para que pueda cargarle un firmware... gracias a todos y si llego a utilizar el CC430, ya les comentare como queda. saludos

 

[torres.electronico]

los micros ya estaran programados... pero la programacion será modificada, actualizaciones y demas... no es transferencia de datos de la PC al pic.. es cargar nuevos firmwares en tiempos diferentes es decir tal vez al mes salga una actualizacion del firmware y se necesita reprogramar... y eso de subirse a mas de 50 postes esta cañon... y no me gustaria dejar un cable dentro del poste

De que tamaño estamos hablando? osea, aproximadamente el firmware que peso tiene? yo lo veo mas viable (pero lento), con un pic mas y usart... osea, implemento un pic para bajar la informacion a una eeprom, y luego, implementar el usart para programar el otro micro... es re lento, pero podria ser la solucion economica... El tema esta en que estamos hablando de una comunicacion de 2400b y no se si mas baja, pero podria ser un inicio a tu desarrollo.
Como hacer para que no tengas un brick a la hora de actualizar firmware? se me ocurre que al bajar el firmware, necesitarias un dato que te diga cuando arranca y termina el paquete de datos y despue una comparacion de peso... si esta todo bien, recien ahi hacer la subida del firmware al 2do pic... osea, usas el primero solo para bajar el firmware, verificar que el paquete este completo y luego grabar el otro micro...repito nuevamente...esto es "lento"