Ha, ha, the magic moment when the light goes on re: JavaScript's non-recursive recursion with callbacks and closures. It took a while before my brain could accept that. It's just so alien to anyone coming to JS from a "normal" language like C++ or Java.
Actually, now that I think about it there is one important detail that I forgot to point out which may have helped. That fileStack thing that is returned from the parser is actually an array within the parser object. It lives as long as the object does. It's not a new thing created every time you call the parser which needs dealing with completely by the caller after the call. That's why we can get away with only popping one file of it after every call. The others stay on the stack till next time. That's why we don't need that loop you added.
I had a go at using Chrome's serial port API a while back, problem was they had changed the API and so it did not work. I have to find time to catch up with the new stuff.
your version is quitting to fast and not 'eating up' all filestack members.
The parseProject as supplied does indeed find all sub-objects and all sub-sub-objects...It traverses all files and finds all PUB/PRI (except the lowercase ones . I tested it under node. It worked.
Your getFileStack method does not do anything. The fileStack returned by the parser is a reference to the fileStack array in the parser object. Exactly the same as what your getFileStack method returns. Except when you call getFileStack before parsing it is empty {} which is kind of useless.
I think you can demonstrate that by printing out the file stack at various points in your code.
This is GREAT. Please give me some link to your (techbasic?) sources showing how to talk to the S6B. I am really interested to assimilate that.
By now I have a compiled binary in the browser. If I can send it somewhere over http or whatever we are fine.
I may be able soon to use a spinneret as PropPlug and Program any board connected to the spinneret. (serial / no usb). work in progress....
The code is not TechBasic. David started writing all of this a month ago, but his day job takes lots more time these days. So the source is not ready yet either. I have a preliminary binary for S6B testing. I have a load client, but I need to write a Javascript client for more testing.
An ActivityBot Propeller+S6B is cheap, self-contained, and low power.
There was some discussion of having some other wifi enabled MCU act as a PropPlug.
@Heater, I've already written a "long poll" Javascript serial terminal. It was in that Spinny Weby Devy thread. I glanced at some "push" technologies for a terminal. The HTML Server push thing looks interesting since it will be in HTML5.
I have a couple of Xbees but do not have any of those S6Bs. I know that Parallax is using them with I-pads but and I know you and David where doing some stuff, and I know that there is a issue with some buffer size of 2k.
Else I am pretty clueless.
I can not see any way to run the propeller serial boot over wireless at all. This is no standard serial stuff. I just went - wondering what it does - thru @Chips PropellerLoader while I was adding it to the spinneret.
No way to get that timing with tcp or udp.
So direct programming is off the table IMHO. The only thing you can do is to transfer a new firmware to some program on the Propeller and let the prop program its own EEPROM.
Can you give me ANY sources doing what you are doing now? I am perfectly willing to tackle the JavaScript version in the browser. I can always cry call for @Heater when I get stuck....
As for the terminal - there are a couple of them out there, but I did not find one easy enough for my needs. My goal is to run all of this from the spinneret. And I do just have 4 sockets, one already used for NETBIOS.
So just open a socket for the serial stream and keep it open is not doable for me. Still thinking about that problem.
BTW - what @Heater and me doing here is heavily based on HTML5. But maybe not compliant.
Ha, ha, "play safe". I pretty much don't care. If it works in Chrome I'm happy if it works in FireFox as well I'm very happy. Safari and Opera are a bonus.
Thing is there is isn't really any such thing as HTML5. The guys developing this stuff have said so. It's become a name for all the new good stuff that has come out recently, webgl, websockets, video tags going back to "boarder-radius". It is constantly under construction.
For a decade or more web developers "played safe" by making sure everything worked on I.E.some.old.version. That will get us nowhere fast.
That terminal thing, could be term.js or tty.js I forget which is the low level part we need. Best to use it with web sockets. If we use the Socket.io library in the browser it will fall back to long polling or even FLASH sockets if websockets are not supported by the server. Socket.io makes all this stuff really easy.
The code is not TechBasic. David started writing all of this a month ago, but his day job takes lots more time these days. So the source is not ready yet either. I have a preliminary binary for S6B testing. I have a load client, but I need to write a Javascript client for more testing.
An ActivityBot Propeller+S6B is cheap, self-contained, and low power.
There was some discussion of having some other wifi enabled MCU act as a PropPlug.
@Heater, I've already written a "long poll" Javascript serial terminal. It was in that Spinny Weby Devy thread. I glanced at some "push" technologies for a terminal. The HTML Server push thing looks interesting since it will be in HTML5.
I just got it working to download a large program today. I had a bug in some PASM code where I got the sense of a range check backwards. Anyway, it can now download big programs using HTTP. The problem is that you have to break the program into small packets of 512 bytes or less. It may be possible to increase that to 1K but probably not much bigger than that because of severe buffer size limits in the Xbee Wi-Fi module. I'm hoping they'll address these in the next firmware release. I'm afraid I haven't been following this project so I'm not sure if what I've done with this simple HTTP downloader is of any use in your project. Maybe someone could describe the current state of this web IDE project and what pieces are missing that might be satisfied by my HTTP download code.
A Editor and spin compiler written in Html, JavaScript and CSS.
- Syntax highlighting and code completion for C, C++,C#, html, js,, css, SPIN, PASM and well Cobol. (just do not think about that last one)
- search, replace.
- code folding depending on indention.
- upload and download files from and to local fie system
- loading and saving files from webserver file system(s) (GET/PUT)
- directory support if directory browsing is allowed for webserver file system(s).
- OpenSpin running in JavaScript inside the browser to compile spin/pasm to binary/eeprom
- support for Library files of Spin Compiler
- ability to save resulting binary/eeprom to local file system or webserver file system(s)
- a simple GUI trying to look as close to the PropTool as feasible by now.
- all of this in 1 .htm file and 2 .js files. No server side code required. All runs in the Browser.
What is still missing:
- your code to program a Propeller via S6B. (will look into that for sure)
- my code to program a Propeller via spinneret as host. (WIP)
- @Heater.'s code to make a Chrome app out of it to use local serial ports from the browser (WIP)
- Serial Terminal to use in Browser. Needs to work with all 3 above.
If you're going to look at it I think I probably need to write some documentation on how it is used. Essentially, there are four programs:
1) xbee-config will setup your Xbee S6B with the correct settings to run the HTTP server. This is a Propeller program.
2) xbee-loader is a Propeller program that you would normally write to the first 32K of EEPROM. It implements a simple HTTP server that knows how to write to EEPROM and start a program from EEPROM.
3) xbee-load is a program that runs on the PC (Macintosh, Linux, Windows). It reads a Spin binary and sends it to the Propeller over a Wi-Fi connection. It uses the XPOST /eeprom-wr/ and /load/ requests to load and start a program.
4) eeprom-dump is a program that isn't really needed except for debugging. It dumps data from the upper 32k of the EEPROM. It is a Propeller program but I'm in the process of adding this feature to the HTTP protocol as well.
There is a Makefile that builds all of these but you need propgcc installed. I've been using the default branch from Google Code but it may build okay under the release_1_0 branch that is distributed with SimpleIDE as well. There is currently no SimpleIDE project for building this.
In addition to all of this there is the beginnings of an HTTP server library. The main interface to this is in xbee-server.c and it uses a PASM frame driver to talk to the S6B module which is in the xbeeframe.c and xbeeframe_driver.spin files.
Running make all on my Mac OS X (10.9) system builds most of the project but returns:
[COLOR=#000000][FONT=Monaco]xbee-loader.o: In function `_handle_xpost_request':[/FONT]
[FONT=Monaco](.text+0x1ad): undefined reference to `_eepromClose'[/FONT]
[FONT=Monaco]collect2: ld returned 1 exit status[/FONT]
[FONT=Monaco]make: *** [xbee-server.elf] Error 1[/FONT][/COLOR]
I use:
openspin Version 1.00.70
propeller-elf-gcc: Thread model: singlegcc version 4.6.1 (propellergcc-alpha_v1_9_0_2400)
Where should I look for: "_eepromClose"?
UPDATE: that symbol is in eeprom.h which is in propgcc's lib directory hierarchy. This does not get installed with SimpleIDE. It's also not in /opt/parallax/lib's hierarchy after a progcc build, so folks will need to add their "/SOURCEDIR/propgcc/lib/include/ to their $PATH var to build this.
Thanks,
dgately
Running make all on my Mac OS X (10.9) system builds most of the project but returns:
[COLOR=#000000][FONT=Monaco]xbee-loader.o: In function `_handle_xpost_request':[/FONT]
[FONT=Monaco](.text+0x1ad): undefined reference to `_eepromClose'[/FONT]
[FONT=Monaco]collect2: ld returned 1 exit status[/FONT]
[FONT=Monaco]make: *** [xbee-server.elf] Error 1[/FONT][/COLOR]
I use:
openspin Version 1.00.70
propeller-elf-gcc: Thread model: singlegcc version 4.6.1 (propellergcc-alpha_v1_9_0_2400)
Where should I look for: "_eepromClose"?
UPDATE: that symbol is in eeprom.h which is in propgcc's lib directory hierarchy. This does not get installed with SimpleIDE. It's also not in /opt/parallax/lib's hierarchy after a progcc build, so folks will need to add their "/SOURCEDIR/propgcc/lib/include/ to their $PATH var to build this.
Thanks,
dgately
Ah yes, that eepromClose function was missing from the release_1_0 branch so I added it to the default branch. I had forgotten about that. Sorry!
Good question... I had rebuilt on 3/13, for what I thought was the default branch. I've re-pulled default and now I get the errors that I thought "fix-xcode-warnings.sh" was supposed to take care of, but I still get errors on fputs & sbrk...
[FONT=Monaco]/Users/altergator/source/propgcc/binutils/binutils/readelf.c:9051:20: error: adding 'int' to a string does not append[/FONT]
[FONT=Monaco] to the string [-Werror,-Wstring-plus-int][/FONT]
[FONT=Monaco] fputs (" " + n, stdout);[/FONT]
[FONT=Monaco] ~~~~~~~~^~~[/FONT]
[SIZE=2]
&
[/SIZE][FONT=Monaco]/Users/altergator/source/propgcc/binutils/binutils/nm.c:1697:28: error: 'sbrk' is deprecated[/FONT]
[FONT=Monaco] [-Werror,-Wdeprecated-declarations][/FONT]
[FONT=Monaco] char *lim = (char *) sbrk (0);[/FONT]
[FONT=Monaco] ^[/FONT]
[FONT=Monaco]/usr/include/unistd.h:582:7: note: 'sbrk' declared here[/FONT]
[FONT=Monaco]void *sbrk(int);[/FONT]
[FONT=Monaco] ^[/FONT][/COLOR]
I'm going to do a fresh clone of propgcc and see what happens.
Good question... I had rebuilt on 3/13, for what I thought was the default branch. I've re-pulled default and now I get the errors that I thought "fix-xcode-warnings.sh" was supposed to take care of, but I still get errors on fputs & sbrk...
[FONT=Monaco]/Users/altergator/source/propgcc/binutils/binutils/readelf.c:9051:20: error: adding 'int' to a string does not append[/FONT]
[FONT=Monaco] to the string [-Werror,-Wstring-plus-int][/FONT]
[FONT=Monaco] fputs (" " + n, stdout);[/FONT]
[FONT=Monaco] ~~~~~~~~^~~[/FONT]
[SIZE=2]
&
[/SIZE][FONT=Monaco]/Users/altergator/source/propgcc/binutils/binutils/nm.c:1697:28: error: 'sbrk' is deprecated[/FONT]
[FONT=Monaco] [-Werror,-Wdeprecated-declarations][/FONT]
[FONT=Monaco] char *lim = (char *) sbrk (0);[/FONT]
[FONT=Monaco] ^[/FONT]
[FONT=Monaco]/usr/include/unistd.h:582:7: note: 'sbrk' declared here[/FONT]
[FONT=Monaco]void *sbrk(int);[/FONT]
[FONT=Monaco] ^[/FONT][/COLOR]
I'm going to do a fresh clone of propgcc and see what happens.
dgately
Did you "source fix-xcode-warnings.sh"? It won't work to just do ./fix-xcode-warnings.sh.
I looked at xbee-load.c and you - hm - invent new HTTP methods XPOST and XLOAD.
But it is not a post at all since you do not encode a post body. What you are doing is a PUT request not a post. Because you are sending the binary data as body.
Why are you using XPOST instead of PUT?
HTTP is a standard and you can not just 'invent' new methods.
The JavaScript XMLhttp request can just use methods defined in HTTP1.1. So I can not 'create' a XPOST request. It is not defined by HTTP1.1.
The same applies for your XLOAD request which is essential a GET request with Parameter. Why you do not use that?
As is this is NOT HTTP1.1 and I will not be able to use it from JavaScript with the XMLhttp object.
By definition a PUT request replaces the resource described by the URL.
That is exactly what you want to do. PUT /eeprom-wr/32768 will replace the first 512 bytes of the eeprom. Clear and confirming with HTTP1.1. Replacing a resource described by URL.
A GET /eeprom-wr/32768 should return those 512 bytes again. Clear and confirming with HTTP1.1. Reading a resource described by URL.
Like in the Linux file system a resource don't has to be a file. can be a device also. or a EEPROM. Does not matter. It is just a resource described by a URL.
The same applies to your XLOAD. It is just a GET with parameter. and should return a correct HTTP1.1 answer.
What you are doing here confirms NOT to HTTP1.1 and you should not name it like that in your requests. It is not.
I looked at xbee-load.c and you - hm - invent new HTTP methods XPOST and XLOAD.
But it is not a post at all since you do not encode a post body. What you are doing is a PUT request not a post. Because you are sending the binary data as body.
Why are you using XPOST instead of PUT?
HTTP is a standard and you can not just 'invent' new methods.
The JavaScript XMLhttp request can just use methods defined in HTTP1.1. So I can not 'create' a XPOST request. It is not defined by HTTP1.1.
The same applies for your XLOAD request which is essential a GET request with Parameter. Why you do not use that?
As is this is NOT HTTP1.1 and I will not be able to use it from JavaScript with the XMLhttp object.
By definition a PUT request replaces the resource described by the URL.
That is exactly what you want to do. PUT /eeprom-wr/32768 will replace the first 512 bytes of the eeprom. Clear and confirming with HTTP1.1. Replacing a resource described by URL.
A GET /eeprom-wr/32768 should return those 512 bytes again. Clear and confirming with HTTP1.1. Reading a resource described by URL.
Like in the Linux file system a resource don't has to be a file. can be a device also. or a EEPROM. Does not matter. It is just a resource described by a URL.
The same applies to your XLOAD. It is just a GET with parameter. and should return a correct HTTP1.1 answer.
What you are doing here confirms NOT to HTTP1.1 and you should not name it like that in your requests. It is not.
OK I do understand. This is quite sad. But if you need to use 'non-standard' methods it is not HTTP protocol but something else.
Sorry. Do not name it HTTP if it is not.
I looked at xbee-load.c and you - hm - invent new HTTP methods XPOST and XLOAD.
But it is not a post at all since you do not encode a post body. What you are doing is a PUT request not a post. Because you are sending the binary data as body.
Why are you using XPOST instead of PUT?
HTTP is a standard and you can not just 'invent' new methods.
The JavaScript XMLhttp request can just use methods defined in HTTP1.1. So I can not 'create' a XPOST request. It is not defined by HTTP1.1.
The same applies for your XLOAD request which is essential a GET request with Parameter. Why you do not use that?
As is this is NOT HTTP1.1 and I will not be able to use it from JavaScript with the XMLhttp object.
By definition a PUT request replaces the resource described by the URL.
That is exactly what you want to do. PUT /eeprom-wr/32768 will replace the first 512 bytes of the eeprom. Clear and confirming with HTTP1.1. Replacing a resource described by URL.
A GET /eeprom-wr/32768 should return those 512 bytes again. Clear and confirming with HTTP1.1. Reading a resource described by URL.
Like in the Linux file system a resource don't has to be a file. can be a device also. or a EEPROM. Does not matter. It is just a resource described by a URL.
The same applies to your XLOAD. It is just a GET with parameter. and should return a correct HTTP1.1 answer.
What you are doing here confirms NOT to HTTP1.1 and you should not name it like that in your requests. It is not.
Looks like I need to wait for that firmware update. Any timeline there?
Enjoy!
Mike
In the meantime, if you'd like to propose a new syntax for any or all of these requests, please feel free and I'll modify my code to match. For the time being we can just put "X" in front of the verbs until the S6B firmware gets fixed.
Well as said, what you are doing with XPOST Is actual a completely correct PUT request. A POST request would require to encode the file transferred. So I vote for XPUT not XPOST.
XLOAD should be replaced by XGET. Because that is what you are doing.
But the main problem remains , that from JavaScript - without using huge libraries like node or so I am not able to do Xwhatever requests. I can use XMLhttprequest in all major browser on all os's, but just valid HTTP requests. Sad but it is. no XPUT, no XPOST, nada.
But the main problem remains , that from JavaScript - without using huge libraries like node or so I am not able to do Xwhatever requests. I can use XMLhttprequest in all major browser on all os's, but just valid HTTP requests. Sad but it is. no XPUT, no XPOST, nada.
Well, since you won't do it, someone else will like I did without special libraries
Are you sure about that. I just put this code into a web page:
var xhr = new XMLHttpRequest();
xhr.open("XGET", "thing", false);
xhr.send(null);
if (xhr.status === 200) {
console.log(request.responseText);
} else {
console.log(request.responseText);
}
It's attached to a mouse click.
After loading the page into the browser (Chrome) I kill the server and run netcat in its place and then hit the mouse button
So the browser seems quite happy to send an XGET or such weird request type. Looks like if I could hand craft a reply from netcat with the correct response headers it would work OK.
Did you "source fix-xcode-warnings.sh"? It won't work to just do ./fix-xcode-warnings.sh.
Yes, but what I found was that I needed to be the owner of the whole directly path for anything inside /opt... I usually leave that dir to root and build with sudo, but looks like I need to be the owner. Since I was building with sudo, sourcing the fix..sh file was not helping, but I had permissions problems without sudo. As soon as I reset the ownership of /opt, propgcc builds and now the xbee loader code builds as well...
Well as said, what you are doing with XPOST Is actual a completely correct PUT request. A POST request would require to encode the file transferred. So I vote for XPUT not XPOST.
XLOAD should be replaced by XGET. Because that is what you are doing.
But the main problem remains , that from JavaScript - without using huge libraries like node or so I am not able to do Xwhatever requests. I can use XMLhttprequest in all major browser on all os's, but just valid HTTP requests. Sad but it is. no XPUT, no XPOST, nada.
So I will need to wait
Enjoy!
Mike
Okay, I'll change XPOST to XPUT. If you check the code you'll see that XLOAD is never used. It's just in the OPTIONS header and can probably be removed. Steve wrote that part to get it to work with his browser code back when I was using XLOAD in the protocol. So are you saying that both of my requests can be XPUT (/eeprom-wr/ and /load/)? Actually, if I move to XPUT and XGET then I guess I can get rid of the "-wr" and "-rd" suffixes and just call the one that writes to EEPROM "/eeprom/". I'll make those changes and push the new code. Thanks for the suggestions!
Edit: Maybe I'll also try just using "PUT" and "GET" in case maybe the internal HTTP server in the S6B doesn't interfere with those like it does with "POST".
Comments
Ha, ha, the magic moment when the light goes on re: JavaScript's non-recursive recursion with callbacks and closures. It took a while before my brain could accept that. It's just so alien to anyone coming to JS from a "normal" language like C++ or Java.
Actually, now that I think about it there is one important detail that I forgot to point out which may have helped. That fileStack thing that is returned from the parser is actually an array within the parser object. It lives as long as the object does. It's not a new thing created every time you call the parser which needs dealing with completely by the caller after the call. That's why we can get away with only popping one file of it after every call. The others stay on the stack till next time. That's why we don't need that loop you added.
I had a go at using Chrome's serial port API a while back, problem was they had changed the API and so it did not work. I have to find time to catch up with the new stuff.
I finally grooked your stack thing. I slaughtered your parser and you 'recursive' test.
There are a couple of things I changed you might need to be aware of.
one thing is uppercase/lowercase for OBJ PRI,PUB,... and we do want all of them JUST being OBJ not objecttiveAnswerwhatever or so.
following changes in your parser:
[SIZE=2]detectSectionChange = [/SIZE][SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]function[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] (line, section) {[/SIZE] [SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0] var[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] sections = [{ re: /^PUB /, section: [/SIZE][SIZE=2][COLOR=#a31515][SIZE=2][COLOR=#a31515]'PUB'[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] },[/SIZE] [SIZE=2] { re: /^PRI /, section: [/SIZE][SIZE=2][COLOR=#a31515][SIZE=2][COLOR=#a31515]'PRI'[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] },[/SIZE] [SIZE=2] { re: /^FUNCTION /, section: [/SIZE][SIZE=2][COLOR=#a31515][SIZE=2][COLOR=#a31515]'FUNCTION'[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] },[/SIZE] [SIZE=2] { re: /^OBJ((\r\n|\n|\r)|$)/, section: [/SIZE][SIZE=2][COLOR=#a31515][SIZE=2][COLOR=#a31515]'OBJ'[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] },[/SIZE] [SIZE=2] { re: /^DAT((\r\n|\n|\r)|$)/, section: [/SIZE][SIZE=2][COLOR=#a31515][SIZE=2][COLOR=#a31515]'DAT'[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] },[/SIZE] [SIZE=2] { re: /^CON((\r\n|\n|\r)|$)/, section: [/SIZE][SIZE=2][COLOR=#a31515][SIZE=2][COLOR=#a31515]'CON'[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] },[/SIZE] [SIZE=2] { re: /^VAR((\r\n|\n|\r)|$)/, section: [/SIZE][SIZE=2][COLOR=#a31515][SIZE=2][COLOR=#a31515]'VAR'[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] }],[/SIZE] [SIZE=2] sec; [/SIZE][SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]for[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] (sec = 0; sec < sections.length; sec += 1) {[/SIZE] [SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]if[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] (line.[COLOR=#ff0000][B]toUpperCase().[/B][/COLOR]match(sections[sec].re)) {[/SIZE] [SIZE=2] section = sections[sec].section; [/SIZE][SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]break[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2];[/SIZE] [SIZE=2] } } [/SIZE][SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]return[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] section;[/SIZE] [SIZE=2] }; [/SIZE]sorry for formatting. regex changed too.
But more important is what you are missing in SpinParser is this.
[SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]function[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] SpinParser() {[/SIZE] [SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]var[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] output = {},[/SIZE] [SIZE=2] fileStack = []; [/SIZE][SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]this[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2].getOutput = [/SIZE][SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]function[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] () {[/SIZE] [SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]return[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] output;[/SIZE] [SIZE=2] }; [/SIZE][SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]this[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2].getFileStack = [/SIZE][SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]function[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] () {[/SIZE] [SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]return[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] fileStack;[/SIZE] [SIZE=2] }; [/SIZE]because we need that stack here in
[SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]var[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] parseProject = [/SIZE][SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]function[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] parse(fileName) {[/SIZE] [SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]var[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] fileStack = parser.getFileStack();[/SIZE] [SIZE=2] [/SIZE]... [SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]if[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] (found==[/SIZE][SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]true[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2]) {[/SIZE] [SIZE=2] appendLine(data.id, [/SIZE][SIZE=2][COLOR=#a31515][SIZE=2][COLOR=#a31515]". init_openspin_done - parsing "[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] + fileName + [/SIZE][SIZE=2][COLOR=#a31515][SIZE=2][COLOR=#a31515]" ... "[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2]);[/SIZE] [SIZE=2] fileStack = parser.parse(fileName, longfileName, content, [/SIZE][SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]true[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2]);[/SIZE] [SIZE=2] } [/SIZE][SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]var[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] done = [/SIZE][SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]true[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2];[/SIZE] [SIZE=2] fileName = fileStack.pop(); [/SIZE][SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]if[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2] (fileName) {[/SIZE] [SIZE=2] done = [/SIZE][SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]false[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2];[/SIZE] [SIZE=2] setTimeout([/SIZE][SIZE=2][COLOR=#020fc0][SIZE=2][COLOR=#020fc0]function[/COLOR][/SIZE][/COLOR][/SIZE][SIZE=2](){[/SIZE] [SIZE=2] parseProject(fileName); }); } [/SIZE]formatting is f..upped, but can you follow me?
because now we are really walking all files...
your version is quitting to fast and not 'eating up' all filestack members.
will add levels (intention?) next.
Enjoy!
Mike
Good point re: the mixed case source.
The parseProject as supplied does indeed find all sub-objects and all sub-sub-objects...It traverses all files and finds all PUB/PRI (except the lowercase ones
Your getFileStack method does not do anything. The fileStack returned by the parser is a reference to the fileStack array in the parser object. Exactly the same as what your getFileStack method returns. Except when you call getFileStack before parsing it is empty {} which is kind of useless.
I think you can demonstrate that by printing out the file stack at various points in your code.
I will have another look when I get home.
An ActivityBot Propeller+S6B is cheap, self-contained, and low power.
There was some discussion of having some other wifi enabled MCU act as a PropPlug.
I have a couple of Xbees but do not have any of those S6Bs. I know that Parallax is using them with I-pads but and I know you and David where doing some stuff, and I know that there is a issue with some buffer size of 2k.
Else I am pretty clueless.
I can not see any way to run the propeller serial boot over wireless at all. This is no standard serial stuff. I just went - wondering what it does - thru @Chips PropellerLoader while I was adding it to the spinneret.
No way to get that timing with tcp or udp.
So direct programming is off the table IMHO. The only thing you can do is to transfer a new firmware to some program on the Propeller and let the prop program its own EEPROM.
Can you give me ANY sources doing what you are doing now? I am perfectly willing to tackle the JavaScript version in the browser. I can always cry call for @Heater when I get stuck....
As for the terminal - there are a couple of them out there, but I did not find one easy enough for my needs. My goal is to run all of this from the spinneret. And I do just have 4 sockets, one already used for NETBIOS.
So just open a socket for the serial stream and keep it open is not doable for me. Still thinking about that problem.
BTW - what @Heater and me doing here is heavily based on HTML5. But maybe not compliant.
current Version is Editor15 - zip in post #451 Link to test http://parallax.msrobots.net/Editor15.htm
Enjoy!
Mike
"...not compliant". Who says? Is there anything in particular we have done that is not compliant?
For a terminal I want to use term.js https://github.com/chjj/term.js
sorry. I just tend to play safe, instead of bragging...
will look at the terminal.
Enjoy
Thing is there is isn't really any such thing as HTML5. The guys developing this stuff have said so. It's become a name for all the new good stuff that has come out recently, webgl, websockets, video tags going back to "boarder-radius". It is constantly under construction.
For a decade or more web developers "played safe" by making sure everything worked on I.E.some.old.version. That will get us nowhere fast.
That terminal thing, could be term.js or tty.js I forget which is the low level part we need. Best to use it with web sockets. If we use the Socket.io library in the browser it will fall back to long polling or even FLASH sockets if websockets are not supported by the server. Socket.io makes all this stuff really easy.
My problem is that by now the spinneret neither support websockets, nor Flash...
Enjoy!
Mike
I just got it working to download a large program today. I had a bug in some PASM code where I got the sense of a range check backwards. Anyway, it can now download big programs using HTTP. The problem is that you have to break the program into small packets of 512 bytes or less. It may be possible to increase that to 1K but probably not much bigger than that because of severe buffer size limits in the Xbee Wi-Fi module. I'm hoping they'll address these in the next firmware release. I'm afraid I haven't been following this project so I'm not sure if what I've done with this simple HTTP downloader is of any use in your project. Maybe someone could describe the current state of this web IDE project and what pieces are missing that might be satisfied by my HTTP download code.
GREAT!!!
And perfectly timed for the weekend.
Will look into this.
Thanks
Mike
OK. The current state of the project.
What we have now is:
A Editor and spin compiler written in Html, JavaScript and CSS.
- Syntax highlighting and code completion for C, C++,C#, html, js,, css, SPIN, PASM and well Cobol. (just do not think about that last one)
- search, replace.
- code folding depending on indention.
- upload and download files from and to local fie system
- loading and saving files from webserver file system(s) (GET/PUT)
- directory support if directory browsing is allowed for webserver file system(s).
- OpenSpin running in JavaScript inside the browser to compile spin/pasm to binary/eeprom
- support for Library files of Spin Compiler
- ability to save resulting binary/eeprom to local file system or webserver file system(s)
- a simple GUI trying to look as close to the PropTool as feasible by now.
- all of this in 1 .htm file and 2 .js files. No server side code required. All runs in the Browser.
What is still missing:
- your code to program a Propeller via S6B. (will look into that for sure)
- my code to program a Propeller via spinneret as host. (WIP)
- @Heater.'s code to make a Chrome app out of it to use local serial ports from the browser (WIP)
- Serial Terminal to use in Browser. Needs to work with all 3 above.
Just give it a try http://parallax.msrobots.net/Editor15.htm
edit - all of this is MIT licensed - edit
Enjoy!
Mike
1) xbee-config will setup your Xbee S6B with the correct settings to run the HTTP server. This is a Propeller program.
2) xbee-loader is a Propeller program that you would normally write to the first 32K of EEPROM. It implements a simple HTTP server that knows how to write to EEPROM and start a program from EEPROM.
3) xbee-load is a program that runs on the PC (Macintosh, Linux, Windows). It reads a Spin binary and sends it to the Propeller over a Wi-Fi connection. It uses the XPOST /eeprom-wr/ and /load/ requests to load and start a program.
4) eeprom-dump is a program that isn't really needed except for debugging. It dumps data from the upper 32k of the EEPROM. It is a Propeller program but I'm in the process of adding this feature to the HTTP protocol as well.
There is a Makefile that builds all of these but you need propgcc installed. I've been using the default branch from Google Code but it may build okay under the release_1_0 branch that is distributed with SimpleIDE as well. There is currently no SimpleIDE project for building this.
In addition to all of this there is the beginnings of an HTTP server library. The main interface to this is in xbee-server.c and it uses a PASM frame driver to talk to the S6B module which is in the xbeeframe.c and xbeeframe_driver.spin files.
Running make all on my Mac OS X (10.9) system builds most of the project but returns:
I use:
openspin Version 1.00.70
propeller-elf-gcc: Thread model: singlegcc version 4.6.1 (propellergcc-alpha_v1_9_0_2400)
Where should I look for: "_eepromClose"?
UPDATE: that symbol is in eeprom.h which is in propgcc's lib directory hierarchy. This does not get installed with SimpleIDE. It's also not in /opt/parallax/lib's hierarchy after a progcc build, so folks will need to add their "/SOURCEDIR/propgcc/lib/include/ to their $PATH var to build this.
Thanks,
dgately
Did you rebuild the propeller-gcc default branch?
Good question... I had rebuilt on 3/13, for what I thought was the default branch. I've re-pulled default and now I get the errors that I thought "fix-xcode-warnings.sh" was supposed to take care of, but I still get errors on fputs & sbrk...
[FONT=Monaco]/Users/altergator/source/propgcc/binutils/binutils/readelf.c:9051:20: error: adding 'int' to a string does not append[/FONT] [FONT=Monaco] to the string [-Werror,-Wstring-plus-int][/FONT] [FONT=Monaco] fputs (" " + n, stdout);[/FONT] [FONT=Monaco] ~~~~~~~~^~~[/FONT] [SIZE=2] & [/SIZE][FONT=Monaco]/Users/altergator/source/propgcc/binutils/binutils/nm.c:1697:28: error: 'sbrk' is deprecated[/FONT] [FONT=Monaco] [-Werror,-Wdeprecated-declarations][/FONT] [FONT=Monaco] char *lim = (char *) sbrk (0);[/FONT] [FONT=Monaco] ^[/FONT] [FONT=Monaco]/usr/include/unistd.h:582:7: note: 'sbrk' declared here[/FONT] [FONT=Monaco]void *sbrk(int);[/FONT] [FONT=Monaco] ^[/FONT][/COLOR]I'm going to do a fresh clone of propgcc and see what happens.
dgately
I looked at xbee-load.c and you - hm - invent new HTTP methods XPOST and XLOAD.
But it is not a post at all since you do not encode a post body. What you are doing is a PUT request not a post. Because you are sending the binary data as body.
Why are you using XPOST instead of PUT?
HTTP is a standard and you can not just 'invent' new methods.
The JavaScript XMLhttp request can just use methods defined in HTTP1.1. So I can not 'create' a XPOST request. It is not defined by HTTP1.1.
The same applies for your XLOAD request which is essential a GET request with Parameter. Why you do not use that?
As is this is NOT HTTP1.1 and I will not be able to use it from JavaScript with the XMLhttp object.
By definition a PUT request replaces the resource described by the URL.
That is exactly what you want to do. PUT /eeprom-wr/32768 will replace the first 512 bytes of the eeprom. Clear and confirming with HTTP1.1. Replacing a resource described by URL.
A GET /eeprom-wr/32768 should return those 512 bytes again. Clear and confirming with HTTP1.1. Reading a resource described by URL.
Like in the Linux file system a resource don't has to be a file. can be a device also. or a EEPROM. Does not matter. It is just a resource described by a URL.
The same applies to your XLOAD. It is just a GET with parameter. and should return a correct HTTP1.1 answer.
What you are doing here confirms NOT to HTTP1.1 and you should not name it like that in your requests. It is not.
see RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616.html
Enjoy!
Mike
.
The S6B server eats standard HTTP methods like PUT/GET/POST, and does not pass them to the serial port.
The only way to get methods past the S6B is to use non standard ones like David has defined.
So they have to be "reinvented" for use with S6B.
OK I do understand. This is quite sad. But if you need to use 'non-standard' methods it is not HTTP protocol but something else.
Sorry. Do not name it HTTP if it is not.
Enjoy!
Mike
Looks like I need to wait for that firmware update. Any timeline there?
Enjoy!
Mike
Thanks,
David
XLOAD should be replaced by XGET. Because that is what you are doing.
But the main problem remains , that from JavaScript - without using huge libraries like node or so I am not able to do Xwhatever requests. I can use XMLhttprequest in all major browser on all os's, but just valid HTTP requests. Sad but it is. no XPUT, no XPOST, nada.
So I will need to wait
Enjoy!
Mike
It is not that I am not willing. In the opposite. I would like to program a propeller from my editor. It is the basic idea of the whole thing.
but I can't use XMLhttprequests with a verb like XPOST. can you?
Enjoy!
Mike
var xhr = new XMLHttpRequest(); xhr.open("XGET", "thing", false); xhr.send(null); if (xhr.status === 200) { console.log(request.responseText); } else { console.log(request.responseText); }It's attached to a mouse click.After loading the page into the browser (Chrome) I kill the server and run netcat in its place and then hit the mouse button
net cat sees an XGET request like so:
So the browser seems quite happy to send an XGET or such weird request type. Looks like if I could hand craft a reply from netcat with the correct response headers it would work OK.
Yes, but what I found was that I needed to be the owner of the whole directly path for anything inside /opt... I usually leave that dir to root and build with sudo, but looks like I need to be the owner. Since I was building with sudo, sourcing the fix..sh file was not helping, but I had permissions problems without sudo. As soon as I reset the ownership of /opt, propgcc builds and now the xbee loader code builds as well...
Thanks guys,
dgately
Edit: Maybe I'll also try just using "PUT" and "GET" in case maybe the internal HTTP server in the S6B doesn't interfere with those like it does with "POST".