True enough. An STM32 F4 is a very different animal to an 8051 or Propeller. That seems to be what happens when we can fit a billion transistors in the space that previously only held one. A full up linux running system with multiple 32 bit cores and a gig of RAM is now smaller than most of the embedded systems I have worked on.
I was just observing that self-hosting seems to continue to be a popular idea. Chip himself has expressed this desire for self-hosting systems.
Interestingly the Espruino does allow editing code without an external editor, a dumb terminal will do. Rather like those BASIC systems of decades ago. It did occur to me a while back to use a Propeller to make such a dumb terminal for my Espruinos!
Yep, I'm prone to exaggeration. I did not say that "no one found a bug with a debugger" though. Again just making an observation, that on the occasions that I could really use a magic tool to pin point a hard to find bug in a complex embedded system it turned out the the debugger or emulator could not actually do it.
I conclude that debuggers are over rated. Certainly not missed on the Propeller.
True enough. An STM32 F4 is a very different animal to an 8051 or Propeller. That seems to be what happens when we can fit a billion transistors in the space that previously only held one. A full up linux running system with multiple 32 bit cores and a gig of RAM is now smaller than most of the embedded systems I have worked on.
Yes and it is exactly that trend that makes thoughts of full self hosting on Prop-scale parts, an ever shrinking niche.
The irony is, In another thread I see a poster called Heater pushing for using Pi's as hosts and Props as Slave IO, and talking about porting tools to the Pi !!
Interestingly the Espruino does allow editing code without an external editor, a dumb terminal will do. Rather like those BASIC systems of decades ago. It did occur to me a while back to use a Propeller to make such a dumb terminal for my Espruinos!
Sure. you can do that, but would you actually do that for serious development ?!
That's the problem with the severe limits of full self hosting - yes they are 'interesting' and I am still impressed with what Turbo Pascal packed into the 39k executable file - but would I use that environment in 2015, for serious work ?
Nope.
Advanced Teachers have the same problem - the 'interesting & curious' they can give only very sparse coverage to, as they do have to expose students to commercially useful systems.
Hi Ken,
back to your original question. It seems to me, that you have not yet played with a raspi? Just order a Raspberry Pi 2 board and start to play with it. I think it is good to know, what is going on in this market.
Best regards, Christof
My 2 cents: I came into touch with Python when I used FreeCAD, an open source CAD-System, which again uses Python as a scripting language. At the very start I made some progress, had to learn the API of FreeCAD, it was not easy to me. I continued to write some Python programs and soon realized: this is not made for real life. I use array intensely and whenever I have to expand an array, a new instance is created and everything is copied, so the speed goes down dramatically when real data came up. I had to give up this project and continued something else.
A similar experience I had often in my life. The step from "it can be done" to "it makes sense to do it this way" is not always possible. So what to teach that is special to Python when student have to learn the very basics of a programming language? I do not think it makes sense, as loops, flow control, variables, arrays etc are basic concepts. Here Basic certainly is sufficient. When it comes to real time applications, an assembler is needed. PASM to me is the tool of choice, as the machine can be run at the limits. If there is some marging, C can be seen as a machine independent assembler. From the marketing perspective Python makes sense if all teachers switch to RaspPi and want to show, that real time needs something different. But, in real life, classes open a door to programming, but compare the time invested by the student to reach a grade to the time to make a useful or not useful, but funny application.
I use array intensely and whenever I have to expand an array, a new instance is created and everything is copied, so the speed goes down dramatically when real data came up. I had to give up this project and continued something else.
In what language is that not a problem? As far as I know they all suffer from this array growth issue. Allocate some new memory, copy the old data to it, start using the bigger new memory area.
Not saying that Python is a performance wizz but it is certainly used for very serious work in "real life".
Basic is rude and crude by comparison.
Python does not seem to be anything like a good idea on such a small device as the Propeller 1.
In what language is that not a problem? As far as I know they all suffer from this array growth issue. Allocate some new memory, copy the old data to it, start using the bigger new memory area.
Not saying that Python is a performance wizz but it is certainly used for very serious work in "real life".
Basic is rude and crude by comparison.
Python does not seem to be anything like a good idea on such a small device as the Propeller 1.
Could Matlab be good at this? I was always told it excelled at data stored in matrix form. It was slower than Fortran in loops however, if I recall.
It is possible it has highly optimized matrix operations that you use rather tan writing them your self.
It is possible it uses "sparse array" techniques for hold arrays with huge numbers of columns and rows but are mostly empty. For example I should be able to write something like
myArray[1000000000] = 42
without the thing instantly trying to allocate giga bytes of RAM.
re: Could Matlab be good at this? I was always told it excelled at data stored in matrix form. It was slower than Fortran in loops however, if I recall.
From the website:
"Creating and Concatenating Matrices
Overview
The most basic MATLAB® data structure is the matrix: a two-dimensional, rectangularly shaped data structure capable of storing multiple elements of data in an easily accessible format. These data elements can be numbers, characters, logical states of true or false, or even other MATLAB structure types. MATLAB uses these two-dimensional matrices to store single numbers and linear series of numbers as well. In these cases, the dimensions are 1-by-1 and 1-by-n respectively, where n is the length of the numeric series. MATLAB also supports data structures that have more than two dimensions. These data structures are referred to as arrays in the MATLAB documentation.
MATLAB is a matrix-based computing environment. All of the data that you enter into MATLAB is stored in the form of a matrix or a multidimensional array. Even a single numeric value like 100 is stored as a matrix (in this case, a matrix having dimensions 1-by-1):
A = 100;
whos A
Name Size Bytes Class
A 1x1 8 double array
Regardless of the class being used, whether it is numeric, character, or logical true or false data, MATLAB stores this data in matrix (or array) form. For example, the string 'Hello World' is a 1-by-11 matrix of individual character elements in MATLAB. You can also build matrices composed of more complex classes, such as MATLAB structures and cell arrays.
To create a matrix of basic data elements such as numbers or characters, see"
Lately I've had many requests for Python on the Propeller, from middle school through university.
Thanks,
Ken Gracey
Would it be possible to change the propeller tool to produce suitable codes for the propeller. You already have an editor so you would only need to change that section of the program that converts the editor content to codes the prop understands. The interpreter in ROM is refered to as a 'spin interpreter' but it's really just an interpreter. The source file could be written in Swahili and, as long as the editor produces the right codes, the prop will function as intended.
Ah, so only the hardest and most complex part of the problem by an order of magnitude!
It's not clear to me that the Spin bytecodes are sufficient to interpret Python efficiently.
Then we still have the sever lack of memory for Python problem.
I was using 'only' as a relative term. As in, there's no need to completely reinvent the wheel. For that matter you could make the same modification to simpleide.
I didn't think the byte codes were specific to spin or any other language. They're just codes that direct the processor. I was using 'just' as a relative term :-)
The lack of memory problem isn't a show stopper. If not full blown Python then a trimmed down version suitable for what the prop is generally used for. The language would have to be adapted anyway to accommodate multiple cogs, the counters, etc.
Maybe it's impossible to program the propeller using Python.
Editors do not 'produce the right codes', Editors do exactly what the name suggests, which is edit
You probably mean to say Compiler.
Yes, compiler is probably the word I should have used. If you swap compiler for editor in my previous message does my argument make sense then?
Maybe propellent.exe could be modified to produce output based on python code written in any text editor. I believe there are some excellent code editors out there though I can't name them. While it would be a nontrivial task it might be possible.
I'm just throwing ideas out there to see if anything will stick. I certainly don't have the skills or the time to acquire the skills required to do any of this stuff.
...If not full blown Python then a trimmed down version suitable for what the prop is generally used for.
I can't see anyone, and certainly not the educationalists who were likely behind Ken's OP, being interested in a cut down Python. You would, at a stroke, render all the existing tutorial material and books, unusable.
Anyway, surely a cut down Python is already out there; it's called Spin.
I think I just don't get the idea behind these requests for Python support on the Propeller.
If you want to teach "programming" in some high level abstract way then by all means use Python. Or Scheme. Or JavaScript or whatever is easiest on a Mac, PC, etc. Same as kids in college were started off with BASIC back in the day.
If you want to teach something about how a computer is built, it's architecture and what it does under the hood surely something low level is in order, assembler for example.
If you want to teach something about the current world of embedded systems development then I guess C is the thing.
What actually is the aim of these guys requesting Python support?
I think I just don't get the idea behind these requests for Python support on the Propeller.
If you want to teach "programming" in some high level abstract way then by all means use Python. Or Scheme. Or JavaScript or whatever is easiest on a Mac, PC, etc. Same as kids in college were started off with BASIC back in the day.
If you want to teach something about how a computer is built, it's architecture and what it does under the hood surely something low level is in order, assembler for example.
If you want to teach something about the current world of embedded systems development then I guess C is the thing.
What actually is the aim of these guys requesting Python support?
@Heater
I completely understand why people are requesting Python support on the Propeller. Python is a very simple language to learn, but has a lot of flexibility. For people who already know the basics of Python, and want to learn about micro controllers, it would be great if they could use their skills in Python without having to learn a whole new language. Basically, a lot of beginners don't want to have to start over. And so people ask for Python on the propeller because they know Python.
Compared to Python, Spin is a much more limited language. This is of course done because of good reason, but many people who are ignorant of this fact ask for Python support.
I totally understand the attraction of Python as an introduction to the ideas of programming for the beginner. Sounds great to me.
But what the hell? Back in 1973 us young teenagers were being taught BASIC as an introduction to the mere idea of programming, which of course we had never been exposed to before. However in the same year we were also expected to become proficient in assembler. By way of gaining some small understanding of how computers actually worked.
Even all that was just a detail. Only 30% of the course. Then there was the numerical analysis and statistics we were expected to understand as part of a comp. sci. course after one year.
Now, I'm not about to say that all such education should go like mine did back in the 1970s. But there was no issue for us with the idea of "having to learn a whole new language". It was just what you have to do. And thank God it was so.
At some point I hope there is still some connection to reality in education. An 8 bit AVR or PIC or even the mighty 32 bit multi-core Propeller is not a suitable platform for a system like Python.
If you want to introduce someone to the concepts of programming, from scratch, by all means I think Python is great.
If you want to introduce someone to the world of embedded systems, small micros, or just how computers work under the hood, please understand that a thing like Python is just stupid.
I completely understand why people are requesting Python support on the Propeller. Python is a very simple language to learn, but has a lot of flexibility. For people who already know the basics of Python, and want to learn about micro controllers, it would be great if they could use their skills in Python without having to learn a whole new language. Basically, a lot of beginners don't want to have to start over. And so people ask for Python on the propeller because they know Python.
Makes sense, but also has the caveat that a Full Python is never going to be practical on a Prop.
So, perhaps there is a middle ground ?
The first step in getting a language to span a large resource set, is to have conditional support.
Looks like python has rather limited inherent conditional support, but there is this https://code.google.com/p/pypreprocessor/
That allows one source to be coded to produce both PC compatible python, and MCU python, which is a great help in teaching and testing.
Aside: It is here that a syntax-smart-editor could help in alerting users if they are using anything within their MCU sections, that are not supported (and lots of Full Python will not be supported).
( Note a syntax-smart-editor is just nice to have it is not mission critical, just saves novices time )
Now, we proceed looking at the simplest MCU language structures :
var = 100
if var == 200:
print "1 - Got a true expression value"
print var
elif var == 150:
print "2 - Got a true expression value"
print var
elif var == 100:
print "3 - Got a true expression value"
print var
else:
print "4 - Got a false expression value"
print var
print "Good bye!"
var1 = 'Hello World!'
var2 = "Python Programming"
print "var1[0]: ", var1[0]
print "var2[1:5]: ", var2[1:5]
a = 0
while a < 10:
a = a + 1
print a
Certainly that level of code is within a MCU, and a modest parser change to existing Basic, Pascal, or Spin et al.
Moving along, we find more common-denominator stuff, still within the realms of small MCUs
x = 0 # Exercise Play Computer Loop
y = 1
for n in [5, 4, 6]:
x = x + y*n
y = y + 1
print(x)
and even the more complex dictionary case handling looks MCU portable/compilable, with a little more work
def doblue (): print "The sea is blue"
def dogreen (): print "Grass is green"
def doyellow (): print "Sand is yellow"
def redflag ():
print "Red is the colour of fire"
print "do NOT play with fire"
def errhandler ():
print "Your input has not been recognised"
# set up a dictionary of actions
takeaction = {
"blue": doblue,
"green": dogreen,
"yellow": doyellow,
"red": redflag}
colour = raw_input("Please enter red blue green or yellow ")
takeaction.get(colour,errhandler)()
Because a primary use of MCU is in control, a focus on the control-flow aspects python is a good place to start
Most of what is on here, looks 'portable' : https://docs.python.org/3/tutorial/controlflow.html
The "middle ground" is not Python. It's a whole new, incompatible, other language that sort of maybe looks like Python. Why invent a new language when we have so many already? Why not use C or Spin or whatever?
Adding a preprocessor adds a whole layer of complexity. Exactly that kind of complexity that Python was designed to avoid!
The "middle ground" is not Python. It's a whole new, incompatible, other language that sort of maybe looks like Python. Why invent a new language when we have so many already? Why not use C or Spin or whatever?
Tell that to those who are asking for python.
A proper subset does not 'sort of maybe look like python', it is cut and paste compatible with python.
The "middle ground" is not Python. It's a whole new, incompatible, other language that sort of maybe looks like Python. Why invent a new language when we have so many already? Why not use C or Spin or whatever?
Adding a preprocessor adds a whole layer of complexity. Exactly that kind of complexity that Python was designed to avoid!
No middle ground for Python? Why invent a new language when we have so many already?
Something needs to fill the educational gap that Python cannot adequately address.
The problem arrises out of Python being the first language someone learns, like on the Raspberry Pi. The beginner doesn't fully comprehend how resource demanding Python is and expects to use it on smaller architectures. This is simply a hazard of starting with a large scale SoC and working down versus starting with a smaller micro-controller and working up tp SoC.
It is also a cultural dilemma when one particular language gets all the limelight. People just want to start with the most popular language of the moment.
Parallax provides education in micro-controllers that is more sensible -- from the bottom and then going up. And has managed to eventually accomodate GCC for the top down approach. Which approach is better? That's open to debate, but my gut feeling is a lot of people don't want to feel they are back-tracking over material that should have been taught first.
++++++++
Python programmers have to eventually something else and more fundamental, such as a shift to SPIN, PASM, GCC, or PropellerBasic to begin to learn how to work with smaller archtectures. Some will never understand the advantages of doing so, but keep asking for Python. Those tend to completely ignore the issues of architecture and just want the most of anything available.
Others will see that lower level programing can empower one to do many things with more precise timing and more directly.
I guess the main point is that you are not really learning programing until you begin to learn other languages for other reasons.
If the user isn't made aware of the need to learn a complete curriculum or to make intellengent choices about size and architecture -- they pretty much try to learn just one language. The Propeller is NOT the only micro-controller that cannot completely support Python.
Something needs to fill the educational gap that Python cannot adequately address.
I agree.
There are already thousands of languages and programming systems to fill that gap. There is a list of hundreds of languages that have been demonstrated on the Propeller. There must be a dozen or so of them that are actually practical and in use every day.
My only small point is that the last thing we is a mutant, cut down, shadow of some other language that serves no significant purpose. I'm always arguing against YAFL that way.
I recall we all had a similar debate about the idea of a cut down C like language for the Propeller that compiled to Spin byte code. That was another appeal to educationalists that was luckily abandoned.
IMHO, a one day, SPIN for Python programmers instruction should address most of this.
Three cases:
1. Somebody doesn't yet understand programming
For this case, they need a lean language and capable environment. As they get some success, they advance. Doesn't matter how, just that they do.
Python on a Pi is perfect for this case. BASIC on a micro is great. Javascript in a browser works too. They become programmers. The one day course won't work for these people, because they are not yet programmers.
Also, SPIN on a Propeller is great for this case too. If they are starting, there are several starting places that make sense. All depends on the educator and the overall student preferences and goals.
2. Understands Python programming, wants more
For this case, "more" really does matter. Heater mentions the embedded scenario, to which I think they should be learning about C, SPIN, Assembly Language, etc... That is where they are going to want to go, because that is where embedded largely is.
The one day course would work, if they understand and have had some success in Python. They begin their journey to all things embedded. Honestly, this is the sweet spot and could be great. A Python programmer can understand SPIN in a day. Heck, a BASIC programmer can understand SPIN in a day. Lots of people can understand SPIN in a day. SPIN is awesome.
Add a Propeller to their Python experiences with a library and have the Propeller do some spiffy stuff they can experience before stepping away from Python and into embedded land. Once they have used the chip at a distance, that one day, "now, let's do it directly on the thing" SPIN for Python programmers course is just the thing.
From there, take 'em on a tour. Next stop, C, etc... They should come out of it with some varied programming experiences which is just the thing they need to continue on in embedded land.
3. The more general "is programmer", wants more.
Forget Python. Introduce them to C and Assembly Language and make sure they experience a few different devices. SPIN + PASM can be a diversion here, if needed / applicable / desirable, but otherwise they are looking to go deeper into embedded.
Since they are a programmer, it's more about mapping what they know to the embedded environments they will encounter, and it's more important for them to understand how to understand what the limits might be, practicalities, etc... than it is to get into language specifics. They, as programmers, can get that sorted quickly enough. They may never have encountered real Assembly Language, and if that is true, make 'em do it. PASM is beautiful and quite easy for this purpose. The only thing comparable is retro devices and their Assembly Language. Otherwise, it's a mess. Get the skill first, then tackle the mess.
They too can take the tour and get a few varied programming experiences. They need to, because that is exactly what is going to happen to them anyway.
Basically, there isn't a need to run Python on a Propeller. There is a great case for extending Python to work super simple with a Propeller.
Cutting down Python will just make a mess and confuse people. Either do it on a machine worth doing Python on, or don't.
Truth is, if they really are interested in the embedded path, then an hour lecture on what that is going to mean for them can include the basic skill of programming itself, which can be Python on a Pi, or their PC, whatever, and then it can frame up what being a programmer means when it comes to tackling different environments, such as C, SPIN, Assembly, whatever...
Put that right out there, voice of experience style, and don't sugar coat it. The sooner they understand the path, the sooner they will be eager to jump in and start working on stuff.
Putting Python on the Propeller is an attempt to sugar coat what just needs to be said and done. I know as a student, I very seriously appreciated those people who just told me like it was. Saved a bunch of time too. Back when I was learning this stuff as a kid, that meant no goofing around. If you want fast, then you want Assembly Language. Just knowing that made the path much easier.
Today, that's not true! Tons of choices. But that also means the very best skill one can have is cultivating the ability to make those choices and that means picking up something and programming in it, flat out. Why?
Because they will need to make those choices, and or have some requirement or other make that choice for them. Get 'em out of the kiddie pool quickly, but be there so they don't drown, but do let 'em struggle a bit. Worth it.
Truth is, if they can't really jump in and do some learning on the fly, or if they don't want to and actually won't, they are more or less qualifying out of this stuff and should continue on a path better aligned with who they are and what they really want to do.
It won't pay off to delay this learning, qualifying activity much. So don't. The students who really want to go here will thank us for it, and so will the ones who really don't, but thought they did. No worries.
I recall we all had a similar debate about the idea of a cut down C like language for the Propeller that compiled to Spin byte code. That was another appeal to educationalists that was luckily abandoned.
Yes, and that was because there really is no "just learning." Everything is capable enough today that it makes no sense at all to just dip in and learn something that can't actually be applied in some fashion. Learning C today on the Propeller means being able to use a Propeller well! We can get awesome things done in C today, because C actually works well today. (and it took a serious effort too)
The same thing is going to happen here. If we can't actually use Python to use a Propeller and do awesome things, then it's never, ever, ever going to be worth it to learn about Python on the Propeller. Useless.
People who attempt this stuff want to learn how to actually do things. So the learning path must include being able to do real things, or it's just a waste of time.
What Python features are suggesting be removed? Perhaps we can discuss it more clearly knowing that.
I've already given a breakdown in #173, strange how so many work on reflex feelings and cannot focus on technical details ?
Ken asked the question, and I've looked at the details, and I do not see any brick-walls that others seem to imagine.
A bemusing part of the 'not python' claims, is I've yet to use two versions of the SAME MCU language from different vendors that are 100% compatible.
With effort, I can often create code that can compile in both, so the idea of a common subset is already widely deployed out there in industry.
I've already given a breakdown in #173, strange how so many work on reflex feelings and cannot focus on technical details ?
Ken asked the question, and I've looked at the details, and I do not see any brick-walls that others seem to imagine.
A bemusing part of the 'not python' claims, is I've yet to use two versions of the SAME MCU language from different vendors that are 100% compatible.
With effort, I can often create code that can compile in both, so the idea of a common subset is already widely deployed out there in industry.
I wonder how those so anxious about "not python" cope with Python2 <> Python 3. Which one is the real python ?
It seems to me that if you take dynamic typing and dynamic memory management out of Python then you end up with too small a subset to be used in the way Python is usually used. And those are part of what makes Python impractical on a P1 or an ATmega328 or other small MCUs. Also, if you take interactivity away then you also take away one of its useful features for beginners. If you end up with a language that has to be compiled on a PC and downloaded to the Propeller, you may as well just use C or Spin or PropBasic.
Comments
True enough. An STM32 F4 is a very different animal to an 8051 or Propeller. That seems to be what happens when we can fit a billion transistors in the space that previously only held one. A full up linux running system with multiple 32 bit cores and a gig of RAM is now smaller than most of the embedded systems I have worked on.
I was just observing that self-hosting seems to continue to be a popular idea. Chip himself has expressed this desire for self-hosting systems.
Interestingly the Espruino does allow editing code without an external editor, a dumb terminal will do. Rather like those BASIC systems of decades ago. It did occur to me a while back to use a Propeller to make such a dumb terminal for my Espruinos!
Yep, I'm prone to exaggeration. I did not say that "no one found a bug with a debugger" though. Again just making an observation, that on the occasions that I could really use a magic tool to pin point a hard to find bug in a complex embedded system it turned out the the debugger or emulator could not actually do it.
I conclude that debuggers are over rated. Certainly not missed on the Propeller.
My favorite code debugger.
That's why they invented front panels on computers!!
Yes and it is exactly that trend that makes thoughts of full self hosting on Prop-scale parts, an ever shrinking niche.
The irony is, In another thread I see a poster called Heater pushing for using Pi's as hosts and Props as Slave IO, and talking about porting tools to the Pi !!
Sure. you can do that, but would you actually do that for serious development ?!
That's the problem with the severe limits of full self hosting - yes they are 'interesting' and I am still impressed with what Turbo Pascal packed into the 39k executable file - but would I use that environment in 2015, for serious work ?
Nope.
Advanced Teachers have the same problem - the 'interesting & curious' they can give only very sparse coverage to, as they do have to expose students to commercially useful systems.
back to your original question. It seems to me, that you have not yet played with a raspi? Just order a Raspberry Pi 2 board and start to play with it. I think it is good to know, what is going on in this market.
Best regards, Christof
A similar experience I had often in my life. The step from "it can be done" to "it makes sense to do it this way" is not always possible. So what to teach that is special to Python when student have to learn the very basics of a programming language? I do not think it makes sense, as loops, flow control, variables, arrays etc are basic concepts. Here Basic certainly is sufficient. When it comes to real time applications, an assembler is needed. PASM to me is the tool of choice, as the machine can be run at the limits. If there is some marging, C can be seen as a machine independent assembler. From the marketing perspective Python makes sense if all teachers switch to RaspPi and want to show, that real time needs something different. But, in real life, classes open a door to programming, but compare the time invested by the student to reach a grade to the time to make a useful or not useful, but funny application.
Not saying that Python is a performance wizz but it is certainly used for very serious work in "real life".
Basic is rude and crude by comparison.
Python does not seem to be anything like a good idea on such a small device as the Propeller 1.
Could Matlab be good at this? I was always told it excelled at data stored in matrix form. It was slower than Fortran in loops however, if I recall.
It is possible it has highly optimized matrix operations that you use rather tan writing them your self.
It is possible it uses "sparse array" techniques for hold arrays with huge numbers of columns and rows but are mostly empty. For example I should be able to write something like
myArray[1000000000] = 42
without the thing instantly trying to allocate giga bytes of RAM.
From the website:
"Creating and Concatenating Matrices
Overview
The most basic MATLAB® data structure is the matrix: a two-dimensional, rectangularly shaped data structure capable of storing multiple elements of data in an easily accessible format. These data elements can be numbers, characters, logical states of true or false, or even other MATLAB structure types. MATLAB uses these two-dimensional matrices to store single numbers and linear series of numbers as well. In these cases, the dimensions are 1-by-1 and 1-by-n respectively, where n is the length of the numeric series. MATLAB also supports data structures that have more than two dimensions. These data structures are referred to as arrays in the MATLAB documentation.
MATLAB is a matrix-based computing environment. All of the data that you enter into MATLAB is stored in the form of a matrix or a multidimensional array. Even a single numeric value like 100 is stored as a matrix (in this case, a matrix having dimensions 1-by-1):
A = 100;
whos A
Name Size Bytes Class
A 1x1 8 double array
Regardless of the class being used, whether it is numeric, character, or logical true or false data, MATLAB stores this data in matrix (or array) form. For example, the string 'Hello World' is a 1-by-11 matrix of individual character elements in MATLAB. You can also build matrices composed of more complex classes, such as MATLAB structures and cell arrays.
To create a matrix of basic data elements such as numbers or characters, see"
http://www.mathworks.com/help/matlab/math/creating-and-concatenating-matrices.html
Would it be possible to change the propeller tool to produce suitable codes for the propeller. You already have an editor so you would only need to change that section of the program that converts the editor content to codes the prop understands. The interpreter in ROM is refered to as a 'spin interpreter' but it's really just an interpreter. The source file could be written in Swahili and, as long as the editor produces the right codes, the prop will function as intended.
Sandy
It's not clear to me that the Spin bytecodes are sufficient to interpret Python efficiently.
Then we still have the sever lack of memory for Python problem.
I was using 'only' as a relative term. As in, there's no need to completely reinvent the wheel. For that matter you could make the same modification to simpleide.
I didn't think the byte codes were specific to spin or any other language. They're just codes that direct the processor. I was using 'just' as a relative term :-)
The lack of memory problem isn't a show stopper. If not full blown Python then a trimmed down version suitable for what the prop is generally used for. The language would have to be adapted anyway to accommodate multiple cogs, the counters, etc.
Maybe it's impossible to program the propeller using Python.
Sandy
You probably mean to say Compiler.
Yes, compiler is probably the word I should have used. If you swap compiler for editor in my previous message does my argument make sense then?
Maybe propellent.exe could be modified to produce output based on python code written in any text editor. I believe there are some excellent code editors out there though I can't name them. While it would be a nontrivial task it might be possible.
I'm just throwing ideas out there to see if anything will stick. I certainly don't have the skills or the time to acquire the skills required to do any of this stuff.
Sandy
I can't see anyone, and certainly not the educationalists who were likely behind Ken's OP, being interested in a cut down Python. You would, at a stroke, render all the existing tutorial material and books, unusable.
Anyway, surely a cut down Python is already out there; it's called Spin.
And we're back to the beginning.
Sandy
If you want to teach "programming" in some high level abstract way then by all means use Python. Or Scheme. Or JavaScript or whatever is easiest on a Mac, PC, etc. Same as kids in college were started off with BASIC back in the day.
If you want to teach something about how a computer is built, it's architecture and what it does under the hood surely something low level is in order, assembler for example.
If you want to teach something about the current world of embedded systems development then I guess C is the thing.
What actually is the aim of these guys requesting Python support?
@Heater
I completely understand why people are requesting Python support on the Propeller. Python is a very simple language to learn, but has a lot of flexibility. For people who already know the basics of Python, and want to learn about micro controllers, it would be great if they could use their skills in Python without having to learn a whole new language. Basically, a lot of beginners don't want to have to start over. And so people ask for Python on the propeller because they know Python.
Compared to Python, Spin is a much more limited language. This is of course done because of good reason, but many people who are ignorant of this fact ask for Python support.
I totally understand the attraction of Python as an introduction to the ideas of programming for the beginner. Sounds great to me.
But what the hell? Back in 1973 us young teenagers were being taught BASIC as an introduction to the mere idea of programming, which of course we had never been exposed to before. However in the same year we were also expected to become proficient in assembler. By way of gaining some small understanding of how computers actually worked.
Even all that was just a detail. Only 30% of the course. Then there was the numerical analysis and statistics we were expected to understand as part of a comp. sci. course after one year.
Now, I'm not about to say that all such education should go like mine did back in the 1970s. But there was no issue for us with the idea of "having to learn a whole new language". It was just what you have to do. And thank God it was so.
At some point I hope there is still some connection to reality in education. An 8 bit AVR or PIC or even the mighty 32 bit multi-core Propeller is not a suitable platform for a system like Python.
If you want to introduce someone to the concepts of programming, from scratch, by all means I think Python is great.
If you want to introduce someone to the world of embedded systems, small micros, or just how computers work under the hood, please understand that a thing like Python is just stupid.
Makes sense, but also has the caveat that a Full Python is never going to be practical on a Prop.
So, perhaps there is a middle ground ?
The first step in getting a language to span a large resource set, is to have conditional support.
Looks like python has rather limited inherent conditional support, but there is this
https://code.google.com/p/pypreprocessor/
That allows one source to be coded to produce both PC compatible python, and MCU python, which is a great help in teaching and testing.
Aside: It is here that a syntax-smart-editor could help in alerting users if they are using anything within their MCU sections, that are not supported (and lots of Full Python will not be supported).
( Note a syntax-smart-editor is just nice to have it is not mission critical, just saves novices time )
Now, we proceed looking at the simplest MCU language structures :
var = 100 if var == 200: print "1 - Got a true expression value" print var elif var == 150: print "2 - Got a true expression value" print var elif var == 100: print "3 - Got a true expression value" print var else: print "4 - Got a false expression value" print var print "Good bye!" var1 = 'Hello World!' var2 = "Python Programming" print "var1[0]: ", var1[0] print "var2[1:5]: ", var2[1:5] a = 0 while a < 10: a = a + 1 print aCertainly that level of code is within a MCU, and a modest parser change to existing Basic, Pascal, or Spin et al.
Moving along, we find more common-denominator stuff, still within the realms of small MCUs
x = 0 # Exercise Play Computer Loop y = 1 for n in [5, 4, 6]: x = x + y*n y = y + 1 print(x)and even the more complex dictionary case handling looks MCU portable/compilable, with a little more work
def doblue (): print "The sea is blue" def dogreen (): print "Grass is green" def doyellow (): print "Sand is yellow" def redflag (): print "Red is the colour of fire" print "do NOT play with fire" def errhandler (): print "Your input has not been recognised" # set up a dictionary of actions takeaction = { "blue": doblue, "green": dogreen, "yellow": doyellow, "red": redflag} colour = raw_input("Please enter red blue green or yellow ") takeaction.get(colour,errhandler)()Because a primary use of MCU is in control, a focus on the control-flow aspects python is a good place to start
Most of what is on here, looks 'portable' :
https://docs.python.org/3/tutorial/controlflow.html
Adding a preprocessor adds a whole layer of complexity. Exactly that kind of complexity that Python was designed to avoid!
A proper subset does not 'sort of maybe look like python', it is cut and paste compatible with python.
..and yet. python users have themselves, decided to add one, What does that tell you ?
What Python features are suggesting be removed? Perhaps we can discuss it more clearly knowing that. Not sure. It does not invalidate my statement though.
No middle ground for Python? Why invent a new language when we have so many already?
Something needs to fill the educational gap that Python cannot adequately address.
The problem arrises out of Python being the first language someone learns, like on the Raspberry Pi. The beginner doesn't fully comprehend how resource demanding Python is and expects to use it on smaller architectures. This is simply a hazard of starting with a large scale SoC and working down versus starting with a smaller micro-controller and working up tp SoC.
It is also a cultural dilemma when one particular language gets all the limelight. People just want to start with the most popular language of the moment.
Parallax provides education in micro-controllers that is more sensible -- from the bottom and then going up. And has managed to eventually accomodate GCC for the top down approach. Which approach is better? That's open to debate, but my gut feeling is a lot of people don't want to feel they are back-tracking over material that should have been taught first.
++++++++
Python programmers have to eventually something else and more fundamental, such as a shift to SPIN, PASM, GCC, or PropellerBasic to begin to learn how to work with smaller archtectures. Some will never understand the advantages of doing so, but keep asking for Python. Those tend to completely ignore the issues of architecture and just want the most of anything available.
Others will see that lower level programing can empower one to do many things with more precise timing and more directly.
I guess the main point is that you are not really learning programing until you begin to learn other languages for other reasons.
If the user isn't made aware of the need to learn a complete curriculum or to make intellengent choices about size and architecture -- they pretty much try to learn just one language. The Propeller is NOT the only micro-controller that cannot completely support Python.
There are already thousands of languages and programming systems to fill that gap. There is a list of hundreds of languages that have been demonstrated on the Propeller. There must be a dozen or so of them that are actually practical and in use every day.
My only small point is that the last thing we is a mutant, cut down, shadow of some other language that serves no significant purpose. I'm always arguing against YAFL that way.
I recall we all had a similar debate about the idea of a cut down C like language for the Propeller that compiled to Spin byte code. That was another appeal to educationalists that was luckily abandoned.
Three cases:
1. Somebody doesn't yet understand programming
For this case, they need a lean language and capable environment. As they get some success, they advance. Doesn't matter how, just that they do.
Python on a Pi is perfect for this case. BASIC on a micro is great. Javascript in a browser works too. They become programmers. The one day course won't work for these people, because they are not yet programmers.
Also, SPIN on a Propeller is great for this case too. If they are starting, there are several starting places that make sense. All depends on the educator and the overall student preferences and goals.
2. Understands Python programming, wants more
For this case, "more" really does matter. Heater mentions the embedded scenario, to which I think they should be learning about C, SPIN, Assembly Language, etc... That is where they are going to want to go, because that is where embedded largely is.
The one day course would work, if they understand and have had some success in Python. They begin their journey to all things embedded. Honestly, this is the sweet spot and could be great. A Python programmer can understand SPIN in a day. Heck, a BASIC programmer can understand SPIN in a day. Lots of people can understand SPIN in a day. SPIN is awesome.
Add a Propeller to their Python experiences with a library and have the Propeller do some spiffy stuff they can experience before stepping away from Python and into embedded land. Once they have used the chip at a distance, that one day, "now, let's do it directly on the thing" SPIN for Python programmers course is just the thing.
From there, take 'em on a tour. Next stop, C, etc... They should come out of it with some varied programming experiences which is just the thing they need to continue on in embedded land.
3. The more general "is programmer", wants more.
Forget Python. Introduce them to C and Assembly Language and make sure they experience a few different devices. SPIN + PASM can be a diversion here, if needed / applicable / desirable, but otherwise they are looking to go deeper into embedded.
Since they are a programmer, it's more about mapping what they know to the embedded environments they will encounter, and it's more important for them to understand how to understand what the limits might be, practicalities, etc... than it is to get into language specifics. They, as programmers, can get that sorted quickly enough. They may never have encountered real Assembly Language, and if that is true, make 'em do it. PASM is beautiful and quite easy for this purpose. The only thing comparable is retro devices and their Assembly Language. Otherwise, it's a mess. Get the skill first, then tackle the mess.
They too can take the tour and get a few varied programming experiences. They need to, because that is exactly what is going to happen to them anyway.
Basically, there isn't a need to run Python on a Propeller. There is a great case for extending Python to work super simple with a Propeller.
Cutting down Python will just make a mess and confuse people. Either do it on a machine worth doing Python on, or don't.
Truth is, if they really are interested in the embedded path, then an hour lecture on what that is going to mean for them can include the basic skill of programming itself, which can be Python on a Pi, or their PC, whatever, and then it can frame up what being a programmer means when it comes to tackling different environments, such as C, SPIN, Assembly, whatever...
Put that right out there, voice of experience style, and don't sugar coat it. The sooner they understand the path, the sooner they will be eager to jump in and start working on stuff.
Putting Python on the Propeller is an attempt to sugar coat what just needs to be said and done. I know as a student, I very seriously appreciated those people who just told me like it was. Saved a bunch of time too. Back when I was learning this stuff as a kid, that meant no goofing around. If you want fast, then you want Assembly Language. Just knowing that made the path much easier.
Today, that's not true! Tons of choices. But that also means the very best skill one can have is cultivating the ability to make those choices and that means picking up something and programming in it, flat out. Why?
Because they will need to make those choices, and or have some requirement or other make that choice for them. Get 'em out of the kiddie pool quickly, but be there so they don't drown, but do let 'em struggle a bit. Worth it.
Truth is, if they can't really jump in and do some learning on the fly, or if they don't want to and actually won't, they are more or less qualifying out of this stuff and should continue on a path better aligned with who they are and what they really want to do.
It won't pay off to delay this learning, qualifying activity much. So don't. The students who really want to go here will thank us for it, and so will the ones who really don't, but thought they did. No worries.
Yes, and that was because there really is no "just learning." Everything is capable enough today that it makes no sense at all to just dip in and learn something that can't actually be applied in some fashion. Learning C today on the Propeller means being able to use a Propeller well! We can get awesome things done in C today, because C actually works well today. (and it took a serious effort too)
The same thing is going to happen here. If we can't actually use Python to use a Propeller and do awesome things, then it's never, ever, ever going to be worth it to learn about Python on the Propeller. Useless.
People who attempt this stuff want to learn how to actually do things. So the learning path must include being able to do real things, or it's just a waste of time.
Ken asked the question, and I've looked at the details, and I do not see any brick-walls that others seem to imagine.
A bemusing part of the 'not python' claims, is I've yet to use two versions of the SAME MCU language from different vendors that are 100% compatible.
With effort, I can often create code that can compile in both, so the idea of a common subset is already widely deployed out there in industry.
Even python itself stumbles on the "not python" test, as they morph the language - try this for some revealing info
https://wiki.python.org/moin/Python2orPython3
I wonder how those so anxious about "not python" cope with Python2 <> Python 3. Which one is the real python ?
Is that going to be true of Python and it still be Python, in the way C is still C?
If so, how; otherwise, there is no case for Python on a Prop.