5 ms·

Will LCSC sell me a single $6.76 board? https://lcsc.com/product-detail/Microcontroller-Units-MCUs-MPUs-SOCs_WCH-Jiangsu-Qin-Heng-CH32V003F4P6-EVT-R0_C5187532.

Will LCSC sell me a single $6.76 board? https://lcsc.com/product-detail/Microcontroller-Units-MCUs-MPUs-SOCs_WCH-Jiangsu-Qin-Heng-CH32V003F4P6-EVT-R0_C5187532.html https://lcsc.com/product-detail/Microcontroller-Units-MCUs-M... Amazing the CPU is priced at $0.10 and clocked 2-3x higher than the Macintosh computers I grew up using. The available memory on these is a lot less than those old macs, though. They tended to have 4-32MB of RAM and 40-120MB discs. Anyone know if this thing can run a simple Python app? e.g. https://wiki.python.org/moin/EmbeddedPython https://wiki.python.org/moin/EmbeddedPython My guess is there probably isn't sufficient memory. Curious what the development workflow consists of for these boards. The lack of a network or display output port seems a tad limiting.

exar0815 4y ago
Not knowing for this particular device, but generally for MCUs? Install a manufacturer-specific toolchain, often based on some minimally changed Eclipse IDE and gcc, Write your software in as old a C dialect you can, sprinkle some generous helping of assembly in. To know which registers to use, dig through thousands of pages of documentation, some more, some less helpful. Most functions are just accessible by flipping bits in specific registers. Afterwards, build the software and flash it with a dongle on it, then run the code. For debugging, you mostly have SWD or JTAG which allows you to poke and change at all registers and any memory, and stop the code when and wherever you want. Which is desperately needed, as most MCUs are riddled with weird edge cases and undocumented behavior. Source: Development on ATmega, STM/SPC
- tormeh 4y ago
  Can confirm. Embedded development (this sort of development) kinda sucks, IMO. It has a certain sort of simple old-school charm, but it's mostly pain, although opinions probably differ.
  - mindslight 4y ago
    Maybe I've just got rosy memories, but small microcontroller development felt a lot nicer than large microcontroller development. For PIC development, you could (and would) be in touch with the entire code base, precisely allocate how your interrupt(s) were used, know exactly how the hardware was configured at the bit register level, etc. Whether to use a multitasking system was a choice depending on the project, as was using a C compiler. If you did use a C compiler, you generally knew how your code was going to translate to assembler. Especially when you were writing routines where the cycle count mattered (interrupt routines, bit banging, processing throughput, etc) The first thing I saw looking at STM32 land is a whole heap of suggested manufacturer libraries that do who-knows-what behind the scenes. The timing properties feel more like using a general purpose OS rather than always having deterministic control over what the CPU was doing. The peripherals are still documented at the register level, but the scope is much larger and it seems you'd be likely to run into undiscovered errata if you attempted to use them in a different way from the manufacturer libraries. Maybe I never got familiar enough with STM32 to appreciate and really understand it. That project was several years back and I got interrupted and have yet to return. I especially look forward to seeing what the Rust community has enabled on ARM microcontrollers in the mean time - I feel like there's a lot more hope for sanity on a ground-up implementation, rather than leaning on whatever the manufacturer dumps. And obviously modern languages are sorely needed, rather than C being considered the "high level" option. But if I were going to start a hardware project today that needed to be reliable, I'd likely still base the core around an 8-bit micro (probably AVR to go with the flow), with an ESP32 as an afterthought for wifi connnectivity.
unwind 4y ago
No, it cannot run Python. Even MicroPython [1] requires 16 KB of RAM, and probably at least 8 times more flash (code space) than this chip has. This is an embedded microcontroller, not a general-purpose computer. You program it in C, and poke registers to make things happen. Edit: forgot link. [1]: https://micropython.org/ https://micropython.org/
- SV_BubbleTime 4y ago
  Last I looked, it was a 256KB rom requirement, and worth noting that the 16KB ram is just the interpreter. Your code adds on top of that. IMO microPython is a waste of time.
  - benj111 4y ago
    Why is it a waste of time? If you want your pi Pico flashing some lights it seems suitable. Fair enough if youre shipping 100k units and want to minimise the bom then fine, but that isn't most hobbyists.
- pencilguin 4y ago
  You could better program it in C++. Or even Rust.
deleted 4y ago
[deleted]
UltraViolence 4y ago
RAM is incomparable to desktop computers since it's used for both programs and data (i.e. variables used in the program) in the latter. On a microcontroller RAM is only used to hold program variables. The program itself is stored in Flash memory.
- SV_BubbleTime 4y ago
  > On a microcontroller RAM is only used to hold program variables. The program itself is stored in Flash memory. That needs a huge asterix. You are using a big generalization with a lot of examples to the contrary. Look up why the Infineon XMC1x00 ARM processors has so much ram. Probably the 4x00 too.
goodpoint 4y ago
It cannot run MicroPython but you can use Nim.

exar0815 4y ago

Not knowing for this particular device, but generally for MCUs? Install a manufacturer-specific toolchain, often based on some minimally changed Eclipse IDE and gcc, Write your software in as old a C dialect you can, sprinkle some generous helping of assembly in. To know which registers to use, dig through thousands of pages of documentation, some more, some less helpful. Most functions are just accessible by flipping bits in specific registers. Afterwards, build the software and flash it with a dongle on it, then run the code. For debugging, you mostly have SWD or JTAG which allows you to poke and change at all registers and any memory, and stop the code when and wherever you want. Which is desperately needed, as most MCUs are riddled with weird edge cases and undocumented behavior. Source: Development on ATmega, STM/SPC

tormeh 4y ago
Can confirm. Embedded development (this sort of development) kinda sucks, IMO. It has a certain sort of simple old-school charm, but it's mostly pain, although opinions probably differ.
- mindslight 4y ago
  Maybe I've just got rosy memories, but small microcontroller development felt a lot nicer than large microcontroller development. For PIC development, you could (and would) be in touch with the entire code base, precisely allocate how your interrupt(s) were used, know exactly how the hardware was configured at the bit register level, etc. Whether to use a multitasking system was a choice depending on the project, as was using a C compiler. If you did use a C compiler, you generally knew how your code was going to translate to assembler. Especially when you were writing routines where the cycle count mattered (interrupt routines, bit banging, processing throughput, etc) The first thing I saw looking at STM32 land is a whole heap of suggested manufacturer libraries that do who-knows-what behind the scenes. The timing properties feel more like using a general purpose OS rather than always having deterministic control over what the CPU was doing. The peripherals are still documented at the register level, but the scope is much larger and it seems you'd be likely to run into undiscovered errata if you attempted to use them in a different way from the manufacturer libraries. Maybe I never got familiar enough with STM32 to appreciate and really understand it. That project was several years back and I got interrupted and have yet to return. I especially look forward to seeing what the Rust community has enabled on ARM microcontrollers in the mean time - I feel like there's a lot more hope for sanity on a ground-up implementation, rather than leaning on whatever the manufacturer dumps. And obviously modern languages are sorely needed, rather than C being considered the "high level" option. But if I were going to start a hardware project today that needed to be reliable, I'd likely still base the core around an 8-bit micro (probably AVR to go with the flow), with an ESP32 as an afterthought for wifi connnectivity.

unwind 4y ago

No, it cannot run Python. Even MicroPython [1] requires 16 KB of RAM, and probably at least 8 times more flash (code space) than this chip has. This is an embedded microcontroller, not a general-purpose computer. You program it in C, and poke registers to make things happen. Edit: forgot link. [1]: https://micropython.org/ https://micropython.org/

SV_BubbleTime 4y ago
Last I looked, it was a 256KB rom requirement, and worth noting that the 16KB ram is just the interpreter. Your code adds on top of that. IMO microPython is a waste of time.
- benj111 4y ago
  Why is it a waste of time? If you want your pi Pico flashing some lights it seems suitable. Fair enough if youre shipping 100k units and want to minimise the bom then fine, but that isn't most hobbyists.
pencilguin 4y ago
You could better program it in C++. Or even Rust.

deleted 4y ago

[deleted]

UltraViolence 4y ago

RAM is incomparable to desktop computers since it's used for both programs and data (i.e. variables used in the program) in the latter. On a microcontroller RAM is only used to hold program variables. The program itself is stored in Flash memory.

SV_BubbleTime 4y ago
> On a microcontroller RAM is only used to hold program variables. The program itself is stored in Flash memory. That needs a huge asterix. You are using a big generalization with a lot of examples to the contrary. Look up why the Infineon XMC1x00 ARM processors has so much ram. Probably the 4x00 too.

goodpoint 4y ago

It cannot run MicroPython but you can use Nim.