Re: iPad. I do have a keyboard (Logitech's) for it and there's a decent amount of screen pixel real estate with the retina display. I do like my everyday computer with its larger screen, but it's not portable. If I used a laptop for Propeller work, I'd use SimpleIDE. I don't plan to write any epic programs that way, but it would be handy for debugging programs and writing small stuff.
We must have done something right here, people want more
Jazzed, Mike,
All this came about because of Jazzed challenging me to get openspin running in the browser. Miraculously it does. msrobots has done a great job and a lot of work in taking that from an experiment to a working web IDE.
There is still a long way to go to get through Jazzzed's requirements in the first post of this thread: a loader, a terminal and so on.
Getting the thing working on mobile devices would be cool but I suspect it's way down in priority just now.
As is making it look nice (no offence ms). Perhaps we some artistic help from a web designer here.
We must have done something right here, people want more
Jazzed, Mike,
All this came about because of Jazzed challenging me to get openspin running in the browser. Miraculously it does. msrobots has done a great job and a lot of work in taking that from an experiment to a working web IDE.
There is still a long way to go to get through Jazzzed's requirements in the first post of this thread: a loader, a terminal and so on.
Getting the thing working on mobile devices would be cool but I suspect it's way down in priority just now.
As is making it look nice (no offence ms). Perhaps we some artistic help from a web designer here.
as above.
By now the Editor has quite simple html and very less style sheet for it self. I do not own ANY mobile device so I have no means to test it except resizing my browser.
First function then form. For function we still need a serial Terminal and a serial Loader. The WIFI Loader seems to work. Ray is trying to build a activeX Loader (Win only) and @Heater. is exploring chrome-apps for using real serial ports and PropGCCs loader converted to JavaScript. And I am still trying to use a spinneret as a PropPlug with IDE. So the Quest goes on.
As for making it 'nicer', supporting mobile apps and all the bling. This is all possible. Its just html, JavaScript and css.
But first it need to function. Then we can think about a Logo... Not the other way around
Because Parallax wants a mobile solution. If you're going to do all the work, then you gotta do that too.
I am actually not doing all the work. I am just playing drums here as some guy named Watts said about his job with the crawling bones...
Over 90 percent of the source is just CodeMirror3. The Spin-Mode was basically done by @PhiPI. I just butchered it and added support for P2 op-codes and added background coloring and more detailed front coloring so it looks more like in the PropTool.
The compiler is written by Roy and 'transpiled' by @Heater to JavaScript. As he is doing now with the loader from PropGCC. I could not convince him to try the same with PropGCC itself. THAT would be cool.
The only thing I did was putting this all together. Just for the FUN of it.
For what I needed the Editor, as Editor for files on the Spinneret. I was done with version 2. The rest is just gravy. Sort of 'Because it is NOT there' as Gary Larson put it quite nicely...
So I am not doing all the work. Just about 3% of the source. If even that much.
If Parallax wants a mobile solution I am fine with it. All source I included (CodeMirror) is MIT licensed. My code is MIT licensed. So I put a MIT license into the source a while ago now.
Since neither @Phipi nor @Heater nor @David objected to this by now I guess it is valid. The Editor.zip includes ALL files, there are no external links to jquery or other web-tools.
The html itself is about 200 lines, some styles and a couple of hundred lines JavaScript.
Any decent web developer should be able to handle html like that. It is as down to the ground you can get.
Besides the Spinneret issue with just having 4 sockets there is no reason to keep everything in one file.
As I said. I just play drums here. But them drums are holding the whole music together usually. Providing some frame to put the rest of the music into. You know that better than me. The last time I played with a band is 30+ years ago...
He was able and willing to separate the Server for use with the Editor. And he did. Besides hosting the Editor this server can call PropellerLoad so you can now use your local serial/usb ports for programming a attached Propeller. By now it will use the first serial Port found - so be aware...
Editor18.htm can still be used as before, but Run RAM and Burn EEPROM just work if started in @Michel L's server.
I have attached Editor18.zip and propeller-web-loader-1.0-WebIDE-18.zip
propeller-web-loader-1.0-WebIDE-18.zip already contains the files of Editor18 in the directory webcontent. You can add your own files and directories there and they will be served by the web server and the editor also.
To use the server you will need to have Java installed. Unzip propeller-web-loader-1.0-WebIDE-18.zip to a place of your choosing.
Inside the download you will find a file prop-web-loader.bat for windows users. I had to edit it to include the path to the java.exe..
the content looks like this now "C:\Program Files (x86)\Java\jre7\bin\java.exe" -jar propeller-web-loader-1.0-SNAPSHOT.jar
Linux/Mac? user need to run the provided .jar file per command line.
java -jar propeller-web-loader-1.0-SNAPSHOT.jar
In both cases it will open a Web Browser showing the root of the server. Click on Editor18.htm and you are running...
A big THANK YOU to @Michel L. again for providing this.
To tease @Heater a bit I included support for JSLINT in the Editor. Currently just linting .js and .css files.
Still a long way to go but now you can edit, compile AND program a Propeller within in a Browser...
providing a way in the application to browse your computer and select a working directory
saving and loading files from that working directory
I can even save the selected directory for the next time
Just so you know, with a self hosted embedded server is almost anything possible. It's as if you write a desktop application but instead of a fat client you use the browser.
Let me know what you think, and what you could use. I'll copy code from BlockyProp to propeller-web-loader and back as they evolve.
I think they are great ideas. And very much intune with the way msrobots and I have been thinking for a while. Turns out that Parallax is getting on to this sort of thing as well as many of their customers want to use iPads as the user interface.
Basically what it boils down to is that your application is split into two parts:
1) The "business logic", as they like to say now a days, which might be responsible, in our case, for compiling Propeller code, programming the chip, communicating with the Propeller when it is running, storing files etc etc.
2) The user interface. A nice editor for Spin, blockly. A terminal window for talking to the Propeller when it runs. Perhaps graphical representations of the Propeller I/O or peripherals or who knows what?
Part 1) is the server. Part 2) is the web browser. The server can be on the same machine or on a different machine, or whatever. When used locally they can both be started up as if a single app.
This rather means that the server part should be platform independent. The easiest way to do that is with Java or some scripting language like Python.
I lean toward JavaScript and node.js here as it makes things like websockets very easy to handle. It's perfect for such networking roles.
This leads to an interesting observation. With JS you are now in the situation that significant amounts of processing logic can be done on the server end or in the browser. With the same code. For example why use openspin on the server when openspin.js can be used in the browser for a quicker turn around? Of course openspin.js can be used by the server as well, no need to recompile it for different platforms.
That only leaves the pesky Propeller loader which si written in C and needs compiling for each platform. I did manage to "transpile" the loader to JavaScript a little while ago. I have no idea if it will run correctly. And it needs a little adapting to drive the serial ports from JS.
On Mac OS X (10.9.2, Mavericks), running the latest, Java 7 Update 55 I get:
[COLOR=#000080][FONT=Monaco]$ java -version[/FONT]
[FONT=Monaco]java version "1.6.0_29"[/FONT]
[FONT=Monaco]Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402)[/FONT]
[FONT=Monaco]Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)
[/FONT]
[FONT=Monaco]$ java -jar -verbose propeller-web-loader-1.0-SNAPSHOT.jar[/FONT]
[FONT=Monaco]...
Exception in thread "main" java.lang.UnsupportedClassVersionError: eu/creatingfuture/propeller/webLoader/WebLoader : Unsupported major.minor version 51.0[/FONT]
[FONT=Monaco] at java.lang.ClassLoader.defineClass1(Native Method)[/FONT]
[FONT=Monaco] at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)[/FONT]
[FONT=Monaco] at java.lang.ClassLoader.defineClass(ClassLoader.java:615)[/FONT]
[FONT=Monaco] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)[/FONT]
[FONT=Monaco] at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)[/FONT]
[FONT=Monaco] at java.net.URLClassLoader.access$000(URLClassLoader.java:58)[/FONT]
[FONT=Monaco] at java.net.URLClassLoader$1.run(URLClassLoader.java:197)[/FONT]
[FONT=Monaco] at java.security.AccessController.doPrivileged(Native Method)[/FONT]
[FONT=Monaco] at java.net.URLClassLoader.findClass(URLClassLoader.java:190)[/FONT]
[FONT=Monaco] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)[/FONT]
[FONT=Monaco] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)[/FONT]
[FONT=Monaco] at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
...[/FONT][/COLOR]
On Mac OS X (10.9.2, Mavericks), running the latest, Java 7 Update 55 I get:
[code] $ java -version
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)
dgately
dgately, you say your running Java 7, but according to java -version it's 1.6.
Any chance you have 2 versions installed and the wrong one is in your Path?
That only leaves the pesky Propeller loader which si written in C and needs compiling for each platform. I did manage to "transpile" the loader to JavaScript a little while ago. I have no idea if it will run correctly. And it needs a little adapting to drive the serial ports from JS.
Unfortunately the built-in Propeller loader will not tolerate any delays.
Just let the Propeller provide the loader platform by presenting a tolerable and proven load method like writing the image to EEPROM and booting from that.
Could a virtual network serial port bridge via USB could be used instead of the S6B or other networked hardware device?
Another option is just to do it the mbed way which I don't really like, but it works. That is, make users download the binary and effectively program it themselves. The device I've used with mbed makes the USB port look like an SDcard, and any binary placed there just gets sucked into the board on reset.
providing a way in the application to browse your computer and select a working directory
saving and loading files from that working directory
I can even save the selected directory for the next time
Just so you know, with a self hosted embedded server is almost anything possible. It's as if you write a desktop application but instead of a fat client you use the browser.
Let me know what you think, and what you could use. I'll copy code from BlockyProp to propeller-web-loader and back as they evolve.
The most easy way for the Editor would be if your webserver would support PUT requests and make the webcontent directory (and subdirs) writable.
As of RFC 2616 a PUT request should replace the resource at the given URI. You may need to exclude your webapp directory.
You already support directory browsing on the server and the editor can already navigate the content of the server FS.
Staying as close to the RFC as possible makes it easy to support different webserver. By now the Editor supports your Java Server, @Heaters Node Server, IIS6/7 Server and the spinneret server. But none of them does all:
- your Java Server does Read, NO Write, Directory support and programming.
- @Heaters Node Server does Read, Write, No Directory support and NO programming (except S6B modul)
- IIS6/7 does Read, Write (if allowed), Directory support but no programming (except S6B modul)
- Spinneret-msrobots does Read, Write, Directory support but no programming (yet)
I have no clue about Linux/Apache and can not test directory support there but it should be able to do the same as IIS6/7.
my next goal is to put your JavaScript code to program into a webworker to have the GUI working more smoothly and to figure out why my spinneret code does not do what it is supposed to do. In theory I can program another propeller from the spinneret via 3 pins. Almost. I am just running out of space and have to optimize something.
But the spinneret can just program via TTL not USB. And the File System does not support long filenames...
Took me a while to figure it out. But I got your attention. :-)
The problem is I do not yet understand how a SPIN/PASM Linter has to look like.
The only examples I found are for JS, CSS. I've kept the files extern so you could take a look.
I need to find some more Linters for CodeMirror3.20 to understand how they should look. As far as I can understand the way csslint.js does it is what CodeMirror wants. I do have a example for JSON also. need to google a bit more...
As for a NODE Server. I did install Node on my computer, but did as much with it as I did with java. Nothing.
So If you could provide your Node Server, adding support for Directory access (basically a html page with links to dir entrys when a GET request ends in '/') and some sort of server side access to serial ports for PropellerLoad.js or even provide some 'service' like @Michel L. does, running on your Node Server and running PropellerLoad.js 'serverside' then I am a happy camper.
You already cover the write part...
dgately, you say your running Java 7, but according to java -version it's 1.6.
Any chance you have 2 versions installed and the wrong one is in your Path?
Attention: the compiler and propeller-load are not provided for mac. Only Windows and Linux.
Any chance you have 2 versions installed and the wrong one is in your Path?
Yes, unfortunately installing Java is not as simple as it should be on Mac OS X. When you install Java from java.com (http://www.java.com/en/download/mac_download.jsp?locale=en), you just get the web plugin. You still need to install the Java JDK to get further.
But, even then, I get an error, which states the OS is not supported...
[COLOR=#000080]
[/COLOR][COLOR=#F5F6C7][FONT=Monaco][COLOR=#000080]$ java -version[/COLOR][/FONT][/COLOR]
[COLOR=#F5F6C7][FONT=Monaco][COLOR=#000080]java version "1.7.0_55"[/COLOR][/FONT][/COLOR]
[COLOR=#F5F6C7][FONT=Monaco][COLOR=#000080]Java(TM) SE Runtime Environment (build 1.7.0_55-b13)[/COLOR][/FONT][/COLOR]
[COLOR=#F5F6C7][FONT=Monaco][COLOR=#000080]Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)[/COLOR]
[/FONT][/COLOR]
[COLOR=#F5F6C7][FONT=Monaco][COLOR=#000080]$ java -jar propeller-web-loader-1.0-SNAPSHOT.jar [/COLOR][/FONT][/COLOR]
[COLOR=#F5F6C7][FONT=Monaco][COLOR=#000080]Apr 28, 2014 5:56:55 PM eu.creatingfuture.propeller.webLoader.WebLoader main[/COLOR][/FONT][/COLOR]
[COLOR=#F5F6C7][FONT=Monaco][COLOR=#000080]WARNING: This OS is currently not supported: MacOS[/COLOR][/FONT][/COLOR]
As far as "Attention: the compiler and propeller-load are not provided for mac. Only Windows and Linux."
I already have openspin and propeller-load installed as I use them from propgcc and SimpleIDE!
Why does this framework require Java support? I thought the intent was to make all of this available to any web accessible device. Java is definitely NOT supported on iPads/iPhones, so those would definitely NOT be supported if Java is required on the client-side. Is Java just a server-side requirement? Even that will be a deal-breaker from my view (I'm sure others will disagree, but?). Is Java supported on RaspberryPi?
Unfortunately the built-in Propeller loader will not tolerate any delays.
Just let the Propeller provide the loader platform by presenting a tolerable and proven load method like writing the image to EEPROM and booting from that.
Could a virtual network serial port bridge via USB could be used instead of the S6B or other networked hardware device?
Another option is just to do it the mbed way which I don't really like, but it works. That is, make users download the binary and effectively program it themselves. The device I've used with mbed makes the USB port look like an SDcard, and any binary placed there just gets sucked into the board on reset.
@Jazzed,
First of all I did not make the S6B setting sticky. Sorry. Its still on the list.
Unfortunately the built-in Propeller loader will not tolerate any delays.
In the current scenario PropellerLoad 'transpiled' to JavaScript would run on the same computer as the serial/usb ports are. Either running as CHROME APP in the browser (serial access possible) or on @Heaters Node Server. Like it does now in native form in @Michel L.'s JavaServer. So I do not think delay is much of a problem.
Just let the Propeller provide the loader platform by presenting a tolerable and proven load method like writing the image to EEPROM and booting from that.
I a not sure if I do understand what you describing, but I guess you think of a resident loader in the lower eeprom and the user program in the upper half like the S6B loader from David does or Catalyst from Catalina or other available 'booter'.
This is doable, but restricts the usage. Your Propeller Board needs to be 'preprogrammed' for use. Some programs save settings in their own eeprom, assuming they are 'booted' from the lower eeprom. Them would kill the resident loader. Some programs may need the upper eeprom for their own purposes. C programs using extended memory models for example.
Short - I would prefer NOT to have a resident loader needed to be installed on the Prop, but just program it via serial/usb.
But if you are willing to accept the restrictions above you may be able to use ANY virtual TCP/IP to serial bridge. Not just the S6B module.
Another option is just to do it the mbed way which I don't really like, but it works. That is, make users download the binary and effectively program it themselves. The device I've used with mbed makes the USB port look like an SDcard, and any binary placed there just gets sucked into the board on reset.
You can do this already with the current editor. Just 'download' the created Result file (binary or eeprom) and do what you want with it.
Like putting on a sd card and inserting ito your propeller board to 'update' from there.
If I remember correctly while playing with your 32mb memory p1 board #008 you used this by yourself. Put a file xxx.yyy on the sd card, boot, and get 'updated'.
That is probably how I killed mine down to 16mb with a hole in each long. I put the sd card in the GG-Platform Board and not the sd slot provided by your addon board and rebooted...
Why does this framework require Java support? I thought the intent was to make all of this available to any web accessible device. Java is definitely NOT supported on iPads/iPhones, so those would definitely NOT be supported if Java is required on the client-side. Is Java just a server-side requirement? Even that will be a deal-breaker from my view (I'm sure others will disagree, but?). Is Java supported on RaspberryPi?
dgately
@dgately
Neither BlockProp nor the Editor require Java.
But them require a webserver to run on. If you do already HAVE some webserver on your device you may not need Java at all. Just put the webcontent there.
Alas programming a attached prop needs access to the serial ports. Except Chrome Apps I did not find any way to access local serial/usb ports from within a browser. So we need server side support for that.
And the only guys here providing a working example are @Michel L. with his Java Server, @Rayman with a almost working activeX control (just windows) and @David with his S6B wifi module from Parallax.
Me (spinneret-msrobots) and @Heater (Node.js) are failing on that part. But we are working on that.
@Heater is running this on his RasPi as far as I know...
Let's narrow the problem to easily understandable chunks.
It is impossible to use an emscripted propeller-load to reliably load a propeller over a network.
Clear enough?
Yes. You will not be able to use ANY serial data send over a network with TCP/IP to program a Propeller because of timing restrictions. I am completely with you there. No Question.
But a emscripten 'transpiled' C program accessing the local serial ports does not need to go over the network. The data is already there local in the browser before the serial transmission to local serial ports starts. I am assuming a local server as Michael L. and @Heater are providing.
NO WAY to try this with wifi or Ethernet connected devices. For them you would need either a solution as @David has, with loading into eeprom and resident loader on the Prop, or my solution with the spinneret, where the spinneret basically saves the binary/eeprom on its local sd card and then resets another propeller and runs @Chips PropLoad changed by Mike G.
Like a PropPlug would do, except the spinneret needs access to pin30/31/reset. So NO USB.
And the spinneret does all the time critical things with the Ethernet before programming some attached Prop.
Yes. You will not be able to use ANY serial data send over a network with TCP/IP to program a Propeller because of timing restrictions. I am completely with you there. No Question.
Actual the Propeller Boot loader is quite good in supporting different speeds of transmission. If you would REALY slow down the transmission rate, TCP/IP to Serial might work. I never tried the low boundary on that. But who would want that?
Next easy to swallow chunk.
Sure. Now, make it work with the serial port on an iPad.
I am sort of old fashioned. Heck I work as a COBOL programmer once in a while, when I need money. So I do not own any mobile devices.
As far as I understand Apple does not like access to serial ports. Well - my washing machine neither. What can I do about it? Nothing.
So for I-Phones you need something like @David's S6B software. OK. It is working right now. NOT nice, but working.
I guess you can do the same with Bluetooth LE or what it is called. But this Editor is not build for APPLE ONLY.
By now you can run ANY spin program thru the compiler and program it to ANY prop, provided you have the Java Server from Michel L running.
If not you can still run the Editor from any platform supplying you with a webserver and program via the S6B or just download the result file and do whatever you want to with it.
By the way ... the Editor does syntax highlighting and code completion for C and C++ also...
So in theory Michel L could provide a service running PropGCC. Or @Heater .. But he declined already...
I suspect msrobots washing machine does in fact have a serial interface somewhere.
My proposed solution for those who insist on using a useless tablet like an iPad is for them to invest in a real computer, a Raspberry Pi say, and have that program the Propeller having exchanged source or binary over IP network.
What minimum set of configurations are necessary to serve the needs?
What platforms need to be supported to serve the most customers?
What needs to be done to make it usable for the different platforms?
You may need to understand that I am doing this for FUN not for business. Working with complex requirements, cooperate speak and 'the one solution for all possible customers' el. al. is not my goal here.
I am in a different position than you are. And I do not want to load any pressure on me like you did to yourself with PropGCC, SimpleIDE, SpinIDE, mcusimulator and all the other Stuff you are providing. I just can't.
I do appreciate all of what you do, but I do have already a couple of fulltime projects I get paid for to manage. This Parallax Stuff I am doing is for escaping that daily terror and having FUN programming again, instead of being restricted by requirements.
It is about the creative part. Just jamming around and not playing by notes. Yes. There might come a nice song out of it. Or not. But it makes FUN doing it by itself.
I tried without success to find any reference where you actual challenged @Heater. to do what we are going to accomplish here, but for me it does not really matter at all. I am doing this as 'chewing gum for my brain'.
Since @Heater talked me into it and I looked at JavaScript for the first time as being more than as scripting language for web pages I discovered a lot of nice things I can do in a browser. I may be able to use some of this in other projects I work for. Or may not. But I had FUN discovering it, and that is what the propeller is about anyways. (at least for me)
By now I am acting like the BORG. I try to assimilate everything I find it could match into the Editor. And look how it behaves. Playing around in the spare 'spare time' I have.
And I am quite proud of the result of the combined work of Phil, Heater, David, Michel L. the CodeMirror guys, emscripten and various other sources in the internet I used to put this experiment together.
Sure. To be a 'real project' way more things need to be done. But it isn't. May evolve to one. Or may not. we will see.
What I think it comes down too is this: Several solutions are required to meet the needs
Comments
We must have done something right here, people want more
Jazzed, Mike,
All this came about because of Jazzed challenging me to get openspin running in the browser. Miraculously it does. msrobots has done a great job and a lot of work in taking that from an experiment to a working web IDE.
There is still a long way to go to get through Jazzzed's requirements in the first post of this thread: a loader, a terminal and so on.
Getting the thing working on mobile devices would be cool but I suspect it's way down in priority just now.
As is making it look nice (no offence ms). Perhaps we some artistic help from a web designer here.
Whilst you have youtube fired up do also check out these two great guys :
Misko Hevery - Introduction to JavaScript and Browser DOM:http://www.youtube.com/watch?v=Trr95ij1358
Dmitry Baranovskiy - JavaScript: Enter The Dragon: http://www.youtube.com/watch?v=ljNi8nS5TtQ
Dmitry has a great style and real attitude.
as above.
By now the Editor has quite simple html and very less style sheet for it self. I do not own ANY mobile device so I have no means to test it except resizing my browser.
First function then form. For function we still need a serial Terminal and a serial Loader. The WIFI Loader seems to work. Ray is trying to build a activeX Loader (Win only) and @Heater. is exploring chrome-apps for using real serial ports and PropGCCs loader converted to JavaScript. And I am still trying to use a spinneret as a PropPlug with IDE. So the Quest goes on.
As for making it 'nicer', supporting mobile apps and all the bling. This is all possible. Its just html, JavaScript and css.
But first it need to function. Then we can think about a Logo... Not the other way around
Enjoy!
Mike
I am actually not doing all the work. I am just playing drums here as some guy named Watts said about his job with the crawling bones...
Over 90 percent of the source is just CodeMirror3. The Spin-Mode was basically done by @PhiPI. I just butchered it and added support for P2 op-codes and added background coloring and more detailed front coloring so it looks more like in the PropTool.
The compiler is written by Roy and 'transpiled' by @Heater to JavaScript. As he is doing now with the loader from PropGCC. I could not convince him to try the same with PropGCC itself. THAT would be cool.
The only thing I did was putting this all together. Just for the FUN of it.
For what I needed the Editor, as Editor for files on the Spinneret. I was done with version 2. The rest is just gravy. Sort of 'Because it is NOT there' as Gary Larson put it quite nicely...
So I am not doing all the work. Just about 3% of the source. If even that much.
If Parallax wants a mobile solution I am fine with it. All source I included (CodeMirror) is MIT licensed. My code is MIT licensed. So I put a MIT license into the source a while ago now.
Since neither @Phipi nor @Heater nor @David objected to this by now I guess it is valid. The Editor.zip includes ALL files, there are no external links to jquery or other web-tools.
The html itself is about 200 lines, some styles and a couple of hundred lines JavaScript.
see for yourself: http://parallax.msrobots.net/Editor17.htm?a=/Editor17.htm and scroll to the end ... (with focus in editor hit ctrl-end)
Any decent web developer should be able to handle html like that. It is as down to the ground you can get.
Besides the Spinneret issue with just having 4 sockets there is no reason to keep everything in one file.
As I said. I just play drums here. But them drums are holding the whole music together usually. Providing some frame to put the rest of the music into. You know that better than me. The last time I played with a band is 30+ years ago...
Enjoy!
Mike
@Michel L. started a thread http://forums.parallax.com/showthread.php/155208-Open-Propeller-Project-5-BlocklyProp and is using a local JavaServer for this.
He was able and willing to separate the Server for use with the Editor. And he did. Besides hosting the Editor this server can call PropellerLoad so you can now use your local serial/usb ports for programming a attached Propeller. By now it will use the first serial Port found - so be aware...
Editor18.htm can still be used as before, but Run RAM and Burn EEPROM just work if started in @Michel L's server.
I have attached Editor18.zip and propeller-web-loader-1.0-WebIDE-18.zip
propeller-web-loader-1.0-WebIDE-18.zip already contains the files of Editor18 in the directory webcontent. You can add your own files and directories there and they will be served by the web server and the editor also.
To use the server you will need to have Java installed. Unzip propeller-web-loader-1.0-WebIDE-18.zip to a place of your choosing.
Inside the download you will find a file prop-web-loader.bat for windows users. I had to edit it to include the path to the java.exe..
the content looks like this now "C:\Program Files (x86)\Java\jre7\bin\java.exe" -jar propeller-web-loader-1.0-SNAPSHOT.jar
Linux/Mac? user need to run the provided .jar file per command line.
java -jar propeller-web-loader-1.0-SNAPSHOT.jar
In both cases it will open a Web Browser showing the root of the server. Click on Editor18.htm and you are running...
A big THANK YOU to @Michel L. again for providing this.
To tease @Heater a bit I included support for JSLINT in the Editor. Currently just linting .js and .css files.
Still a long way to go but now you can edit, compile AND program a Propeller within in a Browser...
Enjoy!
Mike
.
Must find time to check it out.
JSlint in a Propeller tool, who'da thunk it.
what do you think about these ideas:
Just so you know, with a self hosted embedded server is almost anything possible. It's as if you write a desktop application but instead of a fat client you use the browser.
Let me know what you think, and what you could use. I'll copy code from BlockyProp to propeller-web-loader and back as they evolve.
I'll also update my github project with your new javascript files. https://github.com/michel-cf/propeller-web-loader
I think they are great ideas. And very much intune with the way msrobots and I have been thinking for a while. Turns out that Parallax is getting on to this sort of thing as well as many of their customers want to use iPads as the user interface.
Basically what it boils down to is that your application is split into two parts:
1) The "business logic", as they like to say now a days, which might be responsible, in our case, for compiling Propeller code, programming the chip, communicating with the Propeller when it is running, storing files etc etc.
2) The user interface. A nice editor for Spin, blockly. A terminal window for talking to the Propeller when it runs. Perhaps graphical representations of the Propeller I/O or peripherals or who knows what?
Part 1) is the server. Part 2) is the web browser. The server can be on the same machine or on a different machine, or whatever. When used locally they can both be started up as if a single app.
This rather means that the server part should be platform independent. The easiest way to do that is with Java or some scripting language like Python.
I lean toward JavaScript and node.js here as it makes things like websockets very easy to handle. It's perfect for such networking roles.
This leads to an interesting observation. With JS you are now in the situation that significant amounts of processing logic can be done on the server end or in the browser. With the same code. For example why use openspin on the server when openspin.js can be used in the browser for a quicker turn around? Of course openspin.js can be used by the server as well, no need to recompile it for different platforms.
That only leaves the pesky Propeller loader which si written in C and needs compiling for each platform. I did manage to "transpile" the loader to JavaScript a little while ago. I have no idea if it will run correctly. And it needs a little adapting to drive the serial ports from JS.
On Mac OS X (10.9.2, Mavericks), running the latest, Java 7 Update 55 I get:
dgately
Java is great. Write once run anywhere!
dgately, you say your running Java 7, but according to java -version it's 1.6.
Any chance you have 2 versions installed and the wrong one is in your Path?
I'll see if I can build a 1.6 version: http://owncloud.creatingfuture.eu/public.php?service=files&t=9723787a87db639711f1b2de1cb0c756
Download the version ending with Java-1.6, that should work.
Attention: the compiler and propeller-load are not provided for mac. Only Windows and Linux.
Just let the Propeller provide the loader platform by presenting a tolerable and proven load method like writing the image to EEPROM and booting from that.
Could a virtual network serial port bridge via USB could be used instead of the S6B or other networked hardware device?
Another option is just to do it the mbed way which I don't really like, but it works. That is, make users download the binary and effectively program it themselves. The device I've used with mbed makes the USB port look like an SDcard, and any binary placed there just gets sucked into the board on reset.
Hi Michel L.
The most easy way for the Editor would be if your webserver would support PUT requests and make the webcontent directory (and subdirs) writable.
As of RFC 2616 a PUT request should replace the resource at the given URI. You may need to exclude your webapp directory.
You already support directory browsing on the server and the editor can already navigate the content of the server FS.
Staying as close to the RFC as possible makes it easy to support different webserver. By now the Editor supports your Java Server, @Heaters Node Server, IIS6/7 Server and the spinneret server. But none of them does all:
- your Java Server does Read, NO Write, Directory support and programming.
- @Heaters Node Server does Read, Write, No Directory support and NO programming (except S6B modul)
- IIS6/7 does Read, Write (if allowed), Directory support but no programming (except S6B modul)
- Spinneret-msrobots does Read, Write, Directory support but no programming (yet)
I have no clue about Linux/Apache and can not test directory support there but it should be able to do the same as IIS6/7.
my next goal is to put your JavaScript code to program into a webworker to have the GUI working more smoothly and to figure out why my spinneret code does not do what it is supposed to do. In theory I can program another propeller from the spinneret via 3 pins. Almost. I am just running out of space and have to optimize something.
But the spinneret can just program via TTL not USB. And the File System does not support long filenames...
Enjoy!
Mike
Took me a while to figure it out. But I got your attention. :-)
The problem is I do not yet understand how a SPIN/PASM Linter has to look like.
The only examples I found are for JS, CSS. I've kept the files extern so you could take a look.
I need to find some more Linters for CodeMirror3.20 to understand how they should look. As far as I can understand the way csslint.js does it is what CodeMirror wants. I do have a example for JSON also. need to google a bit more...
As for a NODE Server. I did install Node on my computer, but did as much with it as I did with java. Nothing.
So If you could provide your Node Server, adding support for Directory access (basically a html page with links to dir entrys when a GET request ends in '/') and some sort of server side access to serial ports for PropellerLoad.js or even provide some 'service' like @Michel L. does, running on your Node Server and running PropellerLoad.js 'serverside' then I am a happy camper.
You already cover the write part...
Enjoy!
Mike
Any chance you have 2 versions installed and the wrong one is in your Path?
But, even then, I get an error, which states the OS is not supported...
As far as "Attention: the compiler and propeller-load are not provided for mac. Only Windows and Linux."
dgately
Why does this framework require Java support? I thought the intent was to make all of this available to any web accessible device. Java is definitely NOT supported on iPads/iPhones, so those would definitely NOT be supported if Java is required on the client-side. Is Java just a server-side requirement? Even that will be a deal-breaker from my view (I'm sure others will disagree, but?). Is Java supported on RaspberryPi?
dgately
@Jazzed,
First of all I did not make the S6B setting sticky. Sorry. Its still on the list.
In the current scenario PropellerLoad 'transpiled' to JavaScript would run on the same computer as the serial/usb ports are. Either running as CHROME APP in the browser (serial access possible) or on @Heaters Node Server. Like it does now in native form in @Michel L.'s JavaServer. So I do not think delay is much of a problem.
I a not sure if I do understand what you describing, but I guess you think of a resident loader in the lower eeprom and the user program in the upper half like the S6B loader from David does or Catalyst from Catalina or other available 'booter'.
This is doable, but restricts the usage. Your Propeller Board needs to be 'preprogrammed' for use. Some programs save settings in their own eeprom, assuming they are 'booted' from the lower eeprom. Them would kill the resident loader. Some programs may need the upper eeprom for their own purposes. C programs using extended memory models for example.
Short - I would prefer NOT to have a resident loader needed to be installed on the Prop, but just program it via serial/usb.
But if you are willing to accept the restrictions above you may be able to use ANY virtual TCP/IP to serial bridge. Not just the S6B module.
You can do this already with the current editor. Just 'download' the created Result file (binary or eeprom) and do what you want with it.
Like putting on a sd card and inserting ito your propeller board to 'update' from there.
If I remember correctly while playing with your 32mb memory p1 board #008 you used this by yourself. Put a file xxx.yyy on the sd card, boot, and get 'updated'.
That is probably how I killed mine down to 16mb with a hole in each long. I put the sd card in the GG-Platform Board and not the sd slot provided by your addon board and rebooted...
Enjoy!
Mike
@dgately
Neither BlockProp nor the Editor require Java.
But them require a webserver to run on. If you do already HAVE some webserver on your device you may not need Java at all. Just put the webcontent there.
Alas programming a attached prop needs access to the serial ports. Except Chrome Apps I did not find any way to access local serial/usb ports from within a browser. So we need server side support for that.
And the only guys here providing a working example are @Michel L. with his Java Server, @Rayman with a almost working activeX control (just windows) and @David with his S6B wifi module from Parallax.
Me (spinneret-msrobots) and @Heater (Node.js) are failing on that part. But we are working on that.
@Heater is running this on his RasPi as far as I know...
Enjoy!
Mike
It is impossible to use an emscripted propeller-load to reliably load a propeller over a network.
Clear enough?
Yes. You will not be able to use ANY serial data send over a network with TCP/IP to program a Propeller because of timing restrictions. I am completely with you there. No Question.
But a emscripten 'transpiled' C program accessing the local serial ports does not need to go over the network. The data is already there local in the browser before the serial transmission to local serial ports starts. I am assuming a local server as Michael L. and @Heater are providing.
NO WAY to try this with wifi or Ethernet connected devices. For them you would need either a solution as @David has, with loading into eeprom and resident loader on the Prop, or my solution with the spinneret, where the spinneret basically saves the binary/eeprom on its local sd card and then resets another propeller and runs @Chips PropLoad changed by Mike G.
Like a PropPlug would do, except the spinneret needs access to pin30/31/reset. So NO USB.
And the spinneret does all the time critical things with the Ethernet before programming some attached Prop.
Enjoy!
Mike
Next easy to swallow chunk.
Sure. Now, make it work with the serial port on an iPad.
Actual the Propeller Boot loader is quite good in supporting different speeds of transmission. If you would REALY slow down the transmission rate, TCP/IP to Serial might work. I never tried the low boundary on that. But who would want that?
Enjoy!
Mike
I am sort of old fashioned. Heck I work as a COBOL programmer once in a while, when I need money. So I do not own any mobile devices.
As far as I understand Apple does not like access to serial ports. Well - my washing machine neither. What can I do about it? Nothing.
So for I-Phones you need something like @David's S6B software. OK. It is working right now. NOT nice, but working.
I guess you can do the same with Bluetooth LE or what it is called. But this Editor is not build for APPLE ONLY.
By now you can run ANY spin program thru the compiler and program it to ANY prop, provided you have the Java Server from Michel L running.
If not you can still run the Editor from any platform supplying you with a webserver and program via the S6B or just download the result file and do whatever you want to with it.
By the way ... the Editor does syntax highlighting and code completion for C and C++ also...
So in theory Michel L could provide a service running PropGCC. Or @Heater .. But he declined already...
next.
Mike
What minimum set of configurations are necessary to serve the needs?
What platforms need to be supported to serve the most customers?
What needs to be done to make it usable for the different platforms?
I wish I had more time for this.
I don't want to be your amputee http://www.youtube.com/watch?v=qnlfKLcAthU
I suspect msrobots washing machine does in fact have a serial interface somewhere.
My proposed solution for those who insist on using a useless tablet like an iPad is for them to invest in a real computer, a Raspberry Pi say, and have that program the Propeller having exchanged source or binary over IP network.
Yes. Me too.
You may need to understand that I am doing this for FUN not for business. Working with complex requirements, cooperate speak and 'the one solution for all possible customers' el. al. is not my goal here.
I am in a different position than you are. And I do not want to load any pressure on me like you did to yourself with PropGCC, SimpleIDE, SpinIDE, mcusimulator and all the other Stuff you are providing. I just can't.
I do appreciate all of what you do, but I do have already a couple of fulltime projects I get paid for to manage. This Parallax Stuff I am doing is for escaping that daily terror and having FUN programming again, instead of being restricted by requirements.
It is about the creative part. Just jamming around and not playing by notes. Yes. There might come a nice song out of it. Or not. But it makes FUN doing it by itself.
I tried without success to find any reference where you actual challenged @Heater. to do what we are going to accomplish here, but for me it does not really matter at all. I am doing this as 'chewing gum for my brain'.
Since @Heater talked me into it and I looked at JavaScript for the first time as being more than as scripting language for web pages I discovered a lot of nice things I can do in a browser. I may be able to use some of this in other projects I work for. Or may not. But I had FUN discovering it, and that is what the propeller is about anyways. (at least for me)
By now I am acting like the BORG. I try to assimilate everything I find it could match into the Editor. And look how it behaves. Playing around in the spare 'spare time' I have.
And I am quite proud of the result of the combined work of Phil, Heater, David, Michel L. the CodeMirror guys, emscripten and various other sources in the internet I used to put this experiment together.
Sure. To be a 'real project' way more things need to be done. But it isn't. May evolve to one. Or may not. we will see.
I completely agree.
Enjoy!
Mike
yes. possible. Now go and do this Node server you are talking about....
Enjoy!
Mike
However you did prompt me to investigate and I discovered I can serve up directory listing by adding a single line to my little server:
app.use('/library', express.directory(__dirname + '/library', {icons: true}));Gives me this: http://the.linuxd.org:3000/libraryOf course what we really need is for such a request to serve up a directory listing in json format for ease of use by the browser code.
Not at all. In the opposite. Just stay close to RFC 2616. Try to remove all that decoration. icons false?
compare your html source to Michel L.'s servers html source or the way IIS does it at http://parallax.msrobots.net/Library/
just simple links without much decoration.
your link
Michel L's Server
IIS6/7
I already have a parser in the editor for that. Just need to adjust for those unneeded spans. will do in Version 19.
Enjoy!
Mike
[/COLOR]
[/COLOR][/SIZE][/COLOR][/SIZE]