Arduino Cinque – The RISC-V, ESP32, WiFi, Bluetooth Arduino

This weekend at the Bay Area Maker Faire, Arduino in conjunction with SiFive, a fabless provider of the Open Source RISC-V micros, introduced the Arduino Cinque. This is a board running one of the fastest microcontrollers available, and as an added bonus, this board includes Espressif’s ESP32, another wonderchip that features WiFi and Bluetooth alongside a very, very powerful SoC.

Details on the Arduino Cinque are slim at the moment, but from what we’ve seen so far, the Cinque is an impressively powerful board featuring the RISC-V FE310 SoC from SiFive, an ESP32, and an STM32F103. The STM32 appears to be dedicated to providing the board with USB to UART translation, something the first RISC-V compatible Arduino solved with an FTDI chip. Using an FTDI chip is, of course, a questionable design decision when building a capital ‘O’ Open microcontroller platform, and we’re glad SiFive and Arduino found a better solution. It’s unknown if this STM32 can be used alongside the FE310 and ESP32 at this point.

We’ve taken a look at SiFive’s FE310 SoC, and it is an extremely capable chip. It was released first at the HiFive1, and our hands-on testing revealed this is a chip that outperforms the current performance champ of the Arduino world, the Teensy 3.6. Of course, with any new architecture, there will be a few problems porting the vast number of libraries over to the FE310, but SiFive has included an Arduino compatible SDK. It’s promising, and we can’t wait to see SiFive’s work in more boards.

61 thoughts on “Arduino Cinque – The RISC-V, ESP32, WiFi, Bluetooth Arduino

  1. Finally, two meme chips together on a meme brand board!

    Jokes aside though, that’s actually pretty darned cool. A really fast and open microcontroller plus a really connected microcontroller would let you do all sorts of fun stuff. It’s a shame the whole board doesn’t have more I/O pins, because I’d really like to see something like this controlling robots. Use the FE310 for controlling stepper motors with great time-resolution, and use the ESP32 to boss it around.

  2. Yup cool. Yet crippled by the Arduino debt : board IO (limited count, supid non-standard pitch between headers), a fake IDE, subpar performance libraries, … For me the biggest turn-off is the “uno-style” board, as the other points can be overcome using other tools.

    However, this is a pretty nice board. Still, some questions are still there : how do you interact with the ESP32 ? Is it reprogrammable ? Same goes for the tiny STM32F103, as it would make a pretty cool power manager.

    1. Yeah. The extremely limited I/O is daft. They’ve got 3 different processors on the board with a large number of I/O pins but then just restrict it by only having the basic Arduino shield connector. I guess if it does prove popular then they can make a Mega version for more $$$. This board looks expensive though so that probably won’t happen.

    2. crippled by hugely small amount of ram. 16kB for 300Mhz! like running your current PC with 512MB ram, doable but puny.
      16kB instruction cache on risc-v also is equilavent to 8kB cache on cortex-M, as code is twice the size.
      No DMA also on any peripheral AFAIK, but that’s in line with arduino model anyway.

      1. I think the four bit (quad) spi FLASH is more of a limitation. The CPU is 320MHz so the FLASH would have to be running at 640MHz to keep up. I haven’t seen serial flash chips that are any faster than 10ns.

        1. Perhaps you’re making a few assumptions? Like one opcode is needed every cycle (unlikely with the cache) and every opcode is exactly 1 byte, and none of the clock cycles are used for command and address to the SPI flash chip.

          1. Factually false. The SiFive core supports the compressed instruction set (‘C’) which means a mix of 32-bit and 16-bit instructions. Density is comparable to Thumb. However, make sure your toolchain is set to use it (which was an issue in the beginning).

        1. Nope, tested on large code size (gcc, -O2, -Os broken on my toolchain) there is a 20/25% reduction in code size, that’s still 30% bigger than thumb2 (original code is is 80% over thumb2), and you get performance hit too.

          This code size is the biggest caveat for riscv in deep embedded world. The other one is that the core is optimized for size and not perf (in term of synthetized hw speed, not sw exec), which is rather dumb given that code size issue.

      1. That looks interesting but it doesn’t look like JavaScript except for the dotted notation. JavaScript normally has some form of object model. This implementation has an API so I assume there is no object model and it more like a straight procedural language.

        It’s still “interesting” though. I often use JavaScript in a browser when I need a complex graphical output from some fairly heavy (interactive) number crunching as browsers are fairly well optimized for running JavaScript efficiently and a browser has reasonable graphics rendering ability.

        1. Look again. The Javascript in Espruino is very much Javascript. Event driven and all.
          As for memory the memory usage of Javascript that is not a language problem, that is a web page coder problem.
          The Espruino Javascript runs in a very small space for example. (Yeah, I know it’s huge to C and assembler coders but that is another story). It need not leak memory any more than any other language.

    1. You can’t do much about that now. If you fix it then all the Arduino shield boards out there won’t fit properly. If you fix the spacing then you might as well redo the entire connector system.

      1. Isn’t that just perpetuating the problem? I don’t see it as a problem, old shields can either be modified or just used with old arduinos and new shields can be made with the new header – which can either be modified for old arduinos or just used with new arduinos.

        1. They retained PS/2 at the same time USB came out.

          Arduino might do a similar thing but the trick would be to ensure shields didn’t just use the old headers at the same time; not a problem USB vs PS/2 faced.

          Recently I was involved with a company that had troubles – their approved configuration required a certain motherboard – an in-house design – that used the PS/2 interface, but they are running out of companies who will even build a PS/2 keyboard. Life sucks for FDA regulated equipment makers. Too bad they only had a couple decades to avoid this.

          1. I’m sorry for using an imperfect example, I should’ve known it wouldn’t get the point across unless it was a perfect 1:1 comparison. *sigh*

    2. The Uno form factor is one of the easiest things to fix.

      Just pop it 10 ton hydraulic press then burn it with an oxy acetylene then hit it with an angle grinder and then irradiate it with plutonium and then it’s form factor will be at it’s best ever.

  3. This board needs some analog peripherals….at least an ADC. I wonder if they’ll use the ADC on the ESP32 or the STM32F103…or none.

    It would be nice if they include in newer versions of the FE310 SOC an ADC, a USB peripheral, and an FPU. With these three things, the RISC-V CPU would be complete enough in my eyes……The ADC is probably the thing that is most badly needed…..

    I know that it is harder/more expensive to fabricate a digital SOC with an analog subsystem…..but it has been the norm for well over 30 years now.

  4. I…I am quite appalled by this. The STM32F103 is pretty beefy and full of features on its own, and yet they relegate it to nothing more than a USB-to-serial? And the ESP32 is just used for WiFi and bluetooth, when it can do so much more, including running a NES-emulator all on its own!

  5. I’ve seen some “tests” comparing the E310 with AVR, ARM Cortex-M0 ect ect that I believe are a little biased since the E310 lacks some basic on chip peripherals that are standard in others, so depending on the types/conditions of tests and what exactly they were measuring, they could get different biased results, for example in the case of power consumption when the other microcontrollers are more rich in peripherals and some of them are powered up by default. Apart from that, why test it against low-end ARMs or the 8-bit AVRs? This is supposed to be a 320MHz clocked microcontroller, so a test would make sense with microcontrollers of similar levels (they do exist).

    As for the Arduino Cinque, the inclusion of both an STM32 and an ESP32 is just an overkill with respect to power consumption. I am sure they could find a better solution but maybe they are rushing to get something initial to the market in order to make their product accustomed to the public.

    I personally believe that some basic peripherals like an ADC & DAC, a bigger on-chip FLASH (they now have a One Time Programmable 8KiB memory for a microcontroller running @ 320MHz) and some DSP/FPU functionality would make this SoC more usable.

  6. A recent RPi (Zero W) is even more powerfull an will be, for sure, far cheaper. Maybe power consumption of this board is lower, but Arduino was never about power efficient designs. I dont see why Arduino wants this arms race.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.