4 ms·

Wouldn’t microcontrollers better run with efficient and low-level languages?

nicoburns 6y ago
Sure. But they're powerful enough that they can run higher-level languages these days, and it lowers the barrier to entry for people wanting to do hardware projects which is pretty cool.
mhaberl 6y ago
In short: yes. BUT maybe it does not matter that much for some projects and a lot of people can write some logic in js a lot faster than in C (or C++ or Rust or..). Also, there are a lot of people who know only js and would like to "play" with some LED, fetching room temperatures, opening closing doors etc - this is a nice way to start. There are a lot more info about performance here: https://www.espruino.com/Performance https://www.espruino.com/Performance
- rhabarba 6y ago
  In my opinion, life would - in the long term - be easier for these people if they were forced to learn C, C++ or Rust for their projects. But it’s been a while since I was a beginner myself, so there might be some bias here.
  - qayxc 6y ago
    C, C++ and Rust are big barrier to most hobby programmers. Python, JavaScript, and other high-level languages are way more accessible and are an order of magnitude faster to get started with. Why waste weeks on learning C when that time could just as well be spent actually getting things done? I also don't see how C - and especially Rust - would make embedded development any easier than using a scripting language. Tooling is often worse, skills cannot be transferred from and to other common areas (mobile, web) and development times are provably longer. Unless your goal is to become a professional and create commercial products in the IoT/embedded space, I doubt learning and using C or C++ would be easier in any way.
    - rhabarba 6y ago
      I wish I could insert the hint here that I actually use C for web development without it looking like a flame bait ... :-) I agree that Rust was not a good example, sorry.
samtho 6y ago
A programming language is just an abstraction (built on other abstraction, typically) of turning transistors on and off. JavaScript is most often run in a runtime like v8, but you could build alternate runtimes or event a compiler to target some VM bytecode or an architecture. One of the things that makes interfacing with hardware (as a software engineer) joyful is having your toolsets match your expectations and mental models of how you want your solution to work. JavaScript was built as a language for interfaces and what is hardware? It’s a physical interface. I personally don’t find it totally unsuited for microcontrollers.
mobilio 6y ago
Technically yes. But in term of development running JS allows devs to code on their PCs and to run some tests on PCs. So once code is ready on some level to be deployed on microcontroller.
- pantalaimon 6y ago
  The same is true for C.
  - mobilio 6y ago
    20 years ago i wrote code for MicroChip PIC series and we're developing using Assembler for maximum performance and minimum codesize. Merging code between different devs there was... challenging!
zorked 6y ago
The same thinking applies to PCs and supercomputers, but sometimes we trade efficiency for convenience. That's happening in the "microcontroller" space too (which are surprisingly powerful nowadays).
rraghur 6y ago
Yes and much more straight forward to interface with hardware - but also requires some level of exp with said low level languages. Arduino did a lot to reduce barrier to entry to the uC world - but even that requires you to understand a little of how C++ works once you move beyond blinky. These (micropython, this project, Lua ) etc lower the barrier to entry even further. The trade off of course is how well they run and how much of the hardware is exposed (register manipulation etc) if you want to get to it...
pjc50 6y ago
Programmers run much better with high-level languages. For quantity-1million, yes the efficiency matters. For quantity-1, the structure is very different. There used to be (maybe still are?) "BASIC Stamp" microcontrollers that run tokenised BASIC. This is the next evolution of that. (The C environments work, but the manufacturer-provided ones are often a bit ropey!)
- watchdogtimer 6y ago
  FWIW, Great Cow Basic (http://gcbasic.sourceforge.net/ http://gcbasic.sourceforge.net/) is available for both PIC and AVR microcontrollers and still actively maintained. I've used it a lot on several PIC projects.
tluyben2 6y ago
We prototype everything in a higher level language first and then 'translate it' (manually) to something that fits the production platform. For instance, for our current iteration of our product, we created a first 'visual prototype' with Flutter (this contains all algorithms and data-structures already to almost translate 1-1 to C++ and C/asm), then we worked down to C++ (next time we are going to try Rust for this phase) on a powerful mcu but with the (mostly) identical peripherals as the final product. Final step (currently ongoing) is the translation to C/asm to fit the MCU's we use (2mhz/24kb). Over the decades we have seen that this process is the fastest and least bug prone way. We already think in low level structures and algorithm implementations when coding the high level 'visual' model (or sales/investor pitch model often) (which used to be Java desktop applications, but now with smart phones it's far closer to what the end product will be) so that when we move down towards production components (which means basically as cheap as possible BOM for 1m+ runs; every cent counts, also, we have never had the experience where, after the fact, we encountered this common thing in software; 'people are more expensive than hardware'. Even for a few cents difference we can pay more people than we needed. But yes, that means optimising every byte...), we don't have to spend that much time on those. It's just on hardware specific stuff for the C++ 'big' mcu version and then it's just bit-fiddling/optimising for the lowest level version.
pritovido 6y ago
Of course. But efficiency is not the only important thing in the world. You can explore the world from different perspectives, not just from one. Lisp was for a long time a very inefficient language, but also extremely important. The users of early Lisp did not care so much about efficiency, they were mainly academics after all and someone else did buy the machines they used(they did cost hundreds of thousands of dollars each). They cared about things like reusability of code, being easy to understand, not making mistakes or just exploring the new world of computers. They invented flow control directives like "cond" and later "if", "while"..., functions, lambdas, macros, program evaluation through eval(interpretation of programs), structured text(s expressions) and complex parsing, automatic reference counting, garbage collectors, closures...and so many things that we take for granted today. If you focus too much on something you become myopic to other things that are also important. And if you don't explore those other areas, you don't even know that they exist.
ex3ndr 6y ago
TBH i found for some use cases JS is much better than C for MCU. Simply due the nature of javascript and it's eventloop MCU could automatically sleep without writing any additional code. While on C you have to use some kind of scheduler that switches power mode of MCU by yourself.
pjmlp 6y ago
Most micro-controllers are more powerful than the PCs I used with MS-DOS on, plenty of juice on those 80x86 with 640 KB memory for high level languages. Naturally anything performance critical back then was written in pure Assembly, but plenty of stuff was achievable with Basic, Pascal, C, Lisp, Clipper, Prolog and plenty of other stuff. First profit from productivity in a high level language, then optimize within its capabilities, and if that still isn't enough than dive into Assembly.
bsder 6y ago
I'm not a fan of Javascript on microcontollers, but you can't ask that question without asking "Okay, so which language?" Your really small language alternatives: 1) BASIC--Okay, but not exactly mainstream nowadays 2) Tcl--My favorite on small devices, but it's more like a Lisp than a mainstream language so there's a barrier 3) A Scheme/Lisp--again sufficiently different that it presents a barrier to entry 4) Forth--For those who don't find Lisp different enough 5) Lua--1-based in a 0-based world AND you have to add so many "extensions" that its no longer "small" when you finish. And ... ? As opposed to: A) Espruino aka Javascript--everybody and their dog can put together 10 lines of Javascript and make it work. Resources are everywhere. You're probably not building anything large enough to activate most of Javascripts negatives (generally related to concurrency and building in the large) B) Micropython -- a lot of people with scientific background can throw together a couple dozen lines of Python and connect to something in their lab. Lots of resources and help available. MY problem is that I would like something like one of these languages but that runs in <4K RAM and <16K FLASH. I want an actual small language that runs in something smaller than an Apple IIe, thanks.

Sure. But they're powerful enough that they can run higher-level languages these days, and it lowers the barrier to entry for people wanting to do hardware projects which is pretty cool.

mhaberl 6y ago

In short: yes. BUT maybe it does not matter that much for some projects and a lot of people can write some logic in js a lot faster than in C (or C++ or Rust or..). Also, there are a lot of people who know only js and would like to "play" with some LED, fetching room temperatures, opening closing doors etc - this is a nice way to start. There are a lot more info about performance here: https://www.espruino.com/Performance https://www.espruino.com/Performance

rhabarba 6y ago
In my opinion, life would - in the long term - be easier for these people if they were forced to learn C, C++ or Rust for their projects. But it’s been a while since I was a beginner myself, so there might be some bias here.
- qayxc 6y ago
  C, C++ and Rust are big barrier to most hobby programmers. Python, JavaScript, and other high-level languages are way more accessible and are an order of magnitude faster to get started with. Why waste weeks on learning C when that time could just as well be spent actually getting things done? I also don't see how C - and especially Rust - would make embedded development any easier than using a scripting language. Tooling is often worse, skills cannot be transferred from and to other common areas (mobile, web) and development times are provably longer. Unless your goal is to become a professional and create commercial products in the IoT/embedded space, I doubt learning and using C or C++ would be easier in any way.
  - rhabarba 6y ago
    I wish I could insert the hint here that I actually use C for web development without it looking like a flame bait ... :-) I agree that Rust was not a good example, sorry.

samtho 6y ago

A programming language is just an abstraction (built on other abstraction, typically) of turning transistors on and off. JavaScript is most often run in a runtime like v8, but you could build alternate runtimes or event a compiler to target some VM bytecode or an architecture. One of the things that makes interfacing with hardware (as a software engineer) joyful is having your toolsets match your expectations and mental models of how you want your solution to work. JavaScript was built as a language for interfaces and what is hardware? It’s a physical interface. I personally don’t find it totally unsuited for microcontrollers.

mobilio 6y ago

Technically yes. But in term of development running JS allows devs to code on their PCs and to run some tests on PCs. So once code is ready on some level to be deployed on microcontroller.

pantalaimon 6y ago
The same is true for C.
- mobilio 6y ago
  20 years ago i wrote code for MicroChip PIC series and we're developing using Assembler for maximum performance and minimum codesize. Merging code between different devs there was... challenging!

zorked 6y ago

The same thinking applies to PCs and supercomputers, but sometimes we trade efficiency for convenience. That's happening in the "microcontroller" space too (which are surprisingly powerful nowadays).

rraghur 6y ago

Yes and much more straight forward to interface with hardware - but also requires some level of exp with said low level languages. Arduino did a lot to reduce barrier to entry to the uC world - but even that requires you to understand a little of how C++ works once you move beyond blinky. These (micropython, this project, Lua ) etc lower the barrier to entry even further. The trade off of course is how well they run and how much of the hardware is exposed (register manipulation etc) if you want to get to it...

pjc50 6y ago

Programmers run much better with high-level languages. For quantity-1million, yes the efficiency matters. For quantity-1, the structure is very different. There used to be (maybe still are?) "BASIC Stamp" microcontrollers that run tokenised BASIC. This is the next evolution of that. (The C environments work, but the manufacturer-provided ones are often a bit ropey!)

watchdogtimer 6y ago
FWIW, Great Cow Basic (http://gcbasic.sourceforge.net/ http://gcbasic.sourceforge.net/) is available for both PIC and AVR microcontrollers and still actively maintained. I've used it a lot on several PIC projects.

tluyben2 6y ago

We prototype everything in a higher level language first and then 'translate it' (manually) to something that fits the production platform. For instance, for our current iteration of our product, we created a first 'visual prototype' with Flutter (this contains all algorithms and data-structures already to almost translate 1-1 to C++ and C/asm), then we worked down to C++ (next time we are going to try Rust for this phase) on a powerful mcu but with the (mostly) identical peripherals as the final product. Final step (currently ongoing) is the translation to C/asm to fit the MCU's we use (2mhz/24kb). Over the decades we have seen that this process is the fastest and least bug prone way. We already think in low level structures and algorithm implementations when coding the high level 'visual' model (or sales/investor pitch model often) (which used to be Java desktop applications, but now with smart phones it's far closer to what the end product will be) so that when we move down towards production components (which means basically as cheap as possible BOM for 1m+ runs; every cent counts, also, we have never had the experience where, after the fact, we encountered this common thing in software; 'people are more expensive than hardware'. Even for a few cents difference we can pay more people than we needed. But yes, that means optimising every byte...), we don't have to spend that much time on those. It's just on hardware specific stuff for the C++ 'big' mcu version and then it's just bit-fiddling/optimising for the lowest level version.

pritovido 6y ago

Of course. But efficiency is not the only important thing in the world. You can explore the world from different perspectives, not just from one. Lisp was for a long time a very inefficient language, but also extremely important. The users of early Lisp did not care so much about efficiency, they were mainly academics after all and someone else did buy the machines they used(they did cost hundreds of thousands of dollars each). They cared about things like reusability of code, being easy to understand, not making mistakes or just exploring the new world of computers. They invented flow control directives like "cond" and later "if", "while"..., functions, lambdas, macros, program evaluation through eval(interpretation of programs), structured text(s expressions) and complex parsing, automatic reference counting, garbage collectors, closures...and so many things that we take for granted today. If you focus too much on something you become myopic to other things that are also important. And if you don't explore those other areas, you don't even know that they exist.

ex3ndr 6y ago

TBH i found for some use cases JS is much better than C for MCU. Simply due the nature of javascript and it's eventloop MCU could automatically sleep without writing any additional code. While on C you have to use some kind of scheduler that switches power mode of MCU by yourself.

pjmlp 6y ago

Most micro-controllers are more powerful than the PCs I used with MS-DOS on, plenty of juice on those 80x86 with 640 KB memory for high level languages. Naturally anything performance critical back then was written in pure Assembly, but plenty of stuff was achievable with Basic, Pascal, C, Lisp, Clipper, Prolog and plenty of other stuff. First profit from productivity in a high level language, then optimize within its capabilities, and if that still isn't enough than dive into Assembly.

bsder 6y ago

I'm not a fan of Javascript on microcontollers, but you can't ask that question without asking "Okay, so which language?" Your really small language alternatives: 1) BASIC--Okay, but not exactly mainstream nowadays 2) Tcl--My favorite on small devices, but it's more like a Lisp than a mainstream language so there's a barrier 3) A Scheme/Lisp--again sufficiently different that it presents a barrier to entry 4) Forth--For those who don't find Lisp different enough 5) Lua--1-based in a 0-based world AND you have to add so many "extensions" that its no longer "small" when you finish. And ... ? As opposed to: A) Espruino aka Javascript--everybody and their dog can put together 10 lines of Javascript and make it work. Resources are everywhere. You're probably not building anything large enough to activate most of Javascripts negatives (generally related to concurrency and building in the large) B) Micropython -- a lot of people with scientific background can throw together a couple dozen lines of Python and connect to something in their lab. Lots of resources and help available. MY problem is that I would like something like one of these languages but that runs in <4K RAM and <16K FLASH. I want an actual small language that runs in something smaller than an Apple IIe, thanks.