Suggestions for microprocessor module

[chilternview]

I guess as you want to write in assembler, you won't be needing floating point math so a simple 8 bit cpu would do the trick.

In which case why not use a PIC? You can use MPELabX for an IDE (or VS Code):

https://www.microchip.com/en-us/tools-resources/develop

Then for programming the PIC, which can be done in circuit, the easiest way is via a PicKit programmer which you can buy new or pick up cheaply on eBay. Or you can make your own programmer, see:

https://www.markhennessy.co.uk/pic/start.htm

[dave j]

At this point I'm leaning towards Bruce Hoult's suggestions, and I'll tell you why:

Regardless of whether they are actually the do-all and end-all of μprocessors out there, he gave me a complete shopping list, including links to online sales. Not a vague "use an Arduino" or "such-and-such a line of processors is easy to use, blah blah blah". Presumably I could buy what he indicated and be in up and running in short order.

Otherwise I'd have to do a lot of investigation online that I'd rather not do. It's actually quite a luxury now that I think about it, having someone do the homework for me, and I do appreciate that.

Again, I could just go online and swim in the vast sea of choices out there. The reason I ask questions here is because folks here have specific knowledge that can be helpful.

I haven't made up my mind yet, but the items Bruce suggested are cheap enough and would no doubt work for me.

I'm still open to suggestions, but it would be nice if they were specific enough so I don't have to do days of research in order to find all the parts-pieces I need.

And yes, I definitely plan on using assembly language, so please don't try talking me out of that, 'k?

If you want to try ARM rather than RISC-V you could use Raspberry Pico (RP2040) or if you want to try both, get the Pico2 version that has the RP2530 which supports architectures.

The Getting Started with Raspberry Pi Pico-series has details of the bits you'll need. It's C oriented but had the same information as the sites @brucehoult linked to for the CH32V stuff.

[brucehoult]

I guess as you want to write in assembler, you won't be needing floating point math so a simple 8 bit cpu would do the trick.

How on earth does that follow?

    bruce@k3:~/programs$ cat fp.s
            .globl main
    main:
            fli.d f0, 3
            fli.d f1, -1
            fli.d f2, 1
            li a0, 0
            li a1, 6
            li a2, 18
            li a3, 12
   
    0:     add a0, a0, a1
            add a1, a1, a2
            add a2, a2, a3
            fmv.d f4, f0
            fcvt.d.l f3, a0
            fdiv.d f3, f2, f3
            fadd.d f0, f0, f3
            fmul.d f2, f2, f1
            feq.d a4, f0, f4
            beqz a4, 0b
   
            la a0, msg
            fmv.x.d a1, f0
            tail printf
   
    msg:    .asciz "%.17g\n"
    bruce@k3:~/programs$ gcc fp.s -o fp
    bruce@k3:~/programs$ ./fp
    3.1415926535897869
    bruce@k3:~/programs$

Any questions?

Of course the CH32V003 or Cortex-M0 or Cortex-M3 don't have floating point hardware, but the CH32V303 and higher, Cortex-M4F, or the Cortex-M33 in the Raspberry Pi RP2350 all have hardware FPUs.

And even if you don't have a hardware FPU you can use a soft float library, as huge numbers of Arduino programs on the 8 bit AVR do.

[brucehoult]

If you want to try ARM rather than RISC-V you could use Raspberry Pico (RP2040) or if you want to try both, get the Pico2 version that has the RP2530 which supports architectures.

I myself suggested RP2040 in my second comment on this post, and RP2350 is even better.

The problem is all the tutorial materials assume you're using VS Code and there is no version of VS Code that supports both Windows 7 and the Raspberry Pi Pico plug-ins.

It is possible to make it using other IDEs such as old versions of Thonny IDE or Arduino IDE but this is not a beginner friendly thing.

If using Windows 11 then sure.

All the CH32Fun things I suggested will work fine on Windows 7, following the standard instructions https://github.com/cnlohr/ch32fun/wiki/Installation

[chilternview]

Any questions?

sin / cos / tan / log ?

There's no denying arm/risc-v etc cores are much more powerful, but I guess it all depends on what the user wants to do with it. If I want to read a temp sensor, send the result via lora to a remote receiver and display it I can do that easily in 8 bit, no need for something more complex. But YMMV.

[SiliconWizard]

A simple, entry-level RISC-V MCU is actually easier to use than most 8-bit MCUs out there, especially the odd ISAs such as the 8-bit PIC.
The peripherals are not particularly complicated either.

Of course you'll need to learn RISC-V assembly, but it's much easier to handle than again most 8-bit MCU ISAs due to it still having relatively few base instructions and being a lot more orthogonal. Sure if you already have previous knowledge of other ISAs, that'll require an extra step for learning, but for someone with no particular previous knowledge of a MCU ISA, RISC-V is a safe bet. It's easier to grasp than ARM IMHO and it'll be directly reusable knowledge as RISC-V is not going to disappear anytime soon.

And, as Bruce said, with CH32Fun, you have a decent starting point for your "baremetal" / even all-assembly journey, while doing this with an ARM-based MCU is not going to be as much of a picnic.

What tends to "intimidate" many people with "recent" MCUs is that they have a much more elaborate internal bus and clocking system than the old CPUs, and so people get easily overwhelmed at first with the required init step to configure all clocks properly, etc. The CH32V00x series Bruce suggested is pretty simple though and reading the docs and using CH32Fun, you should get started without too much difficulty. And again, benefit is that it's going to be knowledge that will be reusable rather than getting cornered into some vintage architecture and environment (which may be fun in its own right, but probably less "useful" these days.)

[Lindley]

What about the Pics from Microchip ? 
Many can be programmed with a USB bootloader like the 40 pin 18F4550  etc  plus their good old free MPLAB v8.92 IDE is still downloadable with its good  Assembler and  runs fine on Win 7.
Plenty of cheap Pickit2/3 programmers from the far east suppliers which will be needed to initially burn the bootloader.
You can build whatever I/Os you need on your own circuit board, ready made dev modules rarely fit every ones needs anyway.

[chilternview]

A simple, entry-level RISC-V MCU is actually easier to use than most 8-bit MCUs out there, especially the odd ISAs such as the 8-bit PIC.

From my point of view the instruction set is of less interest than the development environment (and I don't do assembler, did that 40 years ago, never again). So does the WCH risc-v stuff have a VSCode extension for compile/debug?

[brucehoult]

A simple, entry-level RISC-V MCU is actually easier to use than most 8-bit MCUs out there, especially the odd ISAs such as the 8-bit PIC.

From my point of view the instruction set is of less interest than the development environment (and I don't do assembler, did that 40 years ago, never again). So does the WCH risc-v stuff have a VSCode extension for compile/debug?

Of course, 100%. Has had for almost ten years.

Here are some video tutorials for using VS Code with a RISC-V microcontroller from 2018. Not a WCH one, those didn't exist then, but once you have the USB connection and GDB server running it's exactly the same.

https://www.youtube.com/playlist?list=PL6noQ0vZDAdh_aGvqKvxd0brXImHXMuLY

See part 10 for actually debugging some RISC-V microcontroller code.



But VS Code won't work on OP's Windows 7.

[Doctorandus_P]

If you don't like that you can kindly fuck off.

Getting a bit touchy?

Guess you didn't read the rest of my post.

[Andy Chee]

And importantly:

I want to program this in assembly language. Not C, C++, C#, Python, etc. Just straight native assembly language.

The SX-28 assembly language is most closely related to the 35 instruction set of the baseline PIC.  Be aware that modern devices can have upwards of 75 assembly instructions and more (and even not so modern devices like the AT90S2313).

Your requirements don't exactly rule out using a Z80 or 6502 assembly language, and using a USB E²PROM programmer for your development.

Do you wish to place a further constraint, like instruction set size?

[Analog Kid]

Do you wish to place a further constraint, like instruction set size?

No: probably the more instructions available the better. I can always learn a new instruction set.

One thing I haven't seen mentioned here that I did list as a requirement is the number of I/O ports.
A prospective project might need 16; even more would be better.
That seems to pretty much rule out a lot of 8-bit legacy processors (e.g., the SX-28 wouldn't do anymore).

How many I/O ports do the newer (RISC?) processors typically have?

[brucehoult]

And importantly:

I want to program this in assembly language. Not C, C++, C#, Python, etc. Just straight native assembly language.

The SX-28 assembly language is most closely related to the 35 instruction set of the baseline PIC.  Be aware that modern devices can have upwards of 75 assembly instructions and more (and even not so modern devices like the AT90S2313).

Your requirements don't exactly rule out using a Z80 or 6502 assembly language, and using a USB E²PROM programmer for your development.

Do you wish to place a further constraint, like instruction set size?

Note that the RV32I instruction set has 37 instructions that normal programs use. Barely more than a baseline PIC.

That is LESS than a Z80 or 6502, especially given that you don't have 8 different addressing modes like many of the 6502's "56 instructions". And you don't have to worry about which status flags each instruction sets, because there aren't any.

The only variation within any one of the 37 instructions is which registers to use for source1, source2 (or a constant), destination.

ALU: (arith) ADD, SUB, (bool) AND, OR, XOR, (shift) SLL, SRL, SRA, (compare) SLT, SLTU

Immediate (12 bits):  (arith) ADDI, (bool) ANDI, ORI, XORI, (shift) SLLI, SRLI, SRAI, (compare) SLTI, SLTIU

Cond branch: BEQ, BNE, BLT, BGE, BLTU, BGEU

Uncond branch: JAL, JALR

Memory: LW, LH, LHU, LB, LBU, SW, SH, SB

Hi20 bits: LUI, AUIPC

That's all 37.

The only addressing mode for the Memory instructions is register + 12 bit offset. Everything else is register-to-register.

[brucehoult]

[How many I/O ports do the newer (RISC?) processors typically have?

However many you want.

The CH32V003 in a 20 pin package gives you 18 IO pins.  In the cheaper 8 pin package it gives you 6 IO pins.

The upwardly-compatible CH32V307 has up to 80 IO pins.

CH32Fun provides source code compatible definitions for them, and everything between: 100 series .. 200 series ...

[Andy Chee]

One thing I haven't seen mentioned here that I did list as a requirement is the number of I/O ports.
A prospective project might need 16; even more would be better.
That seems to pretty much rule out a lot of 8-bit legacy processors (e.g., the SX-28 wouldn't do anymore).

How many I/O ports do the newer (RISC?) processors typically have?

Do you mean I/O ports or I/O pins?

For example, the SX-28 had 3 ports; Port A, port B and port C. 

But port A had 5 pins, port B & C had 8 pins each.

[Analog Kid]

Pins. (As in bits.)

[Andy Chee]

Note that the RV32I instruction set has 37 instructions that normal programs use. Barely more than a baseline PIC.

That is LESS than a Z80 or 6502, especially given that you don't have 8 different addressing modes like many of the 6502's "56 instructions". And you don't have to worry about which status flags each instruction sets, because there aren't any.

I wasn't seriously suggesting the Z80 or 6502.  I only mentioned them in order to constrain requirements.

Evidently, the OP is not adverse to learning larger assembly instruction sets.

No: probably the more instructions available the better. I can always learn a new instruction set.

[Andy Chee]

Pins. (As in bits.)

There are heaps of new and legacy devices with 16 I/O pins.  It certainly will not narrow your choices!

Do you require a native DIP package? That would definitely narrow your choices!

A DIP package shouldn't be a game breaker though, because most surface mount devices can usually be accommodated on a DIP carrier PCB or similar.

[brucehoult]

Evidently, the OP is not adverse to learning larger assembly instruction sets.

No: probably the more instructions available the better. I can always learn a new instruction set.

The thing is you never NEED more unless some specialised operation is starting to seriously affect overall program speed.

Multiply and CLZ are probably the biggest gains if you need to do them a lot. With those you can do 1 MFLOP soft float on a 48MHz CPU. Maybe several, actually. 16 MHz AVR does about 200 KFLOP with Arduino soft float. POPCOUNT is probably next. But, heck, Intel only added POPCNT in Nehalem (2008) and LZCNT in Haswell (2013).

Arm Cortex-M3 and higher have a CLZ, but no POPCOUNT.

It's hard to see what else you'd need. Things such as setting or clearing a bit in memory (or a peripheral register) happen a lot but it really doesn't matter whether it takes one instruction or five, especially if the one instruction is multi-cycle. Some Arm cores have support for setting and clearing bits by "bit-banding" but that's a memory aliasing feature not extra instructions.

[brucehoult]

Do you require a native DIP package? That would definitely narrow your choices!

A DIP package shouldn't be a game breaker though, because most surface mount devices can usually be accommodated on a DIP carrier PCB or similar.

The very first reply on this post had a link to a $1.50 DIP-format board with CH32V003

https://www.aliexpress.com/item/1005005221751705.html

For your viewing pleasure, here is one of mine plugged into a breadboard.

[Andy Chee]

Evidently, the OP is not adverse to learning larger assembly instruction sets.

No: probably the more instructions available the better. I can always learn a new instruction set.

The thing is you never NEED more unless some specialised operation is starting to seriously affect overall program speed.

If some specialised operation was still creating a bottleneck in my optimised assembly program, I might rethink the solution.  For example, would an FPGA be better than a microcontroller?

Of course, the OP's request is too generic at this stage to make any such recommendation.

What would help is if the OP could outline some potential applications they plan on doing.  For example, in another thread, the OP has proposed a 16 neon bulb, random noise generator, that they want to make into a 16-bit random number generator to feed into a PC.

[brucehoult]

Evidently, the OP is not adverse to learning larger assembly instruction sets.

No: probably the more instructions available the better. I can always learn a new instruction set.

The thing is you never NEED more unless some specialised operation is starting to seriously affect overall program speed.

If some specialised operation was still creating a bottleneck in my optimised assembly program, I might rethink the solution.  For example, would an FPGA be better than a microcontroller?

Sure quite possibly, but that's a whole other ball of wax, different environment and language to learn.

A LOT more expensive too.

Sipeed's Tang Nano 9K is the cheapest "name brand" [1] FPGA dev board I know of, and it's around $20.

By the time you get to that kind of price you can be looking at a 1.5 GHz quad core Linux SBC with 1 or 2 GB RAM and WIFI/BT e.g. Raspberry Pi Zero 2W.

[1] I have a lot of Sipeed products, talk to the R&D director Caesar Wu online from time to time.

[SiliconWizard]

A simple, entry-level RISC-V MCU is actually easier to use than most 8-bit MCUs out there, especially the odd ISAs such as the 8-bit PIC.

From my point of view the instruction set is of less interest than the development environment (and I don't do assembler, did that 40 years ago, never again).

If the thread gets derailed, sure. If using a higher level language, the ISA doesn't matter a lot. But the OP specifically said they wanted to use assembly language.

[cfbsoftware]

At this point I'm leaning towards Bruce Hoult's suggestions
...
...
And yes, I definitely plan on using assembly language, so please don't try talking me out of that, 'k?

I'd second that - particularly the RP2040 combined with the book RP2040 Assembly Language Programming: ARM Cortex-M0+ on the Raspberry Pi Pico by Stephen Smith:

https://www.amazon.com.au/dp/148427752X?ref_=mr_referred_us_au_au

[Analog Kid]

Do you require a native DIP package? That would definitely narrow your choices!

No, I don't want a chip at all; I want a chip mounted on a dev board ready to rock.