I suppose you could write a circular buffer into flash, but you risk shortening the life of your product.
For ad-hoc use, you can have people telnet into the X2 and do the “set trace state=on mask=printf:*” to see your print statements in realtime as they occur.
If you want something formal with a better history which you control, the you could write a simple thread-based buffer which waits for a telnet-like connection, then dumps perhaps the last 50 “messages” upon connection, then shows new messages in realtime as they are passed to this thread. This would give you some ability to have some print-like messages real-time only & not buffered, while others might buffer.
Since you are using the X2, you’d need to be careful with memory usage, plus manually force garbage collection at the appropriate times since the ‘print’ strings will need to be detected as freeable periodically.
> Since you are using the X2, you’d need to be careful
> with memory usage, plus manually force garbage
> collection at the appropriate times since the ‘print’
> strings will need to be detected as freeable
The garbage collection idea is possibly good for other reasons. However, the strings will not need manual garbage collection. They’ll either be completely persistent because they are not template copies, or if they are will lose all references and be cleaned up immediately right after the print completes.
Using the ‘set trace’ command is good as mentioned for ad-hoc usage. For more visibility, I recommend offloading the log if possible. I would check out the ‘logging’ module from the standard library in conjunction possibly with one of its handlers to get the message off the system to syslog or an NT event log for example. You can log to the file system this way as well, you’ll just want to consider the impact on the flash. At a fairly low message frequency, erase-write cycles are probably not a large problem.