Hacker News Reader

Comment by eric__cartman | Hacker News Reader

The ATmega 328P an Arduino Uno or Nano uses has 2KB of memory and 32KB of flash storage for the program. Having some sort of micropython interpreter there would be impossible, and even if it could be achieved, somone still has to write the low level C/ASM code to make it all work. For many embedded systems, low level languages like C or C++ (perhaps Rust for a lot of ARM micros) is the only sensible choice. If it's not a multi user system that's connected to a network, people trying to abuse memory unsafe code isn't a concern.

View on HN

> has to write the low level C/ASM code to make it all work

shhh. Let's not disturb those that believe in the GC fairy that sprinkles their code with safety magic late at night while they soundly sleep. Firmware doesn't exist. I can't hear you. Na na na na na na na

Too late, here is Firmware being written in Go.

https://www.withsecure.com/us-en/solutions/innovative-securi...

I hope Rust takes off for embedded programming. I've been working with ESP32 and C is really the only choice if you are doing anything remotely fancy or resource constrained

What bothers me about rust is the designers are people that have been bitten hard by working on browsers written in C++ with it's manual memory management and no way to enforce object lifetimes. Rusts solution to that seems like a big hammer when it comes to embedded where you usually have either stack allocated or compile time allocated objects.

If you code in that style you won't even notice the borrow-checker is there. Unless you have a bunch of shared global state, the the overhead of arc will seem silly on your single core uc.

> bunch of shared global state

A good indication of embedded is having to manage shared global state.

This is very unlike a browser where you can hide all that behind OS calls.

That kind of style is often correlated with a lot of shared global state, even in relatively high level software like database engines. Most software avoids shared global state by delegating that implementation to the operating system, which often comes at the cost of performance.

I have worked in embedded code bases like that. While some of it is unavoidable for io, I have worked in other codebases where the compile time allocated memory was moved around in a way that would have satisfied the borrow checker except for that first mutable borrow. I haven't done rust for uc yet, so I won't claim it is a good fit, but it didn't seem like the parent poster had either, and I think there is a decent chance it could work well of the tooling is there. Which I'm not sure it is.

Python is more than adequate for most of the simple scripts that people run on Arduinos. There's no reason that a lightweight interpreter or even a compiled implementation could not run on even the AVR-based Arduinos, and obviously the beefier ones are straight up 32-bit ARM so it would be trivial to stand up MicroPython on them.

> The ATmega 328P an Arduino Uno or Nano uses has 2KB of memory and 32KB of flash storage for the program.

And costs the same as an ARM with dozens of megabytes of each.

Cheap ARM Cortex's tend to top out at 128/256k of flash and 8/16/32k of RAM.

Reply on news.ycombinator.com