¿Por qué se prefiere el búfer de anillo para la comunicación asíncrona?

FLASH y EEPROM tienen problemas de resistencia con varias escrituras en la misma ubicación, pero eso no afecta a la RAM, que es donde normalmente se almacena un búfer de anillo para comunicaciones asíncronas. Las dos razones principales en las que puedo pensar son:

• Muchos protocolos comunes no siguen la secuencia secuencial de comando / respuesta que describe. Por ejemplo, los receptores GPS envían una transmisión bastante continua, por lo que es importante poder seguir recibiendo datos mientras se procesan los datos anteriores.

• Debido a que los buffers de anillo a menudo son necesarios para ese tipo de protocolos, es más conveniente usarlos para todas las comunicaciones asíncronas. La única sobrecarga adicional real es la necesidad de una cola de cola y una cabecera, que en muchos casos solo será de un solo byte.

Teniendo en cuenta sus restricciones si escribe en la RAM, simplemente reinicie el búfer al final de un mensaje y comience nuevamente desde el inicio del búfer. Pero los usos son tan limitados y las ventajas tan pequeñas que la mayoría preferiría usar un búfer de anillo en todas las aplicaciones.

Primero que nada, como otros han señalado, cualquier búfer de comunicación estaría en la memoria RAM, no en flash o EEPROM, por lo que no hay problema con el desgaste de la memoria.

La razón principal que veo para usar buffers de anillo para la comunicación, es cuando usa una rutina de servicio de interrupción (ISR) para manejar los caracteres entrantes. El ISR es el productor, y el nivel base (sin interrupción) es el consumidor. Junto con el búfer de anillo hay dos punteros, uno para la ubicación del carácter para almacenar el siguiente carácter entrante y el segundo para mantener un registro del último carácter recuperado del búfer. Cuando los punteros son iguales, el búfer está vacío.

Al usar un búfer de anillo, el sistema puede manejar los caracteres que ingresan a una velocidad alta (por ejemplo, cada 87 µs para 115.2 KBaud), y no preocuparse de que se procesen de inmediato (asumiendo que el búfer es lo suficientemente grande como para manejar el retraso). entre la recepción y la recuperación).

Esto sería importante, por ejemplo, en un RTOS no preventivo donde no se produce un cambio de tarea hasta que la tarea actual cede voluntariamente el control del sistema operativo. Mientras tanto, el ISR recopilará caracteres en segundo plano y, cuando se produzca el cambio de tarea, probablemente la tarea para procesar los caracteres entrantes se ejecutará a continuación.