¿Problemas con tiempos y C?

[tapi8]

Resulta que estoy asesorando a una persona sobre un proyecto, el quiere hacerlo en C porque le resulta mas facil (el ya sabia algo de C, aunque no para PICs), se ha comprado tambien una placa Teensy (parecida a Arduino pero algo mas potente, creo) que tambien se programa en C o algo parecido (usa el mismo lenguaje que Arduino) resulta que mirando las expecificaciones de estas placas, le dice que por debajo 14uS los tiempos no son fiables, que pueden fallar, vamos.

Pregunto aqui porque yo de C no se casi nada, ¿Es posible esto de que por debajo de 14uS falle?, porque de momento estamos trabajndo con 45uS, pero tendremos que empezar a trabajar con tiempos por debajo de 10uS, y en una segunda parte seguramente con tiempos de 4 o 5uS y deben ser bastante exactos, si fallaran una vez no pasaria nada, pero si fallan mucho nos descompesaria totalmente la onda que estamos generando y claro fallaria todo.

¿Como los veis?

[Diego E.]

Hola Tapi8, cuando se requiere tiempos muy precisos tanto en C como en assembler creo que lo mejor es manejarlos por hardware, me explico, para temporizadores utilizar contadores con interrupción y para manejo de ondas utilizar PWM, también es conveniente trabajar con una mayor velocidad 8Mhz, 16Mhz o más.

Hacer tiempos por instrucciones siempre lleva mucho error.

Saludos.

[migsantiago]

Hola, una sugerencia es revisar el archivo LST que se genera. Ese trae la conversión de instrucciones en C a ensamblador. Ya siendo vistas en ensamblador pueden calcular fácilmente cuánto tiempo tardarán en ejecutarse sabiendo la velocidad de ejecución del CPU.

[tapi8]

Gracias por contestar.

Hola Tapi8, cuando se requiere tiempos muy precisos tanto en C como en assembler creo que lo mejor es manejarlos por hardware, me explico, para temporizadores utilizar contadores con interrupción y para manejo de ondas utilizar PWM, también es conveniente trabajar con una mayor velocidad 8Mhz, 16Mhz o más.

Hacer tiempos por instrucciones siempre lleva mucho error.

¿Generar los PWMs con los modulos CCP? Puede ser una opcion pero necesitamos 6 PWMs de los cuales 3 estan inactivos y otros 3 activos y cada 125uS cambian de dutty y a veces tambien cambia la frecuencia, estar continuamente cambiando cambiando la configuracion del modulo me parece mas complejo que hacerlos por software...

En asm le hice un par de PWMs de muestra para que viera como es la generacion de las ondas, y a 8MHz con TMR0 y bucles salen los tiempos clavados, sin ningun problema. No uso interrupciones porque entre guardar reg detectar el flag y restablecer, pierdo tiempo. En un futuro habra que leer varios ADCs y habra que hacerlos tambien sin interrupcion porque los tiempos se van al carajo, tengo controlados los puntos donde se que puedo hacer estas lecturas.

Hola, una sugerencia es revisar el archivo LST que se genera. Ese trae la conversión de instrucciones en C a ensamblador. Ya siendo vistas en ensamblador pueden calcular fácilmente cuánto tiempo tardarán en ejecutarse sabiendo la velocidad de ejecución del CPU.

Si Migsantiago, ya lo ha hecho y se ha quedado alucinado, hacer un bsf le lleva 4 ciclos de instruccion. Desde un principio quiso C en vez de asm, logicamente, pero cada vez le convence mas el asm  , va al reves de todo el mundo.

La intencion es que si lo hace en C usara como minimo un PIC a 64MHz (16MIPS).

[Diego E.]

Yo he hecho PWM utilizando temporizador con interrupción, lo que hago es verificar en el debugger del mplab los tiempos en que entra y tarda en salir de esta, y así ajusto el valor del contador.

[tapi8]

Si, yo tambien ajusto los tiempos en el MPLAB con el stopwatch, supongo que es lo que hace todo el mundo, en asm no hay problema, pero en C me da que no va a ser posible, ayer estuve intentando hacer una secuencia y ya estoy trabajando con tiempos de 9uS...

Tenemos otro problema y es que tenemos que hacer lecturas del ADC, de momento solamente una pero seran mas, creo que sera mejor hacerlas con otro PIC y transmitirle los datos a traves de la USART?

[KILLERJC]

Resulta que estoy asesorando a una persona sobre un proyecto, el quiere hacerlo en C porque le resulta mas facil (el ya sabia algo de C, aunque no para PICs), se ha comprado tambien una placa Teensy (parecida a Arduino pero algo mas potente, creo) que tambien se programa en C o algo parecido (usa el mismo lenguaje que Arduino) resulta que mirando las expecificaciones de estas placas, le dice que por debajo 14uS los tiempos no son fiables, que pueden fallar, vamos.

Solo quiero decir que como vos presupones esto es mentira total, como si programarlo en C fuera a cambiar la velocidad maxima que puede ir el micro, solo que puede llevar mas tiempo de codigo y no alcanzar esa meta que tenes.

Tenemos otro problema y es que tenemos que hacer lecturas del ADC, de momento solamente una pero seran mas, creo que sera mejor hacerlas con otro PIC y transmitirle los datos a traves de la USART?

Yo pienso que depende del costo, si el costo no te varia mucho ( programador + IC ) por ahi convendria mas en gastar unos 0.5/1U$S que estar limitado con el sistema o que te lleve 3/4 semanas mas optimizando el codigo en ASM.
Y mas si puede llegar a ocurrir un cambio en el codigo mas adelante. Que vuelvas a tener que replantearte cada uno de los tiempos ( Y que seguro te olvidas alguno ).

[tapi8]

Solo quiero decir que como vos presupones esto es mentira total, como si programarlo en C fuera a cambiar la velocidad maxima que puede ir el micro, solo que puede llevar mas tiempo de codigo y no alcanzar esa meta que tenes.

No se si es mentira, es lo que pone en las especificaciones de esa placa segun me comenta esta persona, yo ni siquiera me moleste en leerlo, porque ya le dije que para lo que queremos hacer esas placas (Arduino, Teensy) no valen de nada o casi nada, solo se aprovecha el Uc y eso ya lo tenemos en PICs a la medida.

El micro va a la misma velocidad eso es obvio, pero si va a mucha velocidad y los tiempos no son exactos, no nos vale de nada ¿No?

Yo pienso que depende del costo, si el costo no te varia mucho ( programador + IC ) por ahi convendria mas en gastar unos 0.5/1U$S que estar limitado con el sistema o que te lleve 3/4 semanas mas optimizando el codigo en ASM.
Y mas si puede llegar a ocurrir un cambio en el codigo mas adelante. Que vuelvas a tener que replantearte cada uno de los tiempos ( Y que seguro te olvidas alguno ).

El coste aqui no es problema, ya que de momento haremos una unidad de prueba, si despues se comercializa ya seria otra cosa, pero tampoco seria mucho problema, ya que cada mosfet a usar cuesta mas que toda la parte de control, pero tiene que funcionar bien y si los tiempos no son correctos, NO funcionara bien.