Author Topic: Micropython for MCUs - is it real or experimental ?  (Read 18542 times)

0 Members and 1 Guest are viewing this topic.

Offline ez24Topic starter

  • Super Contributor
  • ***
  • Posts: 3082
  • Country: us
  • L.D.A.
Micropython for MCUs - is it real or experimental ?
« on: November 29, 2016, 06:19:20 am »
In an online intro course to MCUs, the instructor said that someday he will be talking about C/C++ and Python.  I did not think much about it until I came across this playlist by Adafruit.  It is 31 videos on micropython.



I am making an assumption that micropython is python programming for an MCU - right?

If so I was wondering if it can be an  alternative to C and Ardunio C++  ?   Could it be that it is like middle ground - better than Arduino language but easier than C for mentally challenged people?

Tomorrow I will start watching YT videos on micropython.

thanks
YouTube and Website Electronic Resources ------>  https://www.eevblog.com/forum/other-blog-specific/a/msg1341166/#msg1341166
 

Offline mtdoc

  • Super Contributor
  • ***
  • Posts: 3575
  • Country: us
Re: Micropython for MCUs - is it real or experimental ?
« Reply #1 on: November 29, 2016, 06:28:34 am »
Have a listen to this Amp Hour episode from 2 weeks ago and your questions will be answered.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Micropython for MCUs - is it real or experimental ?
« Reply #2 on: November 29, 2016, 06:38:09 am »
It can be an alternative to Arduino if you only use Arduino API and no custom code at all. And alternative as in "only suitable for hobby and toys, not a real production".

Also, MicroPython sacrifices quite a bit of actual Python, so you will always have to be aware of what you are doing and how much memory those things will consume. On a plus side, you will have to learn how to write very efficient Python code, a skill that will be useful for real Python programming :)
« Last Edit: November 29, 2016, 06:39:46 am by ataradov »
Alex
 

Online Berni

  • Super Contributor
  • ***
  • Posts: 4923
  • Country: si
Re: Micropython for MCUs - is it real or experimental ?
« Reply #3 on: November 29, 2016, 06:40:59 am »
You do realize that Arduino is just C with extra libraries added to make using hardware easier.

And its not like pyhton is that much easier, there are still plenty of complex things to wrap your head around. But it is a higher level language that is more comparable to C++.

The language that is best depends on the application. C is perhaps not the best choice for making big complex GUIs, but then again a a very high level language like pyhton might not be a good choice for 8 bit MCUs because it uses a lot of resources to do what it does and might not leave you with much memory left or eat too much CPU time. Its a matter of the right tool for the job.
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4067
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Micropython for MCUs - is it real or experimental ?
« Reply #4 on: November 29, 2016, 06:45:04 am »
Everything can be a suitable alternative for C/C++ if there will be proper cross-compiler.
Anything requiring an additional active translator or interpreter will have significant performance and space constraints.
However, for the scope of beginners training or arduino. This does not matter.

Back in high-school I've programmed a PIC with Java. It was slow, created a ginormous image compared to the tasks, but it was simple enough to understand. It came in Eclipse, with simulator. (that's why java)
 

Online e100

  • Frequent Contributor
  • **
  • Posts: 564
Re: Micropython for MCUs - is it real or experimental ?
« Reply #5 on: November 29, 2016, 07:13:48 am »
It's a derivative of Python.
The mains problem is that it's relatively slow at read/writing pins which can make it difficult to write device drivers.
Only a small subset of the Python libraries have been ported to Micropython.

Usable for I2C/SPI/UART devices or slow speed peripherals.
The interactive prompt allows you to try things without going through a compile/upload cycle.

 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: Micropython for MCUs - is it real or experimental ?
« Reply #6 on: November 29, 2016, 11:13:07 am »
...an  alternative to C and Ardunio C++  ?   Could it be that it is like middle ground - better than Arduino language but easier than C for mentally challenged people?

There is no such thing like "Arduino language". Arduino IDE is just a repack of the GCC toolchain (GCC is a C/C++ compiler ported for almost any processor and microcontroller) with a few libraries for the MCUs and a small editor on top. Arduino is using both C/C++.

Arduino sketches are using C, C++ or a combination of both.
 
The following users thanked this post: EBRAddict

Online e100

  • Frequent Contributor
  • **
  • Posts: 564
Re: Micropython for MCUs - is it real or experimental ?
« Reply #7 on: December 20, 2016, 02:27:28 pm »
There's an interesting talk given by Damien George, the creator of Micropython about the technical aspects of the implementation
It's free of hyperbole and explains when it would be a good or bad choice for projects.

« Last Edit: December 20, 2016, 05:01:22 pm by e100 »
 
The following users thanked this post: I wanted a rude username

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 7307
  • Country: nl
  • Current job: ATEX product design
Re: Micropython for MCUs - is it real or experimental ?
« Reply #8 on: December 20, 2016, 02:37:42 pm »
It's a derivative of Python.
The mains problem is that it's relatively slow at read/writing pins which can make it difficult to write device drivers.
Only a small subset of the Python libraries have been ported to Micropython.

Usable for I2C/SPI/UART devices or slow speed peripherals.
The interactive prompt allows you to try things without going through a compile/upload cycle.
A typical Python 2.7 interpreter was using some 10 MB of memory on linux the last time I checked it. Now, python is only useful, if you have the libraries, and the "infinite" memory and infinite processing power. i really dont see the point to run it without the operating system, and crippling it so you basically have to rewrite stuff.
 

Offline RGB255_0_0

  • Frequent Contributor
  • **
  • Posts: 772
  • Country: gb
Re: Micropython for MCUs - is it real or experimental ?
« Reply #9 on: December 20, 2016, 02:41:21 pm »
I think Lady Ada is sleeping with the creator as she's really pushing MicroPython in practically every video.
Your toaster just set fire to an African child over TCP.
 

Online e100

  • Frequent Contributor
  • **
  • Posts: 564
Re: Micropython for MCUs - is it real or experimental ?
« Reply #10 on: December 20, 2016, 04:59:20 pm »
I think Lady Ada is sleeping with the creator as she's really pushing MicroPython in practically every video.

Selling a $45 pyboard is probably a lot more profitable than selling yet another Arduino derivative when you have to compete against a sea of cheap Chinese clones.
 

Offline diyaudio

  • Frequent Contributor
  • **
  • !
  • Posts: 683
  • Country: za
Re: Micropython for MCUs - is it real or experimental ?
« Reply #11 on: December 20, 2016, 04:59:35 pm »
I think Lady Ada is sleeping with the creator as she's really pushing MicroPython in practically every video.
lol
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1663
  • Country: us
Re: Micropython for MCUs - is it real or experimental ?
« Reply #12 on: December 20, 2016, 07:00:53 pm »
I think Lady Ada is sleeping with the creator as she's really pushing MicroPython in practically every video.

Thanks. Now I'll have to find a way to purge that image from my mind.
Complexity is the number-one enemy of high-quality code.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: Micropython for MCUs - is it real or experimental ?
« Reply #13 on: December 20, 2016, 07:49:46 pm »
Arduino sketches are using C, C++ or a combination of both.

Arduino libs are C++ and the code is all compiled as C++, so you have classes and what not. Of course, most people using this rarely venture farther than some basic C-like code with it.
 

Offline rob77

  • Super Contributor
  • ***
  • Posts: 2085
  • Country: sk
Re: Micropython for MCUs - is it real or experimental ?
« Reply #14 on: December 20, 2016, 08:24:08 pm »
micropython is perfect for small projects involving high level data processing and network connectivity. the nodemcu/esp8266 with micropython is an order of magnitude more usable than with the lua or arduino firmware.
 

Offline julianhigginson

  • Frequent Contributor
  • **
  • Posts: 783
  • Country: au
Re: Micropython for MCUs - is it real or experimental ?
« Reply #15 on: December 20, 2016, 11:25:38 pm »
I think Lady Ada is sleeping with the creator as she's really pushing MicroPython in practically every video.

well, that was unnecessary....
 
The following users thanked this post: janoc, benst, Bassman59, newbrain

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: Micropython for MCUs - is it real or experimental ?
« Reply #16 on: December 20, 2016, 11:48:22 pm »
micropython is an interpreter ... like a java machine this is a python machine.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline rob77

  • Super Contributor
  • ***
  • Posts: 2085
  • Country: sk
Re: Micropython for MCUs - is it real or experimental ?
« Reply #17 on: December 21, 2016, 01:38:38 am »
micropython is an interpreter ... like a java machine this is a python machine.

python, perl, ruby, lua... most of high level languages are interpreted , that's a fact ;) no-one says interpreted languages are good for everything, but interpreted languages are great for many projects. not good for high speed IO bit banging, but even if you need high speed IO you still can write your own library/module in a low level language and use it from the interpreted language ;)
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: Micropython for MCUs - is it real or experimental ?
« Reply #18 on: December 21, 2016, 12:02:28 pm »
I can see this useful for a couple of things:

- Opening up the market even further for CS people to play with hardware (makes sense for Adafruit)

- Provide a scripting environment on a MCU, which can be useful for some general purpose boards, although it seems Micropython is a "one all be all" firmware of your MCU

- Quick & dirty projects that don't care about wasted resources and violation of the "no mem alloc" guideline on MCU's.

There are some niches and I might try it out someday, but for me it's applications are quite limited.
 

Offline julianhigginson

  • Frequent Contributor
  • **
  • Posts: 783
  • Country: au
Re: Micropython for MCUs - is it real or experimental ?
« Reply #19 on: December 21, 2016, 12:12:56 pm »
I left myself 24 hours to scratch my head on micropython, and while it seems like a really cool thing they have managed to get working, well, I really don't get it. As in, why would anyone use it - beyond playing about with it and toggling LEDs - to build something? even a prototype?

it seems that there's going to be a learning curve for this, even to people who use python regularly... so ... why would someone learn micropython when they could just learn c, and be working with a language that will give them so much more scope to grow past toggling a LED? (Then again that's also my argument about arduino/processing... ) 
 

Offline rob77

  • Super Contributor
  • ***
  • Posts: 2085
  • Country: sk
Re: Micropython for MCUs - is it real or experimental ?
« Reply #20 on: December 21, 2016, 01:46:24 pm »
I left myself 24 hours to scratch my head on micropython, and while it seems like a really cool thing they have managed to get working, well, I really don't get it. As in, why would anyone use it - beyond playing about with it and toggling LEDs - to build something? even a prototype?

it seems that there's going to be a learning curve for this, even to people who use python regularly... so ... why would someone learn micropython when they could just learn c, and be working with a language that will give them so much more scope to grow past toggling a LED? (Then again that's also my argument about arduino/processing... )

for example you need a wifi connected remote sensor - with an esp8266 and micropython you will have it up in running in few minutes. timers, network sockets, IO libraries - all are available in micropython... so what you need is "describe the functionality" in a nice object oriented way...  instead of "write the core functionality" in C, the most expensive part of every small project is the human effort, so if you can write your firmware in few lines of python code an save a day or two of coding and debugging, then why not ? . as mentioned it's ideal for small projects or standalone components of bigger ones.
 
The following users thanked this post: thm_w

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Micropython for MCUs - is it real or experimental ?
« Reply #21 on: December 21, 2016, 04:34:37 pm »
so if you can write your firmware in few lines of python code an save a day or two of coding and debugging, then why not ?
Because no one just makes simple Wi-Fi connected sensors each and every day. And when you need to add some real functionality, you will have to scrap that day of work and start writing things in real languages.

So all you've got is a fast satisfaction, but no actual result.
Alex
 
The following users thanked this post: julianhigginson

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: Micropython for MCUs - is it real or experimental ?
« Reply #22 on: December 21, 2016, 05:29:53 pm »
The nice thing is that micropython comes with a full blown networking stack , encryption and the whole hoopla. All the annoying crap nobody wants to deal with is already handled. you don't need to muck with libraries.

Here is a nice task to do : pick a cpu, slap on wifi and bluetooth. hook up a temperature/humidity/voc sensor. send data to a logging server. scatter 20 of these things around a building.

let's look at a few things:
- development time
- development tools
- cost of the hardware

i can do it with an epsressif ESP32 ( 180 MHz SOC with wif and bluetooth embedded ) and a bosh BM280 environmental sensor. hardware cost  : 4 to 5$

Development time : open i2c port , read bytes , send them through json packager and blast them into a socket instance. It's all there. the whole program is barely 30 lines of code. including network protection and encryption.

Development tools needed : a computer with a terminal program. i don't need no stinking compiler , no stinking debugger, no stinking ide , no stinking jtag dongle. no stinking wires no stinking serial port.

i can write, edit, trace directly over the bluetooth or wifi serial port emulator. firmware is updated over the air.

Try doing that with your devtools.

It may not work for all cases but for small systems that do processing at the node and send data to an aggregator :perfect.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 
The following users thanked this post: rob77, Howardlong, newbrain, julianhigginson, I wanted a rude username

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 7307
  • Country: nl
  • Current job: ATEX product design
Re: Micropython for MCUs - is it real or experimental ?
« Reply #23 on: December 21, 2016, 08:06:51 pm »
i can do it with an epsressif ESP32 ( 180 MHz SOC with wif and bluetooth embedded ) and a bosh BM280 environmental sensor. hardware cost  : 4 to 5$
IDK, but I have trouble sourcing the ESP32 for the moment.
It will run this micropython? Out of the box?
 

Offline julianhigginson

  • Frequent Contributor
  • **
  • Posts: 783
  • Country: au
Re: Micropython for MCUs - is it real or experimental ?
« Reply #24 on: December 22, 2016, 12:42:17 am »
The nice thing is that micropython comes with a full blown networking stack , encryption and the whole hoopla. All the annoying crap nobody wants to deal with is already handled. you don't need to muck with libraries.

But surely at some point - SOMEONE has to get drivers for the processor up and runnning? someone has to get libraries included, compiling, and more importantly thoroughly debugged.

the executive for python has to be able to run on the chip, talk to any on chip peripheral you need, manage memory allocation, map any sleep commands that the "OS" supports to the specific sleep functionality of the processor...

So in this case, if I have a processor that someone's gone and spent a bunch of time adding all this stuff in and getting it working, then yeah. I guess it'd be cool (but god help me if there's any bugs under that huge rug that literally all the hardware has been swept under!)

Compare to freeRTOS which also gives you this stuff, with its own API for the features that will be about the same as the micropython hardware API. except freeRTOS is years older, and so years more developed, with support all over the place for numerous chips (actively supported and encouraged for use by most cortex M manufacturers!) And if you have a problem with FreeRTOS, it's all there in your project to dig into and look at if needed


Quote
Here is a nice task to do : pick a cpu, slap on wifi and bluetooth. hook up a temperature/humidity/voc sensor. send data to a logging server. scatter 20 of these things around a building.

let's look at a few things:
- development time
- development tools
- cost of the hardware

i can do it with an epsressif ESP32 ( 180 MHz SOC with wif and bluetooth embedded ) and a bosh BM280 environmental sensor. hardware cost  : 4 to 5$

you can use these parts with a C compiler, too.

Quote
Development time : open i2c port , read bytes , send them through json packager and blast them into a socket instance. It's all there. the whole program is barely 30 lines of code. including network protection and encryption.

working with FreeRTOS will be similar.

Quote
Development tools needed : a computer with a terminal program. i don't need no stinking compiler , no stinking debugger, no stinking ide , no stinking jtag dongle. no stinking wires no stinking serial port.

mbed might be OK for a simple toy application like this... and that's a similar deal.
hell, it already has example apps from microsoft and IBM for sending this kind of data vial MQTT or HTTP REST(or AMQP with azure) all the way to azure or watson.

OK, it wont support ESP32 specifically, as that's some weird non-ARM architecture. But maybe the Realtek part will get mbed support some time? otherwise, use nearly ANY arm cortex part with a $2 ESP8266 module.

Quote
i can write, edit, trace directly over the bluetooth or wifi serial port emulator. firmware is updated over the air.

Try doing that with your devtools.

OK, now using serial port debugging from inside your python application, you try tracing what happens when the I2C driver compiled into the executive messes up underneath your python code for some reason, and you can only read zeros from your sensor...

or the memory allocation code screws up in some funny way on your particular target?

Or the way the generic OS sleep functionality is mapped to the specific features of your particular target is not right for some specific setting that the executive picks without telling you when you call a generic sleep/wait function?

And having all the relevant code for even looking at what might actually be happening under your application locked away in a separate project that you have no direct access to, no easy way to trace into it from your application code, and no experience with the language it's written in?
 :box:

Quote
It may not work for all cases but for small systems that do processing at the node and send data to an aggregator :perfect.

Don't get me wrong - I really love fast prototyping capabilities in modern software dev offerings... and I may even get a micropython dev board to play with some time.... My main issue is this is so far removed from normal embedded tools, that you're really going out on a limb just to learn it and really limiting your options when something goes wrong. For similar effort, you could just learn an embedded development language and basic techniques that have been proven over literally 5 decades of use.

To me, as neat a solution as it may be, it just looks like "IoT toy for web developer who wants to think they're a hardware person" same deal as that Tessel javascript board. It may be neat, beautiful, and elegant, but at the end of the day, it's a neat beautiful elegant cage.
« Last Edit: December 22, 2016, 03:44:27 am by julianhigginson »
 

Online e100

  • Frequent Contributor
  • **
  • Posts: 564
Re: Micropython for MCUs - is it real or experimental ?
« Reply #25 on: December 22, 2016, 03:13:21 am »
Perhaps the most important question is, does it work well enough to get the job done?
The European Space Agency asked the same question back in 2015 with regards to using Micropython on space qualified hardware.
So far I'm not aware of any conclusions from that investigation, but the fact that they even bothered to fund an investigation would indicate that they saw a potential cost saving over using traditional tools.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Micropython for MCUs - is it real or experimental ?
« Reply #26 on: December 22, 2016, 03:16:30 am »
but the fact that they even bothered to fund an investigation
Means that bureaucracy did its job and someone got paid to do pointless work. They will never approve this thing for anything space related. Half of the C standard is not approved for normal automotive use via MISRA-C. I can't see a dynamic language getting anywhere close to space stuff.
Alex
 
The following users thanked this post: Kjelt

Online e100

  • Frequent Contributor
  • **
  • Posts: 564
Re: Micropython for MCUs - is it real or experimental ?
« Reply #27 on: December 22, 2016, 04:29:46 am »
but the fact that they even bothered to fund an investigation
Means that bureaucracy did its job and someone got paid to do pointless work. They will never approve this thing for anything space related. Half of the C standard is not approved for normal automotive use via MISRA-C. I can't see a dynamic language getting anywhere close to space stuff.

There are already cubesats using commodity hardware and software.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Micropython for MCUs - is it real or experimental ?
« Reply #28 on: December 22, 2016, 04:33:10 am »
There are already cubesats using commodity hardware and software.
You are mixing toys that live 2 weeks and cost next to nothing with long term missions. The former ones can be made of anything, it does not matter. The later ones will never run Python of any kind for mission critical stuff.
Alex
 

Online e100

  • Frequent Contributor
  • **
  • Posts: 564
Re: Micropython for MCUs - is it real or experimental ?
« Reply #29 on: December 22, 2016, 04:45:17 am »
There are already cubesats using commodity hardware and software.
You are mixing toys that live 2 weeks and cost next to nothing with long term missions. The former ones can be made of anything, it does not matter. The later ones will never run Python of any kind for mission critical stuff.

The current launch cost of a cubesat is about $40,000.
I would say that some of the organisations flying cubesats would be offended if you described their projects as toys.
« Last Edit: December 22, 2016, 04:46:48 am by e100 »
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Micropython for MCUs - is it real or experimental ?
« Reply #30 on: December 22, 2016, 04:47:04 am »
The current launch cost of a cubesat is about $40000.
And the Curiosity rover costs $2.5 Billion.

And I'm pretty sure they are overpaying at that price.

I would say that some of the organisations flying cubesats would be offended if you described their projects as toys.
Their problem, not mine.
Alex
 

Offline rob77

  • Super Contributor
  • ***
  • Posts: 2085
  • Country: sk
Re: Micropython for MCUs - is it real or experimental ?
« Reply #31 on: December 22, 2016, 11:24:12 am »
The current launch cost of a cubesat is about $40000.
And the Curiosity rover costs $2.5 Billion.

And I'm pretty sure they are overpaying at that price.

I would say that some of the organisations flying cubesats would be offended if you described their projects as toys.
Their problem, not mine.

man you're stupidly biased against micropython and talking any kind of bullshit just to "be right"  :-DD who the hell suggested micropython for a $2.5 billion project ? you mixing up anything just to "keep your ground" and ignoring the fact that micropython might be, and actually IS useful for many small projects.
 

Offline ehughes

  • Frequent Contributor
  • **
  • Posts: 409
  • Country: us
Re: Micropython for MCUs - is it real or experimental ?
« Reply #32 on: December 22, 2016, 03:47:20 pm »
It is academically interesting but kinda useless for anything real. I honestly can't see the benefit of it. All of the examples are doing such trivial thing that are easy to do in a real language.  It has to be stripped down to a level where you lose all of the benefits of a dynamic language.     It is a lot of code just to be able to slowly twiddle bits on a 32-bit processor.  That you you really don't get that much space to run code.      You could run a small Cortex A5 and get real python. 

For Space you don't willy nilly can code and see what happens.   That is such poor engineering discipline.    If you need the ability to change code that much in flight there a serious problem on the design side.

.....That and I am highly offended by the significance of white space in code.  It is literally the dumbest thing you could possible do in a language design.       Invisible things should never, ever control execution flow.   The whole "it makes nice looking code" is really ridiculous given that I can run things through astyle.         I have literally witnessed engineers puzzling over a mistaken indent causing function problems.    This may work for hispster web programmers but I have yet to meet someone who does serious embedded work who finds this acceptable.     

Having a dynamic scripting language is a nice tool, but Python is a bad choice for embedded.      That and I really like Julia now for my scripts....  It actually runs at a reasonable rate and provides advantages over C for high end computing.

 

Offline rob77

  • Super Contributor
  • ***
  • Posts: 2085
  • Country: sk
Re: Micropython for MCUs - is it real or experimental ?
« Reply #33 on: December 22, 2016, 04:31:21 pm »
It is academically interesting but kinda useless for anything real. I honestly can't see the benefit of it. All of the examples are doing such trivial thing that are easy to do in a real language. 

ok first please define "real language"...

and once again, one single example... Espressif ESP8266 - millions of chips produced, so don't tell me it's not real. and now show me the advantages of maintaining a toolchain , writing code in "real" language  and reading many pages of datasheets to make the hardware work in your code in your "real" language (wifi anyone ?  >:D ) .

further advantage is a very easy and risk-free remote firmware upgrade.. you're changing your high level code (in fact a single file on the internal filesystem) and not reflashing the OS/runtime.

and once again and slowly... no-one is suggesting to use micropython in time critical applications or complex projects...
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: Micropython for MCUs - is it real or experimental ?
« Reply #34 on: December 22, 2016, 05:13:19 pm »
Espressif ESP8266 - millions of chips produced, so don't tell me it's not real.
ESP8266 is not an MCU.
 

Offline rob77

  • Super Contributor
  • ***
  • Posts: 2085
  • Country: sk
Re: Micropython for MCUs - is it real or experimental ?
« Reply #35 on: December 22, 2016, 05:42:39 pm »
Espressif ESP8266 - millions of chips produced, so don't tell me it's not real.
ESP8266 is not an MCU.

and what is it then ? it's a 32bit MCU accompanied with a wifi chip.
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: Micropython for MCUs - is it real or experimental ?
« Reply #36 on: December 22, 2016, 06:00:11 pm »
it's a 32bit MCU accompanied with a wifi chip.
and 512k of external ROM containing the firmware that makes it an ESP8266. It is no more an MCU than Raspberry Pi, Teensy or Arduino is an MCU.



 
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Micropython for MCUs - is it real or experimental ?
« Reply #37 on: December 22, 2016, 06:02:27 pm »
that makes it an ESP8266
ESP8266 is a chip. It does need external components to operate, but the name ESP8266 belongs to a chip. The modules have different names.
Alex
 

Offline dferyance

  • Regular Contributor
  • *
  • Posts: 178
Re: Micropython for MCUs - is it real or experimental ?
« Reply #38 on: December 22, 2016, 06:30:36 pm »
The nice thing is that micropython comes with a full blown networking stack , encryption and the whole hoopla. All the annoying crap nobody wants to deal with is already handled. you don't need to muck with libraries.
....

But all you described was exactly that; libraries. Networking stack, is a library, encryption is a library, wifi is a library. They might be great and easy to use libraries and that has merit, but none of that is unique to python. Having lots of pre-built easy-to-use libraries is a large part of the appeal of Arduino and that uses C++.

I like toy projects like this though. It is a fun challenge and cool to tinker with. But let's be realistic; this is making a major trade-off to be able to use python code that just isn't worth it. As long as it is a fun project to play with there is nothing wrong with it. But the mistake is when it is used as a crutch for people who refuse to learn C or anything new to them.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: Micropython for MCUs - is it real or experimental ?
« Reply #39 on: December 22, 2016, 06:33:35 pm »
i can do it with an epsressif ESP32 ( 180 MHz SOC with wif and bluetooth embedded ) and a bosh BM280 environmental sensor. hardware cost  : 4 to 5$
IDK, but I have trouble sourcing the ESP32 for the moment.
It will run this micropython? Out of the box?
yup. Micropython is released for the ESP32. and Wifi/ble are full working.

Wipy module :   https://www.pycom.io/solutions/py-boards/wipy2/

Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline rob77

  • Super Contributor
  • ***
  • Posts: 2085
  • Country: sk
Re: Micropython for MCUs - is it real or experimental ?
« Reply #40 on: December 22, 2016, 06:34:45 pm »
it's a 32bit MCU accompanied with a wifi chip.
and 512k of external ROM containing the firmware that makes it an ESP8266. It is no more an MCU than Raspberry Pi, Teensy or Arduino is an MCU.

raspberry pi is a full blown computer (CPU must be equipped with a MMU to fall into that category)
arduino is a board + ecosystem built around the ATmega MCU
Teensy is similar to arduino in terms of definition (dev board + ecosystem built around a MCU)

esp8266 is the name of both popular wifi module and also the chip itself... so it's not the external SPI flash that makes it the esp8266... the external SPI flash holds your firmware.

feature list of that esp8266 chip.
Quote
32-bit RISC CPU: Tensilica Xtensa LX106 running at 80 MHz*
64 KiB of instruction RAM, 96 KiB of data RAM
External QSPI flash - 512 KiB to 4 MiB* (up to 16 MiB is supported)
IEEE 802.11 b/g/n Wi-Fi
Integrated TR switch, balun, LNA, power amplifier and matching network
WEP or WPA/WPA2 authentication, or open networks
16 GPIO pins
SPI, I²C,
I²S interfaces with DMA (sharing pins with GPIO)
UART on dedicated pins, plus a transmit-only UART can be enabled on GPIO2
1 10-bit ADC

btw... what you call a CPU accompanied with memory and IO on the same chip ? wait... wasn't it a MCU ? ok the flash is external, but the chip has both instruction and data memory built in... so it's damn close if not spot on ;)


 

Offline dferyance

  • Regular Contributor
  • *
  • Posts: 178
Re: Micropython for MCUs - is it real or experimental ?
« Reply #41 on: December 22, 2016, 06:42:59 pm »
.....That and I am highly offended by the significance of white space in code.  It is literally the dumbest thing you could possible do in a language design.       Invisible things should never, ever control execution flow.   The whole "it makes nice looking code" is really ridiculous given that I can run things through astyle.         I have literally witnessed engineers puzzling over a mistaken indent causing function problems.    This may work for hispster web programmers but I have yet to meet someone who does serious embedded work who finds this acceptable.     

Having programmed in Haskell and F# before python, I thought I would love the way python has significant whitespace - I don't, it is bad. In those other languages, especially Haskell, you don't run into whitespace bugs -- your code just won't compile if you mess it up. It has to do with the way the code is written in a purely functional style. When writing in a dynamic-typing and procedural language, if half your procedure is missing, or in the wrong block, python will appear to handle it fine but just do the wrong thing. Also you end up with much larger functions than in Haskell which makes tab alignment hard.

So my point is, don't totally reject whitespace being significant. Wait until trying it in Haskell. If you still don't like it after that, fine, that is a valid opinion. But don't let python scare you away.

I currently have many co-workers who love python, but having tried a wide variety of languages, I really don't get the appeal. I put it on par with Javascript; fine for simple scripting, but nothing to get excited about. Just chalk it up to some of the mistakes of starting out. Once people have worked in several different fields and on very different kinds of systems and technology, their opinions change -- or should change. Embedded programmers sometimes make the same mistakes just on different things.
 

Offline slicendice

  • Frequent Contributor
  • **
  • Posts: 365
  • Country: fi
Re: Micropython for MCUs - is it real or experimental ?
« Reply #42 on: December 22, 2016, 06:57:52 pm »
Sticking Python generated intermediate language code directly in to those chips will not work. It can not be interpreted in such a small chip, there simply is not enough room for an interpreter.

The code has to be compiled in to machine code, thus eliminating any slowdowns that you get when running intermediate code through an interpreter.

A user could actually use whatever language he/she wishes, to code a microchip, as long as that code is translated into that particular chip compatible machine code.

This means one could write in Assembly, C, C++, C#, Pascal, Java, JavaScript, Python... and the list goes on and on... it could even be programmed in XML.

So, back to answering the original question...If you get(understand) Python better than C or any other programming language, then go with that language. But if you want a huge collection of support libraries (ready made code), then go for C (though Python can use C libraries). If you understand the internal workings of a chip and how it "thinks" (registers etc..., then you can even code it using Assembly (the way chips were programmed and optimized in the early days).

Hope this helps!
« Last Edit: December 22, 2016, 07:00:16 pm by slicendice »
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: Micropython for MCUs - is it real or experimental ?
« Reply #43 on: December 22, 2016, 06:59:29 pm »
The nice thing is that micropython comes with a full blown networking stack , encryption and the whole hoopla. All the annoying crap nobody wants to deal with is already handled. you don't need to muck with libraries.

But surely at some point - SOMEONE

Of course. but with MicroPython it has already been done. Benefits me directly. Too many devkits come with a massive lump of code you have to dig through to get it running. I have not seen a single devkit that comes with turnkey systems. It takes several days to understand the toolchain. MBED is getting there but it still is a royal pain in the patooie sometimes.

Quote
Compare to freeRTOS which also gives you this stuff, with its own API for the features that will be about the same as the micropython hardware API. except freeRTOS is years older, and so years more developed, with support all over the place for numerous chips (actively supported and encouraged for use by most cortex M manufacturers!) And if you have a problem with FreeRTOS, it's all there in your project to dig into and look at if needed
  i don;t wan tto dig in. i have an application to write. i do not want te learn about operating systems, have to find a librarary that handles tcp/ip transport or ble transport , find a library that can handle json and encryption and figure out how to make all these things work nicely together.  i am a visual basic programmer : meaning i am used ot a rich set of instruction provided by the development tool. in a few lines of code i can do what i want as the 'operating system' already provides everything.

I have seen people try to develop an embedded module that configures an i2c slave properly, get data bytes out , format them as human readable text , and get the data loaded somewhere on a server.... using the regular tools. it takes days and the learning curve is very steep.



do the same thing using an electric-imp or a laird BLE600 and it is peanuts. why ? because all the heavy lifting is already done. simply do something like this :


while 1(
if handle = void then
   handle = connect(gateway,hostname,username,key)
   if handle=void then toggle_red_led
else
   red_led=off
   data = readsensor   <- i will write the code for 'readsensor'
   transmit (handle, jsonformat(data,formatstring)
   toggle blue_led
end if


or something along those lines.
this checks for a connection , if none exists : open it. if failse : blink red led. if works : read sensor data, format it and send it. blink blue led.

how much more complicated do you want it ?
this is the problem with all these iot things : i have a ton of idea's , unfortunately my coding skills are none to very mediocre. i need simple stuff. i can hack an i2c and spi bus like the best. but i have no clue how to write the underlying code to set up a ble or  wifi link to a server and get data there. that 'heavy lifting' needs to be done for me.

Any microcontroller manufacturer that wants to win the market needs to provide the fabric to do that. ( that is what espressif is doing ) People simply don't want to deal with that complicated stuff. It is time consuming , error prone and reinventing the wheel. The silicon itself is worthless these days. Any 32 bit machine can be had for 1 to s$. I don't care where i buy it from.  My selection criteria is : what is MY time to market. And that is heavily dependent on the tools/examples/code provided and how easy it is to pick it up and work with it.

Quote
you can use these parts with a C compiler, too.
even in assembly or using a hex editor. but why do you want to torture yourself ? and go through endless , compile, download, reset , doesn't work , alter , compile again. flash again...
with an interpreter i can alter a few lines and directly run. i can scatter debug code left and right and then simply comment it out. i can get a command prompt and execute a few lines interactively.
Having the capability to just type in a few commands and see immediate response is a dream to develop code.


Quote
OK, now using serial port debugging from inside your python application,
interactive prompt. simply type i2c_send_start <enter> and wathc the SDA and data lines toggle.
nothing beats the capabiltiy to call the functions from a prompt. (or jiggle the pins interactively) once you figure out how to do it then you can craft the routine properly.

Quote
you try tracing what happens when the I2C driver compiled into the executive
not my problem. the executive is supposed to work.

Quote
the memory allocation code
not my issue. executive issue .

Quote
Or the way the generic OS sleep
not my issue ..

I split my code form that what is provide and assumed to work properly. Gone ar ethe days where you develop everytinhg yourself , from scratch. Whoever gets me the richest, easiest to use platform at the lowest price will win my business.

Quote
And having all the relevant code for even looking at what might actually be happening under your application locked away
Micropython is fully open source. you can dig as deep as you want. down to bare metal and datasheets.

anyway. my mindest is different. i have something i want to do and needs ot send it's data to a webserver for interaction. i wan this over an encrypted link. don;t want to learn about networking , bluetooth and all this other kerfuffle. just give me afunction call to open the connection and one to send and one to receive. i will do the rest.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: Micropython for MCUs - is it real or experimental ?
« Reply #44 on: December 22, 2016, 07:08:36 pm »
Sticking Python generated intermediate language code directly in to those chips will not work. It can not be interpreted in such a small chip,
Quote

Works perfectly fine. 'small chip' these days is a 32 bit ARM F4 running at 180 MHz... that is serious horsepower. Homecomputers in the 80's ran on 8 bit at 2MHz and could do serious stuff. An old 8051 ran full blown basic interpreter with floating point in 8 k rom and 256 bytes of ram.. that 3$ ESP32 chip has a dual core 32 bit cpu running at 180 Mhz with 512k of ram... one core is used for ble/wifi , the other is yours to do what you want ...
the micropython engine is barely 60k. leaves 400k for user program... plenty of room for something that will sit somewhere in a lightswitch or lightbulb. wanna make your own RGB led-lightbulb that can be controlled from your smartphone ? 3$ chip and 10 lines of code. bye arduino and rpi. you are too expensive , too big, too cumbersome.

Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 
The following users thanked this post: thm_w

Offline slicendice

  • Frequent Contributor
  • **
  • Posts: 365
  • Country: fi
Re: Micropython for MCUs - is it real or experimental ?
« Reply #45 on: December 22, 2016, 08:29:01 pm »
 :-DD

Why on earth would I want to use a chip with that amount of horsepower just to turn on a light bulb?
Why would I waste 60k of ram in a chip if I can do same stuff in just a few hundred bytes?
Why would I halve the performance of the chip by using an interpreter as unnecessary overhead?

Switching on a light bulb over WiFi can be written in a couple of lines of code in the Arduino environment. Python leverages a lot of readily written C and Assembler libraries, skipping the interpreter, where performance counts. Don't know how Micropython is implemented and what chips it supports, so won't argue on that.

I must agree that a cheap chip in small form factor and with a lot of horsepower is appealing though.

What I don't like nor agree with is the thinking that one should waste resources just because one can. This sort of thinking ends up in products like M$ Windows and similar which are consuming way too much resources while doing nothing. (in Win10 they have actually tried to work on this for the first time since first NT based release)
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Micropython for MCUs - is it real or experimental ?
« Reply #46 on: December 22, 2016, 09:18:42 pm »
but the fact that they even bothered to fund an investigation
Means that bureaucracy did its job and someone got paid to do pointless work. They will never approve this thing for anything space related. Half of the C standard is not approved for normal automotive use via MISRA-C. I can't see a dynamic language getting anywhere close to space stuff.

There are already cubesats using commodity hardware and software.

Indeed. But they are also very heavily modified. I've worked directly with, and consulted to, several cubesat teams, and while there is a limited amount of off the shelf stuff in there, none of it is turnkey by any stretch of the imagination. Even with the off he shelf components, the whole thing has to be integrated.

If Micropython is see to be fit for purpose for some things then so be it, but the power budget on these spacecraft is typically very limited, for a 1U it's about 1W. Pissing your power budget away in a housekeeping unit built with interpreted code (I am assuming it's interpreted) isn't what I'd recommend as a first shot, but if the team lacks embedded expertise and can make it work then so be it.

Usually in my experience, it's not the embedded expertise that's lacking, it's the RF and modulation/coding that's usually where there's a dearth of knowledge.

I have nothing against Micropython, but like any language it is not a universal panacea.

Edit: I see it's compiled which is definitely a step in the right direction, but the devil's in the detail, there will need to be a HAL of some description written, and I'd anticipate its performance in DSP won't be stellar. How does it deal with data structures and GC for example? How deterministic is it? In real time systems, these are crucial considerations.
« Last Edit: December 22, 2016, 09:47:08 pm by Howardlong »
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: Micropython for MCUs - is it real or experimental ?
« Reply #47 on: December 22, 2016, 09:39:29 pm »
:-DD

Why on earth would I want to use a chip with that amount of horsepower just to turn on a light bulb?
Why would I waste 60k of ram in a chip if I can do same stuff in just a few hundred bytes?
Why would I halve the performance of the chip by using an interpreter as unnecessary overhead?

Switching on a light bulb over WiFi can be written in a couple of lines of code in the Arduino environment.

your atmel chip  alone costs more than the esp32 and does not have wifi and ble ... you need external stuff for that .. which costs more money...
does it matter if your lightbulb turns on 20 microseconds faster than mine ? mine is on the market , you are still getting yours to work ...
the esp has 512K of ram. so what if i use 60k ?


Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 7307
  • Country: nl
  • Current job: ATEX product design
Re: Micropython for MCUs - is it real or experimental ?
« Reply #48 on: December 22, 2016, 10:32:51 pm »
i can do it with an epsressif ESP32 ( 180 MHz SOC with wif and bluetooth embedded ) and a bosh BM280 environmental sensor. hardware cost  : 4 to 5$
IDK, but I have trouble sourcing the ESP32 for the moment.
It will run this micropython? Out of the box?
yup. Micropython is released for the ESP32. and Wifi/ble are full working.

Wipy module :   https://www.pycom.io/solutions/py-boards/wipy2/
I was asking about a trusted source, where I can buy 1K PCS of the modules. I was really cautious about the ESP8266 also, but then Avnet (well, the local Avnet supply chain child company) started supplying it.
I actually asked them about the ESP32, no answer.
Anyway, I've used python for IOT-i stuff. I had big reservations, but it actually worked out quite well in the end. Say, hundred lines of code. The programmer guy reviewing my code told me I do too much error handling...
I kinda starting to like the idea...
 

Offline slicendice

  • Frequent Contributor
  • **
  • Posts: 365
  • Country: fi
Re: Micropython for MCUs - is it real or experimental ?
« Reply #49 on: December 22, 2016, 11:21:16 pm »
Anyway, I've used python for IOT-i stuff. I had big reservations, but it actually worked out quite well in the end. Say, hundred lines of code. The programmer guy reviewing my code told me I do too much error handling...
I kinda starting to like the idea...

That's great! Personally I don't like Python at all, C makes so much more sense to me as a language. I've been studying quite a lot of math libraries and I found out that everybody was complaining that Python is really slow compared to pure C. Much easier to slap together a complicated formula in Python, but C gives the answer much faster. And it makes sense to me, as there is virtually no overhead in C.

Using Python on a chip that has room for it is alright, if the performance drain is no issue. Helps completing stuff a lot faster.

C is really easy to learn, and it is really easy to jump to C++, Java and C# after learning basic ANSI C. But making some more complex projects in C requires a good set of ready made libraries, or really good knowledge of how Microcontrollers or Processors work. Coding in pure C can become very time consuming in the long run compared to higher level languages. But that is nothing compared to Assembly language, where you have to control every bit and byte moving in a microcontroller.

If you want to be in control of your chip programming and don't want to be forced to be dependent on too many ready made libraries, or be limited to just a few chip, then go for Assembly and C. Where C is the better choice and Assembly worthwhile learning. If C is too hard to learn then I'd say programming is not your thing, and you should consult a pro or at least someone with basic programming skills.

If you are only going to program a handful of chips and they all have full Java or Python support (ready made libraries for those chips), but no direct C support, then go for those languages. You can always switch to C later on same chips.
 

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 7307
  • Country: nl
  • Current job: ATEX product design
Re: Micropython for MCUs - is it real or experimental ?
« Reply #50 on: December 22, 2016, 11:55:52 pm »
If you are only going to program a handful of chips and they all have full Java or Python support (ready made libraries for those chips), but no direct C support, then go for those languages. You can always switch to C later on same chips.
I did program chips in ASM (AVR), they went on the field, and as far as I know they are still working. I program in C and I program in python. When the task was to count pulses, assign a date stamp, code it in SHA256 and send it over GPRS to a server, expecting JSON, running a database with a billion entries, then the coding was done in python.
I never used ASM after entering the 32 bit era. I remember having a nice ASM library for serial port, with named registers, designated memory spaces, pointers for circular buffers. It was great fun. That was days to write and debug, and sure I used it in multiple projects.
Now, I can simply send a tuple or list of variables though any communication device, and it comes back unchanged. In fact, I can compress the tuple with a single command, and make it use less data, so it arrives faster to the other side of the wire. And the compression is tested, built in, kinda optimal.
Only grudge I have against full python is the memory usage. My benchmark is an almost empty interpreter of python 2.7, on linux, which is around 10 MB. It becomes a problem, if you want to run more than one at the same time.
 

Offline thm_w

  • Super Contributor
  • ***
  • Posts: 6278
  • Country: ca
  • Non-expert
Re: Micropython for MCUs - is it real or experimental ?
« Reply #51 on: December 23, 2016, 12:33:36 am »
I was asking about a trusted source, where I can buy 1K PCS of the modules. I was really cautious about the ESP8266 also, but then Avnet (well, the local Avnet supply chain child company) started supplying it.
I actually asked them about the ESP32, no answer.
Anyway, I've used python for IOT-i stuff. I had big reservations, but it actually worked out quite well in the end. Say, hundred lines of code. The programmer guy reviewing my code told me I do too much error handling...
I kinda starting to like the idea...

ESP32 is not really widely available yet, I would say quite a few more months until its cheap and available as the ESP8266 is. You can buy it for a premium right now though from say adafruit ($9 http://esp32.net/).
Aliexpress is a good measure of availability: esp8266 = 10,300 results, esp32 = 50 results.
Digikey/avnet are dinosaurs with regard to these products. With digikey they don't even sell the chip they are reselling a module from Sparkfun/Adafruit. Which is fine for their clientele (the module will have been fully tested).
Profile -> Modify profile -> Look and Layout ->  Don't show users' signatures
 

Offline krho

  • Regular Contributor
  • *
  • Posts: 222
  • Country: si
Re: Micropython for MCUs - is it real or experimental ?
« Reply #52 on: December 23, 2016, 08:46:11 am »
The esp32 indeed has 512K of SRAM, but this is marketing gimmick. Some of that is ICacheand DCache, then when you use the BT an WIFI stack approximately 257k remains. But this is still more than on any M4 or even smaller sized AVR. And all of them are priced way higher.
 

Offline slicendice

  • Frequent Contributor
  • **
  • Posts: 365
  • Country: fi
Re: Micropython for MCUs - is it real or experimental ?
« Reply #53 on: December 23, 2016, 01:19:19 pm »
We are starting to get a bit off topic here. :-)

Whatever chip you choose to program, if it has full support for MicroPython development and has support for external RAM, and you need to get a lot of features coded quickly then MP is a good choice. Assuming you know how to code in Python.

ESP32 supports up to 16 MB off-Chip SPI Flash and up to 8 MB off-Chip SPI SRAM, which is plenty for most tasks.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Micropython for MCUs - is it real or experimental ?
« Reply #54 on: December 23, 2016, 04:20:44 pm »
Assuming you know how to code in Python.
And someone did all the hard work for you already. And you will be forever limited to a subset of MCUs supported by those ports. Good luck in your embedded endeavors with this approach.
Alex
 

Offline slicendice

  • Frequent Contributor
  • **
  • Posts: 365
  • Country: fi
Re: Micropython for MCUs - is it real or experimental ?
« Reply #55 on: December 23, 2016, 05:27:37 pm »
And someone did all the hard work for you already. And you will be forever limited to a subset of MCUs supported by those ports. Good luck in your embedded endeavors with this approach.

Yep! I started my programming journey using C# only, and thought it would be enough. I was so wrong. Now I use about 10 different programming and scripting languages, all suitable for different applications, to get stuff done reliably and efficiently. And there is still so many new languages to learn. :-/O No single programming language can do it all. Or some can, but in many cases it would be like climbing up a tree with your butt first.  :-DD
 

Offline timb

  • Super Contributor
  • ***
  • Posts: 2536
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
Re: Micropython for MCUs - is it real or experimental ?
« Reply #56 on: December 23, 2016, 08:14:05 pm »
Assuming you know how to code in Python.
And someone did all the hard work for you already. And you will be forever limited to a subset of MCUs supported by those ports. Good luck in your embedded endeavors with this approach.

The source is available, so there's nothing stopping you from porting it to a new MCU...

It's actually not too hard to port! I've been working on a PSoC 5LP port in my spare time and almost have all the basics working I think. I haven't put that much time into it, either.
Any sufficiently advanced technology is indistinguishable from magic; e.g., Cheez Whiz, Hot Dogs and RF.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: Micropython for MCUs - is it real or experimental ?
« Reply #57 on: December 23, 2016, 08:41:54 pm »
Assuming you know how to code in Python.
And someone did all the hard work for you already. And you will be forever limited to a subset of MCUs supported by those ports. Good luck in your embedded endeavors with this approach.
source is avaialble. written in plain c. and there is a hooks library to attach your own custom functions.

anyway. the thing that is interesting for me is that this is a turnkey platform with internet connectivity. i can focus on acquiring the data. blasting it into the backbone server is handled by the micropython engine. I really do not want to deal with learning how to run a ble or wifi stack and have to bother with 'sometimes it don't work' .

there is a point where you have to let go and focus on your product. otherwise your development cycle becomes so long and complicated you never get anywhere.
i have a ton of idea's for iot products. i can;t make em cause i run into endless misery getting my data out of the platform and onto someone's server. it is all too complicated.
i tried Lua but that is dead in the water... micropython seems to do the trick. i despise python as a language ( whitespace formatting -puke- ) but it gets the job done and it runs on a beautiful, cheap chip that has both ble and wifi. all i need is access to the i2c bus and a couple of io pins ( very slow toggle rates. so no problem if micropython is slow on that )

i was able to make a prototype sending data into a bakcbone in a few hours. been running for weeks without a single glitch.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Micropython for MCUs - is it real or experimental ?
« Reply #58 on: December 23, 2016, 08:44:06 pm »
source is avaialble. written in plain c. and there is a hooks library to attach your own custom functions.
I'm not worried about the Python itself. But all those libraries that actually make it marginally useful may not be so easy to port / debug.
Alex
 

Offline timb

  • Super Contributor
  • ***
  • Posts: 2536
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
Re: Micropython for MCUs - is it real or experimental ?
« Reply #59 on: December 23, 2016, 08:52:07 pm »
Assuming you know how to code in Python.
And someone did all the hard work for you already. And you will be forever limited to a subset of MCUs supported by those ports. Good luck in your embedded endeavors with this approach.
source is avaialble. written in plain c. and there is a hooks library to attach your own custom functions.

anyway. the thing that is interesting for me is that this is a turnkey platform with internet connectivity. i can focus on acquiring the data. blasting it into the backbone server is handled by the micropython engine. I really do not want to deal with learning how to run a ble or wifi stack and have to bother with 'sometimes it don't work' .

there is a point where you have to let go and focus on your product. otherwise your development cycle becomes so long and complicated you never get anywhere.
i have a ton of idea's for iot products. i can;t make em cause i run into endless misery getting my data out of the platform and onto someone's server. it is all too complicated.
i tried Lua but that is dead in the water... micropython seems to do the trick. i despise python as a language ( whitespace formatting -puke- ) but it gets the job done and it runs on a beautiful, cheap chip that has both ble and wifi. all i need is access to the i2c bus and a couple of io pins ( very slow toggle rates. so no problem if micropython is slow on that )

i was able to make a prototype sending data into a bakcbone in a few hours. been running for weeks without a single glitch.

I wish someone would revive the LUAmcu project and get it going again... LUA just isn't as popular as Python, despite being an amazingly fast scripting language (just as fast as compiled C, in some cases). It's also very elegant, syntax wise.
Any sufficiently advanced technology is indistinguishable from magic; e.g., Cheez Whiz, Hot Dogs and RF.
 

Offline rob77

  • Super Contributor
  • ***
  • Posts: 2085
  • Country: sk
Re: Micropython for MCUs - is it real or experimental ?
« Reply #60 on: December 23, 2016, 10:03:13 pm »
Assuming you know how to code in Python.
And someone did all the hard work for you already. And you will be forever limited to a subset of MCUs supported by those ports. Good luck in your embedded endeavors with this approach.
source is avaialble. written in plain c. and there is a hooks library to attach your own custom functions.

anyway. the thing that is interesting for me is that this is a turnkey platform with internet connectivity. i can focus on acquiring the data. blasting it into the backbone server is handled by the micropython engine. I really do not want to deal with learning how to run a ble or wifi stack and have to bother with 'sometimes it don't work' .

there is a point where you have to let go and focus on your product. otherwise your development cycle becomes so long and complicated you never get anywhere.
i have a ton of idea's for iot products. i can;t make em cause i run into endless misery getting my data out of the platform and onto someone's server. it is all too complicated.
i tried Lua but that is dead in the water... micropython seems to do the trick. i despise python as a language ( whitespace formatting -puke- ) but it gets the job done and it runs on a beautiful, cheap chip that has both ble and wifi. all i need is access to the i2c bus and a couple of io pins ( very slow toggle rates. so no problem if micropython is slow on that )

i was able to make a prototype sending data into a bakcbone in a few hours. been running for weeks without a single glitch.

I wish someone would revive the LUAmcu project and get it going again... LUA just isn't as popular as Python, despite being an amazingly fast scripting language (just as fast as compiled C, in some cases). It's also very elegant, syntax wise.

are you serious ? :D  writing object-like structures in plain C is probably better than LUA  :-DD no just kidding.. lua is great in some rare cases but definitely not for the "general public" . you have to do everything yourself in Lua even inheritance , not talking about libraries for basic stuff someone would consider granted ;) however lua is great in cases when you let's say have a complex project written in plan C with many own libraries and you want to shorten the turn-around times for new releases... so you rewrite the high level logic in lua while using all your existing libraries written in C.
 

Offline slicendice

  • Frequent Contributor
  • **
  • Posts: 365
  • Country: fi
Re: Micropython for MCUs - is it real or experimental ?
« Reply #61 on: December 24, 2016, 08:00:13 am »
want to shorten the turn-around times for new releases... so you rewrite the high level logic in lua while using all your existing libraries written in C.

Spot on!  :-+
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Micropython for MCUs - is it real or experimental ?
« Reply #62 on: December 25, 2016, 12:27:30 am »
Quote
the thing that is interesting for me is that this is a turnkey platform with internet connectivity.
Does micro-python provide internet connectivity, or does it just interface to the existing internet support on platforms like ESP8266?

I haven't used micro-python, and I've just started to learn/use "real" python.  It seems to me that micro-python is "real" and likely to become "more real" if more people use it.  Whether it's limitations (compared to real python) will prevent that remains to be seen.  Whether it's a good idea is a third question.

Don't forget that BASIC52 and PBASIC (basic stamp) were "viable" and popular for a long time, despite being "horribly slow" by compiled-language standards.
 

Offline miceuz

  • Frequent Contributor
  • **
  • Posts: 387
  • Country: lt
    • chirp - a soil moisture meter / plant watering alarm
Re: Micropython for MCUs - is it real or experimental ?
« Reply #63 on: December 25, 2016, 09:10:16 am »
I'm a professional programmer with over 15 years of experience, I know a bunch of languages and platforms and I hate the current trend of those hipster webdev languages.

I was very sceptical about micropython at first. Then I just spent an hour looking on the web for a proper parameters to flash micropython on esp8266 and gave it a shot.

Having a terminal access to all the hardware via an interface of the familiar programming language was... a fine experience. I have spent some time writing a library for I2C - based SHT25 sensor - you make an I2C call, you observe results, you write some code to parse those results into a meaningful data structure - all in the terminal live on the hardware.

Library for SPI-based ssd1306 display was built in and worked out of the box. Another builtin library HTTPRequest did not work for me unfortunately - I didn't figure out what exactly Sparkfun phant expects in a POST request.

All in all - it's a nice toy to string something quick in no time. I wouldn't go with it in a commercial design of any reasonable size, but it can take you looong way in the process of prototyping. And no, it's no biggie when you have to "redesign" everything in a "proper" language - you had everything for free in micropython anyway and all algorithms specific to your application should be language agnostic - you have to be just adding {'s and ('s.

I can understand why people are looking at it for space applications. For one thing - python is a lingua franca for all trades of scientists, on another hand - having rock solid interpreter that makes firmware update easy is lucrative. I won't do navigation and communication tasks in micropython, but scientific payload - why not?


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf