A Smaller, Cheaper RISC V Board

Early this year, the world of electronics saw something amazing. The RISC-V, the first Open Source microcontroller was implemented in silicon, and we got an Arduino-derived dev board in the form of the HiFive 1. The HiFive 1 is just a bit shy of mindblowing; it’s a very fast microcontroller that’s right up there with the Teensy when it comes to processing power. There’s support for the Arduino IDE, so all those fancy libraries are ready to go. That’s not to say there aren’t a few problems; it’s a relatively expensive board, and it does use the ubiquitous but somewhat unfortunate Arduino form factor.

In the past few months, SiFive, the folks behind the FE310 microcontroller inside the HiFive 1, have been working to get bare chips out on the market. Now, those trays of microcontrollers are being turned into newer, slightly more development-friendly boards. Meet the LoFive RISC-V. It’s a GroupGets crowdfunding campaign from [Michael Welling], and it takes all the openness from the HiFive 1 and the FE310 microcontroller and stuffs it into a cheap, easy-to-use board.

Like the HiFive 1, the LoFive features the FE310 microcontroller and a 128 Mbit SPI flash. Unlike the HiFive 1, there’s not much else on this board. There’s a few voltage regulators, a crystal, some caps, and a button on an interrupt pin. If you’re looking for an Open Source microcontroller development board without a lot of cruft, here you go. This is a RISC-V microcontroller with the minimum amount of support circuitry.

The GroupGets campaign is offering up 1,000 of these little boards for $25 each plus shipping. If you’ve been looking for an excuse to play around with Open Source microcontrollers, this may be the best chance you’re going to get for a while.

61 thoughts on “A Smaller, Cheaper RISC V Board

        1. If you are running the Javascript and its interpreter out of ROM, sure. Especially if you’ve crunched the JS into some type of bytecode first: collapse keywords and variables into 8 or 16 bit integer IDs. Much like the BASIC implementations of Apple II and C-64 machines. After that it would depend on just how _much_ JS you wanted to run and how dynamic it is. If you only create objects of precompiled types then those can be in ROM and accessed by small IDs into tables of known types. Otherwise you’d need to store hash tables of property ID strings and RAM would run out fast.

        1. You misunderstand the thinking there. To SiFive, whom they’re BUYING the silicon, it’s royalty free. And, in the large, if you took the 32-bit Rocket Core and ASIC-ed it, you’d have the bulk of this chip. There’s actually not a lot of closed anything on this “CorePlex” that requires patent or copyright licensing.

          So, while you’re buying the SiFive device, they don’t have to pay anyone for licensing, much like if ARM went and made their OWN iterations of a core- and if you didn’t like SiFive, you could just as easily produce a very similar (to the point that your software wouldn’t need to change…AT…ALL…) device if you had the moxie to ASIC it yourself.

          You need to revise your thoughts…they’re deeply in error and you fail to comprehend what’s going on…to be blunt.

          1. Furthermore, the whole design is available royalty free for others to manufacture (aside from the peripheral IP, which would probably differ between foundries anyway).

          2. So? you can ask SiFive for their design, I mean the real IP, not just chisel sources. It will cost you some money, ok it’s not royalty based as it’s a one time payment, but that’s their business: selling IP.
            Yes you can say that sifive has not to pay for other third party IP that’s true, but meaningless for the end user.

            RISC-V advantage is the patent free customization that are possible, but SiFive design is a straight rocket core (kudo for them to share their 32bit work) with nothing fancy. Not like Pulp core which is interesting but lacks tool support (no mainstream gcc first).

        1. It’s 1-2% now, but since ARM have a monopoly on the ISA, if they changed it to 80% tomorrow there’s not a single thing you could do about it. Saying “what’s the point” is pretty short sighted.

          You’re probably the guy who will be (indirectly) enjoying the benefits of Risc-V 10 years from now (and probably still without an ounce of gratitude or reflection).

          1. If ARM decide to increase it to 80%, they’d lose all their customers, and they’d force everybody to use an alternative.

            In other words: it would realistically never happen. ARM has a large portfolio of cores for this reason. Chances are that most potential customers will find something that will match their budget.

            Furthermore, you’re relying to somebody who made a simple objective observation. Here was no need at all to call him ungrateful or whatever other misdeed you’re imagining.

            RISC V is a neat project. But unless you have some very strong ideological motivations, it makes more sense to evaluate chips with different CPUs on their individual technical and financial merits. Licensing costs is basically irrelevant in that.

      1. That’s just words. I have no way to verify that SiFive’s device contains only what they say it does, and no reason to trust them or their fab over ST, NXP or whoever. Until Chris Gammell gets his chip printer working it’s not within my resources to manufacture one myself. And just as a personal opinion, I think the RISC-V architecture is ugly and less well suited for microcontrollers than Cortex-M.

          1. Not when you are paranoid. How do you know that nothing extra (like a back door) has been added. A backdoored design would have the same cycle timings… Until the backdoor was activated.

            For that matter, how do you know that the FPGA you are testing on doesn’t have a back door changing your design while you test.

            Or the chip printer, how do you know it’s not inserting a back door into the design while you print your chip???

            Of course at some point you have to draw a line and say “I have been paranoid enough, let’s just trust SiFive’s fab.”

          2. No, you still don’t know what’s inside silicon. Open source HDL != open source hardware.
            FPGA design are never cycle perfect result (unless talking from cycle per instruction for CPU). Timings are way different (important for peripherals) and most of the time design differs since FPGA are not strictly the same as asic (ie no power domain on fpga, quite different clocks implementation etc…).
            I use routinely fpga to validate sw before silicon is here or developing bootrom code, it works and it’s a fantastic tool, but still it’s not replacing validation/simulation and final tests on silicon.

    1. Where are you finding Cortex M0 dev/eval breakouts for $2.50 a piece? (That’s 1/10th of the price here for a single…)

      Best price I see is for $8.88 from _reputable_ sources. Hm…the new board’s just 3 times the price of a Cortex-M0 and it’s fully open source from the ISA to the board implementing the CPU configuration. I think you’re missing the point as much as the guy who claimed that you’re paying royalties to SiFive. Royalties are paid out for licensing code and hardware design…not parts. And you missed the mark on pricing because the bulk of Cortex-M0 boards are only 1/2 to 1/3rd as expensive.

    2. Show me this $5 (or less!) small form factor Cortex-M0 board (with a 640MHz clock, since M0 has about half the DMIPS/MHz as FE310, which runs at 320MHz) which can compete for power at about twice the clock rate to keep up.

  1. “it’s a very fast microcontroller that’s right up there with the Teensy when it comes to processing power.” – ok, so why would I want to use this as opposed to a teensy (or other board in the same basic price range)? I am trying to see what the compelling draw is. Am I missing something?

    1. > Am I missing something?

      Yes, go read the post again. There are two very important words hidden in the first two sentences. Hint: “Open Source”.

      Even this doesn’t matter to YOU, it’s pretty damn important to others out there. This chip really is ground-breaking for that reason.

      So why’s it so expensive? Almost all other silicon remains closed-source because they know that their business model depends on it. The margins are so thin and the patent minefield is so large, that some of them refuse to even send a datasheet without an NDA (let alone HDL files on the chip itself). So now if RISC-V wants to try a different business model in a way that doesn’t mitigate those risks, then yea, it’s going to cost more.

      There’s obviously room in the ecosystem for the RISC-V to exist, even at the prices that they’re asking now.

      1. We won’t get into .the ability to largely implement the core yourself if SiFive actually buys it and goes away.

        People don’t get that it consumes LESS power than the Cortex-M0 they keep pointing to and saying, “That’s cheaper!” (While grotesquely overstating the difference, to be brutally blunt. 5-10 times? Hardly. Pull up what price you pay Mouser or similar for those “cheaper” boards…only 2-3 times more expensive, folks…). People don’t get that you can figure it out and have HDL to implement your own ASIC or FPGA softcore and not spend a fortune on IP rights in the same- and you can start out as an FPGA and move to an ASIC without changing much of any, IF any, code. The same can’t be said of ARM, which entails you having an ARM core in your FPGA or external to it…or using a MicroBlaze, NIOS II, or the like and then having to buy an ARM for parts count and recoding when you go to an ASIC for your design.

        It’s time for people to wise up and educate themselves instead of flapping their jaws.

        1. Sorry to end up your fanboyism, but no, rocket core are not as efficient as ARM CM0 (not even CM4) when running on the same process (you can’t compare a 90nm flash based CM0 with a 28/55nm flashless risc-v).
          ARM has many more years of polishing their architecture, risc-v is young, very young and that’s only when really playing with it that you experience it (got fpga boards here with various risc-v running). But even young it’s usable and well tough.
          RISC-V has a MAJOR drawback in embedded: code size. RV32IMA is twice the code size of thumb2, using compressed code only gives you 1.5x the size of thumb2 code.
          Since ram and flash size are the real cost of silicon, this is a real issue on small soc, it only disappears when you move to cortex-A, which are different beasts.

          1. I have compared generated code size on lwip core library with different compilers, rv32im/rv32imc (gcc 6.1) and arm gcc thumb2 (gcc 4.8.4). Code size compared only on core library (some inlining may occurs), compiled in -Os with same options.

            rv32im/rv32imc: avg=1.34, stdev=0.15
            rv32im/thumb2: avg=1.61, stdev=0.3
            rv32imc/thumb2: avg=1.21 stdev=0.24

            So rv32imc is not as efficient as arm thumb2 (+21% static code size), but can be in some (rare) case as efficient.
            I didn’t have latest gcc7 or rv32ima on hand to test further. I do not think it will change dramatically the result as im/thumb2 is already showing good numbers.

          2. Thank you for the numbers! Actually evaluating claims is always important.

            Two additional notes:

            It’s the actual intention of a RISC architecture to move more complex operations out of the CPU, into general code, so a certain increase in code size isn’t surprising. At the end of the day it matters how fast or with which amount of energy the code executes, after all.

            The other thing is, the RISC compiler is pretty young, so probably not too good at optimization, yet. This can get better over time without changing the hardware.

  2. an article about a new microcontroller on a tech blog.. how about some freaking specs and features ?

    what peripherals does it sport, how many timers, pin change interrupts, serial interfaces, RAM size and tech, clock speed, does it have DMA, … etc

    1. All the details you want are in the link to the last article hackaday did on this processor. That links is in the second sentence of the article. This article is just covering the fact it is now available in a lower budget, small development board.

      1. True for the most part.

        The error of that one section of pins not being on the 0.1″ centers could have been solved by just putting it on the 0.1″ centers as soon as the issue was found.. It’s close enough that any shields made to that point would have fit albeit tightly but then the issue would not have propagated much.

        The un-dense pin density makes sense for the number of IO pins available to the Atmel chips also it wouldn’t be very breadboard and hobbyist friendly if it was using a denser pin arrangement.

        As for the pins being female… “Typical patriachy! Why does it have to be male!!” /S
        Yeah, being male and pointing out the bottom would have made breadboaring an absolute dream.

          1. And the board in question here is basically the same breadboardable form-factor as a nano or Teensy anyway. So what was the point of this whole line of argument.

            Something that is unfortunate though is that it seems to need a full JTAG interface, for which they are pushing an FT2232 board. Too bad they couldn’t come up with something with a lower signal count comparable to SWD.

          2. Exactly this ^^^^,

            Not just the nano, but also the Pro Mini, and my personal favorite, the Pro Micro (which are so cheap on eBay that I buy them in packs of 10).

            Who cares if the original Arduino form factor isn’t on 0.1″ centers? Use the Pro Micro for that, or the Nano. Or, just complain more on the internet and look like an idiot.

      1. Not a particularly fast ADC though, fine for temperatures or light level sample or position of potentiometer or something. In general I’d prefer to use an op amp as comparator on ramping style ADCs.

    1. GCC 7 is fine and easy to build, same for other tools (open-ocd, gdb). That’s why risc-v is more interesting than previous opensource attempt (like openrisc), because from start they done their work well (openriscv wasn’t albe to upstream their gcc due to a guy refusing to give its copyright to GNU for example).
      I had numerous issues with older patched toolchains, sometimes giving unusable code on some optimization different than -O2.

  3. The statement “all those fancy libraries are ready to go” might be a little overly optimistic. For example, here’s the Wire library code needed to talk to any I2C chips.

    https://github.com/sifive/cinco/blob/master/hardware/freedom_e/libraries/Wire/Wire.cpp

    You don’t need to be very experienced with C++ or Arduino lib development to see it’s currently just an empty placeholder. The most recent commit affecting that file also reads “Wire: Delete everything. We haven’t really implemented this yet.”

    Hopefully in time this an others will become mature libraries. Then again, after more than 1 year Intel never managed to get their Wire library really working well on Arduino 101. It’s easy to take these widely used libs for granted, but the reality of “Arduino support” can vary quite a lot.

    Still, just the concept of a fully open source processor is pretty amazing. I really hope it takes off.

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.