Comment by Karliss
7 days ago
1KB isn't so bad unless you are making something complicated or need large buffers. You can do quite a bit of nontrivial stuff with it. Years ago I made universal remote with ATtiny13 + external EEPROM for storing remote data. It has only 64 bytes of RAM, that's what I would call very tight. Was still able to program it in C, 1KB flash and number of pins were bigger limiting factor than ram.
Plenty of DIY projects used ATtiny2313 with V-USB. That's a pure software USB implementation bit banging the IO pins (not a USB stack on top of hardware USB support)+ your application logic squeezed into 2K of flash + 128 bytes of ram.
Chips like this are great for digital glue logic. Read a sensor, read a button press, blink some LEDs with simple state machine or control loop.
It's been long enough ago that I don't use it as an interview answer anymore, but one of the most interesting things I built (technique-wise) was a Z-80 based serial multiplexer with no RAM. The only volatile memory it used was the device registers. The fun part was handling subroutine calls without a stack. The Z-80 has an indexed jump mode, so before calling a subroutine, I'd fill the jump register with the statement after the subroutine call, and when the subroutine was done, execute the jump with the (return) address prefilled.
Anything to save a few bucks on a 6264 SRAM component :-)
Yes, that's "bare metal" as opposed to programming in MicroPython, Javascript with Espruino, Lua/NodeMCU, Rust, or adding your C application on top of an off-the-shelf RTOS.
C support is basically universal these days, very few chips require you to program in only assembly anymore.
I had no troubles targeting an ATTiny13A with Rust.
(had to disable debug symbols, though)
Why should that be any harder than C?
Rust compiles to bare metal (assembly aka machine instruction code), just like C does.
It also supports running in freestanding setups without an OS, and quite a lot of the language's features still work.
I was extremely surprised by how much functionality is packed into "core", and runs without an OS when using freestanding rust. Even stuff that requires an allocator can run provided you provide your own heap!
A cool example of this was implementing fmt::Write for a memory mapped uart console thing. Then implementing a kprintln! macro that supports all of the formatting machinery that you are use to. This worked without even a heap available.
Bare metal refers to not using an rtos. I know that sounds weird but it is an industry convention. It does not refer to the language.
4 replies →
In Embedded, it's usually agreed that "Bare Metal" means using no OS, not meaning using low level languages.
2 replies →
Check out the video introducing Swift for Embedded. Seems like a really nice devX for this kind of thing.