PropellerIDE Development Thread
Brett Weir
Posts: 288
Hi everybody,
Until recently, I had been out of commission for some time and hadn't been making any progress on PropellerIDE (long story). Now that I'm getting back up to speed, I'd like to say hi and find out how everyone is doing.
A little about what I'm doing now. I finally have the PropellerIDE release process completely automated, so turnaround time for new builds is miles ahead of where it was before. The most up-to-date development releases can be found here:
https://github.com/parallaxinc/PropellerIDE/releases
The only build that isn't automated yet is Raspberry Pi. If anyone can help with setting up QEMU or cross-compiling to ARM, that would help a lot and ensure that Raspberry Pi releases are always up to speed.
I'm also refactoring packthing to support more output formats, including RPM, Mac PKG, etc. I recently added a self-extracting archive target. Are there any other formats you'd like to see? Does anyone need 32-bit releases?
The serial terminal is now embedded into PropellerManager, so I can start deeper integration between the terminal and loader. As for now, the terminal is stable and supports copy / paste without crashing (yay!). Some people are reporting problems with the most recent loader. Can you guys download it for any platforms you have available and try it out? I'd like to know how many people are experiencing the same problem and on what boards / cables / operating systems.
Some more general questions... How many people are using PropellerIDE? What do you like about it? What do you not like about it? What features would you most like to see? What is your programming language of choice on the Propeller?
Anyway, it's good to be back.
PropellerIDE Useful Links: Docs - Tracker - Repo
Until recently, I had been out of commission for some time and hadn't been making any progress on PropellerIDE (long story). Now that I'm getting back up to speed, I'd like to say hi and find out how everyone is doing.
A little about what I'm doing now. I finally have the PropellerIDE release process completely automated, so turnaround time for new builds is miles ahead of where it was before. The most up-to-date development releases can be found here:
https://github.com/parallaxinc/PropellerIDE/releases
The only build that isn't automated yet is Raspberry Pi. If anyone can help with setting up QEMU or cross-compiling to ARM, that would help a lot and ensure that Raspberry Pi releases are always up to speed.
I'm also refactoring packthing to support more output formats, including RPM, Mac PKG, etc. I recently added a self-extracting archive target. Are there any other formats you'd like to see? Does anyone need 32-bit releases?
The serial terminal is now embedded into PropellerManager, so I can start deeper integration between the terminal and loader. As for now, the terminal is stable and supports copy / paste without crashing (yay!). Some people are reporting problems with the most recent loader. Can you guys download it for any platforms you have available and try it out? I'd like to know how many people are experiencing the same problem and on what boards / cables / operating systems.
Some more general questions... How many people are using PropellerIDE? What do you like about it? What do you not like about it? What features would you most like to see? What is your programming language of choice on the Propeller?
Anyway, it's good to be back.
PropellerIDE Useful Links: Docs - Tracker - Repo
Comments
Welcome back! I'm sure there are many here who will look forward to new developments in PropellerIDE.
David
Features... I'd love a check box that enables loading an image directly to the upper part of 64Kb eeprom.
You might need to load some code to ram that facilitates the shift.... I could provide that if your time is allocated elsewhere.
Granted, this 'need' may be slightly exotic though!
Oh, and did I mention PropBasic support???!!!
some time ago I posted in the other thread: http://forums.parallax.com/discussion/comment/1340933/#Comment_1340933.
For now I use PropellerTool again, because I miss the 'block group indicators'. I can not live without them.
Thanks.
Large size EEPROM is something that I have never used before on a project, so I'd like to see what's involved in adding it and how it affects things.
Ahhhh! That one sounds fun. LanguageManager was almost in a good place to do this before I got sidetracked. I can't wait to get back to this one.
Sounds like the right time and place to mention any public issue tracker and/or feature roadmap. I recall seeing something like that a while ago but don't remember where.
Have you been working on implementing Jeff's Wi-Fi loader protocol for PropellerIDE? Any chance I could convince you to let me try to make my Wi-Fi loader work for your PropellerIDE needs?
Thanks,
David
Ahh, let's see...
It should display in the same tab. Have you tried a recent version?
Yeah, this is annoying. I want to change this behavior.
The syntax highlighter needs some work.
This absolutely should work. I put a lot of work into overhauling this feature. Try a new version?
It should open in the library folder. Are you running as an administrator account on the other computer? But I'll be adding the last directory support back in. I removed during a large refactoring and haven't put it back.
This is expected behavior. I wanted PropellerIDE to work more like a web browser and provide a persistent Propeller workspace. Ideally you should only need one PropellerIDE, because it needs to own all the Propeller devices attached to the system. This is how the serial terminal and loader can interact with the hardware without clobbering each other.
I like how it works now, but here are other possibilities.
- Have a save/load session feature.
- Pop up editor *windows* that appear as separate applications but are running on top of the same PropellerIDE base.
I never intended to have users editing files in the Programs folder. The idea is still to copy the library folder to somewhere that you can have a working copy. I'm reluctant to have the installer do this because then there's the risk of the installer clobbering all of the user's modified work. The installer would start becoming more complicated. So I'm on the fence.
You mean the indent guides, right? These are planned, but before I can implement them, I have to overhaul how the background coloring is implemented. Big job. =|
You should try out the latest version!
Oh, haha, it's in the same place and there's a link to it in the project GitHub. I'll add them to the top though.
Tracker: https://lamestation.atlassian.net/projects/IDE/
Repository: https://github.com/parallaxinc/PropellerIDE
I have shelved Wi-Fi support to focus on the core application and wait for it to become more stable.
PropellerIDE uses PropellerManager now, which is more than just a loader. I have put a great deal of work into building a general purpose API for Propeller devices, and more and more of PropellerIDE is using this API. The command-line loader, the serial terminal, and soon the memory map, all use this API directly.
http://developer.parallax.com/projects/propellermanager/doc/html/annotated.html
I also regularly test the loader on Windows, Mac, and Linux, which is where I ran into problems when PropellerIDE still used p1load. To use your loader, it would need to provide all of this.
If you're really interested in contributing to PropellerIDE, it would be very helpful to have a second set of eyes working on the PropellerManager API. Most of the infrastructure for eventually adding Wi-Fi support should be in place already.
I use PropellerIDE all the time. I love it. The one main advantage over Proptool that I really make use (all of the time) is the scrolling list of Pub and Pri routines. This makes editing long programs such a pleasure. I would like to see more choices for setting the Baud rate in the serial terminal... ala Proptool.
Nice work. Hope your health issues are fully resolved.
Rich
Couple ways I had thought about previously...
1) PropellerIDE uploads the code image to the eeprom in the normal way. Then if the checkbox is ticked, then PIDE will auto-perform a 2nd upload to ram of some code which just copies the image from lower to upper eeprom.
2) PropellerIDE uploads a loader to RAM and then listens on serial port. The loader will send some bytes to the serial port (ie. "IM READY"), then PIDE will reply with the actual image which the loader just saves into upper eeprom. When finished, the loader could optionally read back that image and either stream back out on the serial port for PIDE to verify, or calculate a running checksum (LUHN would be easy), and transmit that.
Clearly option 1) would trash the lower eeprom, whereas 2) wouldn't .
I prefer 2), but 1) is perhaps simpler to implement as an "add-on" feature. - Well, those are the ideas I had to share.
As to this being a valid user feature- not sure. Maybe the same feature could upload user DATA too to upper eeprom. So many Parallax boards have the double eeprom nowadays- yet few people seem to take advantage of that for pre-loading data.- Well, or maybe they do!!
I wouldn't say the Wi-Fi support is nearly there. All the other nice stuff I need is there and all the application that use PropellerManager are already there.
I had been working on integrating that before but there were stability issues and then I never got back to it. That's something I can definitely pick back up though.
I'm really very happy to hear that. I spent a great deal of time building the new project viewer and it's good to hear you're making use of it.
This is already in the works. There will be presets, but you'll also be able to enter your own baud rate settings. I use MIDI a lot so 312500 is an important (and often unavailable) setting, so I want to be sure people can use whatever obscure setting they need.
Thanks. I am doing better now. I've started exercising and sleeping more and I'm much less overwhelmed with my work now. Now my focus is on getting my company moving forward again and putting a solid LameStation course together by next summer, so I'm pretty excited about that.
A big part of supporting the Wi-Fi loader is creating a framework for implementing two-stage download processes. I can see this being doable once PropellerManager is more mature. Adding it now would be something of a hack job, but if PropellerManager goes where I want it to, this kind of thing could be supported as "just another download option." It's low on my list of things to worry about though.
These days, most modern USB-Bridge devices allow (almost) any baud value and they will give you a baud operation determined by the Virtual Baud Clock (usually 12MHz or 24MHz)
If you allow users to enter any value, the COM open usually reports an error, if that value is not supported - or some parts auto-snap to the nearest supported value.
Yessir, at this point, it's more a matter of getting around to exposing a text box in the interface. :P
Brett,
Let me know and I'll do anything I can to get PropBASIC supported.
I think you have my e-mail address, if not just send me a PM.
P.S. Also willing to support Lamestation with PropBASIC.
Bean
Yeah, that is what I do for SimpleIDE (use bstc). I don't understand what the big deal is to support @@@@ ?
Bean
There's no reason it has to use the external clock if you don't care about download speed. PropellerManager will read the binary to determine clock settings and insert them into the image.
Who is going to add the support? I didn't write the compiler and I know as much about it.
And if we are improving the compiler, I'd be more interested to see a revised @ operator that returns a real memory address rather than a separate @@@ operator. I find @@@ was a path of least resistance way to add a missing feature from the original @ operator. Is there really a reason to have three memory address operators? Why not just one?
There's lots of features I'd like to see in OpenSpin that aren't there because there isn't anyone to do them. If you could produce a version of PropBASIC that didn't need the extra operator, we could sidestep the whole problem, as realistically, I shouldn't even be distributing bstc with PropellerIDE anymore. If PropBASIC doesn't work without bstc, then I can't distribute PropBASIC either, and then we are nowhere.
Who is the author of openspin ? Is there any way we could try to get @@@ implemented ?
The problem with not using @@@ is that then I need to generate code just to get the address of something that is really just a constant, but there is no operator to get that constant. This creates a lot of extra code and there is only 496 instructions available as it is. So that would be my last resort.
I think the @@@ is used anytime code that is NOT in the initial cog has to access any hub variable. I'll have to check on that though...
I am open to modify PropBASIC in any way to make it work.
Bean
Yeah, it would. The biggest test would be to see how much code out there actually uses this feature.
Roy Eltham is the developer. Anything is possible, but Roy has a job and family, and after waiting for almost a year, unused code removal still isn't stable enough for me to release it.
I know full well the pain you're going through. I have to do some icky things to return pointers to some data in the LameStation music format.
I use @ and @@ when for example I have a list of addresses within the same object. Spin compilers addresses in DAT blocks relative to the object so I have to add the object address to use them.
Before I can integrate PropBASIC, it needs to be released under an open source license, added to the Parallax GitHub, and made to compile with an open source Spin compiler, the only one I know if being OpenSpin. If you want to see this happen any time in the near future, the best bet is to remove the requirement for @@@.
It's ugly. Although I commend Brad for enabling something to uncripple @, we need to come up with either a different syntax or else overload Spin's original @ operator to accommodate what Brad was trying to accomplish.
-Phil