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.
Silly me! I thought we were talking about a way to get Python running on the Propeller so kids could learn to program in general with some Prop/MCU specific capabilities. I didn't know we were talking about a PC hosted code generation tool to create code in some other language that just happened to be written in Python because Python is a good embeddable scripting language.
Sure, Python on a workstation is a great choice for that! It's a really good way to develop tools and provide a pythonic domain specific language.....once the folks have learned some Python somehow.
Python is also a great learning language if it can retain all the things that make it Python: REPL, full object support, simple syntax, etc. Once you make a non-Python, you've lost any advantage to using it as a learning language (IMHO).
myhdl looks like a brilliant implementation of a domain specific tool with embedded Python, I'll certainly check this out! But it certainly isn't a route for new programmers to learn the basics of programming.
I guess you're saying that the 64k of ROM is not available for use by Python so the Python code will have to fit in the 64k of instruction RAM? In that case, P2 could certainly run the same code.
PyMite is a flyweight Python interpreter written from scratch to execute on 8-bit and larger microcontrollers with resources as limited as 64 KiB of program memory (flash) and 4 KiB of RAM. PyMite supports a subset of the Python 2.5 syntax and can execute a subset of the Python 2.5 bytecodes.
20KiB Flash and 4K RAM, will run today. But the 4K heap is rather small and limits the complexity of programs that can be run. I am also intending to port PyMite to the popular Motorola HC11-through-Star12 family. Porting to the HC11 would allow PyMite to run on MIT's popular Handyboard robot controller. These first two porting targets are simply my preference. This does not limit in any way someone taking the PyMite source and porting it to the processor of their choice. The only requirements so far are an ANSI C compiler, and a fair amount of porting effort.
Well, when somebody actually makes a serviceable GUI for regex, then we've made sufficient progress for the GUI to be comparable to the command line. I've not seen we are there yet.
This is not an anti GUI statement. I like GUI environments a lot. Often, I'm doing things that don't need so much expressive syntax, and I'm happy to operate in the nice environment and get the nice help it can provide. No worries.
But, when I'm faced with something new, I always ask where the command line is and how it works. I ask, because it's basic info I may need or want. And if it doesn't have one, then it doesn't have one, but then it's on my "keep an eye on this" list, because somebody somewhere will make one that does.
In terms of the basic education people need, I think they need the command line. For a while. Nobody cares what they do, other than we want them successful. And we want them to have the max ability to be successful, and understanding command line operation is important.
I was part of an ugly data migration and translation of some seriously large and messy CAD data sets a few years back. Was on IRIX too. (which was fun, because IRIX is awesome) The guy who got called into assist with this had developed a pile of the code being used. Let's just say the quantity and quality of mess was beyond even his expectations.
So there we are, and we realize it's gonna take some code. New code.
He asked about tools, and I fetched gcc and set it up for him as this site didn't have a license for MipsPro. Notice he didn't ask about a specific set of tools, just tools. What can he program with? That's a programmer. If gcc were not on the table, he would have used Perl, or whatever else he could find on that box.
What does this guy do? He cracks open a few XTerms via the X Window system in use there, and sets about authoring the new code and modifying his existing, which he pulled down from some private repository. First a build of existing and test. Done, works, spiffy! Then, it's get the new done.
Tools? Vi + Gcc and friends. That's it. Took him about 4 hours to get it done, and I was there watching as he almost never picked up the mouse. In fact, the mouse was just a tool to switch windows to switch command lines, and for a brief moment, wondered if it were not possible to make a quick program to change window focus...
If he were on a console, he would be using the Fkey terminal set to get this done, but a desktop was just fine, as was a modem running at a few Kb / sec. Would not have mattered one bit. He didn't ask about an editor or IDE.
Of course, I asked about this, and his reply:
I like vi, because it's fast, has the functions I need, and it's everywhere, and it always works.
I like terminals, because they have the functions I need, are everywhere, and they always work.
I like gcc, because it has the functions I need, is everywhere, and it always works.
I like UNIX, because it has a great command line, and nearly always works. But, it's not everywhere.
Really, it was hard to see being more productive. Very little time was wasted, and this guy is a programmer, and a mentor of mine, from time to time. I don't have that kind of skill, but I can see how it plays out, and it was definitely a good day. You can put this guy in front of Visual Studio, and he's gonna go to town there too. Doesn't matter much. Writing programs matters a lot.
When I program, I gotta work for it, and that's fine. I don't do it every day. But I do it a lot. And if I've got a terminal, then that's what I use. If I've got a GUI, that's what I use. Was mentored up to be tool independent, and OS independent (as possible) and that pays off big. Any of us here, who have had similar experiences, knows that.
Heck, I would regularly write scrips and little programs on UNIX boxes over free JUNO dialup in hotel rooms. 3Kb / sec tops. You can bet good old vi was the tool. What else could be? (yes, there are a few options, but not GUI ones) And that was an adventure. Fire up JUNO, check e-mail, bury the browser and it's ADS, then use what's left of the connection to do stuff. Not much left. But it was totally free, and this was the mid 90's. There were a lot of boxes with SSH tunnels and such, and quite a few with modems too.
(I was doing some admin on the side for extra $$$, and would use business travel downtime to get it done)
My first computers didn't have mice! Actually, when I first saw one, it seemed such a waste. So many resources required to make use of the thing. For programs? Sure. Graphics are fun with a mouse. Day to day computing? Pffft!
Took getting enough resources for that to change. And here we are.
I just don't see how some basic education in these ways and means hurts. It's part of a well rounded experience, and it opens doors for people they may seriously need to walk through at times too. The expectation is nice, new, spiffy stuff! The reality might just be stuff, not so spiffy, not so new. Don't they have to be at least minimally ready for that? Just in case?
Middle Schoolers?
Absolutely put 'em on a command line. They can handle it. Many of us did. The bonus for them today is Minecraft. They get that too. We got Rocky's Boots.... http://en.wikipedia.org/wiki/Rocky%27s_Boots
For them, interactive is killer! I assure you, they will either pick up on it and be interested, or not. And if interested, they will start inputting all kinds of stuff and will learn a ton, particularly given somebody to talk to while doing it. The usual, edit, compile, load, run, is fine. But, the little, random bites one can take on the command line is fine too. Not as scary as people think. Little, young brains can pack syntax in quite easily, and once they have that experience, it takes almost no time at all for it to be part of them, and that's all they need.
Same thing for the computer math. Hex, bits, bytes, etc... aren't that hard, and they are fun! Given someone has fun presenting them.
Anyway, seems someone has distilled Python down to some subset or other, and it seems it might fit into a P1. Not sure awesome things could be done on a Prop with that, but it also seems like it would deliver Python command line interactive on a P1, and on that basis, great! Maybe somebody will port it.
There is this too: Where does John Carmack start his kid?
Now I get back to Props and part of why they are great! A P1 can deliver this. Won't do much, but it can. And it doesn't need to do much. Once the idea of programming sinks in, move to a bigger / better tool and have at it. A little Python, that is interactive can do that, as can a BASIC, or whatever.
We know there is room for a BASIC and some reasonable program and graphics / sound / I/O to happen. We don't know there is room for a Python to deliver the same, but if there is, maybe it's not such a bad idea for middle schoolers.
Who really can do a command line. And should, if only for a while.
Slow day at the coal mine..........so why not try building PyMite!!
1) built Python 2.6.9 on my Raspi2
2) grabbed the files for PyMite
3) Started the build and boom! C errors:
cc -Wall -fno-strict-aliasing -Wstrict-prototypes -Wdeclaration-after-statement
-Werror -g -D__DEBUG__=1 -I/home/pi/python/python-on-a-chip/src/platform/desktop
64 -I../../vm -c -o sli.o sli.c
[highlight]
sli.c: In function ‘sli_strcmp’:
sli.c:94:17: error: comparison between pointer and integer [-Werror]
sli.c:94:36: error: comparison between pointer and integer [-Werror]
sli.c: In function ‘sli_ltoa10’:
sli.c:187:5: error: this decimal constant is unsigned only in ISO C90 [-Werror]
[/highlight]
cc1: all warnings being treated as errors
<builtin>: recipe for target 'sli.o' failed
make[2]: *** [sli.o] Error 1
Here's the code from sli.c
int
sli_strcmp(char const *s1, char const *s2)
{
/* While not at either strings' end and they're same */
[highlight]while ((*s1 != C_NULL) && (*s2 != C_NULL) && (*s1 == *s2))[/highlight]
{
s1++;
s2++;
}
/* Return string difference */
return *s1 - *s2;
}
...and....
/* Special case (can't convert it to positive value) */
[highlight] if (number == -2147483648)[/highlight]
{
sli_memcpy(buf, (unsigned char *)"-2147483648", 11);
return PM_RET_OK;
}
C doesn't like me so I'm not even going to bother.........
If you can fix up the make file to stop warnings being treated as errors it might work just fine.
This isn't really a good practice. Better to fix these bugs so you don't end up missing a warning that signifies something that could really cause you trouble in the sea of warnings that you're ignoring. What is the definition for C_NULL? What is the type of "number"?
This isn't really a good practice. Better to fix these bugs so you don't end up missing a warning that signifies something that could really cause you trouble in the sea of warnings that you're ignoring. What is the definition for C_NULL? What is the type of "number"?
I'm still looking at the source....I'm not the quickest with C. My intent is to fix it.......
I realize that is not the proper way to fix the problem but in the mean time, I "Heater-ized" the make file.
Silly me! I thought we were talking about a way to get Python running on the Propeller so kids could learn to program in general with some Prop/MCU specific capabilities. I didn't know we were talking about a PC hosted code generation tool to create code in some other language that just happened to be written in Python because Python is a good embeddable scripting language.
Sure, Python on a workstation is a great choice for that! It's a really good way to develop tools and provide a pythonic domain specific language.....once the folks have learned some Python somehow.
Python is also a great learning language if it can retain all the things that make it Python: REPL, full object support, simple syntax, etc. Once you make a non-Python, you've lost any advantage to using it as a learning language (IMHO).
myhdl looks like a brilliant implementation of a domain specific tool with embedded Python, I'll certainly check this out! But it certainly isn't a route for new programmers to learn the basics of programming.
Now you are getting much closer to the idea. ( You missed mention of the code-testing features.)
Notice those asking Ken, were not saying the Prop was to be the first and only teaching vehicle, they simply wanted a means to use what students had already learnt elsewhere.
( There are 5M+ RaspPi's out there too, remember., and zillions more PCs, and this is not development fully hosted on the Prop.
Others took that tack, I think it is smarter to pair the prop with a proper development resource on a PC, a best of both worlds approach ...)
I agree, myhdl is a brilliant implementation of a domain specific tool with embedded Python.
Ultimately I'm with David that disabling/ignoring such warnings is not the best idea and should be addresses properly at some point.
On the other hand I remember when C compilers were more like JavaScript. They would compile any old junk and leave it to you to debug the problems at run time. None of this modern day nannying
Well, flagging errors is certainly better than trying to fix them. I still cringe at the memory of PL/S, the student version of PL/1. Its compiler would try to figure out what you meant if you made an error, patch your program, and keep going. It was virtually always wrong.
Ultimately I'm with David that disabling/ignoring such warnings is not the best idea and should be addresses properly at some point.
On the other hand I remember when C compilers were more like JavaScript. They would compile any old junk and leave it to you to debug the problems at run time. None of this modern day nannying
It does now build cleanly with the change to the make file. I need to find my MBED board (the only supported platform I think I have) so I can build a VM for the MBED and download it.
Once I have that, I can actually try and test it. Now, where is that little box........
Its compiler would try to figure out what you meant if you made an error, patch your program, and keep going. It was virtually always wrong.
My current favourite language, JavaScript, goes one better. If you are a beginner and missing out semicolons here and there it will try and guess where they should be and put them in. Unlike PL/S it is only sometimes wrong. Which can make life very interesting....
Ok, let me qualify that a little bit. FINALLY, I was able to run ipm, the Pymite interactive REPL, on my Raspberry Pi and type in Python code that was executed on my MBED running the Pymite VM!!!
It was a convoluted royal pain in the butt to get there but there I got!
Now all we need to do is port the VM to the Propeller and make the tool chain and process usable. Yeah, that's all!
I'll start a Propeller Pymite thread in the morning.
I need to dig in my toy box to see if I have any other platforms that have Pymite VMs.
bumping this with news/links from another forum...
Pycom
Pycom collaborates on single port of MicroPython for the ESP32
Jan 25, 2017 https://www.pycom.io/pycom-collaborates-single-port-micropython-esp32/
...
We are pleased to confirm that after further discussions with Damien George, we have decided to work together on a single Port of MicroPython for the Espressif ESP32.
...
Pycom is committed to propagating MicroPython amongst the IoT industry as we firmly believe this great language is the ideal solution for rapid product development in an already complex space.
...
MicroPython ported to the ESP32 https://github.com/micropython/micropython-esp32 https://github.com/pycom
bumping this with news/links from another forum...
Pycom
Pycom collaborates on single port of MicroPython for the ESP32
Jan 25, 2017 https://www.pycom.io/pycom-collaborates-single-port-micropython-esp32/
...
We are pleased to confirm that after further discussions with Damien George, we have decided to work together on a single Port of MicroPython for the Espressif ESP32.
...
Pycom is committed to propagating MicroPython amongst the IoT industry as we firmly believe this great language is the ideal solution for rapid product development in an already complex space.
...
MicroPython ported to the ESP32 https://github.com/micropython/micropython-esp32 https://github.com/pycom
ESP32 has (broadly) similar CPU resource to a P2, but has only 2 cores and no USB ability.
A P2 port of this could be possible ?
There might not be enough memory on a P2. I think the ESP32 has 512k of RAM but pretty much as much flash as you want. You'd have to find out how much code space is required for MicroPython.
Comments
Silly me! I thought we were talking about a way to get Python running on the Propeller so kids could learn to program in general with some Prop/MCU specific capabilities. I didn't know we were talking about a PC hosted code generation tool to create code in some other language that just happened to be written in Python because Python is a good embeddable scripting language.
Sure, Python on a workstation is a great choice for that! It's a really good way to develop tools and provide a pythonic domain specific language.....once the folks have learned some Python somehow.
Python is also a great learning language if it can retain all the things that make it Python: REPL, full object support, simple syntax, etc. Once you make a non-Python, you've lost any advantage to using it as a learning language (IMHO).
myhdl looks like a brilliant implementation of a domain specific tool with embedded Python, I'll certainly check this out! But it certainly isn't a route for new programmers to learn the basics of programming.
This sounds like:
Interesting!
That might actually fit in a P1 right now.
Well, when somebody actually makes a serviceable GUI for regex, then we've made sufficient progress for the GUI to be comparable to the command line. I've not seen we are there yet.
This is not an anti GUI statement. I like GUI environments a lot. Often, I'm doing things that don't need so much expressive syntax, and I'm happy to operate in the nice environment and get the nice help it can provide. No worries.
But, when I'm faced with something new, I always ask where the command line is and how it works. I ask, because it's basic info I may need or want. And if it doesn't have one, then it doesn't have one, but then it's on my "keep an eye on this" list, because somebody somewhere will make one that does.
In terms of the basic education people need, I think they need the command line. For a while. Nobody cares what they do, other than we want them successful. And we want them to have the max ability to be successful, and understanding command line operation is important.
I was part of an ugly data migration and translation of some seriously large and messy CAD data sets a few years back. Was on IRIX too. (which was fun, because IRIX is awesome) The guy who got called into assist with this had developed a pile of the code being used. Let's just say the quantity and quality of mess was beyond even his expectations.
So there we are, and we realize it's gonna take some code. New code.
He asked about tools, and I fetched gcc and set it up for him as this site didn't have a license for MipsPro. Notice he didn't ask about a specific set of tools, just tools. What can he program with? That's a programmer. If gcc were not on the table, he would have used Perl, or whatever else he could find on that box.
What does this guy do? He cracks open a few XTerms via the X Window system in use there, and sets about authoring the new code and modifying his existing, which he pulled down from some private repository. First a build of existing and test. Done, works, spiffy! Then, it's get the new done.
Tools? Vi + Gcc and friends. That's it. Took him about 4 hours to get it done, and I was there watching as he almost never picked up the mouse. In fact, the mouse was just a tool to switch windows to switch command lines, and for a brief moment, wondered if it were not possible to make a quick program to change window focus...
If he were on a console, he would be using the Fkey terminal set to get this done, but a desktop was just fine, as was a modem running at a few Kb / sec. Would not have mattered one bit. He didn't ask about an editor or IDE.
Of course, I asked about this, and his reply:
I like vi, because it's fast, has the functions I need, and it's everywhere, and it always works.
I like terminals, because they have the functions I need, are everywhere, and they always work.
I like gcc, because it has the functions I need, is everywhere, and it always works.
I like UNIX, because it has a great command line, and nearly always works. But, it's not everywhere.
Really, it was hard to see being more productive. Very little time was wasted, and this guy is a programmer, and a mentor of mine, from time to time. I don't have that kind of skill, but I can see how it plays out, and it was definitely a good day. You can put this guy in front of Visual Studio, and he's gonna go to town there too. Doesn't matter much. Writing programs matters a lot.
When I program, I gotta work for it, and that's fine. I don't do it every day. But I do it a lot. And if I've got a terminal, then that's what I use. If I've got a GUI, that's what I use. Was mentored up to be tool independent, and OS independent (as possible) and that pays off big. Any of us here, who have had similar experiences, knows that.
Heck, I would regularly write scrips and little programs on UNIX boxes over free JUNO dialup in hotel rooms. 3Kb / sec tops. You can bet good old vi was the tool. What else could be? (yes, there are a few options, but not GUI ones) And that was an adventure. Fire up JUNO, check e-mail, bury the browser and it's ADS, then use what's left of the connection to do stuff. Not much left. But it was totally free, and this was the mid 90's. There were a lot of boxes with SSH tunnels and such, and quite a few with modems too.
(I was doing some admin on the side for extra $$$, and would use business travel downtime to get it done)
My first computers didn't have mice! Actually, when I first saw one, it seemed such a waste. So many resources required to make use of the thing. For programs? Sure. Graphics are fun with a mouse. Day to day computing? Pffft!
Took getting enough resources for that to change. And here we are.
I just don't see how some basic education in these ways and means hurts. It's part of a well rounded experience, and it opens doors for people they may seriously need to walk through at times too. The expectation is nice, new, spiffy stuff! The reality might just be stuff, not so spiffy, not so new. Don't they have to be at least minimally ready for that? Just in case?
Middle Schoolers?
Absolutely put 'em on a command line. They can handle it. Many of us did. The bonus for them today is Minecraft. They get that too. We got Rocky's Boots.... http://en.wikipedia.org/wiki/Rocky%27s_Boots
For them, interactive is killer! I assure you, they will either pick up on it and be interested, or not. And if interested, they will start inputting all kinds of stuff and will learn a ton, particularly given somebody to talk to while doing it. The usual, edit, compile, load, run, is fine. But, the little, random bites one can take on the command line is fine too. Not as scary as people think. Little, young brains can pack syntax in quite easily, and once they have that experience, it takes almost no time at all for it to be part of them, and that's all they need.
Same thing for the computer math. Hex, bits, bytes, etc... aren't that hard, and they are fun! Given someone has fun presenting them.
Anyway, seems someone has distilled Python down to some subset or other, and it seems it might fit into a P1. Not sure awesome things could be done on a Prop with that, but it also seems like it would deliver Python command line interactive on a P1, and on that basis, great! Maybe somebody will port it.
There is this too: Where does John Carmack start his kid?
http://www.cultofmac.com/313160/doom-makers-weapon-choice-teaching-coding-apple-iic/
Same place he did. Interesting.
Now I get back to Props and part of why they are great! A P1 can deliver this. Won't do much, but it can. And it doesn't need to do much. Once the idea of programming sinks in, move to a bigger / better tool and have at it. A little Python, that is interactive can do that, as can a BASIC, or whatever.
We know there is room for a BASIC and some reasonable program and graphics / sound / I/O to happen. We don't know there is room for a Python to deliver the same, but if there is, maybe it's not such a bad idea for middle schoolers.
Who really can do a command line. And should, if only for a while.
1) built Python 2.6.9 on my Raspi2
2) grabbed the files for PyMite
3) Started the build and boom! C errors:
Here's the code from sli.c
int sli_strcmp(char const *s1, char const *s2) { /* While not at either strings' end and they're same */ [highlight]while ((*s1 != C_NULL) && (*s2 != C_NULL) && (*s1 == *s2))[/highlight] { s1++; s2++; } /* Return string difference */ return *s1 - *s2; }...and..../* Special case (can't convert it to positive value) */ [highlight] if (number == -2147483648)[/highlight] { sli_memcpy(buf, (unsigned char *)"-2147483648", 11); return PM_RET_OK; }C doesn't like me so I'm not even going to bother.........
Thoughts? Suggestions? Corrections?
I see "cc1: all warnings being treated as errors"
If you can fix up the make file to stop warnings being treated as errors it might work just fine.
I'm still looking at the source....I'm not the quickest with C. My intent is to fix it.......
I realize that is not the proper way to fix the problem but in the mean time, I "Heater-ized" the make file.
Now you are getting much closer to the idea. ( You missed mention of the code-testing features.)
Notice those asking Ken, were not saying the Prop was to be the first and only teaching vehicle, they simply wanted a means to use what students had already learnt elsewhere.
( There are 5M+ RaspPi's out there too, remember., and zillions more PCs, and this is not development fully hosted on the Prop.
Others took that tack, I think it is smarter to pair the prop with a proper development resource on a PC, a best of both worlds approach ...)
I agree, myhdl is a brilliant implementation of a domain specific tool with embedded Python.
Ultimately I'm with David that disabling/ignoring such warnings is not the best idea and should be addresses properly at some point.
On the other hand I remember when C compilers were more like JavaScript. They would compile any old junk and leave it to you to debug the problems at run time. None of this modern day nannying
-Phil
It does now build cleanly with the change to the make file. I need to find my MBED board (the only supported platform I think I have) so I can build a VM for the MBED and download it.
Once I have that, I can actually try and test it. Now, where is that little box........
Ok, let me qualify that a little bit. FINALLY, I was able to run ipm, the Pymite interactive REPL, on my Raspberry Pi and type in Python code that was executed on my MBED running the Pymite VM!!!
It was a convoluted royal pain in the butt to get there but there I got!
Now all we need to do is port the VM to the Propeller and make the tool chain and process usable. Yeah, that's all!
I'll start a Propeller Pymite thread in the morning.
I need to dig in my toy box to see if I have any other platforms that have Pymite VMs.
Pycom
Pycom collaborates on single port of MicroPython for the ESP32
Jan 25, 2017
https://www.pycom.io/pycom-collaborates-single-port-micropython-esp32/
...
We are pleased to confirm that after further discussions with Damien George, we have decided to work together on a single Port of MicroPython for the Espressif ESP32.
...
Pycom is committed to propagating MicroPython amongst the IoT industry as we firmly believe this great language is the ideal solution for rapid product development in an already complex space.
...
MicroPython ported to the ESP32
https://github.com/micropython/micropython-esp32
https://github.com/pycom
https://en.wikipedia.org/wiki/ESP32
ESP32 has (broadly) similar CPU resource to a P2, but has only 2 cores and no USB ability.
A P2 port of this could be possible ?
We shall see....