Wouldn’t Upsave and Download be more correct when using remote resources?
Have never seen the phrase Upsave but for me it makes sense when using a resource at a higher level than the one I’m working from.
It's confusing. Browsers traditionally haven't been used to run applications like Spin compilers and editors. So as far as the browser makers are concerned the reason you are fetching a file from your local file system is to send it to a remote server. Eg, sending an attachment to Parallax. That is an "upload". Likewise "download". Everything went straight through the browser.
With the arrival of HTML5 and "web apps" this starts to sound a bit odd.
Now that I read your post again I'm not sure I know what you meant by "Prop-to-Prop communication over the web[/internet]". What did you have in mind?
Are we talking adding a gadget to the system that does IP on be half of the Propeller? Say a wifi dongle or serial to ethernet device, or what?
Are we talking putting a IP stack in the Propeller and giving it a ethernet physical interface somehow?
If I wanted to have two Propellers communicating of the internet I would have them both connected to Raspberry Pis or, something similar, and let that take care of all the networking stuff. Simple, cheap, flexible.
Which brings us to that idea of using two Propeller's, one to act as the network node, serving up the web IDE and other files, and programming a second Propeller that is the "target" for the user application.
That's a fine idea as it means your communication node cannot be messed up by faulty user programs. But I cannot see a Propeller system fulfilling that role as cost effectively or capably as a cheap ARM board. The Raspberry Pi is one example there are increasingly more on the market.
P.S. I was going to edit away my Ganges comment as I started to think it was in bad taste. But now i have been quoted so there is no point I guess.
I was just thinking that maybe by setting up IP conduits between Propellers, we could exploit the internet as a serial connection, purging all the Ganges bilge water. How this could be done, I'm not sure. It would be neat if we could exploit those cheap USB wi-fi dongles and converse with them at "full speed" 12MHz. Do you know if those dongles fit within some class of Microsoft USB devices, so that their interfaces are known and static?
I think that Prop to Prop, or Prop to whatever IP conduit is a great goal. I would love to see Propeller boards fitted out with these serial to IP devices: http://www.lantronix.com/device-networking/embedded-device-servers/xport.html however at 55 dollars a pop I'll stick with my somewhat bigger Raspberry Pi's as IP adapters.
The WIZnet Serial to Ethernet gateways are nice but again for what you get a Raspi is a better deal.
The ability to handle USB WiF dongles is the only cost effective way at $10 - $15 each connection. If you get much more, you may as well go with a Raspberry Pi solution or a router hacked with WRT.
You guys are killing me by starting all these totally interesting threads that I want to chime in on while I'm away from the forum engaging in real life for a few days. I come back and the thread is 30+ deep and I've missed so much. I have a ton of thoughts about this stuff going in a million directions, but I'll try to stay on point.
I like the idea of the letting the flakey stuff be flakey, as it is wont to be, and getting the important stuff safely secured on something that is known.
I really like this line of thinking. I don't worry as much about the closed nature of the companies building our computing infrastructure as much as I worry that we've just been in such a hurry to get everything built that we might've missed some great and important ideas along the way.
I think every device will be supporting web browsing, without any special contracts, or extras required.
Not sure if that includes devices built from the Propeller 2, though. Im sure therell be some kind of browser for it at some point, but I think a modern web browser (HTML5, CSS3, fast JS engine) is probably too much to ask for. This is not exactly what you're asking, but it's been on my mind.
Available for all OS's, tablets etc., essentially equivalent of serial over tcp/ip with a vt100 equivalent terminal.
There is also VNC and RDP, both require more work, both available for every os.
+1! ssh would be no walk in the park to implement, but restricting support to elliptical curve cryptography might be easier, not to mention much faster, but limits the choice of ssh clients to newer ones. Dropbear is probably the place to start, once a C compiler and OS are available. (rereading that made me laugh... "yeah! the *only* thing we need is a C compiler and an OS!")
VNC would be a lot more straightforward, even the more sophisticated encoding modes.
IMHO the best way to go there is development on the P2 itself. You do not need a browser/pc/tablet at all. just P2, Keyboard, Monitor and software running on the P2.
I think this is probably the holy grail for a lot of P2 watchers. Someone mentioned in the big thread once that they hoped that the P2 would be the platform from which Chip would design the P3, but until FPGA layout software, and board layout software, etc. run on the P2, thats not really possible. But following Chips thoughts above about "let the flaky stuff be flaky", if a Prop2 machine could do everything else then an RDP client on that Prop2 could provide access to a flaky Windows machine running the necessary software.
Ah, you say, the browser cannot interact with the local machine, read files and so on. So what? just put a simple server on the local machine. Written in Python or JavaScript or whatever you like.
The HTML5 File API can access the local machine. And it's (actually) not a badly designed API! BTW, awesome code drop. It's a big part of my day job (too?), so it's really neat to me that you guys are mixing this chocolate with that peanut butter.
Ok, to answer Chip's original thoughts: if the Propeller 2 can drive an ethernet PHY (even at 10BASE-T speeds, this is something to consider for SERDES), then I guarantee that a browser-based editor will be built. Even being able to connect with a wifi IC will probably be enough. From there a TCP/IP stack will be built (if it's not already on the chip), then a web server, and then all you have to do is serve up the in-browser IDE Heater showed off above. Enable the File API and you can send local compiled & saved files to the server on the P2. Easy(ish). Make the server a little smarter and it can write to a local SD, twiddle pins, maybe fire up Forth programs with GET/POST params. Just point your browser to http://propeller2/4th/streaming_sampler.4th?in_pins=1,2,3,5,6,7&rate=20000 Lots of possibilities there.
I promised to stay on-point, but I wanted to throw a new idea out there. If USB 1.1 is possible, then it may be possible to present the Prop2 to a USB host as a USB network device. Since it would be purpose-built it can do anything with the packets the host gives it. It can respond to DHCP packets and configure the network device on the USB host, it can respond to DNS, it can even serve up... an in-browser Prop2 IDE. Or anything really. Maybe even serve up a frame buffer as an MPEG-1 stream (I-frames only). I did some math on how many ops it takes to do the JPEG/MPEG DCT and while I'm pretty sure it's not possible even for VCD quality, it's close enough to suggest.
One last thought: my wife played with a little programmable board a few years ago called the Little Schemer that had a browser-based programmer that sent the byte code to the uc via a photodiode. You'd hold the board up to the screen and it would reprogram like magic. Limited but very, very slick. Hit the "Send" button at the link above to see an example.
The HTML5 File API can access the local machine...
can you post a example of this? All I found was using the file api for accessing a browser based File System. NOT the local machine.
Ok, to answer Chip's original thoughts: if the Propeller 2 can drive an ethernet PHY (even at 10BASE-T speeds, this is something to consider for SERDES), then I guarantee that a browser-based editor will be built. Even being able to connect with a wifi IC will probably be enough. From there a TCP/IP stack will be built (if it's not already on the chip), then a web server, and then all you have to do is serve up the in-browser IDE Heater showed off above. Enable the File API and you can send local compiled & saved files to the server on the P2. Easy(ish). Make the server a little smarter and it can write to a local SD, twiddle pins, maybe fire up Forth programs with GET/POST params. Just point your browser to http://propeller2/4th/streaming_samp...6,7&rate=20000 Lots of possibilities there.
All of this is already done on the P1 (Spinneret). The Editor/Compiler @Heater. showed above does exactly what you are describing here and can run from a Spinneret including access to SD and running programs with a link+querystring. Alas them are not forth programs, but Pasm binaries loaded into a cog for execution.
What still is missing on Spinneret-msrobots is to program another Propeller from the created binary saved on the SD. I sort of got stuck there and was happy to get distracted by David to implement support for his loader using the S6B WIFI module Parallax sells.
I really like your example with a photodiode. This is quite cool. Someone smarter than me needs to figure out how to do that and what transfer rate could be archived. Like David's Prop resident loader for the S6B we would need a resident loader on the prop reading the photodiode and saving to the upper EEPROM. Anyone?
This might be the cheapest way to go. Possible slow but has quite some cool factor to it. Another positive thing on it is that it should work even on I-phones not giving you access to serial ports.
@Heater still claims that a Editor Chrome Apps could be done using local serial ports. I looked at it and as usual he is right. But reading further Chrome Apps do not support a lot some stuff I do in the Editor. Solvable but hairy. I need to replace all alert(), confirm() and window.open() by something else for the Chrome App. This could work but restricts us to Chrome. Will not run anywhere else.
I sort of dislike that.
By now I can run the editor from windows with IE and with Chrome. Did not have any other browser to test with and feel no need to install all of them.
@Heater is not using windows since 1996(?) or so. So he is the guy for those Linux Systems. As far as I know all of it is working on that side.
@David is using Mac's I think and is able to use it too.
@Jazzed tried on I-phone and Android and while slow and cumbersome (small screen) it did work using the S6B loader.
Sure. By now the Editor is not pretty and nice, but clobbered together as proof of concept. First function, then style. Its gray in gray and made to look like the PropTool.
(gray in gray. like the famous Austrian? War Flag... white Eagle on white ground...)
this runs on a windows server somewhere in Europe and saving of files on that server is not allowed. You can download to your own computer instead of saving. Or save on @Heaters server, if you remember the url...
I think it would be great to be able to program the Prop, both versions and also the Stamps using a Tablet. Am I missing something here or is it currently possible to program the Prop from a Tablet?
Try out the link above. I do not have any tablet but @Jazzed tried it with Android and I-phone? pad?
@Cluso99 had it - slow - working on Zoom.
By now you can edit your program and compile it just in any(?) browser. First call will be slow. Next ones will be faster.
As for programming the only working solution (as of now) is David's loader for the S6B Parallax WIFI module. (more things in development, but not working yet)
I can not tell you much about that since I still do not have any of those modules. I just added support for them in the editor. @Jazzed and @David where able to run it successful.
And completely unrelated - Before I could order the stuff you advised me to get, the bounty part worked out. So I have the keys back for my second SL.... But thanks anyway!
Yes, I'm able to program my ActivityBoard with Digi XBee S6B from iPad and Android phone with the Editor webapp. The Propeller is running Davids xbee-server application that uses the S6B to download programs to upper 32KB of the 64KB EEPROM. When the load is complete, a Propeller COG reads the program into HUB memory and starts it up. The board must be reset manually, and the Propeller program just waits for the Send S6B button click in the browser.
It will take some work to make the Editor webapp "mobile friendly" though. The Android phone experience is terrible. The iPad experience was Ok because of better performance, a bigger screen, and somewhat better editor operation.
There must be a way to get the same code running as a Chrome App or a regular WEB page. Like testing for which browser you are running on and doing different things accordingly. Presumably there is an alternate way of doing alerts and such in a Chrome app. It's more work of course but there we go.
My msrobots editor is not running at the moment I hope to get it back on line soon, today perhaps.
You can run the samples just by going through the menu tools->extensions. Or just visit "chrome://extensions".
Set the "developer mode" check box to on.
Hit the "load unpacked extensions" button.
In the file selection dialog that pops up just select the directory containing the app you want to install into chrome.
For example public/chrome-app-samples/serial/ledtoggle/
Then hit the launch link.
That's the same page I started from. The only download link I see there is to the "hello world" app which a link to the chrome-app-samples repository on github. No google account required to get that code. Just:
Took me a while to figure out how to start the Demos.
Tools>Extensions. Hmm. Found no way to start them direct.
But serial control signals demo finds my Spinnerets as comport and is able to reset them via RTS checkbox. Nice.
Since I do not own a arduino nor a android the other serial demos did not run. So I looked thru the source. Confusing.
A Chrome App looks not doable without forking the Editor into two different ones. Still doable, but I am not really happy with it.
A positive thing is the amount of APIs. File System. Google Drive. GitHub-Auth. Nice. But its just one Vendor. And Google is in no way better than MS. Big Company. Big dependencies.
Sort of like Rays IE only solution. One Vendor. Big Company. Big dependencies.
As of now the Editor supports multiple browser on multiple OSes. It can load and save files according to RFC HTTP standards. On windows/Linux and Node servers. Even on the Spinneret (if you can live with Fat32)
The S6B loader seems to work. I do not have one but Jazzed and David where able to use it. Even from some tablet PCs.
I am not sure how proceed with Chrome Apps and will need to think about it.
OK that's great. You managed to reset a Spineret. I have not yet connected an actual device and seen my Chrome port working with it.
I had a quick look at the source. Might be confusing but most of it we don't need to understand completely. Just use it!
As far as I can tell the only thing you need a little manifest and a background script. Perhaps those icons. It should be possible to keep everything else the same. I would be very surprised if we cannot use exactly the same files as both a Chrome app and the normal web page app.
But its just one Vendor. And Google is in no way better than MS.
I do agree that I would hate to have to build HTML5 apps for Chrome that don't work as normal web content on other browsers.
So I would not like to use two many of those Chrome App only API's.
But If we can use the same stuff as a webpage and a Chrome app with only ten lines of code difference it seems reasonable.
In this case we can always get serial port access via little local web server anyway.
Not much like MS. This stuff is all open source after all.
Edit: Seems you are right. This Chrome App thing needs looking at. I just added a manifest, background and icon files to my Editor17 directory. I can now load it as a Chrome app and the HTML displays fine. None of the JS scripts run though. It complains about "security" and "content policy".
The good news is that I did manage to compile the propeller-load from propgcc using Emscripten. We almost have a JS loader!
Comments
Wouldn’t Upsave and Download be more correct when using remote resources?
Have never seen the phrase Upsave but for me it makes sense when using a resource at a higher level than the one I’m working from.
With the arrival of HTML5 and "web apps" this starts to sound a bit odd.
"upsave"? Nice idea, also sounds very odd though.
I was just thinking that maybe by setting up IP conduits between Propellers, we could exploit the internet as a serial connection, purging all the Ganges bilge water. How this could be done, I'm not sure. It would be neat if we could exploit those cheap USB wi-fi dongles and converse with them at "full speed" 12MHz. Do you know if those dongles fit within some class of Microsoft USB devices, so that their interfaces are known and static?
P.S. "Upsave" sounds intuitive to me.
I think that Prop to Prop, or Prop to whatever IP conduit is a great goal. I would love to see Propeller boards fitted out with these serial to IP devices: http://www.lantronix.com/device-networking/embedded-device-servers/xport.html however at 55 dollars a pop I'll stick with my somewhat bigger Raspberry Pi's as IP adapters.
The WIZnet Serial to Ethernet gateways are nice but again for what you get a Raspi is a better deal.
I really like this line of thinking. I don't worry as much about the closed nature of the companies building our computing infrastructure as much as I worry that we've just been in such a hurry to get everything built that we might've missed some great and important ideas along the way.
Not sure if that includes devices built from the Propeller 2, though. Im sure therell be some kind of browser for it at some point, but I think a modern web browser (HTML5, CSS3, fast JS engine) is probably too much to ask for. This is not exactly what you're asking, but it's been on my mind.
+1! ssh would be no walk in the park to implement, but restricting support to elliptical curve cryptography might be easier, not to mention much faster, but limits the choice of ssh clients to newer ones. Dropbear is probably the place to start, once a C compiler and OS are available. (rereading that made me laugh... "yeah! the *only* thing we need is a C compiler and an OS!")
VNC would be a lot more straightforward, even the more sophisticated encoding modes.
I think this is probably the holy grail for a lot of P2 watchers. Someone mentioned in the big thread once that they hoped that the P2 would be the platform from which Chip would design the P3, but until FPGA layout software, and board layout software, etc. run on the P2, thats not really possible. But following Chips thoughts above about "let the flaky stuff be flaky", if a Prop2 machine could do everything else then an RDP client on that Prop2 could provide access to a flaky Windows machine running the necessary software.
The HTML5 File API can access the local machine. And it's (actually) not a badly designed API! BTW, awesome code drop. It's a big part of my day job (too?), so it's really neat to me that you guys are mixing this chocolate with that peanut butter.
Ok, to answer Chip's original thoughts: if the Propeller 2 can drive an ethernet PHY (even at 10BASE-T speeds, this is something to consider for SERDES), then I guarantee that a browser-based editor will be built. Even being able to connect with a wifi IC will probably be enough. From there a TCP/IP stack will be built (if it's not already on the chip), then a web server, and then all you have to do is serve up the in-browser IDE Heater showed off above. Enable the File API and you can send local compiled & saved files to the server on the P2. Easy(ish). Make the server a little smarter and it can write to a local SD, twiddle pins, maybe fire up Forth programs with GET/POST params. Just point your browser to http://propeller2/4th/streaming_sampler.4th?in_pins=1,2,3,5,6,7&rate=20000 Lots of possibilities there.
I promised to stay on-point, but I wanted to throw a new idea out there. If USB 1.1 is possible, then it may be possible to present the Prop2 to a USB host as a USB network device. Since it would be purpose-built it can do anything with the packets the host gives it. It can respond to DHCP packets and configure the network device on the USB host, it can respond to DNS, it can even serve up... an in-browser Prop2 IDE. Or anything really. Maybe even serve up a frame buffer as an MPEG-1 stream (I-frames only). I did some math on how many ops it takes to do the JPEG/MPEG DCT and while I'm pretty sure it's not possible even for VCD quality, it's close enough to suggest.
One last thought: my wife played with a little programmable board a few years ago called the Little Schemer that had a browser-based programmer that sent the byte code to the uc via a photodiode. You'd hold the board up to the screen and it would reprogram like magic. Limited but very, very slick. Hit the "Send" button at the link above to see an example.
can you post a example of this? All I found was using the file api for accessing a browser based File System. NOT the local machine.
All of this is already done on the P1 (Spinneret). The Editor/Compiler @Heater. showed above does exactly what you are describing here and can run from a Spinneret including access to SD and running programs with a link+querystring. Alas them are not forth programs, but Pasm binaries loaded into a cog for execution.
What still is missing on Spinneret-msrobots is to program another Propeller from the created binary saved on the SD. I sort of got stuck there and was happy to get distracted by David to implement support for his loader using the S6B WIFI module Parallax sells.
I really like your example with a photodiode. This is quite cool. Someone smarter than me needs to figure out how to do that and what transfer rate could be archived. Like David's Prop resident loader for the S6B we would need a resident loader on the prop reading the photodiode and saving to the upper EEPROM. Anyone?
This might be the cheapest way to go. Possible slow but has quite some cool factor to it. Another positive thing on it is that it should work even on I-phones not giving you access to serial ports.
@Heater still claims that a Editor Chrome Apps could be done using local serial ports. I looked at it and as usual he is right. But reading further Chrome Apps do not support a lot some stuff I do in the Editor. Solvable but hairy. I need to replace all alert(), confirm() and window.open() by something else for the Chrome App. This could work but restricts us to Chrome. Will not run anywhere else.
I sort of dislike that.
By now I can run the editor from windows with IE and with Chrome. Did not have any other browser to test with and feel no need to install all of them.
@Heater is not using windows since 1996(?) or so. So he is the guy for those Linux Systems. As far as I know all of it is working on that side.
@David is using Mac's I think and is able to use it too.
@Jazzed tried on I-phone and Android and while slow and cumbersome (small screen) it did work using the S6B loader.
Sure. By now the Editor is not pretty and nice, but clobbered together as proof of concept. First function, then style. Its gray in gray and made to look like the PropTool.
(gray in gray. like the famous Austrian? War Flag... white Eagle on white ground...)
for those who need a link to test ... http://parallax.msrobots.net/Editor17.htm
this runs on a windows server somewhere in Europe and saving of files on that server is not allowed. You can download to your own computer instead of saving. Or save on @Heaters server, if you remember the url...
Enjoy!
Mike
Yes it is - within bounds -
Try out the link above. I do not have any tablet but @Jazzed tried it with Android and I-phone? pad?
@Cluso99 had it - slow - working on Zoom.
By now you can edit your program and compile it just in any(?) browser. First call will be slow. Next ones will be faster.
As for programming the only working solution (as of now) is David's loader for the S6B Parallax WIFI module. (more things in development, but not working yet)
I can not tell you much about that since I still do not have any of those modules. I just added support for them in the editor. @Jazzed and @David where able to run it successful.
Look for the thread from Jazzed in the P1 forum. here: http://forums.parallax.com/showthread.php/152711-A-Propeller-WebTool-Framework-for-Compiled-Languages/page11
And completely unrelated - Before I could order the stuff you advised me to get, the bounty part worked out. So I have the keys back for my second SL.... But thanks anyway!
Enjoy!
Mike
Yes, I'm able to program my ActivityBoard with Digi XBee S6B from iPad and Android phone with the Editor webapp. The Propeller is running Davids xbee-server application that uses the S6B to download programs to upper 32KB of the 64KB EEPROM. When the load is complete, a Propeller COG reads the program into HUB memory and starts it up. The board must be reset manually, and the Propeller program just waits for the Send S6B button click in the browser.
It will take some work to make the Editor webapp "mobile friendly" though. The Android phone experience is terrible. The iPad experience was Ok because of better performance, a bigger screen, and somewhat better editor operation.
There must be a way to get the same code running as a Chrome App or a regular WEB page. Like testing for which browser you are running on and doing different things accordingly. Presumably there is an alternate way of doing alerts and such in a Chrome app. It's more work of course but there we go.
My msrobots editor is not running at the moment I hope to get it back on line soon, today perhaps.
You need to register a Google Account to even Download Demo Apps.
Not even Microsoft is so gross.
Unhappy!
Mike
No you don't. I downloaded the chrome app samples from here https://github.com/GoogleChrome/chrome-app-samples. Just use git clone.
You can run the samples just by going through the menu tools->extensions. Or just visit "chrome://extensions".
Set the "developer mode" check box to on.
Hit the "load unpacked extensions" button.
In the file selection dialog that pops up just select the directory containing the app you want to install into chrome.
For example public/chrome-app-samples/serial/ledtoggle/
Then hit the launch link.
I was just following the instructions from here: https://developer.chrome.com/apps/first_app
The serial port example works.
You will need to "Experimental Extension APIs" in the chrome://flags page. And be sure you have permissions to use the port.
One can package Chrome apps for down load by users, they have to install into chrome as above.
P.S. When you said "Chrome App Demos" did you mean something different to the examples on github? Got a link?
wants a google account to download anything they offer
Mike
That's the same page I started from. The only download link I see there is to the "hello world" app which a link to the chrome-app-samples repository on github. No google account required to get that code. Just: and you have then have all 77 samples showing off all the chrome app API.
Forget about hitting those "Try it now" buttons.
Took me a while to figure out how to start the Demos.
Tools>Extensions. Hmm. Found no way to start them direct.
But serial control signals demo finds my Spinnerets as comport and is able to reset them via RTS checkbox. Nice.
Since I do not own a arduino nor a android the other serial demos did not run. So I looked thru the source. Confusing.
A Chrome App looks not doable without forking the Editor into two different ones. Still doable, but I am not really happy with it.
A positive thing is the amount of APIs. File System. Google Drive. GitHub-Auth. Nice. But its just one Vendor. And Google is in no way better than MS. Big Company. Big dependencies.
Sort of like Rays IE only solution. One Vendor. Big Company. Big dependencies.
As of now the Editor supports multiple browser on multiple OSes. It can load and save files according to RFC HTTP standards. On windows/Linux and Node servers. Even on the Spinneret (if you can live with Fat32)
The S6B loader seems to work. I do not have one but Jazzed and David where able to use it. Even from some tablet PCs.
I am not sure how proceed with Chrome Apps and will need to think about it.
Enjoy!
Mike
OK that's great. You managed to reset a Spineret. I have not yet connected an actual device and seen my Chrome port working with it.
I had a quick look at the source. Might be confusing but most of it we don't need to understand completely. Just use it!
As far as I can tell the only thing you need a little manifest and a background script. Perhaps those icons. It should be possible to keep everything else the same. I would be very surprised if we cannot use exactly the same files as both a Chrome app and the normal web page app. I do agree that I would hate to have to build HTML5 apps for Chrome that don't work as normal web content on other browsers.
So I would not like to use two many of those Chrome App only API's.
But If we can use the same stuff as a webpage and a Chrome app with only ten lines of code difference it seems reasonable.
In this case we can always get serial port access via little local web server anyway.
Not much like MS. This stuff is all open source after all.
Edit: Seems you are right. This Chrome App thing needs looking at. I just added a manifest, background and icon files to my Editor17 directory. I can now load it as a Chrome app and the HTML displays fine. None of the JS scripts run though. It complains about "security" and "content policy".
The good news is that I did manage to compile the propeller-load from propgcc using Emscripten. We almost have a JS loader!