4 ms·

I mean absolutely no disrespect and wish everyone well in this project, but other than a fun hobby or even more fun career for the author, what is the use case

by SeanDav 11y ago

I mean absolutely no disrespect and wish everyone well in this project, but other than a fun hobby or even more fun career for the author, what is the use case for MicroPython? Surely at the microcontroller level, C is perfectly adequate and already in place, everywhere?

tasty_freeze 11y ago
First, someone might prefer python on a microcontroller for the same reasons one might prefer python on any other system: interactive development, clean string and list handling, no need to explicitly manage memory, familiarity with the language ... Now that one can buy a 100+ MHz 32b CPU with 256KB RAM and 1MB of FLASH for $5 (and dropping), using assembly or C to make it fit into an 8b PIC with 2KB of RAM to save $3 isn't a worthwhile trade off for many applications.
dbcurtis 11y ago
Excellent questions. First, there is the complexity of setting up a cross-development environment for your chosen controller. Take the 8-bit AVR's as found in Arduino. I was using those before Arduino, and frankly didn't see the point of Arduino. But then given my prior experience it was not much of an issue for me to set up a good cross-dev environment and write C to the bare-metal, and pretty soon was sending patches to gdb-avr. But... the magic of Arduino, I see now, was that it created an approachable development environment for AVR's that was friendly to people that didn't come to AVR's ready to patch gdb to their liking. Now fast-forward to today, when 8-bit controllers are pretty much a thing of the past and ARM Cortex-Mx processors are the way to go. Setting up C/C++ cross-development is a bit more challenging. Writing enough code to get out of reset, get your I/O mux'es set, and actually wiggle an output pin is a lot of work. What Micropython does is turn a USB cable into a development environment that allows you to try things on an ARM a few minutes after your PyBoard arrives in the mail. It also provides a BSD-licensed base of code that works with a well-defined and easy to install build chain so that you can reflash the part with a custom build of your liking. So for the performance-critical parts, you can write a C extension, if it comes to that. But a little bit of in-line assembly (which Micropython supports) might be all you need. TL;DR: You can avoid a lot of time-consuming heavy lifting and focus your energy on the part that matters to you, accessible through a very powerful language. I'm admittedly a Micropython partisan. But FWIW I have been doing embedded development off-and-on since the 6502 was the hot new chip (yes, gray beard and all) and to me Micropython is the most interesting development in embedded development since Arduino. All that said: Is it really a viable way to ship a commercial product? I say yes: 1. The licensing is there. 2. You can easily write C extensions for the performance critical parts. 3. Python should give you time-to-market advantages over C-on-the-bare-metal.
- SeanDav 11y ago
  Excellent summary and some good points made, thanks.
ufo 11y ago
My question is "why not Lua"? I can see why someone would like to program on a higher level scripting language instead of C and Lua is very much designed from the start to be lean, fast and embeddable. It also inter-operates very easily with C.
- pfalcon 11y ago
  Because some people disagree that Lua is nice language. Lean-ness is questionable, e.g. BrainFuck is much more "lean", so what? MicroPython can be built to the same binary sizes as a typical Lua build, and yet offer more language features. Lua's embedability has stronghold in games, that's where it usually embedded. Embedded hardware systems are a little different beasts. For them, it's helpful to differentiate e.g. integer from float number (Lua's numbers are floats, it took Lua a long way to acquire a standard module to do bitwise operations, which some people consider just an ugly hack). Also, helpful to differentiate arrays with guaranteed O(1) access from dictionaries (Lua has some mutant container type about whose behavior you can never be sure).
  - ufo 11y ago
    Lua 5.3 released recently and has integers and bitwise operators. Array access is also O(1) as long as you use integer keys and don't have any "holes" in the array.
    - pfalcon 11y ago
      That's what I mean - recently. With more than 20-year Lua history, finally recently adding bitwise operations to the core language is move welcomed by Lua community. No talking about the fact that Lua authors still can't find right pattern for modules, so in 5.3 they smashed how it was in 5.2 and few previous versions (and that's not the 1st time IIRC), and welcomed community to redo their homework on that part. That only emphasizing the fact that Lua is intended for adhoc embedding, like, you put it in your game, wrap your game's objects. Anything else - well, depends. Changes in 5.3 is a reason why a lot of community is on 5.2. (Well, to be fair, there's Python2/Python3 split too, MicroPython is Py3.) > Array access is also O(1) as long as you use integer keys and don't have any "holes" in the array. Right, if you don't have "holes", if you start array indexing from arbitrary number (it would be cool to start indexing from e.g. Pi btw, too bad Lua isn't orthodox enough to do that ;-) ), then it's O(1). Otherwise, it's phase of moon dependent (pun intended).

by SeanDav 11y ago

tasty_freeze 11y ago

First, someone might prefer python on a microcontroller for the same reasons one might prefer python on any other system: interactive development, clean string and list handling, no need to explicitly manage memory, familiarity with the language ... Now that one can buy a 100+ MHz 32b CPU with 256KB RAM and 1MB of FLASH for $5 (and dropping), using assembly or C to make it fit into an 8b PIC with 2KB of RAM to save $3 isn't a worthwhile trade off for many applications.

dbcurtis 11y ago

Excellent questions. First, there is the complexity of setting up a cross-development environment for your chosen controller. Take the 8-bit AVR's as found in Arduino. I was using those before Arduino, and frankly didn't see the point of Arduino. But then given my prior experience it was not much of an issue for me to set up a good cross-dev environment and write C to the bare-metal, and pretty soon was sending patches to gdb-avr. But... the magic of Arduino, I see now, was that it created an approachable development environment for AVR's that was friendly to people that didn't come to AVR's ready to patch gdb to their liking. Now fast-forward to today, when 8-bit controllers are pretty much a thing of the past and ARM Cortex-Mx processors are the way to go. Setting up C/C++ cross-development is a bit more challenging. Writing enough code to get out of reset, get your I/O mux'es set, and actually wiggle an output pin is a lot of work. What Micropython does is turn a USB cable into a development environment that allows you to try things on an ARM a few minutes after your PyBoard arrives in the mail. It also provides a BSD-licensed base of code that works with a well-defined and easy to install build chain so that you can reflash the part with a custom build of your liking. So for the performance-critical parts, you can write a C extension, if it comes to that. But a little bit of in-line assembly (which Micropython supports) might be all you need. TL;DR: You can avoid a lot of time-consuming heavy lifting and focus your energy on the part that matters to you, accessible through a very powerful language. I'm admittedly a Micropython partisan. But FWIW I have been doing embedded development off-and-on since the 6502 was the hot new chip (yes, gray beard and all) and to me Micropython is the most interesting development in embedded development since Arduino. All that said: Is it really a viable way to ship a commercial product? I say yes: 1. The licensing is there. 2. You can easily write C extensions for the performance critical parts. 3. Python should give you time-to-market advantages over C-on-the-bare-metal.

SeanDav 11y ago
Excellent summary and some good points made, thanks.

ufo 11y ago

My question is "why not Lua"? I can see why someone would like to program on a higher level scripting language instead of C and Lua is very much designed from the start to be lean, fast and embeddable. It also inter-operates very easily with C.

pfalcon 11y ago
Because some people disagree that Lua is nice language. Lean-ness is questionable, e.g. BrainFuck is much more "lean", so what? MicroPython can be built to the same binary sizes as a typical Lua build, and yet offer more language features. Lua's embedability has stronghold in games, that's where it usually embedded. Embedded hardware systems are a little different beasts. For them, it's helpful to differentiate e.g. integer from float number (Lua's numbers are floats, it took Lua a long way to acquire a standard module to do bitwise operations, which some people consider just an ugly hack). Also, helpful to differentiate arrays with guaranteed O(1) access from dictionaries (Lua has some mutant container type about whose behavior you can never be sure).
- ufo 11y ago
  Lua 5.3 released recently and has integers and bitwise operators. Array access is also O(1) as long as you use integer keys and don't have any "holes" in the array.
  - pfalcon 11y ago
    That's what I mean - recently. With more than 20-year Lua history, finally recently adding bitwise operations to the core language is move welcomed by Lua community. No talking about the fact that Lua authors still can't find right pattern for modules, so in 5.3 they smashed how it was in 5.2 and few previous versions (and that's not the 1st time IIRC), and welcomed community to redo their homework on that part. That only emphasizing the fact that Lua is intended for adhoc embedding, like, you put it in your game, wrap your game's objects. Anything else - well, depends. Changes in 5.3 is a reason why a lot of community is on 5.2. (Well, to be fair, there's Python2/Python3 split too, MicroPython is Py3.) > Array access is also O(1) as long as you use integer keys and don't have any "holes" in the array. Right, if you don't have "holes", if you start array indexing from arbitrary number (it would be cool to start indexing from e.g. Pi btw, too bad Lua isn't orthodox enough to do that ;-) ), then it's O(1). Otherwise, it's phase of moon dependent (pun intended).