Breaking News
Comments
Newest First | Oldest First | Threaded View
Page 1 / 4   >   >>
Charles.Bagnall
User Rank
Rookie
further comments
Charles.Bagnall   1/9/2014 1:25:49 PM
NO RATINGS
MicroPython points in an interesting and long overdue direction in the embedded field: Simplicity and Directness!  I'm thinking of the benefits of interpreted execution.  And I believe this could be positive not only for hackers, makers, students and all the "new brew" folks in this field, but even the hard-boiled professionals, who - by all reports - could use a hand in getting the job done right! 

So, kudos to Damien George for getting this project going, and thanks to Caleb for the article bringing some attention in this direction.

TonyTib
User Rank
CEO
Re: Hmmm, we'll see
TonyTib   12/11/2013 12:30:30 PM
NO RATINGS
Some more feedback:

I'm still a bit skeptical, but Bogdan Marinescu (one of the principal eLua developers) has a high regard for Damian the MicroPython developer.

eLua has already been ported to mbed (although it really needs a mbed targer with >= 64K SRAM), and you should see better eLua on mbed support in the future.


Sometime (yeah, maybe next year) I'll have to check out the mbed ecosystem.

EdwinBland
User Rank
Rookie
Re: uPython close to C speeds
EdwinBland   12/6/2013 12:21:50 PM
NO RATINGS
@alex_m1

Hey... that's promising from the FAQ:  "Micro Python also includes a complete compiler (which is why we can do the CALL_METHOD trick), whereas PyMite does not. Micro Python can compile to native machine code." 

ref: Update #12.  The C API appears to be very similar to normal Python's C extensions. 

ref: Update #7. Inline assembler is a nice concept.

So in concept(python extension code reuse)... a bunch of methods which previously were residing in a python extension (written in C) could be directly compiled to run within the MicroPython environment...   Assuming of course no hardware dependencies/incompatibilities...etc.

I'd like to play with this... it sounds promising. 

Tx for the clarification Alex.

 

 

 

alex_m1
User Rank
CEO
Re: uPython close to C speeds
alex_m1   12/6/2013 10:56:16 AM
NO RATINGS
@EdwinBland: MicroPython is not about extension.It's about compiling python to near c speed. Have a look at the kickstarter.

EdwinBland
User Rank
Rookie
uPython close to C speeds
EdwinBland   12/6/2013 10:08:22 AM
NO RATINGS
I suspect the author is referring to writing python extensions.  In the linux environment this is often compiled as a shared library with a glue layer interface written in C to bridge the environments.   It's conceivable this could also be implemented on a uC.   The code which needs to be optimized for speed could be compiled into the extension code library.  I suspect there's a fair amount of effort for this.

 

 

alex_m1
User Rank
CEO
Re: Hmmm, we'll see
alex_m1   12/5/2013 3:38:32 PM
NO RATINGS
@TonyTib, Those all seem like interesting  and useful architectures. It would be interesting to run something like micro python on a beagle bone for example.

Yes dynamic capabilities are helpfull. But there are many other things that make python so simple and powerfull and many of them could apply even in simpler code.


For example: http://www.kickstarter.com/projects/214379695/micro-python-python-for-microcontrollers/posts/675393

TonyTib
User Rank
CEO
Re: Hmmm, we'll see
TonyTib   12/5/2013 12:55:19 PM
NO RATINGS
Well, the BeagleBone has some real time options such as real time Linux (LinuxCNC has been ported), and no OS (using TI's StarterWare, although I haven't heard of anyone doing that.)

It also has a 200MHz co-processor (the PRU) that can toggle I/O's in the multi-megahertz range; several projects are using it for stepper motor control.  On the other hand, I'm sure programming the PRU isn't as easy as Python.

If the Beagle group creates a new 'Bone based on TI's upcoming AM5x MPU,it'll have dual core ARM goodness.

Another interesting option (and one I'll probably try, since I already have a RPi) is combining the RPi with the XMOS startKit, which can definitely do very high speed bit-banging but should be easier to program than the PRU.


Frankly, for simple bit-banging pretty much any language will do; Python's advantages come when you take advantage of its dynamic capabilities.


Too many fun options, too little time.

alex_m1
User Rank
CEO
Re: Hmmm, we'll see
alex_m1   12/5/2013 5:01:45 AM
NO RATINGS
@ewertz  I wonder how much percentage of designs are low/medium speed real-time, and how many are really fast,faster than what micro python might offer.

And If what is needed is hard and fast realtime , Something like a dual core microcontroller like the lpc43xx look usefull:

Big core runs python and complex software,second smaller core runs the real-time section written in c.

ewertz
User Rank
Manager
Re: Hmmm, we'll see
ewertz   12/4/2013 7:37:59 PM
NO RATINGS
This seems like it has the potential to run faster than current Python on something like the Pi/Beagle*.  In the latter case, one is running Python in userspace and having to go through the kernel and/or filesystem to get at the pins (and probably the peripherals).  MicroPython doesn't seem to have this (methinks substantial performance) limitation.

For 95+% of hobbyist/education applications either implementation is probably perfectly fine (most of which could probably run on a 1MHz 8080).  For high-speed control, neither Python-based system would probably be able to cut it.  It would depend entirely how any given application is partitioned, especially those that are running on top of an general-purpose OS.  In these cases, MicroPython may have the edge.  Moderate to high-speed control loops are probably iffy in both cases if the control comes back up into Python.  However, if the on-chip peripherals (or support circuitry) can do all of the "real" control work autonomously, then it pretty much doesn't matter what's running on top of it.

One could almost certainly bit-bang stuff faster with MicroPython, but beyond that, I'm unsure that it's a clear winner for much else other than its lower-power operation.  As is always the case, there are plenty more tools (debuggers, etc) that are going to run on the more PC-like Pi/Beagle* platforms than on the more deeply-embedded implementations -- which makes them substantially more usable for relative newbies.

The same basic argument holds for why the Pi won't/can't kill-off the Arduino -- for some things the latter just fits the problem better (at "1/500th of the performance" and 1/3 the price).

 

 

alex_m1
User Rank
CEO
Re: Hmmm, we'll see
alex_m1   12/4/2013 4:06:24 PM
NO RATINGS
LOL.

Page 1 / 4   >   >>


EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
Max Maxfield

Dr. Duino Diagnostic Shield Deduces Dilemmas in Arduino Shield Stacks
Max Maxfield
9 comments
As you are probably aware, I'm spending a lot of my free time creating Arduino-based projects, such as my Inamorata Prognostication Engine, my BADASS Display, and my Vetinari Clock.

EDN Staff

11 Summer Vacation Spots for Engineers
EDN Staff
20 comments
This collection of places from technology history, museums, and modern marvels is a roadmap for an engineering adventure that will take you around the world. Here are just a few spots ...

Glen Chenier

Engineers Solve Analog/Digital Problem, Invent Creative Expletives
Glen Chenier
15 comments
- An analog engineer and a digital engineer join forces, use their respective skills, and pull a few bunnies out of a hat to troubleshoot a system with which they are completely ...

Larry Desjardin

Engineers Should Study Finance: 5 Reasons Why
Larry Desjardin
46 comments
I'm a big proponent of engineers learning financial basics. Why? Because engineers are making decisions all the time, in multiple ways. Having a good financial understanding guides these ...

Flash Poll
Top Comments of the Week
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)