When to use a microcontroller?

For help with the bus itself (not a specific product).
Posts: 165
Joined: Sun Sep 18, 2016 6:07 pm

When to use a microcontroller?

Postby rpu_bus » Sun Sep 17, 2017 2:43 pm

I was looking at some literature regarding [Rust on MCU's] and I don't make it very far...

[Rust on MCU's]: https://github.com/japaric/discovery/tree/master/src/01-background

I think Rust and Micropython are a good way to abstract a complex MCU. The real problem when someone like myself writes a program for an MCU is that I can clobber the control registers with ease. This can make programming very frustrating, No matter how amazing an ARM, MIPS, or x86 may be they are complicated and easy to mess up. So Rust, Micropython, eLua, and in the distant past Ladder Logic gained traction to varying degrees as the abstraction layer between the bewildering complexity of MCU's and their usability. I personally really like the idea of Micropython but that is because I like Python so much.

People love ideas like future proofing or 32 bits cost less, but those ideas are mind viruses and don't hold up when you look at the facts. The fact is 8 bit MCU's cost less (just go to Digikey or Mouser and look for the lowest prices), 8 bit MCU's are not going away, in fact some like the ATmega328 are more likely to be available in twenty years than any 32 bit option (which seem to pass into and out of production like water flowing down a creek). My idea of future-proof is that I can build the product in the future and the parts will be available.

Some hardware engineers (e.g. myself) like 8-bit machines, partly because their 400-page datasheet leaves some room in the brain. I don't have room or patience for the 4000-page M0, and especially not the 40,000-page x86. Also, it is my opinion that programming an 8-bit AVR in C is less problematic than programming an ARM or x86.

So if abstraction layers are the answer then why not always use them? Well, it turns out that MCU's are used to do some strange things, and if those things are not in the abstraction layer then the hacking absurdity to work with what is available begins. Having a simple machine that can be programmed with C or assembly to do precise timing (i.e. within a few clocks) is really important, I don't think software people understand this (for the most part anyway). It is the sort of thing that yields an ideal spark time in an internal combustion engine or measures an optical or VR homing mark on the fly (it is not just about the ws2812 or NeoPixel).

C is an abstraction of the machine instruction set, while assembly code is a textual representation of the machine instructions. C++ is an object-oriented extension to C that make use of the heap memory system for OOP purposes. C is the sweet spot for programming microcontrollers when the higher level abstraction languages don't offer the desired functions. Arduino programs are written in C++, but I had problems every time I made use of the OOP features, so I ended up using C. After some research, I concluded it was the way C++ used the heap memory that was causing the problems. After that conclusion, I ported or unwrapped everything I used back into C and the various problems vanished. C only uses the heap when you tell it to (e.g. malloc, calloc, free, realloc...), so you can prevent heap fragmentation by simply not using it (an Operating System will catch the fault when the heap and stack memory systems collide, or add more memory to the heap if it is available).

I probably need to be clear about C++ on an MCU. It can certainly work for a programmer that knows what they are doing, but I am no way in hell going to spend my time making it work.

To sum this up I would use C for 8-bit AVR devices and Micropython, Rust, or eLua on a 32 bit ARM devices (unless I had a compelling reason to use C). If there is an OS like Linux on the device then any language is good (e.g. C++, Python, Perl, more Python to get the bad taste out).
Last edited by rpu_bus on Mon Sep 25, 2017 10:49 pm, edited 1 time in total.

Posts: 165
Joined: Sun Sep 18, 2016 6:07 pm

Re: When to use a microcontroller?

Postby rpu_bus » Tue Sep 19, 2017 1:45 pm

What about the editor and/or IDE to use with the MCU?

I would not read too much into what these [recruiters] have found but it is still worth a look (they have probably lumped C into the C++ category).

[recruiters]: https://triplebyte.com/blog/technical-interview-performance-by-editor-os-language

I use SciTE fairly often and some nano/pico or Vim. I don't use Vim enough to be any good at it. I was thinking about trying Atom, but my time would be better spent with Vim and just using it more. Vim is actually fairly good to work with on a headless device, which I suspect will be increasingly common now that I have the [RPUpi] working. Pycharm also looks interesting, but I think the programs I do are too small to benefit enough. One thing interesting is how much they dislike Eclipse.

[RPUpi]: https://github.com/epccs/RPUpi/

Return to “Installation, Troubleshooting, and Usage”

Who is online

Users browsing this forum: No registered users and 1 guest