Parallax isn't positioning the Propeller 2 for schools and education. The current Propeller will fill that role. From Ken's message above:
Developing a quality educational program takes several years, so my statement won't be true for educational customers who read this thread in 2013. Just planning ahead since some customers read forum posts that are many years old and end up making outdated conclusions.
Since Propeller 1 has been available for quite some time and the PropBOE is heading into production our next phase of educational support will use Propeller 1.
It would be nice to be able to write efficient drivers in C.
Yes, definitely!
Although often better written in PASM there would be many times that a perfectly good driver
could be turned out in C. So a compiler that is able to generate good PASM code for use in
a cog would expand the number of coders that could create good drivers. In fact if the generated
cog PASM is good enough then entire applications that presently require PASM skills could
be done in pure C...this would be a great thing.
Parallax isn't positioning the Propeller 2 for schools and education. The current Propeller will fill that role. From Ken's message above:
The idea is not to replace Propeller1. Propeller 2 provides ADC/DAC on each pin, and it has more MIPS with more ram. This makes it more like a super SoC and makes some experimentations really easier than using an MCU with an external DAC/ADC. Even if the price is higher than Prop1+ADC+DAC, it still will provide a better educational experience (especially because of its parallelism and "software peripherals" handling).
Although often better written in PASM there would be many times that a perfectly good driver
could be turned out in C. So a compiler that is able to generate good PASM code for use in
a cog would expand the number of coders that could create good drivers. In fact if the generated
cog PASM is good enough then entire applications that presently require PASM skills could
be done in pure C...this would be a great thing.
I'll ask the GCC team if there is any way we can support this.
Binaries can be linked micro-code style like we do today with other compilers.
The thing about needing a DIP version of Prop 2 for edu use is a valid point.
I realize that Parallax and others will produce little boards that have a prop 2
on them and can plug into a breadboard or be soldered onto a circuit board.
But I really find those kinds of carrier boards esthetically displeasing :-(
It's like stuffing a bunch of code into Main() instead of putting it into a separate
and neat function of its own. I wince every time I see one of those busy little
circuit boards grafted onto a project.
Surely there is someone clever enough to come up with a way to cheaply
create little encapsulated modules that look like largish DIP ICs and contain
a Prop2, xtal, eeprom...etc and look nice and tidy. perhaps it's even possible
to create them without needing a tiny circuit board inside... some way to make
assembling them like a dead bug, point2point affair.
+
+
and a sm Prop2 and some epoxy to form the plastic case
= profit
(maybe this is a job for microcontrolled? didn't he say he needed some $ :-)
I'll ask the GCC team if there is any way we can support this.
Binaries can be linked micro-code style like we do today with other compilers.
With small core like the Prop, I think the best way to manage this, is to move both GCC and PASM.
PASM can become more structured, and C-Like, and GCC would likely need some subset-rules, when coding.
I like the approach of HLA, which removes much of the label-fluff from ASM, with support for IF ELSE etc, but the lines of code
are still pure-asm in nature.
#define (etc) is another clear code management tool.
Lots of simple things, can reduce the culture shock effect, of someone new ot ASM/PASM
Surely there is someone clever enough to come up with a way to cheaply
create little encapsulated modules that look like largish DIP ICs and contain
a Prop2, xtal, eeprom...etc and look nice and tidy.
but they will still have a PCB inside them, or is it just being able to SEE the PCB that bothers you ?
Seems strange, as it sits on a PCB, you can also see... ?
Maybe Parallax should think to make a version that have less pins in a DIP package (and a 48 LQFP package) ... DIP is the way to success in schools and education.
The Die maxes out a LQFP128, so LQFP48 you can forget about.
That leaves needing a good (small) PCB design, as a carrier.
This is great. I'm pleased with the resolution posted so far.
I strongly agree with Holly on C --> PASM in the COG.
I've made this suggestion several times before - perhaps if I do it often enough someone will act on it!
C ---> PASM on the Cog would be quite easy - provided you to limit yourself to a subset of C. For instance, only support a subset of types (e.g. only have a single type of "int" which is 32 bits).
These requirements do not match GCC very well, but would be a very close fit for the "original" TCC compiler (i.e. otccn.c available here), which compiles a surprisingly large subset of C to X86 assembler in about a thousand lines of C code. Swap out the X86-specific ASM instructions and swap in PASM instructions and away you go - a perfect language for writing COG-based drivers in C!
This would be an extremely useful project for someone to take on.
I've made this suggestion several times before - perhaps if I do it often enough someone will act on it!
C ---> PASM on the Cog would be quite easy - provided you to limit yourself to a subset of C. For instance, only support a subset of types (e.g. only have a single type of "int" which is 32 bits).
These requirements do not match GCC very well, but would be a very close fit for the "original" TCC compiler (i.e. otccn.c available here), which compiles a surprisingly large subset of C to X86 assembler in about a thousand lines of C code. Swap out the X86-specific ASM instructions and swap in PASM instructions and away you go - a perfect language for writing COG-based drivers in C!
This would be an extremely useful project for someone to take on.
Ross.
This makes the most sense, you are effectively making a C-Syntax Assembler.
If it supported in line assembler, and output ASM files with C as comments, it gets very easy for anyone to get up to speed.
A simulator would finish it all off nicely....
There's growing chatter and hand-wringing on the interwebs lately about Microsoft adopting HTML5 as the environment of choice for apps in Win8 -- to the possible deprecation of .NET. This could make any HTML5-capable web browser the cross-platform presentation engine of choice. But I'm not sure what programming language would be turning the gears of these apps. Javascript? Surely not! My suspicion is that a localized web server will handle the back-end stuff, and it could be written in anything -- even Perl. This would also help Microsoft advance their cloud computing objectives, since any app that runs as a local server could just as easily run remotely. (Well, almost any app. I'd like to see a remote app that can upload programs over a local USB port. Javascript certainly can't handle that on the client side -- at least I don't think it can.)
So what does this mean for a Propeller IDE? Is HTML5 a rich enough environment to support IDE operations? If so, should Parallax Semiconductor be on the bleeding edge of adoption? Given the effort required to produce an IDE and the consequent fact that it will have to serve the Propeller community for years to come, maybe HTML5 is worth looking into, just so we don't fall behind the curve.
are written with web standards, primarily HTML, CSS, and JavaScript;
and are deployed on more than one mobile platform.
So it looks like the normal HTML and Java script nonsense.
There is at least one MCU dev system out there that is programmed via a WEB based IDE. You edit on your browser and compilation happens on their web site. I forget what that board is called. No idea how it downloads to the board but I guess the MCU has a boot loader that is friendly to USB and you just drop the compiled and downloaded binary into a file system on that USB device.
I suspect the real work on a completely local system would have to be done in a back-end server app that could be written in anything (C, C++, Python, etc.). The browser/HTML5 would just be the GUI (i.e. editor window, buttons, etc.). I believe the idea has merit, assuming HTML5 is rich enough to accommodate the IDE's presentation needs.
I believe the idea has merit, assuming HTML5 is rich enough to accommodate the IDE's presentation needs.
HTML5 may be rich enough, but it seems like no one has ever actually made a browser that really supported anything the W3C has put together, and if they did you still couldn't code to just it.
I hate the thought of a ton of conditional Smile regarding what browser, what version, what platform...
I haven't seen enough HTML5 to know if the capabilties to support a GUI IDE are there, but I suspect they are or willbe soon. This would offer platform independence for teh front-end and allow the myriad of intelligent human interface devices we interact with each day to be our portal into programming. The backend would still need to genrate the binary that somehow gets loaded into an embedded device.
For the "internet of things", this could well be a code generator backend running in the cloud someplace that ships a loadable off to an internet connected device for loading/reloading. There still needs to be a "local" backend to generate code for devices that can't be connected to the net, don't have the resources to talk to the net or don't want to be connected to the net for various reasons.
Splitting the effort between the front end creation of human understandable code (text, 12blocks, etc.) and the backend generation makes sense.
There almost needs to be a third piece to the pie - code delivery. Prop Plug, USB, Xbee, IP, the device being programmed has many different ways to bootstrap and load it's code before it starts being useful.
I suspect the real work on a completely local system would have to be done in a back-end server app that could be written in anything (C, C++, Python, etc.). The browser/HTML5 would just be the GUI (i.e. editor window, buttons, etc.). I believe the idea has merit, assuming HTML5 is rich enough to accommodate the IDE's presentation needs.
-Phil
Interesting and timely idea Phil.
I was talking to someone about doing just this with a Spinneret yesterday for loading the SDcard for booting an upcoming MCU ... that is until the MCU can do it by itself
The mbed uses a browser-based IDE with a remote compiler. All of your development code is stored on their server, where it's compiled. You then download a binary and save it to flash memory on the mbed. The bootloader automatically loads the newest binary when it powers up. so you only need to put the file there.
It works well enough, and it's a neat concept, but if you don't have access to the internet, you can't use it. Fortunately, there's a workaround... using the LPCXpresso Eclipse-based IDE. You basically follow the same process, but it's less automated.
I'm not sure why Parallax would consider being on the bleeding edge for this project. I don't think the targeted audience wants a browser-based IDE as their primary working environment.
We have to distinguish between a browser-based "cloud" IDE and a browser-based local IDE. In the latter case, the "server" software runs on either the user's own computer or his organization's central server, so no internet connection is necessary. That latter scenario can be very beneficial to large organizations, since the working files can be centrally located and software upgrades need to be made on only one machine.
To me, an argument for being on the bleeding edge is that the effort to develop the IDE, compared to the manpower available, is pretty large in Parallax's case. So whatever is done has to last awhile. Today's bleeding edge is tomorrow's yesterday's news. So it's better to position youself ahead of the curve just to avoid falling behind.
I doubt that any of us have really experienced how a full-featured HTML5 platform looks and feels. I know I haven't. But the hints drifting about that it's something Microsoft is embracing whole-hog, plus something that would make cross-platform portability easier, gives me reason to think that it's something worth serious consideration.
I think Phil's idea sounds very interesting. I do have some concerns regarding possible network security issues with the server-end, or installation and configuration complexities. Now Jazzed might be onto something with Spinneret acting as the server and programmer. The compiler could be written in java(?) and run on the local machine.
Whether HTML5-based applications are the wave of the future, I don't know. IMO, Parallax would be making a huge mistake to suddenly decide to build their "professional level" tools as a web app. The fact is, there are thousands+ of software developers successfully using traditional toolchains. To throw away a successful model for one that, at this time, is somewhat of a novelty, would only put Parallax further behind in the race they've entered.
Fwiw, the mbed IDE is very limited. It's not designed to be a professional environment, but more of a hobbyist tool.
IMO, Parallax would be making a huge mistake to suddenly decide to build their "professional level" tools as a web app.
Once again, an HTML5 application need not be a web app. The entire application can be contained in the user's PC, with the user's browser serving as the GUI. The back-end work can be done by software that's resident in the user's PC -- or on a corporate server.
I'm not familiar with mbed. But given your impression, it's probably a poor standard of comparison to what could be done. Frankly, I'm not familiar enough with HTML5 to actively promote it. But I do believe it's something that bears investigation.
Now Jazzed might be onto something with Spinneret acting as the server and programmer. The compiler could be written in java(?) and run on the local machine.
Let me expand on this a little. What ever cloud thingy that was being discussed was not really my point.
The Spinneret's SDcard can be used as a local (co-resident) store for Propeller programs and used to boot other Propellers in an isolated place or an equipment farm available for remote users.
Now, with the understanding that there will be a SPI interface available for booting Propeller 2, this becomes more interesting. At some point Propeller 2 could be used to save programs to it's own bootable SDcard and therefore be "self-servicing". Until that happens, or even afterwards a Spinneret could be used to manage the boot program. An even more interesting idea is TFTPBOOT of course.
I think Spinneret can contribute lots of value in this respect.
Now if i could only remember how to spell Spinnerrettee and propably
Let me expand on this a little. What ever cloud thingy that was being discussed was not really my point.
The Spinneret's SDcard can be used as a local (co-resident) store for Propeller programs and used to boot other Propellers in an isolated place or an equipment farm available for remote users.
Now, with the understanding that there will be a SPI interface available for booting Propeller 2, this becomes more interesting. At some point Propeller 2 could be used to save programs to it's own bootable SDcard and therefore be "self-servicing". Until that happens, or even afterwards a Spinneret could be used to manage the boot program. An even more interesting idea is TFTPBOOT of course.
I think Spinneret can contribute lots of value in this respect.
Now if i could only remember how to spell Spinnerrettee and propably
I wasn't particularly thinking about the all powerful Cloud, but rather as you mention, the Spinneret acts as a network connected programmer, with the addition of Phil's idea for a web-browser based IDE GUI. The java compiler was just a thought considering it could be executed from the local machine within the browser, and then sent down the network for programming.
One thing markaeric mentions in that other thread is integration with the OBEX. I hadn't thought about that, but a web-aware IDE has the possibility to use an accommodating OBEX directly as a library folder or, at least, as a direct link for downloading the necessary files.
Comments
Developing a quality educational program takes several years, so my statement won't be true for educational customers who read this thread in 2013. Just planning ahead since some customers read forum posts that are many years old and end up making outdated conclusions.
Since Propeller 1 has been available for quite some time and the PropBOE is heading into production our next phase of educational support will use Propeller 1.
Ken Gracey
All of the above. If the IDE can be configured to use command line tools of your choice, then you should be able to use it.
Yes, definitely!
Although often better written in PASM there would be many times that a perfectly good driver
could be turned out in C. So a compiler that is able to generate good PASM code for use in
a cog would expand the number of coders that could create good drivers. In fact if the generated
cog PASM is good enough then entire applications that presently require PASM skills could
be done in pure C...this would be a great thing.
The idea is not to replace Propeller1. Propeller 2 provides ADC/DAC on each pin, and it has more MIPS with more ram. This makes it more like a super SoC and makes some experimentations really easier than using an MCU with an external DAC/ADC. Even if the price is higher than Prop1+ADC+DAC, it still will provide a better educational experience (especially because of its parallelism and "software peripherals" handling).
Binaries can be linked micro-code style like we do today with other compilers.
I realize that Parallax and others will produce little boards that have a prop 2
on them and can plug into a breadboard or be soldered onto a circuit board.
But I really find those kinds of carrier boards esthetically displeasing :-(
It's like stuffing a bunch of code into Main() instead of putting it into a separate
and neat function of its own. I wince every time I see one of those busy little
circuit boards grafted onto a project.
Surely there is someone clever enough to come up with a way to cheaply
create little encapsulated modules that look like largish DIP ICs and contain
a Prop2, xtal, eeprom...etc and look nice and tidy. perhaps it's even possible
to create them without needing a tiny circuit board inside... some way to make
assembling them like a dead bug, point2point affair.
+
+
and a sm Prop2 and some epoxy to form the plastic case
= profit
(maybe this is a job for microcontrolled? didn't he say he needed some $ :-)
With small core like the Prop, I think the best way to manage this, is to move both GCC and PASM.
PASM can become more structured, and C-Like, and GCC would likely need some subset-rules, when coding.
I like the approach of HLA, which removes much of the label-fluff from ASM, with support for IF ELSE etc, but the lines of code
are still pure-asm in nature.
#define (etc) is another clear code management tool.
Lots of simple things, can reduce the culture shock effect, of someone new ot ASM/PASM
Why ?
but they will still have a PCB inside them, or is it just being able to SEE the PCB that bothers you ?
Seems strange, as it sits on a PCB, you can also see... ?
The Die maxes out a LQFP128, so LQFP48 you can forget about.
That leaves needing a good (small) PCB design, as a carrier.
I strongly agree with Holly on C --> PASM in the COG.
I've made this suggestion several times before - perhaps if I do it often enough someone will act on it!
C ---> PASM on the Cog would be quite easy - provided you to limit yourself to a subset of C. For instance, only support a subset of types (e.g. only have a single type of "int" which is 32 bits).
These requirements do not match GCC very well, but would be a very close fit for the "original" TCC compiler (i.e. otccn.c available here), which compiles a surprisingly large subset of C to X86 assembler in about a thousand lines of C code. Swap out the X86-specific ASM instructions and swap in PASM instructions and away you go - a perfect language for writing COG-based drivers in C!
This would be an extremely useful project for someone to take on.
Ross.
You're hired!
Let me rephrase that slightly - this would be an extremely useful project for someone ELSE to take on!
Ross.
This makes the most sense, you are effectively making a C-Syntax Assembler.
If it supported in line assembler, and output ASM files with C as comments, it gets very easy for anyone to get up to speed.
A simulator would finish it all off nicely....
So what does this mean for a Propeller IDE? Is HTML5 a rich enough environment to support IDE operations? If so, should Parallax Semiconductor be on the bleeding edge of adoption? Given the effort required to produce an IDE and the consequent fact that it will have to serve the Propeller community for years to come, maybe HTML5 is worth looking into, just so we don't fall behind the curve.
-Phil
According to my quick google an HTML 5 app is: So it looks like the normal HTML and Java script nonsense.
There is at least one MCU dev system out there that is programmed via a WEB based IDE. You edit on your browser and compilation happens on their web site. I forget what that board is called. No idea how it downloads to the board but I guess the MCU has a boot loader that is friendly to USB and you just drop the compiled and downloaded binary into a file system on that USB device.
All in all I don't much like the idea.
For me that is a mighty generous comment to say the least.
C.W.
-Phil
HTML5 may be rich enough, but it seems like no one has ever actually made a browser that really supported anything the W3C has put together, and if they did you still couldn't code to just it.
I hate the thought of a ton of conditional Smile regarding what browser, what version, what platform...
C.W.
For the "internet of things", this could well be a code generator backend running in the cloud someplace that ships a loadable off to an internet connected device for loading/reloading. There still needs to be a "local" backend to generate code for devices that can't be connected to the net, don't have the resources to talk to the net or don't want to be connected to the net for various reasons.
Splitting the effort between the front end creation of human understandable code (text, 12blocks, etc.) and the backend generation makes sense.
There almost needs to be a third piece to the pie - code delivery. Prop Plug, USB, Xbee, IP, the device being programmed has many different ways to bootstrap and load it's code before it starts being useful.
Just wandering into waters too deep for me......
Rick
Interesting and timely idea Phil.
I was talking to someone about doing just this with a Spinneret yesterday for loading the SDcard for booting an upcoming MCU ... that is until the MCU can do it by itself
It works well enough, and it's a neat concept, but if you don't have access to the internet, you can't use it. Fortunately, there's a workaround... using the LPCXpresso Eclipse-based IDE. You basically follow the same process, but it's less automated.
I'm not sure why Parallax would consider being on the bleeding edge for this project. I don't think the targeted audience wants a browser-based IDE as their primary working environment.
To me, an argument for being on the bleeding edge is that the effort to develop the IDE, compared to the manpower available, is pretty large in Parallax's case. So whatever is done has to last awhile. Today's bleeding edge is tomorrow's yesterday's news. So it's better to position youself ahead of the curve just to avoid falling behind.
I doubt that any of us have really experienced how a full-featured HTML5 platform looks and feels. I know I haven't. But the hints drifting about that it's something Microsoft is embracing whole-hog, plus something that would make cross-platform portability easier, gives me reason to think that it's something worth serious consideration.
-Phil
That already say --- Not for people that will even have code protect in Propeller!
Fwiw, the mbed IDE is very limited. It's not designed to be a professional environment, but more of a hobbyist tool.
Once again, an HTML5 application need not be a web app. The entire application can be contained in the user's PC, with the user's browser serving as the GUI. The back-end work can be done by software that's resident in the user's PC -- or on a corporate server.
I'm not familiar with mbed. But given your impression, it's probably a poor standard of comparison to what could be done. Frankly, I'm not familiar enough with HTML5 to actively promote it. But I do believe it's something that bears investigation.
-Phil
The Spinneret's SDcard can be used as a local (co-resident) store for Propeller programs and used to boot other Propellers in an isolated place or an equipment farm available for remote users.
Now, with the understanding that there will be a SPI interface available for booting Propeller 2, this becomes more interesting. At some point Propeller 2 could be used to save programs to it's own bootable SDcard and therefore be "self-servicing". Until that happens, or even afterwards a Spinneret could be used to manage the boot program. An even more interesting idea is TFTPBOOT of course.
I think Spinneret can contribute lots of value in this respect.
Now if i could only remember how to spell Spinnerrettee and propably
I wasn't particularly thinking about the all powerful Cloud, but rather as you mention, the Spinneret acts as a network connected programmer, with the addition of Phil's idea for a web-browser based IDE GUI. The java compiler was just a thought considering it could be executed from the local machine within the browser, and then sent down the network for programming.
To avoid me further hi-jacking this thread, I created a new thread to discuss such an approach here: http://forums.parallax.com/showthread.php?132466-Thoughts-on-Chip-s-original-P2-IDE%28a%29
-Phil