"Apparently you are right. I cannot account for it. My conclusion is these guys don't want to teach the binary and hex and assembler and real-time concerns of the low level of the embedded or even "normal" computing world. But they want to use a tiny MCU. They are very confused"
They are, considering the old guard they are so impressed with came up learning assembler, hex, binary and digital logic. The fundamentals as it were. And most learned not in a class setting but at home. Now they want the kiddies to use a language that hides everything, effectively turning the hardware back into a black box. Not smart, not conducive to producing the next Wozniak, May or Sinclair.
The micropython port to the esp8266 WiFi modules is making progress.
WiFi is said to be at least kind of running but the esp8266 specific gpios are not supported yet...
Optimistic view: Within some weeks :-) or months :-( we'll have a $3 python coprocessor with WiFi abilities for the propeller...
Interesting progress, and & interesting part - NOT an ARM it seems....
* Core is a 106micro Diamond Standard core (LX3) made by Tensilica
32b with 24b/16b opcodes
* Running at 80MHz
* 64KBytes of instruction RAM
* 96KBytes of data RAM
* 64KBytes boot ROM
* Winbond W25Q40BVNIG SPI flash
Compared with the larger 2015 ARM MCUs, that is modest resource set, but the price point is also compelling.
That smaller resource set would make it more 'not python'
"..they could instead grab a 2015 large 'MCU', (eg 2MBF.512KR, 200MHz) which can run MicroPython, and present that to their customer base, solving two problems at once."
They could...I suspect Chip would have something to say about that.
Why ?
The Parallax culture has already changed. Did you note how many external software consultants Ken now manages ?
Such is the nature of the modern world, software matters more than hardware, and Parallax are a module and software and Education support company, more than a chip company.
If Parallax do not deliver the solution their own customers are asking for, those customers will likely find it somewhere else.
Seems there are choices out there already, and improving..
Weeeelll, that's rather a stretch, as I include proper source editing in the development loop.
I can agree with that. But the Python language system, or C or any other is not an IDE or even an editor. There is a spearation of concerns, the compilers/interpreters, the editors, the IDEs. It just so happens that due to the interpretted nature of Python, JS, Perl, Scheme, Forth, etc they can throw in a convenient REPL almost for free.
The request for Python on the Prop has not included a full up IDE on the Prop as well has it? !
Command line 'interactive' is not quite the interactive modern student expect.
They certainly expect a syntax highlighting editor, that has other smarts like find declaration.
I wonder, does a kid who has never programmed before expect anything like that? They don't even know what "syntax" is, or a declaration etc.
Why ?
I don't know, it my "gut feeling" again. Something about the 4 million dollars sunk into the P2 development so far....
And you notice that development stopped a long time ago on the BS2 and a successor never appeared even though it's 20 years old now.
It's not to say it wasn't a big seller, it was with 3 million sold. But most companies continually improve their product lines to entice more customers, etc. Parallax never did with the BS2 according to some because of Scenix-Microchip lawsuit.
Command line 'interactive' is not quite the interactive modern student expect.
Why would they not expect this? It's not like they are going to enter industry in a vacuum. The various modes of development, ALL OF THEM, are relevant and significant to their overall education and personal development.
I would think those students expect education that results in a meaningful improvement in their ability to participate and advance in the industry. What they want and what they need won't always align, and that's fine. Everybody expect to have to work some, and understanding these things is just part of the work.
Command line interactive is an extremely useful thing to understand. So is using an IDE, as well as command line compiled.
Here's a similar scenario. I've taught Mechanical CAD for years. I'm really good at it, and I've ran and taught on most of the systems you can name out there. That training can sometimes bill out at $2K / DAY. (no joke, and it's a good gig when one can get it, but the work is often HARD)
How to get those rates?
Make damn sure that education is meaningful. And that means dragging them through some stuff and being there the whole time to make sure they get the understanding they need to be successful. And hear some rants. Good for the soul. Get it out, then get to work is how I've always played it.
It has been really interesting to see this last generation go through the process. They really do want to optimize toward the easy stuff. I have a hard time in the class sometimes. But I do make them do the harder stuff, and I make sure they know why and that it's OK to grumble the whole way through. I'll even buy drinks, if needed to get through it, but they get through it.
The older guard has always seen it for what it is and there is less friction there. Industry is messy and they know it. So they dig in and get what they need to be successful in the work they choose to do.
I get a lot of referrals. I get 'em, because people got what they needed, not always what they wanted. The same thing was done for me in my 20's several times. Loved those educators / instructors and trainers. Loved 'em because I was successful, and they were a part of that.
There are some boundaries to be defined here.
Higher education / University / academic - This may not always be realistic education for industry. It's value is largely up to the students who see it and exploit it. Industry expectations may well differ considerably from academic norms. This is OK, not a negative statement. Just a statement.
For profit / niche / job type training -- this is more frequently realistic when it's targeted for industry. In fact, the primary differentiators is the targeting and expectations associated with that. A secondary differentiator is skills based education being more of a focus than theory or higher level things in general. Less time, more focus, specific goals.
Hobby / club - all over the map.
Primary Education - Like any other subject, this is focused on literacy, basic skills, learn how to learn, exposure to material, etc... High school and grade school are what I'm talking about here. (US)
I think we really do need to understand something about these requests for context. Some of this discussion is "better than" type discussion, and "better than" isn't always relevant. Other parts of this discussion carries assumptions about the type of education, and those color the answers as should be, but the important thing missed is there does not always need to be a resolution. More than one scenario may well be acceptable, and the idea of serving all of them might not be possible, practical, viable too.
Getting back to student expectations... yeah, they have them. That's not necessarily the point.
What the vast majority of them are going to find is they need to be able to jump in on the tools, systems, processes and standards in use where they end up. That is the "work" part of "work" and it's not always fun, or what we prefer.
Those CAD students get dropped into scenarios with all sorts of tools other than the ones they love to use. And it's expensive to change up, so they get told to use the tool, or seek other employment. Which is why good training means taking them a few places they don't want to go, but might need to have gone to make the best of the opportunities they encounter later on.
So, what kind of education requests are these? It matters for the discussion, IMHO.
Why would they not expect this? It's not like they are going to enter industry in a vacuum. The various modes of development, ALL OF THEM, are relevant and significant to their overall education and personal development.
I would think those students expect education that results in a meaningful improvement in their ability to participate and advance in the industry.
I think you missed the point. Can you point to any mainstream MCU company offering only a command line debug. ( or even find some that bother to include command line debug ?? )
Nope, it is all JTAG/2W/1W links, to host Debuggers, that is what they will find in their jobs.
Heck, I have 21c micros here, with HW Debug, & the esp8266 above mentioned HW Debug.
I think what you are trying to refer to, used to be called a Monitor Program, and I've not used one in decades.
Of course, I've not left the low level behind either, I still paste hex strings into terminals to test, and I would certainly expect modern MCU students to be able to do that.
but I would also expect them to know good Editing, documentation, and Version control, and I can't see bashing away on a terminal getting much time anywhere, not in 2015.
Command line 'interactive' is not quite the interactive modern student expect.
They certainly expect a syntax highlighting editor, that has other smarts like find declaration.
I wonder, does a kid who has never programmed before expect anything like that? They don't even know what "syntax" is, or a declaration etc.
Err, that rather proves my point. The fastest way to learn what "syntax" is, or a declaration etc, is to use a good editor & a loaded code example, with a "Change this to ..." worksheet.
Decent frameworks are free, no reason or excuse not to use them.
Editors keep getting better at this stuff, and it is the sort of thing a PC CPU should be used for.
I am referring to a command line interface to the whole works. Understanding it is a basic element of literacy. It may be a practice, or may not, depending on where they go and who they are.
This is why knowing something about the requests is a good idea.
Heck, I'm currently learning about injection mold tooling. It is tough, and there are some basic points of literacy, just like a command line, that are proving very worth knowing, even though high end and modern tools are in regular use.
Another recent example was a CNC mill. Start by direct machine input, manual tool offsets, facing, insuring square, etc... then move up to a basic editor, then DNC, then advanced and highly automated software.
We had to go old school a week ago, due to some manufacturing requirement and specialized tool. Didn't miss a beat, and because I had that literacy from the 90's, it was no problem.
There seems to be a conflating of the desire to be rid of basic means, and their relevance.
Where consumer product design is in play, the trent toward new is understandable and expected. Industrial automation is a different beast, all over the map. I'm sure it is not hard to think up a few more examples.
Btw, having a monitor is pretty great when running on and developing for and on command line systems. So is an interactive language.
If anything, they need to understand what is possible. They might need it.
They might want it too. Great for them either way.
I am referring to a command line interface to the whole works. Understanding it is a basic element of literacy. .
?? What "command line interface to the whole works" can you mean ?
The editors I use have no command line interface to the whole works. They simply open all my windows as before.
(I think they have some CL options for file-open, that I never use)
The IDEs I use have no command line interface to the whole works.
The Terminals I use have no command line interface to the whole works. (but I do work with strings and files there)
The Compilers I use do have a command line interface, but I set that once, and forget all about it.
I certainly do not have any "command line interface to the whole works" inside my development loop.
Clearly you could use some exposure to more of the command line options and possibilities
Tachyon would be a spiffy place to start.
And who said anything about YOUR setup? Or mine, which is similar.
Some IDE type environments that run via simple terminal, have command lines right there in the editor. Others are line editors that operate command line. Compiler, OS, linker, debugger, monitor, all can operate on a command line basis.
Still others take things like input files to allow for entirely command line operation.
No mouse needed for any of it, nor a graphics display.
Of course that is extreme these days. But an interactive environment isn't.
It's pretty much impossible to make any progress on Ken's question until he clarifies the requirements. "Python running on the Propeller" is too vague. However, I assumed he meant Python like it exists currently on a PC which would imply a read-eval-print loop running on the Propeller itself. If he meant to include a Python-like language that is compiled on a PC and the generated code run on the Propeller like is done with Spin then many more possiblities exist. I'll also concede that it would be possible to have a completely interactive version of Python with the compiler running on a PC and the generated code running on the Propeller. However, that would still require that the Python runtime fit on the Propeller and that will certainly require extended memory. A Python-like language that doesn't support any of the dynamic features of Python is probably also possible but I have doubts as to its usefulness. It sounds to me like something that will take a large amount of work to create but will be found wanting because it is missing this or that feature of Python that the target audience might require.
Now a diversion I see - My setup is quite common, and normal, as I use the industry provided tools. ie it is exactly what Students could expect when they go to vendor's web sites, in 2015.
I write many command line programs, so I have plenty of exposure to them, but I again reiterate, I do NOT use the command line within my development loop.
It's pretty much impossible to make any progress on Ken's question until he clarifies the requirements. "Python running on the Propeller" is too vague. However, I assumed he meant Python like it exists currently on a PC which would imply a read-eval-print loop running on the Propeller itself. If he meant to include a Python-like language that is compiled on a PC and the generated code run on the Propeller like is done with Spin then many more possiblities exist. I'll also concede that it would be possible to have a completely interactive version of Python with the compiler running on a PC and the generated code running on the Propeller. However, that would still require that the Python runtime fit on the Propeller and that will certainly require extended memory. A Python-like language that doesn't support any of the dynamic features of Python is probably also possible but I have doubts as to its usefulness. It sounds to me like something that will take a large amount of work to create but will be found wanting because it is missing this or that feature of Python that the target audience might require.
Thanks for bringing me back, David. I didn't realize that this thread had gone 12 pages long. I was only making a terse inquiry and the answer is clear: no Python on Propeller - at least right now.
My request originated from a few teachers. Python seems to be gaining interest in middle school as a first language, sometimes even elementary. Several teachers using the S2 wanted to go from the graphical programming to code, but not Spin.
I think their ideal design is the Python runtime be stuffed into Propeller.
There's no need to look further into this request. You are all welcome to keep talking about it, however.
Jmg, have you actually used python? Have you worked with the REPL? Have you used the command line to the Interpreter while investigating modules or developing modules? Have you used espruino (including the Chrome application)? Have you used micropython for anything?
... I'll also concede that it would be possible to have a completely interactive version of Python with the compiler running on a PC and the generated code running on the Propeller. However, that would still require that the Python runtime fit on the Propeller and that will certainly require extended memory. A Python-like language that doesn't support any of the dynamic features of Python is probably also possible but I have doubts as to its usefulness.
For those who cry 'not python; at the mere idea of any subset, here is a very good example of python used as a design language, for embedded logic in CPLDs http://www.myhdl.org/examples/
Things to Notice :
There is no command line interface on a CPLD, yet they used python ?
There is no run-time library, inside a CPLD, yet they used python ?
- take a look at the Test Benches, and see how those are used to verify the logical control-flow code, before a chip is programmed.
Note those test benches do not have to run in the CPLD, but they are very useful in the Host.
Now, just imagine replace of the CPLD with a Prop. Voila.
Instead of worrying about what MyHDL was not, Jan focused on what could be done with a subset of Python.
I find the end result impressive, and certainly useful.
Maybe NotPython should compile to Spin bytecodes. Well, that again brings up the question I've asked many times on this forum. Where can I find a description of the Spin bytecodes? People have pointed me to various descriptions of them in the past but I can't remember the links. Can someone point me in the right direction again. This time I'll try to get Parallax to post the bytecode definitions in a place where people can find them.
Thanks for bringing me back, David. I didn't realize that this thread had gone 12 pages long. I was only making a terse inquiry and the answer is clear: no Python on Propeller - at least right now.
My request originated from a few teachers. Python seems to be gaining interest in middle school as a first language, sometimes even elementary. Several teachers using the S2 wanted to go from the graphical programming to code, but not Spin.
I think their ideal design is the Python runtime be stuffed into Propeller II. <----
There's no need to look further into this request. You are all welcome to keep talking about it, however.
Thanks,
Ken Gracey
I corrected the post for you, @Ken. I hope you don't mind...
I corrected the post for you, @Ken. I hope you don't mind...
Enjoy!
Mike
Hard to stuff anything into the P2 when it does not yet exist. Also, I suspect Python will still not fit in the P2 since at last report it will have only 512k of memory shared between code and data but I guess it depends on whether anything is done in P2 to improve instruction density.
Hard to stuff anything into the P2 when it does not yet exist. Also, I suspect Python will still not fit in the P2 since at last report it will have only 512k of memory shared between code and data but I guess it depends on whether anything is done in P2 to improve instruction density.
I am with you there @David Betz. But the chances to get it running on a P2 are hopefully better as they are on a P1.
I just wanted to tease @Ken a little bit. Sorry if that came over wrong.
@Chip does what he does very well and we all will be surprised with what he will come up with. @Ken does what he does very well and holds Parallax together and on course.
Maybe NotPython should compile to Spin bytecodes. Well, that again brings up the question I've asked many times on this forum. Where can I find a description of the Spin bytecodes? People have pointed me to various descriptions of them in the past but I can't remember the links. Can someone point me in the right direction again.
Hard to stuff anything into the P2 when it does not yet exist. Also, I suspect Python will still not fit in the P2 since at last report it will have only 512k of memory shared between code and data but I guess it depends on whether anything is done in P2 to improve instruction density.
Which will make tracking the efforts of a (Micro)Python on esp8266 WiFi chip topical.
This is the resource they have to pack it into ( more than P1, but less than P2 ?)
* esp8266 Core is a 106micro Diamond Standard core (LX3) made by Tensilica (32b with 24b/16b opcodes)
* Running at 80MHz
* 64KBytes of instruction RAM
* 96KBytes of data RAM
* 64KBytes boot ROM
* Winbond W25Q40BVNIG SPI flash
IIRC that has 16 registers, which would match the mapping PropGCC uses ?
Which will make tracking the efforts of a (Micro)Python on esp8266 WiFi chip topical.
This is the resource they have to pack it into ( more than P1, but less than P2 ?)
* esp8266 Core is a 106micro Diamond Standard core (LX3) made by Tensilica (32b with 24b/16b opcodes)
* Running at 80MHz
* 64KBytes of instruction RAM
* 96KBytes of data RAM
* 64KBytes boot ROM
* Winbond W25Q40BVNIG SPI flash
IIRC that has 16 registers, which would match the mapping PropGCC uses ?
Sounds interesting. I guess the boot ROM can hold the VM implementation and code could be paged in out of the SPI flash. You're right that anything that will fit on this will likely also fit on P2.
Sounds interesting. I guess the boot ROM can hold the VM implementation and code could be paged in out of the SPI flash. You're right that anything that will fit on this will likely also fit on P2.
ROMs in parts like this, are rather like the ROM in the P1. Unlikely to be changed frequently.
I'll see if there is a ROM listing anywhere.
MyHDL is certainly impressive. I was recently thinking of dipping my toes into HDL with it.
Things to notice:
There is no command line interface on a CPLD , yet they used python ? because there is no Python running on the CPLD.
There is no run-time library, inside a CPLD , yet they used python ? becaue there is no Python running on the CPLD.
If I imagine replacing the CPLD with a Prop I see this (By analogy with the work flow in MyHDL) :
1) Use Python to define a program, that program definition may well only use a subset of Python, NotPython. (Like MyHDL)
2) Use Python to turn that description into a program in some language,Spin say, or C. (Like Verilog)
3) Use the Spin/C compiler to generate the executable for the Prop. (Like CPLD configuration)
In order for that Spin code to fit in the Prop and run at any reasonable speed it looks to me as if that NotPython description of it will have to have a Spin like simplicity. No dynamic types, no garbage collection etc etc. Just as MyHDL does. All the things that make Python nice to program in have to go.
Which returns us to the question: Why bother with all that complexity for no benefit?
Excuse me for a while I'm off to play with MyHDL. Thanks for the reminder about that.
What "command line interface to the whole works" can you mean ?
I have been puzzling over this question all night. Perhaps you don't mean it the way I'm reading it.
Anyone who has become a little familiar with the Unix command line, or shell, usually bash now a days, soon realizes that it is the "Interface to the whole works". With that shell one can view and control everything that is viweable and controlable on the machine.
No GUI can match it. By the time you have added enough, buttons, menues, check boxes, tabs, text boxes etc to a GUI to enable what you can do in a shell you have an interface that is so ridiculously complex it would be easier to use the command line!
Editors I use do have a command line shell.
Some IDEs have a command line shell
My terminals certainly have terminals to allow using multiple command lines at the same time.
I have never seen a compiler with a command line. They do have command line arguments though.
Pretty much every developer I know makes heavy use of the command line and would complain like hell if it were not available.
Having said all that, you are right, I use Sublime Text for my JavaScript, QtCreator for my QT GUI apps, xTimeComposer for XMOS work, PropellerIDE for Propeller work, and so on.
Although quite often I can't be bothered with firing up and fighting with those unwieldy beasts and just hack the code in vim and then run "make" or whatever I need, so much quicker and easier.
There is a kind of paradox here. Such GUI things are supposed to be intuitive, obvious and simple. As such they should be learnable in no time. As such schools should not have to be spending time on teaching them, better to spend time on what's under the hood.
Oh, and what's with that syntax highlighting thing? I like nice syntax highlighting in my editors as much as anyone. But I do wonder sometimes what that is about. We don't syntax highlight normal English text, mathematicians do not syntax highlight their maths notation. How come software engineers are incapable of reading without colouring it in for them?
Comments
"Apparently you are right. I cannot account for it. My conclusion is these guys don't want to teach the binary and hex and assembler and real-time concerns of the low level of the embedded or even "normal" computing world. But they want to use a tiny MCU. They are very confused"
They are, considering the old guard they are so impressed with came up learning assembler, hex, binary and digital logic. The fundamentals as it were. And most learned not in a class setting but at home. Now they want the kiddies to use a language that hides everything, effectively turning the hardware back into a black box. Not smart, not conducive to producing the next Wozniak, May or Sinclair.
* Core is a 106micro Diamond Standard core (LX3) made by Tensilica
32b with 24b/16b opcodes
* Running at 80MHz
* 64KBytes of instruction RAM
* 96KBytes of data RAM
* 64KBytes boot ROM
* Winbond W25Q40BVNIG SPI flash
Compared with the larger 2015 ARM MCUs, that is modest resource set, but the price point is also compelling.
That smaller resource set would make it more 'not python'
The Parallax culture has already changed. Did you note how many external software consultants Ken now manages ?
Such is the nature of the modern world, software matters more than hardware, and Parallax are a module and software and Education support company, more than a chip company.
If Parallax do not deliver the solution their own customers are asking for, those customers will likely find it somewhere else.
Seems there are choices out there already, and improving..
The request for Python on the Prop has not included a full up IDE on the Prop as well has it? !
I wonder, does a kid who has never programmed before expect anything like that? They don't even know what "syntax" is, or a declaration etc. I don't know, it my "gut feeling" again. Something about the 4 million dollars sunk into the P2 development so far....
And you notice that development stopped a long time ago on the BS2 and a successor never appeared even though it's 20 years old now.
It's not to say it wasn't a big seller, it was with 3 million sold. But most companies continually improve their product lines to entice more customers, etc. Parallax never did with the BS2 according to some because of Scenix-Microchip lawsuit.
Why would they not expect this? It's not like they are going to enter industry in a vacuum. The various modes of development, ALL OF THEM, are relevant and significant to their overall education and personal development.
I would think those students expect education that results in a meaningful improvement in their ability to participate and advance in the industry. What they want and what they need won't always align, and that's fine. Everybody expect to have to work some, and understanding these things is just part of the work.
Command line interactive is an extremely useful thing to understand. So is using an IDE, as well as command line compiled.
Here's a similar scenario. I've taught Mechanical CAD for years. I'm really good at it, and I've ran and taught on most of the systems you can name out there. That training can sometimes bill out at $2K / DAY. (no joke, and it's a good gig when one can get it, but the work is often HARD)
How to get those rates?
Make damn sure that education is meaningful. And that means dragging them through some stuff and being there the whole time to make sure they get the understanding they need to be successful. And hear some rants. Good for the soul. Get it out, then get to work is how I've always played it.
It has been really interesting to see this last generation go through the process. They really do want to optimize toward the easy stuff. I have a hard time in the class sometimes. But I do make them do the harder stuff, and I make sure they know why and that it's OK to grumble the whole way through. I'll even buy drinks, if needed to get through it, but they get through it.
The older guard has always seen it for what it is and there is less friction there. Industry is messy and they know it. So they dig in and get what they need to be successful in the work they choose to do.
I get a lot of referrals. I get 'em, because people got what they needed, not always what they wanted. The same thing was done for me in my 20's several times. Loved those educators / instructors and trainers. Loved 'em because I was successful, and they were a part of that.
There are some boundaries to be defined here.
Higher education / University / academic - This may not always be realistic education for industry. It's value is largely up to the students who see it and exploit it. Industry expectations may well differ considerably from academic norms. This is OK, not a negative statement. Just a statement.
For profit / niche / job type training -- this is more frequently realistic when it's targeted for industry. In fact, the primary differentiators is the targeting and expectations associated with that. A secondary differentiator is skills based education being more of a focus than theory or higher level things in general. Less time, more focus, specific goals.
Hobby / club - all over the map.
Primary Education - Like any other subject, this is focused on literacy, basic skills, learn how to learn, exposure to material, etc... High school and grade school are what I'm talking about here. (US)
I think we really do need to understand something about these requests for context. Some of this discussion is "better than" type discussion, and "better than" isn't always relevant. Other parts of this discussion carries assumptions about the type of education, and those color the answers as should be, but the important thing missed is there does not always need to be a resolution. More than one scenario may well be acceptable, and the idea of serving all of them might not be possible, practical, viable too.
Getting back to student expectations... yeah, they have them. That's not necessarily the point.
What the vast majority of them are going to find is they need to be able to jump in on the tools, systems, processes and standards in use where they end up. That is the "work" part of "work" and it's not always fun, or what we prefer.
Those CAD students get dropped into scenarios with all sorts of tools other than the ones they love to use. And it's expensive to change up, so they get told to use the tool, or seek other employment. Which is why good training means taking them a few places they don't want to go, but might need to have gone to make the best of the opportunities they encounter later on.
So, what kind of education requests are these? It matters for the discussion, IMHO.
I think you missed the point. Can you point to any mainstream MCU company offering only a command line debug. ( or even find some that bother to include command line debug ?? )
Nope, it is all JTAG/2W/1W links, to host Debuggers, that is what they will find in their jobs.
Heck, I have 21c micros here, with HW Debug, & the esp8266 above mentioned HW Debug.
I think what you are trying to refer to, used to be called a Monitor Program, and I've not used one in decades.
Of course, I've not left the low level behind either, I still paste hex strings into terminals to test, and I would certainly expect modern MCU students to be able to do that.
but I would also expect them to know good Editing, documentation, and Version control, and I can't see bashing away on a terminal getting much time anywhere, not in 2015.
Err, that rather proves my point. The fastest way to learn what "syntax" is, or a declaration etc, is to use a good editor & a loaded code example, with a "Change this to ..." worksheet.
Decent frameworks are free, no reason or excuse not to use them.
Editors keep getting better at this stuff, and it is the sort of thing a PC CPU should be used for.
To save the programmer time and detail.
Agreed.
No, I was not referring to a monitor.
I am referring to a command line interface to the whole works. Understanding it is a basic element of literacy. It may be a practice, or may not, depending on where they go and who they are.
This is why knowing something about the requests is a good idea.
Heck, I'm currently learning about injection mold tooling. It is tough, and there are some basic points of literacy, just like a command line, that are proving very worth knowing, even though high end and modern tools are in regular use.
Another recent example was a CNC mill. Start by direct machine input, manual tool offsets, facing, insuring square, etc... then move up to a basic editor, then DNC, then advanced and highly automated software.
We had to go old school a week ago, due to some manufacturing requirement and specialized tool. Didn't miss a beat, and because I had that literacy from the 90's, it was no problem.
There seems to be a conflating of the desire to be rid of basic means, and their relevance.
Where consumer product design is in play, the trent toward new is understandable and expected. Industrial automation is a different beast, all over the map. I'm sure it is not hard to think up a few more examples.
Btw, having a monitor is pretty great when running on and developing for and on command line systems. So is an interactive language.
If anything, they need to understand what is possible. They might need it.
They might want it too. Great for them either way.
?? What "command line interface to the whole works" can you mean ?
The editors I use have no command line interface to the whole works. They simply open all my windows as before.
(I think they have some CL options for file-open, that I never use)
The IDEs I use have no command line interface to the whole works.
The Terminals I use have no command line interface to the whole works. (but I do work with strings and files there)
The Compilers I use do have a command line interface, but I set that once, and forget all about it.
I certainly do not have any "command line interface to the whole works" inside my development loop.
Tachyon would be a spiffy place to start.
And who said anything about YOUR setup? Or mine, which is similar.
Some IDE type environments that run via simple terminal, have command lines right there in the editor. Others are line editors that operate command line. Compiler, OS, linker, debugger, monitor, all can operate on a command line basis.
Still others take things like input files to allow for entirely command line operation.
No mouse needed for any of it, nor a graphics display.
Of course that is extreme these days. But an interactive environment isn't.
I write many command line programs, so I have plenty of exposure to them, but I again reiterate, I do NOT use the command line within my development loop.
Thanks for bringing me back, David. I didn't realize that this thread had gone 12 pages long. I was only making a terse inquiry and the answer is clear: no Python on Propeller - at least right now.
My request originated from a few teachers. Python seems to be gaining interest in middle school as a first language, sometimes even elementary. Several teachers using the S2 wanted to go from the graphical programming to code, but not Spin.
I think their ideal design is the Python runtime be stuffed into Propeller.
There's no need to look further into this request. You are all welcome to keep talking about it, however.
Thanks,
Ken Gracey
Seems like a more reasonable way to achieve the goal...
For those who cry 'not python; at the mere idea of any subset, here is a very good example of python used as a design language, for embedded logic in CPLDs
http://www.myhdl.org/examples/
Things to Notice :
There is no command line interface on a CPLD, yet they used python ?
There is no run-time library, inside a CPLD, yet they used python ?
- take a look at the Test Benches, and see how those are used to verify the logical control-flow code, before a chip is programmed.
If you like to drill right down to the details, see this
http://www.myhdl.org/examples/stopwatch/cpldfit.txt
Note those test benches do not have to run in the CPLD, but they are very useful in the Host.
Now, just imagine replace of the CPLD with a Prop. Voila.
Instead of worrying about what MyHDL was not, Jan focused on what could be done with a subset of Python.
I find the end result impressive, and certainly useful.
The discussion was Python on a Propeller.
By analogy, Python used to make PASM programs is an example of Python as development toolchain.
An IDE is another example.
The command line, vi, scripts, make, compile, link, package is yet another.
Python with a Propeller can make good sense. Python ON the Propeller, not so much.
Anyway, great example of a different way to get development done.
I corrected the post for you, @Ken. I hope you don't mind...
Enjoy!
Mike
Hard to stuff anything into the P2 when it does not yet exist. Also, I suspect Python will still not fit in the P2 since at last report it will have only 512k of memory shared between code and data but I guess it depends on whether anything is done in P2 to improve instruction density.
I am with you there @David Betz. But the chances to get it running on a P2 are hopefully better as they are on a P1.
I just wanted to tease @Ken a little bit. Sorry if that came over wrong.
@Chip does what he does very well and we all will be surprised with what he will come up with. @Ken does what he does very well and holds Parallax together and on course.
It is what it is.
Enjoy!
Mike
Some recent talk on Spin is here
http://forums.parallax.com/showthread.php/160616-Fast-Spin-exeucition-a-Verilog-coding-challenge
leads to
http://forums.parallax.com/showthread.php/157766-Boosting-SPIN-performance?p=1298037&viewfull=1#post1298037
and
http://forums.parallax.com/showthread.php/104276-Spin-Interpreter-Faster?p=731577&viewfull=1#post731577
and this
http://forums.parallax.com/showthread.php/96211-Spin-Bytecode-Disassembler
Seems there are slightly-better Spin-engines, but they all should swallow the same byte-codes
Which will make tracking the efforts of a (Micro)Python on esp8266 WiFi chip topical.
This is the resource they have to pack it into ( more than P1, but less than P2 ?)
* esp8266 Core is a 106micro Diamond Standard core (LX3) made by Tensilica (32b with 24b/16b opcodes)
* Running at 80MHz
* 64KBytes of instruction RAM
* 96KBytes of data RAM
* 64KBytes boot ROM
* Winbond W25Q40BVNIG SPI flash
IIRC that has 16 registers, which would match the mapping PropGCC uses ?
ROMs in parts like this, are rather like the ROM in the P1. Unlikely to be changed frequently.
I'll see if there is a ROM listing anywhere.
Google did find a nice die shot
http://zeptobars.ru/en/read/Espressif-ESP8266-wifi-serial-rs232-ESP8089-IoT
and talk of ROM dumps is here
http://www.esp8266.com/viewtopic.php?f=6&t=39&start=10
and here is the ROM-DisAsm
http://df.lth.se/~kongo/esp8266.bin/iram0.txt
and some links on Lua efforts too
http://www.esp8266.com/wiki/doku.php?id=lua
MyHDL is certainly impressive. I was recently thinking of dipping my toes into HDL with it.
Things to notice:
There is no command line interface on a CPLD , yet they used python ? because there is no Python running on the CPLD.
There is no run-time library, inside a CPLD , yet they used python ? becaue there is no Python running on the CPLD.
If I imagine replacing the CPLD with a Prop I see this (By analogy with the work flow in MyHDL) :
1) Use Python to define a program, that program definition may well only use a subset of Python, NotPython. (Like MyHDL)
2) Use Python to turn that description into a program in some language,Spin say, or C. (Like Verilog)
3) Use the Spin/C compiler to generate the executable for the Prop. (Like CPLD configuration)
In order for that Spin code to fit in the Prop and run at any reasonable speed it looks to me as if that NotPython description of it will have to have a Spin like simplicity. No dynamic types, no garbage collection etc etc. Just as MyHDL does. All the things that make Python nice to program in have to go.
Which returns us to the question: Why bother with all that complexity for no benefit?
Excuse me for a while I'm off to play with MyHDL. Thanks for the reminder about that.
Anyone who has become a little familiar with the Unix command line, or shell, usually bash now a days, soon realizes that it is the "Interface to the whole works". With that shell one can view and control everything that is viweable and controlable on the machine.
No GUI can match it. By the time you have added enough, buttons, menues, check boxes, tabs, text boxes etc to a GUI to enable what you can do in a shell you have an interface that is so ridiculously complex it would be easier to use the command line!
Editors I use do have a command line shell.
Some IDEs have a command line shell
My terminals certainly have terminals to allow using multiple command lines at the same time.
I have never seen a compiler with a command line. They do have command line arguments though.
Pretty much every developer I know makes heavy use of the command line and would complain like hell if it were not available.
Having said all that, you are right, I use Sublime Text for my JavaScript, QtCreator for my QT GUI apps, xTimeComposer for XMOS work, PropellerIDE for Propeller work, and so on.
Although quite often I can't be bothered with firing up and fighting with those unwieldy beasts and just hack the code in vim and then run "make" or whatever I need, so much quicker and easier.
There is a kind of paradox here. Such GUI things are supposed to be intuitive, obvious and simple. As such they should be learnable in no time. As such schools should not have to be spending time on teaching them, better to spend time on what's under the hood.
Oh, and what's with that syntax highlighting thing? I like nice syntax highlighting in my editors as much as anyone. But I do wonder sometimes what that is about. We don't syntax highlight normal English text, mathematicians do not syntax highlight their maths notation. How come software engineers are incapable of reading without colouring it in for them?