Shop OBEX P1 Docs P2 Docs Learn Events
PropellerIDE Development Thread — Parallax Forums

PropellerIDE Development Thread

Brett WeirBrett Weir Posts: 288
edited 2015-09-24 19:16 in Propeller 1
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
«134567

Comments

  • Hi Brett,

    Welcome back! I'm sure there are many here who will look forward to new developments in PropellerIDE.

    David
  • VonSzarvasVonSzarvas Posts: 3,262
    edited 2015-09-24 08:30
    Yes, welcome back Brett. And take care of yourself.

    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???!!! :)
  • Hello Brett,

    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.
  • VonSzarvas wrote: »
    Yes, welcome back Brett. And take care of yourself.

    Thanks. =)
    VonSzarvas wrote: »
    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.

    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.
    VonSzarvas wrote: »
    Oh, and did I mention PropBasic support???!!! :)

    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.
  • Brett Weir wrote: »
    VonSzarvas wrote: »
    Oh, and did I mention PropBasic support???!!! :)

    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.
  • Hi Brett,

    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
  • dnalor wrote: »

    Ahh, let's see...
    - If an error occurs during compilation (F8, F9), a new tab is opened every time, instead of displaying the error in the open tab.

    It should display in the same tab. Have you tried a recent version?
    - When you press the enter key after a comment at the end of a line, a new comment line is generated. To write new code you have to hit backspace until you are at the beginning of the line.

    Yeah, this is annoying. I want to change this behavior.
    - In DAT-Section: Bytes between strings are colored like a string e.g. TESTDAT BYTE $0D,$0A,"String",$0D,$0A,"String",0"

    The syntax highlighter needs some work.
    - Code suggestion/auto-completion do not work!? e.g. with pressing the point after the object name only a empty box appears.
    f560114db78d81f6c56a5ea2a981d3.jpg

    This absolutely should work. I put a lot of work into overhauling this feature. Try a new version?
    - Save as at a new file opens the file dialog in programmfolder on one computer, system32 at an other computer instead the last used folder.

    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.
    - A doubleclick on a spin-file opens it in a new PropellerIDE with all the opened tabs of the already opened PropellerIDE instead in a new tab only or a PropellerIDE with only this file.

    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.
    And it would be nice, if you could select another installation path (not in program files) or at least a different folder for the libraries. A second library path would also be a possibility. Editing files in the programmfolder of Windows 7 is not good idea. These files are then saved in some virtual folder.

    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.
    For now I use PropellerTool again, because I miss the 'block group indicators'. I can not live without them.

    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!
  • Brett Weir wrote: »
    VonSzarvas wrote: »
    Oh, and did I mention PropBasic support???!!! :)

    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.

    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
  • David Betz wrote: »
    Hi Brett,

    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

    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.
  • Brett Weir wrote: »
    David Betz wrote: »
    Hi Brett,

    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

    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'll take a look at your API to see if it fits at all with what I've been working on or if I think I can contribute. I've wanted to build a Qt-based serial terminal emulator for a while. Maybe this will be an opportunity to work on one.

  • Looks like you've got Jeff's Wi-Fi protocol mostly done. Probably no point in me jumping in at this point. I didn't realize you were nearly there.
  • I would like to see support for the new openspin -u option (un-used code remover), currently I’m using a shell for this
  • rjo__rjo__ Posts: 2,114
    Brett,

    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
  • Brett Weir wrote: »
    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.

    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!!




  • David Betz wrote: »
    Looks like you've got Jeff's Wi-Fi protocol mostly done. Probably no point in me jumping in at this point. I didn't realize you were nearly there.

    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.
  • Roadster wrote: »
    I would like to see support for the new openspin -u option (un-used code remover), currently I’m using a shell for this

    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.
  • rjo__ wrote: »
    Brett,

    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'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. :)
    I would like to see more choices for setting the Baud rate in the serial terminal... ala Proptool.

    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.
    Nice work. Hope your health issues are fully resolved.

    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. :)
  • VonSzarvas wrote: »
    Brett Weir wrote: »
    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.

    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!!

    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.
  • jmgjmg Posts: 15,140
    Brett Weir wrote: »
    I would like to see more choices for setting the Baud rate in the serial terminal... ala Proptool.

    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.
    Allow Any-value at all is the best.
    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.

  • jmg wrote: »
    Brett Weir wrote: »
    I would like to see more choices for setting the Baud rate in the serial terminal... ala Proptool.

    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.
    Allow Any-value at all is the best.
    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 Weir wrote: »
    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.
    I've tried using Jeff's two-stage loader over a serial connection and it speeds up loading of medium to large programs. I suppose very small programs are slightly slower though. Also, propeller-load uses a two-stage loader for XMM programs. The main problem with them is that they assume that you have a crystal on your board to allow higher baud rates. The beauty of the internal Propeller loader is that it works with the internal clock.

  • BeanBean Posts: 8,129
    edited 2015-09-25 12:54
    VonSzarvas wrote: »
    Oh, and did I mention PropBasic support???!!! :)

    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
  • I would like to see PropBasic also, but correct me if I'm wrong, but openspin doesn't support @@@ and PropBasic uses that operator, I guess bstc can be used.
  • BeanBean Posts: 8,129
    Roadster wrote: »
    I would like to see PropBasic also, but correct me if I'm wrong, but openspin doesn't support @@@ and PropBasic uses that operator, I guess bstc can be used.

    Yeah, that is what I do for SimpleIDE (use bstc). I don't understand what the big deal is to support @@@@ ?

    Bean
  • David Betz wrote: »
    Brett Weir wrote: »
    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.
    I've tried using Jeff's two-stage loader over a serial connection and it speeds up loading of medium to large programs. I suppose very small programs are slightly slower though. Also, propeller-load uses a two-stage loader for XMM programs. The main problem with them is that they assume that you have a crystal on your board to allow higher baud rates. The beauty of the internal Propeller loader is that it works with the internal clock.

    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.
  • Brett Weir wrote: »
    David Betz wrote: »
    Brett Weir wrote: »
    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.
    I've tried using Jeff's two-stage loader over a serial connection and it speeds up loading of medium to large programs. I suppose very small programs are slightly slower though. Also, propeller-load uses a two-stage loader for XMM programs. The main problem with them is that they assume that you have a crystal on your board to allow higher baud rates. The beauty of the internal Propeller loader is that it works with the internal clock.

    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.
    Yes, low baud rates should work.

  • Brett WeirBrett Weir Posts: 288
    edited 2015-09-25 19:58
    Bean wrote: »
    Roadster wrote: »
    I would like to see PropBasic also, but correct me if I'm wrong, but openspin doesn't support @@@ and PropBasic uses that operator, I guess bstc can be used.

    Yeah, that is what I do for SimpleIDE (use bstc). I don't understand what the big deal is to support @@@@ ?

    Bean

    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.
  • BeanBean Posts: 8,129
    Brett, I agree that the "@" operator should be revised (fixed) so that it returns the "true" address. But that would probably break old code.

    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
  • Bean wrote: »
    Brett, I agree that the "@" operator should be revised (fixed) so that it returns the "true" address. But that would probably break old code.

    Yeah, it would. The biggest test would be to see how much code out there actually uses this feature.
    Who is the author of openspin ? Is there any way we could try to get @@@ implemented ?

    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.
    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 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 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 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.
    I am open to modify PropBASIC in any way to make it work.

    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 @@@.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2015-09-26 07:00
    Re: @@@

    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
Sign In or Register to comment.