I think that if the Propeller and Parallax are going to support the iPad via a wifi server, the solutiom might as well support wifi programing for all wifi capable pads with the iPad just being a pilot target program.
The computer industry has heavily committed to Pads as the way of the future either in the pure form or as Smart Phones. If it is the platform of choice for newer younger generations, it needs support. Of course, you can't do all and everything out of the gate. People on the internet tend to ask for all they can.
It is up to Parallax to set goals and policy. Someone claimed that Henry Ford said, "If I had given the customer what he wanted, I would have sold him a faster horse."
I pity the teacher when people on the internet start defining 'the classroom'. Many times, a book, a pencil, and some paper achieve a lot more that sophisticated technology.
There is one place where I think I have to conceed that C in COG is a subset of "real C". That is in the support of recursive function calls. The COG C code I have generated uses the normal PASM calling convention, not a call stack, so recursive calls are not possible. I'm nt sure if it's even possible.
So yeah, you got me there:)
COGC when used as a stand-alone COG program will not support recursion or any other stack operations (one function call at a time can be used - two if you're lucky). There are other restrictions such as some special syntax outlined in the wiki.
However, if you give a COGC program sufficient stack, it can be used like any other C program. So, theoretically, recursion is possible.
COGC when used as a stand-alone COG program will not support recursion or any other stack operations (one function call at a time can be used - two if you're lucky). There are other restrictions such as some special syntax outlined in the wiki.
Is this stack use due to the function call, or the parameters ?
ie could using global params within the COG, allow more depths of call, by avoiding param passing ?
Is this stack use due to the function call, or the parameters ?
ie could using global params within the COG, allow more depths of call, by avoiding param passing ?
PropellerGCC is smart enough to use "registers" in place of stack within a small limit. Globals can be used for parameters, but at some point the number of function calls will require a stack.
That thing (Electric Imp) is pretty interesting... However, it is not an SD card and won't work like one. But, it is programmable, which is nice.
The Toshiba FlashAir, on the other hand, is an SD card with wifi. You can't program it though (unless you figure out how to root it).
Hmm, been out for a week, but read most of the new posts.
I would agree with the posters who've made the point that shooting for an iPad solution instead of a more generic cross-platform solution is rather an odd direction to take for Parallax.
Would seem more logical to work on a way to allow any child with access to an iPad, Android table, or Mom/Dad's laptop/desktop the ability to
take part.
If some local school has a technology lab full of iPads, and simply refuse to consider anything else, well I guess thats what volunteers are for.
How about something like this:
Child opens computing device, and goes to a URL provided by teacher, which is a link to some server at Parallax education dept.
He pastes in his program from his home text editor and pushes compile.
The webpage spits back a Go/No Go, with compiler errors.
IF program compiles, he gets a webpage that comes back with COMPILE SUCCESSFUL with his program listing, maybe a .bin attachment which he can save and take to school.
IF program has errors, he fixes as best he can if not at school, or if at school, asks the teacher for help.
THEN resubmits, etc, etc.
Did a Google search for online compiler, and there are a vast number of options available. I can't see how the Prop compiler couldn't be made to made into a CGI or whatever they use now by someone half-competent.
The beauty of this is you wouldn't even need to have the kids make accounts and deal with all the hassles that would entail, school getting parent's permission etc.
Actually, the beauty of this is that it wouldn't be restricted to the more well off iPad owner's kids.
If an assignment or in school work, the child just emails the teacher the assignment or IM's him/her. Or be fancy and have the teacher emailed a copy if you want to set up accounts.
If the school has 1 Prop/BOE, then the teach would just program it each time, or have a Prop/Boe locked down laptop that the kids could program it from.
If the school has 1 Prop/BOE for student, then they might have to queue up, or, get some donated laptop/desktops added to their lab.
I know this is nowhere as sexy as many here would like, but then we're full grown geeks and that how we are.
Kids and teachers, this is about as complex as it should be unless they have a volunteer from Parallax who want's to support them
Cheers.
Oh, the pic below is some adapter I found that supposedly allows you to connect an iPad to a 'computer', not sure what it really allows.
Here we see Gordon Williams showing how it should be done. Ten minutes in he gives a very cool live coding demonstration of creating a simple MCU project with a ping sensor and a servo. All done via a simple terminal app in a browser.
Reminds me that Chip has on occasion expressed the wish that some future Propeller board/chip should be a self hosting development environment. No PC required. Gordon has achieved that with a two dollar MCU and JavaScript.
Seems to me this could all be done on a Prop II board with Spin. The proposed PII dev board from Parallax includes 32MB of SDRAM.
If JavaScript is not your thing why not host the open source spin compiler on the Prop board?
Here we see Gordon Williams showing how it should be done. Ten minutes in he gives a very cool live coding demonstration of creating a simple MCU project with a ping sensor and a servo. All done via a simple terminal app in a browser.
Reminds me that Chip has on occasion expressed the wish that some future Propeller board/chip should be a self hosting development environment. No PC required. Gordon has achieved that with a two dollar MCU and JavaScript.
Seems to me this could all be done on a Prop II board with Spin. The proposed PII dev board from Parallax includes 32MB of SDRAM.
If JavaScript is not your thing why not host the open source spin compiler on the Prop board?
That's quite cool! Can't wait to get my board from the Kickstarter. I wonder how much performance he is giving up by running straight from source code though?
"Quite cool". It's the most coolest thing since Bill Gates put a BASIC interpreter on an 8080. Except that was Smile and this is brilliant:)
From the FAQ,
To give you a rough idea of speed, on the STM32F4 you can turn an IO pin on and off in a simple while loop at around 4kHz.
So we are looking at about 8K simple lines of JS per second.
Sounds awful right?
Thing is it does not matter. If you have software, in C++, and hardware support for PWM and time stamped input pin changes etc then you can do a lot of real-timeish things even if the code that is managing everything is quite slow.
It's the same as I see in some of my server processes. For example one of my processes spends most of its time in an XML library. That library is written in C. So it makes almost zero difference performance wise if my app is written in JS or C++. I was somewhat amazed when I first saw that for real when I wrote a JS equivalent of an old C++ process.
So we can imagine that if there were some common thing that needed more speed, someone would provide a C++ module to do that.
Or we can see it as similar to the use of byte code interpreted Spin on the Prop. It's OK to be slow, the PASM is doing the heavy lifting.
So, what about making Chip's dream come true and getting openspin running on the P2 (or even P1)?
The editor seems to be the biggest problem here.
Back in the good old days of BASIC that was solved by having line numbers and an editor that worked on one line at a time, by number.
JS solves this problem a bit by enabling one to redefine functions by name on the fly.
Did you notice that the code that is being edited is also running at the same time!
Remember the bad old days (before micros) the minis and mainframes of the day only had small amounts of core memory. The Friden/Singer/ICL mini that I worked on (I bought an 18mth old second hand one that was max memory config in 1977) only had a max memory of 110KB (where B was a 6-bit subset of ASCII). A processor core had 10KB max private memory (equivalent to cog memory) and a max of 80KB of common/shared memory (equivalent to hub memory) but was typically 10KB in the early days.
The assembler used the disc drives (10MB ea) to do the compilation and took hours. We have come a long way since then.
I just point this out because we can have an SD based compiler that would run on the P1 using these methods. While it may be slow, in many cases who cares. We have many of these bits to the puzzle already solved.
So we have as options...
1. iPad/Android/Laptop/PC can edit a file
2. iPad/Android/Laptop/PC can go online and submit a file for compilation (any language) to a server hosted in the cloud (Parallax or school)
3. We only need to solve how to get the binary (or script?) to the P1 cheaply
BTW It won't work if the kids who do their work at home cannot test if they have the required equipment. No use compiling at home then waiting to test at school - they are too impatient these days.
Sorry, but the problem that needs to be solved is point 3. The rest will fall into place. How about some discussion on this instead of language discussions or the pros and cons of iPad. The iPad is here to stay and there are a lot of valid reasons why schools (and many businesses including hospitals) are going this way - many because of the fact the iPad is locked down. Apple controls what software can run so viruses are being restricted on these devices.
Thing is it does not matter. If you have software, in C++, and hardware support for PWM and time stamped input pin changes etc then you can do a lot of real-timeish things even if the code that is managing everything is quite slow.
Maybe this speed is tolerable in an early educational setting, where the priority is on capturing a students interest, over doing anything real-world.
However, notice you have to jump languages to get real work done, which rather undermines the whole idea of starting in .js
(and this is not actually running on a Prop...)
Full Debug now requires cross-language testing, and the quick-start fades rather quickly.
Sorry, but the problem that needs to be solved is point 3.
Yes, quite so. I carfully ignored the communication problem in my post about Epruino:)
Thing is, it's the same communication problem if you compile on the target and just have a terminal in the web page or compile on a server and have to send the binary to the target.
It's an artificial problem caused by modern tablets that should not exist at all.
How about some discussion on this instead of language discussions
I agree. My point in introducing that video was not to say we should adopt JS for the Propeller. Rather it was just to point out a very good example of what the final user experience could be like, I'm just guessing that the educators in question on this thread have something like that in mind even if they can't express it so clearly yet.
...or the pros and cons of iPad. The iPad is here to stay...
You mean like how Windows and the PC is here to stay. Wait a minute, the whole point of this thread is that no one want's that any more, they want tablets...
Which reminds us that any solution should be open standards based and cross-platform.
jmg,
Maybe this speed is tolerable in an early educational setting, where the priority is on capturing a students interest, over doing anything real-world.
Again I say my point was not about JS per se but just the shear beauty of that interface.
Anyway, I had the impression that "early educational setting" is exactly what we are talking about on this thread. Else why are we even discussing developing with an iPad?
...notice you have to jump languages to get real work done, which rather undermines the whole idea of starting in .js
If performance is an issue for that "real work" then that is true of the Propeller and Spin. Want to go fast? Better learn PASM.
I agree. My point in introducing that video was not to say we should adopt JS for the Propeller. Rather it was just to point out a very good example of what the final user experience could be like, I'm just guessing that the educators in question on this thread have something like that in mind even if they can't express it so clearly yet.
I find it interesting that you consider the user interface to be "good" in that video. As I saw it, it was just a command line interface. We can do that with FemtoBASIC as well as that interactive BASIC that Bean wrote (sorry, I forget its name) and my little xbasic. I was under the impression that some sort of IDE was going to be needed for an on-target development environment to be acceptable to people these days.
"Back in the day," a 16K byte 8-bit processor (8080 ancestor ... Datapoint 2200) was more than adequate for software development in assembly language or Basic-like interpretive language, particularly once a small disk drive (1MB) was added. Obviously, you needed some kind of console, but an iPad could certainly serve for that, particularly with a Bluetooth keyboard that would be transparent to the Propeller board. A Propeller Activity Board with a WiFi module and SD card would work as would other configurations. A console link could even be done using the headphone jack with the HiJack protocol since the data rates are low.
I'm still puzzling over your statement about "getting real work done".
Back in the days when MS BASIC ruled the world of 8 bit micros I thought it was mind bendingly stupid. It was a really crude and amazingly slow way of getting anything done. I mean, I could write in assembler, or if I was lazy PL/M.
Of course that was disregarding the fact that I had assemblers and compilers and the dev systems to run them on. at 10,000 dollars a piece, thanks to my educational institution or work place. I could set up and handle interrupts with ease and talk to UART registers and such in my sleep. Whereas MS BASIC ran the editor and run time in a hand full of kilobytes on the target itself, millions of people could get "real work" done with that. How else did MS get where it is?
If you check that video the "real work" (in a real-time MCU sense) is accurate timing of a ping sensor and PWM for a servo.
Or is the "real work" showing something about programming and how to open a rubbish bin with a proximity sensor?
I was under the impression that some sort of IDE was going to be needed for an on-target development environment to be acceptable to people these days.
It is for more serious work, but there is a very wide range of educational use, and the Quick Demo Script has a place.
It is what comes next, for the more able/serious students, that is a little harder to nail down.
The ideal IDE to me, includes a simulator, but that is some ways off....
Meanwhile, the Borland Model, from the first Turbo Pascal is not a bad one to reality-check against - I found this
["Turbo Pascal packs an editor, compiler, linker, and run-time library into just 39K bytes of random access memory"]
and this
["The review stated that the IDE that simplified the edit-compile-run-debug loop made Turbo Pascal accessible to new programmers like BASIC"]
It is for more serious work, but there is a very wide range of educational use, and the Quick Demo Script has a place.
It is what comes next, for the more able/serious students, that is a little harder to nail down.
The ideal IDE to me, includes a simulator, but that is some ways off....
Meanwhile, the Borland Model, from the first Turbo Pascal is not a bad one to reality-check against - I found this
["Turbo Pascal packs an editor, compiler, linker, and run-time library into just 39K bytes of random access memory"]
and this
["The review stated that the IDE that simplified the edit-compile-run-debug loop made Turbo Pascal accessible to new programmers like BASIC"]
Turbo Pascal was written in assembly language. I guess that isn't really a problem since we have Chip around! He wrote the Spin compiler in x86 assembly language. I'm sure he could write one in PASM. :-)
Or is the "real work" showing something about programming and how to open a rubbish bin with a proximity sensor?
Yes, it works fine at the early education level, as I mentioned already.
What comes next is harder to manage, if you have to split languages and development flows.
I think that the enviroment that Heater's video shows has many of the advantages people claim for Forth but with a more user-friendly language. You get to build things incrementally as he did in the video and test them as you go rather than making a monolithic program and testing it all at once. I don't see why you couldn't use a similar approach for more complex programs although you'd want a way to include already debugged library code as well as the code you're developing from scratch. If I were going to do something like this on the Propeller I'd include the ability to store code on an SD card as well as in flash memory. I suppose he didn't want to do that because it meant that any board he was using would need an SD card slot and not every production board will want one.
This is partially solved. Blinking lights, serial output to some terminal, etc... But the holy grail is that "run it and fire off the terminal to get a console back" function; otherwise, agreed!
@Heater: Want to go fast? Better learn PASM
Yes! Students will do this and PASM is not all that difficult. The one I am mentoring is writing some good PASM now. Didn't take long. The big hurdle was figuring out how to represent things and the other big one was how to debug without a step by step simulation or some other tool. Some interactive sessions where I would start working on broken code chattering about it all were effective and that led to the idea of thinking about the code clearly before just writing it so that the debugging steps and tests are there in one's mind.
Didn't most of us learn on much slower things? I got started on machines that could do 10-100 instructions per second. BASIC. Moving to 6502 assembly language didn't take long and the motivation was there along with basic tools; namely, a monitor, line assembler, and the outputs of the machine.
After reading through this thread, perhaps Chip is not so off track as we think for wanting on-chip development. Hmmm... Soon, P2 chips can host little cheap things that can very easily program P1 chips, right along with P2 chips. That can and will be done with just serial, or a nice editor / environment too. P2 chips will do that nicely enough from what we've seen so far.
I've also come to understand the interest in using things like phones. Young people are coming up in a time where the PC isn't a given. I really didn't understand that before now. Good discussion everybody.
I find it interesting that you consider the user interface to be "good" in that video. As I saw it, it was just a command line interface. We can do that with FemtoBASIC as well as that interactive BASIC that Bean wrote (sorry, I forget its name) and my little xbasic. I was under the impression that some sort of IDE was going to be needed for an on-target development environment to be acceptable.
Yep, it's just a command line interface.
Here is the beauty of it:
1) Type in a definition of a simple function. Call it "f".
2) Set that running at at regular intervals, say 1000ms:
setInterval (f, 1000);
Now f is running and doing whatever it does.
3) Define another function, call it "g"
4) Set that running as above for f above
Note: Whilst you were creating the function "g" the function "f" was running all the time.
Hmm...this does not do quite what I want. OK redefine "f". Boom, the running program's behavior changes.
I think that is really neat.
You cannot do that with programs developed in an IDE with the normal "edit, compile, download, oops it does not work" development cycle. I'm sure any kind of BASIC has an "edit" mode and a "run" mode.
IDE's and compiled languages etc are great for big projects. For an educational starter with direct feed back they are crappy. There is too much stuff in the way. The Forth guys will tell you that.
Yes! Students will do this and PASM is not all that difficult.
I agree. PASM is about the simplest assembler language I have ever seen and very easy to use thanks to how well it is integrated into Spin language and tools.
Didn't most of us learn on much slower things?
Yep. I don't think speed is the issue when you are reaching out to beginners trying to get them enthused about programming and computing in general. Many of us started out with:
10 PRINT "HELLO"
20 GOTO 10
How fast did that run? But it did the trick, it showed you could have control of the machine.
The move to assembler comes later when you hit the speed barrier, but by then you at least know what a program is (sequence, selection, iteration), what data is and why you want to go faster.
Young people are coming up in a time where the PC isn't a given.
1) Type in a definition of a simple function. Call it "f".
2) Set that running at at regular intervals, say 1000ms:
setInterval (f, 1000);
Now f is running and doing whatever it does.
3) Define another function, call it "g"
4) Set that running as above for f above
Note: Whilst you were creating the function "g" the function "f" was running all the time.
Hmm...this does not do quite what I want. OK redefine "f". Boom, the running program's behavior changes.
I think that is really neat.
You cannot do that with programs developed in an IDE with the normal "edit, compile, download, oops it does not work" development cycle. I'm sure any kind of BASIC has an "edit" mode and a "run" mode.
IDE's and compiled languages etc are great for big projects. For an educational starter with direct feed back they are crappy. There is too much stuff in the way. The Forth guys will tell you that.
The reason that works is that I imagine he doesn't even parse the function that you're entering until you type the closing brace and maybe not until you type <ENTER> after that. So, the code you're editing is probably not the code that is running. I don't think you'd even want that because you could change one line of the function in a way that breaks the remaining line. In other words, any multi-line edit would cause trouble if the code were continually running. Of course, I don't KNOW that is what he's doing but that's what I'm guessing. That's the way I did it in my Bob interpreter although that compiled to bytecodes.
The reason it works is that JS has "first class functions". That is to say a function is a variable like any other and can be treated as such.
It should surprise no one that a command line system could accept:
a = 2
and then
a = 3.
Fine, "a" was 2 and then it was 3.
In JS we can write:
function f() { return 2 }
then:
function f() { return 3 }
in the same way. First "f" was one thing, then it was another. We are not editing code line by line but simply redefining functions as a whole. Rather like you might do in Lisp or Scheme. Or Forth for that matter.
So yes, the redefinition does not happen until the new definition is complete and correct.
Now couple that with JavaScript's even loop and it becomes easy to have the editor and the program being edited both running at the same time.
in the same way. First "f" was one thing, then it was another. We are not editing code line by line but simply redefining functions as a whole. Rather like you might do in Lisp or Scheme. Or Forth for that matter.
So yes, the redefinition does not happen until the new definition is complete and correct.
Isn't that what I said. The new function isn't parsed or used until the final brace is entered. My point is that the function code you're currently editing isn't what is being executed. It's the old version of the function that is executing until after you finish your edit.
What about something like Carl Gundel's RunBasic? (runbasic.com) You can set up your own RunBasic web server, (Even on a Raspberry PI!), Develop and test your program, and then serve it up.
Could maybe Brad's Spin Tool be made to operate through a web server interface this way? With maybe a 'web' serial terminal for the 'serve it up' part?
Something like this running on a Raspberry Pi or BeagleBone or something like that could easily then load a Prop in the usual way. Neatly gets around the 'no programming' rules
I've even seen a project to make a Pi into a USB over IP server, which could solve he connection problem if the IDE were on the Ipad too..
BST is out of the picture as it is closed source and unsupported now.
But yes your general ideas are sound.
Only we have not even figured out the most efficient, cost effective, communication path from tablet to server to Propeller powered robot yet.
David,
Yep.
I didn't know BST was dead. I guess I've been WAAAAY out of the loop.
I don't have a great deal of time to spend on it, but this idea just won't go away. I may just have to do something about it... on another thread, since it doesn't fully satisfy THIS problem...
Comments
The computer industry has heavily committed to Pads as the way of the future either in the pure form or as Smart Phones. If it is the platform of choice for newer younger generations, it needs support. Of course, you can't do all and everything out of the gate. People on the internet tend to ask for all they can.
It is up to Parallax to set goals and policy. Someone claimed that Henry Ford said, "If I had given the customer what he wanted, I would have sold him a faster horse."
I pity the teacher when people on the internet start defining 'the classroom'. Many times, a book, a pencil, and some paper achieve a lot more that sophisticated technology.
However, if you give a COGC program sufficient stack, it can be used like any other C program. So, theoretically, recursion is possible.
Is this stack use due to the function call, or the parameters ?
ie could using global params within the COG, allow more depths of call, by avoiding param passing ?
PropellerGCC is smart enough to use "registers" in place of stack within a small limit. Globals can be used for parameters, but at some point the number of function calls will require a stack.
https://www.sparkfun.com/products/11395
its a wifi SD card. It would not be iPad per se, but could be a browser access to the prop. Kind of a stretch, but might start some ideas.
The Toshiba FlashAir, on the other hand, is an SD card with wifi. You can't program it though (unless you figure out how to root it).
I would agree with the posters who've made the point that shooting for an iPad solution instead of a more generic cross-platform solution is rather an odd direction to take for Parallax.
Would seem more logical to work on a way to allow any child with access to an iPad, Android table, or Mom/Dad's laptop/desktop the ability to
take part.
If some local school has a technology lab full of iPads, and simply refuse to consider anything else, well I guess thats what volunteers are for.
How about something like this:
Child opens computing device, and goes to a URL provided by teacher, which is a link to some server at Parallax education dept.
He pastes in his program from his home text editor and pushes compile.
The webpage spits back a Go/No Go, with compiler errors.
IF program compiles, he gets a webpage that comes back with COMPILE SUCCESSFUL with his program listing, maybe a .bin attachment which he can save and take to school.
IF program has errors, he fixes as best he can if not at school, or if at school, asks the teacher for help.
THEN resubmits, etc, etc.
Did a Google search for online compiler, and there are a vast number of options available. I can't see how the Prop compiler couldn't be made to made into a CGI or whatever they use now by someone half-competent.
The beauty of this is you wouldn't even need to have the kids make accounts and deal with all the hassles that would entail, school getting parent's permission etc.
Actually, the beauty of this is that it wouldn't be restricted to the more well off iPad owner's kids.
If an assignment or in school work, the child just emails the teacher the assignment or IM's him/her. Or be fancy and have the teacher emailed a copy if you want to set up accounts.
If the school has 1 Prop/BOE, then the teach would just program it each time, or have a Prop/Boe locked down laptop that the kids could program it from.
If the school has 1 Prop/BOE for student, then they might have to queue up, or, get some donated laptop/desktops added to their lab.
I know this is nowhere as sexy as many here would like, but then we're full grown geeks and that how we are.
Kids and teachers, this is about as complex as it should be unless they have a volunteer from Parallax who want's to support them
Cheers.
Oh, the pic below is some adapter I found that supposedly allows you to connect an iPad to a 'computer', not sure what it really allows.
I urge Ken and all Parallaxians to watch this video. https://www.youtube.com/watch?v=lrJJQ1uW3lA
Here we see Gordon Williams showing how it should be done. Ten minutes in he gives a very cool live coding demonstration of creating a simple MCU project with a ping sensor and a servo. All done via a simple terminal app in a browser.
Reminds me that Chip has on occasion expressed the wish that some future Propeller board/chip should be a self hosting development environment. No PC required. Gordon has achieved that with a two dollar MCU and JavaScript.
Seems to me this could all be done on a Prop II board with Spin. The proposed PII dev board from Parallax includes 32MB of SDRAM.
If JavaScript is not your thing why not host the open source spin compiler on the Prop board?
"Quite cool". It's the most coolest thing since Bill Gates put a BASIC interpreter on an 8080. Except that was Smile and this is brilliant:)
From the FAQ,
So we are looking at about 8K simple lines of JS per second.
Sounds awful right?
Thing is it does not matter. If you have software, in C++, and hardware support for PWM and time stamped input pin changes etc then you can do a lot of real-timeish things even if the code that is managing everything is quite slow.
It's the same as I see in some of my server processes. For example one of my processes spends most of its time in an XML library. That library is written in C. So it makes almost zero difference performance wise if my app is written in JS or C++. I was somewhat amazed when I first saw that for real when I wrote a JS equivalent of an old C++ process.
So we can imagine that if there were some common thing that needed more speed, someone would provide a C++ module to do that.
Or we can see it as similar to the use of byte code interpreted Spin on the Prop. It's OK to be slow, the PASM is doing the heavy lifting.
So, what about making Chip's dream come true and getting openspin running on the P2 (or even P1)?
The editor seems to be the biggest problem here.
Back in the good old days of BASIC that was solved by having line numbers and an editor that worked on one line at a time, by number.
JS solves this problem a bit by enabling one to redefine functions by name on the fly.
Did you notice that the code that is being edited is also running at the same time!
Remember the bad old days (before micros) the minis and mainframes of the day only had small amounts of core memory. The Friden/Singer/ICL mini that I worked on (I bought an 18mth old second hand one that was max memory config in 1977) only had a max memory of 110KB (where B was a 6-bit subset of ASCII). A processor core had 10KB max private memory (equivalent to cog memory) and a max of 80KB of common/shared memory (equivalent to hub memory) but was typically 10KB in the early days.
The assembler used the disc drives (10MB ea) to do the compilation and took hours. We have come a long way since then.
I just point this out because we can have an SD based compiler that would run on the P1 using these methods. While it may be slow, in many cases who cares. We have many of these bits to the puzzle already solved.
So we have as options...
1. iPad/Android/Laptop/PC can edit a file
2. iPad/Android/Laptop/PC can go online and submit a file for compilation (any language) to a server hosted in the cloud (Parallax or school)
3. We only need to solve how to get the binary (or script?) to the P1 cheaply
BTW It won't work if the kids who do their work at home cannot test if they have the required equipment. No use compiling at home then waiting to test at school - they are too impatient these days.
Sorry, but the problem that needs to be solved is point 3. The rest will fall into place. How about some discussion on this instead of language discussions or the pros and cons of iPad. The iPad is here to stay and there are a lot of valid reasons why schools (and many businesses including hospitals) are going this way - many because of the fact the iPad is locked down. Apple controls what software can run so viruses are being restricted on these devices.
Yes
Maybe this speed is tolerable in an early educational setting, where the priority is on capturing a students interest, over doing anything real-world.
However, notice you have to jump languages to get real work done, which rather undermines the whole idea of starting in .js
(and this is not actually running on a Prop...)
Full Debug now requires cross-language testing, and the quick-start fades rather quickly.
Thing is, it's the same communication problem if you compile on the target and just have a terminal in the web page or compile on a server and have to send the binary to the target.
It's an artificial problem caused by modern tablets that should not exist at all. I agree. My point in introducing that video was not to say we should adopt JS for the Propeller. Rather it was just to point out a very good example of what the final user experience could be like, I'm just guessing that the educators in question on this thread have something like that in mind even if they can't express it so clearly yet. You mean like how Windows and the PC is here to stay. Wait a minute, the whole point of this thread is that no one want's that any more, they want tablets...
Which reminds us that any solution should be open standards based and cross-platform.
jmg, Again I say my point was not about JS per se but just the shear beauty of that interface.
Anyway, I had the impression that "early educational setting" is exactly what we are talking about on this thread. Else why are we even discussing developing with an iPad? If performance is an issue for that "real work" then that is true of the Propeller and Spin. Want to go fast? Better learn PASM.
I'm still puzzling over your statement about "getting real work done".
Back in the days when MS BASIC ruled the world of 8 bit micros I thought it was mind bendingly stupid. It was a really crude and amazingly slow way of getting anything done. I mean, I could write in assembler, or if I was lazy PL/M.
Of course that was disregarding the fact that I had assemblers and compilers and the dev systems to run them on. at 10,000 dollars a piece, thanks to my educational institution or work place. I could set up and handle interrupts with ease and talk to UART registers and such in my sleep. Whereas MS BASIC ran the editor and run time in a hand full of kilobytes on the target itself, millions of people could get "real work" done with that. How else did MS get where it is?
If you check that video the "real work" (in a real-time MCU sense) is accurate timing of a ping sensor and PWM for a servo.
Or is the "real work" showing something about programming and how to open a rubbish bin with a proximity sensor?
Either way it works very well.
It is for more serious work, but there is a very wide range of educational use, and the Quick Demo Script has a place.
It is what comes next, for the more able/serious students, that is a little harder to nail down.
The ideal IDE to me, includes a simulator, but that is some ways off....
Meanwhile, the Borland Model, from the first Turbo Pascal is not a bad one to reality-check against - I found this
["Turbo Pascal packs an editor, compiler, linker, and run-time library into just 39K bytes of random access memory"]
and this
["The review stated that the IDE that simplified the edit-compile-run-debug loop made Turbo Pascal accessible to new programmers like BASIC"]
Yes, it works fine at the early education level, as I mentioned already.
What comes next is harder to manage, if you have to split languages and development flows.
4. Getting output back to the student.
This is partially solved. Blinking lights, serial output to some terminal, etc... But the holy grail is that "run it and fire off the terminal to get a console back" function; otherwise, agreed!
@Heater: Want to go fast? Better learn PASM
Yes! Students will do this and PASM is not all that difficult. The one I am mentoring is writing some good PASM now. Didn't take long. The big hurdle was figuring out how to represent things and the other big one was how to debug without a step by step simulation or some other tool. Some interactive sessions where I would start working on broken code chattering about it all were effective and that led to the idea of thinking about the code clearly before just writing it so that the debugging steps and tests are there in one's mind.
Didn't most of us learn on much slower things? I got started on machines that could do 10-100 instructions per second. BASIC. Moving to 6502 assembly language didn't take long and the motivation was there along with basic tools; namely, a monitor, line assembler, and the outputs of the machine.
After reading through this thread, perhaps Chip is not so off track as we think for wanting on-chip development. Hmmm... Soon, P2 chips can host little cheap things that can very easily program P1 chips, right along with P2 chips. That can and will be done with just serial, or a nice editor / environment too. P2 chips will do that nicely enough from what we've seen so far.
I've also come to understand the interest in using things like phones. Young people are coming up in a time where the PC isn't a given. I really didn't understand that before now. Good discussion everybody.
Here is the beauty of it:
1) Type in a definition of a simple function. Call it "f".
2) Set that running at at regular intervals, say 1000ms: Now f is running and doing whatever it does.
3) Define another function, call it "g"
4) Set that running as above for f above
Note: Whilst you were creating the function "g" the function "f" was running all the time.
Hmm...this does not do quite what I want. OK redefine "f". Boom, the running program's behavior changes.
I think that is really neat.
You cannot do that with programs developed in an IDE with the normal "edit, compile, download, oops it does not work" development cycle. I'm sure any kind of BASIC has an "edit" mode and a "run" mode.
IDE's and compiled languages etc are great for big projects. For an educational starter with direct feed back they are crappy. There is too much stuff in the way. The Forth guys will tell you that.
The move to assembler comes later when you hit the speed barrier, but by then you at least know what a program is (sequence, selection, iteration), what data is and why you want to go faster. Oh yeah, the PC is a dinosaur already.
The reason it works is that JS has "first class functions". That is to say a function is a variable like any other and can be treated as such.
It should surprise no one that a command line system could accept:
a = 2
and then
a = 3.
Fine, "a" was 2 and then it was 3.
In JS we can write:
function f() { return 2 }
then:
function f() { return 3 }
in the same way. First "f" was one thing, then it was another. We are not editing code line by line but simply redefining functions as a whole. Rather like you might do in Lisp or Scheme. Or Forth for that matter.
So yes, the redefinition does not happen until the new definition is complete and correct.
Now couple that with JavaScript's even loop and it becomes easy to have the editor and the program being edited both running at the same time.
Could maybe Brad's Spin Tool be made to operate through a web server interface this way? With maybe a 'web' serial terminal for the 'serve it up' part?
Something like this running on a Raspberry Pi or BeagleBone or something like that could easily then load a Prop in the usual way. Neatly gets around the 'no programming' rules
I've even seen a project to make a Pi into a USB over IP server, which could solve he connection problem if the IDE were on the Ipad too..
BST is out of the picture as it is closed source and unsupported now.
But yes your general ideas are sound.
Only we have not even figured out the most efficient, cost effective, communication path from tablet to server to Propeller powered robot yet.
David,
Yep.
I didn't know BST was dead. I guess I've been WAAAAY out of the loop.
I don't have a great deal of time to spend on it, but this idea just won't go away. I may just have to do something about it... on another thread, since it doesn't fully satisfy THIS problem...