$0.2 CH32X033 RISC-V, 62K Flash, 20K SRAM with native USB2.0

[SiliconWizard]

LCSC currently has (limited) stock for the CH32X035. JLCPCB has a bit more stock though for both the CH32X035 and CH32X033, if you use JLCPCB.

No clue about TinyUSB on these. I haven't looked at the USB core they implement and how close they are to the FS one in the CH32V2/3. You should probably look at the reference manuals to compare them and see what porting would entail.

[rhodges]

I have been working with the CH32V003 with great results.

I just bought 10 of the CH32V033 to play with and it seems that I should use the ch32v20x.h with it. I really like the idea of extra RAM, Flash, and keeping the C (compressed) option.
Losing the "E" (embedded) gives another 16 RISC-V registers. What luxury! But maybe it will bite me when an interrupt calls a function, and more registers may be needlessly saved.
Having the "M" option for hardware multiply and divide is nice.
Going from 64 byte Flash erase and programming to 256 bytes is a bit of a bummer, but increasing the Flash by (almost) 4 times should compensate for that. And having plenty of RAM to buffer a partial block should also help.

The low price of the CH32V003 made it easy to buy 50 or 100 at a time, compared to buying two or three STM32F407 boards "just for experimenting". Adding ten cents for the CH32V033 is not a problem. I am glad it is another option if the CH32V003 does not have everything I want.

[brucehoult]

I just bought 10 of the CH32V033 to play with and it seems that I should use the ch32v20x.h with it. I really like the idea of extra RAM, Flash, and keeping the C (compressed) option.
Losing the "E" (embedded) gives another 16 RISC-V registers. What luxury! But maybe it will bite me when an interrupt calls a function, and more registers may be needlessly saved.

Seems it has two levels of hardware register stacking (on chip shadow registers), which should take just 1 cycle to save/restore RA and all the A and T registers.

See the INTSYSCR CSR.

[Atlan]

CH32X033 Some example of using the LIN bus.?

[rhodges]

Seems it has two levels of hardware register stacking (on chip shadow registers), which should take just 1 cycle to save/restore RA and all the A and T registers.

Does this mean if I have no more than two interrupt priorities, I can let the hardware shadow those registers? And it appears that the saved registers agree with the RISC-V calling ABI. Or am I mistaken?

For context, I decided at the start to write code that will work with any RISC-V compiler, so on the CH32V003 I did not enable the automatic interrupt register saving. Since it was saving to memory, I was not really sure how much that would save anyway.

So if I enable this feature and add an assembly "mret" at the end of a handler written as an ordinary function, this will work? (I don't mind losing two bytes for the extra "ret".)

[brucehoult]

Seems it has two levels of hardware register stacking (on chip shadow registers), which should take just 1 cycle to save/restore RA and all the A and T registers.

Does this mean if I have no more than two interrupt priorities, I can let the hardware shadow those registers?

Yes, but not simply priorities, but nested interrupts. Priority just decides which of two simultaneous interrupts is serviced first. You can't get nested interrupts unless you explicitly re-enable interrupts inside your interrupt function, which you must not do unless you've read and saved all useful CSRs first! e.g. mepc, mcause, mtval, mstatus.MPP, mstatus.MPIE. Considerable care is needed.

And it appears that the saved registers agree with the RISC-V calling ABI. Or am I mistaken?

Sure. The function itself should as usual, save and restore any S registers it uses.

For context, I decided at the start to write code that will work with any RISC-V compiler, so on the CH32V003 I did not enable the automatic interrupt register saving. Since it was saving to memory, I was not really sure how much that would save anyway.

Previous experimenting showed that on CH32V003 the HPE was faster or at least no slower unless the number of registers you needed to save was truly small -- 3 or less, maybe?

So if I enable this feature and add an assembly "mret" at the end of a handler written as an ordinary function, this will work? (I don't mind losing two bytes for the extra "ret".)

Nooooooooo!!!

Returning behind the compiler's back means that it won't get a chance to restore any S registers it saved, or delete the stack frame.

The "correct" way to do it is to use __attribute __((interrupt("WCH-Interrupt-fast"))) with WCH's own compiler (or this *might* have been upstreamed by now -- the previous time we discussed this here was 18 months ago).

Or to roll it yourself with a generic compiler the correct way is:

Code: [Select]

void my_handler_inner(){
    // ...
}

__attribute__((naked))
void my_handler(){
    asm volatile ("call my_handler_inner");
    asm volatile ("mret");
}

The inner handler must NOT be inlined. Using an asm statement to call it both ensures this and also makes Clang happy as it doesn't allow non-asm code in a naked function.

User jnk0le proposed an extension to the existing __attribute__((interrupt)) feature which would work for the CH32V003, for the bigger WCH cores, and for any future core with a similar feature. He suggested (for CH32V003):

Code: [Select]

__attribute__((interrupt, prestacked("x1,x5-x7,x10-x15")))

This proposal was made in October 2023. I don't know the current status.

[rhodges]

Thank you for clearing that up!

On the CH32V003, I believe that if I enabled the register saving and did nothing else, I would lose some clock cycles for the unneeded saves and restores, but nothing bad would happen. And then if I wanted, I could rewrite the interrupt handlers to take advantage of that. It need not be an "all or nothing" problem.

And on the CH32X03x, this feature would also not create any problems if I did not actually take advantage of it. But since it is hardware shadowing, there would be no cost to enable it. Am I missing anything subtle? I would keep in mind the two level depth, of course.

Thanks!

[rhodges]

I am starting to dig into the PIOC, and I think it could be a game changer.

Get the manuals CHRISC8B-EN.pdf and PIOC-EN.pdf here:
https://github.com/openwch/ch32x035/tree/main/EVT/EXAM/PIOC
You can also browse the PIOC sample code from this folder.
Beware: The UART and 1wire code I read looks like it came from a cut-and-paste maniac.

If there is interest, I would like to take the discussion to a new thread just for PIOC.
The "eMCU" seems to be very much like an early PIC, enough so that my years of PIC programming will probably make this easy to get up to speed.

When active, it takes 4K of the 20K SRAM for its 2K instruction space. Both the host and the eMCU share that memory, so it is possible for the host to write blocks of data for the eMCU to use. I don't see if the eMCU can write to its own program space, though. The eMCU shares the same 48mhz clock as the host. It has an interrupt signal to the host, but not DMA. It has many ways to wait for data or signals.

It has a very small number of PIC-like special function registers, and 32 bytes of shared memory. It has a timer that can be used for PWM.

[SiliconWizard]

I remember Nominal also got interested in the PIOC. Don't know if he did anything with it yet.

I'm not sure about that being a "game changer". While it looks like a small, but complete RISC-like core of its own, it can only address two GPIOs at most, from what I saw. That's very limited. So in practice, as they kind of advertise, it's mostly useful for proprietary 1-wire interfaces, like those security chips, or the ubiquitous "smart" RGB LEDs. Or maybe get one more UART than available on the chip, if you really need that.

The RP2040's PIO may be simpler than this PIOC RISC core, but it can address all GPIOs and all PIO instances run in parallel, so in practice it's way more useful and versatile.

Just saying - it may be useful but it doesn't get me too excited.

[rhodges]

Those are good points. And I am thinking of projects with WS2812B where I have to divide the main clock by 5 to get the SPI to feed the LEDs.

The CH32X033 should be capable of using FreeRTOS if I wanted, but serial devices with special needs might make it awkward. I think the PIOC has something to offer here.

I am also looking at using it to help with an RS485 project, where a smarter UART would be nice.

[brucehoult]

RP2040 costs 5x more (and is a steal at that price).

People using them in small enough quantities to not care about the difference between $0.20 and $1 or even $3.60 [1] for a CV1800B are probably going to be buying them on a board, not a chip, anyway?

[1] in qty 5 at Arace. LCSC have other Sophgo chips, but not CV1800 or SG2000 (yet?)

[SiliconWizard]

To me the real interest for this CH32X series is the CH32X035 (not 33), which (if I'm correct) is the only one supporting USB-PD, which, to me, is the main selling point.
You can design a bunch of cheap, USB-PD powered devices around that and probably not require any additional MCU if the device is not too complex.
USB power supplies, USB lighting, USB soldering irons, you name  it...

So if you are interested in USB-PD, keep that in mind: go for the CH32X035 rather than CH32X033.

[Sacodepatatas]

The "eMCU" seems to be very much like an early PIC, enough so that my years of PIC programming will probably make this easy to get up to speed.

Yes, it is (somebody should update the "PIC architecture" entry at wikipedia). In fact, when I programmed my PDM thing using the PIOC, first what I did is writing some PIC16F84 assembly code and some EQU statements to the register file naming convention, to get a code that could simulate in MPLAB. Once it worked (mainly adjusting cycles for every loop), i did a simple mnemonic replacement such as MOVWF by MOVA, etc, and then using the WCH's assembler tool, include the hex into the main code of the X035, etc... And it worked.

https://github.com/Saco-de-patatas/CH32X0035-PDM

[Nominal Animal]

I programmed my PDM thing using the PIOC

You can push the quantization noise even higher in frequency (and thus easier to filter out) by avoiding the smallest and largest input values.

Given L = 2^N for N-bit PDM, using range (ceil(L/k)) to (ceil(L-1-L/k)) limits the longest consecutive run of the same output state from a constant input state to k-1 cycles.

For example, if you limit your 12-bit input values to 10.4 bits, between 1366 and 2730 inclusive, then you'll never see the same output state for three consecutive cycles in the output.  Limiting to 11 bits, 1024..3071, you'll never see the same output for four consecutive cycles in the output.  And so on.

(When the input varies from cycle to cycle, you can occasionally see k-cycle runs, but they're irrelevant from the frequency analysis perspective.)