Getting started with microcontrollers

[brucehoult]

A newbie?  They are going to write "a = a + b" and a thing called a C compiler will turn that into the necessary four AVR instructions. Instructions which the newbie will never see or be aware of.

Yes, C compiler hide it, but if you attach with debugger you will see that STM32 doing it with a single instruction, while 8-bit CPU requires several instructions to calculate 32-bit integers.

If newbies are using a debugger, it will be a source-level debugger.

And you will need to know it in order to understand why 32-bit MCU do it much faster even if you configure both 32-bit and 8-bit MCU for the same clock frequency...

Supercharged V12's go faster at the same RPM than 4 cylinders, but 90% of people drive 4 cylinder. They get the job done.

[radiolistener]

For a newbie learning to understand the AVR based ones definitely is easier just because the core is simpler and the peripherals are simpler.

I don't agree with this. Less resources, less performance don't means that learning will be more easy.

I'm strongly sure STM32 is better platform for beginners.
And choice for STM32 platforms will helps to make life more easy for beginners i future...

For example. ZX Spectrum 48 "core is much more simpler and peripherals are simpler", but does it means that newbie programmer these days should use ZX Spectrum 48 instead of Raspberry Pi 4 for learning?


I know some guys who will try to prove that ZX Spectrum 48 is the only option which newbie programmer should start with and Raspberry Pi 4 is too complicated for newbie. The same as you're trying to impose your opinion that Arduino is the only option which newbie should start with. But is that true? What do you think?

Many newbies starting learning with Raspberry Pi and have better progress than these who started with ZX Spectrum 48. Despite the fact that Raspberry Pi core/peripherals are much more complicated than ZX Spectrum 48, it still helps to learn with Raspberry Pi more easy than with ZX Spectrum 48. Isn't it? 


AVR was nice controllers for programming in asm 25 years ago. I remember 2004... they sent me large stickers "My microcontroller can beat your microcontroller", that was funny So they had good marketing even 20 years ago, but that is just marketing and ideology. These days it's architecture become very ancient and learning it will become a breaker to learn modern controllers like STM32.

I know peoples which cannot learn STM32 just because they started with AVR with Arduino and now unable to learn STM32. And since modern market is full of different STM32 and other ARM contorllers, they feel like failures and are forced to buy very expensive and slow controllers, simply because they are used to them. That's real world... 

So lets just leave it at that and stop polluting this thread with personal believes about what you think he or any other newbie should do.

Note, that I didn't talked what newbie should do. This is your pollution's here with categorical statement "newbie should start with arduino UNO or nano with no alternative" 

I just explained why your idea that "newbie should start with arduino" is not good, and provided info that there are other ways which is better if you want to learn microcontrollers for professional purposes.

As I already stated, this is your choice what you should use.

I just wonder, why you're trying to hide info that there are other solutions?
Why you're impose this limited arduino solution as the only and uncontested way that a beginner should do?

[tooki]

You clearly don’t see or understand the value of getting a beginner going with a low barrier to entry. Early successes are encouraging, and make the learner experience that they can get it to do something.

Yes, I don't see any barriers here to entry for beginners. The only barrier here is a mind lock like "it looks unclear and not familiar for me, so I don't  want to look into it and don't want to learn it". This is not a barrier, but just an unwillingness to learn something new.

Anything that stands in the way of getting things done — including lack of knowledge — is a barrier.

Nothing has zero barriers to entry. But some have more than others. If you don’t see this, then you’re blind.

And what you’re pushing for in subsequent replies is the exact opposite of what any sane beginner would do. You clearly have ZERO clue about how to educate, so I sincerely hope you are never in a position to be training beginners.

I suspect, however, that trying to get you to understand this is as pointless as discussing “analog vs digital” with you, in that the fact that the entire rest of the planet disagrees with you isn’t sufficient to make you reconsider your viewpoint.

So to any beginners who are reading this: ignore basically everything radiolistener has said in this thread.

[pcprogrammer]

Supercharged V12's go faster at the same RPM than 4 cylinders, but 90% of people drive 4 cylinder. They get the job done.

I would state that they also consume less energy (the 4 cylinder types), but that analogy does not necessarily apply to the MCU world. The older types can consume more per MHz than the newer ones.

Quote from radiolistener.

I just wonder, why you're trying to hide info that there are other solutions?
Why you're impose this limited arduino solution as the only and uncontested way that a beginner should do?

We are not hiding this, we are just stating that a lot of the other solutions are more complex to start with.
If a beginner wants to dive into the deep end with and STM32, ESP32, RP2040 or whatever is out there that is perfectly fine. And with the Arduino IDE the simple things will be most likely just as simple, but the moment you want to go a bit deeper it gets more complicated.

An STM32 timer has much more possibilities than the ones on the ATmega MCU's, and the documentation is less clear for the STM32's. That is what we are trying to put out there.

The comparison between ZX spectrum and Raspberry PI is very lame and bares no weight here. Both these systems run on an OS. Basic for the first one and mostly Linux for the latter. This makes things a lot easier. Go and try to program the Raspberry PI bare metal, without any prior knowledge. It will be much harder than doing it on a ZX spectrum. The needed information is much easier to find for a Z80 based system.

But as others have already concluded you are pulling our chains and that is what is called trolling. I have seen this behavior of you in other threads too and a lot of the more active members state to take everything you write with a grain of salt, or negate the advice to do the exact opposite. So you saying "don't use the Arduino with ATmega", actually means "use it as much as you can". 

[dobsonr741]

try to program the Raspberry PI bare metal

Respectfully disagree, bare metal raspberry pi is simple with Circle: https://github.com/rsta2/circle

[pcprogrammer]

try to program the Raspberry PI bare metal

Respectfully disagree, bare metal raspberry pi is simple with Circle: https://github.com/rsta2/circle

Well that is not the intention of how I meant it. Here the work has been done by others to facilitate you to program somewhat bare metal.

My view point is to work from nothing else but the documentation available on the raspberry pi. Then it ain't simple anymore. Having to deal with multiple cores and the correct startup sequences, etc.

Everything is simple when someone else already did the hard work.

[dobsonr741]

Newton said “If I have seen further it is by standing on the shoulders of Giants” February 5, 1676. Applies to us and open source. I always consider it, unless there is a corporate policy opposing a certain type of open source license.

[radiolistener]

And what you’re pushing for in subsequent replies is the exact opposite of what any sane beginner would do. You clearly have ZERO clue about how to educate, so I sincerely hope you are never in a position to be training beginners.

I had some experience to train beginners, and they had very good progress and thanked me for the training. I success to learn even these who was unable to learn from other teacher who are professionals in education. This is nice to see their progress, it's like your own progress. But education someone eat a lot of my energy, so I think you're right - this is really not my mission to teach others. Even 2-3 hours per day for 5 students make me sucked all the energy out of me and I just collapsed at home and slept for hours. Teaching others takes too much of my energy, so I don't like it. 

I suspect, however, that trying to get you to understand this is as pointless as discussing “analog vs digital” with you, in that the fact that the entire rest of the planet disagrees with you isn’t sufficient to make you reconsider your viewpoint.

I well understand your point of view, but unfortunately when you can understand other point of view it don't means that he also can understand your point of view. That's the world we are living in. When you can see someones mistake, it don't means that he also can see their own mistakes... That is why I don't like to train someone, especially if he don't have enough knowledge or desire to learn...

The comparison between ZX spectrum and Raspberry PI is very lame and bares no weight here. Both these systems run on an OS. Basic for the first one and mostly Linux for the latter. This makes things a lot easier. Go and try to program the Raspberry PI bare metal, without any prior knowledge. It will be much harder than doing it on a ZX spectrum. The needed information is much easier to find for a Z80 based system.

I have no idea, why you're decided that someone needs to learn computers from programming bare metal for low level hardware? 

When you bought ZX Spectrum, do you started programming in Z80 machine codes or in Basic within the Basic interpreter?

The same for Raspberry Pi, why beginner should start programming bare metal for low level hardware instead of C or Python in the Linux environment? I think there is no such requirement and beginner can start programming in C or Python in the Linux environment. That is expected way.

And I think there is much more easy to find information about programming in C or Python for Linux, than for programming in Basic for ZX Spectrum. 

[radiolistener]

But as others have already concluded you are pulling our chains and that is what is called trolling.

Usually the trolls themselves who blame others for trolling. I just ignore it. 

I have seen this behavior of you in other threads too and a lot of the more active members state to take everything you write with a grain of salt, or negate the advice to do the exact opposite.

I don't trolling, but sometimes I can say something with a kind of sarcasm or as a joke. It should be obvious.

For example when I talked about Rust in this thread, it was a bit of a joke and a bit of serious suggestion. These who follow this suggestion won't regret it, but I understand that it looks scary for newbies and very small amount of them will not be afraid and will follow this path. And they will be rewarded. And I think you're know why 

The rest, who will accept your recommendation for Arduino Uno with a high probability will not be able to find themselves in programming for microcontrollers. I think this is not their mission in our world, so I’m not worried about those who take your advice, but those who take up learning Rust, I worry about them and I would like to support them

[kevin.gibbs]

If you want very simple solutions like reading inputs and activating outputs, your knowledge of assembler is enough. The code will take only a few lines after basic standard microcontroller configuration (stack placement, interrupt configuration). You will be more comfortable using the C language for more complex functions. It is probably better to start getting acquainted with it on Arduino examples.

[paulca]

I think there is a lot of debate here which is people not realising they are standing in different parts of the map and shouting about their perspective of what they see as the same thing, when it isn't.

Learning MCU development as a "Bare Metal" exercise is a valid pursuit to learn about how MCUs work.  In some cases it's the only option.

However.  Times are changing.  MCUs are now getting larger, faster, cheaper and in the emerging "hobbiest" markets were cost is far less of an issue due to very low volumes and no "bean counters", so the hobbiest can afford some pretty serious MCU hardware.

The Arduino Framework certainly wasn't the first "Generic Dev Framework" for MCUs, but it is certainly the first one that the world will remember.

Whether you guys like it or not, it splits the software model in two.  Actually, if you don't start accepting it and get onboard with the idea, you will either detrimentally harm the development or screw yourself out of a job further down the road.

The split is now between:
Framework and Library code <-->  Application code.

This is a natural split point in software as it tends to be different types/classes of developers who do well in lower level, generic framework and library code and those who do better at understanding and implementing what customers actually want.

In the big iron world the splits/layers/components/dependencies split dozens and dozens of times.

You can even see it in STM32.  They have several layers of frame works and abstractions.

The difference in my humble opinion is that Arduino and it's surrounding eco-system have functioning hardware integrations and devices for thousands of devices.  STM32 ... their HAL barely works on it's own, but comes with support for exactly zero devices. 

Even with that, in STM32 the HAL and LL libs are so broken and different between models and ranges that you stand about as chance of getting a "Plug and play" hardware driver as you do getting blood out of a stone.

If you approach this from the point of view of an Application developer, their first and only question is, "How do I make it work to solve this problem and meet the customer needs?".  They do not care HOW, they just want to get something working.

In my opinion, Arduino is the place to start.  If you don't like the hand-holding, over caring framework:
* You don't have to use it.
* It only costs you about $5 to switch to an STM32.

STM32 is better if you want to explore the still stuck in the 1990s MCU land.  This is where the industry still is basically.

While you and I can drop $30 on an STM32 H750 to run a pretty heating dashboard in 2Mb of RAM.  The product industry cannot.  Not when their competitor can run it with nearly as many features on an F411 costing a tenth the price.

Summary:  Regardless of the hardware, if you want to develop applications first and foremost, then a practical, easy to learn application dev framework is the way to go.  Aka Arduino.  Even if you are running Arduino Framework on Atmel/MC 8bit micros or on STM32H7 32bit dual cores or ESP32s.  If however you want to learn the low level reality of spending months trying to fit all your requirements into 16K or RAM and a 50Mhz CPU, using ASM macros and compiler tricks all day... and still contribute to some of the most buggy and annoying sofware in the world..... don't (use a app dev framework).

[Rick Law]

Thanks for the replies. 

Some background: About 50 years ago I had a 6502 board and I did quite a bit with it, all programming in assembler.  Then about 30 Years ago, with PCs, Windows, etc I lost the ability to interface with the real outside world and i kept thinking how I could do it. About 25 years ago I bought a Velleman K8055 board,
https://www.velleman.eu/products/view/?country=uk&lang=en&id=351346
which I still have, but I never did much with it after my first playing around.
... ...

The OP, in this follow up reply (reply #8 on this tread) says he did 6502 assembler on a 6502 experiment board.  So he knows how to develop program with limited feature, limited resources, and limited assistance (50 yr ago, no google search for help).

His having worked with an microprocessor based experiment board, Arduino UNO will be both familiar (UNO as experiment board)  and welcoming with more assistance than anyone could expect some 30/50yrs ago.

Once he starts with an infrastructure to load and run something on an MCU of any sort, I think he can move forward from there.  Discussion about features and resources with different varieties of MCUs may be interesting, but that surely doesn't have much impact during his getting starting phase.

[brucehoult]

The OP, in this follow up reply (reply #8 on this tread) says he did 6502 assembler on a 6502 experiment board.  So he knows how to develop program with limited feature, limited resources, and limited assistance (50 yr ago, no google search for help).

Indeed so, which is why AVR is a great place to start.

AVR is much easier to program in asm than 6502, is at least 50 times faster and often 150x -- 16x clock speed, 1 cycle/instruction vs 3-4 average, not to mention that, say, adding two local variables in registers vs two local variables in ZP is 1 instruction vs 4 (and 11 clock cycles) for 8 bit and 2 instructions vs 7 (and 2 clock cycles vs 20). Also setting up things such as GPIO on AVR is not much different to setting up GPIO on a 6522 VIA. You can't say that about STM Arm chips.

PLUS you've got the whole programming in C using the Arduino environment thing IF YOU WANT IT.

[John Celo]

I sometimes see ESP32 and similar microcontrollers suggested to beginners based on their specs alone, while neglecting some important aspects.

Namely, ESP32 has very slow build times (even after the first build where it caches *some things*), complicated toolchain and, in part, thanks to it's very large flash (8mb!), it takes quite a long time to reprogram the flash too.

The end result is that it is gathering dust, because it not fun to use a device that compiles and flashes so slowly.
And that's after getting ESP-IDF working with debugger, breakpoints and live variables.

Only after flashing ESP32 with micropython/circuit python did I start having to have fun with it, because the frustrating slowness of the toolchain gets sidestepped. And you can REPL it and iterate quickly and, well, actually have fun!

I'd rather use an anemic Arduino Nano, because it compies and flashes quickly, than a powerful device with a slow, complicated toolchain and massive flash that takes half a minute to reflash.

It's more than just raw specs. Turns out that I don't need a powerful specs to read sensors, blink leds, control an i2c/spi displays or some motor driver modules.

I've ordered STM32 board and an STLink programmer and I'm curious to see how pleasant or unpleasant, slow or fast the toolchain and overall development experience is going to be.

Needless to say, I wouldn't recommend MCUs to beginners based on specs alone, certainly not ESP32s (unless they explicitly want wireless perhaps)

[pcprogrammer]

I've ordered STM32 board and an STLink programmer and I'm curious to see how pleasant or unpleasant, slow or fast the toolchain and overall development experience is going to be.

You most likely won't be disappointed. The compiler is fast (gnu arm tool chain) and since the flash memories are not that big the programming is also fast. But figuring out how to setup the peripherals based on the datasheets is a bit more of a chore. On the one side due to the complexity and capabilities they offer, and on the other side due to the somewhat crappy documentation. 

[paulca]

I'd rather use an anemic Arduino Nano, because it compies and flashes quickly, than a powerful device with a slow, complicated toolchain and massive flash that takes half a minute to reflash.

Wow.  Half a minute.  You won't get very far in the big iron world with a total round trick of under 30s.

In Eclipse/IntelliJ and most serious IDEs it will be compiling the build constantly in the background.  So it seems almost instant, almost, not quite, but you can make a change and hit "Run tests" and it will actually start running the tests within 10 seconds or so.  Depends on how fast your machine is and how much memory you are playing with.

However.  Once that application component is "pushed" to the repo, the build pipelines will pick it up.  Some will reuse the checkedout, prebuilt workspace and pick up from the last build, but these are usually rare and discouraged outside of "DEV" environments.  For obvious reasons(?) generally the build workspace is wiped clean and all code and dependencies downloaded fresh for each build.

In these cases a moderately sized ... say ... SpringBoot based REST API Micro-Service, with less than 1000 lines of actual code, might take 10-15 minutes to complete.  That will be about 5 minutes to download everything, like the code, the dependant jars, and resolve the external dependency tree an download it.  (This is all similar to how PlatformIO or ESPHome remote serverside builds work in MCU land, just triggered off a Git push to a branch.)  It will take about 3-5 minutes to run the build.  Then another 5 minutes or so to build the docker images and deploy it to an environment.

Even for projects which are written in non-compiled code, such as python, it still takes 30-60s to build the docker image and another minute or two to deploy them.

Granted deployment isn't always required or necessary outside of CICD/CD you can usually run the code directly in a local dev environment and point against other pre-loaded docker services on your local machine.

For a bit of exposure to this 'real' world, try this simple task.

Compile Firefox from source on Linux. 

If you have done this, I would implore you to "STFU and dry your eyes.", you have it easy.

[radiolistener]

Compile Firefox from source on Linux. 

I wanted to compile it, but unfortunately download source code was failed due to not enough GB of free disk space. When I started download archive I didn't expected that archive will eat several GB of free disk space, but it also require even more space to unzip it...   

[paulca]

Compile Firefox from source on Linux. 

I wanted to compile it, but unfortunately download source code was failed due to not enough GB of free disk space. When I started download archive I didn't expected that archive will eat several GB of free disk space, but it also require even more space to unzip it...   

LOL, wait till you are multiple hours into the compile and it fails because it consumed >10Gb of disk.




May I add, for people like me the appeal of MCUs is their simplicity.

A platform for which you can "saturate the stack" from the very, very bottom to the very, very top.  Full 100% round-trip stack dev.  100% bespoke code.

Anyone who has tried (and it's worth doing for fun), "Bare metal" programming a modern PC will tell you it's damned complicated.  MCUs, even dual core ones are so incredibly simple in comparison you can actually get real, useful, functional code written for them.... bare metal.

Even to start to come up to something like 1980s DOS level of computing, bare metal on a modern AMD64 architecture is going to take you weeks and involve some of the most nasty low-level, detailed hardware/firmware and concurrency project you have ever encountered.

So for this I agree with those steering people away from Arduino, STM32-HAL, ESP32-IDF and others.  If you want the above go bare-metal datasheet and register macros.  Have fun.

However, my point still stands that if you want a "hobby platform" as a "maker" and your primary focus is on "making stuff" and "making stuff work", then you can take the above as optional.  Use the biggest, easiest, most convienient app dev framework for whatever hw platform you choose.

There is no need to pick one.   When we get Windows vs. Linux debates, it's pointless the answer to "Which is best?", is "Both".  Next!

I have limited experience in Arduino (including baremetal cross compiled avr toolchain), STM32-HAL, ESP32 (with arduino and IDF).

I have half a dozen H7 STMs with >1Mb static RAM, but I also have some F0's with 4K.  I have big Uno boards and I have custom PCB ATTiny85s.

No one size, platform, language, technology stack fits all.  The more the merrier.  More tools in the box with some knowledge in how to use them makes it far more likely you have the right one for the job at hand.

[pcprogrammer]

There is no need to pick one.   When we get Windows vs. Linux debates, it's pointless the answer to "Which is best?", is "Both".  Next!

Wrong, the answer is "Neither". 

[brucehoult]

Compile Firefox from source on Linux. 

I wanted to compile it, but unfortunately download source code was failed due to not enough GB of free disk space. When I started download archive I didn't expected that archive will eat several GB of free disk space, but it also require even more space to unzip it...   

LOL, wait till you are multiple hours into the compile and it fails because it consumed >10Gb of disk.

What kind of computer are you guys using?

Back when I actually worked for Mozilla in 2009, Firefox took around 10 minutes to build on my quad core i7-860. I imagine on my current *laptop* it would be 2 or 3 minutes.

And SSDs today cost 6c/GB, 10c/GB for a really good one. If you're still on 3.5" hard disks, 4TB ones are $70 ... less than 2c/GB.

[paulca]

Requirements¶
Memory: 4GB RAM minimum, 8GB+ recommended.

Disk Space: At least 30GB of free disk space.

Operating System: A 64-bit installation of Linux. It is strongly advised that you use a supported distribution; see Supported Build Hosts. We also recommend that your system is fully up-to-date.

[paulca]

Back when I actually worked for Mozilla in 2009, Firefox took around 10 minutes to build on my quad core i7-860. I imagine on my current *laptop* it would be 2 or 3 minutes.

2009.  Interesting.  My experience was around 2002 when it had only just been renamed to firefox from Mozilla (after Netscape died)

So, the last hardware I compiled it on would have been a PiledriverFX room heater octo-core with 4Gb RAM.  It took hours.  Although i did recall it being faster than vanilla Mozilla was (Mozilla at the time was trying to become a bonafide baremetal OS entirely).

The other monster when compiling a full Linux distro from source was "Open Office"  or previously "Star Office" or previously "Sun office".  It was another overnight compile with 10s of Gb of disc space used.

Back then I even had 3 old PCs all running "distcc" to speed up "OS Wide" make clean install scripts, with 100s for packages compiled.

Last time I did a full OS build though was 4 or 5 years ago. An instance of Gentoo Linux.  I recall the base system took less than an hour, the X11 layer about an hour and KDE 2 hours.  Firefox I didn't install and I accepted the "binary dist" chrome on advice at the time.

So maybe you are right and Firefox is no longer an "compile overnight" monster.

[radiolistener]

What kind of computer are you guys using?

Back when I actually worked for Mozilla in 2009, Firefox took around 10 minutes to build on my quad core i7-860. I imagine on my current *laptop* it would be 2 or 3 minutes.

And SSDs today cost 6c/GB, 10c/GB for a really good one. If you're still on 3.5" hard disks, 4TB ones are $70 ... less than 2c/GB.

On PC I have 5-10 GB free space on 1TB drive. When I realize that this is not enough space, I tried to download it to a fast 16GB flash drive, but it appears that it also not enough to unzip the source even if archive is downloaded to a separate disk.

[brucehoult]

So just for fun I tried it.

I expect 2009 Firefox would build in 2 or 3 minutes now, but 15 years later 2024 Firefox took 11m18s to build on my laptop [1]. CPU time was 204m54s User plus 8m24s System.

That's a "non-artifact" build, which is their current term for compiling all the C / C++ / Rust rather than downloading pre-built object files and only building the Javascript (etc?) implementing the UI.

Downloading and unpacking the source took around 20 or 30 min (depends on your internet speed of course), ending up using 9336 MB of disk. Fully built it's now using 26058 MB of disk. Let's call it $2.50 worth of SSD.

[1] Lenovo Legion Pro 5i (2023), i9-13900HX, 32 GB RAM, 1 TB SSD, 4060 GPU, cost $1750 inc tax&delivery

[paulca]

Parallelism is highly important of course.  The kernel is usually the master of this.  Given enough distcc instances and cores it will go faster and faster and faster with so many non-dependant targets to compile.  I just wish Make could cope with parallel targets including linking.

When working with LFS (Linux From Scratch) the metric was known as BinUtils.  A base system would take 24.5 BinUtils to compile.

So you referenced it by the first thing you compiled.... err binutils.  How long it took and then all other compile times where ratios to that.

EDIT:  Up to the day.  On a personal project, if I commit a code change and push it, gitlab will launch pipelines to build the python library, then build the docker image for that section of project and push it to a registry.

A single character typo can result in a wait of 5 minutes or more.

This was only implemented as a learning project, as it is how things are done when you have a few dozen developers and not one.  However, as I am one dev on this project, I am winding all of that back to simple "build.sh", "deploy.sh" scripts.  No need.  Sledge hammer to crack a nut.  CNC machine to mount a shelf.