4 ms·

I think the future of this hardware revolution will be python on a microcontroller.It could solve the complexity this article describes while keeping prices rea

by hershel 13y ago

I think the future of this hardware revolution will be python on a microcontroller.It could solve the complexity this article describes while keeping prices realistic for a product: Micropython[1] is being in development right now,Currently working on a $6 mcu, with a potential for running on a $3/84mhz/3mm*3mm/49-pin mcu with varied peripherals (or maybe even something cheaper). And as or complexity, this video shows an easy wifi interface[2]. And since it has a C-FFI, developing a first generation of a product in python and optimizing to c in next generations according to market and technical need is a good possibility. [1]https://github.com/micropython/micropython https://github.com/micropython/micropython [2]https://www.kickstarter.com/projects/214379695/micro-python-python-for-microcontrollers/posts/681998 https://www.kickstarter.com/projects/214379695/micro-python-...

anon24892 13y ago
I very much disagree, in the general case. The complexity of embedded systems design can't be significantly reduced by using python and I often do not think while developing that I higher level language would help, in fact I often think that C maps very well to the problem. It was designed as a system programming language and is good as one. The complexity of embedded code does not lie in the code itself but in the hardware and you have sacraficed a few orders of magnitude in speed for very little or no gain. The code itself is usually fairly simple but you would not be able to tell anything from looking at it, you need to refer to datasheets. Not only this but by using an more expensive ECU to begin with you really limit the scalability of your design and add to recurring costs. I use a more powerful microcontroller at work and we still constantly have to drop down to assembly, albeit in limited controlled ways. That said, there will be areas where this is a viable option, but not many. You have to analyze your problem and decide if is viable; for an embedded webserver it is, for a DCDC converter where speed is of a concern it is not. For a smoke alarm where cost is primarily a factor and your margins are tiny it is not.
- hershel 13y ago
  The way to reduce the complexity of the hardware is mostly by using good libraries like arduino or mbed(or maybe goot rtos's with plenty of drivers, if there's such a thing). Do you use them ? And as my example vs the OP's article with arduino, it seems that micro python offers a much better interface to said libraries. Not sure it's only the language, could be also the library implementation. With regards to performance penalty : micro python has some unique compile mode which brings the speed to maybe 8x of c. Assuming you're willing to waste some memory and speed(say a first version kickstarter product, or a low/mid volume commercial product) , you also get rid of pointers(which are the source of great complexity and bugs in c) and gets access to much better testing tools via python.

by hershel 13y ago

anon24892 13y ago

I very much disagree, in the general case. The complexity of embedded systems design can't be significantly reduced by using python and I often do not think while developing that I higher level language would help, in fact I often think that C maps very well to the problem. It was designed as a system programming language and is good as one. The complexity of embedded code does not lie in the code itself but in the hardware and you have sacraficed a few orders of magnitude in speed for very little or no gain. The code itself is usually fairly simple but you would not be able to tell anything from looking at it, you need to refer to datasheets. Not only this but by using an more expensive ECU to begin with you really limit the scalability of your design and add to recurring costs. I use a more powerful microcontroller at work and we still constantly have to drop down to assembly, albeit in limited controlled ways. That said, there will be areas where this is a viable option, but not many. You have to analyze your problem and decide if is viable; for an embedded webserver it is, for a DCDC converter where speed is of a concern it is not. For a smoke alarm where cost is primarily a factor and your margins are tiny it is not.

hershel 13y ago
The way to reduce the complexity of the hardware is mostly by using good libraries like arduino or mbed(or maybe goot rtos's with plenty of drivers, if there's such a thing). Do you use them ? And as my example vs the OP's article with arduino, it seems that micro python offers a much better interface to said libraries. Not sure it's only the language, could be also the library implementation. With regards to performance penalty : micro python has some unique compile mode which brings the speed to maybe 8x of c. Assuming you're willing to waste some memory and speed(say a first version kickstarter product, or a low/mid volume commercial product) , you also get rid of pointers(which are the source of great complexity and bugs in c) and gets access to much better testing tools via python.