3º: no entiendo muy bien a que te referis con que si no me importa perder datos, que significaria perder datos, por ejemplo que si estoy esperando el comando "ACTIVA", me llegaria "ACT" O "VA"?, o directamente no recivir nada, me podrias ampliar la idea?
El problema esta en como realizas el soft. Pueden ser de varios tipos por ejemplo el tuyo que pregunta por el valor de la entrada, usa un delay para saber luego que entra y asi por 8 bits, puede que no funcione correctametne y pierdas justamente alguna letra o letras. Me explico con cosas sobre el tiempo.
PRINCIPAL:
CALL LEE_RS232_SOFT
CALL OTRAS_RUTINAS
GOTO PRINCIPAL
Un programa seria algo asi donde esas Otras rutinas pueden ser muchas cosas. Ahora suponete que entro al CALL LEE_RS232 y no habia nada en el puerto lo cual salio, y luego entro a Otras_rutinas que se tarda 1 segundo en salir para ser exagerado y que veas donde esta el problema.
Por 1 segundo (en realidad lo que tarde lo que exista depues de esa lectura) vos estas inhabilitando a tu programa el recibir mensajes. Lo cual si aunque sea tarda un poco como para que la rutina RS232 pierda el valor de start ese dato se deberia descartar. Ahora imaginate esto con 2 UART, lo mas simple a hacer es:
PRINCIPAL:
CALL LEE_RS232_SOFT1
CALL LEE_RS232_SOFT2
CALL OTRAS_RUTINAS
GOTO PRINCIPAL
Y si.. pero ahora mientras recibe por mi primer UART por software, no va a estar recibiendo por la segunda. Por eso mismo decia que si no te importa perder datos. La solucion es crear una sola rutina que tenga en cuenta ambas entradas, que esto es lo complicado, pero.... volvimos al problema de antes!
Casos en los que esto NO te va a afectar es que:
- Sea unicamente el PIC quien decida cuando recibir, es decir que el PIC le avise el bluetooth o wifi o lo que sea que le envie datos y ahi recibirlos, pero que sino no envien nada.
- Tambien que lo unico que te importe sea transmitir. y no recibir.
Si por ejemplo el bluetooth/wifi/GSM ( que tengas conectado a la UART por soft) jamas pero jamas te va a enviar un dato sin que vos se lo pidas entonces adelante, pero recorda que mientras tengas que recibir no podes dejar de hacerlo o no te vas a poner a hacer otra cosa. No recuerdo como es que funcionan estos modulos, pero imagino que si alguien intenta por ejemplo parearse con el bluetooth deberia avisarle solo el bluetooth al PIC para que este responda. Con lo cual deberias estar "alerta". Pero como decia si el PIC actua como maestro y que unicamente va a recibir cuando este lo dicte, no tendrias problemas.
Otra forma de realizarlo es que tengas 2 UART por HW. Y una sola por Soft, entonces la recepcion podes moverla al PORTB,0 que tiene interrupcion por flancos y con un timer ver los tiempos ( en ves de delays) y hacer una maquina de estados. De esa forma las 3 recepciones estan realizadas por Interrupciones. Obviametne debera tener mayor prioridad la del PORTB,0 por los tiempos.
Podrias haber realizado lo mismo con el RB4 a RB7 y tener las 2 UART por soft ( siempre hablo de recepcion que es lo que presente complicacion ), Y actuar en consecuencia de la misma forma que antes. Espero que me entiendas a que me refiero.
La otra es que por ejemplo uses al menos 1 con otro tipo de comunicacion ( I2C, SPI ) siempre y cuando sea posible obviamente.
4º: que micro puedo conseguir que no sea smd, 40 pines....a y que pueda programarlo con el Pickit 2, con dos puertos seriales por HW, en donde vivo no hay mucha variedad, y si tubiera que pasar como decis a un 18f, podria seguir programandolo en asembler?
Acabo de ver la pagina de Microchip, y lamentablemetne en 8 bits no existe NADA actualmente con 2 UART y estan previsto como futuros lanzamientos micros con 2 UART y hasta con 5 UART
Aun asi casi todo SMD, que creo que te conviene mas si aprendes a usar el ICSP. ( No creo que lo soporte el Pickit2 eso si )
Pero tenes PIC24 que poseen 2 UART y son DIP, mas de 2 UART te vas a SMD. ( Seguro que varios de estos si le da soporte el Pickit2 )
Todos los PICs pueden ser programados en ASM, lo que si cambia la arquitectura, asi como en los PIC16 tenes bancos, en lso PIC18 tambien pero esta organizado de una forma mas lineal. Y en los dsPIC / PIC24 aun mejor , por ejemplo otro cambio el reloj del PIC24 y dsPIC se divide por 2 y no por 4 como en los PIC16/PIC18, aunque aumenta la complejidad y cambia bastante como es para realizar el ASM de micros de 16bits frente a los de 8bits, los de 16bits como se basa en gcc es algo mas "nominal" a otro ASM de otro micro ( atmel / ARM ) al menos en sus directivas. Pero si te compras una bestia de estas ni renegaria con ASM..
Aca un link cuando me puse a jugar con ASM en XC16, usando XC16 como base, lo cual me daba un par de ventajas. Y sin sobrecargas por que todo estaba realizado en ASM incluso le habia quitado al rutina de inicio de C.
http://www.todopic.com.ar/foros/index.php?topic=45240.msg376311#msg376311Resumiendo:
No es estrictamente necesario tener varias UARTs, solo tenes que tener en cuenta que esos problemas de tiempos pueden suceder, y la mejor forma de actuar es hacerlo a traves de interrupciones ( y no como el codigo que pasaste que usa delays ). Si transportas ese codigo a las interrupciones creo que vas a estar bien. Tambien intentaria usar una velocidad no muy grande en esas UART, en la de HW si. Y tratar de usar el micro con la mayor velocidad posible.
