CyanIDE - Web-based propeller IDE
ProcessingData...
Posts: 208
CyanIDE is my personal project to make a web-based editor for the Propeller.
683 x 344 - 94K
Comments
Can't wait to play with it.
https://c9.io/
https://github.com/ajaxorg/cloud9/
Cloud9 certainly runs on BB and also looks like it runs on RasPi, so that's a boon for all the Node/JS folks!
Edit: Just found ideone also. You can play in all kinds of languages here. Haven;t dug any further yet on this one.
Currently, one of my biggest issues is syntax highlighting, primarily the backgrounds of code blocks like CON and PUB. I wrote a highlighter a while ago as a Chrome extension for the forums that handled it fairly well, but I haven't been able to replicate it in Codemirror(yet), which is the editor API I'm currently using. I haven't been able to find any other editors that support per-line background coloring.
I found that Phil did his own experimentation with a syntax highlighter in Codemirror(http://www.phipi.com/editspin/), but all the work that he has done is in version 2 of Codemirror, now deprecated and incompatible with Codemirror 3 (which supposedly can support per-line background highlighting).
I'll keep plugging away at it, even though I have a tough time with regex, especially in Javascript.
ideone doesn't look like they want to be distributable but hey do have the API that you can hook your front end into and use their backend for compiling? (need to read more on this).
https://github.com/ajaxorg/ace
On-the-fly background highlighting. I think this is the highlight of my day.
I'll take a look at Ace and see if I can replicate the highlighting.
I played around with Cloud 9 on c9.io. It might be a bit heavy weight so I like the idea of making a simplified IDE for Spin.
I was wondering what it would take to get ACE working on it's own (Never had any luck following the Cloud 9 instructions) so I'd love to see what you come up with.
The Syntax Highlighting is giving me a few issues, mostly in performance; I need to change the way I'm implementing it.
I'm also trying to use one of the emulators I found on the forums to create virtual propellers in the cloud, so you can interface with the serially and actually develop on the go.
Hopefully I can let you guys use it soon!
Looking good so far.
I'm rebuilding this project from the ground up, and it's working well so far. I've recycled pieces of @msrobots editor [http://forums.parallax.com/showthread.php/152711-A-Propeller-WebTool-Framework-for-Compiled-Languages/page31?highlight=CyanIDE], and made some optimizations and improvements.
Currently, I can load up a local spin file into the current tab, and have a fully functional Serial Terminal to work with.
The WebWorkers compiling portion I can copy and implement,
However, looking at the most critical piece of the project, the Javascript propeller loader, I am utterly at a loss. Many google searches and forum searches later, I am still no further is starting the implementation of the loader/propeller identifier.
So, I am asking for some help with this. I've found a Python implementation of a loader, but as I have explained, I'm not sure where to start with it.
I know that the baud rate is 115200.
[Flush Output Buffer]
[Set DTR to On]
[Wait for a few milliseconds]
[Set DTR to Off]
[Wait for a few milliseconds]
[Flush Input Buffer]
???
I think if I can understand the loading process better, then I would be better able to write and implement the loader.
The Chrome Apps serial API documentation is here: https://developer.chrome.com/apps/serial
Any pushes in the right direction would be greatly appreciated. Thank you!
Here is a screenshot of the project in its current state:
Some systems I've seen pulse both RTS and DTR, to make "which is used" a don't care.
- I think some very cheap adaptors, only bring out one.
There is also this thread
http://forums.parallax.com/showthread.php/159865-p1load-a-propeller-loader
Addit : when you are unsure of the elasticity of the Sw/OS/Links (sounds true here?) it could pay to collect the pgm info into an array first, then do one call. (See David's comments)
That reduces chances of unexpected gaps, but should have a message predicting how long it will take, based on the Baud chosen and the Pgm payload size.
It can be found in the Propeller 1 Verilog page. See here
That will confirm the transport & send code is all OK, then you can do the pwm style bit-triplet modulation.
eg
http://forums.parallax.com/showthread.php/97913-The-3-Bit-Protocol
I started work on a Propeller loader in JavaScript a few weeks back. You can see it here: https://github.com/ZiCog/propeller-loader.js
The basic plan was to take the Propeller loader from prop-gcc (PLoadLib) as a guide and implement it in JavaScript. The end result is to be usable in Chrome as an extension, and from the command line under node.js
Some details:
1) The PLoadLib directory contains the orgnal C code of the loader from prop-gcc. It has been hacked around with debug printf so we can compare what it sends/receives over the serial line with any JS version we create. This loader is known to work on the Raspberry Pi and MIPS based WIFI routers.
PLoadLib can be built with:
$ gcc -DMAIN PLoadLib.c osint_linux.c
2) propeller-loader.js - This is the JS version of the loader algorithm from PLoadLib.c Note that due to the asynchronous nature of JS this code does not look much like the original. You cannot have a loop blocking on serial port reads for example.
3) propeller.js - This is the interface to the Propeller over a serial line. It is for node.js. It also drives a GPIO pin on the Raspberry Pi GPIO header for Propeller reset.
4) There is no propeller serial interface for use in Chrome yet. The idea is that a module similar to propeller.js is created to do that and dropped in to the Chrome version.
5) loader.js is to be "main" for the command line version under node.js. It is not yet connected to anything else.
6) crockford_objects.js - This is junk. Just playing with a way to make classes in JS.
TODO:
1) Hook up loader.js to propeller-loader.js for use under node.
2) None of this has been tested against a real Propeller.
3) Make it work !
4) Create the Chrome app version.
Thanks to @Heater for your propeller-loader code. I have successfully ported it over to the Chrome Apps API.
However, I have run into an issue. When the propeller goes into it's reset state, chrome.serial throws "system_error", and won't send or receive any more input on that connection, until I disconnect and reconnect, flushing the input from the propeller, which means I miss the handshake and all that for doing any actual *loading*.
So, as I explore other options, I have a few ideas:
- The Propeller actually resets on serial.connect(), (I'm assuming that it toggles RST for me. ) so I might be able to catch the propeller by starting the loading process immediately after the connection is established.
- Possibly interface with the FTDI devices found in most of the USB-Serial interfaces that are in prop plugs, on quickstarts, etc. I'd prefer not to do that, as it removes the whole "abstraction" of the USB-Serial interface with CyanIDE. (What if someone's using a USB<->Serial device from a different manufacturer?)
... and that's about it. Short of writing my own application to deploy with the chrome app (which I'd like to avoid also), that's where I'm at. So, I'm seriously hoping the first option works.
Any ideas on why chrome might have this strange behavior? Also, any other ideas?
On a less-frustrating note, if you would like to poke at the pre-pre-pre release version of CyanIDE, you can install it in Chrome 38+ on ChromeOS, Windows, MacOS and Linux from this link:
https://chrome.google.com/webstore/detail/cyanide/pbghfehmafdhddjjpphclgailccffcgh
- Subfolders are not supported
- The serial terminal should work-ish. enough to send characters to your Propeller. RST and DST buttons do not work.
- Saving and creating new files works. Deleting files works by right-clicking the file.
Let me know what you think, and if you have any suggestions. Thanks!
Sounds almost like a bug in Chrome.
Can you connect to a std terminal, and check send/receive and how it reacts to handshake lines, and even send a wrong baud character (eg set terminal to half the real baud and send 00, to generate a deliberate frame error )
Also try simple loopback tests, at various baud rates.
I did abstract the loader code from CyanIDE, so I'll see about getting that up on git later today.
I've noticed that I don't have the same serial issues on the Chromebook, but I'm still getting weird values back from the propeller. I'll keep testing.
I rewrote the code for the loader, and now I'm getting input from the propeller! I'll be testing it on windows later this evening.
Changes are up on github.
Sorry for my ignorance here.
No problem! I didn't explain very well on how to get the loader installed in the readme.
To install the loader on the Chromebook,
- Go to the right hand column of the github site, and click "Download Zip".
- Open the zip in the Files app
- Chrome will automatically open and mount the zip folder like it would a USB Drive.
- Open a Chrome window, click on the menu in the right-hand corner, and go to More Tools->Extensions
- Check the checkbox that says "Developer Mode"
- You should see some new buttons appear, click the one that says "Load unpacked extension"
- Browse to the Propeller Loader folder that was mounted earlier, and click open
- Chrome will install the app, and you should be able to click "Launch" underneath the name of the app. (PropellerLoader2.0)
Right now, it simply opens a connection to the propeller, writes the first sync byte, sends the LSFR and the rest of the sync bytes, and then prints whatever it got back from the propeller.
It's been referenced in this bug report: https://code.google.com/p/chromium/issues/detail?id=428588&q=serial%20windows&colspec=ID%20Pri%20M%20Week%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified
I'll go forward with developing on Linux and ChromeOS, and hope that this gets fixed in the next release of Chrome. If not, I may create a different loader for Windows to use with CyanIDE.