Retardo de software vs temporizadores de hardware

Al trabajar con un microcontrolador, ¿en qué condiciones exactas deberíamos elegir entre temporizadores de hardware y retrasos de software en un controlador integrado?

He visto artículos que enfatizan el uso de temporizadores.

Si los temporizadores son tan buenos, ¿por qué se necesitan retrasos en el software?

Este es el enlace que describe el uso de s/w o temporizadores de hardware.

http://betterembsw.blogspot.in/2012/12/software-timing-loops.html

Pero esto no enfatiza el caso cuando los temporizadores h/w están disponibles en el controlador que estamos usando.

¿Cuál es el propósito de la demora? Sin esta información, esta pregunta es demasiado amplia para responder.
Debe aclarar qué quiere decir con retrasos tanto de software como de hardware. Los retrasos en el software pueden ser simples bucles o pueden depender de un temporizador de hardware, ya sea esperando un valor particular o mediante el uso de interrupciones. Tal vez un enlace a los artículos que mencionas pueda ayudar.
En general, el hardware cuesta dinero por unidad más NRE y el software cuesta solo NRE, por lo que normalmente se prefiere el software, siempre que funcione lo suficientemente bien como para cumplir con las especificaciones.
@SpehroPefhany: diría que dada la pregunta (ciertamente vaga) que dice "trabajar con un microcontrolador" , si tiene un micro y tiene temporizadores de hardware, generalmente es deseable usarlos donde sea práctico en lugar de escribir más software.
@JohnU Sí, estoy de acuerdo, si el periférico está ahí, casi siempre es mejor usar el hardware interno .
Creo que esta pregunta merece ser reabierta. La terminología está un poco fuera de lugar, pero es una pregunta típica de principiante con respecto al uso de temporizadores y formas de realizar retrasos.
@ Rookie91 Si menciona algunos artículos que ha visto y que son relevantes para su publicación, proporcione enlaces. Esto haría un mejor contexto para su pregunta.

Respuestas (3)

Por retrasos de hardware quise decir 'Temporizadores'.

La ventaja de usar temporizadores para realizar un retraso es que proporcionan una forma de permitir el conteo asíncrono. Al usar un "retraso de software", obliga al controlador a poner todos sus recursos en el procesamiento de algún tipo de bucle (incrementando una variable hasta un valor dado) y bloqueando así el resto de la ruta de ejecución del código.

Si la demora del hardware es tan buena, ¿por qué se necesitan las demoras del software?

Un retraso de software es más fácil de implementar y puede ser suficiente si es solo un retraso muy corto que no interrumpe significativamente ninguna otra tarea en la ruta de procesamiento de código secuencial principal. Además, los temporizadores pueden estar en uso para algunas otras tareas relacionadas con el hardware, como la generación de PWM, y es posible que no estén "libres" para configurarse de acuerdo con sus requisitos de retraso.

Otro caso de uso sería algún retraso inicial que se requiere antes de que se ejecute el ciclo principal. No habría necesidad de utilizar un retardo de hardware en ese caso.

Una última cosa que me viene a la mente es que un retraso de software no requiere que las interrupciones estén habilitadas globalmente, mientras que es un requisito para retrasos basados ​​en temporizadores (al menos para el caso de uso común).

No NECESITA una interrupción para un retraso del temporizador. Ciertamente puede sentarse en una línea y sondear el valor del temporizador. Pierde muchos de los beneficios de usar un temporizador, pero no necesita la interrupción. IIRC, de hecho, los temporizadores STM pueden establecer una bandera cuando haya alcanzado su tiempo objetivo, por lo que puede sondear la bandera sin siquiera sondear el conteo del temporizador.
@ScottSeidman: Cierto, complementé que es un "requisito" para el caso de uso común.

Siempre que sea posible, normalmente usaría un temporizador y un retraso de software por las siguientes razones

  • Un tiempo de retraso basado en un temporizador es fácil de calcular ya que sabe cuánto dura un tic. Un retraso de software puede optimizarse si su compilador es demasiado inteligente o dado que muchos procesadores modernos usan una tubería, es difícil calcular con precisión la cantidad de tiempo que tomará un bucle de software simple.

  • A menudo puede usar un temporizador para generar una interrupción para poder continuar con otras tareas.

¿Cuándo no usaría un temporizador?

  • Si no tuviera uno de repuesto

  • Si necesitaba un retraso realmente corto como, por ejemplo, configurar algunas líneas de puerto de salida para una dirección específica y luego bajar otra línea para indicar que quiero leer datos. Tal retraso puede ser tan corto como unos pocos ciclos de reloj, por lo que no sería beneficioso usar un temporizador.

Los temporizadores de hardware son muy precisos, pero normalmente hay un número limitado de ellos disponibles. Los temporizadores de software solo consumen ciclos de CPU y espacio de memoria, que son los únicos límites en el número que puede tener.

Un compromiso que se utiliza en muchos sistemas es configurar un temporizador de hardware para generar una interrupción de "tictac" periódica precisa a una velocidad conocida, y luego implementar una cantidad arbitraria de temporizadores de software (cuya resolución es el período de tictac) en función de esa interrupción. .

Las tasas de ticks varían, desde los 18,20651 Hz [1] utilizados en la PC IBM original, hasta los 10 kHz o más en algunos sistemas integrados en tiempo real.

[1] El valor exacto es 7166250 393609.216 H z . Brownie señala a la primera persona que puede explicar completamente de dónde viene este número.

Seguro que tiene que ver con los televisores a color... :)
Pensé que el reloj del sistema era de 14,31818 MHz, cuatro veces la portadora de color NTSC necesaria para generar la ráfaga de color para poder usar un televisor como monitor. Este reloj de 14 MHz se dividió por 3 para dar al procesador su reloj de 4,772727 MHz, que se dividió por 4 para alimentar el contador/temporizador del sistema a 1,193182 MHz, y se renueva a 65 536 para dar a DOS su tic de 18,20651 Hz. No estoy seguro de cómo se relaciona eso con tu ecuación, 7166250 393609.216 H z , aunque. Referencia técnica de IBM XT página 1-4.
@AdamDavis: ¡Ya casi llegamos! ¿De dónde viene el número de 14,31818 MHz?
@DaveTweed ¿Es esta otra historia de "parte trasera de los caballos --> diámetro del propulsor del cohete"? Frecuencia de explosión de color.
Exactamente. Todo se debe a que los televisores en blanco y negro originales tenían sus frecuencias verticales bloqueadas en la frecuencia de la línea de alimentación de 60 Hz, de modo que la interferencia de la línea de alimentación permanecería inmóvil en la pantalla.
60 H z ⋅ 525 2 ⋅ 1 1.001 ⋅ 455 2 ⋅ 4 3 ⋅ 1 4 ⋅ 1 2 dieciséis = 18.20651 H z
Retardo de software vs temporizadores de hardware
RespuestasAquíPolítica de privacidad1y, 4v