I seem to recall that when it came to in COG driver code it was OK using make files.
Nowhere near as easy as using Spin and PASM in the Prop Tool or BST.
Spin/PASM is definitely easier to use with multiple file projects since the OBJ section does the job of both #include and the linker. That's a big win. I suppose we could create a C/C++ preprocessor like they did with the Arduino ot make C/C++ easier. The problem is then you don't have real C/C++.
All we want is to write a few hundred lines of code and compile it. Would be better just to concatenate the source files together and let prop-gcc compile it.
That concept was workable when you only had one board to work with. So, now I have, four or five different boards, each with a different capability, how do address that problem, with your concept. I know we just all settle in on one board type, and then we can have that SimpleIDE work with that one Simple Universal Board, life has just gotten simpler. So then when you want to do something real, you just go with an Arduino.
All we want is to write a few hundred lines of code and compile it. Would be better just to concatenate the source files together and let prop-gcc compile it.
That concept was workable when you only had one board to work with. So, now I have, four or five different boards, each with a different capability, how do address that problem, with your concept. I know we just all settle in on one board type, and then we can have that SimpleIDE work with that one Simple Universal Board, life has just gotten simpler. So then when you want to do something real, you just go with an Arduino.
Ray
Board type is not really needed unless you're using the XMM memory model. We could make it go away if we make XMM go away.
To my mind the whole idea of pulling PASM out of Spin objects to use with C is nuts. It's a complex convoluted thing that most users should not have to do.
If by "most users" you mean simple users, then yes, I'd agree. On the other hand, I have a project where I'd LOVE to use C/C++ for the high level stuff, but better than half the functionality is in PASM because it needs to be really fast.
I tried moving two of my objects over using the "Spin file" method. One works beautifully, the other just hangs. Both work in the original Spin/PASM project. It's frustrating in the extreme, and made worse by the lack of debugging on the Prop.
To my mind the whole idea of pulling PASM out of Spin objects to use with C is nuts. It's a complex convoluted thing that most users should not have to do.
If by "most users" you mean simple users, then yes, I'd agree. On the other hand, I have a project where I'd LOVE to use C/C++ for the high level stuff, but better than half the functionality is in PASM because it needs to be really fast.
I tried moving two of my objects over using the "Spin file" method. One works beautifully, the other just hangs. Both work in the original Spin/PASM project. It's frustrating in the extreme, and made worse by the lack of debugging on the Prop.
I think even SimpleIDE makes it easy to integrate existing PASM objects into your C programs as long as you let it build them from .spin files. It doesn't seem to handle .s, .S, or .sx files well though, especially when their names conflict with .c or .cpp files.
Let's not confuse SimpleIDE and PropellerIDE. The former is intended for C/C++ using prop-gcc, I'm told any Spin support it has is going to be removed if it has not been already. The later is for Spin using OpenSpin.
Combining those posts has left me confused.
If "SimpleIDE makes it easy to integrate existing PASM objects into your C programs as long as you let it build them from .spin files" then why would "any Spin support it has is going to be removed if it has not been already" ?
Other vendors have one IDE (including debug) and DownLoader, for multiple languages.
Some even manage it for multiple MCUs.
The best systems allow you to mix HLL and Assembler and step-debug into either, but getting all those ducks in a row is not trivial, especially around Debug (and Debug is a bridge Parallax is not even approaching yet )
The supportin SimpleIDE for including a .spin file in a C/C++ project just to make use of the embedded PASM code is separate from supporting Spin projects. I think it is the Spin project support that is under consideration for removal.
The support in SimpleIDE for including a .spin file in a C/C++ project just to make use of the embedded PASM code is separate from supporting Spin projects. I think it is the Spin project support that is under consideration for removal.
That still seems strange, as it means to develop that embedded PASM code, you are forced into two environments ?!
This thinking underlines the importance of trying to converge PASM and GAS, so that ASM can be more easily moved at the source level.
The support in SimpleIDE for including a .spin file in a C/C++ project just to make use of the embedded PASM code is separate from supporting Spin projects. I think it is the Spin project support that is under consideration for removal.
That still seems strange, as it means to develop that embedded PASM code, you are forced into two environments ?!
This thinking underlines the importance of trying to converge PASM and GAS, so that ASM can be more easily moved at the source level.
I think the idea was to allow PASM code from OBEX to be used without having to first extract it from .spin files. Then the code doesn't have to be maintained in two separate locations. It is possible to write some PASM code and provide both a Spin and a C/C++ wrapper.
I think the idea was to allow PASM code from OBEX to be used without having to first extract it from .spin files. Then the code doesn't have to be maintained in two separate locations.
Yes, that bit makes perfect sense, but that does not include editing or tuning that code.
When Debug arrives, users expect to be able to Step through all of their sources.
I was not totally serious about my suggestion to concatenate all ones source files together.
On the other hand I hate make files, project files and all build systems. I already said what I want included into my program when I wrote the source, with all those #includes. Can't you, stupid compiler, just build the thing for me like Ada, Python or Spin etc does?
I was not totally serious about my suggestion to concatenate all ones source files together.
On the other hand I hate make files, project files and all build systems. I already said what I want included into my program when I wrote the source, with all those #includes. Can't you, stupid compiler, just build the thing for me like Ada, Python or Spin etc does?
Well, you don't actually have to use make or a build system. If you have a directory that contains only source files for your project you can do something like this:
Can someone point me to good methods to port a PASM program I wrote to C in SimpleIDE?
I currently use SimpleIDE as my main educational tool when teaching with the ActivityBoard and Bot.
I have a driver for the Logitech Extreme 3D Pro we were using today. Luckily I found a way to send date through XBEE to the robot, so the stick could be PASM while the bot was C.
However I'd love to be able to make a driver or maybe library thing for the joystick. The main thing is I don't know how to quickly read all the buttons the way I did using PASM years ago.
Not trying to detract from the thread, but I saw this sort of thing was discussed in here.
Also, what is the best solution for programming in Spin on a Raspberry Pi? For now I've just been using C since Prop Tool doesn't work in Linux.
Also, what is the best solution for programming in Spin on a Raspberry Pi? For now I've just been using C since Prop Tool doesn't work in Linux.
I think this deserves another thread, but give PropellerIDE (built from source) a try. Worst comes to worst, you can find a binary distribution of OpenSpin for Raspberry Pi here and then compile from the command line.
I just forked the SimpleIDE project into my repo, got it compiling and running... and notice that the master branch is quite old - 0.7.2. Any idea what branch should be used? qt5?
-Edit-
Dumb question. qt5side is the right branch. Can I recommend you change the GitHub settings for that repo to use qt5side as the deafult branch?
Keith, I can't help with porting PASM but PropellerIDE does build on the Raspberry Pi with a bit of work. There are a couple threads that take you through the steps. Searching for me isn't convenient right now. I'll update this if I get a chance to search later.
PropellerIDE and OpenSpin work great for Spin on the Raspberry Pi.
I just forked the SimpleIDE project into my repo, got it compiling and running... and notice that the master branch is quite old - 0.7.2. Any idea what branch should be used? qt5?
-Edit-
Dumb question. qt5side is the right branch. Can I recommend you change the GitHub settings for that repo to use qt5side as the deafult branch?
$ git clone https://github.com/parallaxinc/OpenSpin.git
$ cd openspin
$ make
You will need a loader to get Propeller binaries into the Propeller. I have one here that will work over the UART on the GPIO header (as well as regular USB adapters). Again you have to build it from it's sources:
I didn't realize that was an option. How do you bind the PASM from a Spin file with C code? (How do you launch it, and access DAT section variables from C?)
Jason,
I've transferred a couple of PASM programs from their SPIN programs into C using SimpleIDE. It is pretty straightforward as long as the Spin program transfers parameters to the PASM using the value in PAR as a reference for all parameters.
The first one I did was to develop an SPI device library using the SpiPAsm spin object in the proptool library. The only wrinkle with that one was that the author did not transfer all parameters referenced to PAR, but had a couple defined in the Spin object. So I had to make a small mod to the PASM. My whole adventure is in this thread (a major part was learning how to do it and make a library):
The second one took a Spin/PASM driver developed by tonyp12 for his 1 pin interface board for the 17 segment LEDs on the prop professional development board. I wanted to be able to use that in C programs so I again made a C library from his object. The only wrinkle with that one was that Tony had the assembler calculate the constants for each character in the font. I had to calculate the values and put them in the PASM. My program is listed in the post at the link below and the one following it.
I just forked the SimpleIDE project into my repo, got it compiling and running... and notice that the master branch is quite old - 0.7.2. Any idea what branch should be used? qt5?
I just forked the SimpleIDE project into my repo, got it compiling and running... and notice that the master branch is quite old - 0.7.2. Any idea what branch should be used? qt5?
-Edit-
Dumb question. qt5side is the right branch. Can I recommend you change the GitHub settings for that repo to use qt5side as the deafult branch?
How do you change the default branch?
1. In the repository's right sidebar, click "Settings".
2. In the left menu, click "Branches".
3. In the default branch sidebar, choose the new default branch.
I just forked the SimpleIDE project into my repo, got it compiling and running... and notice that the master branch is quite old - 0.7.2. Any idea what branch should be used? qt5?
I just forked the SimpleIDE project into my repo, got it compiling and running... and notice that the master branch is quite old - 0.7.2. Any idea what branch should be used? qt5?
-Edit-
Dumb question. qt5side is the right branch. Can I recommend you change the GitHub settings for that repo to use qt5side as the deafult branch?
How do you change the default branch?
1. In the repository's right sidebar, click "Settings".
2. In the left menu, click "Branches".
3. In the default branch sidebar, choose the new default branch.
Looks like Jeff Martin at Parallax will have to do that. I have the ability to commit to the propside repository but not change its settings.
I'm sorry, but I'm now far less interested in making any changes to SimpleIDE. When a single file is over 8,000 lines long with the classes containing hundreds of functions, getting in to make a small change is much more difficult. Individual functions are hundreds of lines long. Source code documentation is... no where? Sparse? A simple search for /** showed 13 matches in the propside/propside directory.
SimpleIDE might be a great program for the end user... but good luck to anyone trying to make changes.
Maybe I'll still poke at it.. idk. This has me very grumpy now
I'm sorry, but I'm now far less interested in making any changes to SimpleIDE. When a single file is over 8,000 lines long with the classes containing hundreds of functions, getting in to make a small change is much more difficult. Individual functions are hundreds of lines long. Source code documentation is... no where? Sparse? A simple search for /** showed 13 matches in the propside/propside directory.
SimpleIDE might be a great program for the end user... but good luck to anyone trying to make changes.
Maybe I'll still poke at it.. idk. This has me very grumpy now
Don't blame me! I just migrated it over from Google Code! :-)
Comments
I seem to recall that when it came to in COG driver code it was OK using make files.
Nowhere near as easy as using Spin and PASM in the Prop Tool or BST.
Ray
If by "most users" you mean simple users, then yes, I'd agree. On the other hand, I have a project where I'd LOVE to use C/C++ for the high level stuff, but better than half the functionality is in PASM because it needs to be really fast.
I tried moving two of my objects over using the "Spin file" method. One works beautifully, the other just hangs. Both work in the original Spin/PASM project. It's frustrating in the extreme, and made worse by the lack of debugging on the Prop.
I'm headed to work now, but I'll post a sample with both later this evening.
J
Combining those posts has left me confused.
If "SimpleIDE makes it easy to integrate existing PASM objects into your C programs as long as you let it build them from .spin files" then why would "any Spin support it has is going to be removed if it has not been already" ?
Other vendors have one IDE (including debug) and DownLoader, for multiple languages.
Some even manage it for multiple MCUs.
The best systems allow you to mix HLL and Assembler and step-debug into either, but getting all those ducks in a row is not trivial, especially around Debug (and Debug is a bridge Parallax is not even approaching yet )
That still seems strange, as it means to develop that embedded PASM code, you are forced into two environments ?!
This thinking underlines the importance of trying to converge PASM and GAS, so that ASM can be more easily moved at the source level.
When Debug arrives, users expect to be able to Step through all of their sources.
I have deleted my propside clone on github.
@Ray,
I was not totally serious about my suggestion to concatenate all ones source files together.
On the other hand I hate make files, project files and all build systems. I already said what I want included into my program when I wrote the source, with all those #includes. Can't you, stupid compiler, just build the thing for me like Ada, Python or Spin etc does?
propeller-elf-gcc -Os -mlmm -o myprog.elf *.c
I currently use SimpleIDE as my main educational tool when teaching with the ActivityBoard and Bot.
I have a driver for the Logitech Extreme 3D Pro we were using today. Luckily I found a way to send date through XBEE to the robot, so the stick could be PASM while the bot was C.
However I'd love to be able to make a driver or maybe library thing for the joystick. The main thing is I don't know how to quickly read all the buttons the way I did using PASM years ago.
Not trying to detract from the thread, but I saw this sort of thing was discussed in here.
Also, what is the best solution for programming in Spin on a Raspberry Pi? For now I've just been using C since Prop Tool doesn't work in Linux.
I think this deserves another thread, but give PropellerIDE (built from source) a try. Worst comes to worst, you can find a binary distribution of OpenSpin for Raspberry Pi here and then compile from the command line.
I just forked the SimpleIDE project into my repo, got it compiling and running... and notice that the master branch is quite old - 0.7.2. Any idea what branch should be used? qt5?
-Edit-
Dumb question. qt5side is the right branch. Can I recommend you change the GitHub settings for that repo to use qt5side as the deafult branch?
PropellerIDE and OpenSpin work great for Spin on the Raspberry Pi.
If you can live on the command line the simplest way to program a Prop from a Pi is to use the OpenSpin Spin compiler.
You will have to build OpenSpin on the Pi from it's source code here: https://github.com/parallaxinc/OpenSpin.git
You will need a loader to get Propeller binaries into the Propeller. I have one here that will work over the UART on the GPIO header (as well as regular USB adapters). Again you have to build it from it's sources:
Now you can edit Spin with vim complete with Spin syntax highlighting thanks to Andrey Demenev. See vim syntax file attached.
Of course you could try building PropellerIDE for the Pi. I have never tried it but:
Should do it on a Pi running Jessie with qtcreator installed.
http://www.vim.org/scripts/script.php?script_id=3019
Jason,
I've transferred a couple of PASM programs from their SPIN programs into C using SimpleIDE. It is pretty straightforward as long as the Spin program transfers parameters to the PASM using the value in PAR as a reference for all parameters.
The first one I did was to develop an SPI device library using the SpiPAsm spin object in the proptool library. The only wrinkle with that one was that the author did not transfer all parameters referenced to PAR, but had a couple defined in the Spin object. So I had to make a small mod to the PASM. My whole adventure is in this thread (a major part was learning how to do it and make a library):
forums.parallax.com/discussion/157441/can-spi-in-simple-libraries-be-speeded-up/p1
The second one took a Spin/PASM driver developed by tonyp12 for his 1 pin interface board for the 17 segment LEDs on the prop professional development board. I wanted to be able to use that in C programs so I again made a C library from his object. The only wrinkle with that one was that Tony had the assembler calculate the constants for each character in the font. I had to calculate the values and put them in the PASM. My program is listed in the post at the link below and the one following it.
forums.parallax.com/discussion/comment/1319703/#Comment_1319703
I'm a beginner, so my programs are not particularly optimized.
hope this helps
Tom
1. In the repository's right sidebar, click "Settings".
2. In the left menu, click "Branches".
3. In the default branch sidebar, choose the new default branch.
Looks like Jeff Martin at Parallax will have to do that. I have the ability to commit to the propside repository but not change its settings.
SimpleIDE might be a great program for the end user... but good luck to anyone trying to make changes.
Maybe I'll still poke at it.. idk. This has me very grumpy now