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...

Notarás la misma predisposición en muchos otros miembros. Cada cual sabe/apora/ayuda de lo suyo.
