Hola lucegiar2005, tienes toda la razón y tu opinión es muy acertada, y aunque el uso de un convertidor frecuencia/tensión con el A/D no sería lo más practico, en este caso no hay que descartar la posibilidad de su uso.
Gracias por la opinión, y acá todas son bienvenidas, ya sean buenas o no.
jpccalvo, lo que comentas de una tabla de 10 valor y un simple programa sería lo optimo, pero no es tan sencillo.
Ejemplo, usamos una tabla de 10 valores, un valor por cada 1000 RPM del motor.
Motor a 1100 RPM, usamos el valor 2 de la tabla que para este rango suponemos genera un avance de encendido de solo 5°, o sea disparamos 25° después de la señal.
1100 / 60 = 18.33 Hz ------> 1 / (18.33 x 360) = 151.5 useg x 25 = 3787.5 useg
O sea que supongamos que en la tabla tenemos el numero 3787 guardado en la posición 2 que corresponde desde los 1001 RPM hasta las 2000 RPM.
Ahora calculemos la demora obtenida a 2000 RPM con este valor de 3787 guardado en la posición 2 de la tabla.
2000 / 60 = 33.33 Hz ------> 1 / (33.33 x 360) = 83.3 useg
O sea que a 2000 RPM el motor gira a una tasa de 83.3 useg por cada grado, el valor 2 de la tabla era 3787 que se correspondía con los 5° de avance para las 1100 RPM, pero que pasa?
3787 useg / 83.3 useg = 45.46°
Y si partimos que la señal de disparo se generaba 30° antes de punto muerto superior, pues 30 - 45.46° = -15.46°
Verás que el valor 2 de la tabla iba perfecto para las 1100 RPM, pero a las 2000 RPM el encendido del motor esta atrasado 15°
Y este es el gran problemas con las tablas y valores fijos pre determiandos, se necesitan una cantidad grande para que el "avance" aparente progresivo.
Con respecto a la página, no hubo manera que la pueda ver, por ahí conseguíamos data para ayudarnos.
Y con respecto a la memoria EEPRON de los PIC, pues te diría que es casi imposible su uso, ya que la misma es relativamente lenta en su lectura. Aparte las tablas en los PIC si o si se almacena en la memoria de programa, como parte del mismo.
Por otro lado, al desear usar niple, se te presentaría en este caso, otro enorme problema, y es que tanto basic, C, Niple, etc, cualquier programa que no sea el asembler, tienen grandes problemas en el control de tiempos, por lo que no son muy exactos y aparte los programas generados son mucho más lentos y largos al momento de la ejecución, y como acá el tiempo es un problema, pues te diría que Niple está muy lejos de ser la mejor opción para esta aplicación.
Lamento las malas noticias de hoy.
Un saludo.
Atte. CARLOS.