Uso de la función putch () diferente en una biblioteca

Estoy escribiendo una biblioteca C para microcontroladores PIC18 que se comunicarán con el chip ESP8266 a través del bus UART. Me gustaría usar la printf()función para enviar cadenas formateadas al chip.

En XC8, printf()utiliza la función putch()que el usuario debe definir como salida. De esta forma, el usuario puede decidir si usar UART, LCD, ... para stdout.

Esto me da un problema. En la biblioteca, quiero usar printf()la que se basa en putch(), pero no puedo (no debo) declarar putch()en la biblioteca porque eso generaría un conflicto cuando un usuario quiera usar el ESP8266 en combinación con una pantalla LCD para la que ya definió putch(). ¿Como puedó resolver esté problema?

Podría usar sprintf()para almacenar temporalmente la cadena en la memoria y luego escribir mi propio código para escribir este byte por byte en el ESP, pero prefiero no hacerlo debido a la ineficiencia de la memoria y el tiempo.

También podría lanzar el mío esp8266_printf()con una funcionalidad limitada y usarlo en su lugar, pero eso tampoco se siente tan bien.

¿Hay una solución limpia (er) para esto?

Nota: esto puede parecer programación pura, pero este truco no es C estándar y, como tal, esta pregunta no es programación estándar y solicita una respuesta ajustada a PIC.
No hay fprintf()disponible?
@IgnacioVazquez-Abrams no, lamentablemente no.

Respuestas (1)

Puede crear un PUTCH personalizado que decida en tiempo de ejecución qué hacer con el byte. Esto se basaría en una configuración global que usted mantenga. Cambiaría la configuración global para enrutar a los personajes a donde quiera que vayan en ese momento. Uno de ellos puede ser la rutina de un cliente, aunque tendría que llamarse de otra forma que no sea PUTCH.

¡Gracias! Eso funcionaría, pero con cadenas largas, ¿no tendría un gran impacto en la eficiencia del tiempo verificar esta configuración global en cada llamada putch()?
La verificación de un valor booleano y if'ing en su valor no debería llevar mucho tiempo en comparación con la escritura en un UART o LCD.
@Camil: Como dijo Wouter, el cheque adicional y la sucursal serán mínimos. La sobrecarga más grande es la llamada de subrutina anidada y el paso de argumentos, el ahorro de estado, etc. Si realmente le preocupa esto, escriba su PUTCH especial en ensamblador. De esa manera, puede hacer la prueba muy rápidamente y evitar la mayor parte de la sobrecarga de otra capa de subrutina. Por ejemplo, puede IR A la subrutina de destino, que luego regresará a la persona que llamó PUTCH. Debe observar con mucho cuidado cómo su compilador realiza el enlace de subrutinas, pero si se hace correctamente, la capa adicional solo debería ser de unos pocos ciclos.
Muy bien, en ese caso simplemente iré por este camino y lo miraré de nuevo si se vuelve lento. ¡Gracias!