TODOPIC
Microcontroladores PIC => dsPIC => Mensaje iniciado por: manwenwe en 18 de Enero de 2007, 17:11:33
-
Hola, estoy empezando a mirarme los dsPIC... he leído que uno de estos es capaz de realizar una conversión en el ADC en 2useg(bastante más rápido que un PIC)...
Me surge la duda de cuantas conversiones por segundo es capaz de realizar un dsPIC: teniendo en cuenta los ciclos de reloj empleados en el bucle utilizado, la lectura del flag de fin de conversión,etc.
No busco algo demasiado técnico sino simplemente un dato que pueda ofrecer por experiencia alguien que haya calculado este ratio...
Gracias de antemano! Saludos!
-
Hola, estoy empezando a mirarme los dsPIC... he leído que uno de estos es capaz de realizar una conversión en el ADC en 2useg(bastante más rápido que un PIC)...
Me surge la duda de cuantas conversiones por segundo es capaz de realizar un dsPIC: teniendo en cuenta los ciclos de reloj empleados en el bucle utilizado, la lectura del flag de fin de conversión,etc.
No busco algo demasiado técnico sino simplemente un dato que pueda ofrecer por experiencia alguien que haya calculado este ratio...
Gracias de antemano! Saludos!
Según el product selection guide, para los dspic con 1 A/D
A/D en 10-Bit -> 1.1 Msps
A/D en 12-Bit -> 500 ksps
Para los dspic con 2 A/D, 2.2Msps.
Product Selection Guide (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1924)
Aún no los he usado y no he leído cómo fundamentan el cálculo pero son los ratings máximos que te aseguran ellos.
-
Gracias por tu respuesta maunix! Me interesaba esto sobre todo para evaluar los tiempos necesarios para guardar todas estas conversiones en una tarjeta MMC/SD...
Pensé en utilizar un dsPIC como muestreador y un segundo PIC o dsPIC como grabador para las tarjetas. La idea era que cada conversión se trasladara a un par de puertos del dsPIC que muestrea y utilizando una linea para señalizar si hay datos nuevos o no, pasarle en paralelo los datos al PIC grabador y que este se encargue de grabarlos en la MMC.
El problema es que según la velocidad de muestreo que me comentas veo que el PIC grabador no sería capaz de seguir el ritmo que marca el muestreador...para esto necesitaría enviar cada dato a la MMC en 333nseg( (1/1Msps)/3... el 3 se refiere a pasar una muestra de 12 bits del ADC a 3 caracteres ASCII) y creo que esto es imposible...
¿Qué opinais? ¿alguna sugerencia?
Saludos!
-
Habría que ver el spec de tu datasheet, pero sí, lo usual es guardar en una memoria RAM estática y luego guardar en una flash (cómo hacen las cámaras de fotos).
No creo que puedas grabar a máxima velocidad, al menos no con una memoria convencional. He visto en la página de ATMEL o de ST (no recuerdo ahora) que tienen memorias de 256bytes de buffer que graban en 1mseg. Esto te da una buena velocidad ya que si hacemos un poco de números.
1mseg / 256 = 3,9 useg.
Esto es una aproximación y nos dará 256K bytes por segundo pero ahora si ya en la FLASH.
Sería cuestión de ver si consigues alguna memoria que tenga un tiempo de grabación similar y un buffer mayor aunque no creo que por ahora tengas mucha suerte al respecto.
Están también las memorias ferromagnéticas que graban en forma casi instantánea a un ratio de 15Mbps en SPI. Lo que no sé es de qué capacidad vienen a precios razonables.
Volviendo a tus exigencias, creo que son aún mayores a lo que te expuse
1. Transmitir en paralelo o por SPI directamente a la memoria, no se si hay gran diferencia entre uno y otro proceso, contemplando el almacenado en un buffer previo los datos y manejando en segundo plano la comunicación con la memoria SPI, tal vez te evites el uso innecesario de otro PIC.
Podrías tener un buffer para almacenar lo leído del A/D y otro que esté para enviar a la memoria. En las rutinas debieras saber cuál usar en cada caso y se usarían alternativamente (no hablo de copiar de un buffer a otro porque insumiría tiempo innecesario).
2. convertir a 3 caracteres ascii es bastante simple, trabajando con los nibbles pero estás aumentando en 2/3 la capacidad de memoria necesaria a la vez que reduces en 2/3 la velocidad de transferencia a la memoria por cada dato. Es decir, si muestras 1.1M de datos por segundo a 12 bits, son 2.2Mbytes. Con tus requerimientos de conversión a ASCII (pasamos de usar 2 bytes por dato a usar 3) estarías requiriendo 3.3MBytes por segundo de transferencia.
¿Cuánto tiempo quieres grabar? También depende de eso. De todas formas, no descartes el uso de una memoria estática.
-
Hola maunix, ante todo muchísimas gracias por las molestias que te has tomado en analizar el problema que expuse: todos los posts que te leo son siempre muy correctos y con las mejores intenciones, mi sincera enhorabuena!
Me explicaré un poco mejor...
Lo que estoy buscando no es para mi sino para una amigo... el suele ayudarme en los diseños electrónicos y yo intento echarle una mano, en la medida que puedo, en la programación para sus proyectos.
Realmente este es un proyecto ambicioso y a la vez muy interesante, por esto estoy tomando bastantes molestias en poder darle alguna idea que pueda hacerle el trabajo más facil. Se trata de hacer un medidor de radiación solar: esto quiere decir, capturar el rizado que se produce( que es más o menos de un 1/1000 de la señal) durante un eclipse solar y guardar los datos en un dispositivo de almacenamiento externo, de forma que todo el aparato de medición tenga un tamaño considerablemente pequeño(no cabe la posibilidad de llevar un ordenador portatil junto al medidor).
La parte electrónica no la entiendo bien del todo porque apenas estoy siguiendo sus procesos pero creo que consta básicamente de: un fototransistor, una fuente de corriente inversa para eliminar el nivel de continua y un filtro pasabanda...
En cuanto al almacenamiento de las muestras: la primera idea que tenía mi compañero era guardarlas en memorias EEPROM. Pero al comentarme que el aparato en cuestón debería estar tomando muestras durante al menos 30 minutos, le sugerí que pensara en las MMC/SD por que con las EEPROM apenas puedes almacenar 1 MB.
Lo que comenté sobre ASCII es debido a que estos datos guardados en la MMC deben ser trasladados posteriormente a una aplicación Windows, por lo que si mantienes 2 caracteres por muestra en vez de 3, uno de los 2 caracteres(si no haces antes una repartición de bits) contendrá 8 bits de los 12 de la salida del ADC: estos 8 bits pasados a ASCII pueden suponer caracteres que Windows no sabe distinguir(caracteres de control).
Igualmente, despues de analizar más lo de la memoria MMC me he dado cuenta en que no caí en que si grabas texto plano Windows no será capaz de reconocer el archivo con las muestras. Implementar el sistema de archivos FAT no es nada facil y no creo que valga la pena perder varios meses en esto. Yo estoy trabajando con un controlador FAT (basado en un ARM9) que es capaz de entrgar 60KB/seg a una tarjeta MMC/SD: creo que esta sería una buena solución.
Como me comentó mi compañero...el verdadero problema que existe que existe es que el dsPIC no debería dejar de tomar muestras en ningún momento.
La verdad es que me he estrujado bastante le cerebro pero no encuentro forma humana de enviar datos a la velocidad suficiente como para no entorpecer el trabajo del ADC. Con esto también quiero decir, que como comenta maunix, lo de poner un segundo PIC no tiene porque ser una buena idea
.
Bueno dejo expuesto más o menos el problema y espero que alguien pueda decirme algo así como: "¿qué haces burro?.... es mucho más facil de lo que intentas" :D
Saludos a todos!
-
A ver manwenwe si puedo seguir dándote una mano con el asunto.
Tu comentas que debes muestrar a 1/1000 de la velocidad de la señal, pero de cuanto estamos hablando exactamente? Es decir, una muestra por microsegundo, por cada 10 microsegundos, etc.
Por otra parte, respecto a la grabación de los datos , creo totalmente innecesario ahora que conozco tus motivos, que grabes en formato ASCII. Tienes (como te has dado cuenta) 2 alternativas.
1) Grabar en un formato binario, un dato de 12 bits a consecuencia del otro. Luego al conectarlo a la PC, podrías por ejemplo por el puerto serie, transferir los datos lenta y tranquilamente. En esa 'transferencia' podrías ya convertirlo a ASCII si quieres con algún formato amigable o bien los transmites binariamente y en el lado de la PC haces la conversión a un formato ASCII. Ambas opciones tienen sus pro y sus contras. La que el PIC haga todo, te da independencia pero la transferencia sería bastante más lenta. La que la PC procese todo, te obliga a hacer la aplicación de la PC pero la velocidad de transferencia seria mucho mayor.
2) Grabar en un archivo de texto o como sea en un formato de archiovos FAT. Tal como te has dado cuenta, no es algo tan simple y por sobre todas las cosas, deberás generar muchos datos extras (datos separados por comas, por punto y coma, por tabulaciones o bien por un retorno de carro). De todas formas no te salvas de que sean más datos que los esperados. Para un dato de 12 bits, que ocupa 3 caracteres ascii + el caracter de separación, vamos a la cuenta de que son 4 bytes por cada muestra.
Volviendo al problema en sí ¿es realmente necesario procesar la señal a 12 bits? Tu hardware realmente debe ser muy bueno para que los últimos 3 ó 4 bits no sean 'ruido'. Tal vez logres idéntico resultado con un muestreo a 8 bits.
Usando un dspic a 3.6V, si muestras con 12 bits estás buscando una precisión de 4096 valores. Eso lleva al siguiente cálculo
Voltaje de cada bit = 3.6V / 4096 = 0,879 milivoltios.
Es decir menos que una milésima de voltio... realmente tu circuito debe ser muy bueno (bueno en este caso significa caro) para que a 1Millón de muestras logres que el ruido sea menor a 1mV.
Si muestreas a 8 bits y guardas los datos en forma binaria, nos acercamos haciendo números rápidos a unos 512K muestras/bytes por segundo.
Como me comentó mi compañero...el verdadero problema que existe que existe es que el dsPIC no debería dejar de tomar muestras en ningún momento.
La verdad es que me he estrujado bastante le cerebro pero no encuentro forma humana de enviar datos a la velocidad suficiente como para no entorpecer el trabajo del ADC. Con esto también quiero decir, que como comenta maunix, lo de poner un segundo PIC no tiene porque ser una buena idea
No se si hay una forma 'mucho más fácil de resolver el problema'. A mi modo de verlo trabajar ' a velocidad' no es algo trivial y requiere de conocer los timings de muchas cosas. A veces al aumentar en 10 el orden de magnitud de la velocidad el problema se complica 100 veces... y el costo también. Tu quieres desarrollar una aplicación de tiempo real y que guarde datos sin pausa.
A lo que voy es que hacer un hardware para leer/grabar datos a 100K muestras por segundo, puede costarte unos 20 dólares. Hacer un hardware para hacer 1M muestras por segundo podría salirte más que 200 dólares. La cantidad de datos se multiplicó por 10 pero el costo por más de 10.
Ni hablar si quieres 10Millones de muestras por segundo!!
Si yo fuera tú , comenzaría por el principio y por lo que te definirá todo el resto.
¿Cuántas muestras por segundo son las realmente necesarias? ¿Qué precisión en bits son lo que realmente necesitas y/o puedes lograr a un costo razonable?
Hola maunix, ante todo muchísimas gracias por las molestias que te has tomado en analizar el problema que expuse: todos los posts que te leo son siempre muy correctos y con las mejores intenciones, mi sincera enhorabuena!
De nada, es el espíritu del foro que contagia... :mrgreen: :mrgreen:
Notarás la misma predisposición en muchos otros miembros. Cada cual sabe/apora/ayuda de lo suyo. 8)
-
Hola de nuevo maunix:
¿Cuántas muestras por segundo son las realmente necesarias? ¿Qué precisión en bits son lo que realmente necesitas y/o puedes lograr a un costo razonable?
Intentaré explicar la precisión de bits a partir de dos preguntas tuyas:
Tu comentas que debes muestrar a 1/1000 de la velocidad de la señal, pero de cuanto estamos hablando exactamente? Es decir, una muestra por microsegundo, por cada 10 microsegundos, etc.
+
Volviendo al problema en sí ¿es realmente necesario procesar la señal a 12 bits? Tu hardware realmente debe ser muy bueno para que los últimos 3 ó 4 bits no sean 'ruido'. Tal vez logres idéntico resultado con un muestreo a 8 bits.
Usando un dspic a 3.6V, si muestras con 12 bits estás buscando una precisión de 4096 valores. Eso lleva al siguiente cálculo
Creo que me expliqué mal no es que la velocidad de muestreo sea de 1000 baudios... lo que es 1/1000 es la variación del rizado de la señal sobre la componente continua: por tanto primero se opta por eliminar la componente continua con una fuente de corriente inversa, despues se filtra la señal para eliminar ruido y finalmente se amplifica para obtener un rango de tensión aceptable para muestrea(no es plan de muestrear sobre una señal de 1mV pico-pico).
Como no veía las cosas tan claras he hablado de nuevo con mi amigo y me ha explicado mejor la teoría del proyecto. La señal a muestrear tendría una amplitud pico-pico de unos 5 voltios y una banda de frecuencias 50-500hz... Por tanto si hacemos hacemos caso al gran Nyquist :D valdría con con una velocidad de muestreo de 1000 baudios(al final acertaste maunix :D).
1000 muestras por segundo, haciendolo como tú comenatas 4 ASCII x 1000 = 4000 bytes para enviar a la memoria en cada segundo (algunos mas para tabular el archivo a grabar: retorno de carro,etc.). Como he comentado antes se puede utilizar un controlador FAT que escribe 60000bytes/seg: con lo que el problema del almacenamiento parece resuelto :o.
Ahora bien, creo que falta por determinar si se puede disminuir la resolución del ADC... Para una señal de rango [-2.5,2.5] voltios....
¿qué resolución es apropiada? ¿8,10,12 bits?
Realmente no se que cantidad de ruido portará la señal a muestrear y si este ruido es gaussiano o afecta de forma distinta a las diferentes bandas de frecuencia... lo único que me dejó claro mi compañero es que es muy importante obtener una buena resolución, pues este es el objetivo final del proyecto: obtener la variación de la radicación solar que llega a la Tierra y que es producida por la atmósfera(apenas inapreciable).
Estoy intentando que este amigo se una al foro y comparta con todos sus conocimientos y dudas pues como dije anteriormente: este es un proyecto realmente muy interesante.
Saludos
-
Creo que me expliqué mal no es que la velocidad de muestreo sea de 1000 baudios... lo que es 1/1000 es la variación del rizado de la señal sobre la componente continua: por tanto primero se opta por eliminar la componente continua con una fuente de corriente inversa, despues se filtra la señal para eliminar ruido y finalmente se amplifica para obtener un rango de tensión aceptable para muestrea(no es plan de muestrear sobre una señal de 1mV pico-pico).
Como no veía las cosas tan claras he hablado de nuevo con mi amigo y me ha explicado mejor la teoría del proyecto. La señal a muestrear tendría una amplitud pico-pico de unos 5 voltios y una banda de frecuencias 50-500hz... Por tanto si hacemos hacemos caso al gran Nyquist :D valdría con con una velocidad de muestreo de 1000 baudios(al final acertaste maunix :D).
Jeje, no se de donde sacaste que yo hablaba de 1000 muestras por segundo :shock:
Creo que mal interpretaste que yo malinterpreté la velocidad (me estoy poniendo poético :mrgreen:).
Si relees mi post, yo mencioné 1/1000 de TU señal, y aclaré al lado si eso era un dato cada 1 useg (1M de muestras por segundo) , o cada 10useg (100K muestras por segundo), solo por citar un ejemplo pensando en lo que originó el post que era hablar de 1.1Msamples por segundo o 2.2Msamples
1000 muestras por segundo, haciendolo como tú comenatas 4 ASCII x 1000 = 4000 bytes para enviar a la memoria en cada segundo (algunos mas para tabular el archivo a grabar: retorno de carro,etc.). Como he comentado antes se puede utilizar un controlador FAT que escribe 60000bytes/seg: con lo que el problema del almacenamiento parece resuelto :o.
Estas son decisiones a las que el diseñador debe recurrir. No me atrevo a decirte qué hacer porque yo lo resolvería todo binariamente y por último generar una comunicación con la PC que me resuelva el levantar el archivo, pero sobre gustos y gastos..... :mrgreen:
Resumiendo , hay cosas que tienen que con el criterio del diseñador y dos o más soluciones son posibles, y cada uno elige la que le parece mejor. En algunos casos es obvio que una solución es mejor que otra, pero en otros casos determinar cuál solución es mejor/más eficiente/más concienzuda no lo es tanto... he ahí la importancia de que cada uno piense diferente y aportar el criterio.
Ahora bien, creo que falta por determinar si se puede disminuir la resolución del ADC... Para una señal de rango [-2.5,2.5] voltios....
¿qué resolución es apropiada? ¿8,10,12 bits?
Creo que aquí debes ver cómo te llega la señal una vez que ha pasado por las etapas anteriores.
Cuando hablaba de 1mV de precisión, me refería a lo que trabaja el A/D a 12 bits, trabajando en 3.6V a fondo de escala, no a que tu proceses una señal de 1mv!! De nuevo ese 1/1000 creo que generó confusión.
¡Ojo con eso! Fijarse bien cuál es la máxima tensión que acepta el A/D del pic o dspic que vas a utilizar, no tiene sentido que escales algo de 0 a 5V si tu A/D solo soporta de 0 a 3.6V.
Otro dato importante, el A/D del pic no soporta señales negativas. Deberás usar un desplazador de nivel para ubicarla en el rango del PIC.
Respecto a la presición, como te dije antes, depende del ruido que tenga tu señal. Ahí no juega el PIC en cuestión sino la calidad del procesamiento previo que tenga la señal, eliminación de ruido, etc. Si trabajas con 12 bits y los 4 últimos bits son ruido... lo notarás porque cambian constantemente incluso para un valor fijo de tensión.
Saludos
-
Otro dato importante, el A/D del pic no soporta señales negativas. Deberás usar un desplazador de nivel para ubicarla en el rango del PIC.
Es lo que pasa cuando dejas de trabajar con las cosas... olvidas los detalles fundamentales... gracias por recordarmelo!
Bueno veremos que sale del tema, cuando esté la cosa más clara volveré a postear para mostrar los avances.
Saludos!
-
Otro dato importante, el A/D del pic no soporta señales negativas. Deberás usar un desplazador de nivel para ubicarla en el rango del PIC.
Es lo que pasa cuando dejas de trabajar con las cosas... olvidas los detalles fundamentales... gracias por recordarmelo!
Bueno veremos que sale del tema, cuando esté la cosa más clara volveré a postear para mostrar los avances.
Saludos!
Muy bien, será interesante ver cómo sigue esta novela. :)