$0.2 CH32X033 RISC-V, 62K Flash, 20K SRAM with native USB2.0 - Page 1
Forum section: electronics / general

author: IOsetting
author_rank: Regular Contributor
timestamp: January 23, 2024, 02:41:14 am
content: I happened to know this CH32 RISC-V microcontroller while browsing Stefan's Hackaday pagehttps://hackaday.io/project/194408-ch32x033-f8p6-development-board.QuoteI checked the price on Taobao, it's around 1.4 CNY (0.2 USD), in fact, it's even cheaper than a CH340N, which costs around 1.5 CNY.This makes it particularly appealing, as you don't need any additional USB2TTL chips when working on small USB applications.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 23, 2024, 03:36:28 am
content: Interesting. The official product page:https://www.wch-ic.com/products/CH32X035.htmlNote that the series is under the CH32X035 name, but it also includes the CH32X033, which is the lowest end of the range (and cheapest), without USB-PD.Otherwise, all CH32X035 support USB-PD as well, so all in all, can be a pretty good option for a whole range of applications at a very low price.They can be found on Aliexpress (using Taobao directly is uncommon in the west I think), not from the "regular" distributors like LCSC at this point.

author: HwAoRrDk
author_rank: Super Contributor
timestamp: January 23, 2024, 03:50:21 am
content: The Programmable Protocol I/O Microcontroller, or PIOC, seems to be quite interesting. Seems like they're gunning for something along the lines of the RP2040's PIO.There's very little information about it in the English Reference Manual:QuoteThat's literally all there is. Surprising that they seem to have embedded a whole other microcontroller replete with timer counter, etc.However, if one goes snooping around theWCH GitHub, they have manuals in Chinese for both thePIOC controller's registersand thePIOC controller's instruction set(dubbed 'WCH-RISC8B'). There's also an assembler ('WASM53B') and a utility to convert assembled binaries into a C include file as hex data. Hopefully we will see English versions of this documentation with time.

author: bingo600
author_rank: Super Contributor
timestamp: January 24, 2024, 03:38:04 pm
content: I just tried to build the usb2serialhttps://github.com/wagiminator/Development-Boards/tree/main/CH32X033F8P6_DevBoard/software/usb2serialUsing xpack-riscv-none-elf-gcc-13.2.0-2It barfed at me ..Code:$ make allBuilding usb2serial.elf ...include/system.c: Assembler messages:include/system.c:330: Error: unrecognized opcode `csrw 0xbc0,a0', extension `zicsr' requiredinclude/system.c:332: Error: unrecognized opcode `csrs mstatus,a0', extension `zicsr' requiredinclude/system.c:334: Error: unrecognized opcode `csrw 0x804,a1', extension `zicsr' requiredinclude/system.c:337: Error: unrecognized opcode `csrw mtvec,a0', extension `zicsr' requiredinclude/system.c:338: Error: unrecognized opcode `csrw mepc,a5', extension `zicsr' requiredlto-wrapper: fatal error: riscv-none-elf-gcc returned 1 exit statuscompilation terminated.A bit of googling revealed that the architure options has changed on newer riscv toolchains.Code:## https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1280#CPUARCH = -march=rv32imac -mabi=ilp32CPUARCH = -march=rv32imac_zicsr -mabi=ilp32And some more PIOC stuffCode:https://github.com/openwch/ch32x035/blob/main/App/01_Snake/code/ch32x035_pioc_ws2812/sdk/Peripheral/inc/PIOC_SFR.hhttps://github.com/openwch/ch32x035/blob/main/App/01_Snake/code/ch32x035_pioc_ws2812/src/ws2812/RGB1W.chttps://github.com/openwch/ch32x035/blob/main/App/01_Snake/code/ch32x035_pioc_ws2812/src/ws2812/RGB1W.hhttps://github.com/openwch/ch32x035/blob/main/App/01_Snake/code/ch32x035_pioc_ws2812/src/ws2812/RGB1W_inc.h/Bingo

author: HwAoRrDk
author_rank: Super Contributor
timestamp: January 24, 2024, 04:39:40 pm
content: Quote from: bingo600 on January 24, 2024, 03:38:04 pmThat change happened in GCC 12.x I believe. Only about 2 years ago...Although, that might as well be yesterday in terms of propagation of changes in GCC.It's actually mentioned in the xPack release notes:https://xpack.github.io/blog/2022/05/15/riscv-none-elf-gcc-v12-1-0-1-released/#risc-v-isa-updates

author: brucehoult
author_rank: Super Contributor
timestamp: January 24, 2024, 05:42:33 pm
content: Quote from: HwAoRrDk on January 24, 2024, 04:39:40 pmThey changed the default ISA spec, but you can just tell recent gcc to use the older one, if you want.-misa-spec={2.2, 20190608, 20191213}2.2 (May 2015, pre-ratification) includes zicsr in rv32i. No post-ratification (June 2019) spec does.gcc has supported all three specs for quite a few versions now, it's just the default one that changed.The xpack author clearly doesn't fully understand the issue. While their fix will work it's not the most elegant.

author: spostma
author_rank: Regular Contributor
timestamp: January 24, 2024, 05:53:53 pm
content: Very interesting low pincount chip with USB Host/Device, USB PD, 12-bit ADC, DMA, 4x UART!There is some more information and examples on the PIOC inside the CH32X035EVT Zipfile, see this translated page:https://bbs-elecfans-com.translate.goog/jishu_2402601_1_1.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-US&_x_tr_pto=wapphttps://bbs-elecfans-com.translate.goog/jishu_2377106_1_1.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-US&_x_tr_pto=wapphttps://www.wch.cn/downloads/CH32X035EVT_ZIP.html

author: Sacodepatatas
author_rank: Regular Contributor
timestamp: January 24, 2024, 10:31:37 pm
content: Last October I asked Patrick Yang in a private message on the social network that was formerly known as Twitter regarding the PIOC and here is his answer:

author: Sacodepatatas
author_rank: Regular Contributor
timestamp: January 24, 2024, 10:46:19 pm
content: Quote from: HwAoRrDk on January 23, 2024, 03:50:21 amI've taken a look at the instruction set, and... Doesn't look like the PIC12/PIC16 instruction set but with different names for the same instruction and registers?? For example, the W register in a PIC would be the A register in the PIOC...

author: HwAoRrDk
author_rank: Super Contributor
timestamp: January 25, 2024, 07:56:53 am
content: I wonder if the PIOC CPU core is the same as (or a variant of) that used in the older CH53x microcontrollers? Given the filename of the assembler is "WASM53B"...

author: c64
author_rank: Frequent Contributor
timestamp: January 27, 2024, 05:54:21 am
content: Quote from: IOsetting on January 23, 2024, 02:41:14 amIs it the only option to buy them in China? From random taobao seller?I checked out the official taobao store and they only have development boards and programming cables

author: westfw
author_rank: Super Contributor
timestamp: January 27, 2024, 06:43:44 am
content: QuoteIt looks like the "Official WCH store" on Aliexpress has the ch32x035 variety (actually, several different packages.)20 chips for about $9, though.https://www.aliexpress.us/item/3256805471117452.html

author: c64
author_rank: Frequent Contributor
timestamp: January 27, 2024, 07:19:55 am
content: I don't think chinese buy on Aliexpress

author: martinribelotta
author_rank: Regular Contributor
timestamp: January 27, 2024, 01:12:29 pm
content: QuoteMainly, chinese speaker/reader use taoboa:https://world.taobao.com/That is owned by Alibaba (same owner of aliexpress)

author: c64
author_rank: Frequent Contributor
timestamp: January 27, 2024, 10:07:37 pm
content: I already found their official shop. No chipshttps://shop137880236.taobao.com/

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 27, 2024, 11:16:36 pm
content: Quote from: westfw on January 27, 2024, 06:43:44 amYes, as I mentioned in my first post, it's available on Aliexpress for us westerners.As I also mentioned, this series of ICs is the CH32X035, with the CH32X033 being the lowest end of the series with no support for USB-PD. So it's not surprising that the CH32X305, with USB-PD support, is a bit more expensive.$0.45/piece for low quantitites is still a pretty good price for the specs. The CH32X033 is also available on Aliexpress, for about $0.3/piece in low quantities.

author: bingo600
author_rank: Super Contributor
timestamp: March 06, 2024, 02:40:11 pm
content: I just got 20 of these, from ali ....Anyone else playing with them yet ?/Bingo

author: Atlan
author_rank: Frequent Contributor
timestamp: March 09, 2024, 09:44:22 pm
content: I installed their IDE, after the update it went wrong, so I uninstalled and installed again, I refused the update. So I could finally start doing something, after a few code edits, it went wrong. The program translated, uploaded and did not work. I created a new project and copied the files. It started working. I don't have big plans yet. And I'm on the lowest line, 003. Affordable, and especially pin and voltage compatible, so I didn't have much choice.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 09, 2024, 10:40:49 pm
content: Quote from: Atlan on March 09, 2024, 09:44:22 pmNote that what I suppose is the CH32V003, if that's indeed what you have here, has nothing (well, probably not nothing of course, but it's not the same series and is still different) to do with the CH32X033/34/35 series which is the topic of this thread. The CH32V003 has been talked about in other threads though.I have no experience with what I suppose is the Mounriver IDE, as I've used makefiles and gcc directly for WCH MCUs, so I don't know how robust it is or whether there are quirks on some OSs, which I wouldn't be completely surprised about though.

author: IOsetting
author_rank: Regular Contributor
timestamp: March 11, 2024, 09:35:28 am
content: Stefan has post some interesting projects of CH32X033https://hackaday.io/project/195160-ch32x033-usb-knobhttps://hackaday.io/project/195159-ch32x033-usb-to-nrfI have soldered a little EVB weeks ago and run a couple of examples from WCHhttps://www.wch.cn/downloads/CH32X035EVT_ZIP.html,to verify the USB functionality, but I haven't got time to play further.Quote from: bingo600 on March 06, 2024, 02:40:11 pm

author: bingo600
author_rank: Super Contributor
timestamp: March 11, 2024, 02:32:52 pm
content: Quote from: IOsetting on March 11, 2024, 09:35:28 amI'll be trying this one asap (have to solder mcu to an adapter etc ...) , but have something else to do in the weekend.https://github.com/wagiminator/Development-Boards/tree/main/CH32X033F8P6_DevBoard/software/usb2serial/Bingo

author: tom66
author_rank: Super Contributor
timestamp: March 11, 2024, 03:36:10 pm
content: I find the use of USB2.0 curious. What is there that you can do at >12Mbps with a 48MHz clock... I guess as long as you can process each byte in 32 instruction cycles, but I can't think of many use cases. Perhaps it's just so cheap nowadays to put a USB2.0 transceiver on something that it doesn't make any difference.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 11, 2024, 09:08:04 pm
content: You are conflating USB 2.0 and USB HS. These MCUs do comply with USB 2.0 but only in FS, obviously. USB 2.0 includes HS, but is also backwards compatible and introduced a few things that were not related to the communication speed either. USB 2.0 doesn't mean USB HS.

author: Nominal Animal
author_rank: Super Contributor
timestamp: March 11, 2024, 10:37:28 pm
content: Quote from: tom66 on March 11, 2024, 03:36:10 pmLots, from HID devices like keyboards, mice, joysticks, to USB serial adapters and bridges to other buses, to debugging and development tools; and no, that's not how it works.First, the USB full-speed (12 Mbit/s including overhead) device peripheral handles entire packets between zero and 64 bytes long. It is not like an UART where you receive one byte at a time. Furthermore, it handles the "header" part of each packet, directing the packet to a specificendpoint(numbered, described in the USB device descriptor), so that you really only need to handle the data part of each packet only.It is much closer to network datagram programming than working with a data stream byte at a time, really. It also means there is no inter-byte timing issues; you only need to handle each full packet.What to use these devices for?Lots.Any kind of standard driverless human interface device (HID), like keyboard, mice, joystick, gamepads, touchpads et cetera. The data protocol is simple and easy (except Microsoft as usual requiring odd quirks and special dispensation, because its built-in drivers are odd and not very intelligent), and is thoroughly documented (except for the Microsoft silliness, which you need to consult Microsoft for). My very first microcontroller project was actually an arcade game controller on a 50cm×20cm / 20"×8" birch board using a Teensy 2.0++ AVR microcontroller (AT90USB1280) appearing as a keyboard (with several different sets of keys the joystick and buttons generated) that I used to play online Flash puzzle platformer games.If you've ever been annoyed at your preferred applications for not having better shortcuts, perhaps want better 3D rotation in CAD/CAM, or better 2D scrolling/panning, you could have solved that with a microcontroller with native USB for USB HID, and a suitable set of buttons, potentiometers, encoders, or even magnetic field sensors. And a 3D printer to make a nice enclosure for it. One of my forever projects is an e-Ink display with a capacitive touch panel, for a programmable physical toolbar (generating application-specific shortcut keypresses), for example.Any kind of data bridge between a computer and external device, from UART/Serial, I2C, SPI to GPIO. Unlike the FTDI devices, these can be programmed with additional logic, for example to do any timing-sensitive stuff, or provide an unified interface across similar but incompatible devices. For example, consider small display controllers, for example OLED display controllers, that provide an unified interface over USB Serial (i.e., appear as if serial ports) using a standardized format –– compare to AT command set for modems –– to query the display properties (flashed to the microcontroller) and to control the display contents. If HID devices are my favourite use case, this has to be the second-favourite one. It is an extremely easy way to add a display to Linux SBCs and appliances, as this way I don't need to hope for an exposed UART not already used for a terminal console, and can use an USB HUB to trivially add more than one device and not lose connectivity.Debugging and driver development for USB-connected devices. I do prefer to use Teensies with lots of RAM and Flash for this, because that way it is trivial to "replay" even long "USB conversations" with predefined response delays, recorded using Wireshark etc. when a device is talking to its Windows closed-source and buggy drivers, to write my own. I've done this for Silhouette Cameo vinyl cutters, without having any kind of access to one, but a friend in Canada – across the pond – having one, and doing experiments I request, recording the communication between the Windows driver/application and device, sending the log to me, and me examining and writing a Linux userspace driver.Quick purpose-designed tools to solve a problem without having to buy expensive test equipment. For example, to explore exposed pins on appliances like routers and TV boxes, one can use an expensive oscilloscope and logic analyzer setup with all sorts of decoders to probe if useful stuff like console UART is exposed; or you can use a few dollar native-USB microcontroller (possibly using a cheap $8 ADuM3160 USB isolator from eBay for isolating the microcontroller from the computer it is connected to, allowing grounding it to the appliance ground) and write a throwaway firmware to start with an ADC probe. When you find a pin with interesting flicker patterns, use a voltage level translator (I recommend TI TXU0n0m for all but I2C, and dedicated ones like PCA9306 for I2C), and connect the pins to the microcontroller peripheral.WhatIdo not understand, is why anyone would use a microcontrollerwithouta native USB peripheral, and instead work with problematic USB-to-serial bridges and whatnot. The popularity of ATmega328/ATmega328p in particular baffles me, as there are several AVRs only a little more expensive but much more useful with native USB support. (ATmega32u4 is my favourite, but I do like both ATmega8/16/32u series and AT90USB series.)For those preferring PICs over AVRs, the USB ones exist too, starting at PIC16F1454 (under 1.5€ in singles at Mouser).For those preferring 8051 (MCS-51) cores, there are CH55x programmable with open source tools.For those preferring ARM Cortex M cores, just about all manufacturers have these, many with Arduino cores for even quicker development (for debugging and throwaway/single-use tools).My preferred combo is having one (or more, because Windows) HID endpoint, and one or more USB Serial endpoints for bulk data. You can use Force Feedback HID messages or raw HID messages to configure the HID device from an userspace GUI application (easy to do in e.g. Python), although I like to use the USB Serial for this (but viatermiosandtermios.ttyPython interfaces on all non-Windows OSes, and not pyserial or similar). An extremely typical use case is to remap the arcade plank to a different set of keypresses at run time. In Linux/BSDs/macOS/Android this is very easy and needs no drivers at all; it is only Windows that requires special care, but fortunately I don't use Windows and thus don't need to care.

author: John Celo
author_rank: Regular Contributor
timestamp: October 30, 2024, 09:14:02 pm
content: Quote from: westfw on January 27, 2024, 06:43:44 amDon't buy MCUs from ali. I got "engineering sample" lot from this "official store". And if it is indeed an "official store" and wch knowingly dumps engineering samples on their "official store" then they should be blacklisted.They "work", but datasheet says that: the channel 3, channel 7, channel 11 and channel 15 functions of the ADC are not available for products with a lot number with the penultimate 5 digits being 0. I2C also doesn't work at all (spent solid time trying to make it work LOL)Their prices aren't even competitive with LCSC, it's unfortunate LCSC doesn't stock all WCH chips in bigger quantities. Any MCU which isn't widely available in stock on LCSC is dead to me. Store on ali isn't a sourcing option.On a related sidenote - how hard would it be to get tinyusb working on ch32x033/ch32x035?Tinyusb supports the ch32v203, but not the x033/x035 series.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 30, 2024, 09:24:09 pm
content: 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.

author: rhodges
author_rank: Frequent Contributor
timestamp: October 31, 2024, 12:41:52 am
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: October 31, 2024, 01:06:12 am
content: Quote from: rhodges on October 31, 2024, 12:41:52 amSeems 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.

author: Atlan
author_rank: Frequent Contributor
timestamp: October 31, 2024, 05:22:39 pm
content: CH32X033 Some example of using the LIN bus.?

author: rhodges
author_rank: Frequent Contributor
timestamp: November 01, 2024, 11:51:15 pm
content: Quote from: brucehoult on October 31, 2024, 01:06:12 amDoes 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".)

author: brucehoult
author_rank: Super Contributor
timestamp: November 02, 2024, 12:54:10 am
content: Quote from: rhodges on November 01, 2024, 11:51:15 pmYes, 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.QuoteSure. The function itself should as usual, save and restore any S registers it uses.QuotePrevious 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?QuoteNooooooooo!!!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: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:__attribute__((interrupt, prestacked("x1,x5-x7,x10-x15")))This proposal was made in October 2023. I don't know the current status.

author: rhodges
author_rank: Frequent Contributor
timestamp: November 02, 2024, 02:22:50 pm
content: 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!

author: rhodges
author_rank: Frequent Contributor
timestamp: November 13, 2024, 09:54:50 pm
content: 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/PIOCYou 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 13, 2024, 10:13:30 pm
content: 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.

author: rhodges
author_rank: Frequent Contributor
timestamp: November 13, 2024, 10:29:39 pm
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: November 13, 2024, 10:47:03 pm
content: 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  for a CV1800B are probably going to be buying them on a board, not a chip, anyway? in qty 5 at Arace. LCSC have other Sophgo chips, but not CV1800 or SG2000 (yet?)

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 13, 2024, 11:06:56 pm
content: 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.

author: Sacodepatatas
author_rank: Regular Contributor
timestamp: November 30, 2024, 07:51:13 pm
content: Quote from: rhodges on November 13, 2024, 09:54:50 pmYes, 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

author: Nominal Animal
author_rank: Super Contributor
timestamp: November 30, 2024, 08:37:02 pm
content: Quote from: Sacodepatatas on November 30, 2024, 07:51:13 pmYou can push the quantization noise even higher in frequency (and thus easier to filter out) by avoiding the smallest and largest input values.GivenL= 2NforN-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 tok-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 seek-cycle runs, but they're irrelevant from the frequency analysis perspective.)