Would you consider to add API logging functionality to send text messages from spark to build mesage/log area ?
I know it can be implemented by events in future, but standard API call and integration into build Web IDE will make it much more easier for troubleshooting and debugging without physical access to Spark Core.
Message area of build should be expandable to multiple messages and each message should have timestamp and source (either from build or sparks).
@michal 100% definitely for sure, this one has been in the backlog for a while. I like your idea about each message indicating source (build or core) + timestamp. I clarified the spec to include this. Thanks for sharing!
We don’t yet have a great way to share our backlog; we’re using Asana to track tasks internally and I’m not aware of a good way to share the backlog without picking up a new tool.
A “Virtual UART” of some sort would be pretty bitchin’ too! So right now, the Core has two UARTs; the backchannel UART accessible over USB and another UART accessible on two pins, right? So what if you added a virtual one that would be accessible on the Spark Build page as an interactive console?
This way would be super useful for remote debugging and/or remote configuration! (Let’s say I had a simple program that controlled some lighting or something and the Spark Core was installed in a permanent electrical fixture in my wall. If I wanted to change some settings or something, this way I could use simple, easy to implement serial commands instead of having to setup a complex web app.)
An excellent idea indeed @timb—and we’re a step ahead of you. A “Virtual UART” has been in our “that would be so awesome” list for a couple months now. We plan for the firmware to call it with Spark.write, Spark.read, Spark.println, etc.
@michal I like the idea of having publicly available specs, it’d be sweet to link from a thread like this to the spec and back and incrementally refine it collaboratively in a community context. As @zach mentioned, we’re currently using Asana for our backlog, and going straight from there to a public context wouldn’t work well at all.
I have a simple idea to facilitate the community specs idea…will discuss with the dev team and get back to you. In the meantime, if you have particular ideas of how to go about this, please share.