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… Read more »
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… Read more »
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… Read more »
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… Read more »
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… Read more »
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… Read more »
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.… Read more »
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.