Running a Android version of the "Propeller Tool" program, along with the terminal, would help, open source it so others could develop their own android apps to interface to their prop projects using phone(usb and bluetooth)..
I successfully tested and ran communication to a Galaxy Tab 2 to a prop plug (android sees it as ftdi) The usb port converter is needed to allow the propplug to plug into the tablet.
Being able to dev on a tablet, which also allows program download into chip using minimal hardware... ... yes do exactly that.
Bloody hell. I just put a server into production use that contains my own home made publish/subscribe protocol over websockets. Now you tell me about MQTT which does pretty much exactly the same thing! Looks like I'm going to be ripping out my pub/sub code and replacing it with MQTT.
Looks like all it needs is a bit of lower level driver code to talk to an ethernet or WIFI shield or whatever which probably exists for the Prop already.
That is only about 200 lines of C++ code and it looks like it would be pretty straight forward to translate it into Spin.
Yep, Heater .... a few people I know wrote there own protocol too before finding out about MQTT ...the great thing about MQTT is that it is very light, as you say 200 lines of code
for the Arduino client .... I would like this ported to Tachyon Forth myself, rather than spin .... but if it was in Spin it might be easier to port to Forth ... who's putting there hand up?
If someone ports to Spin, I will have a go at the Forth port.
There is already a Forth Driver for the Spinneret, I would like to interface to that code ..
I tried the MQTT python client by sending and receiving messages on the MQTT test server (http://test.mosquitto.org/). It works very well and the API is really simple. I think making a port to the propeller would be interesting.
Using the node.js module MQTT it's a five minute job to get both a server and clients up and talking to each other https://github.com/adamvr/MQTT.js/
If you want a more serious server with support for message storage and other goodies the is mosca https://github.com/mcollina/mosca
I might be tempted to get that C client working on the Prop.
What's this obsession with Forth? Such a thing as an MQTT client written in Forth would make my brain explode.
1) Get that Arduino MQTT client code working on my PC using a regular socket to provide the underlying transport That ensure I know it works.
2) Move that over the to the Prop and provide a WIZnet interface. The Spinneret is two expensive for my taste. One can probably get a Raspberry Pi to provide a WIZnet style interface, it's a lot cheaper than a Spinneret. Even the Sparkfun WIZnet modules are expensive by comparison.
Which prompts the question? Why put MQTT on the Propeller when could just spit data over to a Raspberry Pi and have it take care of all the networking protocols, something that it is a thousand times better at and will end up costing about the same.
Which prompts the question? Why put MQTT on the Propeller when could just spit data over to a Raspberry Pi and have it take care of all the networking protocols, something that it is a thousand times better at and will end up costing about the same.
You are right. Eventually, if Ethernet communication is cheap on the P2 and only require a cog and a MagJack, we could think about porting it.
What would you suggest for connecting multiple propeller or other MCU to the raspberryPI? I don't like usb serial that much because it requires long usb cables and the number of usb port is limited. SPI / I2C won't work well over a long distance too...
If we are talking about making an ethernet driver in COG and skipping the WIZ chip then we are also going to need a TCP/IP stack, which MQTT requires, in the Prop. Which is clearly impossible:)
The MQTT is the easy part.
For connecting multiple Props or other MCU's to the Pi I would suggest some kind of serial bus system. R2433/485.
Or you could build a star topology with a Prop near the Pi to concentrate all the radial links.
If we are talking about making an ethernet driver in COG and skipping the WIZ chip then we are also going to need a TCP/IP stack, which MQTT requires, in the Prop. Which is clearly impossible:)
The MQTT is the easy part.
For connecting multiple Props or other MCU's to the Pi I would suggest some kind of serial bus system. R2433/485.
Or you could build a star topology with a Prop near the Pi to concentrate all the radial links.
Any chance we could use an analog front-end like this one:
[h=1]SST12LF02-QXCE[/h]
to save money on RF comms? This one does wifi and bluetooth and is only 68 cents in volume...
Fully acknowledging that I have no idea what I'm talking about, it seems to me that this (+antenna) is the Wifi/Bluetooth equivalent of a MagJack.
- data sheet not available without NDA
- needs a fair bit of support circuitry
- needs a ton of firmware (on prop or other mcu)
- needs FCC certification for end device ($$$$$$$)
- needs licensing of BT and WiFi "essential" patents (unless exhaused by Microchip)
- needs a TON of work
Would be much less work to get USB running on P2, and write stacks for cheap WiFi & BT dongles. Much less $$$ too.
- data sheet not available without NDA
- needs a fair bit of support circuitry
- needs a ton of firmware (on prop or other mcu)
- needs FCC certification for end device ($$$$$$$)
- needs licensing of BT and WiFi "essential" patents (unless exhaused by Microchip)
- needs a TON of work
Would be much less work to get USB running on P2, and write stacks for cheap WiFi & BT dongles. Much less $$$ too.
Fair enough. I figured the FCC certification was a non-starter, but I was curious to hear a knowledgable objection... which I now have.
FWIW, I agree that bit-banging 10base-T on the Prop2 is a totally worthwhile effort. And that a USB stack, while a huge amount of work, would have a bigger payoff.
Yep, bit-banging 10base-T and USB (1.5 and 12Mbps) would save every Parallax customer a ton of money... all those lovely cheap (fcc certified) wifi and bluetooth dongles out there... leveraging off the incredible volume production of those in Asia is a big win; we can get BT and WiFi dongles for less than the cost of the raw chips here.
Not to mention that I strongly suspect one P2 cog could do four 1.5Mbps USB ports fairly simply using the hardware threads (the bit banging part; the real stack goes above that as Spin or LMM code) - plenty for keyboards, usb/serial (ok, serial not standard at 1.5, but works in Linux at least), mice, game controllers etc.
Fair enough. I figured the FCC certification was a non-starter, but I was curious to hear a knowledgable objection... which I now have.
FWIW, I agree that bit-banging 10base-T on the Prop2 is a totally worthwhile effort. And that a USB stack, while a huge amount of work, would have a bigger payoff.
The proptcp TCP/IP stack is open sourced licensed under the GPL.
I'm sure know what that means, Basically it is off limits to producers of closed source products and does not fit well with the MIT license parallax insists on for their offering in OBEX.
Somewhere we have compatibility with Arduino growing for the Propeller. I have not followed it much.
So perhaps this TCP/IP implementation is appropriate: http://playground.arduino.cc/Code/SerialIP
It uses SLIP over a serial line for packet transfer which is actually cool enough for me but I guess it can be upgraded to support WIZ chips or whatever.
I'd far rather have a $3 SDRAM on the module than a $16 WiFi chip - it would mean a minimum ($16-$3)*4 = $52 difference in module price, which would kill the market for P2 modules.
Now a place for a WiFi daughter board header might make sense, or a motherboard with wifi that takes a P2/sdram module might make sense.
Of course, a USB-AF socket, for a USB WiFi dongle ($8) makes even more sense.
I agree it's perhaps not a cool idea for Parallax to make such a WIFI enabled Prop II board as a Prop II demonstrator module. Such a module should be more general purpose and price is critical as you say.
That does not mean it might not be a cool idea for someone else to make a product from.
I agree it's perhaps not a cool idea for Parallax to make such a WIFI enabled Prop II board as a Prop II demonstrator module. Such a module should be more general purpose and price is critical as you say.
That does not mean it might not be a cool idea for someone else to make a product from.
1) Get that Arduino MQTT client code working on my PC using a regular socket to provide the underlying transport That ensure I know it works.
2) Move that over the to the Prop and provide a WIZnet interface. The Spinneret is two expensive for my taste. One can probably get a Raspberry Pi to provide a WIZnet style interface, it's a lot cheaper than a Spinneret. Even the Sparkfun WIZnet modules are expensive by comparison.
Which prompts the question? Why put MQTT on the Propeller when could just spit data over to a Raspberry Pi and have it take care of all the networking protocols, something that it is a thousand times better at and will end up costing about the same.
Because ... if I am going to make a "product" then I don't want to ask the end user to purchase a PI to use it ... it needs to stand alone ... I would like the Prop to do everything if possible ..
What's this obsession with Forth? Such a thing as an MQTT client written in Forth would make my brain explode.
Because Forth is interactive (development is quick), Forth makes very small code, which is a requirement on this platform .. i.e the WizNet driver with Telnet support is like a few hundred bytes from memory ..
.. and because it is the MOST fun language to program in ... as you interactively talk to hardware. For example, If you don't understand the Prop timers, just go and experiment with the built in Forth words that talk to
the registers .. no code/compile/debug cycle .... just fun
PS: ... and Tachyon Forth is blazingly fast !! (approx 5x Spin)
I can't fault any of those reasons for using Forth, small and fast is good. Rapid development is a bonus.
It's me. I just can't do anything with Forth. I tried to get my head around it in the 1980's and again recently. I just don't see how to make any non-trivial code in it that is not totally unreadable and looking like the output of a terminal set to the wrong baud rate.
Given the speed of the compile, download loop with Spin in the prop tool I don't get the attraction of the interactive part of Forth.
I do get your idea about making a product out of Props and not wanting a Pi in there. I had my hobbiest hat on for a minute there.
Given the speed of the compile, download loop with Spin in the prop tool I don't get the attraction of the interactive part of Forth.
.
Ok, for example: From a console, you type I2C and it tells you the address's of all the devices on the I2C bus including the 1st 16 memory contents.
You want to talk to an SPI device, so to develop an SPI driver you interactively create some words that generate the required bus waveform, you test those words interactively until
you are satisfied they are taking to the hardware as intended. Then, you build up higher level words that talk to the low level words and build up the driver, testing as you go ..
In this way, you end up with some high level driver words that do eveything you want ... and everything just works without bugs, because you tested as you go ..
I have built large Forth programs in this way, for example, I developed a complete commercial Greenhouse controller this way, it controlled temperature humidity, ventilation, the nutrient feed, irrigation rate,
implemented solar integration, reported back to the Farmer all the vital parameters to his PC ... etc etc ..after I had developed the final "word" of this application, I never had to go back and fix a bug, in the 15 yrs it was operational!
I have never been able to do that with a C program.
This all sounds great. What you are describing is a Read Evaluate Print Loop (REPL). As seen with high level languages like Lisp, Scheme, JavaScript etc. A REPL can be very nice when you are not totally convinced that some weird expression you want to write actually does what you think it should. You can instantly play with it in the REPL. Forth systems get bonus points for that feature.
Note I said "Forth systems". The REPL is not part of the language, syntactically or semantically, but part of the run time that most/all Forth systems have. A subtle but important difference. Like an IDE is not part of C or C++.
Still in the Prop Tool one can write a few lines of code and get it running on the Prop almost as quickly as a REPL.
...everything just works without bugs, because you tested as you go
Also great stuff. This called "test driven development". http://en.wikipedia.org/wiki/Test-driven_development An idea that the young software developers of today think is new. Forth systems get bonus points for that. Just to make that perfect it would be nice if all those little tests you did by hand were saved and could be repeated later. That way you could go back and change things and repeat the tests to be sure you did not break anything.
I have never been able to do that with a C program.
You are not alone. I'm not sure it is C's fault. Traditionally getting code compiled and run was a slow and tedious business. Could take all night for me back in university try to write ALGOL for our mainframe. That led to a culture of writing as much code as possible in one go and then compiling and running it. Then scratching ones head because it immediately crashed or produced screwy results. OK, fix what we think is wrong and try again.
A culture of test driven development and the fast turn around of edit, compile, run on todays machines helps there a lot.
Problem is...I can't even do simple things in Forth. Like how do you do arithmetic on complex numbers? I have yet to figure out a nice way to do it or find anyone who could help. So far it seems to be easier to do it in assembler.
Forth is attractive to me due to how it is interactive. The key realization for me was the idea that you build the Forth that gets the job done and when all that is done, it is the tool for the job. With C or SPIN or anything like it really, the tool is defined, and it is used to make a program. Forth is the program, if that makes any sense.
For me, I struggle with that paradigm, and Forth is not for me. Sometimes it is fun to dabble. To Heater's point, one would define the words that can then be used to do the math. C has a set of well defined operations that one expresses that math.
As for building on a running system, I have been playing on the P2 emulation, and it is entirely possible to do that easily now. Run the monitor, and from it cogs can be stopped, started, data put in, taken out, etc...
So then, from SPIN or C, specific pieces can be built, or written in PASM, and dropped in and or removed as needed.
Say a program written in this way is rendering to an HDTV display, and a TV is desired. Stop the video COG, upload another one, start it, and now the display is on the TV. Doing this isn't hard. One could do the same with other devices, limited by the COGS. Forth can do this in a much more granular fashion, but the door is open now for it to happen with C, SPIN, PASM now too.
Forth provides a good environment for doing small programming tasks, such as a small test program to generate ASCII characters. It provides features that you would find in simple monitor programs, but allows more complicated programs to be developed. So in some sense, Forth is a monitor program with flexible scripting features. Forth lacks many features that are found in other high level languages, such as variable types, structures, formatted I/O and local variables. It is true that Forth words have been developed to provide some of this functionality, but it's not a good fit for the language.
Another issue is that Forth compilers do not provide much error checking. The compiler doesn't warn the Forth programmer when he hasn't terminated all IF statements with a THEN, or uses the wrong loop terminator for a BEGIN loop, or forgets to use an UNLOOP when exiting a DO loop.
So I would say that Forth is good for a lot of simple tasks, but it's probably not the right language for writing very large programs.
The key realization for me was the idea that you build the Forth that gets the job done and when all that is done, it is the tool for the job. With C or SPIN or anything like it really, the tool is defined, and it is used to make a program. Forth is the program, if that makes any sense.
No:)
Well actually yes. What you are saying is that Forth is not defined. Which kind of fits with my observation that Forth is not actually a language at all. Any more than assembly languages are.
Funily enough back in the early 1980's I and a collegue were given that task fo getting a Motorola 6809 processor working. We had the naked CPU's. No boards, no assemblers, nothing. After putting the hardware around it first thing we did was build an ultra simple monitor program so that we could type op-codes into memory, in HEX, and run them and hence develop further functionality interactively and incrementally.
You don't need Forth to do this and the result is about as portable. i.e. not at all:)
Making Prop2 Accessible to the world... It's certainly not going to be Forth that sells it to the world. It will sell it to a small handful of Forth enthusiasts. Sorry, but it's true.
In the world of microcontrollers, people for the most part use Assembly, C/C++, and, to a lesser extent these days, BASIC. You may not like it, but that's what will sell Prop2's.
It's great that there are enthusiasts for other languages that are making them for the Prop and Prop2, it will serve the other enthusiast and hobby folks well. It's a positive thing for the community here, but lets be realistic, the hobby market is a tiny fraction of the sales Parallax needs for the Prop/Prop2.
I think the biggest things that will help the Prop2 sell well to the world are already in the works. The SimpleIDE tool and propgcc.
Comments
I successfully tested and ran communication to a Galaxy Tab 2 to a prop plug (android sees it as ftdi) The usb port converter is needed to allow the propplug to plug into the tablet.
Being able to dev on a tablet, which also allows program download into chip using minimal hardware... ... yes do exactly that.
Yep, Heater .... a few people I know wrote there own protocol too before finding out about MQTT ...the great thing about MQTT is that it is very light, as you say 200 lines of code
for the Arduino client .... I would like this ported to Tachyon Forth myself, rather than spin .... but if it was in Spin it might be easier to port to Forth ... who's putting there hand up?
If someone ports to Spin, I will have a go at the Forth port.
There is already a Forth Driver for the Spinneret, I would like to interface to that code ..
Using the node.js module MQTT it's a five minute job to get both a server and clients up and talking to each other https://github.com/adamvr/MQTT.js/
If you want a more serious server with support for message storage and other goodies the is mosca https://github.com/mcollina/mosca
I might be tempted to get that C client working on the Prop.
What's this obsession with Forth? Such a thing as an MQTT client written in Forth would make my brain explode.
With the Spinneret?
My approach would be,
1) Get that Arduino MQTT client code working on my PC using a regular socket to provide the underlying transport That ensure I know it works.
2) Move that over the to the Prop and provide a WIZnet interface. The Spinneret is two expensive for my taste. One can probably get a Raspberry Pi to provide a WIZnet style interface, it's a lot cheaper than a Spinneret. Even the Sparkfun WIZnet modules are expensive by comparison.
Which prompts the question? Why put MQTT on the Propeller when could just spit data over to a Raspberry Pi and have it take care of all the networking protocols, something that it is a thousand times better at and will end up costing about the same.
You are right. Eventually, if Ethernet communication is cheap on the P2 and only require a cog and a MagJack, we could think about porting it.
What would you suggest for connecting multiple propeller or other MCU to the raspberryPI? I don't like usb serial that much because it requires long usb cables and the number of usb port is limited. SPI / I2C won't work well over a long distance too...
The MQTT is the easy part.
For connecting multiple Props or other MCU's to the Pi I would suggest some kind of serial bus system. R2433/485.
Or you could build a star topology with a Prop near the Pi to concentrate all the radial links.
Now we just need a bit-banged replacement for the enc28j60 :-)
Fully acknowledging that I have no idea what I'm talking about, it seems to me that this (+antenna) is the Wifi/Bluetooth equivalent of a MagJack.
- data sheet not available without NDA
- needs a fair bit of support circuitry
- needs a ton of firmware (on prop or other mcu)
- needs FCC certification for end device ($$$$$$$)
- needs licensing of BT and WiFi "essential" patents (unless exhaused by Microchip)
- needs a TON of work
Would be much less work to get USB running on P2, and write stacks for cheap WiFi & BT dongles. Much less $$$ too.
Fair enough. I figured the FCC certification was a non-starter, but I was curious to hear a knowledgable objection... which I now have.
FWIW, I agree that bit-banging 10base-T on the Prop2 is a totally worthwhile effort. And that a USB stack, while a huge amount of work, would have a bigger payoff.
Yep, bit-banging 10base-T and USB (1.5 and 12Mbps) would save every Parallax customer a ton of money... all those lovely cheap (fcc certified) wifi and bluetooth dongles out there... leveraging off the incredible volume production of those in Asia is a big win; we can get BT and WiFi dongles for less than the cost of the raw chips here.
Not to mention that I strongly suspect one P2 cog could do four 1.5Mbps USB ports fairly simply using the hardware threads (the bit banging part; the real stack goes above that as Spin or LMM code) - plenty for keyboards, usb/serial (ok, serial not standard at 1.5, but works in Linux at least), mice, game controllers etc.
The proptcp TCP/IP stack is open sourced licensed under the GPL.
I'm sure know what that means, Basically it is off limits to producers of closed source products and does not fit well with the MIT license parallax insists on for their offering in OBEX.
We have to start again.
So perhaps this TCP/IP implementation is appropriate: http://playground.arduino.cc/Code/SerialIP
It uses SLIP over a serial line for packet transfer which is actually cool enough for me but I guess it can be upgraded to support WIZ chips or whatever.
I'd far rather have a $3 SDRAM on the module than a $16 WiFi chip - it would mean a minimum ($16-$3)*4 = $52 difference in module price, which would kill the market for P2 modules.
Now a place for a WiFi daughter board header might make sense, or a motherboard with wifi that takes a P2/sdram module might make sense.
Of course, a USB-AF socket, for a USB WiFi dongle ($8) makes even more sense.
That does not mean it might not be a cool idea for someone else to make a product from.
Because ... if I am going to make a "product" then I don't want to ask the end user to purchase a PI to use it ... it needs to stand alone ... I would like the Prop to do everything if possible ..
Because Forth is interactive (development is quick), Forth makes very small code, which is a requirement on this platform .. i.e the WizNet driver with Telnet support is like a few hundred bytes from memory ..
.. and because it is the MOST fun language to program in ... as you interactively talk to hardware. For example, If you don't understand the Prop timers, just go and experiment with the built in Forth words that talk to
the registers .. no code/compile/debug cycle .... just fun
PS: ... and Tachyon Forth is blazingly fast !! (approx 5x Spin)
I can't fault any of those reasons for using Forth, small and fast is good. Rapid development is a bonus.
It's me. I just can't do anything with Forth. I tried to get my head around it in the 1980's and again recently. I just don't see how to make any non-trivial code in it that is not totally unreadable and looking like the output of a terminal set to the wrong baud rate.
Given the speed of the compile, download loop with Spin in the prop tool I don't get the attraction of the interactive part of Forth.
I do get your idea about making a product out of Props and not wanting a Pi in there. I had my hobbiest hat on for a minute there.
Ok, for example: From a console, you type I2C and it tells you the address's of all the devices on the I2C bus including the 1st 16 memory contents.
You want to talk to an SPI device, so to develop an SPI driver you interactively create some words that generate the required bus waveform, you test those words interactively until
you are satisfied they are taking to the hardware as intended. Then, you build up higher level words that talk to the low level words and build up the driver, testing as you go ..
In this way, you end up with some high level driver words that do eveything you want ... and everything just works without bugs, because you tested as you go ..
I have built large Forth programs in this way, for example, I developed a complete commercial Greenhouse controller this way, it controlled temperature humidity, ventilation, the nutrient feed, irrigation rate,
implemented solar integration, reported back to the Farmer all the vital parameters to his PC ... etc etc ..after I had developed the final "word" of this application, I never had to go back and fix a bug, in the 15 yrs it was operational!
I have never been able to do that with a C program.
B.
This all sounds great. What you are describing is a Read Evaluate Print Loop (REPL). As seen with high level languages like Lisp, Scheme, JavaScript etc. A REPL can be very nice when you are not totally convinced that some weird expression you want to write actually does what you think it should. You can instantly play with it in the REPL. Forth systems get bonus points for that feature.
Note I said "Forth systems". The REPL is not part of the language, syntactically or semantically, but part of the run time that most/all Forth systems have. A subtle but important difference. Like an IDE is not part of C or C++.
Still in the Prop Tool one can write a few lines of code and get it running on the Prop almost as quickly as a REPL.
Also great stuff. This called "test driven development". http://en.wikipedia.org/wiki/Test-driven_development An idea that the young software developers of today think is new. Forth systems get bonus points for that. Just to make that perfect it would be nice if all those little tests you did by hand were saved and could be repeated later. That way you could go back and change things and repeat the tests to be sure you did not break anything.
You are not alone. I'm not sure it is C's fault. Traditionally getting code compiled and run was a slow and tedious business. Could take all night for me back in university try to write ALGOL for our mainframe. That led to a culture of writing as much code as possible in one go and then compiling and running it. Then scratching ones head because it immediately crashed or produced screwy results. OK, fix what we think is wrong and try again.
A culture of test driven development and the fast turn around of edit, compile, run on todays machines helps there a lot.
Problem is...I can't even do simple things in Forth. Like how do you do arithmetic on complex numbers? I have yet to figure out a nice way to do it or find anyone who could help. So far it seems to be easier to do it in assembler.
Forth is attractive to me due to how it is interactive. The key realization for me was the idea that you build the Forth that gets the job done and when all that is done, it is the tool for the job. With C or SPIN or anything like it really, the tool is defined, and it is used to make a program. Forth is the program, if that makes any sense.
For me, I struggle with that paradigm, and Forth is not for me. Sometimes it is fun to dabble. To Heater's point, one would define the words that can then be used to do the math. C has a set of well defined operations that one expresses that math.
As for building on a running system, I have been playing on the P2 emulation, and it is entirely possible to do that easily now. Run the monitor, and from it cogs can be stopped, started, data put in, taken out, etc...
So then, from SPIN or C, specific pieces can be built, or written in PASM, and dropped in and or removed as needed.
Say a program written in this way is rendering to an HDTV display, and a TV is desired. Stop the video COG, upload another one, start it, and now the display is on the TV. Doing this isn't hard. One could do the same with other devices, limited by the COGS. Forth can do this in a much more granular fashion, but the door is open now for it to happen with C, SPIN, PASM now too.
Another issue is that Forth compilers do not provide much error checking. The compiler doesn't warn the Forth programmer when he hasn't terminated all IF statements with a THEN, or uses the wrong loop terminator for a BEGIN loop, or forgets to use an UNLOOP when exiting a DO loop.
So I would say that Forth is good for a lot of simple tasks, but it's probably not the right language for writing very large programs.
No:)
Well actually yes. What you are saying is that Forth is not defined. Which kind of fits with my observation that Forth is not actually a language at all. Any more than assembly languages are.
Funily enough back in the early 1980's I and a collegue were given that task fo getting a Motorola 6809 processor working. We had the naked CPU's. No boards, no assemblers, nothing. After putting the hardware around it first thing we did was build an ultra simple monitor program so that we could type op-codes into memory, in HEX, and run them and hence develop further functionality interactively and incrementally.
You don't need Forth to do this and the result is about as portable. i.e. not at all:)
In the world of microcontrollers, people for the most part use Assembly, C/C++, and, to a lesser extent these days, BASIC. You may not like it, but that's what will sell Prop2's.
It's great that there are enthusiasts for other languages that are making them for the Prop and Prop2, it will serve the other enthusiast and hobby folks well. It's a positive thing for the community here, but lets be realistic, the hobby market is a tiny fraction of the sales Parallax needs for the Prop/Prop2.
I think the biggest things that will help the Prop2 sell well to the world are already in the works. The SimpleIDE tool and propgcc.