|
|
Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.
Mensajes - ADC
Páginas: [1]
1
« en: Domingo 17 de Agosto de 2008, 20:58 »
P.D. que se me pasan unos comentarios muy importantes.
He hablado de la tendencia a Linux embebido (tambien existe .NET micro framework, Windows CE y otros). Por ejemplo ya hay mucha gente haciendo su software no solo en C y C++, sino en C# ,Java, Phyton, Ruby, etc,(Linux permite eso por ejemplo), al final son las cuentas las que mandan, si el tiempo de desarollo es caro y el hardware barato, manda el tiempo de desarollo.
Saludos
2
« en: Domingo 17 de Agosto de 2008, 20:51 »
Mayor dificultad para integrar tu codigo con un sistema operativo: esto esta relacionado directamente con la eficiencia, ya que si no podemos utilizar un sistema operativo, muy buenos y listos tenemos que ser para que nuestro programa en ASM sea capaz de ejecutar eficientemente (sin esperas activas, con tiempos de respuesta controlados, aprovechando de forma dinámica los modos de bajo consumo....) varios procesos simultaneamente. Ademas la API de los SO siempre es en C.
Por que ninguna empresa te va a pedir que programes en ASM: quizás te pidan en la oferta de trabajo que sepas ASM, pero despues es muy raro programar algo en ASM, así, que para el caso, como la mayoria estais aprendiendo, deciros que lo mas problable es que si llegais a trabajar en desarrollo de sistemas embebidos nunca utilizareis ASM.
Por que la tendencia en sistemas embebidos son los sistemas con Linux embebido: es la tendencia, cada vez son mas baratos, en pocos años por el precio de PIC podrás comprar un micro capaz de mover Linux (hay ARM de 3€ y pico capaces), esto no es "usar Linux por que si", usar un SO tan avanzado permite implentar facilmente una series de funcionlidades en nuestros dispositivos que hace unos años no pensabamos que fuese posible.
Bueno, de todas formas tambien quiero dejar claro que existe la posiblidad de que una determinada aplicación se tenga que usar ASM. Despues de tanto rollo no he comentado una cosa que en realidad es la clave, la decisión de si se va utilizar ASM o C en un produto se toma siempre como resultado de un estudio economico del proyecto, así que en determinados casos puede resultar la opcion adecuada. Lo que pasa es actualmente siempre se quiere mucha funcionalidad en el sistema, y esto hace que ASM siempre pierda, por su mayor tiempo de desarrollo sobre todo.
Resumen:
mas funcionalidad = mas codigo
tiempo desarrollo ASM = 10*tiempo desarollo C
tiempo de desarrollo = coste, +competencia
C es reusable
ASM no es reusable
ASM mala integracion con SOs
escasa diferencia de precios entre micros mas y menos potentes
Saludos,
adc
3
« en: Domingo 17 de Agosto de 2008, 20:27 »
Imagina que vamos ha hacer 2000 sistemas y tenemos dos opciones , hacerlo que un PIC de 2€ en ASM o con un ARM de 4€ en C. Supon que el tiempo de desarrollo en C es de un mes. Pues si haces cuentas, y ves que ASM tardarás 10 veces mas que C (es una buena aproximacion general), y que el ingeniero te cuesta 3000€ al mes te queda:
En C:
Desrrollo 3000€
Coste micros 2000*4 = 8000€
Total : 11000€
En ASM:
Desarrollo 10*3000€ = 30000€
Coste micros 2000*2 = 4000€
Total = 34000€
La conclusion es evidente.
Legibilidad, reusabilidad: No hace falta decir que el codigo ASM es muy poco legible, nostros mismo si nos llevamos un mes sin ver nuestro propio codigo, tenemos que llevarnos un rato reanalizandolo para ver que hace esto o aquello, incluso habiendolo comentado. Pues imagina que te vas de la empresa a otra a mitad de proyecto, y que te tiene que sustituir otra persona, pues ya esta, a todo ese tiempo de desarrollo, sumale un mes o dos para que el que te sustituye se entere de que hace tu programa y como lo hace. Eso es una ruina para la empresa, ninguna empresa se puede permitir eso.
4
« en: Domingo 17 de Agosto de 2008, 20:17 »
Bueno, despues de muchisimo tiempo sin postear por aqui me encuentro esta discusion, que personalmete creo que es algo que está mas que hablado y que todo el mundo tiene claro, pero veo que no.
En resumen, C sin dudarlo, y como explicare mas adelante no es cuestion de cual es mejor o peor, por que esos son terminos muy relativos. Mis cometarios estan basados en mi experiencia profesional.
Eficiencia del codigo: ¿Como?¿C mas eficiente que ASM?jajaja... Seguro que pensareis. Pues lo cierto es que en la muchos casos puedes conseguir código igual de eficiente en C que ASM por dos razones fundameltanmente:
1-Un buen compilador es capaz de optimizar el codigo MUCHO, incluso mas que una persona. Tened en cuenta que el codigo al final es un grafo de operaciones que puede ser optimizado mediante algoritmos, y los compiladores mejoran cada dia, así que sobre todo en codigos largos podemos optener optimizaciones muy buenas.
2- La librerias. ¿Eres un experto en metodos numericos?¿Estas seguro que tu algorimo es el mas eficiente?¿Seguro? Para muchas aplicaciones, sobre todo de cálculo, el uso de librerias especializadas nos aseguran que estamos utilizando los algoritmos mas eficientes para las operaciones que utilicemos. Es imposible e ineficiente, incluso para un ingeniero experto y con conocimietnos de metodos numericos, recordar o ponerse a buscar que metodos es el mas rapido para tal operación, o cual necesita menos memoria, etc...
Tiempo de desarrollo: El tiempo de desarrollo es fundamental para cualquier producto comercial, por varias razones. La primera es que obviamente a mas tiempo de desarrollo mas costoso sera el sistema. La segunda el el time-to-market, es decir, que mientras antes tengamos nuestro producto acabado, menos competencia tendremos. La tercera el la presión de los clientes: en el caso de que sea un sistema encargado, los clientes se ponen muy nerviosos conforme pasa el tiempo, les gusta tener resultados rápido. En muchos casos, sobre todo en empresas en las que se hacen series pequeñas (menos de 5000 unidades) el tiempo de desarrollo es clave, ya que los gastos de ingenieria suponen una parte muy importante de el coste final de producción: Ejemplo:
5
« en: Miércoles 30 de Agosto de 2006, 02:22 »
Ufff, no se entiende mucho tu pregunta, pero por el titulo supongo que dices que quieres medir la frecuencia de una señal con el modulo PWM??? .. Pues de entrada te digo que ese modulo no sirve para eso. En pricipio para medir frecuencias necesitaras hacer un analisis espectral de la señal, esto es, aplicar un algoritmo matematico, (la FFT o trasformada rapida de Fourier es el mas usado) pero esto es una movida gorda, y mas si no te suena. Si lo que quieres medir es una señal conocida, por ejemplo, sabes que la señal que vas a medir el un seno puro, una cuadrada... puedes medir(muestreandola con el conversor AD) su maximo y su minimo y contar los cruces por la media de estos valores. Si es una cuadrada TTL o con unas tensiones H y L fijas y conocidas, podrias adaptarlas de algun modo a TTL y usar el modulo CCP.
Saludos y suerte.
6
« en: Miércoles 30 de Agosto de 2006, 02:08 »
Hola gancuba, si que puedes implementar un stack tcp-ip en un pic sin usar nada mas, de hecho microchip tiene disponible uno para su familia PIC18 gratuitamente, seguro que lo puedes portar a PIC16 facilmente. No necestias modem o controlador ethernet, puede funcionar por RS232 mediante SLIP, que viene a ser TCP/IP sobre RS232. Toda la info necesaria esta en la nota de aplicacion AN833 de Microchip. Ahora si no quieres complicarte la vida compra esto: http://www.embeddedartists.com/products/uc...proto_small.phpmontale linux y dale caña, si has estudiado teleco o infomatica seguramente tendras alguna experiencia en software de comunicaciones en linux/unix. Saludos.
7
« en: Jueves 12 de Enero de 2006, 23:54 »
Uff!! que de tiempo si visitar este foro y ya veo que va muy bien, parece que se ha convertido en una gran comunidad y con algunos proyectos estupendos!!! Veo que algunos empiezan a buscar algo de mas potencia de la que puede proporcinar un PIC (o cualquier micro de 8bit) y es que la verdad es que al fin y al cabo ¡¡¡son solo de ocho bit!!! y ¡¡¡ sin multiplicador!!!. Esto restringe completamente a los que busquen hacer algo de procesamiento de señales de cierto nivel (audio, video,radio...), o cualquier otra aplicacion de calculo masivo o con restricciones de tiempo. Hasta hace poco tiempo la unica opcion viable para esto era hacer una relativamente fuerte inversion en un sistema de desarrollo de algun DSP especializado (texas ins.,analog devices,...),desde luego los DSPic tenian un nombre un poco engañoso, porque aunque acerca el procesado de señales un poco, la verdad es que esta MUY MUY lejos de un autentico DSP y apenas es valido para procesados muy simples y anchos de banda y resoluciones reducidos y es que en mi opinion no se le puede llamar DSP a cualquier cosa que sea capaz de hacer un MAC. Afortunadamente el desarrollo tecnologico no cesa y la capacidad de integracion sigue cumpliendo casi estrictamente la ley de Moore, ¿alguien sabe algo sobre ARM7 o ARM9?. Seguro que os suena, quizas lo haveis leido en las especificaciones de un catalogo de PDAs. Pues bien, hoy por hoy esta familias seguramente sean de los micros de proposito general mas potentes para aplicaciones embebidas, solo dire que si buscais potencia este probablemente es el mejor camino, si no me creeis informaos. Mirad ESTO: http://www.embebidos.com/produkt.cfm?prodid=644y desde luego no es de los modelos mas potentes jejej.... 32 bit, muchos Mhz,MAC, Ethernet,+todo lo que tenian los PIC y mucho mas... compiladores gratuitos, programacion estandarizada mediante interfaces JTAG, sistemas operativos (QNX,varios derivados LINUX, incluso Windows Embedded). Por cierto he leido en algun post que hay gente interesada en desarrollo con sistemas operativos para microcontroladores, yo he usado SALVO RTOS(pumpkyninc creo)con la familia PIC y TINY RTOS(IAR) con los 8051, por supesto antes de meterles mano teneis que saber para que sirven y en que os pueden ayudar, lo mejor un buen libro sobre sistemas operativos, para esto es bueno saber bien la teoria. Bueno voy a corta ya el royo que parezco un vendedor. Saludos y que esto siga igual!!!! P.D.: http://www.arm.com/ 
8
« en: Domingo 9 de Enero de 2005, 03:24 »
P.D.:
Se me pasaba otra solucion.Como utilizas el modulo PWM tu salida no necesita tener una respuesta lineal, puedes montar un comparador en vez de un inversor, quizas te de el apaño, porque la salida siempre va a ser +Vsat o -Vsat, y como alimentas con 10V que es la salida que quieres, no te tienes que preocupar de la imprecision que tienes en la ganacia al hacerla con resistencias...
....
9
« en: Domingo 9 de Enero de 2005, 03:16 »
Pues tu problema quiza sea simplemente que en los AO estandar en relidad el rango de salida no es +-Vcc, es decir +Vsat no sera 10V si lo alimentas con 10V y -Vsat tampoco sera 0, la proximidad dependera del AO. Si no puedes cambiar la alimentacion del AO intenta con un modelo "rail to rail". Otra cosa es la resistencia de la entrada no inversora, la corriente de entrada del AO como sabes no es 0 en realidad, asi que hay tienes una caida de tension con lo que tendrias que ajustar la ganancia.
Saludos y suerte.
10
« en: Lunes 3 de Noviembre de 2003, 00:56 »
Espero no ofenderte pero eso que pones no tiene mucho sentido.Paramejorar la precision lo que tienes que hacer es operar con mas bits, si tu micro es de 8bit y quieres usar floats de 32 bit tendras que currarte funciones para hacer operaciones de 32 bit por software, los fabricantes suelen ofrecer librerias gratuitas para estas cosas.
Saludos:sorcerer:
11
« en: Sábado 1 de Noviembre de 2003, 19:47 »
Saludos al foro en general. Sobre los moviles: Los moviles en general no se pueden pueden programar, solo los modelos que tienen motor Java pueden correr aplicaciones. Quizas a lo que te refieras es a comandar el terminal a traves del puerto.... y esto si se puede y de hecho es algo en lo que he trabajado bastante, asi que esto os puede servir de guia: Los moviles se pueden manejar,configurar,acceder al SIM, a los mensajes.... ¿como?-> hay dos maneras: Terminales sin modem(mala opcion): algunos se puden manejar con protocolos propiedad del propio fabricante, si el protocolo es publico todo bien, podras hacer mas cosas que con la siguiente opcion, pero lo que aprendas solo te servira para esa marca/modelo. Terminales con modem: se pueden manejar con comandos AT-GSM, es una extension de los comandos AT para modem, son estandar y ofrecen bastante funcionalidad asi que bajate la lista.Lo que necesitas es un terminal con modem (puede que el tuyo lo tenga y ni lo sepas, por cierto no le preguntes a un vendedor si sabe que terminales tinen modem,por que almenos aki en españa no tienen ni puta idea(solo son vendedores, solo conocen la funcionalidad que anuncian por TV), compra el cable de datos, enchufalo al puerto serie y lanza Hyperterminal, prueva a usar 19600 bps no paridad,un bit de parada. Si quieres enviar SMSs o cosas asi tienes que buscarte el formato del PDU(las tramas de lo paquetes). Bueno ya pasare otro dia y pondre algo mas, ahora mismo no puedo seguir. Saludos. 
12
« en: Viernes 5 de Septiembre de 2003, 02:19 »
No utilizo el 8051, pero en otros micros DB reserva un byte a partir de una posicion de memoria
ej:
#org 0x1000;
DB 0x5,0x6,0x7,0x8,0x9,0xA
reserva 5 bytes con esos valores a partir de la direccion 1000h.
13
« en: Viernes 29 de Agosto de 2003, 01:20 »
Hola Jonathan. Hay multitud de sistemas operativos, especificamente compatible para PIC solo conozco este, aunque probablemente podrias adaptar otro, por ejemplo LINUX, pero esto te llevaria mucho tiempo y trabajo aunque fueses un experto, hay otras formas de hacer multitarea (en la web de microchip hay una nota de aplicacion sobre el tema "Simple multitasking with PIC micro MCUs"). El idioma del sistema operativo no debe ser relevante, lo unico que tienes que aprender son los servicios que te ofrece y como usarlos, generalmente son funciones o procedimientos, un ejemplo: void task_ADC() { for(;  { OS_WaitSem(SEM_MUESTREAR,NO_TIMEOUT); ... //codigo que haga lo que quieras en C o ASM ... OS_SignalSem(SEM_ADOK); } } este ejemplo seria la definicion de un proceso, cuando lo creases se quedaria esperando que el semaforo SEM_MUESTREAR sea señalado por otro proceso o desde la rutina de interrupcion,cuando esto ocurriese el proceso pasaria a estado "ready" y entraria en ejecucion cuando el micro este libre y no halla otro proceso con prioridad superior a la suya esperando, ejecutaria el codigo y al final señala al semaforo SEM_ADOK, por ejemplo para indicar a otro proceso que se ha procesado una muestra. Esto esta muy bien Jonathan, pero lo mejor es que no empieces con esto directamente, primero debes conocer bien el micro, haz programas en ASM y en C, cuando no tengas ya problemas y domines esto, lo mejor es que busques documentacion sobre sistemas operativos en general, pues todos tienen mucho en comun, almenos conceptualmente. Realmente si lo que quieres en introducirte lo que tienes que hacer es experimentar con el micro, hacer pequeños proyectos, primero en ASM, mas tarde en C. Un buen camino seria aprender a manejar los puertos de E/S, un proyectito para manejar una pantalla LCD y un teclado, despues aprende a manejar el puerto serie y ya podras enviar comandos al micro desde el PC con cualquier terminal (p.e. Hyperterminal, que viene con windows),una vez sepas esto no tendras problemas para manejar todos lo demas perifericos del micro, pero lo mas importante... leete el dasheet del micro que vallas a usar:excl:. Saludos... 
14
« en: Jueves 28 de Agosto de 2003, 00:35 »
Hola Jonathan.
El sistema operativo del que te hablo es totalmente independiente de windows y de linux, es un nucleo desarrollado por otra empresa, y sirve para varios microcontroladores, incluyendo los de Microchip, Motorola, Atmel, TexasInstruments e incluso para micros x86.
Si no tienes conocimentos claros sobre que es un sistema operativo realmente, te recomiendo que no lo uses con el pic por ahora, espera a adquirir buenos conocimentos sobre SO en general, de todas formas te comento para que y como lo uso:
La pricipal ventaja de usar un sistema operativo reside en poder correr varios procesos "a la vez" en un micro, para esto ofrece servicios para poder crear o destruir procesos, para que se puedan comunicar o sincronizar entre si, para poder parar procesos deurante un tiempo...
imagina la siguiente situacion: tu aplicacion recibe comandos por el puerto serie por ejemplo, para activar unos reles, a la vez tienes que hacer parpadear un led con una frecuencia de 1Hz, leer un teclado matricial y escribir mensajes ,segun el comando recibido, en una pantalla LCD. Si lo enfocaras desde una perspectiva clasica secuencial(como se programa para MSDOS p.e.) tendrias que comprobar si se ha recibido un comando por el puerto, en caso afirmativo escrivir el mensaje correspondiente en la LCD y activar algun rele,comprobar si se pulso una tecla, esperar un segundo(malgastando tiempo de CPU) y despues cambiar el estado del LED, todo esto secuencialmente.Esto presenta problemas, el mas evidente es que no puedes asegurar que el LED parpadee a 1Hz, ademas durantes el segundo que estas esperando puedes perder comandos recibidos por el puerto serie, o pulsaciones del teclado. Con un sitema operativo crearias procesos independientes para cada tares, por ejemplo en este caso, podrias tener un proceso para gestionar los comandos recibidos (OnCommad), otro para leer el teclado (OnKeys), otro para escribir en la LCD(LCDUpdate) y otro para hacer parpadear el LED(LEDBlink). El proceso OnCommad solo se ejecutaria cuando recibieses un comando por el puerto, dejando el micro libre el resto del tiempo,OnKeys cunado se pulse una tecla,LCDupdate solo cuando OnCommad le envie un mensaje con lo que tiene que escribir, y LCDBlink cada segundo(dejando el micro libre cada vez), de este modo puedes sacar mucho mas rendimiento al micro.Como ves la multitarea y la programacion basada en eventos no es ni mucho menos exclusiva de los PCs:D
Saludos y animo:comp:
15
« en: Miércoles 27 de Agosto de 2003, 03:02 »
Hola, llevo como 4 años metido a fondo con los microcontroladores y suelo frecuentar el foro de www.odisea2010.com, pero esta muerto, la gente no hace proyectos, por eso voy a compartir lo fundamental con vosotros a ver si os animais.... Sobre los PICs: Todos los se comercializan actualmente son de 8 bit, aunque se espera una familia nueva de 16 bit con una alu tipo DSP para este otoño. Para empezar os recomiendo directamente el 18F452 es de 8 bit, 10MIPS@40Mhz, con multiplicador hardware(las series 12, 14 y 16 no tienen). Es importantisimo conocer muy bien la arquitectura y el dispositivo en cuestion xq trae un monton de perifericos integrados, asi que hay que manejar MUCHOS registros, aunque programeis en C. Sobre los programadores: Me refiero con programador al dispositivo que se utiliza para cargar en la FLASH el programa, os recomienfo el TE-20, lo tienen en cualquier tienda de electronica decente por unos 10€. Con este programador podeis programar cualquier PIC(incluido los DSPic) xq son todos compatibles, si no te coincide con el zocalo sacais cables y los llevais a las patillas correspondientes del PIC( bajaos los datasheet de: www.microchip.com). Necesitareis ademas un programilla : el ICprog(es gratuito). Sobre los lenguajes de programacion: Hay de todo: ASM, Basic , C,Pascal. Lo mejor es aprender ASM pero no dedicarle demasiado tiempo, mas que nada para conocer bien el micro, yo uso C,concretamente con el compilador Hi-Tech PICC18 junto con el IDE HI-TIDE. Este compilador es de los mejores, y el IDE simula entradas y salidas virtuales, con lo que puedes simular proyectos +o- simples sin montar nada. Cuando domineis esto, que sera rapido xq ya sabeis C, el paso siguiente es usar un Sistema Operativo en el PIC:o, ke para ke? pues para lo mismo que haceis con windows o linux. Yo uso SalvoRTOS hay una version freeware que limita a un maximo de tres procesos 5 semaros y 4 colas de mensajes, os aseguro que es lo mejor, usando un SO puedes harcer en 2 dias proyectos que en ASM tardarias 2 o 3 meses. Otras cosas importantes pa empezar: Necesitas una insoladora(dos tubos fluorescentes en una caja). Un soldador. Un programa para dibujar PCBs(placas). Un cursillo rapido de electronica basica. Y algunas referencias: www.microchip.com www.microchipc.com (imprescindible para C) www.pumpkininc.com www.odisea2010.com (para aprender) www.conket.com (para aprender) espero que ya sepais por donde empezar y ya pasare por aki, a ver si esto progresa... Saludos 
Páginas: [1]
|
|
|
Mostrar Mensajes
