PIC 18f4550 y CCS compiler

[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

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?

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.