Today, on the Raspberry Pi website, the blog I guess, they are making available the "Essentials of C". It has a .pdf download of that available. I tried to attach a zip file of that here, but I guess the file is to big.
I took a very quick skim through the pdf version, and I think that the source is very good for beginners. I know that I have seen a lot of beginners here, wanting to use SimpleIDE, asking for, or looking for the programming guide to C. This pdf could be a very good introductory start, and a good added resource for what the Learn site has to offer.
The way I will probably use it is , on the Windows desktop I would open up the pdf file, and I would also connect up to the Raspberry Pi via the terminal window, and then use NANO to actually write and run the example programs.
Yes, the source covers the dreaded Pointers - "*", and "&". I think it does a very good job with that, using the examples that are relatively easy to understand. It would be kind of interesting to see, using SimpleIDE and the Propeller, where the memory is located when you use those commands.
This is just a heads up for possibly making SimpleIDE easier to use.
There's an error already in the first example.. It's not often you see 'hello world' incorrectly implemented.
(in ANSI C 'main' shall always return an int, but they declared it as 'void main'. This actually matters on some hardware architectures, even if not on the Pi).
They're continuing the wrong notation in the explanation on the next page. Strange that.
The next examples are fine (except for always using 'void main', why on earth?),
until we come to the section about functions, page 39.
Declaring a local function without 'static' demands a prototype (besides being pointlessly globally visible), and there isn't one, so you'll get a compiler warning when compiling with -Wall.
The chapter on strings is pretty good, with graphical illustrations of null-terminated strings. The follow-up chapter about string functions is also good.
But I don't like that, as so many others, they immediately go to 'sscanf' for something as simple as reading a number from a string. I think I mentioned in another post that, despite programming for a living in C every day, for decades, I have *never* needed sscanf (or variants). Not once.
I also think they should at least have mentioned the problems with strcpy() and strcat() (overwriting too short destination strings). No need to elaborate, that could have been left as an interesting exercise. But nothing.
Finally, on page 59, they admit that 'main' shall actually return 'int'. So why did they spend 58 pages teaching otherwise? If they believe that it makes it easier for the reader, they're mistaken.
Chapter ten, file input and output, sticks to the old fopen/fwrite/fread functions. Well, they are still somewhat useful sometimes, but the historical reason for these functions was mainly to provide buffered input (and output). So the C runtime library keeps a small buffer for this. Nowadays the operating system read() and write() functions are buffered in the kernel, and are more efficient than the fread() fwrite() variants. And if you have two or more programs communicating via files, they'll be out of sync if the 'f' functions are used. They will not be out of sync with read/write, even when data has not yet touched the disk. But read/write aren't even mentioned. Using fread/fwrite is more out of inertia these days, it's almost like seeing somebody casting the return value of malloc(). Made sense back in the K&R days, not now.
The preprocessor chapter is ok.
Chapter 13, page 81, is a quick reference, starting with control structures. It's good, and useful. Unfortunately the 'variable types' page is not as good as I would like. It harks back to DOS days, in a way. 'int can be either a short int (16 bits) or a long int (32 bits);' -- er, no, it's not exactly like that. Not really.
The pages about operators is good. Great reference. Although I don't think I saw explained anywhere what 'Bitwise 1's complement' actually means, something a new C coder may not know.
All in all the book makes C look easy, and seems to be a good starting point for new C coders. But I wish they had avoided the unnecessary inaccuracies and omissions. And I really wish they had written something about 'static', it's not that easy to understand for a beginner, but it's important to understand early on what it means, and why there are two quite different meanings of the keyword, depending on where it's used.
There's an error already in the first example.. It's not often you see 'hello world' incorrectly implemented.
(in ANSI C 'main' shall always return an int, but they declared it as 'void main'. This actually matters on some hardware architectures, even if not on the Pi).
They're continuing the wrong notation in the explanation on the next page. Strange that.
The next examples are fine (except for always using 'void main', why on earth?),
until we come to the section about functions, page 39.
Declaring a local function without 'static' demands a prototype (besides being pointlessly globally visible), and there isn't one, so you'll get a compiler warning when compiling with -Wall.
The chapter on strings is pretty good, with graphical illustrations of null-terminated strings. The follow-up chapter about string functions is also good.
But I don't like that, as so many others, they immediately go to 'sscanf' for something as simple as reading a number from a string. I think I mentioned in another post that, despite programming for a living in C every day, for decades, I have *never* needed sscanf (or variants). Not once.
I also think they should at least have mentioned the problems with strcpy() and strcat() (overwriting too short destination strings). No need to elaborate, that could have been left as an interesting exercise. But nothing.
Finally, on page 59, they admit that 'main' shall actually return 'int'. So why did they spend 58 pages teaching otherwise? If they believe that it makes it easier for the reader, they're mistaken.
Chapter ten, file input and output, sticks to the old fopen/fwrite/fread functions. Well, they are still somewhat useful sometimes, but the historical reason for these functions was mainly to provide buffered input (and output). So the C runtime library keeps a small buffer for this. Nowadays the operating system read() and write() functions are buffered in the kernel, and are more efficient than the fread() fwrite() variants. And if you have two or more programs communicating via files, they'll be out of sync if the 'f' functions are used. They will not be out of sync with read/write, even when data has not yet touched the disk. But read/write aren't even mentioned. Using fread/fwrite is more out of inertia these days, it's almost like seeing somebody casting the return value of malloc(). Made sense back in the K&R days, not now.
The preprocessor chapter is ok.
Chapter 13, page 81, is a quick reference, starting with control structures. It's good, and useful. Unfortunately the 'variable types' page is not as good as I would like. It harks back to DOS days, in a way. 'int can be either a short int (16 bits) or a long int (32 bits);' -- er, no, it's not exactly like that. Not really.
The pages about operators is good. Great reference. Although I don't think I saw explained anywhere what 'Bitwise 1's complement' actually means, something a new C coder may not know.
All in all the book makes C look easy, and seems to be a good starting point for new C coders. But I wish they had avoided the unnecessary inaccuracies and omissions. And I really wish they had written something about 'static', it's not that easy to understand for a beginner, but it's important to understand early on what it means, and why there are two quite different meanings of the keyword, depending on where it's used.
Thanks for your review, Tor. Many nice insights there, most of which I did not know. And most importantly, thank you for providing the reasoning behind your objections.
To be fair gcc will compile a void main without any complaint. Unless one compiles with -Wall. But then again I think use of -Wall is the first thing one should learn about compiling C programs.
An int will be 16 bits on Arduino and other 8 bit machines. So perhaps it's good to point out, for those coming from Arduino, that the size of int is not defined in the language. It's implementation dependent. But then again I don't think one should ever use int. Given that it is undefined it better use int32_t etc
There are so many unsafe standard library functions, strcpy etc, that I don't think they should ever even be mentioned to beginners! That includes all the no thread safe functions http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0492c/Chddjdaj.html Perhhaps not an issue for beginners on the Raspi but for sure can cause problems on the multi-core Propeller.
There are so many unsafe standard library functions, strcpy etc, that I don't think they should ever even be mentioned to beginners! That includes all the no thread safe functions http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0492c/Chddjdaj.html Perhhaps not an issue for beginners on the Raspi but for sure can cause problems on the multi-core Propeller.
To be fair, none of those functions are particularly common in the beginner world, with the exception of exit() which isn't going to be used on a microcontroller anyway. But thanks for sharing, as this is yet another example of something I didn't already know
Well, that exit() issue described in that ARM document is definitely not standard. Never seen that before. There's no _sys_exit() to call on a desktop Linux system, and not on Raspbian for Raspberry Pi either. Exit'ing from a C program on any *nix / posix pthread-based program will do what you would expect. So I wouldn't worry about it.
I think that little book covers what's necessary for a beginner, with just a few adjustments it would have been perfect.
I didn't understand the exit() thing either. That called for a litlle googling...
Turns out that the concerns in the ARM manual are about the perfectly standard behavior of exit().
On cplusplus.com I find:
"Data races
Calling this function destroys all objects with static duration: A program with multiple threads running shall not call exit (see quick_exit for a similar function that does not affect static objects)."
Which looks disturbing. It links us to "POSIX Safety Concepts" which defines, for example:
MT-Safe or Thread-Safe functions are safe to call in the presence of other threads. MT, in MT-Safe, stands for Multi Thread.
That is to say exit() is not thread safe.
In a pthreads tutorial I find:
"It is necessary to use pthread_exit at the end of the main program. Otherwise, when it exits, all running threads will be killed."
Ha, ha. So, if I want an orderly shutdown of my multi-threaded program I don't just call exit() willy nilly.
To be honest I have never thought so hard about the humble exit(). It's just that thing you might put at the end of main or where you have an unrecoverable error situation.
Never used exit() in threads. All the multi-threaded code I ever written is expected to run forever. Often there is nowhere to exit to anyway!
Well, I actually use pthread_join() to wait for all my threads to finish (some of them may need various individual methods for getting them to finish what they're doing). After that it's exit().
(Each individual thread will call pthread_exit() nominally, of course. Normal thread programming.) I don't normally terminate the main thread only (the one with the main() program in), there's always something useful for the main program to do, even if it's mostly waiting.
(Even so, that calling exit() in the main program without stopping threads will kill the threads still running.. I'd say that's exactly what a user would expect. That's what exit() does. It terminates the program, including all its threads, and closes all file descriptors and releases all allocated memory.)
But with pthreads were're not at beginner level anymore, so we're getting even more off-topic I guess..
Certainly we expect exit() to bring the hammer down. Kill the threads, close files, release all memory etc.
That just leaves the niggle that writes to files may not have completed properly. Or hardware may not have been returned to a sensible state. Do you want that motor controlled by a GPIO pin to continue running when the program controlling it is not? Etc.
Yeah, a bit above beginner level. But it started with my assertion that we should not expose beginners to those unsafe standard library functions. Turns out that careless use of exit() is unsafe sometimes. Not sure what to do about exit() in that case though.
If SimpleIDE is not a supported Parallax product, which you have said it isn't, then the splash screen posted shows clearly Parallax's logo and copyright messages.
Since SimpleIDE is no longer supported by Parallax, I guess there has to be some other means of being able to play with your Propeller boards on different OSs and boards, using C of course.
I had made some inquiries here before, about a method for installing PropGCC, in this case, for a Raspberry Pi, but I never did get an easy solution for doing such a thing. I am not even totally sure as to what components you would need to load and run a C program on your Propeller. Sometimes you read some posts that differ from other posts as to what an "official" way of doing things should be. I guess in this case open source is not my friend.
I guess what is needed is a specific location for obtaining PropGCC binaries for the Raspi, and then some kind of .sh or bash program to have the binaries loaded to the system. Of course this would have to have some kind of "official" title attached. But who is going to maintain such a thing. Again open source is not my friend.
So, what is the alternative? Just go with another processor that has better "official" support?
Since SimpleIDE is no longer supported by Parallax, I guess there has to be some other means of being able to play with your Propeller boards on different OSs and boards, using C of course.
Ray,
SimpleIDE is not an official Parallax product, it is a Open Source Community project, and as such, supported by many people, Parallax included. Parallax is just a contributor.
Have you gone through the Github site providing the most up to date files?
Ray,
SimpleIDE is not an official Parallax product, ...
So, they have an official copyright for SimpleIDE, as stated in About, but it is not an official Parallax product, hmm, this is getting to be interesting.
I also went to the link that was provided, is the latest SimpleIDE there copyrighted by Parallax? Also, is Parallax expecting new/old users to build their own SimpleIDE versions. Yes, that should work out great, and an easy way of using the Propeller. Also, does Parallax have a copyright for PropGCC?
This all used to be simple and straight forward, now it is becoming not so Simple.
Ray,
SimpleIDE is not an official Parallax product, ...
So, they have an official copyright for SimpleIDE, as stated in About, but it is not an official Parallax product, hmm, this is getting to be interesting.
I also went to the link that was provided, is the latest SimpleIDE there copyrighted by Parallax? Also, is Parallax expecting new/old users to build their own SimpleIDE versions. Yes, that should work out great, and an easy way of using the Propeller. Also, does Parallax have a copyright for PropGCC?
This all used to be simple and straight forward, now it is becoming not so Simple.
Ray
We will have to wait until tomorrow for Parallax to respond. Courtney was gone for a week.
I've only skimmed this thread... My experience is that SimpleIDE works fine on Windows and certain popular desktop Linux distributions. Are you suggesting it doesn't ?
I would think it reasonable that Parallax's contribution to the project was to get those certain OS supported which most it's customers are using. If not now, then certainly at the time of the initial development and investment.
Parallax has also (and in my opinion very generously) shared the entire project to the opensource community, so that anyone is free to make changes to the code, including to add support for more and future hardware platforms.
If anyone has a desire for RaspPi support, or indeed support on any other platform, then I can only suggest that person or team fork the opensource code base and add those features for themselves. That is the whole point of sharing the code for everyone and making it opensource.
With respect, taking a negative tone toward Parallax here for something you feel they should be doing for you is not a reasonable way to proceed, and is not fair. If you have genuine interest in starting a user group to work on projects that interest you, then perhaps creating a concise list of objectives and then reaching out for interested parties to join the team (in a positive and constructive manner) might be a better way to start.
Since everybody is going into politician mode, and declaring that when I just asked for a simple explanation as being negative of Parallax, then I am done with this thread. I would imagine if I were to pursue this any further, I would be banned or at least my posts would be redacted. Yes, I will only ask questions that throw a positive light on Parallax and the Propeller.
Since everybody is going into politician mode, and declaring that when I just asked for a simple explanation as being negative of Parallax, then I am done with this thread. I would imagine if I were to pursue this any further, I would be banned or at least my posts would be redacted. Yes, I will only ask questions that throw a positive light on Parallax and the Propeller.
Ray
Ray,
@VonSzarvas and my self are not Parallax employees, we were just asking to wait to get an answer from Parallax next week. No politician mode here. We are all family here.
Back in the day Parallax offered 500 dollars worth of free Parallax stuff to anyone contributing language translations to SimpleIDE. My friend contributed a Finnish translation on my prompting. And got his reward. But, last I checked there was no Finnish language option in SimpleIDE repository. Correct me if that has changed.
Also back in the day there was a lot of discussion about getting SimpleIDE and prop-gcc built and running on the Raspberry Pi. Including changes to the loader to enable loading a Prop over the UART on the GPIO pins. We had it all working fine.
Since then things got moved to github.
Sorry, but since then I have become a bit out of touch. But from what I read things have been neglected.
I do agree with VonSzarvas that anyone who wants to see support for different platforms or other changes is free to fork the code base of prop-gcc or SimpleIDE and make whatever changes they like.
However, that is not the end of the story. We don't want multiple versions of everything everywhere and total confusion.
Ideally the project owners of prop-gcc and SimpleIDE would accept pull requests for changes to the project from the community. And the projects would progress with community support.
I don't see any such project leaders and hence no such community support.
Ray- yes like Publison said, and I feel your reaction is somewhat OTT. No one is going into any mode, and no one is asking you to throw light.
What we are trying to help you understand is that you have an option to fork your own code (or form a team to do that) and develop for Pi whatever you need. IMO, You have been advised that one-way-or-another many times, and yet are still finding ways to ask the same questions whilst having gentle digs toward Parallax and adding complication in the process- seemingly because you feel Parallax should be developing RaspPi support for you. As I could understand from previous posts from Parallax staff, such development is not currently planned, so your best option remains to make your own plans.
As for questions about Parallax's copyright terms, I really suggest you contact Parallax support by phone or email to discuss them. I can't imagine this is the right place for such talk.
The way I see it, Parallax does a huge deal for the community and provides significant opensource and quality resources to help everyone get started. Sure, Parallax could do more- as could us all. We all have limited resources, but that's the point of opensource isn't it? Now and in the future anyone can grow the code. I like to believe that there is more to be achieved from creating than consuming.
As you say, this thread has covered it's course. Time to move on- perhaps with different opinions, but remaining friends I hope.
I guess what is needed is a specific location for obtaining PropGCC binaries for the Raspi, and then some kind of .sh or bash program to have the binaries loaded to the system. Of course this would have to have some kind of "official" title attached. But who is going to maintain such a thing. Again open source is not my friend.
Okay, let's talk solutions. There are "solutions" out there to your problem. I put that in quotes because I don't know of anything (other than SimpleIDE) that fits your requirements to the "T" per sei.
First, understand that I have a server monitoring the PropGCC Git repository and it will build a new PropGCC archive every time a new commit is made. You can download new Raspberry Pi images from it. The links are in many places, including here, here, and direct from the source. To utilize these archives, simply download the file and extract it to your /opt directory. You could also extract it elsewhere, but most of the software in the Parallax community will search for it in /opt by default, so that's your easiest solution.
Now, how do you use PropGCC? There are a few options. The following order is the first to come to mind, not ordered by "best" or "easiest" or what-not.
2) OmniaCreator
No longer in development, but a cool idea that is still available for consumption none-the-less: http://omniacreator.com/
3) Roll your own Makefiles and your favorite text editor
PropGCC ships with a reusable Makefile named common.mk. You can write a Makefile which includes this common one, and you'll be up and running reasonably quickly. Combine that with your favorite editor like vim, gedit, emacs, etc, and maybe that's good enough for you?
If you choose option 3, then PropWare's standalone headers and libraries will give you easy access to the simpletools.h header and its related headers and libraries (as well as PropWare and libpropeller of course). Download those headers and libraries by selecting the artifact whose name is PropWare-<VERSION>-Generic-propware.zip from this page.
This post is not meant to include detailed instructions on getting up-and-running with any of these three solutions. If you need detailed instructions, please start a new thread asking for such.
Thank you, DavidZemon, for your helpful suggestions.
SimpleIDE Windows, Mac, and Linux are official Parallax softwares. SimpleIDE Raspberry Pi was created as an open project by our community members and hosted on Learn by Parallax as a solution for people using the specific model of Raspberry Pi listed on the download page. Our community is welcome to contribute to its development and updates. Cluso, I hope this answered your question.
I am locking this thread to further commenting. If anyone here has a specific question regarding SimpleIDE software, you are always welcome to direct it to our technical support staff.
Comments
I took a very quick skim through the pdf version, and I think that the source is very good for beginners. I know that I have seen a lot of beginners here, wanting to use SimpleIDE, asking for, or looking for the programming guide to C. This pdf could be a very good introductory start, and a good added resource for what the Learn site has to offer.
The way I will probably use it is , on the Windows desktop I would open up the pdf file, and I would also connect up to the Raspberry Pi via the terminal window, and then use NANO to actually write and run the example programs.
Yes, the source covers the dreaded Pointers - "*", and "&". I think it does a very good job with that, using the examples that are relatively easy to understand. It would be kind of interesting to see, using SimpleIDE and the Propeller, where the memory is located when you use those commands.
This is just a heads up for possibly making SimpleIDE easier to use.
Ray
There's an error already in the first example..
(in ANSI C 'main' shall always return an int, but they declared it as 'void main'. This actually matters on some hardware architectures, even if not on the Pi).
They're continuing the wrong notation in the explanation on the next page. Strange that.
The next examples are fine (except for always using 'void main', why on earth?),
until we come to the section about functions, page 39.
Declaring a local function without 'static' demands a prototype (besides being pointlessly globally visible), and there isn't one, so you'll get a compiler warning when compiling with -Wall.
The chapter on strings is pretty good, with graphical illustrations of null-terminated strings. The follow-up chapter about string functions is also good.
But I don't like that, as so many others, they immediately go to 'sscanf' for something as simple as reading a number from a string. I think I mentioned in another post that, despite programming for a living in C every day, for decades, I have *never* needed sscanf (or variants). Not once.
I also think they should at least have mentioned the problems with strcpy() and strcat() (overwriting too short destination strings). No need to elaborate, that could have been left as an interesting exercise. But nothing.
Finally, on page 59, they admit that 'main' shall actually return 'int'. So why did they spend 58 pages teaching otherwise? If they believe that it makes it easier for the reader, they're mistaken.
Chapter ten, file input and output, sticks to the old fopen/fwrite/fread functions. Well, they are still somewhat useful sometimes, but the historical reason for these functions was mainly to provide buffered input (and output). So the C runtime library keeps a small buffer for this. Nowadays the operating system read() and write() functions are buffered in the kernel, and are more efficient than the fread() fwrite() variants. And if you have two or more programs communicating via files, they'll be out of sync if the 'f' functions are used. They will not be out of sync with read/write, even when data has not yet touched the disk. But read/write aren't even mentioned. Using fread/fwrite is more out of inertia these days, it's almost like seeing somebody casting the return value of malloc(). Made sense back in the K&R days, not now.
The preprocessor chapter is ok.
Chapter 13, page 81, is a quick reference, starting with control structures. It's good, and useful. Unfortunately the 'variable types' page is not as good as I would like. It harks back to DOS days, in a way. 'int can be either a short int (16 bits) or a long int (32 bits);' -- er, no, it's not exactly like that. Not really.
The pages about operators is good. Great reference. Although I don't think I saw explained anywhere what 'Bitwise 1's complement' actually means, something a new C coder may not know.
All in all the book makes C look easy, and seems to be a good starting point for new C coders. But I wish they had avoided the unnecessary inaccuracies and omissions. And I really wish they had written something about 'static', it's not that easy to understand for a beginner, but it's important to understand early on what it means, and why there are two quite different meanings of the keyword, depending on where it's used.
Direct link: https://www.raspberrypi.org/magpi-issues/Essentials_C_v1.pdf
Thanks for your review, Tor. Many nice insights there, most of which I did not know. And most importantly, thank you for providing the reasoning behind your objections.
An int will be 16 bits on Arduino and other 8 bit machines. So perhaps it's good to point out, for those coming from Arduino, that the size of int is not defined in the language. It's implementation dependent. But then again I don't think one should ever use int. Given that it is undefined it better use int32_t etc
There are so many unsafe standard library functions, strcpy etc, that I don't think they should ever even be mentioned to beginners! That includes all the no thread safe functions http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0492c/Chddjdaj.html Perhhaps not an issue for beginners on the Raspi but for sure can cause problems on the multi-core Propeller.
So yeah, some weird stuff going on there.
To be fair, none of those functions are particularly common in the beginner world, with the exception of exit() which isn't going to be used on a microcontroller anyway. But thanks for sharing, as this is yet another example of something I didn't already know
I think that little book covers what's necessary for a beginner, with just a few adjustments it would have been perfect.
Turns out that the concerns in the ARM manual are about the perfectly standard behavior of exit().
On cplusplus.com I find:
"Data races
Calling this function destroys all objects with static duration: A program with multiple threads running shall not call exit (see quick_exit for a similar function that does not affect static objects)."
Whatever that implies.
http://www.cplusplus.com/reference/cstdlib/exit/
On gnu.org the libc manual marks exit as being:
"MT-Unsafe race:exit | AS-Unsafe corrupt | AC-Unsafe corrupt lock"
Which looks disturbing. It links us to "POSIX Safety Concepts" which defines, for example:
MT-Safe or Thread-Safe functions are safe to call in the presence of other threads. MT, in MT-Safe, stands for Multi Thread.
That is to say exit() is not thread safe.
In a pthreads tutorial I find:
"It is necessary to use pthread_exit at the end of the main program. Otherwise, when it exits, all running threads will be killed."
Ha, ha. So, if I want an orderly shutdown of my multi-threaded program I don't just call exit() willy nilly.
To be honest I have never thought so hard about the humble exit(). It's just that thing you might put at the end of main or where you have an unrecoverable error situation.
Never used exit() in threads. All the multi-threaded code I ever written is expected to run forever. Often there is nowhere to exit to anyway!
(Each individual thread will call pthread_exit() nominally, of course. Normal thread programming.) I don't normally terminate the main thread only (the one with the main() program in), there's always something useful for the main program to do, even if it's mostly waiting.
(Even so, that calling exit() in the main program without stopping threads will kill the threads still running.. I'd say that's exactly what a user would expect. That's what exit() does. It terminates the program, including all its threads, and closes all file descriptors and releases all allocated memory.)
But with pthreads were're not at beginner level anymore, so we're getting even more off-topic I guess..
That just leaves the niggle that writes to files may not have completed properly. Or hardware may not have been returned to a sensible state. Do you want that motor controlled by a GPIO pin to continue running when the program controlling it is not? Etc.
Yeah, a bit above beginner level. But it started with my assertion that we should not expose beginners to those unsafe standard library functions. Turns out that careless use of exit() is unsafe sometimes. Not sure what to do about exit() in that case though.
If SimpleIDE is not a supported Parallax product, which you have said it isn't, then the splash screen posted shows clearly Parallax's logo and copyright messages.
IMHO this is quite misleading!
I had made some inquiries here before, about a method for installing PropGCC, in this case, for a Raspberry Pi, but I never did get an easy solution for doing such a thing. I am not even totally sure as to what components you would need to load and run a C program on your Propeller. Sometimes you read some posts that differ from other posts as to what an "official" way of doing things should be. I guess in this case open source is not my friend.
I guess what is needed is a specific location for obtaining PropGCC binaries for the Raspi, and then some kind of .sh or bash program to have the binaries loaded to the system. Of course this would have to have some kind of "official" title attached. But who is going to maintain such a thing. Again open source is not my friend.
So, what is the alternative? Just go with another processor that has better "official" support?
Ray
Ray,
SimpleIDE is not an official Parallax product, it is a Open Source Community project, and as such, supported by many people, Parallax included. Parallax is just a contributor.
Have you gone through the Github site providing the most up to date files?
https://github.com/parallaxinc/SimpleIDE/commits/qt5side
I also went to the link that was provided, is the latest SimpleIDE there copyrighted by Parallax? Also, is Parallax expecting new/old users to build their own SimpleIDE versions. Yes, that should work out great, and an easy way of using the Propeller. Also, does Parallax have a copyright for PropGCC?
This all used to be simple and straight forward, now it is becoming not so Simple.
Ray
We will have to wait until tomorrow for Parallax to respond. Courtney was gone for a week.
I've only skimmed this thread... My experience is that SimpleIDE works fine on Windows and certain popular desktop Linux distributions. Are you suggesting it doesn't ?
I would think it reasonable that Parallax's contribution to the project was to get those certain OS supported which most it's customers are using. If not now, then certainly at the time of the initial development and investment.
Parallax has also (and in my opinion very generously) shared the entire project to the opensource community, so that anyone is free to make changes to the code, including to add support for more and future hardware platforms.
If anyone has a desire for RaspPi support, or indeed support on any other platform, then I can only suggest that person or team fork the opensource code base and add those features for themselves. That is the whole point of sharing the code for everyone and making it opensource.
With respect, taking a negative tone toward Parallax here for something you feel they should be doing for you is not a reasonable way to proceed, and is not fair. If you have genuine interest in starting a user group to work on projects that interest you, then perhaps creating a concise list of objectives and then reaching out for interested parties to join the team (in a positive and constructive manner) might be a better way to start.
Ray
Ray,
@VonSzarvas and my self are not Parallax employees, we were just asking to wait to get an answer from Parallax next week. No politician mode here. We are all family here.
Back in the day Parallax offered 500 dollars worth of free Parallax stuff to anyone contributing language translations to SimpleIDE. My friend contributed a Finnish translation on my prompting. And got his reward. But, last I checked there was no Finnish language option in SimpleIDE repository. Correct me if that has changed.
Also back in the day there was a lot of discussion about getting SimpleIDE and prop-gcc built and running on the Raspberry Pi. Including changes to the loader to enable loading a Prop over the UART on the GPIO pins. We had it all working fine.
Since then things got moved to github.
Sorry, but since then I have become a bit out of touch. But from what I read things have been neglected.
I do agree with VonSzarvas that anyone who wants to see support for different platforms or other changes is free to fork the code base of prop-gcc or SimpleIDE and make whatever changes they like.
However, that is not the end of the story. We don't want multiple versions of everything everywhere and total confusion.
Ideally the project owners of prop-gcc and SimpleIDE would accept pull requests for changes to the project from the community. And the projects would progress with community support.
I don't see any such project leaders and hence no such community support.
Just my take on things...
What we are trying to help you understand is that you have an option to fork your own code (or form a team to do that) and develop for Pi whatever you need. IMO, You have been advised that one-way-or-another many times, and yet are still finding ways to ask the same questions whilst having gentle digs toward Parallax and adding complication in the process- seemingly because you feel Parallax should be developing RaspPi support for you. As I could understand from previous posts from Parallax staff, such development is not currently planned, so your best option remains to make your own plans.
As for questions about Parallax's copyright terms, I really suggest you contact Parallax support by phone or email to discuss them. I can't imagine this is the right place for such talk.
The way I see it, Parallax does a huge deal for the community and provides significant opensource and quality resources to help everyone get started. Sure, Parallax could do more- as could us all. We all have limited resources, but that's the point of opensource isn't it? Now and in the future anyone can grow the code. I like to believe that there is more to be achieved from creating than consuming.
As you say, this thread has covered it's course. Time to move on- perhaps with different opinions, but remaining friends I hope.
But see my post above.
Should we assume Parallax is not the project lead? They just put the work of Steve Denson into github and washed their hands of it's progress?
How can Parallax be building a whole curriculum on C if they are not taking care of the tools to do it with?
It is confusing.
Okay, let's talk solutions. There are "solutions" out there to your problem. I put that in quotes because I don't know of anything (other than SimpleIDE) that fits your requirements to the "T" per sei.
First, understand that I have a server monitoring the PropGCC Git repository and it will build a new PropGCC archive every time a new commit is made. You can download new Raspberry Pi images from it. The links are in many places, including here, here, and direct from the source. To utilize these archives, simply download the file and extract it to your /opt directory. You could also extract it elsewhere, but most of the software in the Parallax community will search for it in /opt by default, so that's your easiest solution.
Now, how do you use PropGCC? There are a few options. The following order is the first to come to mind, not ordered by "best" or "easiest" or what-not.
1) PropWare
Follow the instructions on PropWare's download page: http://david.zemon.name/PropWare/#/download
2) OmniaCreator
No longer in development, but a cool idea that is still available for consumption none-the-less: http://omniacreator.com/
3) Roll your own Makefiles and your favorite text editor
PropGCC ships with a reusable Makefile named common.mk. You can write a Makefile which includes this common one, and you'll be up and running reasonably quickly. Combine that with your favorite editor like vim, gedit, emacs, etc, and maybe that's good enough for you?
If you choose option 3, then PropWare's standalone headers and libraries will give you easy access to the simpletools.h header and its related headers and libraries (as well as PropWare and libpropeller of course). Download those headers and libraries by selecting the artifact whose name is PropWare-<VERSION>-Generic-propware.zip from this page.
This post is not meant to include detailed instructions on getting up-and-running with any of these three solutions. If you need detailed instructions, please start a new thread asking for such.
Has open source ever harmed you?
Do you have closed source friends that treat you better?
But, I do get your point perhaps. It would be great if Parallax had these things in order.
SimpleIDE Windows, Mac, and Linux are official Parallax softwares. SimpleIDE Raspberry Pi was created as an open project by our community members and hosted on Learn by Parallax as a solution for people using the specific model of Raspberry Pi listed on the download page. Our community is welcome to contribute to its development and updates. Cluso, I hope this answered your question.
I am locking this thread to further commenting. If anyone here has a specific question regarding SimpleIDE software, you are always welcome to direct it to our technical support staff.