Suggestions for a microcontroller (general-purpose)

[Analog Kid]

Let's say a guy who last worked with microcontrollers (a Ubicom SX-28) about a decade ago, and now wants to start playing with one again. Question is, which one?

I've thought about something like the AT-Tiny or equivalent. But there are so may choices available, it's quite confusing.

Here's what I'd like to have:

• 8- or 16-bit controller (maybe even 32-bit later on)
• Real-time clock/counter
• USB programming (I guess almost everything uses this nowadays?)
• Programmer with ZIF socket
• Basic IDE that runs under Windows: assemble/link/run from PC; maybe a debugger, though not necessary
• Several I/O ports
• Ability to use interrupts and to create my own ISRs
• Moderately fast; speed not crucial, but at least many MHz would be nice
• Decent amount of program & data memory
• Likely to remain available and supported in the forseeable future

I want to program in the μc's native assembly language, not C or C++. The IDE would let me create and use my own libraries (or I could simply create separate object modules), or I could simply put everything in one source file.

The IDE wouldn't even need to have its own editor (though it probably will): I have my own that I use for programming.

So what would y'all suggest? Oh, and $inexpensive$ would be nice.

[brucehoult]

You really need to define your terms.

The only concrete thing you're said is "ATtiny".

As far as I know, ATtiny maxes out at:

- 32 pins on ATtiny 48, 88, 828, otherwise 24 or fewer

- 3k bytes RAM on ATtiny3224/6/7, otherwise 2k bytes or fewer.

- 32 KB program memory (flash) on ATtiny3216/7/24/6/7, otherwise 16 KB or less

- maximum 20 MHz

And 8 bit, obviously.

The bigger ones cost something like $1.30.

Looking at those specs, how would you feel about:

- 32 bit

- 48 MHz

- 2 KB RAM

- 16 KB program flash

- 8 to 20 pins

- $0.10 to $0.20

[ledtester]

I would look at the Raspberry Pi Pico and the W-version for wifi and BT radios.

- dual core, lots of memory - both RAM and flash, fast, decent amount of GPIO, standard DMA and timers plus the programmable IO blocks which people have done some amazing things with

Also - it is very easy to program - it can appear as a mass storage device so you just  drag-and-drop files to program it. You can actually use flash as a file system which your applications can access.

In addition to C/C++ it can be programmed in Micro Python which can be fast enough for a lot of things like experimenting, prototyping and avoids the complexities of C.

Lots of hobbyist support.

[Smokey]

Professional use that might end up in products:
For a full range of parts within the same development environment, I'd say STM32 stuff.  People complain about CubeMX and CubeIDE, but it's a full featured thing supported by a big company that doesn't routinely make breaking changes to stuff and will be around for a while (and isn't Chinese, which is relevant for a few reasons these days).

For hobby stuff:
Whatever was used by whatever project you are copying and already has working code somewhere.

[Analog Kid]

Please keep in mind that I want to program this in assembly language, not C or Python or whatever.
Just my preference.
And yes, this is for hobby use, not production. But I don't want to just follow an instructable or someone else's design and use whatever they used: this is for my own li'l projects.

[Smokey]

I'd still pick stm32 stuff.  Just in case you change your mind and actually want to finish a project then the c dev environments will be there waiting for you ready to go :⁠-⁠)

If it's not for a product and you don't care about cost or dev tools, then just about anything is on the table and I can't say why one would be better than another.
Actually maybe you might want to use 8051 stuff since that's been around from the old days when people still used assembly.  You could find an old library books that has asm examples code.

[Analog Kid]

Well, just for ha-has let's say a guy wanted to investigate going the 8051 route: what would a guy do for a programmer? Are there USB programmers for that processor? I wouldn't guess so.

Point is, I need a package: microprocessor, programmer & IDE (basically Windows software to run the programmer). Doesn't have to be anything fancy.

If a programmer is easy enough to build (including the software to drive it) I might could do that.

[brucehoult]

Well, just for ha-has let's say a guy wanted to investigate going the 8051 route: what would a guy do for a programmer? Are there USB programmers for that processor? I wouldn't guess so.

Point is, I need a package: microprocessor, programmer & IDE (basically Windows software to run the programmer). Doesn't have to be anything fancy.

If a programmer is easy enough to build (including the software to drive it) I might could do that.

Even our host managed to work out the MCU, at a similar level to ATtiny, but much cheaper I was alluding to.

[Smokey]

Looks like Atmel/Microchip have a whole series of 8051 stuff (at89) with all sorts of programmer options from uart bootloader to spi to jtag. 

[RoGeorge]

Buy any Arduino.  Use assembly instead of C.  Anything that can be programmed in C or Python can be programmed as well in assembler.  See in this search results which one you like:
https://duckduckgo.com/?t=ffab&q=arduino+in+assembler&ia=web

Also, writing in assembler is a futile exercise these days.  That was a thing 30+ years ago.  Nowadays C optimization is very good, and the ratio between speed vs memory optimization can be changed with a simple compile switch.

[IOsetting]

I would recommend stm32, which covers both hobbyists and professionals, the toolchains and hardware are affordable, no knowledge will be wasted, no significant challenges in near future (if there are any, it might be risc-v).

[pcprogrammer]

If you really want to stick to assembler, the AVR based MCU's (ATtiny - ATmega) will be easy to use. A USBASP will be very useful for working with them. https://www.aliexpress.com/item/1005006827605143.html

The 8051 core based MCU's are also an option, but I don't know about how to program the more modern versions. My experience with them is from way way back and used UV erasable EPROM's to hold the code. Did write in assembler. But now that I'm using C to work with the more modern MCU's I would not dream of going back to assembler to write a full program.

The STM32's or Raspberry Pico recommended by some are 32 bit ARM based and very powerful, but learning the full width of the assembly language takes quite some time, in which one can easily learn C or micro python. I myself would choose C, because it allows you to use many different MCU's with even the ones with small memories.

Also, writing in assembler is a futile exercise these days.  That was a thing 30+ years ago.  Nowadays C optimization is very good, and the ratio between speed vs memory optimization can be changed with a simple compile switch.

I fully concur with this. Don't be a dinosaur and move on to learn C, unless assembly is what you grave of course.

[peter-h]

How cost sensitive is this?

If you can afford say $5 them go for arm32. These chips (I am using STM 32F417) do basically everything for most products including USB and ETH. And you will save yourself a huge amount of work re-doing every new product or version.

[voltsandjolts]

Suggestions for a microcontroller (general-purpose)

Most microcontrollers are general purpose. Take your pick.

[phil from seattle]

Just about every micro out there can be programmed in ASM. I don't think that is a limitation. 

I'd skip 8 and 16 bit micros and go straight to 32 bits. My current favorite is the RP2350 or RP2040.  The RPi Pico (RP2040) costs all of 4 bucks, there is a WiFi version for a buck more, programs via USB, has in circuit debugging and has several tool chains (including Arduino). And as a bonus, you can get custom boards made for a very reasonable amount if that's something might want to do. I've used just about every micro out there and love the simplicity of the RP series. One of the really cool things about the RP family is programmable I/O (PIO) - basically little general purpose programmable I/O finite state machine processors that allows hardware control independent of the CPU. It can be a serious performance boost over non-PIO implementations. The RP2040 has 8 and the RP2350 has 12. We use them in a motion controller application to significantly boost the step rate to servos and avoid use of a second timer.

As to the 8-bit 8051, way long in the tooth (~45 years old).  Perhaps venerable is a kinder term. Used for embedded cores in all sorts of controllers. It available as a soft core in VHDL and Verilog.  Also for FPGAs.  Good skill to have in certain job categories. But, again, I'd skip 8-bit and to go to 32.

[Picuino]

Why would you want to program only in assembler? That's going to limit you a lot on larger micros (16 and 32 bit).
Nowadays it is much better to program in C and leave assembler for small optimized routines or access to special instructions.

I would advise you to look for micros from the old Atmel (now Microchip). Not the attiny range, but the atmega and above.

Here you have some tools to search for micros:

* https://www.microchip.com/maps/Microcontroller.aspx
* https://www.microchip.com/en-us/parametric-search/980

[woofy]

Jump straight to 32 bit. Forget 16 bit. 8 bit is worth considering when it has peripherals needed for a project.

My advice, go STM32.
Buy yourself a nucleo board, download the free CubeIde and your away.
https://www.st.com/en/evaluation-tools/stm32-nucleo-boards.html

But really, do some research on different microcontrollers, what ISA interests you? The SX-28 was a PIC look-a-like. If you can get your head around that architecture, you should have no trouble with most controllers.

[newbrain]

I'll add my two cents, and also advice going Arm or maybe RISC-V.

If you go the Arm way, the RP2040 (RPi Pico) is a Cortex-M0+ core, with a very simple instruction set (see the attached picture) and none of the traps for old players more sophisticated Cortex-Ms have, but still quite powerful.
A regular instruction set (quite RISCy), plenty of memory, many general purpose registers, HW multiplication, etc. etc.

For the full core documentation, Arm pages are the best.

You mentioned writing your own ISRs, an advantage of the Arm architecture ISRs are exactly like any other function, no need for special return instructions or prologues and epilogues, the CPU will stack all the registers for you and pop them out automatically.

The ABI to interface with libraries written in C is quite rational and simple.

Don't let the fact it's 32 bits deter you, it just makes things easier.
Instruction are 16 bit wide (Thumb2), possibly followed by a 16 bit operand.

RP2040 peripherals are not that crazy to program, and cover all the basic needs and some advanced ones with PIO - another assembly language in itself!
Documentation is half decent (IMO, worse than STM32, but better than others).

Pico boards are so cheap it's a no-brainer, if you don't like the experience, you are out of only a few dollars.
A (DD)Go(ogle) search brings up many results with info on how to use assembly on an RP2040.

Pico2's RP2350 is a more complex Cortex-M33 core, a large (and a bit sideways) superset of the simple M0+.

My first language was 6502 machine code (pencil and paper then hex on keypad, no assembler!), and I admit I had lots of fun.
Would I do that now with availability of cheap powerful HW, excellent free compilers and IDEs? Well, I might but just for the nostalgia value...

EtA: Oh, and if you come from PIC or 8051, the simple memory model and availability of registers are a breath of fresh air!

[eleguy]

I would add ESP32 to the list. Lots of speed and memory. Depends surely in which amounts one is going to buy MCUs but there is no really difference between "10 cent" and "dollar" thingies in smaller amounts. Shipping costs are anyhow way higher.  Availability, easiness, adoption rate, documentation, ... there are many other things that do weight much more.

[brucehoult]

I'll add my two cents, and also advice going Arm or maybe RISC-V.

If you go the Arm way, the RP2040 (RPi Pico) is a Cortex-M0+ core, with a very simple instruction set (see the attached picture) and none of the traps for old players more sophisticated Cortex-Ms have, but still quite powerful.

Still far more complex than RV32I (or RV32E, the 16 register variant that competes with Cortex-M0), for little or no benefit. There are a lot of different specialised instruction formats each with arbitrary limitation, and use of the upper eight registers (five other than PC, LR, SP) is quite limited: only MOV, ADD, and CMP.

You mentioned writing your own ISRs, an advantage of the Arm architecture ISRs are exactly like any other function, no need for special return instructions or prologues and epilogues, the CPU will stack all the registers for you and pop them out automatically.

Not quite correct. The CPU stacks the registers that the C compiler won't. If you're writing in asm then you still have to remember to push and pop R4-R11 if you use them.

Instruction are 16 bit wide (Thumb2), possibly followed by a 16 bit operand.

Not correct. All instructions are 16 bit except `bl`, fences, and CSR read/write.

Literal operands are not stored in the next 16 bits of code, but are accessed with a PC-relative load, usually from a constant pool just after the end of the function (sometimes after an unconditional branch in a very large function).

My first language was 6502 machine code (pencil and paper then hex on keypad, no assembler!), and I admit I had lots of fun.
Would I do that now with availability of cheap powerful HW, excellent free compilers and IDEs? Well, I might but just for the nostalgia value...

Mine too, but out of necessity. I still do a bit of 6502 for fun, but ABSOLUTELY would not recommend any 1970s 8 bit CPU except the M6809 for beginners. But AVR, Arm, or RISC-V just make so much more sense today.

AVR is annoying for handling values larger than 8 bits, especially including pointers.

All the various Arm instruction sets are annoyingly complex: A32 you have to deal with predication, T16 has too many instruction formats each with weird non-orthogonal limitations, T32 and A64 are too big.

RV32I or RV32E are the simplest and most orthogonal, with no special cases. If your CPU has the C extension the assembler will just transparently use that to reduce code size when it can with no thought on your part, or you can disable the assembler using it to get nice uniform 4-byte instructions.

[Psi]

Seriously consider your reasoning for wanting to program in assembler.

It just makes things complicated for no reason, unless you simply want to learn assembly or need to extract every last clock cycle/flash space from an existing mcu project.  If you do want to use ASM 32bit mcus will require less coding, since you can work with large numbers directly. But be warned, really older cpus were designed for humans to code them in asm, where as modern cpus are designed with compilers in mind so things are not always as simple for a human.

There's no need for a programmer with ZIF socket, you can program modern chips while they're in circuit which is much easier and faster.

If you need a USB connection on the MCU you'll probably want something 32bit, like STM32.  For most 8bit mcu's you use an external usb to serial chip to avoid having to work with USB directly. Also USB requires a clock that's faster than most 8bit mcu's have.


 

[mikeselectricstuff]

ARM is one of the nicest architectures to program in assembler, but unless you're specifically doing it as a learning thing there's little need nowadays, though at least a general undertanding of what a compiler is doing can be very valuable.
 

[brucehoult]

But be warned, really older cpus were designed for humans to code them in asm,

That is true, but in the sense that they are almost impossible to write a good compiler (with efficient code) for, but merely very difficult for humans to program because humans are able to understand what properties something like C has to guarantee that are not actually needed in a particular situation, and also to modify their algorithm to fit the limitations of the CPU.

where as modern cpus are designed with compilers in mind so things are not always as simple for a human.

The first part is true, the second is false. Everything that makes a CPU easy for a compiler also makes it easy for a human.

Historically there were some things that were done that were not especially easy for a compiler, but mechanical bookkeeping could cope with, but that were taxing for a human to keep track of. Those are mostly:

- branch delay slots (in MIPS, SPARC, PA-RISC, i860, M88k, Am29k, SuperH)

- no pipeline interlocks in early MIPS, which meant you had to make sure there were sufficient other instructions between instructions A and B if B used the result of A, otherwise you got the old value of the register not the new one.

That stuff is all long gone.

The only thing that remains is that in CISC you can write complex addressing modes with many operations in one line of code such as multiple adds, scaling one of the operands, and one or sometimes more loads from memory. In RISC you have to instead write several simple instructions in a row using one or more temporary registers. This is not a problem since you usually have a lot of registers.

[newbrain]

Not quite correct.
Not correct.

Yup, you are obviously right on both counts.
I was really sloppy, and linked to the documentation to make up for it, not intending this to be a course in Arm assembly.
I should have cared more, since I knew what you remarked (especially about the Thumb2 IS).

M6809

Eh, I would have loved to get my teenage hands on one*, but I have one now, and sooner or later I'll make a FORTH system out of it - single instruction inner interpreter FTW!

RV32I or RV32E are the simplest and most orthogonal

I have nothing against RISC-V, and I can see its advantages, but for the first foray into 32 bit territory I still think a bit more mainstream is an easier path.
The regularity of the IS is a plus though, I have some RISC-V dev boards, but nothing with the support level of the Pico, are there any that you can suggest?

*Among many other things, not all CPU related...

[JPortici]

Let's say a guy who last worked with microcontrollers (a Ubicom SX-28) about a decade ago, and now wants to start playing with one again. Question is, which one?

I've thought about something like the AT-Tiny or equivalent. But there are so may choices available, it's quite confusing.

Here's what I'd like to have:

• 8- or 16-bit controller (maybe even 32-bit later on)
• Real-time clock/counter
• USB programming (I guess almost everything uses this nowadays?)
• Programmer with ZIF socket
• Basic IDE that runs under Windows: assemble/link/run from PC; maybe a debugger, though not necessary
• Several I/O ports
• Ability to use interrupts and to create my own ISRs
• Moderately fast; speed not crucial, but at least many MHz would be nice
• Decent amount of program & data memory
• Likely to remain available and supported in the forseeable future

I want to program in the μc's native assembly language, not C or C++. The IDE would let me create and use my own libraries (or I could simply create separate object modules), or I could simply put everything in one source file.

The IDE wouldn't even need to have its own editor (though it probably will): I have my own that I use for programming.

So what would y'all suggest? Oh, and $inexpensive$ would be nice.

I would say PIC24FJ512GU410 series: https://ww1.microchip.com/downloads/aemDocuments/documents/MCU16/ProductDocuments/DataSheets/PIC24FJ512GU410-Family-Data-Sheet-DS30010203D.pdf
It's my goto for these requirements
(but doing it all in assembly, nah.)