Sipeed MaixCAM is an AI camera based on SOPHGO SG2002 RISC-V (and Arm, and 8051) SoC with a 1 TOPS NPU that takes up to 5MP camera modules and comes with a 2.3-inch color touchscreen display.
The development kit also comes with WiFi 6 and BLE 5.4 connectivity, optional Ethernet, audio input and output ports, a USB Type-C port, and two 14-pin GPIO headers for expansion that makes it suitable for a range of computer vision, Smart audio, and AIoT applications.
Sipeed MaixCAM specifications:
- SoC – SOPHGO SG2002
- CPU
- 1 GHz RISC-V C906 processor or Arm Cortex-A53 core (selectable at boot) running Linux
- 700 MHz RISC-V C906 core running an RTOS
- 25 to 300 MHz low-power 8051 processor
- NPU – 1 TOPS @ INT8 with support for models such as Mobilenetv2, YOLOv5, YOLOv8, etc…
- Video Codec – H.264, H.265, MJPEG hardware encoding and decoding up to 2K @ 30fps
- Memory – 256MB DDR3
- CPU
- Storage
- MicroSD card slot (bootable)
- SD NAND flash (bootable)
- Display – 2.3-inch IPS capacitive touchscreen display with 552×368 resolution; connected through a 31-pin, 2-lane MIPI DSI connector and a 6-pin capacitive touch connector
- Camera I/F – 4-lane MIPI CSI input via 22-pin connector for up to 5MP cameras. Supports 4MP GC4653 and OS04A10 cameras out of the box
- Audio Output – On-board power amplifier for 1W speakers via headers
- Audio Input – Onboard analog silicon microphone
- Networking
- WiFi 6 and BLE 5.4 module
- Customizable Ethernet version
- USB – USB 2.0 Type-C port
- Expansion – 2x 14-pin 2.54mm pitch GPIO headers with I2C, SPI, UART, ADC, PWM, WDT
- Misc –
- RST button, USER button
- Power indicator, user LED
- Power Supply
- Mechanical – 3D printed enclosure, two threaded holes
The MaixCAM builds on the company’s board based in LicheeRV-Nano board powered by the SG2002 SoC and all software for the board can run on the camera including the Debian and Qt-based Linux images. Willy – a regular CNX Software reader and commenter – tried one of those two months ago, but was rather unimpressed with usability (e.g. no SSH) and the delta compared to the latest Linux 5.10, and ended up rebasing the code to Linux 5.10.251. There’s a very large number of changes (about 25,000), and the git pull request has yet to be processed by SOPHGO.
There’s also software specific to the Sipeed MaixCAM which we are told won’t work on the LicheeRV-Nano or other SG2002 boards which are better suited for Linux development:
- MaixPy – Python development package with an API optimized for MaixCAM that supports hardware acceleration
- MaixVision – AI Vision IDE for programming, running code, real-time image preview, and even block-based programming
- MaixCDK – C++ version of MaixPy
You’ll find all three along with other technical details in the wiki. To make things even easier, Sipeed provides the MaixHub with a list of pre-trained AI models that can be directly uploaded to the MaixCAM hardware. Example apps include a simple HTTP streamer, face detection, fire detection, and a few others, as the list is not super long right now. You can also access those by tapping on the “App Store” button in the user interface on the 2.3-inch display.
Sipeed has started selling the MaxiCAM RISC-V AI camera on Aliexpress for about $40 for a kit with a 4MP camera and accessories.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
I still don’t get why the SG2002 is a thing. It seems a really odd choice to put two (big) cores and you need to select one with a jumper. It would seem that the other core would then really become a waste of silicon.
I don’t really see any reason why you would want to suddenly have another type of core, not that you can do it by software since it’s decided at bootup time. It’s a very odd choice that kinda ruins the entire chip, in my view.
On the opposite I find the idea particularly smart and audacious from a sales perspective. These devices target vendors of IoT devices running on Arm and who are afraid of the messy RISC-V ecosystem. It’s easy to say “you’re on Arm, no problem, we have this as well, it’s already an upgrade for you since all other components including the RAM are integrated”. This can be sufficient to convince users to switch to that device and to postpone their RISC-V migration later.
Even as an end user I thought “in the worst case I’ll use it in Arm mode”. Finally I only found the riscv image when I first tested it so it was the opportunity for me to update my toolchain to riscv and rebuild my packages, and since it worked, I stayed on it in riscv mode. I still have not tried it in Arm mode yet. I don’t even know if their A53 has crypto extensions. But I anticipate that it should be significantly faster in Arm mode at least for some use cases, given that the instruction set is quite cleaner and more efficient. Just try an unaligned 32-bit read for a network protocol parser, one is just an “ldr”, the other one is something like 12 or 18 instructions, I don’t remember, but it’s absolutely ugly.
But end users of such devices don’t care at all about performance, what matters is 1) price, 2) space, 3) power usage. A future version of this chip will very likely drop the A53 and cut its price by probably $0.5 or so, without anyone noticing since by then everyone will have adopted it in RISC-V mode.
And the overall board is really really nice. It’s even more complete than the awesome Breadbee, and its I/O are more easily accessible. I’d have preferred to have soldered SD-NAND but without a way to program it, micro-SD finally is a fine option as well. What’s annoying as a dev board is the lack of an USB accessible UART, but the 2.54mm pitched pins are easy to connect to, and in theory I should be able to use the USB-C in gadget mode (no success for now).
Im busy testing some SDNAND chips at the moment, found the DUO(256) does have a flash over serial option to program SPI/NAND and EMMC. Im using a sdcard breakout until i solder the actual chip to a Milk-v board
I have an SD breakout adapter that I’ve used to connect my SD-NAND, but no matter what I try, it’s never properly detected. I even suspected voltage issues at some points but it’s OK. I’ve detached all wires from each other in case it was a capacitance issue, no luck. I tried different adapters (USB-based and non-USB based). My chips are CSNP01G something FWIW. I wasn’t aware about the flash-over-serial, that’s good to know! It could be sufficient to reflash the boot loader for example. If you manage to get yours to work, I’m very interested. In the mean time I’ve found some $1.31 256MB micro-SD that just arrived today and are working fine (16 MB/s, quite decent for what it is), and it can constitute a reasonable alternative to SD-NAND.
I disagree, it seems quite obvious for anyone before they buy it that RISCV is the focus, with the ARM support not being as good. This isn’t an incentive to switch to RISC-V or anything.
If someone is going to bother to use ARM with this SoC, they will keep with it. Note per example that this kit has a camera but the C906 core only has support with the 0.7 version of the Vector instruction of RISC-V(it wasn’t ready yet). You are going to have to rely on custom toolchains to get it running while the A53 has a good well known NEON. This is important for Image/Video processing and is going to affect a lot in performance.
You want it for being a good cheap linux chip like there are others with A7(the luckfox comes to mind) or so. The confusion with the two cores that you cannot use at the same time are uneeded and instead might have been better if one was replaced by a small graphics accelerator or so.
RVV 0.7 is supported in GCC 14 upstream, so there’s no need to use a custom toolchain anymore. But obviously, many packages are not yet built with GCC 14 and won’t benefit.
https://forum.beagleboard.org/t/th1520-vector-instructions-in-gcc/37458
Well, you will need to use -march=rv64gc_xtheadvector or -march=native(if you are compiling on the device), so no package will benefit unless you are building them yourself. It is however good that GCC supports it now.
Though packages in general will choose to support the most common ISA, which would be rv64gc. If they do target one with Vector extensions then it would be the official one which isn’t compatible with the T-Head one. Will T-Head even continue to use it for future chips?
And that is for packages that rely on auto-vectorization or using some GCC vectorization feature. If the package includes hand written ASM, then I am going to guess that most maintainers won’t choose to support the T-Head old version of it, which while has quite a bit of compatible stuff that didn’t change from v0.7, enough has changed(specially in Load/Store) that it does matter.
Link to changes in V0.7 to V1:
https://www.remlab.net/op/riscv-v-draft-1.shtml
That’s the well-known problem of risc-v, fragmentation, that makes it a much worse choice for general computing than armv5 or armv7 used to be before the arm926 and respectively the cortex era. Here everyone comes with their own extensions, like on the Marvell Dove running v6/v7 with iwmmx-t extensions brought by intel to DEC’s StrongARM. I guess nobody ever used them. Later it was vfpv3-d16, that convinced some distros to use that as the common denominator for FPU and to ditch NEON (which was not much present by then). At least A7 has cleaned up a lot of things by standardizing VFPv4 and NEON on the low-end, and ARMv8 made everything much better. RISC-V seems to still be in its infancy with everyone trying to promote their core and extensions as the future winner, and software developers watching and waiting for the end of the battle before choosing what they implement and maintain.
Again, I do strongly prefer aarch64 to riscv64 in terms of ISA, but on this low-end segment I certainly understand why a vendor wants to cut prices by dropping license costs. Risc-V is immature but highly sufficient for lots of such devices, even without vector instructions. Also, such a small device is definitely not where you’d place a graphics accelerator. This targets tiny headless devices, not anything that would be used to play video or games. Regarding the Luckfox, I’m well aware of it as I also have one. I had bet more on it initially, since using much better known and supported components. But its form factor is just not as interesting, it’s exactly twice as large as the licheerv-nano. If Sipeed had done something in the same form factor based on the luckfox’s chip (RV1106G2) I’d definitely have bought it instead of the risc-v one.
Graphics accelerators aren’t just for videos or games but any sort of display. This kit has a camera and a display in fact. Depending on the specific graphic accelerator it could be useful for display(like a simple 2D one) or both.
The objective would be to lessen the burden of the main core for other things and to offer a faster, more responsive feedback to the user.
This has already been done with quite a few MCUs, so it’s not like a graphics accelerator is anything Like the Chrom-ART from STM which you can have with a 80 MHz M4.
Renesas also offer some like how the S7G2 has a LCD Controller and a 2D drawing engine.
Yes, it`s not going to be useful in a lot of headless applications, but the same is true for the big core that you don’t use in this SoC, or rather, it’s even worse as that one would have no utility at all, it’s a choose one and stick with it.
Well, offloading 80 MHz worth of operations from a 1 GHz CPU isn’t going to be much noticeable. However what matters for such devices is to have a DMA-capable SPI controller for moderately high resolutions displays.