-
I don't think you should learn how to program microcontrollers using C right now.
I'd recommend that you learn how to program microcontrollers using assembly first. That's going to be a lot right there, if you don't know anything about electronics and digital systems.
I started with a PIC16F883 controller. It's cheap, has many internal peripherals for you to mess around with, and has an easy to follow datasheet, as well as a manual that will explain things in even further detail. EVERYTHING is in the datasheet and manual for you. There will probably be some things you won't understand. There's a book called Digital Systems, 12th edition. It will teach you all about logic levels, logic gates, truth tables, Karnaugh maps, Boolean algebra etc. It's a great book and will help you out.
Once you learn how to do all that, and get good at it, you can start learning C++. Once you learn C++ and get good at it... you can then bridge the two together and start programming controllers using C.
Learning to program micro controllers with C immediately is craziness. You can probably do some stuff... but you really won't understand what your really doing at all.
-
It's more straightforward to use assembly when one's learning how microcontrollers work since there's less in between hardware documentation and a project.
The "stuff" in between editing an assembly file and having a binary to put on a chip is a little more transparent too. Most of the difficulty in writing C for a microcontroller is getting the toolchain to work.
I started with doing assembly with TI MSP430s which had the benefit of being ARM-esque. When getting started the chip you have in front of you that works is the best chip to use. Once you can see similarities and differences between chips to make a decision, then you can make a decision. -
Once you learn how to do all that, and get good at it, you can start learning C++. Once you learn C++ and get good at it... you can then bridge the two together and start programming controllers using C.
Learning to program micro controllers with C immediately is craziness. You can probably do some stuff... but you really won't understand what your really doing at all.
Advising for Assembly -> C++ -> C is .. questionable. C++ is a way more complex and non-obvious language than C.
And I don't see anything crazy or wrong in learning C straight away. In the end, C is a cross-platform assembly, that's what it is. -
There is no way on earth I would recommend learning assembly language for an ARM device as a first go at programming.
I also would caution against assembly language for mid-range PICs. They don't have very many instructions and extremely limited addressing formats along with an extremely limited stack and no PUSH/POP op codes, bottom line: they are UGLY to program. Keeping track of paging and banking is a PITA! And yes, I have spent a good deal of time with the 16F877(A) and 16F827. But that was 20 years ago and I'm not going to use them again.
The AVR ATmega128 is a reasonable architecture and assembly programming isn't overly difficult but why bother? C works very well with these ATmegas.
For certain incantations of ARM processors, the startup code must be written in assembly language. crt.s (or crt.S) is the usual file for this code. You don't want to write a lot of code in this file. Just branch to the C code and call it good. This is how it's usually done anyway. Only the most brief startup functions (set up .data and clear .bss) and certain interrupt vectors are contained here. The less the better!
IBM used to guesstimate 100 lines of debugged code per day. Those 100 lines can do a little (assembly) or a lot (FORTRAN), take your pick.
-
For a basic understanding of how a microprocessor works learning a simple assembler is certainly useful in learning how to program, but I second that going for ARM assembly is not good advice.
And indeed assembler -> C++ -> C is not the way to go.
In one of the first posts in this thread I advised to first study how a microprocessor work since the original poster wants to learn embedded programming, and to my opinion knowing how a microprocessor with its peripherals work will give you an advantage over just starting with programming in C.
Learning how assembly works is part of the process, also to my opinion. You don't have to become a master in assembly programming first, but at least know about the basics.
Then move on to studying C. And with that I mean the basics of C, like variables, if/else statements, for and while loops etc. Do not dive into library based functions just yet, like printf and atoi and what more you have, that are additions based on basic C.
See if you can write some simple program on a micro controller where you output something to a uart with just plain C.
That is how I learned to program. And take small steps just as someone else here advised.
Edit: I wonder if the original poster is taking in any of this? Being that his original post was his first and only one, and he was last active on the 23th of this month. -
There is no way on earth I would recommend learning assembly language for an ARM device as a first go at programming.
Actually, starting on an embedded platform to learn programming is a recipy for a dissaster. Better start to learn programming on a PC first. Command line tools are very close to embedded software as there is no graphical user interface. Also, a lot of embedded software is developed & tested on a PC because there will be much more debugging and testing facilities.
I agree with the people stating that programming consists of two things you'll need to learn: 1) how to translate a problem into a structured flow (using flowcharts / UML / whatever) and knowing the programming language inside out.
-
Agreed. While the question itself was a bit too wide, and even seasoned CS teachers may have a hard time giving a fully satisfying answer in just a few lines, learning "programming" directly on microcontrollers sounds like a bad idea and usually leads to poor software developers with bad habits.
But to even answer the question, we'd need to know what the OP's goal is to begin with. Maybe they don't care about becoming a poor software developer and they just want to make some LEDs blink, or something. -
That's one of the advises on the topic, which I bumped at in 90s, which I follow to date.
A piece of documentation to the Merc MUD, written in summer 1993, https://github.com/alexmchale/merc-mud/blob/master/doc/hacker.txt -
Agreed. While the question itself was a bit too wide, and even seasoned CS teachers may have a hard time giving a fully satisfying answer in just a few lines, learning "programming" directly on microcontrollers sounds like a bad idea and usually leads to poor software developers with bad habits.
But to even answer the question, we'd need to know what the OP's goal is to begin with. Maybe they don't care about becoming a poor software developer and they just want to make some LEDs blink, or something.
In some ways, I think the Raspberry Pi is perfect for learning both application programming and embedded programming (such as it is on the Pi).
Software development is much easier on a Linux workstation and the Pi provides that. Given one of the Starter Kits, embedded programs are also workable. Certainly not bare metal and, yes, there are some layers in the path but none of that matters in the vast majority of applications. I would go for the Pi 400 but the Pi 4 is certainly workable.
If you simply must use Windows, SSH is enabled on the Pi by default. Use Putty on Windows to make a SSH connection to your Pi (although getting the IP address may be a problem the first time around). Later, use VNC to get a graphics windows on Windows of the PI desktop.
This kit is particularly useful as all the code is given in C, Python, Java and Scratch. There are many interesting and useful projects to build:
https://www.amazon.com/Freenove-Complete-Raspberry-708-Page-Tutorials/dp/B09ZXNL2WH
That still leaves a large gap that I'll call 'design'. That comes with experience, both bad and good.
-
In some ways, I think the Raspberry Pi is perfect for learning both application programming and embedded programming.
RPI is not embedded programming, it's a GNU/Linux computer running a GLIBC-based rootfs.
Sure, you can use GPIO, spi, i2c, etc, but this doesn't make it an embedded device.
Embedded is a vague term. Yes, the RPi can be considered an "embedded" target, but no, it is about nothing like a microcontroller, for instance.
There are ways to program it bare metal, but this is way, way beyond any beginner's capabilities (and even those of many experienced developers!)
I for one find some answers rather strange here, but probably coming from the fact the question was posted in a "Microcontrollers" section.
The easiest, most comfortable and more flexible way of learning "programming" is to simply use a PC. Almost everyone has one these days, and tools (even free ones) are abundant. Free resources are abundant as well. You can basically start with zero cost and actually learn something. Go "embedded" if that's a goal of yours only after you have at least mastered the basics.
-
All utter nonsense. Only people that like being in a world of pain would adhere to such restrictions (and use OpenWRT nowadays). You have to be aware that crutches like ucLibc where invented to deal with limited storage which was an issue >15 years ago. Nowadays such limitations no longer apply and hence the need for crutches is no longer there.
Any computing system inside a device that isn't a desktop PC or server, is embedded. -
Any computing system inside a device that isn't a desktop PC or server, is embedded.
Your definition becomes all the more correct if we include systems such as the Jetbot Nano which, while running a full version of Ubuntu, is aimed at some variant of AI where the CUDA cores are working at a parallel solution to some gigantic matrix problem such as computer vision route following. Independent of the OS, the Nano can achieve 472 GFLOPS (16 bit FP) with 128 CUDA cores.
Many years ago, it wasn't uncommon to see laptops dedicated to small(ish) robots. I would argue that the primary purpose of the laptop was control and that would make it 'embedded'. By my defintion...
It isn't easy to differentiate or classify embedded versus non-embedded. Large AI projects may indeed use a server for the number crunching and some variant of networking for communication. The application is still 'embedded' if the purpose of the system is something like facial recognition.
-
Any computing system inside a device that isn't a desktop PC or server, is embedded.
Wikipedia agrees with this: https://en.wikipedia.org/wiki/Embedded_system
The first sentence of the Dutch version of it might be interpreted as such that it includes your every day computer too. https://nl.wikipedia.org/wiki/Embedded_systemQuoteEen embedded system (ook wel ingebed systeem of geïntegreerd systeem) is een elektronisch systeem (hardware én software) dat is geïntegreerd in gebruiksartikelen of apparaten, met de bedoeling deze een vorm van intelligent gedrag te bezorgen.
QuoteAn embedded system (also integrated system) is an electronic system (hardware and software) that is integrated into consumables or appliances, with the intent to give them a form of intelligent behavior.
Some might say that this is what a computer does. -
Good old pic16f84 books, that's where I started!
No magic libraries, no "do_everything();"
-
Raspberry Pi becomes embedded when you build a WiFi connected coffeemaker out of it. If you connect a monitor and keyboard (or through SSH) and use it as a programming learning environment, then it's not embedded, except that if your aim is to make the coffeemaker after all, then it maybe is embedded. Go figure.
Embedded is one of those relatively useless and potentially confusing terms. This is why I say microcontroller when I mean microcontroller, and say single-board computer when I mean a general purpose computer which runs a general purpose OS.
These terms are much more well-defined (not perfectly of course) and have handy TLAs, namely MCU and SBC. -
Raspberry Pi becomes embedded when you build a WiFi connected coffeemaker out of it. If you connect a monitor and keyboard (or through SSH) and use it as a Embedded is one of those relatively useless and potentially confusing terms. This is why I say microcontroller when I mean microcontroller, and say single-board computer when I mean a general purpose computer which runs a general purpose OS.
But what do you call a board with a micro-controller? And when does a board become a computer?
Technically speaking the chip on a raspberry pi is a micro-controller. It has a CPU and peripherals, which somewhat is the definition of a micro-controller.
And with the rather powerful micro-controllers like on a raspberry pico it is possible to drive a vga screen and turn it into a computer. Not a good one to run linux on, but might be possible. -
Not sure debating about what "embedded" really entails is that fruitful, but hey. Here goes.
Words have a meaning, and common sense supplements them.
What is commonly called "embedded" is the *embedded* CPU or more generally "computing resources" in any device *the purpose of which is not computing per se*. (There is some computing resource embedded in something else, that's the whole idea.)
While many people assume that "embedded" is basically something around either a MCU, or a simple SoC, and no OS or some kind of dedicated low-level RTOS, this is just a narrow view. For instance, some scopes of the 2000's were based on a mini-ITX motherboard, a x86 CPU and Windows 2000 or XP. Would you not call that "embedded"? Examples abound. Many avionics devices look more like full-fledged computer-like motherboards than small boards based on some MCU, yet they perfectly qualify as "embedded". They also often run some OSs that are way more complex than say, FreeRTOS.
-
There is no way on earth I would recommend learning assembly language for an ARM device as a first go at programming.
The basics of the ARM assembly languages are among the better ones. If you can find something with an ARM7TDMI then that's fairly simple to learn on. Hard to know whether A32 mode or T16 mode is better to start with, as they both have strong and weak points. But either is massively better than the complexity of ARMv7 / T32.
It's usually the hardware setup stuff that kills you on modern ARM SoCs.
Cortex M0, and the Pi Pico, are probably a good modern, easily obtained, place to start.QuoteI also would caution against assembly language for mid-range PICs. They don't have very many instructions and extremely limited addressing formats along with an extremely limited stack and no PUSH/POP op codes, bottom line: they are UGLY to program. Keeping track of paging and banking is a PITA!
A restricted ISA isn't a bad thing in itself. A beginner should mostly use their time to learn how to use the available tools, not learning what the tools are. They shouldn't be wondering if they've missed something, or if there is some cool construct/instruction that does exactly what they want but they just haven't found it yet. They shouldn't be wondering what is legal and what is illegal.
But PIC goes too far, and in a very awkward direction that doesn't fit modern programming practices.
A week or two ago I did an exercise where I reduced the already pretty slim (37 instructions) RV32I instruction set down to just 10 (ten) instructions that are still sufficient to write absolutely any program, or to compile C to. Except for SB/SH (which need more) each missing instruction can be replaced by 2-4 of the remaining instructions.
I hand-altered some compiled C code (e.g. my count primes benchmark) to use only the 10 instructions and found the code size increase was less than 30% and the execution time increase much less than that (as most of the extra code was preloading constants outside a loop, for use inside the loop).
The instructions:
LW, SW Rd, imm(Rb): load/store with register base and 12 bit signed offset
ADDI Rd, Rs, imm: add 12 bit signed immediate constant
ADD, NAND, SLL, SRA: Rd = Rs1 op Rs2 register to register ALU operations
JAL Rd,.+imm, JALR Rd,imm(Rb): unconditional branches
BLT Rs1,Rs2,.+imm: conditional branch
That's a really small instruction set to be both universal and to offer code size and speed close to real world instruction sets.
(NAND of course isn't a standard RV32I instruction, but is replacing AND, OR, XOR. I originally included BLTU until I realised you can emulate it by simply adding 0x80000000 to both values and then use BLT)
Working 10-instruction subset assembly language source for my Primes benchmark is here: https://hoult.org/primes.S (I didn't convert main(), just countPrimes())
The original C source is here: https://hoult.org/primes.txtQuoteThe AVR ATmega128 is a reasonable architecture and assembly programming isn't overly difficult but why bother? C works very well with these ATmegas.
Yes, a good choice for first adventures in assembly language programming, up there with RISC-V and ARM and MSP430.
I think C working well with an ISA is a basic prerequisite for bothering with the ISA at all, these days. If a compiler can use it easily then probably so can a human.
The one thing about learning programming, whether C or asm, on a microcontroller is the difficulty of observing execution. If you can attach a debugger and single-step then that's good, otherwise it can be best to learn using an emulator with instruction-by-instruction trace output.QuoteIBM used to guesstimate 100 lines of debugged code per day. Those 100 lines can do a little (assembly) or a lot (FORTRAN), take your pick.
The correct figure is ten
See "The Mythical Man Month" from 1975, by the manager of the software when the IBM 360 was developed.
-
Quote
The basics of the ARM assembly languages are among the better ones.
Perhaps the original ARM32 instruction set.
Thumb (eg all the Cotex-M microcontrollers) is less good. Obfuscated instruction encodings.
The Cortex-M0 subset of Thumb is pretty unpleasant. Lack of orthogonality and severe limits on operand ranges :-(
(Also, there tends not to be very much ASM example code for ARM (or any of the modern RISC architectures. Part of the whole RISC thing is that humans aren't supposed to need to deal with ASM.)
The MSP430 is pretty nice, but it's an older CISC-like architecture.
AVR isn't bad for a RISC-like architecture, but it's 8bits. Lots of existing material, though.
MIPS seems to be used by a lot of "computer architecture" classes, which might be a better learning path than simply "assembly language programming." But it's sort-of dying out (being replaced by RISC-V?)
-
Quote
The basics of the ARM assembly languages are among the better ones.
Perhaps the original ARM32 instruction set.
Thumb (eg all the Cotex-M microcontrollers) is less good. Obfuscated instruction encodings.
The Cortex-M0 subset of Thumb is pretty unpleasant. Lack of orthogonality and severe limits on operand ranges :-(
As I said "they both have strong and weak points".
Original ARM32 has a relatively small number of different instruction formats, and is quite orthogonal. If you think you should be able to do something then you can. But it's got the complexity of conditional execution in every instruction and the "free" shift/rotate in a lot of them.
Thumb1 has as you say a lack of orthogonality -- there are something like 20 different instruction formats, each with annoying restrictions -- and dealing with things such as hi vs lo registers is annoying.QuotePart of the whole RISC thing is that humans aren't supposed to need to deal with ASM.)
I've never agreed with that.
Some early RISC CPUs had programmer-unfriendly features such as branch delay slots and more generally no pipeline interlocks, so you had to count the number of instructions and clock cycles between an instruction that generated a result and the first instruction that used that result, and if you didn't leave enough gap then you just silently got garbage. THAT is the origin of the "humans aren't expected to program this by hand" meme, but it was actually just a terrible design in general because 1) compilers too often had to bloat the program size by putting in NOPs because there was no useful work that could be done while waiting, and more importantly 2) when you made a 2nd or 3rd generation machine with the same instruction set it had a different pipeline design and the rules imposed by the first design were simply not the right rules any more.
Once you added pipeline interlocks so the machine would just stall for a couple of cycles if needed, so you could actually build multiple generations of hardware that ran the same code, the programmer-unfriendliness went away too.
The remaining "programmer unfriendly" aspect of RISC is just the lack of memory-to-memory operations and complex addressing modes. Most of that went away once you got enough registers that all your function arguments and local variables can be in registers not in the stack frame. 32 registers is almost always more than enough for that, but 16 usually is too. VAX and M68k probably should have used a register-based ABI (as ARM32 and x86_64 both do with 16 registers).
If you want to code a = b + c on a machine with stack-based ABI then you want to have instructions like add b(SP), c(SP), a(SP). On a RISC machine with the same stack-based ABI you need load t1,b(SP); load t2,c(SP); add t1,t1,t2; store t1,a(SP). Which is admittedly pretty awful. But once you have a register-based ABI it's just add a,b,c, which is fine, and in fact I'd say *easier* than the CISC way.
-
try programing in assembly a MIPS4 machine like the R18200
-
A week or two ago I did an exercise where I reduced the already pretty slim (37 instructions) RV32I instruction set down to just 10 (ten) instructions that are still sufficient to write absolutely any program, or to compile C to. Except for SB/SH (which need more) each missing instruction can be replaced by 2-4 of the remaining instructions.
I hand-altered some compiled C code (e.g. my count primes benchmark) to use only the 10 instructions and found the code size increase was less than 30% and the execution time increase much less than that (as most of the extra code was preloading constants outside a loop, for use inside the loop).
The instructions:
LW, SW Rd, imm(Rb): load/store with register base and 12 bit signed offset
ADDI Rd, Rs, imm: add 12 bit signed immediate constant
ADD, NAND, SLL, SRA: Rd = Rs1 op Rs2 register to register ALU operations
JAL Rd,.+imm, JALR Rd,imm(Rb): unconditional branches
BLT Rs1,Rs2,.+imm: conditional branch
That's remarkable!
Is there a reason for that exercise other than curiosity? Like, to build a minimal RV core on an FPGA? -
A week or two ago I did an exercise where I reduced the already pretty slim (37 instructions) RV32I instruction set down to just 10 (ten) instructions that are still sufficient to write absolutely any program, or to compile C to. Except for SB/SH (which need more) each missing instruction can be replaced by 2-4 of the remaining instructions.
I hand-altered some compiled C code (e.g. my count primes benchmark) to use only the 10 instructions and found the code size increase was less than 30% and the execution time increase much less than that (as most of the extra code was preloading constants outside a loop, for use inside the loop).
The instructions:
LW, SW Rd, imm(Rb): load/store with register base and 12 bit signed offset
ADDI Rd, Rs, imm: add 12 bit signed immediate constant
ADD, NAND, SLL, SRA: Rd = Rs1 op Rs2 register to register ALU operations
JAL Rd,.+imm, JALR Rd,imm(Rb): unconditional branches
BLT Rs1,Rs2,.+imm: conditional branch
That's remarkable!
Is there a reason for that exercise other than curiosity? Like, to build a minimal RV core on an FPGA?
Mostly just interest in how minimal you can go without suffering too much. Maybe with an idea to build something in 7400 logic sometime?
We know we can build a one-instruction computer using, for example, SUBLEQ. But it's awfully inconvenient to use and you lose more than an order of magnitude of speed compared to normal ISAs. How low can you go while staying reasonably fast, and fully supporting C++?
Logic gates isn't the only resource I tried to minimise. Instruction opcode space is also valuable. The cost to have AND, OR, XOR ... and SUBTRACT ... is pretty minimal in gates. And whatever ALU operations you have, providing immediate operand versions as well as register operand versions uses an extremely minimal number of gates. But it uses a lot of opcode space. With 5 bit register fields and 12 bit immediate operand fields, every ANDI, ORI, XORI uses the same amount of opcode space as 128 AND, OR, XOR register-to-register instructions. And yet ORI and XORI are almost never used. On the other hand ADDI gets a huge amount of use: incrementing and decrementing counters and pointers, allocating and deallocating stack frames, loading constants, copying one variable to another (add #0)
With only 10 instructions, you're *almost* down to only needing a 3 bit opcode field. Could these instructions be encoded in a smaller way than RV32I's 32 bit instructions?
-
Which are the minimalist instructions ever? Like ijvm?
-
Which are the minimalist instructions ever? Like ijvm?
According to the wikipedia page, that's got 28 instructions! And without any kind of shift or rotate -- my 10 instruction ISA at least has 2 instructions dedicated to shifts.
I don't have HALT or IN/OUT but I can do everything else. I/O in modern machines is done with memory-mapped I/O registers not special instructions. For HALT you can probably just substitute an infinite loop.