debug.print x100 per second, I’d suggest you will struggle with the data rate, irrespective of getting it into a file. There’s a lot of things debug.print is good for, but this I’m suspecting is not one… string manipulation will likely put you in a GC spin.
I ran this program for about 30 mins last night. The number of entries in the output matched the frequency of printing and duration of the experiment while simultaneously running the main app with a barely noticeable lag in performance from time to time. So I have no worries about this not working, it’s just an experiment to gather data about my battery life anyway.
I think it works because my app doesn’t have much work to do, it just needs to accomplish it quickly (in terms of human perception of latency) when it has work to do. So adding prints is probably just filling in the dead time.
I imagine after 180000 prints the GC ran multiple times (right?) that would explain the occasional hiccup anyway. But I’m not sure. When I’m not using the wireless link (which i’m not in this experiment) the Debug.Print would be the only thing causing allocation.
I found out I can save the contents of the Output Window after the fact using File -> Save Output. This gets the job done but a more configurable solution using redirection or something like that is still welcome. I still have to go in and clean out lines not printed explicitly by my code.
ah, if it’s just your own data logging interest/concern and you’re not really doing too much other processing, there’s a chance it’ll work. You can even try to be smart(er) a bit about allocating strings and concatenating, all those things create more work for the GC…
Of course debug.print is just one way to get data out a serial port and into a PC. Using a terminal program (teraterm etc) you can direct output to a file easily, and don’t need to worry about a crash or something else causing a disruption. I’d set up a serial connection to a PC and do it explicitly rather than the hassle of figuring out how to get output windows or mfdeploy output captured.
Well, I have no idea what changed since the other day. I used git to keep it the same! Maybe I simply got lucky a few times in a row with how the CLR was scheduling things. But everything you said came to fruition and it is only good for a couple minutes before it just freezes with no output or exception-thrown messages.
Serial link it is, then.
@RoSchmi thanks for sharing this MFDeploy based project. It is in my list of future tasks to explore MFDeploy and try to eliminate my need to distribute third party software including Fez Config. I hope this comes in handy for studying.