This is something I've considered for a while since Ken's post about programming via iPad (or other light-weight devices like my Android phone).
I'm interested in exploring the idea of porting the Propeller-Tool (or other "compiled") Propeller development system entirely to the web browser context. The requirements of the system would be to function almost identically to the Propeller Tool. For lack of a better name, I would call this a Propeller-WebTool.
While it the concept may be oriented toward a web browser, it is theoretically possible to use this framework with any Propeller module having an SD Card and a serial port.
A Propeller-WebTool SystemWhat would be a Propeller-WebTool development system? Major components:
5. A Network Enabled Propeller Device. The target device for programming.
That list is essentially the same as what we have today except the last item. Addressing each item in turn as required ....
1. A compiler.The compiler is high on the list of complexities and costs. Please note that this thread is about "compiled" languages (like SPIN, C, PropBasic) moderators will receive requests for off topic posts.
For this particular concept, having the compiler run in the client's web-browser would be ideal especially because of the cheap and light-weight wireless (Bluetooth, Wifi, or Xbee) devices that can provide serial connectivity to the Propeller chip.
I have some questions:
Apparently yes, but how do I interact with it?
2. Will it run in all web browsers? Apparently not Internet Explorer:
"Assertion failed: Cannot fallback to non-typed array case: Code is too specialized."
Can that be fixed?
3. Can the resulting code be modified to use a buffer (DOM textarea) as input for compile?
5. Can other language compilers be ported?
There is also the Adafruit supported WebIDE. Can that be configured for Spin syntax?
For example, in the case of RPi it is easy because everything can go into the RPi SDCard file-system. In the case of other devices the on-board Propeller SDCard would be used for user's Propeller-WebTool storage.
3. A LoaderA loader would need to be written. It could be part of the compiler, but it would not be a standard Propeller loader. The current Propeller loader is not tolerant of delays that would be caused by network issues. While determinism is great, in this respect insisting on it is actually a problem.
The loader needs to be "2 sided." That is, on the web-browser "client side", a transfer mechanism should be worked out that is compatible with the Propeller target "host side" protocol. The client/host protocol must be tolerant of network delays. We have lots of these kind of details already worked out in the Propeller-GCC loader's XMM serial_load protocol.
4. A TerminalA terminal would be required for "debug output" or just general message input/output on the target Propeller Device. It is not clear what code might be available to act as a serial port web terminal. The protocol application layer used must be very light-weight. The terminal program should attempt to automatically choose the device to use.
5. A Network Enabled Propeller DeviceA target Propeller device should be network enabled. This could be achieved using Bluetooth, Wifi, Xbee, or another device like Rasberry PI. The Propeller lower 32KB EEPROM would contain a boot-loader program (upper 32KB should be available for the user). The boot program would talk to the serial port to handle programming packets. This program would reside entirely in a COG and allow overwriting all of HUB RAM. One difficulty involves resetting the device because not all network virtual serial port devices have a control signal that can be used for remote reset.
Final thoughts.Someone might say that this is all solved with the RPi or other super cheap Linux box. Well it is, but the only thing different really is that the compiler itself would run on the host system in the case of RPi. The other elements discussed are web-enabled supplements. And theoretically could work with any Propeller with SD Card attached.