buenos dias gente!. tengo a mi cuñado que esta en la contruccion de un banco de pruebas, el corre en la categoria light de fiat 600, y esta atorado con el proyecto, me pidio si podia poner aca el proyecto para ver si alguien puede echarle una mano. dejo la transcripccion de su mail asi como el pdf del proyecto. saludos y gracias!

"Hola, el motivo de mi consulta es en relación al proyecto que adjunto como PDF. Se trata de un banco de pruebas casero para autos, en este momento me encuento haciendo la parte electrónica y estoy trabado con la programación del microcontrolador (PIC 16f877a).
El software necesario debe leer los niveles de voltaje en los puertos de entrada analogicos, AN0, AN1, AN2, AN3 y AN4, luego pasarlos por el convertidor analógico digital y transmitir estos datos por el puerto serial, según se los requiera la PC con la cual tendrán comunicación full duplex a través del puerto serial.
El programa del PIC debe contener subrutinas para las lecturas de los sensores, conversiones análogas – digital, transmisiones y recepción de datos, para el caso de las lecturas en los sensores al momento de la prueba se debe de tomar muestras para el tacómetro óptico e inductivo aproximadamente 50 veces por segundo de tal forma que se pueda tener una buena resolución de las graficas al momento de la prueba, mientras que para la temperatura ambiente, presión atmosférica y humedad relativa las muestras se toman únicamente tres veces: al inicio, a la mitad y al finalizar la prueba, o puede ser activada la lectura desde una solicitud directa de la PC por medio del software, según lo requiera el usuario de la PC.
Agradecería si alguien podría darme una orientación de como realizar este tipo de programación, si es muy difícil de aprender para un aficionado, o en caso de tener que contratar a alguien que la haga si es muy caro, desde ya muchas gracias."

LINK

El proyecto es interesante, mire un poco por arriba el paper.

El desarrollo de soft del PIC es por lo menos complicado, requiere de mucha prueba/error y de algo con que comparar. Es decir tener un banco con medidas fiables para calibrar.
La lectura de las señales repetitivas de alta velocidad, sobre todo las opticas/magneticas, requieren de una limpieza para poder establecer el punto justo que corresponde a la señal en si y no a ruidos.

Sin tener los dispositivos para poder realizar pruebas creo que es dificil poder sacar algo en concreto.
Lo que si es seguro que no son 5 minutos de sentarse a hacer el programa.

gracias master po por siempre responder!, le voy a mandar el link de este tema, y espero que se registre por que el va a saber explicar mejor que tiene y que no, y hasta donde llego con el proyecto... a ver si acá puede encontrar la solución y le sacamos un sponsoreo del foro para el fito XD

Yo te recomendaría trabajar con la plataforma Arduino, no con PICs. Salvo el precio mas alto, tiene muchas ventajas: Un Bootlader que simplifica la vida al cargar programas por el puerto USB. Una ide de programación muy buena. Un idioma de programacion muy similar al "C". posibilidad de intrerfacear con muchos programas de adquisición de datos. Facilidad de buscar errores, por la posibilidad de plantar banderas y ver por el monitor el valor de las variables.
Yo le usado para seguirle la pista a un encoder con pulsos cercanos a 1 khz sin problemas. Lo único que hay que hacer es optoaclopar las señales, cosa que probablemente también tengas que hacer con un PIC.

Saludos

Gracias peter por los datos!

Nunca trabaje con Arduino asi que no se que capacidad tiene el entorno de programacion para hacer "multitarea", ya que en este caso me parece que es mas practico manejar todo con interrupciones.
Lo primero que hay que ver es la comunicacion serie, yo trabaje con PIC16 y con la velocidad maxima a la que trabajan, 20MHz, la maxima velocidad estandar que maneja la UART para RS232 es 57600 bps, creo que el maximo estaba cerca de 80000 bps pero no es un valor estandar, a 115200 bps no llega con ese cristal.
Digo que hay que ver lo del puerto serie porque uno tiene que pensar cual va a ser el flujo maximo de informacion, ya que los microcontroladores de 8 bits como los PIC y ATMega no son muy aptos para calculos que no sean de numeros enteros, conviene enviar a la PC el valor de captura de cada conversor A/D, que en el caso de los PIC tiene una resolucion de 10 bits, y dejar que la PC se encargue de los calculos y calibracion para mostrar una lectura final.
Ya que la maxima frecuencia a la que se pedira informacion va a estar alrededor de 50 veces por segundo, lo que habria que hacer es implementar una rutina de interrupcion donde se vayan leyendo por turno los sensores. Digamos que tenemos 10 sensores, leeriamos uno cada vez que entramos a la rutina de interrupcion, por lo que la rutina se ejecutaria 500 veces por segundo, esto es asi porque el conversor A/D solo puede capturar una entrada a la vez, y la captura no es instantanea. Yo probe una rutina de interrupcion que se ejecuta 7812,5 veces por segundo para capturar audio, y funciono perfectamente, asi que la velocidad de captura es suficiente, lo que hacia era disparar la captura en una interrupcion, y en la proxima leia el valor y disparaba la siguiente captura.
No se cuantos sensores va a haber, pero suponiendo que sean nada mas que los conectados a las 5 entradas del conversor A/D, serian 2 bytes por entrada (para representar los 10 bits de captura) por 5 entradas, es decir 10 bytes para enviar. A 57600 bps, donde cada bit dura 1/57600 segundos y se requieren 10 bits por byte en formato 8N1 (sin control de paridad), cada byte duraria 173,6 microsegundos, es decir que la lectura de los 5 sensores duraria 1,736 milisegundos en enviarse a la PC, y si se debe enviar esto 50 veces por segundo (1/50 = 20 milisegundos), tenemos que hay margen para enviar 11 veces y media mas datos a 57600 bps (20ms/1,736ms). Esto hay que tenerlo en cuenta a medida que agregues sensores o comunicacion desde la PC, ya que aunque se pueda enviar y recibir a la vez, en la practica tanto la PC como el PIC esperaria a recibir los datos del otro antes de enviar nuevos.
Lo que yo haria, ya que hay margen suficiente a esa velocidad, es enviar todas las lecturas juntas, aunque la PC solo necesite una medicion, el PIC tendria que ir midiendo permanentemente y guardando los resultados, y simplemente enviaria todo de una sola vez al requerirselo desde la PC. Tambien habria que armar la rutina de interrupcion de acuerdo a como se tenga que hacer otros tipos de mediciones que no sean del conversor A/D, todo eso depende mucho del circuito y de la forma en que lo haga el hard del PIC, es dificil pensar una forma generica de hacer el programa.
Me olvidaba, la transmision y recepcion en el PIC funcionan en paralelo al resto de la ejecucion, no hay que andar esperando una respuesta de la PC, esas funciones se hacen de forma automatica por byte, y hay que chequear permanentemente (o programar una interrupcion) para enterarse si el byte ya se envio o si se recibio uno nuevo. Aclaro esto porque en muchos lenguajes de alto nivel como por ejemplo algunas variantes de BASIC para PIC, esto no funciona de ese modo, hay que interrumpir la ejecucion de otras cosas para esperar valores desde el puerto serie.

No creo que el sistema a medir sea tan exigente. En el pdf que adjunto gatoadrogue miden una señal digital y la convierten en analógica utilizando varios ciclos de reloj para la conversión A/D, seguramente para evitar interferencia por el ruido, pero a costa de la repuesta a cambios . Yo mediría directamente una señal digital mediante interrupciones, con varios muestreos por revolución del motor (habría que hacer pruebas para ver si el ruido no es un obstáculo insalvable). Según especifico la señal seria de unos 50 Hz y cualquier micro o Arduino podría manejarla sin problemas
Las señales analógicas de presión, temperatura, humedad ambiente no varían rápidamente y no necesitan un muestreo rápido , igualmente para Arduinos se venden unos sensores económicos microprocesados que no sobrecargan al micro.
Saludos

Lo mio apuntaba especificamente a un par de cosas:
- Hay que pensar como se van a pedir los datos desde la PC y cual va a ser el peor caso de transferencia de datos para elegir la velocidad y el protocolo de comunicacion entre la placa y la PC. En el mensaje original da a entender que la PC va a pedir cada medicion particular, y eso no se puede responder de forma inmediata porque hay que elegir la entrada correspondiente del conversor A/D, disparar la captura, y luego esperar el tiempo que especifican las hojas de datos antes de que el PIC o ATMega pueda recien enviar el resultado por RS232. Es mas practico que el microcontrolador lea esas entradas periodicamente ya que de esa manera puede responder a la PC de forma inmediata cuando se lo requiera.
- Ademas si se pide cada medicion una por una, hay que implementar comandos para indicarle eso al microcontrolador, el cual tiene que analizarlos y determinar que medicion se requiere antes de enviarla. Por los calculos que hice hay tiempo de sobra a 57600 bps y es mas simple para la implementacion que la PC requiera todas las ultimas mediciciones y el microcontrolador las envie en un solo bloque.

Si se planifica bien la secuencia que se va a ejecutar y se automatiza todo lo posible, el programa va a quedar bastante simple y no va a ser necesaria la fuerza bruta, por lo que cualquier PIC o Arduino tendria que servir, pero si se improvisa pidiendo datos cuando el microcontrolador no esta listo, no queda otra que poner el microcontrolador mas potente solo por las dudas.

Estoy de acuerdo Pastbytes, solo leí por arriba el PDF, no había reparado el hecho que la Pc genera la interrupción pidiendo datos. En realidad no me parece acertado, a menos que el PIC responda de alguna manera yo plantearía todo como un Data Logger y la información vaya en un solo sentido.

Saludos

Si uno no quiere meterse mucho en programacion, por la plata que sale cada PIC y el poco espacio que ocupa conviene usar un PIC para cada cosa, cada uno corriendo un programa simple.
Por ejemplo un PIC que solamente cuente ciclos y calcule frecuencia y envia el resultado por puerto serie, es un loop muy simple. Despues otro que lea un AD y tambien lo convierta.
Por mi experiencia de tratar con gente que esta en temas tecnicos pero no programa, la palabra interrupcion no hay que mencionarla siquiera, hacer un programa que este atento a varios eventos es complicado para alguien que esta en el tema, asi que si se puede encarar de otra forma mejor.
Para diseñar un sistema siempre tenes que cortar el problema que queres solucionar en partes mas simples, si estas en software hacelo con software, sino dividilo de otra forma.

Saludos
MARCOS