As I see it, it would be like a regular local development environment that users are given remote access to. The spark API calls all happen as they do now. What is different is that the user will be developing via a remote spark core using a remote development environment. Setup like this:
In spark HQ, a spark core connected to the Keil debugger and to a usb port on a machine hosting a desktop OS. The OS would be run in a VM for easier manageability so this could eventually scale to multiple instances of different OSs (each with their own core) as demand grows.
The OS is configured with a spark development environment, the spark cli, Netbeans/Eclipse, the Keil debugger IDE etc…
Users gain access to the development environment via desktop remoting technology such as Remote Desktop on Windows, or VNC on linux.
After logging into the remote environment, the user writes code using the local IDE. When ready it is flashed to the connected spark core as normal (e.g. dfu-util.). The user can see output via the serial port, or use the software provided with the Keil debugger to visualize in detail what is happening in the core.
A booking system, access control etc. would be needed to provision the remote desktop instances.
With this in place, it would provide users the ability to debug their code on a spark core connected to the pricey Keil debugger.
If the user doesn’t need any hardware attached to the core to run their code then they can just get started. E.g. My use case was debugging the TCPServer stack to find out why there are sometimes delays of several seconds before handling a request. This use case would be ideal for this setup, as are all software-only setups, which are the easiest to get started.
Should a user need some hardware connected to the spark, then there are a couple of choices:
- communicate the hardware needs to someone on site so that it can be setup. Given the extra effort required by someone on side, I don’t envisage this being the norm, but it could be workable for cases where the bug is significant enough.
- rework the code to abstract out the external hardware. This is probably the best approach generally since it provides an isolated test case.
Finally, a fallback when debugging remotely isn’t possible for some reason, the debugging device could be shipped and loaned out to trusted developers. This might in fact be the initial mode of operation since we’ll obtain the Keil debugger before the rest of the infrastructure is in place.