#@eightycc (bob) re your PR, let's do a
gilded pecan
I may be misunderstanding: there's no way to add timestamps to other than console UART macro calls. If I don't enable console UART, I can't get that capability. Is that right?
often my casual debugging prints are via USB serial, so I do an explicit mp_printf(&mp_plat_print, call. This works fine but it's a lot to type. A macro or routine that includes the &mp_plat_print argument so I don't have to type it would be welcome.
hollow marsh
Ah ha! I misunderstood. I like the idea and will implement it.
I prefer putting it in the second PR for RAM logging, it's a general change that will fit there best. I can add a dynamic control(s) that adds a timestamp to other console destinations. Yes, I see what you mean by a lot to type. How about CP_DEBUGF?
gilded pecan
as for timestamps, that could be done at the mp_printf level, so it works for any stream, or there could even be a %<something> arg that is a timestamp
(written before you wrote you reply?
hollow marsh
Yes, exactly.
gilded pecan
or just MP_PLAT_PRINTF (since there's nothing about it that's necessarily for debugging in particular)
and in another PR is fine! I'll merge the current one.
gilded pecan
not that I can think of right now. Maybe there could be some comments in circuitpy_mpconfig.h about what the macros do, if it's not obvious.
hollow marsh
@danh I've been thinking about the "cooking" of line endings ('\n' -> '\r\n') that happens on some (but not all!) serial console output. I think it would be helpful to make whether or not line endings get "cooked" an attribute of the serial destination (UART, tud, BLE, etc.) instead of trying to get it right in the string to be printed. I'd like to see all serial output go through a single simplified path.
hollow marsh
Related, it may clarify/simplify messages (including logging) to have three virtual destinations: STDOUT, STDERR, and STDLOG. Each destination would have one or more default physical destinations that could be adjusted at run time.