I suggest surveying the members of this forum to find out what they would like. One way to do this is to provide a list of features, and ask people to select items from the list that they want. I don't know if this forum provides a polling feature that could do this. If not, a list of options could be listed in the initial post of the thread.
It is just as important to find out what non-propeller developers need. A large development team will need tools with more advanced features, such as a debugger and simulator. They will need tools that automate the build process. This information could be gathered from current members who work for existing companies that design and build products. We need to find out what tools these companies are already using, which they will most likely require if they used the Prop. We can also see what kind of tools other chip companies provide. Quite often, the chip selection process consists of comparing the features and tools provided by each vendor.
Good question Leon. I don't know the answer but I do know that all the tools to do this exist now. RossH's summary above is brilliant - and as he says, the costs to parallax for some of those solutions is minimal. Maybe even zero if existing goodwill and code is harnessed.
Ross - re
at least not unless Parallax's primary goal is to compete with the Arduino. But you know what? I think that contest is one that Parallax is very likely to lose!
I won't dwell too much on the Spin equivalent except to point out it is somewhere in the middle of a huge manual and has ~ squiggles in it.
So - here is a challenge - could you run Arduino code 'out of the box' on the Propeller?
Hardware is easy and there are several solutions that look similar. Gadget Gangster has some boards with sockets on them.
Here is the code:
void setup() {
// initialize the digital pin as an output.
// Pin 13 has an LED connected on most Arduino boards:
pinMode(13, OUTPUT);
}
void loop() {
digitalWrite(13, HIGH); // set the LED on
delay(1000); // wait for a second
digitalWrite(13, LOW); // set the LED off
delay(1000); // wait for a second
}
Some tweaks needed. I'm not sure what "HIGH" is - a string, bit, byte, unsigned long. Is Arduino C C89 compatible?
But on the other hand the core of the BCX basic code that does this is this
' ************ main **********
Do
High(0) ' bit 0 high (pin 1 on physical chip)
Sleep(1000) ' sleep this number of milliseconds
Low(0) ' bit 0 low
Sleep(1000) ' sleep
Loop
' ********** end main ********
and we can translate that to C with a keypress to this entire program
#include <catalina_cog.h>
// *************************************************
// Typedef
// *************************************************
typedef unsigned char UCHAR;
typedef unsigned long DWORD;
typedef unsigned long UINT;
// *************************************************
// Standard Macros
// *************************************************
#define BOR |
// *************************************************
// User Prototypes
// *************************************************
void High (int);
void Low (int);
void Sleep (int);
// *************************************************
// User Global Initialized Arrays
// *************************************************
// *************************************************
// Main Program
// *************************************************
int main(int argc, char *argv[])
{
for(;;)
{
High(0);
Sleep(1000);
Low(0);
Sleep(1000);
}
return 0; // End of main program
}
// *************************************************
// Runtime Functions
// *************************************************
// ************************************
// User Subs and Functions
// ************************************
void High (int Pin)
{
UINT Mask;
memset(&Mask,0,sizeof(Mask));
Mask=Mask BOR (1<<Pin);
_dira(Mask,Mask);
_outa(Mask,0xFFFFFFFF);
}
void Low (int Pin)
{
UINT Mask;
memset(&Mask,0,sizeof(Mask));
Mask=Mask BOR (1<<Pin);
_dira(Mask,Mask);
_outa(Mask,0x00000000);
}
void Sleep (int milliseconds)
{
UINT clkcycles;
memset(&clkcycles,0,sizeof(clkcycles));
clkcycles=(_clockfreq()/1000)*milliseconds;
clkcycles-=4296;
if(clkcycles<381)
{
clkcycles=381;
}
_waitcnt(clkcycles+_cnt());
}
where the core code is
// *************************************************
// Main Program
// *************************************************
int main(int argc, char *argv[])
{
for(;;)
{
High(0);
Sleep(1000);
Low(0);
Sleep(1000);
}
return 0; // End of main program
}
and it is entirely possible to create a function "digitalwrite()" to replace "high()"
The Propeller has 32 pins and so I feel it would be entirely possible to get that Arduino program running right out of the box. If you can do that, you can make the Propeller much more attractive to Arduino fans.
And you don't need the Prop II. Though the tools that you would create to do this (a pretty front end IDE and a pile of command line compilers) would be easy to port over to the Prop II and also to maintain backwards compatibility.
RossH said
Catalina + BlackCat + Code::Blocks
and if you like I am sure you can add a little command line program in there that might convert Arduino C to C89 C.
This is all code we can have working very soon if we wish to.
...here is a challenge - could you run Arduino code 'out of the box' on the Propeller
No. Arduino "sketches", as they like to call their programs, are written in C++. They make use of objects in a similar way that we use objects in Spin. For example this is the "hello world" program for Arduino using a serial port for output:
void setup() // run once, when the sketch starts
{
Serial.begin(9600); // set up Serial library at 9600 bps
Serial.println("Hello world!"); // prints hello with ending line break
}
void loop() // run over and over again
{
// do nothing!
}
Now the Arduino comes with a bunch objects like the "Serial" above.
You could run those programs on the Propeller now if you compile for the ZPU architecture with GCC and use Zog virtual machine. All you have to do is provide a library that implements those objects to be called from the "sketches".
Ah, thanks for that heater Well, that makes me think of think of several things:
1) replace serial.begin(9600); with serial_begin(9600); and add this function further down in the code. Easy to replace . with _ to make it work in a C89 way.
2) Think about a C++ command line compiler (which is the real topic of this thread but which I must say is beyond me to comment on)
3) Explore Zog solutions.
Thinking of 3), given we have a "one keypress" compile/download for catalina, I wonder if such a thing could be done for Zog? I'm thinking wildly here about a Zog solution that solves the GCC and Arduino problem at the same time?
You mention "funny object formats". I don't see anything funny about either ELF or COFF. They are very expressive formats that provide the information needed to link and debug large programs. Other than being binary formats I see nothing "funny" about them. What I do find funny is the Parallax object format which has no official definition and whose structure must be reverse engineered by reading dumping the files generated by the Propeller Tool.
Hi David,
Okay - "funny" is probably the wrong word. Substitute "inappropriate". ELF was designed to be the native executable and object format for Unix systems in the days of System V (circa 1980's). So why would you use it on a Windows-based development system intended for an embedded target?
But I do agree with you that Parallax should have defined an object format for the Propeller. And if they were a Unix house, then I would even probably go along with ELF as a logical candidate. But they're not (at least, not as far as I am aware) - and the days when most embedded work was done on Unix systems are long gone (they probably disappeared around the same time as System V).
Dr_A: What's the setup requirement for your tool set. A person has propeller, USB cable, Demo Board. What needs to happen?
Productivity, Yes. I liked that post from Jazzed very much, because it gets to the meat of things. That absolutely is the core requirement.
I've gone the distance with gcc and friends on various platforms, and there generally is setup. Once the setup is done, things move well from there, at least that's been my experience on IRIX & Linux. Windows took some dealing. Haven't gone down that road on Mac OS yet.
I love the Prop tool and BST, simply because they do present a clear, dead simple, consistent means of interaction. Setup is minimal. For the "non pro", retaining that is very, very important. The pro will do, what I commonly refer to as 'boot strapping", needed to get enabling technology up and running, because they know how to take it from there, and they've done it all before too. I'm sure that is what is meant by "software engineers know how to do things".
One thing that comes to mind then, is LEAN. Whatever happens, I think it should be as LEAN as possible, without overly constraining people. I also think it should not be the only option. If there is Parallax and Parallax Semiconductor, then there should be a Parallax like option, and "the pro" option, where they both are lean and clear and productive, but not necessarily easy, in the case of the Pro option.
Parallax wants a C compiler (gcc) and Eclipse, which is what many of their competitors uses, not a C++ command line compiler.
There! You see how easy it is to get this completely wrong? Here is what Ken actually said in the first post in this thread:
The objective is create an open-source cross-platform compatible compiler suite for Propeller 2 (code name) supporting Spin, C/C++ and possibly other languages. A GUI such as Eclipse would be customized to make use of the GCC optimizer.
I think we've already identified that this is unlikely to be completely achieved (most notably the Spin part).
And this is what Ken said in a later post in this thread:
What we're interested in considering is a cross-platform set of tools with the possibility of supporting different languages. Whether or not GCC/GNU with Eclipse is practical we are not sure at this point - our starting point is a simple discussion among the interested folks who may contribute, develop or even review.
Now everyone is trying to second guess what Parallax really wants. And what their reasons are. (Because their competitors use it? Which competitors?. Do they want Eclipse? No - that was just a suggestion! Do they even want GCC? Well ... not sure anymore!).
Okay - "funny" is probably the wrong word. Substitute "inappropriate". ELF was designed to be the native executable and object format for Unix systems in the days of System V (circa 1980's). So why would you use it on a Windows-based development system intended for an embedded target?
But I do agree with you that Parallax should have defined an object format for the Propeller. And if they were a Unix house, then I would even probably go along with ELF as a logical candidate. But they're not (at least, not as far as I am aware) - and the days when most embedded work was done on Unix systems are long gone (they probably disappeared around the same time as System V).
Ross.
While it may be true that ELF originated with Unix I don't see how that is relevant. The C language originated with Unix as well and you're not using that as an argument to not use it on microcontrollers. ELF is simply a file format that allows a lot of information about a program to be encoded relatively efficiently. It isn't all that hard to parse and it is also unnecessary to write code to parse it since that code already exists as part of binutils.
While it may be true that ELF originated with Unix I don't see how that is relevant. The C language originated with Unix as well and you're not using that as an argument to not use it on microcontrollers. ELF is simply a file format that allows a lot of information about a program to be encoded relatively efficiently. It isn't all that hard to parse and it is also unnecessary to write code to parse it since that code already exists as part of binutils.
Fair point about C - although C has evolved to be platform-agnostic, whereas ELF is still Unix. But I agree ELF would be fine to use even on other platforms - provided those platforms have a program loader that knows how to load ELF. But is that likely to be the case on the Propeller? I don't think so - so the ELF binaries will have to be converted to something else to be loaded. Also, to go back to a point I have made previously - binutils exists because of ELF, not the other way 'round!
Dr_A: What's the setup requirement for your tool set. A person has propeller, USB cable, Demo Board. What needs to happen?
You would need to then download and install Catalina, and download and install the IDE. And if anything doesn't work, post a question on the Catalina thread and it almost always will be answered within 24h, and often by Ross within 10 mins. (Ross, do you ever sleep??).
It isn't even close to being the right solution though. Take Ken's quote
What we're interested in considering is a cross-platform set of tools with the possibility of supporting different languages.
Well, fail there on the IDE because it is not cross platform, only Windows. That is solvable though - use the existing proptool and add more menus and the ability to shell out to command line programs. Or use BST. Or GCC...
I'm at the point Ross is at
Now everyone is trying to second guess what Parallax really wants.
Fair point about C - although C has evolved to be platform-agnostic, whereas ELF is still Unix. But I agree ELF would be fine to use even on other platforms - provided those platforms have a program loader that knows how to load ELF. But is that likely to be the case on the Propeller? I don't think so - so the ELF binaries will have to be converted to something else to be loaded. Also, to go back to a point I have made previously - binutils exists because of ELF, not the other way 'round!
Ross.
I'm not sure that binutils exists because of ELF although I may be wrong. I'm pretty sure binutils pre-dates ELF and was also used to work with earlier COFF object files. Also, you keep saying that ELF is designed for Unix systems. Can you give me an example of some feature of ELF that only makes sense on Unix? It seems like a pretty generic format to me.
XMOS uses Eclipse and their XC, C and C++ compilers are based on gcc.
Many ARM toolsets are based on gcc and Eclipse - Atollic and Code Red come to mind for ST and NXP, and Rowley uses gcc for the ARM with their own IDE.
Microchip uses gcc for their 16-bit dsPIC and PIC24 compilers, and the 32-bit PIC32 compiler, with the CodeBeans IDE, for their new MPLAB-X.
Atmel uses gcc for their 8-bit and 32-bit AVR compilers, with MS Visual Studio as the new IDE.
There are other non-gcc tools for ARM and AVR, from Keil and IAR.
C++ is available with some of the above, but it's very rarely used by anyone.
Eclipse is cross-platform, which is an advantage. Most professional users should be familiar with it, but it isn't the most user-friendly of IDEs.
As you can see, gcc and Eclipse are used by Parallax's competitors. There are probably more.
My favourite IDE is Rowley Associates CrossStudio, They wrote it themselves using QT and it runs on Windows, MAC OS and Linux. It's used with all their compilers.
A statement from Parallax is needed, before any more time and bandwidth are wasted.
One thing the "bothers" me, and maybe I've missed something, but it seems like all this still seems to revolve around building a tool to develop single "programs", maybe rather large ones, that run on the prop as if it was a PC so to speak. Shouldn't the programming tool, whatever it ends up being, allow for things such as the following:
- Each COG doing it's own thing, in the most simple case each one running C compiled to PASM, in a much more complex case each running C compiled to XMM using a shared XMM store, and anything in between.
- One or more COG's running PASM, LMM, XMM compiled from C using other COG's as peripherals via shared memory.
- One or more COG's in the above cases running PASM, LMM, or XMM imported as a binary into the new tool, could have been created using some other tool.
I'm sure there are other possible combinations, those are just a few that came to mind.
Seems like a lot of discussion of saws and hammers when we don't even know what we want to build.
Parallax is after something that runs on a PC, and other platforms, not software resident on the Propeller, although that might also be feasible with the new chip.
Seems like a lot of discussion of saws and hammers when we don't even know what we want to build.
That is why I suggested polling the forum membership to find out what features they would like to see. It seems that the major players in this effort have a pre-conceived notion about what they want to build. However, the larger population of developers may have a completely different idea.
Parallax is after something that runs on a PC, and other platforms, not software resident on the Propeller, although that might also be feasible with the new chip.
Leon, I was referring to the end user applications not the development tool, I'll edit the post to clarify.
...and the days when most embedded work was done on Unix systems are long gone
What? Since 1998 I have used nothing but Linux to develop embedded code on. That's "a unix" system is it not?. Almost never see anything else around here.
According to Ken's first post, developers who expressed an interest were to be invited to a meeting with Chip a week later, to discuss the various options, and a small team would be put together. Has that happened?
This meeting happened May 17th. One team has already been identified, but the project has not started. Ken has already expressed that the internal team has to make decisions. We are waiting for that.
It's not existing users that matter for this exercise, they are mainly hobbyists. Parallax needs tools that will be acceptable to professional users.
In my earlier post, I suggested that the survey should be filled out by the forum membership based on their personal preferences, and it should be filled out based on the practices of the company they work at. So each person should fill out the survey twice. The survey should have two columns -- one for personal preferences and one for professional company preferences. I suspect that the answers would be quite different The following is a list of features with my personal preferences and my understanding of my company's professional preferences.
Please indicate your desire for features in the Prop 2 development tools by assigning a value between 1 to 10 for each item. A value of 10 indicates that you strongly want this feature, and a value of 1 indicates that you do not need this feature and would not use it. The first column is your personal score and the second column would be the score you believe you company would use.
1/5 - C++ language support
10/10 - C language support
10/1 - Spin language support
5/1 - PBASIC language support
10/10 - PASM language support
10/10 - C compiler generates PASM
10/10 - C compiler generates LMM PASM
8/8 - C compiler generates XMM PASM (executes from external memory)
8/1 - C compiler generates spin bytecodes
6/1 - Spin code can execute from external memory
3/8 - Compiler and tools must be based on GCC
8/10 - Simulator
3/10 - Debugger
5/10 - Graphical interface to all features
10/10 - Command line interface to all features
10/10 - Runs under Windows
10/10 - Runs under Linux
1/3 - Runs on a Mac
1/5 - Text editor must have lots of features, such as auto-completion and syntax support
5/10 - Compiler tool-chain, and make process must be similar to GCC
jazzed, I added your suggestion to my previous post. If anybody else has additional suggestions, please post them here. Also, it would be good to get survey results from as many people as possible. This way we could compile the results and get a better idea of what hobbyist and professional developers actually want.
EDIT: Steve, did you edit your post? I could swear that it was slightly different the first time I read it. Please don't leave. I'm just trying to find out what people want. I agree that a large portion of the target audience is professional developers. Many of the people on this forum are professional developers, but we use the Prop for hobby. However, I think professional developers could fill out the survey for both personal use and professional use. Anybody that feels they can only fill out one column should leave the other column blank or put a dash. That is, use a score like 8/- if you're only answering as a hobbiest, or -/7 if you are only answering as a professional user.
Why so much talk on internal functions in that "C - GCC" compiler.
For me and end user only thing that are important is ---->
How Code is written/Formated and END product that LOADS to Propeller.
Way how it is compiled --- I don't think are so interesting for USER. If it is not Meaning that that END product will be used to Build LIBRARY of executable code that are linked to END-RUN product and are only available for USER as that one -- NOT as Program code.
I'm not sure that binutils exists because of ELF although I may be wrong. I'm pretty sure binutils pre-dates ELF and was also used to work with earlier COFF object files. Also, you keep saying that ELF is designed for Unix systems. Can you give me an example of some feature of ELF that only makes sense on Unix? It seems like a pretty generic format to me.
jazzed, I added your suggestion to my previous post. If anybody else has additional suggestions, please post them here. Also, it would be good to get survey results from as many people as possible. This way we could compile the results and get a better idea of what hobbyist and professional developers actually want.
EDIT: Steve, did you edit your post? I could swear that it was slightly different the first time I read it. Please don't leave. I'm just trying to find out what people want. I agree that a large portion of the target audience is professional developers. Many of the people on this forum are professional developers, but we use the Prop for hobby. However, I think professional developers could fill out the survey for both personal use and professional use. Anybody that feels they can only fill out one column should leave the other column blank or put a dash. That is, use a score like 8/- if you're only answering as a hobbiest, or -/7 if you are only answering as a professional user.
Why so much talk on internal functions in that "C - GCC" compiler.
For me and end user only thing that are important is ---->
How Code is written/Formated and END product that LOADS to Propeller.
Way how it is compiled --- I don't think are so interesting for USER. If it is not Meaning that that END product will be used to Build LIBRARY of executable code that are linked to END-RUN product and are only available for USER as that one -- NOT as Program code.
This is certainly true but the ELF object file format keeps getting brought up as a negative feature of using the GCC toolchain so I keep trying to point out that it isn't. You are right that we don't really care much what happens internally as long as the end result is an efficient working compiler toolchain.
EDIT: Steve, did you edit your post? I could swear that it was slightly different the first time I read it. Please don't leave. I'm just trying to find out what people want. I agree that a large portion of the target audience is professional developers. Many of the people on this forum are professional developers, but we use the Prop for hobby. However, I think professional developers could fill out the survey for both personal use and professional use. Anybody that feels they can only fill out one column should leave the other column blank or put a dash. That is, use a score like 8/- if you're only answering as a hobbiest, or -/7 if you are only answering as a professional user.
Ok, one more before I take a break. Yes, it was edited slightly. You got the gist of it just fine.
I like your survey methodology a lot. I really do, and it will be good if others answer.
So, here's my vote:
5/10 - C++ language support
10/10 - C language support
10/1 - Spin language support
1/1 - PBASIC language support
10/10 - PASM language support
5/10 - C compiler generates PASM
10/10 - C compiler generates LMM PASM
10/8 - C compiler generates XMM PASM (executes from external memory)
5/5 - C compiler generates spin bytecodes
8/1 - Spin code can execute from external memory
10/10 - Compiler and tools must be based on GCC
8/10 - Simulator
8/10 - Debugger
5/10 - Graphical interface to all features
10/10 - Command line interface to all features
10/10 - Runs under Windows
10/10 - Runs under Linux
1/8 - Runs on a Mac
5/8 - Text editor must have lots of features, such as auto-completion and syntax support
10/10 - Compiler tool-chain, and make process must be similar to GCC
I'm just tired of the subject for the time being and have other things to do that are more rewarding.
My suggestion. GOOD IDE that have possibility to add as many Compilers/Languages as possible that can be developed in time Propeller II live.
That said.
IDE.
SPIN / PASM.
BASIC of any type
"C - GCC" else other type of "C" that can be accepted.
AND that all of them can be RUN from single IDE.
Sapieha, thanks for your input. However, that's going to be hard to add to a spreadsheet. Would you mind copying the survey items from my earlier post and assigning your own scores between 1 and 10? You only need to put one set of scores if you want to answer only as a hobbyist, or only as a professional developer.
First of all - IDE that can run all of above You mentioned!.
10/10 - PASM language support
10/10 - PASM language support that can generate LMM/XMM code
10/10 - Spin language support
10/10 - IDE->Graphical interface to all features
10/10 - Command line interface to all features
10/10 - Runs under Windows
10/10 - Runs under Linux
10/10 - Runs on a Mac
10/10 - Text editor (IDE) must have lots of features, such as auto-completion and syntax support (Like Propeller Tool's have now) -- NOT Forget Compilation to multiple targets from ONE opened IDE!
NOW You can add all "C" options
1/5 - C++ language support
10/10 - C language support
10/1 - Spin language support
5/1 - PBASIC language support
10/10 - PASM language support
10/10 - C compiler generates PASM
10/10 - C compiler generates LMM PASM
8/8 - C compiler generates XMM PASM (executes from external memory)
8/1 - C compiler generates spin bytecodes
6/1 - Spin code can execute from external memory
3/8 - Compiler and tools must be based on GCC
8/10 - Simulator
3/10 - Debugger
5/10 - Graphical interface to all features
10/10 - Command line interface to all features
10/10 - Runs under Windows
10/10 - Runs under Linux
1/3 - Runs on a Mac
1/5 - Text editor must have lots of features, such as auto-completion and syntax support
Comments
It is just as important to find out what non-propeller developers need. A large development team will need tools with more advanced features, such as a debugger and simulator. They will need tools that automate the build process. This information could be gathered from current members who work for existing companies that design and build products. We need to find out what tools these companies are already using, which they will most likely require if they used the Prop. We can also see what kind of tools other chip companies provide. Quite often, the chip selection process consists of comparing the features and tools provided by each vendor.
Ross - re
What a challenge. Ok, here we have the arduino blinkenlichten demo http://arduino.cc/en/Tutorial/Blink
I won't dwell too much on the Spin equivalent except to point out it is somewhere in the middle of a huge manual and has ~ squiggles in it.
So - here is a challenge - could you run Arduino code 'out of the box' on the Propeller?
Hardware is easy and there are several solutions that look similar. Gadget Gangster has some boards with sockets on them.
Here is the code:
void setup() { // initialize the digital pin as an output. // Pin 13 has an LED connected on most Arduino boards: pinMode(13, OUTPUT); } void loop() { digitalWrite(13, HIGH); // set the LED on delay(1000); // wait for a second digitalWrite(13, LOW); // set the LED off delay(1000); // wait for a second }Some tweaks needed. I'm not sure what "HIGH" is - a string, bit, byte, unsigned long. Is Arduino C C89 compatible?
But on the other hand the core of the BCX basic code that does this is this
and we can translate that to C with a keypress to this entire program
#include <catalina_cog.h> // ************************************************* // Typedef // ************************************************* typedef unsigned char UCHAR; typedef unsigned long DWORD; typedef unsigned long UINT; // ************************************************* // Standard Macros // ************************************************* #define BOR | // ************************************************* // User Prototypes // ************************************************* void High (int); void Low (int); void Sleep (int); // ************************************************* // User Global Initialized Arrays // ************************************************* // ************************************************* // Main Program // ************************************************* int main(int argc, char *argv[]) { for(;;) { High(0); Sleep(1000); Low(0); Sleep(1000); } return 0; // End of main program } // ************************************************* // Runtime Functions // ************************************************* // ************************************ // User Subs and Functions // ************************************ void High (int Pin) { UINT Mask; memset(&Mask,0,sizeof(Mask)); Mask=Mask BOR (1<<Pin); _dira(Mask,Mask); _outa(Mask,0xFFFFFFFF); } void Low (int Pin) { UINT Mask; memset(&Mask,0,sizeof(Mask)); Mask=Mask BOR (1<<Pin); _dira(Mask,Mask); _outa(Mask,0x00000000); } void Sleep (int milliseconds) { UINT clkcycles; memset(&clkcycles,0,sizeof(clkcycles)); clkcycles=(_clockfreq()/1000)*milliseconds; clkcycles-=4296; if(clkcycles<381) { clkcycles=381; } _waitcnt(clkcycles+_cnt()); }where the core code is
// ************************************************* // Main Program // ************************************************* int main(int argc, char *argv[]) { for(;;) { High(0); Sleep(1000); Low(0); Sleep(1000); } return 0; // End of main program }and it is entirely possible to create a function "digitalwrite()" to replace "high()"
The Propeller has 32 pins and so I feel it would be entirely possible to get that Arduino program running right out of the box. If you can do that, you can make the Propeller much more attractive to Arduino fans.
And you don't need the Prop II. Though the tools that you would create to do this (a pretty front end IDE and a pile of command line compilers) would be easy to port over to the Prop II and also to maintain backwards compatibility.
RossH said
and if you like I am sure you can add a little command line program in there that might convert Arduino C to C89 C.
This is all code we can have working very soon if we wish to.
No. Arduino "sketches", as they like to call their programs, are written in C++. They make use of objects in a similar way that we use objects in Spin. For example this is the "hello world" program for Arduino using a serial port for output:
void setup() // run once, when the sketch starts { Serial.begin(9600); // set up Serial library at 9600 bps Serial.println("Hello world!"); // prints hello with ending line break } void loop() // run over and over again { // do nothing! }Now the Arduino comes with a bunch objects like the "Serial" above.You could run those programs on the Propeller now if you compile for the ZPU architecture with GCC and use Zog virtual machine. All you have to do is provide a library that implements those objects to be called from the "sketches".
1) replace serial.begin(9600); with serial_begin(9600); and add this function further down in the code. Easy to replace . with _ to make it work in a C89 way.
2) Think about a C++ command line compiler (which is the real topic of this thread but which I must say is beyond me to comment on)
3) Explore Zog solutions.
Thinking of 3), given we have a "one keypress" compile/download for catalina, I wonder if such a thing could be done for Zog? I'm thinking wildly here about a Zog solution that solves the GCC and Arduino problem at the same time?
Hi David,
Okay - "funny" is probably the wrong word. Substitute "inappropriate". ELF was designed to be the native executable and object format for Unix systems in the days of System V (circa 1980's). So why would you use it on a Windows-based development system intended for an embedded target?
But I do agree with you that Parallax should have defined an object format for the Propeller. And if they were a Unix house, then I would even probably go along with ELF as a logical candidate. But they're not (at least, not as far as I am aware) - and the days when most embedded work was done on Unix systems are long gone (they probably disappeared around the same time as System V).
Ross.
Productivity, Yes. I liked that post from Jazzed very much, because it gets to the meat of things. That absolutely is the core requirement.
I've gone the distance with gcc and friends on various platforms, and there generally is setup. Once the setup is done, things move well from there, at least that's been my experience on IRIX & Linux. Windows took some dealing. Haven't gone down that road on Mac OS yet.
I love the Prop tool and BST, simply because they do present a clear, dead simple, consistent means of interaction. Setup is minimal. For the "non pro", retaining that is very, very important. The pro will do, what I commonly refer to as 'boot strapping", needed to get enabling technology up and running, because they know how to take it from there, and they've done it all before too. I'm sure that is what is meant by "software engineers know how to do things".
One thing that comes to mind then, is LEAN. Whatever happens, I think it should be as LEAN as possible, without overly constraining people. I also think it should not be the only option. If there is Parallax and Parallax Semiconductor, then there should be a Parallax like option, and "the pro" option, where they both are lean and clear and productive, but not necessarily easy, in the case of the Pro option.
There! You see how easy it is to get this completely wrong? Here is what Ken actually said in the first post in this thread:
And this is what Ken said in a later post in this thread:
Ross.
While it may be true that ELF originated with Unix I don't see how that is relevant. The C language originated with Unix as well and you're not using that as an argument to not use it on microcontrollers. ELF is simply a file format that allows a lot of information about a program to be encoded relatively efficiently. It isn't all that hard to parse and it is also unnecessary to write code to parse it since that code already exists as part of binutils.
Fair point about C - although C has evolved to be platform-agnostic, whereas ELF is still Unix. But I agree ELF would be fine to use even on other platforms - provided those platforms have a program loader that knows how to load ELF. But is that likely to be the case on the Propeller? I don't think so - so the ELF binaries will have to be converted to something else to be loaded. Also, to go back to a point I have made previously - binutils exists because of ELF, not the other way 'round!
Ross.
You would need to then download and install Catalina, and download and install the IDE. And if anything doesn't work, post a question on the Catalina thread and it almost always will be answered within 24h, and often by Ross within 10 mins. (Ross, do you ever sleep??).
It isn't even close to being the right solution though. Take Ken's quote
Well, fail there on the IDE because it is not cross platform, only Windows. That is solvable though - use the existing proptool and add more menus and the ability to shell out to command line programs. Or use BST. Or GCC...
I'm at the point Ross is at
I'm not sure that binutils exists because of ELF although I may be wrong. I'm pretty sure binutils pre-dates ELF and was also used to work with earlier COFF object files. Also, you keep saying that ELF is designed for Unix systems. Can you give me an example of some feature of ELF that only makes sense on Unix? It seems like a pretty generic format to me.
XMOS uses Eclipse and their XC, C and C++ compilers are based on gcc.
Many ARM toolsets are based on gcc and Eclipse - Atollic and Code Red come to mind for ST and NXP, and Rowley uses gcc for the ARM with their own IDE.
Microchip uses gcc for their 16-bit dsPIC and PIC24 compilers, and the 32-bit PIC32 compiler, with the CodeBeans IDE, for their new MPLAB-X.
Atmel uses gcc for their 8-bit and 32-bit AVR compilers, with MS Visual Studio as the new IDE.
There are other non-gcc tools for ARM and AVR, from Keil and IAR.
C++ is available with some of the above, but it's very rarely used by anyone.
Eclipse is cross-platform, which is an advantage. Most professional users should be familiar with it, but it isn't the most user-friendly of IDEs.
As you can see, gcc and Eclipse are used by Parallax's competitors. There are probably more.
My favourite IDE is Rowley Associates CrossStudio, They wrote it themselves using QT and it runs on Windows, MAC OS and Linux. It's used with all their compilers.
A statement from Parallax is needed, before any more time and bandwidth are wasted.
- Each COG doing it's own thing, in the most simple case each one running C compiled to PASM, in a much more complex case each running C compiled to XMM using a shared XMM store, and anything in between.
- One or more COG's running PASM, LMM, XMM compiled from C using other COG's as peripherals via shared memory.
- One or more COG's in the above cases running PASM, LMM, or XMM imported as a binary into the new tool, could have been created using some other tool.
I'm sure there are other possible combinations, those are just a few that came to mind.
Seems like a lot of discussion of saws and hammers when we don't even know what we want to build.
C.W.
Leon, I was referring to the end user applications not the development tool, I'll edit the post to clarify.
C.W.
It's not existing users that matter for this exercise, they are mainly hobbyists. Parallax needs tools that will be acceptable to professional users.
What? Since 1998 I have used nothing but Linux to develop embedded code on. That's "a unix" system is it not?. Almost never see anything else around here.
I'm taking a break from this thread for a while.
Please indicate your desire for features in the Prop 2 development tools by assigning a value between 1 to 10 for each item. A value of 10 indicates that you strongly want this feature, and a value of 1 indicates that you do not need this feature and would not use it. The first column is your personal score and the second column would be the score you believe you company would use.
1/5 - C++ language support
10/10 - C language support
10/1 - Spin language support
5/1 - PBASIC language support
10/10 - PASM language support
10/10 - C compiler generates PASM
10/10 - C compiler generates LMM PASM
8/8 - C compiler generates XMM PASM (executes from external memory)
8/1 - C compiler generates spin bytecodes
6/1 - Spin code can execute from external memory
3/8 - Compiler and tools must be based on GCC
8/10 - Simulator
3/10 - Debugger
5/10 - Graphical interface to all features
10/10 - Command line interface to all features
10/10 - Runs under Windows
10/10 - Runs under Linux
1/3 - Runs on a Mac
1/5 - Text editor must have lots of features, such as auto-completion and syntax support
5/10 - Compiler tool-chain, and make process must be similar to GCC
However, I agree with Leon that the target audience is not necessarily represented by these forums.
Leon, nothing will be resolved until requirements are written and feasibility studies are completed.
Have fun. I'll check back in a week or so.
EDIT: Steve, did you edit your post? I could swear that it was slightly different the first time I read it. Please don't leave. I'm just trying to find out what people want. I agree that a large portion of the target audience is professional developers. Many of the people on this forum are professional developers, but we use the Prop for hobby. However, I think professional developers could fill out the survey for both personal use and professional use. Anybody that feels they can only fill out one column should leave the other column blank or put a dash. That is, use a score like 8/- if you're only answering as a hobbiest, or -/7 if you are only answering as a professional user.
Why so much talk on internal functions in that "C - GCC" compiler.
For me and end user only thing that are important is ---->
How Code is written/Formated and END product that LOADS to Propeller.
Way how it is compiled --- I don't think are so interesting for USER. If it is not Meaning that that END product will be used to Build LIBRARY of executable code that are linked to END-RUN product and are only available for USER as that one -- NOT as Program code.
My suggestion. GOOD IDE that have possibility to add as many Compilers/Languages as possible that can be developed in time Propeller II live.
That said.
IDE.
SPIN / PASM.
BASIC of any type
"C - GCC" else other type of "C" that can be accepted.
AND that all of them can be RUN from single IDE.
This is certainly true but the ELF object file format keeps getting brought up as a negative feature of using the GCC toolchain so I keep trying to point out that it isn't. You are right that we don't really care much what happens internally as long as the end result is an efficient working compiler toolchain.
Ok, one more before I take a break. Yes, it was edited slightly. You got the gist of it just fine.
I like your survey methodology a lot. I really do, and it will be good if others answer.
So, here's my vote:
5/10 - C++ language support
10/10 - C language support
10/1 - Spin language support
1/1 - PBASIC language support
10/10 - PASM language support
5/10 - C compiler generates PASM
10/10 - C compiler generates LMM PASM
10/8 - C compiler generates XMM PASM (executes from external memory)
5/5 - C compiler generates spin bytecodes
8/1 - Spin code can execute from external memory
10/10 - Compiler and tools must be based on GCC
8/10 - Simulator
8/10 - Debugger
5/10 - Graphical interface to all features
10/10 - Command line interface to all features
10/10 - Runs under Windows
10/10 - Runs under Linux
1/8 - Runs on a Mac
5/8 - Text editor must have lots of features, such as auto-completion and syntax support
10/10 - Compiler tool-chain, and make process must be similar to GCC
I'm just tired of the subject for the time being and have other things to do that are more rewarding.
First of all - IDE that can run all of above You mentioned!.
10/10 - PASM language support
10/10 - PASM language support that can generate LMM/XMM code
10/10 - Spin language support
10/10 - IDE->Graphical interface to all features
10/10 - Command line interface to all features
10/10 - Runs under Windows
10/10 - Runs under Linux
10/10 - Runs on a Mac
10/10 - Text editor (IDE) must have lots of features, such as auto-completion and syntax support (Like Propeller Tool's have now) -- NOT Forget Compilation to multiple targets from ONE opened IDE!
NOW You can add all "C" options