People get a lot of traction out of the audio jack. It has three lines plus ground, not just two, I think. My wife uses it for a credit card reader on her iPhone.
Sorry, I guess I didn't read the thread as thoroughly as I should have. I started reading your post 13 but thought it just dealt with programming languages and missed the idea at the end to use a BeagleBone or RaspPi as an interface to the Propeller.
David, I was just teasing with everyone. The web interface/raspi/cloud/hosted solution has been brought up before and after me.
This really an interesting thread there are a number of solutions to be investigated and pursued and as usual, the forum collective brain storm is up to a full gale on this problem!
David, I was just teasing with everyone. The web interface/raspi/cloud/hosted solution has been brought up before and after me.
This really an interesting thread there are a number of solutions to be investigated and pursued and as usual, the forum collective brain storm is up to a full gale on this problem!
I happen to have one of the Redpark serial cables for the old 30 pin dock connector. I realize it probably isn't the best solution but I might start with it because it involves no additional hardware investment.
[QUOTE=mindrobots;1216842. . . the forum collective brain storm is up to a full gale on this problem![/QUOTE]
It's really true, Rick. Almost every possible solution has been brought up in this thread and for this crowd-sourcing set of ideas we are really thankful. Parallax has the best customers of any company, in case anybody wondered.
Our initial objectives are as follows:
(a) Outline a comparison of the various alternatives to meeting a full program/download goal (identify hardware, pros, cons, etc.)
(b) Meet with key developer relations people from Apple to further narrow our possibilities from a larger comparison. Are we chasing a rabbit through the forest, or down a hole with our preferred alternative(s)? We have two key contacts.
(c) Write a specification for what we would like to achieve.
(d) Put it out for development review and quoting. I'm not ruling out anything here in terms of development team - PropGCC and the related tools were built by people on these forums, yet we know we will need some specific expertise with iPad depending on the choice of what we want to do. Would need to determine costs and benefits at this point, more closely than currently known.
If anybody thinks there's a better way to go about it, please share.
Well, if you're willing to work with Apple on this and pay them for every piece of hardware you sell, you can probably do a lot better...
I have this remote control ball thing (Sphero) that works with iPad and iPhone and Android. You can control it and send it updates over Bluetooth.
So, I'm pretty sure this would be the ideal solution.
Well, if you're willing to work with Apple on this and pay them for every piece of hardware you sell, you can probably do a lot better...
I have this remote control ball thing (Sphero) that works with iPad and iPhone and Android. You can control it and send it updates over Bluetooth.
So, I'm pretty sure this would be the ideal solution.
Ray, with the idea you suggest I could imagine a GUI (like the S2) that sends configuration commands to an ActivityBot running a SIDE-loaded program, instead of a complete download of a whole Propeller binary file. This is what you suggest, right?
/me still looking for that old Parallax ad with the dog....
Times are changing, Jeff. I work in two different schools right now and receive input from instructors quite regularly. Many tools have bigger ecosystems around them, code keeps looking more high-level than before, and the operating system of choice is new (and locked down, and limited). To remain viable and productive, Parallax has to listen to these customers and give it an honest consideration. Neither one of us reflect the demographic that we need to reach, so this can be hard to envision.
Maybe you're trying to save my time, which would certainly be considered a productive contribution but we won't know if it's worth the time until we're done exploring possibilities. All I ask is that this thread mostly be used for what I originally suggested: ideas, input, etc. that we can use.
In the end, we all benefit from a successful Parallax. Parallax has $4M into Propeller 2, everything we've ever made. Efforts like this help us will help us achieve that goal.
Ray, with the idea you suggest I could imagine a GUI (like the S2) that sends configuration commands to an ActivityBot running a SIDE-loaded program, instead of a complete download of a whole Propeller binary file. This is what you suggest, right?
I think that would be one great thing to have with a robot.
But, Sphero is also able to update it's firmware over the Bluetooth connection.
So, if you can compile your code on the iPad (should be fairly straightforward), then you should be able to program the Parallax robot over Bluetooth as well...
I see it exactly the opposite way. The Prop and the Pi are so very different they can not be in competition. They are complimentary.
...
True. That is the beauty of the plan to use the Pi. The Pi is great for the networking, Prop loading, compiler running, IDE hosting etc.
BUT it is severely limited in GPIO and real-time capabilities.
Exactly where the Propeller shines.
I would agree, and note this is not really a Pi, as much as a Pi-App.
Most class rooms would dedicate a Pi for this task, and then care less what the actual HW was.
Parallax would have to provide the (significant) collection of Pi tools, to allow the WiFi in, to Compile to Prop & Download,
so it becomes a Prop-Pi-Server, but running on generic Pi hardware.
This allows kids to use Apple stuff if they really want to, but avoids the crippling constraints of trying to use only iPads
Apple is very much a Consumer Company, and a somewhat paranoid one at that, best to jump off the Apple as soon as possible, and run the real work, on something (anything!) else.
Expanding on the Software delivery and management side, which is perhaps the most challenging, I see there are just emerging SD cards with Wifi built in. (and flash drives with WiFi, but those tended to include batteries, and are larger physically)
Not cheap yet, but long term, the single package has real appeal.
Development could be done with separate units, until the price moves mass-market.
A product like that would allow Parallax to sell a pre-loaded card, as a Prop(pi) Server.
All tools needed would be on the SD, and the WiFi link to the iPads is there too.
Has any one tried this on an ipad? https://www.realvnc.com/products/ios/
If you can VNC to a Pi running Debian Wheezy & SimplIDE, problem solved-no custom programming necessary and best of all no having to deal with apple.
-dan
Apple is very much a Consumer Company, and a somewhat paranoid one at that, best to jump off the Apple as soon as possible, and run the real work, on something (anything!) else.
I assume you're talking about iPads and iPhones and not Macintoshes. I've done all of my PropGCC work on a Mac and find it a much better development environment than a Windows machine. For one, it compiles PropGCC a *lot* faster than Windows. Linux would be good as well of course.
I've done all of my PropGCC work on a Mac and find it a much better development environment than a Windows machine. For one, it compiles PropGCC a *lot* faster than Windows. Linux would be good as well of course.
Is that really a Mac/Windows issue ? I'd have expected any command line compiler to have very little to do with the OS, once it got going.
Given newest MACs use intel cores, I would expect speed differences to be more core-defined than OS defined ?
What machine specs did you compare in your tests ?
Is that really a Mac/Windows issue ? I'd have expected any command line compiler to have very little to do with the OS, once it got going.
Given newest MACs use intel cores, I would expect speed differences to be more core-defined than OS defined ?
What machine specs did you compare in your tests ?
The problem is the GNU emulation environment under Windows. You have to use either Cygwin or MinGW to compile PropGCC under Windows. They are both slow. The native Windows tools are fine I'm sure.
One big difference between windows and Unixes is windows has a high process start overhead and it much prefers to initiate new threads.
Unix is extremely lean when it comes to either.
Recent versions of windows are better at this, but there are still significant differences.
I very regularly used to run batch transforms on large data sets consisting of many files. These were process oriented things, not threaded, unless I wanted to code for threads. Simple scrips were stupid easyand could be generated with other scripts and simple programs.
Running these on Windows never ever reached the speeds of IRIX and Linux, despite better specs on the windows machine.
A 400Mhz mips box or 800Mhz P3 running linux could knock the task out faster than a wintel at double those speeds. This was during windows xp, 2K, etc... timeframe. No contest. I was kind of shocked at how good IRIX was, particularly when running a couple of big scripts at the same time on a single core machine. Linux was close, and by now likely equal or better.
That is with reasonably comparable I/O, BTW.
Today, My Mac running at 2 something Ghz i7 and with a slow 3500 RPM disk can compile PropGCC in about 7 to 10 minutes. My windows machine at a higher clock and ssd takes longer. It is an i7 with 3.5Ghz burst mode too.
I suspect the slowness goes right to being process oriented as opposed to threaded.
Another difference comes down to what gets cached and how. IRIX file caching has to be seen to be believed. Insane good. Linux is great now, though I've not really pushed it on the later kernels. It was not up to IRIX back then. Windows isn't so good at this. Never has been. That will impact things that run a lot in ways you don't always think about. Often I will see repeated loads on windows, wher I would not on IRIX, and not as often on Linux.
Lastly, those things remain true on Unix in general even when the RAM is consumed near fully. I can do a Propgcc build on the Mac with a ton of Smile running, and it takes an extra minute or two. No big deal.
Windows craps out when it begins to see less than a GB free. I notice this behavior on large CAD datasets today, and my Mac performs better on them despite half the RAM and a slower disk.
I also see windows perform marginally when all cores are saturated. It just can't schedule like Unixes can. Never has.
When things are nice and roomy, windows will do well. When it is a crunch of some kind, it does not perform as well.
The new win 8 kernel is supposed to be much improved. Too bad about the UI. Haven't tried it yet. Wish I could get that kernel on Win 7...
Today, My Mac running at 2 something Ghz i7 and with a slow 3500 RPM disk can compile PropGCC in about 7 to 10 minutes. My windows machine at a higher clock and ssd takes longer. It is an i7 with 3.5Ghz burst mode too.
I'm using a 2010 vintage MacBook Pro with a dual core i5.
I'm pretty sure I posted some benchmark builds for fun in the P2 forum. I get my Mac fixed this weekend. (Finally). I really miss it. When you get P2 stuff done, I'll build again. And update docs, which I have not done.
Mine is a quad core i7, with the hyper threading. Nice CPU. Slow disk though, but Mac OS seems to manage it well enough, I've not seen fit to upgrade it. That same disk on a Windows machine would be painful...
I'm eager to try Macricks, but I want to keep my old Snow Leopard OS for builds of GCC. Maybe I will put a really fast one in there and see how much better Apple has done.
To be really honest, I would move back to Linux / MacOS for this stuff if it were easier to run the windows pnut.exe . The little bit of PropGCC I did on Mac OS was pure joy. Nice UI, real OS, etc... Pretty too.
Right now, the FPGA stuff is on old XP, right along with a ton of Prop things. And that box is an old core duo. Slow as all get out now...
Anyway, native windows tools are threaded, run fast, etc. Anything else comes off as kind of crappy, and of course when you really lean on it, windows isn't optimal.
Based on what Ken says, another way we could go is to have preloaded robotics code on the props and have an iPad app that serves as a wireless controller and activator or selector of various functionalities. This could make the robots super accessible to people.
Thank you Rick! I've been numorous times searching Google/Parallax.com in the attempt to find that...
It seems that computer, tablet, phone, and device industries are moving more toward a generic GUI which is open and operates on interchanging standards. You can see the same trend happening here that happened years ago with the automotive industry. Companies like Microsoft and Apple which set copied the initial standards are finding it harder and harder to stay relevant. If you look at cell phones, it appears to have already happened. The masses don't care what the application is as long as it is cheap! and works mostly like they are used to.
Ken, please don't tie yourself to an expensive, closed system which allows someone else to dictate what you are/are not allowed to do. I can't imagine Apple being compatible with anything more than very limited programming capabilities. Unless their attitude has changed from this example (http://www.tomsguide.com/us/Apple-App-BASIC-Commodore-64,news-4608.html) Happened a while back so who knows.
The future is open. Efforts which embrace a larger audience would certainly pay off..
My crystal ball doesn't seem to show an Apple or Microsoft logo in it, but hey I may have read the instructions for configuring it wrong.
Manomio's C64 app is alive and kicking on iPads and iPhones, today. It includes BASIC and a small number of games on installation with the ability to in-app purchase additional officially licensed games. Sounds like a good deal for C64 enthusiasts and license owners, to me...
The idea of programming Propellers via iPad does not imply allowing iOS executable code to be compiled. I think the stumbling block for many early compiler/interpreter app attempts was in allowing in-app code development for the iOS device itself. Things may have changed and a well-designed, secure app, developed by a company with real skin in the Education game (Parallax) could be the ticket. Many iOS device developers have a good handle on providing their apps on Android devices as well. But, the real revenue-maker is definitely iOS, for app developers.
Parallax has to think about the marketing of such an app as we've discussed. Having a great idea for an app is good, but you need a great marketing plan to get your idea into the hearts and minds of your consumer base. There's no better marketing machine than Apple, at this time, on this planet anyway. It can all change tomorrow, of course, but you really can't say where the future will lead.
I agree with others that a central host device would be the best way to go. Here's what is proposed:
Here we can see a central host wireless server. The students can use their WiFi devices (iPad, Android, laptop) to connect to the server. If the server is internet connected then they can use it like a regular access point, and browse the internet.
The server hosts a Node.js application for the Propeller compilation aspects. A browser based client connects to the server and appears much like a traditional IDE to the user. They can go about and edit the code as normal. When they hit "Compile and Run" then the code is compiled on the server and downloaded to one of the connected Propeller devices.
The Propeller could be connected in whatever way(s) the server can find them, but the easiest would be USB.
The server would be some small ARM system. Parallax could package it up nicely where it is plug and play, and with a case that clearly labels USB ports so that it makes it easy to select the correct Propeller board from the web client. Each classroom would have one server per three or four students. Parallax could make a custom case for whatever ARM board they select:
The overall system is fairly simple, and a competent programmer should be able to come up with something usable and deployable for testing in two months or less. I'm basing this on my experience with Node.js: I started developing an application a month and a half ago, and now it's a fairly advanced tool. Node.js is is dead simple even for somebody with no web programming experience.
The advantages of this system include:
- Easy to build and test for a small company (Parallax!)
- Easy to setup for the customer
- Device agnostic (won't get tied to Apple, Android, Windows...)
- Additional revenue from a "Classroom package"
You could have this system up and running in a classroom by January for testing, and production ready by school year 2014-2015
Some challenges that I forsee:
- What to do with the files (where to store them?)
- How to compile larger, multifile projects?
- How to deal with the restricted networks of schools if the server isn't recognized as a valid network client?
But these are fairly minor questions, and ones that you would have to deal with anyway.
Ditto Invent-O-Doc! Having the Props connect to the server, rather than to the clients, does simplify things. Even an XBee could be connected to the server to distribute code to any number of Propeller boards. That way each student's Prop board could be located in his/her own work area.
I had envisaged one ARM board, with WIFI, per student, simply because it saves dragging USB or serial cables to the desks or work benches. But one such board could easily serve a whole class as you have drawn it.
I agree with others that a central host device would be the best way to go. Here's what is proposed:
Here we can see a central host wireless server. The students can use their WiFi devices (iPad, Android, laptop) to connect to the server. If the server is internet connected then they can use it like a regular access point, and browse the internet.
The server hosts a Node.js application for the Propeller compilation aspects. A browser based client connects to the server and appears much like a traditional IDE to the user. They can go about and edit the code as normal. When they hit "Compile and Run" then the code is compiled on the server and downloaded to one of the connected Propeller devices.
The Propeller could be connected in whatever way(s) the server can find them, but the easiest would be USB.
The server would be some small ARM system. Parallax could package it up nicely where it is plug and play, and with a case that clearly labels USB ports so that it makes it easy to select the correct Propeller board from the web client. Each classroom would have one server per three or four students. Parallax could make a custom case for whatever ARM board they select:
The overall system is fairly simple, and a competent programmer should be able to come up with something usable and deployable for testing in two months or less. I'm basing this on my experience with Node.js: I started developing an application a month and a half ago, and now it's a fairly advanced tool. Node.js is is dead simple even for somebody with no web programming experience.
The advantages of this system include:
- Easy to build and test for a small company (Parallax!)
- Easy to setup for the customer
- Device agnostic (won't get tied to Apple, Android, Windows...)
- Additional revenue from a "Classroom package"
You could have this system up and running in a classroom by January for testing, and production ready by school year 2014-2015
Some challenges that I forsee:
- What to do with the files (where to store them?)
- How to compile larger, multifile projects?
- How to deal with the restricted networks of schools if the server isn't recognized as a valid network client?
But these are fairly minor questions, and ones that you would have to deal with anyway.
Very nice description. I think this would be a good approach. Notice also that there is nothing in this approach that would prevent a native iOS app to be constructed to talk to the same server. If Parallax has a need for something a bit more polished than what is possible with a web-based app, that would fit into this approach as well. The nice thing about this is that you can build the server and the web-based apps first and they work on any web-enabled client. Then you can go on as a second step to build an iOS and/or Android native app if that promised to have some advantage for those platforms.
The nice thing about this is that you can build the server and the web-based apps first and they work on any web-enabled client. Then you can go on as a second step to build an iOS and/or Android native app if that promised to have some advantage for those platforms.
Agreed. One native app that could help students grasp things, is a Good Simulator.
Comments
David, I was just teasing with everyone. The web interface/raspi/cloud/hosted solution has been brought up before and after me.
This really an interesting thread there are a number of solutions to be investigated and pursued and as usual, the forum collective brain storm is up to a full gale on this problem!
It's really true, Rick. Almost every possible solution has been brought up in this thread and for this crowd-sourcing set of ideas we are really thankful. Parallax has the best customers of any company, in case anybody wondered.
Our initial objectives are as follows:
(a) Outline a comparison of the various alternatives to meeting a full program/download goal (identify hardware, pros, cons, etc.)
(b) Meet with key developer relations people from Apple to further narrow our possibilities from a larger comparison. Are we chasing a rabbit through the forest, or down a hole with our preferred alternative(s)? We have two key contacts.
(c) Write a specification for what we would like to achieve.
(d) Put it out for development review and quoting. I'm not ruling out anything here in terms of development team - PropGCC and the related tools were built by people on these forums, yet we know we will need some specific expertise with iPad depending on the choice of what we want to do. Would need to determine costs and benefits at this point, more closely than currently known.
If anybody thinks there's a better way to go about it, please share.
/me still looking for that old Parallax ad with the dog....
I have this remote control ball thing (Sphero) that works with iPad and iPhone and Android. You can control it and send it updates over Bluetooth.
So, I'm pretty sure this would be the ideal solution.
June07_Propeller_NV_lg.jpg
Ray, with the idea you suggest I could imagine a GUI (like the S2) that sends configuration commands to an ActivityBot running a SIDE-loaded program, instead of a complete download of a whole Propeller binary file. This is what you suggest, right?
Times are changing, Jeff. I work in two different schools right now and receive input from instructors quite regularly. Many tools have bigger ecosystems around them, code keeps looking more high-level than before, and the operating system of choice is new (and locked down, and limited). To remain viable and productive, Parallax has to listen to these customers and give it an honest consideration. Neither one of us reflect the demographic that we need to reach, so this can be hard to envision.
Maybe you're trying to save my time, which would certainly be considered a productive contribution but we won't know if it's worth the time until we're done exploring possibilities. All I ask is that this thread mostly be used for what I originally suggested: ideas, input, etc. that we can use.
In the end, we all benefit from a successful Parallax. Parallax has $4M into Propeller 2, everything we've ever made. Efforts like this help us will help us achieve that goal.
I think that would be one great thing to have with a robot.
But, Sphero is also able to update it's firmware over the Bluetooth connection.
So, if you can compile your code on the iPad (should be fairly straightforward), then you should be able to program the Parallax robot over Bluetooth as well...
I would agree, and note this is not really a Pi, as much as a Pi-App.
Most class rooms would dedicate a Pi for this task, and then care less what the actual HW was.
Parallax would have to provide the (significant) collection of Pi tools, to allow the WiFi in, to Compile to Prop & Download,
so it becomes a Prop-Pi-Server, but running on generic Pi hardware.
This allows kids to use Apple stuff if they really want to, but avoids the crippling constraints of trying to use only iPads
Apple is very much a Consumer Company, and a somewhat paranoid one at that, best to jump off the Apple as soon as possible, and run the real work, on something (anything!) else.
Not cheap yet, but long term, the single package has real appeal.
Development could be done with separate units, until the price moves mass-market.
A product like that would allow Parallax to sell a pre-loaded card, as a Prop(pi) Server.
All tools needed would be on the SD, and the WiFi link to the iPads is there too.
https://www.realvnc.com/products/ios/
If you can VNC to a Pi running Debian Wheezy & SimplIDE, problem solved-no custom programming necessary and best of all no having to deal with apple.
-dan
Yes, as that is what Ken asked about.
Is that really a Mac/Windows issue ? I'd have expected any command line compiler to have very little to do with the OS, once it got going.
Given newest MACs use intel cores, I would expect speed differences to be more core-defined than OS defined ?
What machine specs did you compare in your tests ?
Unix is extremely lean when it comes to either.
Recent versions of windows are better at this, but there are still significant differences.
I very regularly used to run batch transforms on large data sets consisting of many files. These were process oriented things, not threaded, unless I wanted to code for threads. Simple scrips were stupid easyand could be generated with other scripts and simple programs.
Running these on Windows never ever reached the speeds of IRIX and Linux, despite better specs on the windows machine.
A 400Mhz mips box or 800Mhz P3 running linux could knock the task out faster than a wintel at double those speeds. This was during windows xp, 2K, etc... timeframe. No contest. I was kind of shocked at how good IRIX was, particularly when running a couple of big scripts at the same time on a single core machine. Linux was close, and by now likely equal or better.
That is with reasonably comparable I/O, BTW.
Today, My Mac running at 2 something Ghz i7 and with a slow 3500 RPM disk can compile PropGCC in about 7 to 10 minutes. My windows machine at a higher clock and ssd takes longer. It is an i7 with 3.5Ghz burst mode too.
I suspect the slowness goes right to being process oriented as opposed to threaded.
Another difference comes down to what gets cached and how. IRIX file caching has to be seen to be believed. Insane good. Linux is great now, though I've not really pushed it on the later kernels. It was not up to IRIX back then. Windows isn't so good at this. Never has been. That will impact things that run a lot in ways you don't always think about. Often I will see repeated loads on windows, wher I would not on IRIX, and not as often on Linux.
Lastly, those things remain true on Unix in general even when the RAM is consumed near fully. I can do a Propgcc build on the Mac with a ton of Smile running, and it takes an extra minute or two. No big deal.
Windows craps out when it begins to see less than a GB free. I notice this behavior on large CAD datasets today, and my Mac performs better on them despite half the RAM and a slower disk.
I also see windows perform marginally when all cores are saturated. It just can't schedule like Unixes can. Never has.
When things are nice and roomy, windows will do well. When it is a crunch of some kind, it does not perform as well.
The new win 8 kernel is supposed to be much improved. Too bad about the UI. Haven't tried it yet. Wish I could get that kernel on Win 7...
Mine is a quad core i7, with the hyper threading. Nice CPU. Slow disk though, but Mac OS seems to manage it well enough, I've not seen fit to upgrade it. That same disk on a Windows machine would be painful...
I'm eager to try Macricks, but I want to keep my old Snow Leopard OS for builds of GCC. Maybe I will put a really fast one in there and see how much better Apple has done.
To be really honest, I would move back to Linux / MacOS for this stuff if it were easier to run the windows pnut.exe . The little bit of PropGCC I did on Mac OS was pure joy. Nice UI, real OS, etc... Pretty too.
Right now, the FPGA stuff is on old XP, right along with a ton of Prop things. And that box is an old core duo. Slow as all get out now...
Anyway, native windows tools are threaded, run fast, etc. Anything else comes off as kind of crappy, and of course when you really lean on it, windows isn't optimal.
Thank you Rick! I've been numorous times searching Google/Parallax.com in the attempt to find that...
It seems that computer, tablet, phone, and device industries are moving more toward a generic GUI which is open and operates on interchanging standards. You can see the same trend happening here that happened years ago with the automotive industry. Companies like Microsoft and Apple which set copied the initial standards are finding it harder and harder to stay relevant. If you look at cell phones, it appears to have already happened. The masses don't care what the application is as long as it is cheap! and works mostly like they are used to.
Ken, please don't tie yourself to an expensive, closed system which allows someone else to dictate what you are/are not allowed to do. I can't imagine Apple being compatible with anything more than very limited programming capabilities. Unless their attitude has changed from this example (http://www.tomsguide.com/us/Apple-App-BASIC-Commodore-64,news-4608.html) Happened a while back so who knows.
The future is open. Efforts which embrace a larger audience would certainly pay off..
My crystal ball doesn't seem to show an Apple or Microsoft logo in it, but hey I may have read the instructions for configuring it wrong.
Manomio's C64 app is alive and kicking on iPads and iPhones, today. It includes BASIC and a small number of games on installation with the ability to in-app purchase additional officially licensed games. Sounds like a good deal for C64 enthusiasts and license owners, to me...
The idea of programming Propellers via iPad does not imply allowing iOS executable code to be compiled. I think the stumbling block for many early compiler/interpreter app attempts was in allowing in-app code development for the iOS device itself. Things may have changed and a well-designed, secure app, developed by a company with real skin in the Education game (Parallax) could be the ticket. Many iOS device developers have a good handle on providing their apps on Android devices as well. But, the real revenue-maker is definitely iOS, for app developers.
Parallax has to think about the marketing of such an app as we've discussed. Having a great idea for an app is good, but you need a great marketing plan to get your idea into the hearts and minds of your consumer base. There's no better marketing machine than Apple, at this time, on this planet anyway. It can all change tomorrow, of course, but you really can't say where the future will lead.
dgately
Here we can see a central host wireless server. The students can use their WiFi devices (iPad, Android, laptop) to connect to the server. If the server is internet connected then they can use it like a regular access point, and browse the internet.
The server hosts a Node.js application for the Propeller compilation aspects. A browser based client connects to the server and appears much like a traditional IDE to the user. They can go about and edit the code as normal. When they hit "Compile and Run" then the code is compiled on the server and downloaded to one of the connected Propeller devices.
The Propeller could be connected in whatever way(s) the server can find them, but the easiest would be USB.
The server would be some small ARM system. Parallax could package it up nicely where it is plug and play, and with a case that clearly labels USB ports so that it makes it easy to select the correct Propeller board from the web client. Each classroom would have one server per three or four students. Parallax could make a custom case for whatever ARM board they select:
The overall system is fairly simple, and a competent programmer should be able to come up with something usable and deployable for testing in two months or less. I'm basing this on my experience with Node.js: I started developing an application a month and a half ago, and now it's a fairly advanced tool. Node.js is is dead simple even for somebody with no web programming experience.
The advantages of this system include:
- Easy to build and test for a small company (Parallax!)
- Easy to setup for the customer
- Device agnostic (won't get tied to Apple, Android, Windows...)
- Additional revenue from a "Classroom package"
You could have this system up and running in a classroom by January for testing, and production ready by school year 2014-2015
Some challenges that I forsee:
- What to do with the files (where to store them?)
- How to compile larger, multifile projects?
- How to deal with the restricted networks of schools if the server isn't recognized as a valid network client?
But these are fairly minor questions, and ones that you would have to deal with anyway.
-Phil
Very well put. A picture is worth a thousand words. You have nicely presented what I was clumsily trying to say back in post #78 or so. http://forums.parallax.com/showthread.php/151052-Programming-Propellers-from-iPad?p=1216343&viewfull=1#post1216343
I had envisaged one ARM board, with WIFI, per student, simply because it saves dragging USB or serial cables to the desks or work benches. But one such board could easily serve a whole class as you have drawn it.
Agreed. One native app that could help students grasp things, is a Good Simulator.
Something like this for the Prop (and Prop2) would be wonderful.
Squint and imagine Spin or C code in the example and you'll instantly get the idea..
Jeff