PIC en protoboard con un MOLEX?

[pollastre]

Buenas,

hace cosa de un par de semanas me ha caido un "marron" en la empresa, en forma de nuevo proyecto que me han "adjudicado". Llevo muchos años programando en distintos lenguajes y entornos, pero es la primera vez que afronto algo que necesita manejar un soldador.... solicito vuestra indulgencia, pues, ante las tonterias que pueda preguntar   

Os resumo un poco el tema; tengo un dispositivo embebido que se comunica al mundo exterior a traves de dos puertos serie. Yo debo programar un circuito host que se comunique con dicho embebido, le mande ordenes y reciba las correspondientes respuestas, etc. Un PIC se ajusta como un guante a las necesidades de este proyecto.

No es requisito imprescindible acceder simultaneamente a los dos puertos serie del embebido, los accesos pueden ser secuenciales y excluyentes. Por lo tanto podria hacerse, bien conectando directamente los dos puertos series del embebido a los dos puertos serie del PIC, bien usando un MUX contra un solo puerto serie del PIC y seleccionando alternativamente la entrada (por favor, id corrigiendome si digo alguna barbaridad)

El factor critico de este proyecto es el espacio del circuito "host". Cuanto mas pequeño, mejor. Si me puedo ahorrar un MUX, me gustaria ahorrarmelo. Por cierto, que el embebido trabaja ya de por sí en niveles TTL, asi que asumo que no me hace falta max232 entre el embebido y el PIC ni nada por el estilo como en el caso de las conexiones PIC<->PC_RS232 .

Ahora es donde necesito vuestra ayuda:

- me ha parecido adecuado para este proyecto el 16F648. (4Kb de FLASH y con USART). ¿ Cómo lo veis vosotros? ¿ Os parece una elección adecuada o intenaríais buscar otro PIC?

- segun creo haber leido el 16F648 tiene un cristal interno capaz de funcionar hasta a 20Mhz. ¿Es fiable y seguro usarlo, o vosotros recomendais a pesar de todo seguir usando cristales exteriores con sus condesadores, etc? ( recordad que cuanto más me ahorre en espacio en el circuito, mejor... si es fiable el cristal interno, con ese me quedo! )

- esta es curiosa: el embebido se conecta al circuito host con un conector "board-to-board" molex de 80 pines ( podeis ver un ejemplo de un embebido que usa dicho conector en http://www.tdc.co.uk/technical/downloads/mc75_module.pdf , en la pagina 2 ).
Ahora, necesitaria poder conectar ese embebido a mi placa protoboard (ya sabeis, esta en la que se pinchan los integrados y los cables para probar los circuitos antes de hacer la PCB definitiva).
Esto sí que me parece un problema.... de donde diablos saco un adaptador de molex80 a placa entrenadora ? Necesitaria algo asi como un molex80 por un lado , y por el otro 80 "cablecitos" que pudiera pinchar en la placa, algo que me parece imposible.

El problema es que el dichoso modulo embebido se conecta al mundo exterior unicamente a traves del molex... y no veo forma de "pinchar" el molex en la protoboard...

El molex80 es demasiado pequeño (en mi opinion) como para andar haciendo soldaduras de cablecitos "a pelo"... aunque si no queda mas remedio.... ¿ a alguien se le ocurre alguna solucion ?


si pudierais ayudarme con alguna de estas cuestiones, la verdad es que me haciais padre... 

gracias y un saludo !

[maunix]

A ver que te puedo aconsejar,

- me ha parecido adecuado para este proyecto el 16F648. (4Kb de FLASH y con USART). ¿ Cómo lo veis vosotros? ¿ Os parece una elección adecuada o intenaríais buscar otro PIC?

El pic en cuestion tiene una sola USART.  Si las comunicaciones son lentas podrías implementar la segunda comunicación con una USART por software.

- segun creo haber leido el 16F648 tiene un cristal interno capaz de funcionar hasta a 20Mhz. ¿Es fiable y seguro usarlo, o vosotros recomendais a pesar de todo seguir usando cristales exteriores con sus condesadores, etc? ( recordad que cuanto más me ahorre en espacio en el circuito, mejor... si es fiable el cristal interno, con ese me quedo! )

No he usado ese pic en cuestión pero sí he usado otros pics con oscilador interno y te puedo decir que son 100% fiables y son la tendencia.  Muchos pics estan siendo reemplazados por sus hermanos casi idénticos con oscilador interno.  Ej. 18F452 --> 18F4520, 18F458 --> 18F4580, etc.

- esta es curiosa: el embebido se conecta al circuito host con un conector "board-to-board" molex de 80 pines ( podeis ver un ejemplo de un embebido que usa dicho conector en http://www.tdc.co.uk/technical/downloads/mc75_module.pdf , en la pagina 2 ).
Ahora, necesitaria poder conectar ese embebido a mi placa protoboard (ya sabeis, esta en la que se pinchan los integrados y los cables para probar los circuitos antes de hacer la PCB definitiva).
Esto sí que me parece un problema.... de donde diablos saco un adaptador de molex80 a placa entrenadora ? Necesitaria algo asi como un molex80 por un lado , y por el otro 80 "cablecitos" que pudiera pinchar en la placa, algo que me parece imposible.

Porque no armas tu circuito en el pcb directamente? Si tienes un programador que soporte ICSP (In Circuit Serial Programming) no necesitarías usar un protoboard. Yo no haría semejante adaptador si me lo puedo 'evitar'.  Con gran frecuencia los problemas suelen ser una mala conexión.

No he trabajado nunca con un conector como ese ni tampoco puedo verlo bien, pero se ve está diseñado para ser parte componente de otro equipo mayor.  En estos puntos,  no siempre es fácil hacerlo 'a mano' y tal vez requieras alguien especialista que te pueda embebe dicha placa sobre un PCB directamente.

Otro comentario, no se de que tiempo dispones pero si es poco y nunca programaste un microcontrolador, tal vez debas considerar subcontratar el trabajo.   Es solo mi opinión, tal vez algun otro tenga otra opinión al respecto.  Yo también vengo del mundo de usar varios lenguajes de programación: Pascal, C, Delphi, bases de datos , etc pero en PC y trabajar con microcontroladores difiere bastante.

Con lo que has dicho además te falta definir el protocolo de comunicación con el PIC y cualquier otro parámetro de configuración que quieras realizar a posterior.


Saludos

[Chaly29]

Hola pollastre, por el tema del PIC el 16F648 funciona muy bien, pero lamento informarte que no llega a los 20 MHz con el oscilador interno (8MHz máximo), por otra parte si bien el oscilador es estable no es muy recomendable usar este tipo de oscilador cuando estamos usando una transmición tipo RS-232, por lo que te recomendaría que uses un cristal para el oscilador.

Por otro lado si la necesidad de tener más pines es la que te lleva a no usar el cristal puedes reemplazar el F648 por otro  PIC con mayor cantidad, como los 16F870, 16F873 o 16F876.

Por el tema de las comunicaciones yo usaria una de ellas por medio del hardware y la otra por medio de software, pero claro, para saber si todo esto es posible hay que tener una idea de la función que habría de realizar el PIC, de esta manera conseguiras que la comunicación sea más segura que con un multiplexor. Otro tema a tocar es la velocidad a la cual se comunica tu modulo.

Con especto al uso de los protobard no se que aconsejarte ya que no tengo ni idea de que tan grande es o sería tu PCB final, si esta es chica yo tomaría el consejo de maunix, ahora si ya estamos hablando de un tamaño mayor habria que verlo.

Bueno, por el momento y solo con estos datos creo que ya podras estar mas orientado a tomar una decisión, un saludo.

Atte. CARLOS.

 

[pollastre]

Hola!

Muchas gracias por vuestras respuestas; os voy comentando mas o menos sobre la marcha....

(1)En efecto, he visto USARTS soft incluso para el "viejo" 16f84, y parecen funcionar sin problemas. Es un codigo sobradamente probado y supongo que sería cosa rápida el añadirlo a mi PIC. Entonces, por tu comentario de emular una segunda USART por soft, parece que el tema del multiplexor contra la USART hardware no te hace demasiada gracia. ¿ Desaconsejas entonces la solucion del MUX, finalmente, frente a la de hacerse una segunda USART soft ?

(2) el espacio en el PCB es crucial para este proyecto. Si el cristal es fiable y puedo ahorrarmelo en la PCB, fantastico. (por esta misma razon, quizas sea tambien bueno deshechar el tema del MUX externo y hacer la segunda usart por software, como decias, pues reduciria el circuito host practicamente al conector molex, el pic y unas pocas R's y C's).

(3) tu comentario ([maunix]) sobre la subcontratacion es muy juicioso, y en verdad, para un proyecto "a vida o muerte", no dudaría en hacerlo. Sin embargo, este proyecto está en fase de "veamos si es factible", así que me puedo permitir un poco de margen... vamos, que a pesar de todo yo ya he advertido claramente en la empresa que no es lo mismo programar o administrar S.O.'s , que la microelectrónica, así que no esperen que de la noche a la mañana les vaya a diseñar a RoboCop 

Ahora, eso sí, si el prototipo se demuestra factible para producción, seguramente haremos una tirada de unas 1000 unidades para empezar. Eso me lleva al segundo punto que quería comentar con vosotros... los PICs son "caros", y permitidme que explique esto: para el aficionado bsucando un circuito que le solucione alguna historia en su casa, que un PIC cueste 5 euros, 3 u 8 no es problema, pues practicamente solo comprará 1 o 2 para su circuito. Pero en una tanda de 1000 unidades, con un precio estimado del aparato completo en torno a 80 euros, entonces 5 euros arriba o abajo *si* son una gran diferencia. Por eso intento ajustar en lo posible el PIC elegido, pues he llegado a ver PICs que rondan los 10 euros, frente a otros, por ejemplo el 16F628, que me salen por 1,9 EUR (eso si, ese precio solo te lo dan cuando los compras de 1000 en 1000 !! )

Por esa misma razon, si puedo programar una USART en software en vez de pagar un PIC con dos USART hard, pues prefiero programarla. Digamos que busco el "minimo PIC que me sirva" para el proyecto (er... el mas barato?  ).

Por ultimo, respecto al tema del Molex... en efecto, su nombre completo es "Molex board-to-board 80pin connector", y sirve como tu bien dices para conectar una "pcb hija" a una "pcb host". Yo estoy desarrollando en este caso la "pcb host". Claramente ese patillaje escapa del ambito de las soldaduras aficionadas, asi que estoy buscando una empresa que me lo "clave" en la PCB de prueba...a ver que empresa soy capaz de encontrar aquí en España para que me haga esto. Claramente es el camino a seguir con este tipo de conectores...

un saludo y gracias por vuestras opiniones !

[Chaly29]

Hola pollastre, claramente te desaconsejo que uses un multiplexor por los motivo ya sitados.

Con respecto al coste de un PIC ya lo veras al comprarlo, pero en fabrica siempre son mucho más económicos, te recomendaría que visitaces la pagina de microchip: http://www.microchip.com y ahi tendras la lista de los precios de fábrica.

Otro asunto es el que un PIC alcance para alojar el programa que diseñes ya que si este es muy grande tendras que migrar a otro PIC de memoria de programa mayor y por supuesto será más costoso.

Con respecto a la transmisión de datos por medio de software es tan fiable como por medio de hardware, por lo tanto no debes de preocuparte de ese tema.

Con respecto al uso de cristales, ahora en el mercado los hay de muy pequeño tamaño, por lo que yo de mi parte no arriesgaria a usar el oscilador interno (no es de cristal, solo es un RC).

Si solo tienes que soldar 1 solo conector no creo que haya drama que una persona con experiencia lo haga, yo e soldados varias cosas del tipo SMD con buenos resultados y solo usando un soldador comun de buena calidad.

Un saludo.

Atte. CARLOS.

[pollastre]

cagoen... entonces el "famoso" oscilador interno de los PIC mas nuevos, es un oscilador tipo RC ? no es un cristal ? ay ay... y yo que creia que era un cristal !

Si es un RC entonces no me conviene usarlo, me temo....

[maunix]

por otra parte si bien el oscilador es estable no es muy recomendable usar este tipo de oscilador cuando estamos usando una transmición tipo RS-232, por lo que te recomendaría que uses un cristal para el oscilador.

Carlos, porqué opinas que no es confiable usar un cristal interno si además usas la USART?

Yo tengo un 18F4580 funcionando con el oscilador interno a 32Mhz con usart a 57600 y anda fenómeno desde hace meses.

De todas formas, me interesaría saber sobre que te basas para decir esto, tal vez sea algo que se me haya pasado por alto. 

En el datasheet del 16F648A, en la primer hoja dice dice:
Precision Internal 4 MHz oscillator factory calibrated to ±1%

más adelante luego dice

and INTOSC is a selfcontained precision two-speed internal oscillator.

No he leído que sea un RC.   

Saludos

[maunix]

Me alegro, si es un proyecto que se hará por miles tal vez sea buena decisión elegir el más económico.

Los más económicos también suelen estar dotados de pocas cosas, entre las cuales está la poca memoria ram y rom.

Si los programas en C,  pronto tendrás algún que otro inconveniente de llenado de memoria dependiendo de la complejidad de tu software.

Si los programas en ensamblador, te llevará mucho tiempo ponerlo a punto aunque el software de seguro ocupará mucho menos que en C.

Es tu decisión y deberás evaluar montones de parámetros que solo tu conoces y hasta debieras prorratear el 'costo de desarrollo'  o las horas de ingeniero puestas en cada dispositivo que vendas.

Ejemplo:

Si tu pic vale 2 euros y vendes 1000 (te habrán salido 2000 euros).
Si además tardaste 1 mes en hacer el proyecto y tu sueldo es también de 1000 euros, entonces cada pic se lo debiera sumar dicho costo

El costo total sería de 3000 euros, divido 1000, serían 3 euros de costo por placa

Si lo programas en ensamblador, de seguro te llevará más tiempo por lo cual a pesar de poder elegir un pic más económico el costo real del proyecto será más caro.

Ahora si haras miles de miles, la hora de ingeniero se diluye más.... es cuestión de hacer los números y no me quiero meter en eso, solo quiero aclarar que estas cuentas o números son específicos de cada proyecto. 

Hay proyectos que los hice en un pic pequeño y en ensamblador porque se harían miles.  Y otros proyectos que los hice en C proque primaba resolverlo rápido aunque el pic sea más costoso porque en el global iba a ser más ventajoso de esa forma.

(1)En efecto, he visto USARTS soft incluso para el "viejo" 16f84, y parecen funcionar sin problemas. Es un codigo sobradamente probado y supongo que sería cosa rápida el añadirlo a mi PIC. Entonces, por tu comentario de emular una segunda USART por soft, parece que el tema del multiplexor contra la USART hardware no te hace demasiada gracia. ¿ Desaconsejas entonces la solucion del MUX, finalmente, frente a la de hacerse una segunda USART soft ?

Con respecto a las usart por soft es un tema a analizar.

Si la usart es "interrupt driven" o manejadas por interrupción, seguramente tendrá utilizando algun timer el cual irá chequeando la entrada del pin de la usart por software cada un determinado tiempo, el cual será no menos que 4 a 8 veces más rapido que el baudeaje de la usart.  Si la usart es de 1200 bps, el muestreo seguro se hará a 4800 o a 9600 ciclos por segundo.

Si no hay superposición entre la usart por soft y hard y además no necesitas dicho timer, no habrá inconvenientes.

Si hay superposición puede ocurrir el caso en que pierdas algún dato o sea mal interpretado por lo que mencioné antes.  Imaginemos que el pic está atendiendo una interrupción de USART por hardware y tu rutina de atención no está bien depurada y se demora un tiempo excesivo y luego al volver al bucle principal tal vez ya hayas perdido un byte que venía por la usart por software.

Es solo un ejemplo.

Una usart por software funciona siempre que se tenga en cuenta sus limitaciones.

Saludos

[Nocturno]

También he usado comunicaciones serie con oscilador interno sin problemas.

[Chaly29]

Hola maunix, sencilla mi respuesta en que me baso para decir que tiene oscilador RC, porque en el chip de silicio intreno colocarle una resistencia o un condensador es facil, pero ponerle un cuarzo ua es casi que imposible, tanto por el tamaño como por que este deberis estar en su propia capsula.

Aparte, no me acuerdo que datasheet eran si que era de un PIC más viejito, pero en este si lo explicaba diciendo que era un oscilador del tipo RC, incluso para calibrarlo tenias que hacerlo por software y no venia de fabrica como ahora.

Ahora analicemos la frese que me colocaste:

Precision Internal 4 MHz oscillator factory calibrated to ±1%

Yo interpreto que el oscilador interno esta calibrado con una precision del 1%, pero eso no quiere decir que ese mismo oscilador tenga un desviamiento máximo del 1%, por lo tato en la practica la frecuencia entregada por el oscilador podria estar incrementada en error.

Tampoco digo que no se pueda usar el oscilador interno y la USART, de hecho tu mismo y el amigo nocturno estan confirmando que sí, pero deberemos tener en cuenta que a mayor numero de baud tengamos en nuestra comunicacion tambien estamos elevando la relación error/periodo entre el error del oscilador y el periodo de la señal de la comunicacion, por consiguiente tambien estamos elevando las posibilidades de que la comunicación falle, y en una tanda de 1000 productos no es un tema para descartar.

Ojo, esto que comento no es algo que yo haya inventado, en varias aplicaciones e visto que recomiendan en el caso de usar la USART tambien usar un cristal y no el oscilador interno, por el motivo que yo cito.

Bueno, espero se me entienda la explicacion, un saludo.

Atte. CARLOS.

 

[pollastre]

Buscando un poco por ahí al hilo del tema este de clock interno, he encontrado un documento que parece soportar la tesis de que el oscilador interno tiene una pequeña desviación de precisión con respecto a un cristal externo:

http://www.rentron.com/PIC16F628.htm

tienes que irte hacia el final del documento, donde el autor compara la salida en un osciloscopio de un circuito usando el oscilador interno del 16F628 contra el mismo circuito usando un cristal externo, y termina diciendo que en "aplicaciones muy criticas en el tiempo *quizás* desearías usar un oscilador externo en vez del interno".
¿ Será esto producto del 1% de margen de error descrito en la documentacion del pIC para el int_clk ?

un saludo,

[MSK]

Hay que leer en los excelentes datasheet de microchip, donde esta toda la informacion de desviacion del oscilador interno RC, en forma de graficas con respecto a temperatura y voltaje.. como todo "rc" no

[jfh900]

Bueno, creo que se ha olvudado algo importante a la hora de desarrollo de un proyecto, y es que hay que realizar una inversión mínima. Haber si por ahorrar costes vas a montar el circuito encima de un carton y soldando los cables por debajo. Si de verdad existe la posibilidad de montar un numero relativamente importante de circuitos debeis de plantearos gastar algo de dinero en el desarollo. En primer lugar comprar varios micros de diferentes configuraciones y en segundo lugar comprar unos cristales y hacer la prueba de cual fuenciona mejor, si con cristal o sin cristal. S por cualquier ciscustancia el microse te queda corto, podras pasar al siguiente de la gama si le habeis comprado y no esperar a tenerle, inclusive se puede comparar determinados aspectos del software en función de los distintos micros, ya que el propio hadware puede solucionar parte de la programación.

Por lo tanto mi consejo es que si quieres ahorrar en la explotacion de un producto, primero tienes que invertir y asegurarte de que el producto funcionara bien bajo todas las circustancias. Si no puede suceder que una vez fabricado el producto no funcione o lo haga de forma deficiente y haya que cambiarlo. Esto biene al hilo que la compra de un cristal de cuarzo no es para arruinarse, asi como la compra de tres o cuatro micros.

Un saludo.

[pollastre]

No, si en el tema de la inversión estoy de acuerdo contigo... el asunto con el cristal, si ves en mi primer post, no es por una cuestion economica, sino de superficie en placa. Como comentaba, el factor critico de este proyecto es el tamaño de la PCB (por supuesto que el precio es importante, pero el tamaño en esta ocasion es prioritario).

Por eso contemplaba la posibilidad de no usar cristal externo, unicamente por reducir al minimo posible el tamaño de la pcb... pero vamos, que si hay que meterle el cristal y sus dos C's pues se le meten , que le vamos a hacer!

un saludo,

[jfh900]

Cuando el tamaño es un problema, se puede realizar la placa con SMD y dejarla tan reducida como quieras.

Un saludo.