It really ought to be possible to run the minimal build on a P1 with an external flash chip.
So yes, getting a minimal build for P1 (and then P2) is probably a good idea to start this up.
The ability to access the FLASH as USB storage is obviously a matter for a bootloader and available memory/storage... A nice feature, but not pertinent to getting python running on current propeller boards. Though, you should always be looking forward.
dgately
Ya know... a HIGHLY useful thing would be a mqtt CLIENT for the p1.
Obviously some kinda wifi interface chip will need to interface between the p1 and the 'net.
cough*wx*
P2 mqtt server, with P1 mqtt slaves running all about?
MicroPython provides the normal Python 'Read-Eval-Print-Loop' command line on a serial port. Editors can use this to upload code to the board and run it, either once or by writing it to the flash as a MicroPython 'file'. The Thonny documentation describes the process - https://bitbucket.org/plas/thonny/wiki/MicroPython
I don't think any fancy USB mass storage mode or anything like that is required. Better to get the basics up and running first.
The MU editor does seem to be rather heavyweight, I think a browser based solution offers a better solutions, especially for the educational market that might use Chrome books and other lightweight computers.
It looks like the Mu installer includes a bunch of regular Python distribution files in its download. I think this could be pared down for used only with MicroPython, if a smaller download is required. Still, it's a 95MB download and 350MB installed, which isn't exactly huge.
RAM and CPU use on Windows:
-Mu native editor in Micro:bit mode - 66 MB, 0% CPU at idle
-Chrome, python.microbit.org - 334 MB, w/CPU use up to 13% at idle
-Firefox, python.microbit.org - 300 MB, w/CPU use up to 4% at idle
-Edge, python.microbit.org - 150 MB, w/CPU <1% at idle
Seems pretty lightweight to me comapred to almost any other modern Windows program.
As far a CircuitPython vs MicroPython - I wonder what Adafruit's thoughts are on accepting new boards into their upstream? I only see 1 non-Adafruit board listed as being supported, and it's referred to as a ""Third-party" or "non-Adafruit" boards". Personally I'd rather see P2 be an equal among MicroPython boards, vs being a "Third-party or non-Adafruit board" among CircuitPython boards.
I was chatting with a friend today and asked why his team had chosen to embed Lua as a scripting language in their software rather than Python, etc. He said he personally preferred something with a more C like syntax but Lua was far faster. I am rather lukewarm on Python despite its popularity. It is relitivly slow in execution and the 'the List is all data structures' sort of paradigm seemed an odd choice to me.
I was chatting with a friend today and asked why his team had chosen to embed Lua as a scripting language in their software rather than Python, etc. He said he personally preferred something with a more C like syntax but Lua was far faster. I am rather lukewarm on Python despite its popularity. It is relitivly slow in execution and the 'the List is all data structures' sort of paradigm seemed an odd choice to me.
Just throwing out Lua as another possibility...
"Everything is a list" sounds like LISP. However, I think Lua also has LISP-like features but with a more familiar syntax. You're right though, it would be good to make an attempt at porting Lua as well. Do you know if it is written in C or C++? We have a way to compile C for the P2 but not C++ currently.
I was chatting with a friend today and asked why his team had chosen to embed Lua as a scripting language in their software rather than Python, etc. He said he personally preferred something with a more C like syntax but Lua was far faster...
Lua was far faster than what ? Did he give specific numbers and platforms ?
The language itself does not determine speed, it is what happens downstream. Compiled languages will always be faster than byte-code ones.
As I said compared to Python, etc. In other words other byte-code interpreted languages. His exact quote is:
Speed. LUA blows Python away in the speed category. I really wanted a C syntax style scripting language like AngelScript. But none of them were even close to the speed of LUA.
This is for a motion control sw package on Windows.
In the MicroPython docs, they talk about having 3 levels of code 'emitters'.
The normal Python bytecode.
A 'native' emitter that puts out native ARM code
A 'Viper' emitter that puts out more optimized native ARM code, at the cost of some potential incompatibilities.
So it seems possible to start with the bytecode and move toward faster solutions later on, by implementing a native P2 emitter.
Inline assembly is also supported for ARM, and wraps nicely into Python functions, so a similar implentation could be used for P2.
I just watched a video last night from the author of micropython. He was talking about optimizations choices he made to get the thing to run on microcontrollers, and I'm pretty excited about what micropython can do.
I think it's going to going to be quite a good fit for propeller 2.
I'll link it here the minute I can find it in my viewing history.
I just watched a video last night from the author of micropython. He was talking about optimizations choices he made to get the thing to run on microcontrollers, and I'm pretty excited about what micropython can do.
Might be worth reaching out to him and see what his thoughts are about how best to get it to run on an 8 core uC.
He knows the codebase and the design decisions the best - he would be able to provide good insight as to the best way to make it fit.
I'd be happy to reach out but it would probably better if someone who had at least looked over the code or spoke any python did it ;-)
(apart from that, I'm already porting a different VM) ;-)
That is a great suggestion. My python skills are modest, but probably enough for this discussion.
It sure looks to me like he made a great set of trade-offs. You get most of python. And it's reasonably fast.
Just getting him to think about it a little is probably worth it.
Yeah red, I'm curious to see where you go with all that. The functional discussion was a big help. I sort of get it. I can see using the Elixir environment now and a little bit of how to do it. That's big progress, if you knew me in these things.
I did some playing around, the pattern matching is really insane. That and lists. It makes you think a different way. Now I'm not claiming to be able to get anything reasonable done yet, but I can see possibly doing it now.
I think the big brain block that we got unclogged with our nice conversation was that state is something to be managed, and there certain ways to do that to limit complexity and other issues.
When I approach these topics before, it was as if State didn't exist at all, and that's doesn't work. But, containing it in those agents, or whatever they're called I can't remember off hand right now, will be really interesting to see on this chip.
He did pack inline-assembly in there. Using a python ish kind of syntax. That has real potential on P2. PASM is going to be needed on this chip. At least for a while. Maybe a long while.
I've got an unrelated problem, that I'm thinking I may use Python to solve. This would be kind of a nice side discussion see where it goes.
Lachlan is in contact already with Damien George (above, in the video). He's aware of the P2 and has expressed some interest, but that's about all I know. I will be writing him a message this weekend.
Lachlan is in contact already with Damien George (above, in the video). He's aware of the P2 and has expressed some interest, but that's about all I know. I will be writing him a message this weekend.
Ken Gracey
Well I won't complicate things then. Let me know if I can help.
I emailed Damien in early November, after a bit of Python discussion with Ken back in March. Damien's busy on several fronts at the moment, as we all are really, but we will pick up the discussion again. Initial discussion was around a P2 emitter for LLVM
Please don't let this stop other discussion, approaches and/or efforts
Was he using a single or multi core processor in that video?
I would think all that time consuming or repetitive tasks would be best handled by the cogs.
One cog for Search, one for Read, maybe one cog that compiles or precompiles (whatever is done for the VM to run).
Oh, and one cog for the VM or maybe a few breaking down the tasks.
Maybe because I think the micropython kernel is currently written in C.
That's sort of what I meant when I mentioned getting C/C++ working. That would be a first step for porting MicroPython. However, it is also possible that MicroPython makes more direct use of LLVM although that seems somewhat unlikely.
Was he using a single or multi core processor in that video?
I would think all that time consuming or repetitive tasks would be best handled by the cogs.
One cog for Search, one for Read, maybe one cog that compiles or precompiles (whatever is done for the VM to run).
Oh, and one cog for the VM or maybe a few breaking down the tasks.
By VM I assume you mean the memory manager. That's tricky when you have multiple asynchronous processors accessing the same heap. I wonder if MicroPython is designed with that in mind? Does it support multiple threads?
Maybe because I think the micropython kernel is currently written in C.
That's sort of what I meant when I mentioned getting C/C++ working. That would be a first step for porting MicroPython. However, it is also possible that MicroPython makes more direct use of LLVM although that seems somewhat unlikely.
What I'd like to understand is the following:
- is LLVM the best tool to achieve the Python port? Is it the same tool Damien used when he created MicroPython?
- does it matter if we use the same compiler as Damien, if his is different? Would we have better results if we used the same compiler?
- could a P2 MicroPython be used with a tool like the Mu editor, if we made some modifications to do what we needed it to?
Do you intend MicroPython to be "self-hosted" like on the first microcomputers that started with a BASIC prompt, or compiled and edited on another device like SimpleIDE and BlockyProp, or both?
Maybe because I think the micropython kernel is currently written in C.
That's sort of what I meant when I mentioned getting C/C++ working. That would be a first step for porting MicroPython. However, it is also possible that MicroPython makes more direct use of LLVM although that seems somewhat unlikely.
What I'd like to understand is the following:
- is LLVM the best tool to achieve the Python port? Is it the same tool Damien used when he created MicroPython?
You just need a C compiler to port Python to the P2. LLVM may be a good way to make a C compiler for the P2 but GCC would also work. Which is best might depend on who you have to do the job. Both are likely a lot of work. You need to find people familiar with LLVM or GCC to do this. It sounds like Damian is familiar with LLVM but is he actually available to help create an LLVM-based P2 C compiler?
- does it matter if we use the same compiler as Damien, if his is different? Would we have better results if we used the same compiler?
Not necessarily. You need a good C compiler that targets the P2.
- could a P2 MicroPython be used with a tool like the Mu editor, if we made some modifications to do what we needed it to?
Sorry, I don't know anything about the Mu editor.
Comments
Ya know... a HIGHLY useful thing would be a mqtt CLIENT for the p1.
Obviously some kinda wifi interface chip will need to interface between the p1 and the 'net.
cough*wx*
P2 mqtt server, with P1 mqtt slaves running all about?
Rubs hand together in a very DR.EVILish way....
I don't think any fancy USB mass storage mode or anything like that is required. Better to get the basics up and running first.
It looks like the Mu installer includes a bunch of regular Python distribution files in its download. I think this could be pared down for used only with MicroPython, if a smaller download is required. Still, it's a 95MB download and 350MB installed, which isn't exactly huge.
RAM and CPU use on Windows:
-Mu native editor in Micro:bit mode - 66 MB, 0% CPU at idle
-Chrome, python.microbit.org - 334 MB, w/CPU use up to 13% at idle
-Firefox, python.microbit.org - 300 MB, w/CPU use up to 4% at idle
-Edge, python.microbit.org - 150 MB, w/CPU <1% at idle
Seems pretty lightweight to me comapred to almost any other modern Windows program.
Source for the web editor is here, probably wouldn't be that hard to modify it for use with P2 MicroPython - https://github.com/bbcmicrobit/PythonEditor
As far a CircuitPython vs MicroPython - I wonder what Adafruit's thoughts are on accepting new boards into their upstream? I only see 1 non-Adafruit board listed as being supported, and it's referred to as a ""Third-party" or "non-Adafruit" boards". Personally I'd rather see P2 be an equal among MicroPython boards, vs being a "Third-party or non-Adafruit board" among CircuitPython boards.
Just throwing out Lua as another possibility...
The language itself does not determine speed, it is what happens downstream. Compiled languages will always be faster than byte-code ones.
This is for a motion control sw package on Windows.
The normal Python bytecode.
A 'native' emitter that puts out native ARM code
A 'Viper' emitter that puts out more optimized native ARM code, at the cost of some potential incompatibilities.
So it seems possible to start with the bytecode and move toward faster solutions later on, by implementing a native P2 emitter.
Inline assembly is also supported for ARM, and wraps nicely into Python functions, so a similar implentation could be used for P2.
Andrew
I think it's going to going to be quite a good fit for propeller 2.
I'll link it here the minute I can find it in my viewing history.
Might be worth reaching out to him and see what his thoughts are about how best to get it to run on an 8 core uC.
He knows the codebase and the design decisions the best - he would be able to provide good insight as to the best way to make it fit.
I'd be happy to reach out but it would probably better if someone who had at least looked over the code or spoke any python did it ;-)
(apart from that, I'm already porting a different VM) ;-)
It sure looks to me like he made a great set of trade-offs. You get most of python. And it's reasonably fast.
Just getting him to think about it a little is probably worth it.
Yeah red, I'm curious to see where you go with all that. The functional discussion was a big help. I sort of get it. I can see using the Elixir environment now and a little bit of how to do it. That's big progress, if you knew me in these things.
I did some playing around, the pattern matching is really insane. That and lists. It makes you think a different way. Now I'm not claiming to be able to get anything reasonable done yet, but I can see possibly doing it now.
I think the big brain block that we got unclogged with our nice conversation was that state is something to be managed, and there certain ways to do that to limit complexity and other issues.
When I approach these topics before, it was as if State didn't exist at all, and that's doesn't work. But, containing it in those agents, or whatever they're called I can't remember off hand right now, will be really interesting to see on this chip.
Well volunteered
He did pack inline-assembly in there. Using a python ish kind of syntax. That has real potential on P2. PASM is going to be needed on this chip. At least for a while. Maybe a long while.
I've got an unrelated problem, that I'm thinking I may use Python to solve. This would be kind of a nice side discussion see where it goes.
Ken Gracey
Absolutely. We're getting asked a lot of questions about tools and many people want to participate.
We're still learning about the possibilities, potential contributors, etc. before we make decisions.
It is our intent to have some open discussions really soon, but we need to have some boards in people's hands first.
Ken Gracey
Well I won't complicate things then. Let me know if I can help.
Please don't let this stop other discussion, approaches and/or efforts
Lachlan
I would think all that time consuming or repetitive tasks would be best handled by the cogs.
One cog for Search, one for Read, maybe one cog that compiles or precompiles (whatever is done for the VM to run).
Oh, and one cog for the VM or maybe a few breaking down the tasks.
Worked very nicely.
What I'd like to understand is the following:
- is LLVM the best tool to achieve the Python port? Is it the same tool Damien used when he created MicroPython?
- does it matter if we use the same compiler as Damien, if his is different? Would we have better results if we used the same compiler?
- could a P2 MicroPython be used with a tool like the Mu editor, if we made some modifications to do what we needed it to?
Ken Gracey
Do you intend MicroPython to be "self-hosted" like on the first microcomputers that started with a BASIC prompt, or compiled and edited on another device like SimpleIDE and BlockyProp, or both?
Not necessarily. You need a good C compiler that targets the P2.
Ken Gracey[/quote]