TODOPIC
Microcontroladores PIC => Primeros pasos - Iniciación a los microcontroladores => Mensaje iniciado por: pollastre en 28 de Mayo de 2006, 11:18:09
-
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 :shock:
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 !
-
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
-
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.
-
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 8)
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? :P ).
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 !
-
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.
-
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....
-
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
-
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
-
También he usado comunicaciones serie con oscilador interno sin problemas.
-
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.
-
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,
-
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
-
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.
-
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,
-
Cuando el tamaño es un problema, se puede realizar la placa con SMD y dejarla tan reducida como quieras.
Un saludo.
-
Amigos, el generador de baudeaje de la usart se inicializa con cada nuevo byte que se transmiten.
Tener un error del 1% o del 5% no le hace NADA.
El otro lado siempre muestrea a 8 o 16 veces mas rapido que el baudeaje utilizado. Esa es la forma en que funcionan las usart y en que debieramos hacer una usart por software si nos tocara hacerlo.
Entonces, si tenemos una desviacion del 5% el otro lado JAMAS se enterara y funcionara de maravillas.
No veo porque tanto terror de usar el oscilador interno! De hecho todos los micros estan viniendo en dicho formato y es una tendencia que continuara.
Para que mayor precision para la usart y utilizar un cristal externo? Respeto todas las opiniones pero sencillamente no le veo el sentido, al menos no para una usart. Si me dicen para medir tiempo con precision del 0,0001% vaya y pase....
En fin, es solo mi opinion.
Saludos
-
Hola maunix, entonces trata de hacer una comunicacion entre 2 PIC a un baud rate de 9600 con el oscilador internoa a 4MHz (el mayor) dejalo funcionando en ambientes distintos, y despues me cuentas.
Un saludo.
Atte. CARLOS.
-
Hola maunix, entonces trata de hacer una comunicacion entre 2 PIC a un baud rate de 9600 con el oscilador internoa a 4MHz (el mayor) dejalo funcionando en ambientes distintos, y despues me cuentas.
Un saludo.
Atte. CARLOS.
Carlos, tampoco es que me voy a poner a armar un circuito para poder probar cada cosa que pongo en un post. Me parece bárbaro pensar diferente a otra persona y respeto las opiniones de todos pero he aquí mi pensamiento.
Lo que sí digo es que tengo una aplicación que corre en un ambiente de Radio Frecuencia con amplificadores de potencia, motores paso a paso, grandes consumos y donde el que gobierna todo es un 18F4580 corriendo a 32Mhz con el cristal interno.
Con la usart he usado 57600 y la he bajado a 19200 (en la que está actualmente ahora) simplemente porque no necesitaba más velocidad pero aclaro que en 57600 funcionaba perfecto.
El equipo se reporta con una PC constantemente y mayor velocidad significaba que la PC tenga que actualizar más rápdo los valores lo cual es totalmente innecesario (para mi aplicación) y reduciendo la velocidad puedo ver como varían ciertos parámetros bien.
Esa aplicación esta corriendo hace más de 6 meses sin problemas.
De todas formas, no vengo acá a convencer a nadie, pero de lo que estoy seguro es que un 1% o un 5% (para exagerar bien) de corrimiento de referencia del resonador de una usart no hará cambiar la comunicación y se efectuará tan bien como siempre.
Microchip claramente dice que el oscilador es interno (no se si es un RC, pero si es un RC no será un RC como los componentes discretos que uno coloca externamente). Es un oscilador compensado en temperatura y tensión que permite una precisión de un 1% lo cual es más que suficiente para la gran mayoría de las aplicaciones. Y a mi entender para el 100% de las aplicaciones que usen una comunicación serie asíncrona.
Nuevamente, a mi entender, (lo aclaro ya que no quiero generar polémica, simplemente exponer mi punto de vista) si hay problemas con la comunicación con un PIC con cristal interno en diversos entornos será porque también los habría si fuera con un cristal externo.
En las comunicaciones que establezco, siempre hago algún tipo de chequeo tipo checksum o crc, no dejo librado a la comunicación la transmisión así porque sí. Esto lo vengo haciendo desde siempre y jamás tuve problemas con ningún hardware que he armado en este aspecto. Ya sea usando RS232 o RS485.
Pero como dije antes, es solo mi opinión.
Saludos
-
por cierto, y relacionado con esta historia que estoy intentando.... alguien me podria por favor aclarar la siguiente duda (ver imagen adjunta) ;
parece tratarse de un switch mediante transistor a colector comun, que sirve para controlar el encendido de un led. Entiendo que la resistencia de 10K de más a la izquierda es necesaria para controlar la I(b) que le llega a la base del transistor, Pero no entiendo demasiado bien para qué sirve la resistencia que he rodeado con un circulo rojo, la de 10K. Alguien podría aclararmelo ?
muchas gracias y un saludo,
-
Las dos resistencias de base, forman un divisor de tensión, como son iguales la tensión de entrada es dividida a la mitad.
Un saludo.
-
Hola pollastre, en ese caso no es de mucha importancia si esta o no esa resistencia, ya que lo unico que comanda es un LED, pero en otros, donde la velocidad de conmutacion es un factor crusial esa resistencia lo que hace es descargar a masa la tension remanente que guarda la base del transistor, como es sabido la bese de un transistos se comporta como un condensador de muy pequeño valor, por lo que al momento de cortar la alimentacion del pn del PIN, este seguira conteniendo una carga que producira que el transistos siga conduciendo un periodo de tiempo mayor al deseado, con la resistencia que tu señalas esa carga es disipada a masa con lo que el periodo extra que el transistos esta conduciendo se reduce muy notablemente.
De lo anterior se deuce que como ya lo e dicho en este caso no es de mucha importancia pero en circuitos que trabajan en modo swichig y a frecuencias altas es de mucha necesidad.
Espero se me haya entendido, un saludo.
Atte. CARLOS.
-
perfectamente, charly29... digamos que en el caso de que el led parpadease intermitentemente a una frecuencia alta (digamos, varias veces por segundo) la resistencia de descarga empezaría a hacerse importante (y casi necesaria) para que el led reflejase lo más fielmente posible los tiempos de saturacion y corte del transistor...
muchas gracias por la explicacion !
-
Hola pollastre, algo como lo que tu dices es lo que quise decir, pero frecuencias altas son por lo menos a partir de 5 KHz, por ese motivo comento que en un led no es necesario.
Un saludo.
Atte. CARLOS.
-
disculpad, una cuestion que me ha surgido.... uno de los ICs que uso tiene 5 patillas de Vcc con sus 5 patillas de GND (supongo que por razones de consumo del propio IC). Por supuesto dicho IC requiere condensadores de desacoplo, ahora bien, mi duda es la siguiente : cual es en vuestra opinion la mejor opcion para esto ? yo barajo dos :
1) un unico condesador de desacoplo para las 5 Vcc's
2) cada patilla Vcc con su propio condensador de desacoplo
por coste y por espacio, evidentemente (1) gana. Sin embargo, si por alguna casualidad, varias de las Vcc's requiriesen *simultaneamente* un aporte de intensidad mayor durante algun transitorio (que es una de las dos utlidades de los condensadores de desacoplo), tal vez un unico condensador comun no bastaría para alimentar la demandad puntual. Qué opinanis ?
garcias por la ayuda !
-
Hola si dispones del datasheet del IC seguro te dira que necesidades de desacoplo tiene, pero mi opinion es si son 5 pines ponele en 2 o 3 minimo, seguro es un IC bastante complejo...
-
pollastre yo que tu pondria un desacoplo en cada pin de alimentacion, esto como regla general. Incluso en los pics que tienen 2 pines de alimentacion, sigue el mismo consejo.
Saludos
-
sea pues como vosotros decis.... 5 x 10nF condensadores de desacoplo, y mejor no arriesguemos :P
saludos !
-
sea pues como vosotros decis.... 5 x 10nF condensadores de desacoplo, y mejor no arriesguemos :P
Eso andará, pero lo "típico" es 100nF ó más comunmente llamados .1uF
-
disculpa, tienes toda la razon, me equivoqué y escribí 10 en vez de 100nF...
por cierto, que tengo por aqui algo de documentacion donde incluso van mas lejos y recomiendan poner en paralelo al ceramico de 100nF un tantalum de capacitancia inferior al tipico de 100nF (no recuerdo cual era el valor exacto ahora mismo)... eso ya me hace 5Vcc x 2 condensadores = 10 condensadores de desacoplo para el IC, vamos, que al final me voy a jartar de poner condensadores :mrgreen:
gracias y saludos!
-
disculpa, tienes toda la razon, me equivoqué y escribí 10 en vez de 100nF...
por cierto, que tengo por aqui algo de documentacion donde incluso van mas lejos y recomiendan poner en paralelo al ceramico de 100nF un tantalum de capacitancia inferior al tipico de 100nF (no recuerdo cual era el valor exacto ahora mismo)... eso ya me hace 5Vcc x 2 condensadores = 10 condensadores de desacoplo para el IC, vamos, que al final me voy a jartar de poner condensadores :mrgreen:
gracias y saludos!
Los capacitores de tantalio son con polaridad, al igual que los electrolíticos pero entregan la corriente más rápido y son muchisimo mejores a alta frecuencia! (los electrolíticos directamente NO sirven para alta frecuencia).
En cuanto a que ahora tengas que usar muchos capacitores.... jeje, solo puedo decirte "bienvenido al mundo real" :) :)
También me sorprendí al usar tantos por primera vez pero es la única forma. Es por eso que vienen también ristras de capacitores todos en un solo encapsulado con varios pines, para este tipo de cosas.
Muchos éxitos y Saludos
-
perdonad de nuevo, pero al respecto de las multiples Vdd de alimentacion en los ICs, leyendo el datasheet del 16F648A acabo de darme cuenta de que el formato SSOP-20 (que es el que planeo utilizar como SMD) tiene DOS pines de Vdd, con sus correspondientes dos pines Vss, a diferencia del paquete PDIP, el de "pinchar de toda la vida", que solo tiene un unico Vdd y Vss.
Esto me deja un poco confundido. Por qué en formato SSOP hay dos Vdd? Debo alimentar las dos? Y si es asi, supongo que las dos deberan llevar sus correspondientes capacitores de bypass, claro.....
gracias y saludos,
-
perdonad de nuevo, pero al respecto de las multiples Vdd de alimentacion en los ICs, leyendo el datasheet del 16F648A acabo de darme cuenta de que el formato SSOP-20 (que es el que planeo utilizar como SMD) tiene DOS pines de Vdd, con sus correspondientes dos pines Vss, a diferencia del paquete PDIP, el de "pinchar de toda la vida", que solo tiene un unico Vdd y Vss.
Esto me deja un poco confundido. Por qué en formato SSOP hay dos Vdd? Debo alimentar las dos? Y si es asi, supongo que las dos deberan llevar sus correspondientes capacitores de bypass, claro.....
gracias y saludos,
La respuesta corta es SI, debes unir todos los pines Vdd y Vss que tenga un pic.
La respuesta larga, fijate en este link donde se habló del tema.
Como dije en dicho post, si no entiendes algo del inglés avisame y te lo traduzco.
http://www.todopic.com.ar/foros/index.php?topic=11605.0 (http://www.todopic.com.ar/foros/index.php?topic=11605.0)
Saludos
-
clarito clarito como el agua.... muchas gracias por el link amigo !
saludos
-
Buenas,
aquí os presento mi primer circuito con un PIC, concretamente un16F648A. A ver si alguien puede decirme por favor si las dos entradas Vdd están correctamente desacopladas, pues la verdad es que no he encontrado por ahi ningun circuito de ejemplo con varios pines de potencia desacoplados, aun cuando sí hay documentos que recomiendan desacoplarlos todos y cada uno... yo lo he hecho de esta manera, es correcto ?
gracias !
pd: disculpad que el circuito no se vea muy bien, forma parte de un circuito mas grande y os he recortado/arreglado esta parte para que podais verla con algo de claridad... de ahi que aparecen algunas imperfecciones.
-
Si , está bien. Aunque en casos en que ambos pines de alimentación estén de un mismo lado, no creo que cambie mucho ponerle 2 capacitores a ponerle solo 1.
Usar varios capacitores para un mismo IC, se hace gralmente cuando los Vdd y Vss están bastante separados, pero no hay 'reglas' para esto, así como lo has hecho está bien.
Saludos
-
Hola.
tengo un par de dudas que seguramente sabreis resolverme...
la primera es sobre las comunicaciones serie y el oscilador interno: hace poco tiempo hice un pequeño proyecto de comunicacion via infrarrojos utilizando en el receptor un 12f629, y por mas que lo intente no consegui hacerlo funcionar adecuadamente si no usaba un cristal externo, y eso con una velocidad de tan solo 2400bps... tan sencillo como que si conectaba el oscilador externo -llegue a realizar una pequeña pcb con un cuarzo y sus condensadores que ponia o retiraba para probar- funcionaba y sino no. y, si, tambien cambiaba la palabra de configuracion para indicarle el modo... cuando lei en un post del foro que con oscilador interno mejor olvidarse de las comunicaciones di por zanjada la cuestion. este nuevo post recupera mis dudas
ahora tengo algo similar con un 12f675 y me vendria de perlas contar con los 2 pines del oscilador... en fin, de vuelta a la pelea... se os ocurre alguna otra cosa? decir que los receptores con cristal externo estan funcionando sin problemas y descarto por tanto problemas de software.
la segunda cuestion es que suelo utilizar los condensadores de desacoplo en todos los casos, y la pregunta es: conviene usarlos tambien cuando la alimentacion es una bateria o pilas o en este caso no son necesarios?
muchas gracias por vuestro tiempo y un saludo
-
Hola.
tengo un par de dudas que seguramente sabreis resolverme...
la primera es sobre las comunicaciones serie y el oscilador interno: hace poco tiempo hice un pequeño proyecto de comunicacion via infrarrojos utilizando en el receptor un 12f629, y por mas que lo intente no consegui hacerlo funcionar adecuadamente si no usaba un cristal externo, y eso con una velocidad de tan solo 2400bps... tan sencillo como que si conectaba el oscilador externo -llegue a realizar una pequeña pcb con un cuarzo y sus condensadores que ponia o retiraba para probar- funcionaba y sino no. y, si, tambien cambiaba la palabra de configuracion para indicarle el modo... cuando lei en un post del foro que con oscilador interno mejor olvidarse de las comunicaciones di por zanjada la cuestion. este nuevo post recupera mis dudas
ahora tengo algo similar con un 12f675 y me vendria de perlas contar con los 2 pines del oscilador... en fin, de vuelta a la pelea... se os ocurre alguna otra cosa? decir que los receptores con cristal externo estan funcionando sin problemas y descarto por tanto problemas de software.
la segunda cuestion es que suelo utilizar los condensadores de desacoplo en todos los casos, y la pregunta es: conviene usarlos tambien cuando la alimentacion es una bateria o pilas o en este caso no son necesarios?
muchas gracias por vuestro tiempo y un saludo
Habría que ver bien cual es tu problema con esa comunicación que mencionas. Jamás he tenido inconvenientes usando el cristal interno y eso que he desarrollado comunicaciones a 57600bps.
No se si se justifique hacer un gráfico con esquemas y mostrando como funciona una usart en modo asíncrono para que entendamos que no es un tema importante tener un error de un 1% o un 5%.
¿Tu estas haciendo una comunicación síncrona o asíncrona?
Respecto a los capacitores, si usas una batería no necesitaras capacitores de 'desacoplo' (los electrolíticos de gran valor) pero siempre serán útiles los de .1uF entre Vdd y Vss al lado de los pines respectivos en tu pic. Esto responde a la necesidad de entregar corriente rápidamente cuando el pic lo requiera.
Saludos
-
hola y gracias maunix
veras, el codigo que utilice de prueba es algo tan sencillo como lo que te expongo a continuacion:
'*****************************
' Codigo del Transmisor
'*****************************
include "modedefs.bas"
define OSC 4
trisa = %00011
trisb = %00000000
porta = 0
portb = 0
bot_1 var porta.0
bot_2 var porta.1
loop:
if bot_1 = 0 then gosub led_on
if bot_2 = 0 then gosub led_off
goto loop
led_on: serout portb.1,n2400,[$FF,$FF,"OK","A"]
return
led_off: serout portb.1,n2400,[$FF,$FF,"OK","B"]
return
end
'**********************************
' Codigo del Receptor
'**********************************
include "modedefs.bas"
define OSC 4
@ DEVICE pic12F629, 0x1FC1
TRISIO=%001001
CMCON=%00000111
GPIO = 0
datos var byte
led_rojo var GPIO.1
led_verde var GPIO.2
Loop:
serin gpio.0,t2400,["OK"],datos
If datos="A" then gosub led_on
if datos="B" then gosub led_off
goto Loop
led_on: High led_rojo
low led_verde
return
led_off: low led_rojo
high led_verde
return
end
*************************************
en el emisor un 16f84a y en el receptor un 12f629 y tal como decia antes con oscilador a cristal todo perfecto y sin el ninguna respuesta de los leds... y seria genial poder evitarlo, por espacio y por economia
en cuanto a subir esquemas o una definicion mas clara del proyecto tendria que solicitar permiso puesto que es un proyecto para una instalacion de arte y los artistas tienen un concepto bastante acentuado de lo que supone copiarse las ideas unos a otros. si te puedo decir que implica el uso de algo mas de cincuenta (si, 50) pics interrelacionados unos con otros en algunos casos y actuando por libre en otros y que siento enormemente no conocer otro lenguaje que no sea basic por cuestiones de velocidad.
podeis contar que si dispongo del permiso subire bastantes cosas que me supusieron un reto y creo que pueden ayudar a otros compañeros, a mi me esta sirviendo para aprender un monton de cosas en este mundillo de pics tan reciente para mi.
gracias de nuevo y un saludo
pd: perdona pollastre que no pretendo desplazar tu consulta inicial, y desde aqui te digo que mucho animo y que estas en el foro adecuado. salu2
-
xocas06 no he usado nunca el basic, y no conozco sus limitaciones y/o cosas a tener en cuenta al momento de usar esas rutinas.
¿Puede ser que tengas que definir en algún lado el clock del PIC? Digo esto porque he de suponer que es una usart por software y tal vez estés seteando mal el clock al usar el interno.
Saludos
-
gracias maunix
no te preocupes porque seguramente es algo que tengo delante y no consigo ver...
y si, la comunicacion es por software -la determinan los comandos serout y serin- y hasta ahora lo unico que he visto para determinar la velocidad del oscilador es el comando device osc 4 y los ajustes de configuracion del propio pic pero con todo eso ya me pelee en su dia y la verdad me da un poco de verguenza repetir una consulta que tambien ya hice en su dia...
un saludo y de nuevo gracias...
-
gracias maunix
no te preocupes porque seguramente es algo que tengo delante y no consigo ver...
y si, la comunicacion es por software -la determinan los comandos serout y serin- y hasta ahora lo unico que he visto para determinar la velocidad del oscilador es el comando device osc 4 y los ajustes de configuracion del propio pic pero con todo eso ya me pelee en su dia y la verdad me da un poco de verguenza repetir una consulta que tambien ya hice en su dia...
un saludo y de nuevo gracias...
Es probable que sea algo simple de ver y que por ahora no lo puedas ver. Si tienes osciloscopio podrias probar algo simple como por ejemplo hacer una salida por un pin todo el tiempo conmutando y ver cuanto tiene de ancho dicha señal.
Más allá que en ensamblador eso se hace con una sola instrucción tal vez puedas hacer lo mismo con el basic y obtener resultados 'comparativos'.
Entonces, si haces por ejemplo
1) SALIDA en ALTO
2) SALIDA en BAJO
3) Volver a 1
Debieras medir los anchos de pulsos.
Estas mediciones las comparas usando el oscilador externo y el interno del pic. Si las mediciones son similares entonces el problema está en otro lado. Si difieren bastante es para preocuparse ya que estariamos hablando de que tu pic oscila a una frecuencia muy diferente a la esperada cuando utilizas el oscilador interno.
En cuanto a que te de vergüenza preguntar algo de nuevo.. pues bien, se me ocurren 2 razones.
1) que te respondieron erróneamente o bien no te satisfizo la respuesta
2) que no sepas o no recuerdes cual era la respuesta.
Si la razón es la 1ra y sabes donde hiciste dicha pregunta, pues vuelve a preguntar debajo de ese mismo hilo diciendo que no entendiste y te volveran a responder para aclarar tus dudas
2) puedes pedir que te ayuden a buscar el topic del que estas solicitando información o bien volver a hacer la pregunta (si consideras que es una pregunta relevante).
Saludos
-
hola maunix
ante la carencia de osciloscopio y partiendo de la base de que era posible hacerlo segui indagando aqui y alla hasta que por fin he dado con la respuesta. en pbasic se ha de añadir la linea DEFINE OSCCAL_1K 1 para que el oscilador interno vaya a la frecuencia correcta.
yo creia que simplemente restaurando el valor del OSCCAL e indicandole en pbasic la instruccion DEFINE OSC 4 era suficiente pero por algun motivo no es asi, tratare de verlo con mas calma cuando pueda. tambien encontre mas informacion en microchip: http://ww1.microchip.com/downloads/en/DeviceDoc/31002a.pdf donde en las paginas 14 y 15 se habla del desvio de frecuencia del oscilador interno -que al final no deja de ser un oscilador RC- y este otro enlace tambien es interesante: http://ww1.microchip.com/downloads/en/AppNotes/00250a.pdf
en cuanto a la verguenza... veras, para empezar creo recordar que hice la consulta en el hilo equivocado. las respuestas que obtuve ya las habia probado anteriormente. no disponia de mucho tiempo para entregar el trabajo y el oscilador a cristal fue un 'mal menor'. ademas lei por aquellos dias un post en el que se decia que oscilador interno y comunicaciones serie mejor olvidarse, asi que me olvide. tambien que soy de las personas que no rechazan una ayuda sino todo lo contrario, pero tampoco quiero que me lo den todo masticado porque mi primera intencion es aprender
gracias por tu tiempo maunix
-
hola maunix
ante la carencia de osciloscopio y partiendo de la base de que era posible hacerlo segui indagando aqui y alla hasta que por fin he dado con la respuesta. en pbasic se ha de añadir la linea DEFINE OSCCAL_1K 1 para que el oscilador interno vaya a la frecuencia correcta.
yo creia que simplemente restaurando el valor del OSCCAL e indicandole en pbasic la instruccion DEFINE OSC 4 era suficiente pero por algun motivo no es asi, tratare de verlo con mas calma cuando pueda. tambien encontre mas informacion en microchip: http://ww1.microchip.com/downloads/en/DeviceDoc/31002a.pdf donde en las paginas 14 y 15 se habla del desvio de frecuencia del oscilador interno -que al final no deja de ser un oscilador RC- y este otro enlace tambien es interesante: http://ww1.microchip.com/downloads/en/AppNotes/00250a.pdf
en cuanto a la verguenza... veras, para empezar creo recordar que hice la consulta en el hilo equivocado. las respuestas que obtuve ya las habia probado anteriormente. no disponia de mucho tiempo para entregar el trabajo y el oscilador a cristal fue un 'mal menor'. ademas lei por aquellos dias un post en el que se decia que oscilador interno y comunicaciones serie mejor olvidarse, asi que me olvide. tambien que soy de las personas que no rechazan una ayuda sino todo lo contrario, pero tampoco quiero que me lo den todo masticado porque mi primera intencion es aprender
gracias por tu tiempo maunix
xocas06 me alegro lo hayas solucionado.
En este mismo hilo (en las páginas anteriores) yo decía casualmente lo contrario, en que el oscilador interno por más desviación que tenga no puede afectar a una comunicación usart asíncrona.
En fin, algunos pensarán que sí, otros pensarán alineados a mi idea, de todas formas, no por ser mayoría se tiene la razón, ¿verdad?
Siempre pienso en postear con mayor detalle, gráficas, etc, pero la falta de tiempo impide a veces elaborar un tema con tanta precisión. Algún día postearé algún ejemplo con gráficas, donde explique porqué pienso de esa manera :) con respecto al oscilador interno vs usart asíncrono o simplemente uart :)
Saludos