EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: oPossum on August 24, 2019, 03:01:19 am
-
https://www.cnx-software.com/2019/08/23/gigadevice-gd32v-risc-v-mcu-development-board/amp/ (https://www.cnx-software.com/2019/08/23/gigadevice-gd32v-risc-v-mcu-development-board/amp/)
The new GD32VF103 series RISC-V MCU family features 14 models with the following key specifications:
Core – GD32VF103 RISC-V “Bumblebee Core” @ 108 MHz
Memory – 8KB to 16KB SRAM
Storage – 16KB to 128KB flash
Peripherals – USB OTG and CAN 2.0B
I/O – 3.3V, 5V tolerant
Supply Voltage – 2.6 to 3.6V
Package – QFN36, LQFP48, LQFP64, and LQFP100 packages
May be pin compatible with STM32F100 series.
-
That sounds lire the first actually usable RISC-V MCU.
Would be nice to have dev kit available from sellers on more approachable platforms. I would definitely get one.
-
"Would be nice to have dev kit available from sellers on more approachable platforms. I would definitely get one."
many available
https://gd32.tmall.com/category.htm?spm=a220o.1000855.w4010-18883888930.2.3a7b676eMpeEuQ&search=y
-
Yeah, but you need to read Chinese. And probably give them your credit card. And I'd rather not.
Hopefully someone will sell them on eBay or Aliexpress.
-
here is link of datasheet (http://dl.sipeed.com/LONGAN/Nano/DOC/) and SDK (http://dl.sipeed.com/LONGAN/Nano/SDK/)
Bumblebee_Core_Doc (https://github.com/nucleisys/Bumblebee_Core_Doc)
GD32VF103_User_Manual_EN_V1.0.pdf (http://GD32VF103_User_Manual_EN_V1.0.pdf)
GD32VF103_Datasheet_Rev1.0.pdf (http://dl.sipeed.com/LONGAN/Nano/DOC/GD32VF103_Datasheet_Rev1.0.pdf)
-
RISC-V CPU target for embedded applications that require low energy consumption and small
area, which is compliant to RISC-V architecture with several efficient micro-architecture
features, including simple dynamic branch prediction, instruction pre-fetch buffers and local
memories. It supports 32 general purpose registers (GPRs) and fast multiplier for
performance/area tradeoff:
- RISC-V compliant little-endian RV32IMAC (32GPRs) ;
- Configurable 2-stage pipeline optimized for low gate-count and high frequency;
- Machine (M) and User (U) Privilege levels support;
- Single-cycle hardware multiplier and Multi-cycles hardware divider support;
- Misaligned load/store hardware support;
- Atomic instructions hardware support;
- Non-maskable interrupt (NMI) support;
- Dynamic Branch Prediction and instruction pre-fetch buffers to speed up control code;
- State-of-the-art micro-architecture design to tradeoff area and performance requirements;
- WFI (Wait for Interrupt) support;
- WFE (Wait for Event) support;
- Interrupt priority levels configurable and programmable;
- Enhancement of vectored interrupt handling for real-time performance;
- Support interrupt preemption with priority ;
- Support interrupt tail chaining;
- Standard 4-wire JTAG debug port
- Support interactive debug functionalities
- Support 4 triggers for hardware breakpoint
-
Would be nice to have models with more RAM too.
-
here is link of datasheet (http://dl.sipeed.com/LONGAN/Nano/DOC/) and SDK (http://dl.sipeed.com/LONGAN/Nano/SDK/)
Bumblebee_Core_Doc (https://github.com/nucleisys/Bumblebee_Core_Doc)
GD32VF103_User_Manual_EN_V1.0.pdf (http://GD32VF103_User_Manual_EN_V1.0.pdf)
GD32VF103_Datasheet_Rev1.0.pdf (http://dl.sipeed.com/LONGAN/Nano/DOC/GD32VF103_Datasheet_Rev1.0.pdf)
Where can you buy the evaluation boards?
-
Where can you buy the evaluation boards?
It seems at the moment only on the Chinese market, so to get it elsewhere you'll need a service like yoybuy.com
-
why you trust eBay and don't Chinese stores, there is much secure than in us, crime there is the death penalty, and you can use Paypal, You are kidding about can't read Chinese in today's world you can read any language, with few keystrokes. The Chinese online stores ( Alibaba group ) are much more reliable than eBay, any seller is required to make a huge deposit just to solve future claims, The risk is much lower
-
why you trust eBay and don't Chinese stores, there is much secure than in us, crime there is the death penalty
Oh my, that's hilarious on so many levels..
You are kidding about can't read Chinese in today's world you can read any language, with few keystrokes.
If it were that easy your English wouldn't be so awful.
There are those of us who don't wish to spend three hours figuring out what's happening on a website half in the wrong language and half extraordinarily poorly translated by machine, just to order some cheap parts. And we don't accept that random stores in another country are secure when said country is rife with crime from the top down.
-
If it were that easy your English wouldn't be so awful.
:--
A bit of self moderation is in order when making comments like this.
-
If it were that easy your English wouldn't be so awful.
:--
A bit of self moderation is in order when making comments like this.
It was not intended to be nasty, only to make a point.
If automatic translation was reliable, one would not need to learn other languages - you'd just use a translator.
I apologise for any feelings hurt.
-
I trust AliExpress over eBay, for tech stuff.
(After all, afaict, eBay is usually some less-technical reseller selling AliExpress goods, anyway.?)
I’m not willing to order from a site where I can’t accurately read the language, though.
Either these chips will show up on a more monolingual-friendly site, eventually, or they’re not worth the trouble. If Baite, or one of the other cluefull vendors starts selling them, I’m in!
-
Either these chips will show up on a more monolingual-friendly site, eventually, or they’re not worth the trouble. If Baite, or one of the other cluefull vendors starts selling them, I’m in!
[/quote]
Segger supports them in their RISC V Embedded Studio.
-
.
-
GD32VF103C-START (https://detail.tmall.com/item.htm?id=601020356481)
70RMB/10$ including onboard debugger
-
And probably give them your credit card. And I'd rather not.
Doesn't your credit card company give you the option of generating one time use numbers? Mine does, and I always use this when ordering something from a potentially dodgy site on the Internet. My CC company lets me generate a one-time number with a fixed credit limit (I usually set it to $1 higher than whatever I'm ordering) and an expiration date of next month.
-
If it were that easy your English wouldn't be so awful.
:--
A bit of self moderation is in order when making comments like this.
Oh, yes, I forgot... Political correctness trumps all these days. My bad.
Frankly, I'm glad to see someone (Monkeh) call a spade a spade.
-
.
-
Is the "F103" codename pure coincidence though? ;D
-
Is the "F103" codename pure coincidence though? ;D
Nope.
Another product line that they have released in the past was the GD32F103. And these were basically pin for pin compatible with the STM32. And they were also mostly register and binary compatible, with a few exceptions...
-
I checked the LQFP48 pinout and it matches up, so theoretically you can drop this thing into an existing board design for STM32F103, once you figure out the code of course.
This is really smart, first the F103 clone for a lower price to build trust/brand, then this. AFAIK there haven't been any major issues with that design, but I don't know if anyone has done in depth characterizations.
-
Doesn't your credit card company give you the option of generating one time use numbers? Mine does, and I always use this when ordering something from a potentially dodgy site on the Internet. My CC company let's me generate a one-time number with a fixed credit limit (I usually set it to $1 higher than whatever I'm ordering) and an expiration date of next month.
I've never heard of such a capability! Sounds neat.
Who is "your credit card company"?
Edit: Hmm: Capital One, Citi, Bank of America offer disposable card numbers (https://www.creditcards.com/credit-card-news/credit-card-virtual-account-numbers.php) on *some* cards... (https://www.cardbenefits.citi.com/Products/Virtual-Account-Numbers)
-
I checked the LQFP48 pinout and it matches up, so theoretically you can drop this thing into an existing board design for STM32F103, once you figure out the code of course.
This is really smart, first the F103 clone for a lower price to build trust/brand, then this. AFAIK there haven't been any major issues with that design, but I don't know if anyone has done in depth characterizations.
Does it have a similar set of peripherals as well?
Yeah, I guess if a company is producing millions a year of devices using a STM32F103, they could justify the time investment in porting the software to this new chip, and then it would just be a matter of changing a single item in the BOM...
Not very fair to STM, but hey. Who said business was fair, right?
-
Does it have a similar set of peripherals as well?
Yeah, I guess if a company is producing millions a year of devices using a STM32F103, they could justify the time investment in porting the software to this new chip, and then it would just be a matter of changing a single item in the BOM...
Not very fair to STM, but hey. Who said business was fair, right?
Yeah the peripherals are almost identical, at least for what I looked at, ADC for example (12-bit same sampling times, etc).
There is an opportunity to improve the peripherals (they did bump up the clock speed), but I think that makes things overly complicated, and the vast majority of people buying the chip don't care. Maybe they will come out with another model in the future though.
-
I've never heard of such a capability! Sounds neat.
Who is "your credit card company"?
Citi.
Another use for them is when buying something that has an auto-renewal "feature". I've been burned by these in the past, as they're sometimes hidden in the small print, so now I just set the expiration date for the virtual card number to next month, and any auto renewal will fail.
-
Does it have a similar set of peripherals as well?
Yeah, I guess if a company is producing millions a year of devices using a STM32F103, they could justify the time investment in porting the software to this new chip, and then it would just be a matter of changing a single item in the BOM...
That illustrates a problem for any traction.
If the MHz is the same, and the peripherals are the same, then it is only price that might select RISC-V, and I doubt any large company will move to/risk a single-source part, for a few cents saving.
To get traction in RISC-V, you really need to offer something extra, as a motivator.
Is Gigadevice 'Chinese enough' to win favours in China, over ARM ? - I notice Softbank sold ARM china recently, and certainly China would be keen to avoid sending any license fees off-shore ?
-
It eventually will offer lower price due to better licensing. And after that it might offer custom instructions.
This is literally the first real MCU with this core. This is good enough for now.
I would really like to get my hands on both dev kits. But I'm with others - I want an ordering firm in a language I can read.
-
If the MHz is the same, and the peripherals are the same, then it is only price that might select RISC-V, and I doubt any large company will move to/risk a single-source part, for a few cents saving.
Also...
- Higher IPC
- Better code density
- Lower mW/MHz
-
While those afraid of everything are making complains, I'm playing with my developer board bought from China in Chinese ( I'm smart enough to use google translator and understand ), paid with Paypal with my one-time card.
I hope they understand how limited they are
I guess no one of those was never been in Shenzhen to understand what is going on, and how obsolete they are
-
I checked the LQFP48 pinout and it matches up, so theoretically you can drop this thing into an existing board design for STM32F103, once you figure out the code of course.
This is really smart, first the F103 clone for a lower price to build trust/brand, then this. AFAIK there haven't been any major issues with that design, but I don't know if anyone has done in depth characterizations.
Does it have a similar set of peripherals as well?
Yeah, I guess if a company is producing millions a year of devices using a STM32F103, they could justify the time investment in porting the software to this new chip, and then it would just be a matter of changing a single item in the BOM...
Not very fair to STM, but hey. Who said business was fair, right?
Certainly would be cool if the peripherals are compatible and anyone who wrote their stuff in C pretty much only has to do a recompile.
-
Certainly would be cool if the peripherals are compatible and anyone who wrote their stuff in C pretty much only has to do a recompile.
Good luck on RTOS. That's a lot of works to do, especially if you make your own and don't want to go through hundreds pages of Chinese document on that particular RV implementation.
My understanding is this GD new MCU was not planned ahead of time. It was just an attempt trying to capitalize the fear of Chinese market on dependency to proprietary US technology.
I believe Zephyr and FreeRTOS are both in pretty good shape for RISC-V. Of course you need a little porting work for each chip/board.
-
Does it have a similar set of peripherals as well?
Yeah, I guess if a company is producing millions a year of devices using a STM32F103, they could justify the time investment in porting the software to this new chip, and then it would just be a matter of changing a single item in the BOM...
That illustrates a problem for any traction.
If the MHz is the same, and the peripherals are the same, then it is only price that might select RISC-V, and I doubt any large company will move to/risk a single-source part, for a few cents saving.
I don't quite agree with that. Using STM is also having a single-source solution.
Whereas the "risk" may not be worth it for a typical western company, I think it can be well worth it for a chinese one.
Don't forget that those chinese chips are MAINLY designed to address the chinese industry and help it become fully independent, not to please the western world.
To get traction in RISC-V, you really need to offer something extra, as a motivator.
For a typical western company, again, I'd agree with you. Not necessarily for a chinese one.
Is Gigadevice 'Chinese enough' to win favours in China, over ARM ?
I don't know about Gigadevice as a whole, but any chip designed in China and not depending on any non-chinese IP is probably enough to win favours in China at the moment.
-
Here is an other one https://www.sifive.com/boards (https://www.sifive.com/boards) HiFive1 Rev B. Only 16KB of ram. And the Vega board https://open-isa.org/ (https://open-isa.org/) with 4 cores :)
-
... And the Vega board https://open-isa.org/ (https://open-isa.org/) with 4 cores :)
That's unusual, it has a NXP logo, and claims to have a foot in both camps, with ARM and RISC V cores. RF support and BGA with large memories (1.25MB Flash 384k RAM )
However, even with a Nov 2018 NXP data sheet download, a search on NXP.COM for RV32M1, finds nothing at all ?
-
It must have been initiated by Freescale as and experiment? https://mcuoneclipse.com/2019/03/16/running-freertos-on-the-vega-risc-v-board/ https://mcuoneclipse.com/2019/03/05/debugging-the-rv32m1-vega-risc-v-with-eclipse-and-mcuxpresso-ide/
-
... And the Vega board https://open-isa.org/ (https://open-isa.org/) with 4 cores :)
That's unusual, it has a NXP logo, and claims to have a foot in both camps, with ARM and RISC V cores. RF support and BGA with large memories (1.25MB Flash 384k RAM )
However, even with a Nov 2018 NXP data sheet download, a search on NXP.COM for RV32M1, finds nothing at all ?
That device makes huge sense. The core is only a few percent of the die on a chip like that. Adding a second core lets them dip a toe in the RISC-V waters cheaply, while having a ARM core that ensures market acceptance. Making a complex chip with only a core whose market acceptance is unproven is risky. Making a simple chip with the unproven core means it won't do enough to attract much of an audience.
-
That device makes huge sense. The core is only a few percent of the die on a chip like that. Adding a second core lets them dip a toe in the RISC-V waters cheaply, while having a ARM core that ensures market acceptance. Making a complex chip with only a core whose market acceptance is unproven is risky. Making a simple chip with the unproven core means it won't do enough to attract much of an audience.
Yes, I agree it is a clever approach. Given the large Flash and RAM, and Peripherals, the cores will be relatively small % of area.
-
Certainly would be cool if the peripherals are compatible and anyone who wrote their stuff in C pretty much only has to do a recompile.
Good luck on RTOS. That's a lot of works to do, especially if you make your own and don't want to go through hundreds pages of Chinese document on that particular RV implementation.
My understanding is this GD new MCU was not planned ahead of time. It was just an attempt trying to capitalize the fear of Chinese market on dependency to proprietary US technology.
ARM is from the UK
-
ARM is from the UK
ARM is owned by Softbank, which is known to be very keen on following US rules. Apple is another owner of ARM, which naturally, follows US rules.
Per US DOC regulation, all companies with more than 25% US capital or US technology fall within DOC's jurisdiction. If such a company defies US regulation, it will face sanction, even if the major stake is owned by foreign entities.
Softbank is Japanese and ARM is headquartered in the UK, How much stock does Apple own in ARM?
-
How much stock does Apple own in ARM?
Probably not a lot these days. Fun fact: ARM was originally started as a joint venture between Acorn Computers, Apple, and VLSI Technology.
-
... And the Vega board https://open-isa.org/ (https://open-isa.org/) with 4 cores :)
That's unusual, it has a NXP logo, and claims to have a foot in both camps, with ARM and RISC V cores. RF support and BGA with large memories (1.25MB Flash 384k RAM )
However, even with a Nov 2018 NXP data sheet download, a search on NXP.COM for RV32M1, finds nothing at all ?
That device makes huge sense. The core is only a few percent of the die on a chip like that. Adding a second core lets them dip a toe in the RISC-V waters cheaply, while having a ARM core that ensures market acceptance. Making a complex chip with only a core whose market acceptance is unproven is risky. Making a simple chip with the unproven core means it won't do enough to attract much of an audience.
These multi-core, multi instruction set franken-monstrosities don't appeal to me at all. TI has something like this in the AM574x sitara.
Which has, count em,
2 Arm Cortex A15, 2 C66x DSP, 2 cortex M4, 2 PRU's and a partridge in a pear tree! Just Crazy.
Each different ISA requiring a different compiler and tool chain. who needs that complexity headache.
I see at least 4 market segments where RISC-V has a unique value proposition.
1. Very low cost high volume commodity controllers where the ARM licence cost is a dead weight and every penny counts.
2. companies like Western Digital who have high volume internal needs and want to be free from ARM licencing control and cost.
3. commodity manufactures who want to be immune to capricious changes in export law/sanctions
4.High security PC applications and server market, those that want to be free from back-doors like Intel's management engine
-
... And the Vega board https://open-isa.org/ (https://open-isa.org/) with 4 cores :)
That's unusual, it has a NXP logo, and claims to have a foot in both camps, with ARM and RISC V cores. RF support and BGA with large memories (1.25MB Flash 384k RAM )
However, even with a Nov 2018 NXP data sheet download, a search on NXP.COM for RV32M1, finds nothing at all ?
That device makes huge sense. The core is only a few percent of the die on a chip like that. Adding a second core lets them dip a toe in the RISC-V waters cheaply, while having a ARM core that ensures market acceptance. Making a complex chip with only a core whose market acceptance is unproven is risky. Making a simple chip with the unproven core means it won't do enough to attract much of an audience.
These multi-core, multi instruction set franken-monstrosities don't appeal to me at all. TI has something like this in the AM574x sitara.
Which has, count em,
2 Arm Cortex A15, 2 C66x DSP, 2 cortex M4, 2 PRU's and a partridge in a pear tree! Just Crazy.
Each different ISA requiring a different compiler and tool chain. who needs that complexity headache.
I see at least 4 market segments where RISC-V has a unique value proposition.
1. Very low cost high volume commodity controllers where the ARM licence cost is a dead weight and every penny counts.
2. companies like Western Digital who have high volume internal needs and want to be free from ARM licencing control and cost.
3. commodity manufactures who want to be immune to capricious changes in export law/sanctions
4.High security PC applications and server market, those that want to be free from back-doors like Intel's management engine
I'd say you missed a few.
1. anything where a custom instruction tightly integrated into the processor (i.e. take one or two register values, compute something, write the result to a register, all in 1 clock cycle) can significantly improve performance and energy efficiency on some task. ARM won't allow you to do that at any price. A coprocessor or memory-mapped device are the best they'll allow. This is ARM policy rather than physics or mathematics, so they could choose to change this.
2. anything that wants a microcontroller level of area / performance / energy consumption but wants 64 bit addressing, for example because you're an I/O controller in the corner of a bigger chip. ARM doesn't offer small 64 bit cores comparable to Cortex M0 or even M3. Again, this is more policy than anything, though they'd also want to define a subset of Aarch64, which is not currently allowed. RV64I cores can be very small -- and there seems to be demand for RV64E (16 registers only) also.
3. anything that wants 64 bit with code density comparable to Thumb2. Aarch64 code is much bigger than Thumb2 (though smaller than original ARM). This is hard to fix. There is insufficient room in the A64 encoding to add on 16 bit opcodes so you'd need either an awkward mode change as with original Thumb, or else an entirely new instruction encoding. MIPS, incidentally, seem to have done a good job of this with NanoMIPS which has 2, 4, and 6 byte instructions and both 32 bit and 64 bit. It looks to be virtually stillborn though, with only a single 32 bit chip announced 15 months ago, and no inclusion in their Open Source offering.
-
... And the Vega board https://open-isa.org/ (https://open-isa.org/) with 4 cores :)
That's unusual, it has a NXP logo, and claims to have a foot in both camps, with ARM and RISC V cores. RF support and BGA with large memories (1.25MB Flash 384k RAM )
However, even with a Nov 2018 NXP data sheet download, a search on NXP.COM for RV32M1, finds nothing at all ?
That device makes huge sense. The core is only a few percent of the die on a chip like that. Adding a second core lets them dip a toe in the RISC-V waters cheaply, while having a ARM core that ensures market acceptance. Making a complex chip with only a core whose market acceptance is unproven is risky. Making a simple chip with the unproven core means it won't do enough to attract much of an audience.
These multi-core, multi instruction set franken-monstrosities don't appeal to me at all. TI has something like this in the AM574x sitara.
Which has, count em,
2 Arm Cortex A15, 2 C66x DSP, 2 cortex M4, 2 PRU's and a partridge in a pear tree! Just Crazy.
Each different ISA requiring a different compiler and tool chain. who needs that complexity headache.
I see at least 4 market segments where RISC-V has a unique value proposition.
1. Very low cost high volume commodity controllers where the ARM licence cost is a dead weight and every penny counts.
2. companies like Western Digital who have high volume internal needs and want to be free from ARM licencing control and cost.
3. commodity manufactures who want to be immune to capricious changes in export law/sanctions
4.High security PC applications and server market, those that want to be free from back-doors like Intel's management engine
I agree with you about some of the weird mixed core chips on the market, requiring a variety of software tool chains and other complexities. However, the NXP chip is designed as an either/or device. You can choose which core to use, and completely ignore the other one. Its completely benign.
-
ARM has design centers in the US and other countries that are part of NATO, so many ARM IPs, partly or as a whole, have been designed in those. That alone can enable the US to set the rules when it comes to dealing with "unwanted" countries.
-
Sipeed are releasing a $4.90 board called the Longan Nano using this GD32VF103CBT6 chip. Board and chip specs in English and SDK are all here:
http://dl.sipeed.com/LONGAN/Nano/ (http://dl.sipeed.com/LONGAN/Nano/)
Orders here: https://www.seeedstudio.com/Sipeed-Longan-Nano-RISC-V-GD32VF103CBT6-Development-Board-p-4205.html (https://www.seeedstudio.com/Sipeed-Longan-Nano-RISC-V-GD32VF103CBT6-Development-Board-p-4205.html)
Good reliable company. Many here will already be familiar with their boards using the Kendryte K210 RISC-V chip.
They say the chip has 32 KB SRAM (double the largest mentioned in the first post in this thread), and 128 KB Flash.
The standard SDK is Eclipse-based, but they are also supporting PlatformIO, which is now sponsored by SiFive and Western Digital making the full version with debugging free for everyone (not only RISC-V users).
-
... And the Vega board https://open-isa.org/ (https://open-isa.org/) with 4 cores :)
That's unusual, it has a NXP logo, and claims to have a foot in both camps, with ARM and RISC V cores. RF support and BGA with large memories (1.25MB Flash 384k RAM )
However, even with a Nov 2018 NXP data sheet download, a search on NXP.COM for RV32M1, finds nothing at all ?
The layout of the documents looks exactly like the documents from Freescale. This is very interesting because it may hint NXP is working on a new breed of non-ARM microcontrollers and maybe even SOCs.
-
A story on the Longan Nano here, although I don't think there's any new info: https://www.cnx-software.com/2019/08/29/longan-nano-gd32v-risc-v-development-board-comes-with-lcd-display-and-enclosure/ (https://www.cnx-software.com/2019/08/29/longan-nano-gd32v-risc-v-development-board-comes-with-lcd-display-and-enclosure/)
And apparently the "Bumblebee" core is actually Andes N22. There's a story here: https://www.cnx-software.com/2019/08/28/andescore-n22-risc-v-core-rv32imac-rv32emac-instruction-sets/ (https://www.cnx-software.com/2019/08/28/andescore-n22-risc-v-core-rv32imac-rv32emac-instruction-sets/)
This story doesn't seem to quite match the Gigadevice/Sipeed docs, for example the Sipeed docs say that PMP (Physical Memory Protection .. basically a set of several base&bound registers so you can detect things such as stack overflow or protect machine mode things from user mode code) is not implemented.
-
Here is an other one https://www.sifive.com/boards (https://www.sifive.com/boards) HiFive1 Rev B. Only 16KB of ram. And the Vega board https://open-isa.org/ (https://open-isa.org/) with 4 cores :)
RV32M1 is not a true 4 core, it's 2+2, ie you use either ARM CM4/CM0+ or RI5CY/ZeroRISCY pair (and I think ARM/RISC-V hybrid also).
-
Just had a short conversation with Sipeed on twitter. They've just received the 2nd batch of 1000 Longan Nano boards, they have over 3000 ordered. The next batch is going to be about three or four weeks away -- which ties in with the delivery date on my order being October 9.
They said once they've caught up on board orders they'll be making the bare chips available too.
-
A story on the Longan Nano here, although I don't think there's any new info: https://www.cnx-software.com/2019/08/29/longan-nano-gd32v-risc-v-development-board-comes-with-lcd-display-and-enclosure/ (https://www.cnx-software.com/2019/08/29/longan-nano-gd32v-risc-v-development-board-comes-with-lcd-display-and-enclosure/)
And apparently the "Bumblebee" core is actually Andes N22. There's a story here: https://www.cnx-software.com/2019/08/28/andescore-n22-risc-v-core-rv32imac-rv32emac-instruction-sets/ (https://www.cnx-software.com/2019/08/28/andescore-n22-risc-v-core-rv32imac-rv32emac-instruction-sets/)
This story doesn't seem to quite match the Gigadevice/Sipeed docs, for example the Sipeed docs say that PMP (Physical Memory Protection .. basically a set of several base&bound registers so you can detect things such as stack overflow or protect machine mode things from user mode code) is not implemented.
They arrived just in time for longan season. :)
-
A story on the Longan Nano here, although I don't think there's any new info: https://www.cnx-software.com/2019/08/29/longan-nano-gd32v-risc-v-development-board-comes-with-lcd-display-and-enclosure/ (https://www.cnx-software.com/2019/08/29/longan-nano-gd32v-risc-v-development-board-comes-with-lcd-display-and-enclosure/)
And apparently the "Bumblebee" core is actually Andes N22. There's a story here: https://www.cnx-software.com/2019/08/28/andescore-n22-risc-v-core-rv32imac-rv32emac-instruction-sets/ (https://www.cnx-software.com/2019/08/28/andescore-n22-risc-v-core-rv32imac-rv32emac-instruction-sets/)
This story doesn't seem to quite match the Gigadevice/Sipeed docs, for example the Sipeed docs say that PMP (Physical Memory Protection .. basically a set of several base&bound registers so you can detect things such as stack overflow or protect machine mode things from user mode code) is not implemented.
I have sources in China that says gigadevice is using Nuclei RISC-V IP and not Andes. Look at https://www.riscv-mcu.com (https://www.riscv-mcu.com) , FPGA page refers to Nuclei.
-
Anyway, it's always nice to see new RISC-V entrants, but I personally don't care much for those small/borderline copycat MCUs (except for the core). Not my thing nor my needs at all. Of course they cover a significant market, just not mine.
I would like to see more of completely original, and a little more powerful RISC-V MCUs (such as the ones SiFive provides, but with more off-the-shelf variants).
The Kendryte initiative was pretty interesting. I got unfortunately disappointed with the lack of documentation and support.
What I would personally be interested in:
- Ultra-low power RISC-V MCUs. There are some that are reasonably low-power now, but still can't compete with ARM-Cortex-based ULP MCUs, and often by far,
- On the other end of the spectrum, beefier (but with still reasonable power consumption) ones, like in the 200-400 MHz range, and a sensible set of peripherals,
- And the absolute ideal: either of the above, but with additional reconfigurable logic blocks (such as a limited number of slices of a typical small FPGA)!
-
A story on the Longan Nano here, although I don't think there's any new info: https://www.cnx-software.com/2019/08/29/longan-nano-gd32v-risc-v-development-board-comes-with-lcd-display-and-enclosure/ (https://www.cnx-software.com/2019/08/29/longan-nano-gd32v-risc-v-development-board-comes-with-lcd-display-and-enclosure/)
And apparently the "Bumblebee" core is actually Andes N22. There's a story here: https://www.cnx-software.com/2019/08/28/andescore-n22-risc-v-core-rv32imac-rv32emac-instruction-sets/ (https://www.cnx-software.com/2019/08/28/andescore-n22-risc-v-core-rv32imac-rv32emac-instruction-sets/)
This story doesn't seem to quite match the Gigadevice/Sipeed docs, for example the Sipeed docs say that PMP (Physical Memory Protection .. basically a set of several base&bound registers so you can detect things such as stack overflow or protect machine mode things from user mode code) is not implemented.
I have sources in China that says gigadevice is using Nuclei RISC-V IP and not Andes. Look at https://www.riscv-mcu.com (https://www.riscv-mcu.com) , FPGA page refers to Nuclei.
It's right there in the datasheet P14:
"Note: The Bumblebee core used for this MCU is jointly developed by Nuclei System Technology
and Taiwanese Andes Technology, and Nuclei System Technology provides authorization and
technical support services.At present, Nuclei System Technology can license the mass-proven N200
series of ultra-low-power commercial processor cores, as well as research a variety of high
performance embedded processor series, and provide customers with customized services."
http://dl.sipeed.com/LONGAN/Nano/DOC/Bumblebee%20core%20intro_en.pdf (http://dl.sipeed.com/LONGAN/Nano/DOC/Bumblebee%20core%20intro_en.pdf)
-
I ordered a couple of longan nano board from aliexpress as soon as I saw that they were available. Let's see when they show up...
Regarding the sw, the longan ide installer seems to include platformio, the compiler (so no need to install it extra... ) I already have vs code installed... I just wonder what is lightweight about this vs code...
-
Note - although this works on PlatformIO - it doesn't work on a Mac. You'll need Windows.
I ordered my Longan nano withe little LCD for a fiver. It took a while to find out how to drive the LCD, I found this helped:
https://github.com/Kevin-Sangeelee/gd32v_test
-
A new toy :D It never stops.
https://www.seeedstudio.com/SeeedStudio-GD32-RISC-V-Dev-Board-p-4302.html (https://www.seeedstudio.com/SeeedStudio-GD32-RISC-V-Dev-Board-p-4302.html)
-
Oooh! new toys. But I've got to get my "Sipeed Longan Nano" running yet. I can connect to it using JLinkExe, but I haven't managed to get OpenOCD connecting to it.
-
Which probe are you using with OpenOCD? It works with JLink.
-
I have an J-Link EDU Mini, and it works with the Seggers JLinkExe tool. At least I've tested connecting, halting, resetting and dumping the flash.
The problem with OpenOCD is probably that I need to find out what configuration file I need. I'm using a git build from the official repository. I've been able to connect, and it reports it recognised 1 hart, but it doesn't reset/halt. And once I got the core working, I also need to figure out the flash.
-
hi folks
I received a few Lonan-Nano devices a few weeks ago.
I am using Linux, a text editor, Makefile and the installed DFU bootloader
The example code and firmware driver code is quite well laid out and
seems to have an examples for all the peripherals and a most of the
capabilites of the peripherals. The SDK seems to be Eclipse based
but that is not my cup of tea.
One thing that caught me out was that you need a modified 'dfu-util'
program to suppoet this chip (at least for Linux). See this fork
https://github.com/riscv-mcu/gd32-dfu-utils
I did a pin-toggle speed test and with some unravelling of the example
code 27 MHz can be done in a while loop with the default 108 MHz system
clock. (Might be possible to do 54 MHz but my inline assembly is not
doing it yet - should be just one line if it is possible)
ADC, DAC, USART, DMA, timer - so fae everything seem to work
At the moment I am having issues getting printf working properly. After
testing and some thought, I feel the problem is likely to be that I an idiot.
cheers
phil
-
I got my boards a few days ago. I did not order a specific programmer because I though with the JLink I could connect. My HW Version is 9.3 (I have the EDU version) and I updated to the latest software (6.56). When I try to connect via Jlink commander, I get a "this J-Link does not support RISCV over JTAG" and it outputs the following through the console:
TotalIRLen = 10, IRPrint = 0x0021
JTAG chain detection found 2 devices:
#0 Id: 0x1000563D, IRLen: 05, RV32
#1 Id: 0x790007A3, IRLen: 05, Unknown device
Debug architecture:
RISC-V debug: 0.13
AddrBits: 7
DataBits: 32
IdleClks: 7
Memory access:
Via system bus: No
Via ProgBuf: Yes (2 ProgBuf entries)
DataBuf: 4 entries
autoexec[0] implemented: Yes
Detected: RV32 core
CSR access via abs. commands: No
ConfigTargetSettings() start
ConfigTargetSettings() end
TotalIRLen = 10, IRPrint = 0x0021
JTAG chain detection found 2 devices:
#0 Id: 0x1000563D, IRLen: 05, RV32
#1 Id: 0x790007A3, IRLen: 05, Unknown device
Cannot connect to target.
It offers though two other variants SWD and cJTAG, via SWD says:
Device "GD32VF103CBT6" selected.
Connecting to target via SWD
ConfigTargetSettings() start
ConfigTargetSettings() end
ConfigTargetSettings() start
ConfigTargetSettings() end
ConfigTargetSettings() start
ConfigTargetSettings() end
ConfigTargetSettings() start
ConfigTargetSettings() end
Cannot connect to target.
J-Link>
Assuming the SWD is the same as in the ARM variant, SWDIO (pin 7 of the JLInk connector) should be connected to JTMS (on the target side) and SWCLK (pin 9) should be connected to (TCK on the target side).
cJTAG says:
Selected interface (cJTAG) is not supported by the connected probe.
@: GromBeestje
How did you get it to connect ?
-
Debug subsystem is not the "standard" sifive implementation, you I guess you need to use software provided by GD.
-
You need J-Link HW version 10+ unfortunately. I have the EDU 10.1 and use Segger Embedded Studio with good results.
-
"this J-Link does not support RISCV over JTAG"You need J-Link HW version 10+ unfortunately.
What? Why? I thought JTAG was JTAG, and it was only a matter of software whether you could program a given device?
-
What? Why? I thought JTAG was JTAG, and it was only a matter of software whether you could program a given device?
I don't konw about this specific case, but Segger really likes to hard-code device IDs into their firmware on limited versions of the hardware (like EDU, SAM-ICE).
-
Platformio lists the compatible programmers: https://docs.platformio.org/en/latest/boards/gd32v/sipeed-longan-nano.html#uploading
-
Have a look at https://riscv.org/specifications/debug-specification/
I tried GNU MCU Eclipse plugins and they didn't work all the time. The Segger setup works and is free and fast (except the edu) for non commercial use. The best is it works all the time. Downloading code can also be done via the GD32 DFU tool. I am sure over time there will be more support.
-
A new toy :D It never stops.
https://www.seeedstudio.com/SeeedStudio-GD32-RISC-V-Dev-Board-p-4302.html (https://www.seeedstudio.com/SeeedStudio-GD32-RISC-V-Dev-Board-p-4302.html)
He who dies with the most toys wins.
https://m5stack.com/collections/m5-core/products/stickv (https://m5stack.com/collections/m5-core/products/stickv)
-
Hello friends. I have the Microsoft VSCode and Platformio installed and running on Manjaro Linux (an Arch-based distro) and it runs fine and I can upload programs to the Longan Nano. I bought one from Amazon Prime and is has the 4x2 pin JTAG header pins populated on the board. Do the ones direct from seeed studio have these pins soldered on? The product photo just shows unpopulated solder pads.
If anyone is interested I took notes on how to set up the tool stack on Manjaro, it all works. Next to try is debugging with an Altera USB Blaster clone.
-
A new toy :D It never stops.
https://www.seeedstudio.com/SeeedStudio-GD32-RISC-V-Dev-Board-p-4302.html (https://www.seeedstudio.com/SeeedStudio-GD32-RISC-V-Dev-Board-p-4302.html)
He who dies with the most toys wins.
https://m5stack.com/collections/m5-core/products/stickv (https://m5stack.com/collections/m5-core/products/stickv)
That's why I've ordered both the new SparkFun RISC-V boards ... and their ESP32 board just to make the order up to enough to get free shipping...
-
"this J-Link does not support RISCV over JTAG"You need J-Link HW version 10+ unfortunately.
What? Why? I thought JTAG was JTAG, and it was only a matter of software whether you could program a given device?
Two options come to mind: The J-Link dongles are supposed to contain some smarts, which needs device-specific support. IIRC the MCU in the revision 10 is significantly more capable than in the previous version, so it's possible they just ran out of space. The more sinister possibility is forcing a wave of hardware upgrades ahead of the Next Big Thing.
-
"this J-Link does not support RISCV over JTAG"You need J-Link HW version 10+ unfortunately.
What? Why? I thought JTAG was JTAG, and it was only a matter of software whether you could program a given device?
Two options come to mind: The J-Link dongles are supposed to contain some smarts, which needs device-specific support. IIRC the MCU in the revision 10 is significantly more capable than in the previous version, so it's possible they just ran out of space. The more sinister possibility is forcing a wave of hardware upgrades ahead of the Next Big Thing.
J-Link is a rather deceptive name. It implies a single product when it was actually been a succession of products, several of which have obsoleted the previous ones for many users.
-
The list of compatible devices list the altera usb blaster, something I also have. I'll try with that and report back. If only this Platformio wouldn't what to install itself every time I run it...
-
The altera usb blaster didn't work either. In the mean time I ordered two of this sipeed rv debuggers and they showed up today.
After switching the driver from ftdi to winusb using Zadig, the adaptor was recognized and the chip programmed:
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/gd32v/sipeed-longan-nano.html
PLATFORM: GigaDevice GD32V 1.0.0 > Sipeed Longan Nano
HARDWARE: GD32VF103CBT6 108MHz, 32KB RAM, 128KB Flash
DEBUG: Current (sipeed-rv-debugger) External (altera-usb-blaster, gd-link, jlink, sipeed-rv-debugger, um232h)
PACKAGES: framework-gd32vf103-sdk 1.0.0, tool-openocd-gd32v 0.1.1, tool-gd32vflash 0.1.0, toolchain-gd32v 9.2.0
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 0 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Checking size .pio\build\sipeed-longan-nano\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
DATA: [= ] 7.0% (used 2300 bytes from 32768 bytes)
PROGRAM: [ ] 1.9% (used 2530 bytes from 131072 bytes)
Configuring upload protocol...
AVAILABLE: altera-usb-blaster, gd-link, jlink, serial, sipeed-rv-debugger, um232h
CURRENT: upload_protocol = sipeed-rv-debugger
Uploading .pio\build\sipeed-longan-nano\firmware.elf
GNU MCU Eclipse OpenOCD, 64-bitOpen On-Chip Debugger 0.10.0+dev-00593-g23ad80df4-dirty (2019-06-18-08:21)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Warn : Transport "jtag" was already selected
jtag
adapter speed: 1000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7)
Error: Trying to use configured scan chain anyway...
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 5 -expected-id 0x790007a3"
Warn : Bypassing JTAG setup events due to errors
Info : datacount=4 progbufsize=2
Info : Exposing additional CSR 3040
Info : Exposing additional CSR 3041
Info : Exposing additional CSR 3042
Info : Exposing additional CSR 3043
Info : Exposing additional CSR 3044
Info : Exposing additional CSR 3045
Info : Exposing additional CSR 3046
Info : Exposing additional CSR 3047
Info : Exposing additional CSR 3048
Info : Exposing additional CSR 3049
Info : Exposing additional CSR 3050
Info : Exposing additional CSR 3051
Info : Exposing additional CSR 3052
Info : Exposing additional CSR 3053
Info : Exposing additional CSR 3054
Info : Exposing additional CSR 3055
Info : Exposing additional CSR 3056
Info : Exposing additional CSR 3057
Info : Exposing additional CSR 3058
Info : Exposing additional CSR 3059
Info : Exposing additional CSR 3060
Info : Exposing additional CSR 3061
Info : Exposing additional CSR 3062
Info : Exposing additional CSR 3063
Info : Exposing additional CSR 3064
Info : Exposing additional CSR 3065
Info : Exposing additional CSR 3066
Info : Exposing additional CSR 3067
Info : Exposing additional CSR 3068
Info : Exposing additional CSR 3069
Info : Exposing additional CSR 3070
Info : Exposing additional CSR 3071
Info : Examined RISC-V core; found 1 harts
Info : hart 0: XLEN=32, misa=0x40901105
Info : Listening on port 3333 for gdb connections
Info : device id = 0x19060410
Info : flash_size_in_kb = 0x00000040
Info : flash size = 64kbytes
cleared protection for sectors 0 through 63 on flash bank 0
Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
** Programming Started **
auto erase enabled
wrote 3072 bytes from file .pio\build\sipeed-longan-nano\firmware.elf in 1.622513s (1.849 KiB/s)
** Programming Finished **
** Verify Started **
verified 2548 bytes in 0.176993s (14.059 KiB/s)
** Verified OK **
Info : Hart 0 unexpectedly reset!
Info : Note: Hart is halted due to the halt-on-reset bit is set,please continue your program by appropriate debugger commands or operations!!
The test code doesn't run but at least, it programmed :).
-
I have one of the Sipeed RV debuggers too. You can also with a spare Sipeed Longan Nano board, burn the firmware so it becomes a debugger for other Longan Nano boards, using the JTAG header already on the board. Just need a ribbon cable to connect the two. That method is supported by PlatformIO too for the Longan Nano board.
-
here is link of datasheet (http://dl.sipeed.com/LONGAN/Nano/DOC/) and SDK (http://dl.sipeed.com/LONGAN/Nano/SDK/)
Bumblebee_Core_Doc (https://github.com/nucleisys/Bumblebee_Core_Doc)
GD32VF103_User_Manual_EN_V1.0.pdf (http://GD32VF103_User_Manual_EN_V1.0.pdf)
GD32VF103_Datasheet_Rev1.0.pdf (http://dl.sipeed.com/LONGAN/Nano/DOC/GD32VF103_Datasheet_Rev1.0.pdf)
Literature package for GD32VF103: https://sourceforge.net/projects/mecrisp/files/Target%20literature%20package%20for%20GD32VF103.tar.gz (25.0 MB)
├── Bumblebee\ Core\ Architecture\ Manual.pdf
├── Bumblebee\ Core\ Brief\ Manual.pdf
├── GD32VF103C-START-V1.0.pdf
├── GD32VF103_Datasheet_Rev\ 1.1.pdf
├── GD32VF103_User_Manual_EN_V1.2.pdf
├── Longan\ Nano\ Pinout.png
├── Longan\ Nano\ Pinout.svg
├── Longan\ nano\ 2663(Assembly\ drawing).pdf
├── Longan\ nano\ 2663(Schematic).pdf
├── RISCVGreenCardv8-20151013.pdf
├── STM32F103\ Reference\ Manual.pdf
├── STM32F103.pdf
├── riscv-privileged-20190608-1.pdf
├── riscv-spec.pdf
└── tool-gd32vflash-v0.1.0-linux.tar.gz
-
https://www.cnx-software.com/2019/08/23/gigadevice-gd32v-risc-v-mcu-development-board/amp/ (https://www.cnx-software.com/2019/08/23/gigadevice-gd32v-risc-v-mcu-development-board/amp/)
The new GD32VF103 series RISC-V MCU family features 14 models with the following key specifications:
Core – GD32VF103 RISC-V “Bumblebee Core” @ 108 MHz
Memory – 8KB to 16KB SRAM
Storage – 16KB to 128KB flash
Peripherals – USB OTG and CAN 2.0B
I/O – 3.3V, 5V tolerant
Supply Voltage – 2.6 to 3.6V
Package – QFN36, LQFP48, LQFP64, and LQFP100 packages
May be pin compatible with STM32F100 series.
As many now know, GD have made their own STM32F10x 'compatible' peripherals and the pinouts of the 64 pin flatpack are compatible between GD and STM.
I've made up a (ongoing) page comparing the peripherals of two chips and some other details : https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32f103-vs-gd32vf103.html (https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32f103-vs-gd32vf103.html)
One current issue I'm trying to resolve is resetting the peripherals to default with a software command.
I can find no reference to SYSRESETREQ in the GD literature other than the reset-logic pic in the GD32VF103 User Manual V1.2 PDF which I suspect is just paste from the GD32F103 PDF. What this means is there seems to be no simple way to reset all the GD32VF103 peripherals to power-up-defaults as can be done on STM32.
This is achieved in the GD32VF103 sample factory code using a long list of individual peripheral register resets but I'm after a simple method as with the STM32F10x.
Does anyone have any experience with this issue and the GD32VF103 ?
-
A system reset
is generated by the following events:
A power reset (POWER_RSTn).
An external pin reset (NRST).
A window watchdog timer reset (WWDGT_RSTn).
A free watchdog timer reset (FWDGT_RSTn).
The SYSRESETREQ bit in RISC-V Application Interrupt and Reset Control Register is set (SW_RSTn).
Reset generated when entering Standby mode when resetting nRST_STDBY bit in User Option Bytes (OB_STDBY_RSTn).
Reset generated when entering Deep-sleep mode when resetting nRST_DPSLP bit in User Option Bytes (OB_DPSLP_RSTn).
A system reset resets the processor core and peripheral IP components except for the JTAG
controller and the Backup domain.
Page 61 GD32VF103_User_Manual_EN_V1.2 from https://gd32mcu.21ic.com/en/index
I hope this helps.
-
Have someone made any progress on linux, with platformio and a spipeed-rv-debugger ?. I have the latest packages from platform io (1.1.2) fot the gigadevices chips but still no dice regarding programming. Maybe the example code doesn't work. Here what I get in the console after "upload":
Processing sipeed-longan-nano (platform: gd32v; framework: gd32vf103-sdk; board: sipeed-longan-nano)
------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: [url]https://docs.platformio.org/page/boards/gd32v/sipeed-longan-nano.html[/url]
PLATFORM: GigaDevice GD32V 1.1.2 > Sipeed Longan Nano
HARDWARE: GD32VF103CBT6 108MHz, 32KB RAM, 128KB Flash
DEBUG: Current (sipeed-rv-debugger) External (altera-usb-blaster, gd-link, jlink, rv-link, sipeed-rv-debugger, um232h)
PACKAGES: framework-gd32vf103-sdk 1.0.0, tool-openocd-gd32v 0.1.1, tool-gd32vflash 0.1.0, toolchain-gd32v 9.2.0
LDF: Library Dependency Finder -> [url]http://bit.ly/configure-pio-ldf[/url]
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 0 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Checking size .pio/build/sipeed-longan-nano/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
DATA: [= ] 7.0% (used 2310 bytes from 32768 bytes)
PROGRAM: [= ] 5.0% (used 6572 bytes from 131072 bytes)
Configuring upload protocol...
AVAILABLE: altera-usb-blaster, gd-link, jlink, rv-link, serial, sipeed-rv-debugger, um232h
CURRENT: upload_protocol = sipeed-rv-debugger
Uploading .pio/build/sipeed-longan-nano/firmware.elf
Open On-Chip Debugger 0.10.0+dev-00911-gcfbca74bd (2019-09-12-09:31)
Licensed under GNU GPL v2
For bug reports, read
[url]http://openocd.org/doc/doxygen/bugs.html[/url]
Warn : Transport "jtag" was already selected
jtag
adapter speed: 1000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)
Warn : JTAG tap: riscv.cpu UNEXPECTED: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)
Error: JTAG tap: riscv.cpu expected 1 of 1: 0x1e200a6d (mfg: 0x536 (Nuclei System Technology Co.,Ltd.), part: 0xe200, ver: 0x1)
Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7)
Error: Trying to use configured scan chain anyway...
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 5 -expected-id 0x790007a3"
Warn : Bypassing JTAG setup events due to errors
Info : datacount=4 progbufsize=2
Info : Exposing additional CSR 3040
Info : Exposing additional CSR 3041
Info : Exposing additional CSR 3042
Info : Exposing additional CSR 3043
Info : Exposing additional CSR 3044
Info : Exposing additional CSR 3045
Info : Exposing additional CSR 3046
Info : Exposing additional CSR 3047
Info : Exposing additional CSR 3048
Info : Exposing additional CSR 3049
Info : Exposing additional CSR 3050
Info : Exposing additional CSR 3051
Info : Exposing additional CSR 3052
Info : Exposing additional CSR 3053
Info : Exposing additional CSR 3054
Info : Exposing additional CSR 3055
Info : Exposing additional CSR 3056
Info : Exposing additional CSR 3057
Info : Exposing additional CSR 3058
Info : Exposing additional CSR 3059
Info : Exposing additional CSR 3060
Info : Exposing additional CSR 3061
Info : Exposing additional CSR 3062
Info : Exposing additional CSR 3063
Info : Exposing additional CSR 3064
Info : Exposing additional CSR 3065
Info : Exposing additional CSR 3066
Info : Exposing additional CSR 3067
Info : Exposing additional CSR 3068
Info : Exposing additional CSR 3069
Info : Exposing additional CSR 3070
Info : Exposing additional CSR 3071
Info : Examined RISC-V core; found 1 harts
Info : hart 0: XLEN=32, misa=0x40901105
Info : Listening on port 3333 for gdb connections
Info : device id = 0x19060410
Info : flash_size_in_kb = 0x00000040
Info : flash size = 64kbytes
Info : JTAG tap: riscv.cpu tap/device found: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)
Warn : JTAG tap: riscv.cpu UNEXPECTED: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)
Error: JTAG tap: riscv.cpu expected 1 of 1: 0x1e200a6d (mfg: 0x536 (Nuclei System Technology Co.,Ltd.), part: 0xe200, ver: 0x1)
Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
Info : Hart 0 unexpectedly reset!
*** [upload] Error 1
============================ [FAILED] Took 3.07 seconds ============================
And the blinky doesn't blink.
(Note: On another computer, with another longan nano, with a jlink 10.1, with embedded studio for RISCV, blinky works).
I'll try my board on segger's IDE with a Jlink 10.1.
-
:palm: I found the problem(s):
The devices I have have the GD32F103C8T6. Advertised where GD32VF108CBT6. Note the number eight after the C and the letter B. The '8' means 64 kBytes Flash and 20 kBytes RAM. The 'B' means 128 kBytes Flash and 32 kBytes RAM.
With the Segger Studio, changing between the two is not a problem two executable files will be generated with different RAM sizes, each works on the correct device (I got a CB board for testing purposes).
On the PlatformIO side, I can choose the device, compile and upload seem to work but I still get the exception... more digging is necessary.
-
Hi guys,
For those who want to get started with the GD32VF103 chip in the most simplest way, have a look at my github repo: https://github.com/lundmar/riscv-gd32vf103-demo
This is the first time I get hands on with a RISC-V chip and I was curious to see how it compares to ARM, in particular concerning the required boot code. I've created a demo software that includes the simplest possible boot code to get a single threaded system running including the Newlib C library and the GD32VF103 driver library.
Simply install the appropriate RISC-V toolchain via crosstool-ng and you will be able to compile the demo software.
-
For those who want to get started with the GD32VF103 chip in the most simplest way, have a look at my github repo: https://github.com/lundmar/riscv-gd32vf103-demo
Looks good!
My only quibble is that both your readme and the makefile say rv32ima while the Bumblebee core actually implements rv32imac. That will work fine, but you're missing out on saving typically 25% to 30% in program size (i.e. getting 35% to 40% more program code into a ROM of a given size) by using the optional 16 bit "C" opcodes.
I also dislike overly-abstracted code, so it's great to have this and I'll try it on my Longan Nano soon. But I have an ATtiny85 project to do first :-)
-
For those who want to get started with the GD32VF103 chip in the most simplest way, have a look at my github repo: https://github.com/lundmar/riscv-gd32vf103-demo
Looks good!
My only quibble is that both your readme and the makefile say rv32ima while the Bumblebee core actually implements rv32imac. That will work fine, but you're missing out on saving typically 25% to 30% in program size (i.e. getting 35% to 40% more program code into a ROM of a given size) by using the optional 16 bit "C" opcodes.
I also dislike overly-abstracted code, so it's great to have this and I'll try it on my Longan Nano soon. But I have an ATtiny85 project to do first :-)
My good sir, you are of course correct. I will not tolerate such quibbles on your mind! :)
Let's go full feature and use the compressed ISA instead - I have updated the repository and the binary output file is now precisely 13.8% smaller (.text size went down 14.7%).
The only reason I left it at "ima" was that I wanted the pure 32-bit experience for my first meet with the RISC-V ISA :)
Also, my own quibbles or disappointment with the GD32VF103 aka Bumblebee core is that it does not implement mtvec.mode = 0x3 which allows for the vector table to be implemented in pure C by pointer functions (hw will jump to addresses instead of executing jump instructions), in the same way many cortex-M does it. This is an optional feature of the RISC-V standard and I believe that RISC-V chips such as the SiFive one implements it. You may notice that I have left code implementation for both ways.
-
Let's go full feature and use the compressed ISA instead - I have updated the repository and the binary output file is now precisely 13.8% smaller (.text size went down 14.7%).
I'm guessing this program is sooo small it's dominated by the table of interrupt vectors.
The only reason I left it at "ima" was that I wanted the pure 32-bit experience for my first meet with the RISC-V ISA :)
A perfectly good reason.
Also, my own quibbles or disappointment with the GD32VF103 aka Bumblebee core is that it does not implement mtvec.mode = 0x3 which allows for the vector table to be implemented in pure C by pointer functions (hw will jump to addresses instead of executing jump instructions), in the same way many cortex-M does it. This is an optional feature of the RISC-V standard and I believe that RISC-V chips such as the SiFive one implements it. You may notice that I have left code implementation for both ways.
Meh. Jump instructions as interrupt/trap vectors saves a fair bit of complexity in the implementation, especially on something that doesn't otherwise have an indirect addressing mode (as RISCs don't). And it works fine as long as you can put all the service routines within 1 MB of the vector table.
I tend to prefer using a single handler function that does the bookkeeping such as saving registers inline and then uses a regular C switch or table of function pointers to choose the handler. You can also preprocess the trap number to avoid having a few dozen pointers to the default "wtf?" handler.
It makes very little difference in speed either way.
-
Is the interrupt mechanism considered part of the ISA, or part of the implementation for a RISC-V processor?I guess for ARM Cortex the NVIC is considered part of the core that is external to the CPU, but they seem sometimes-depressingly tightly coupled and non-RISCy.
-
Is the interrupt mechanism considered part of the ISA, or part of the implementation for a RISC-V processor?I guess for ARM Cortex the NVIC is considered part of the core that is external to the CPU, but they seem sometimes-depressingly tightly coupled and non-RISCy.
I'll say "part of the ISA, but optional".
The standard privileged architecture specifies a basic interrupt handler that must be present, though it has optional features. Each privilege level that supports handling interrupts (M, S if it exists, U if it exists and the "N" extension is implemented) has a set of interrupt registers including the PC to return to, the exception cause, the exception data, and exception handler base address.
The exception handler base address is constrained to be a multiple of 4, and the bottom two bits indicate the mode. Mode 00 means all exceptions go to a single handler located at baseAddress. Mode 01 means synchronous exceptions (system call, illegal instruction, illegal memory access etc) go to baseAddress while interrupts go to baseAddress plus 4 * interrupt number, where you will normally put a jump instruction to the actual handler. Modes 10 and 11 are reserved.
An implementation can choose to support only mode 00, only mode 01, or both modes. An implementation can choose to use a fixed base address, or allow the user to set it. As usual in RISC-V you find the capabilities by trying to write what you want to the CSR then read it back and see if you get back the same thing you tried to write.
The proposed "Fast interrupts extension" aka CLIC (Core Local Interrupt Controller) uses mode 11. This mode loads a pointer to the handler from baseAddress plus 4 * interrupt number or 8 * interrupt number (64 bit systems). Another mechanism allows to specify (with a bitmap) for each interrupt individually whether it will use its own vector or a common handler at interrupt vector 0.
There is a whole lot more detail, far too much to go into here. If interested then read the specifications on github :-)
Embedded software might be written to expect and need one particular interrupt controller mode. The Linux kernel will I believe work fine as long as at least one of modes 00, 01, or 11 is implemented.
The very simplest implementations can support a single exception handler function at at fixed address (0, for example), and call themselves compatible with the RISC-V Privileged ISA, and things will work. The Linux kernel for example can discover that only mode 00 is supported, and can read back the fixed interrupt handler address from the CSR. Supporting higher modes can require a bit more hardware but provide higher performance.
-
Hi all,
I have die pictures of the GD32VF103 for you:
https://richis-lab.de/STM32_10.htm (https://richis-lab.de/STM32_10.htm)
(https://richis-lab.de/images/STM32/15_03.jpg)
There also is a flash die on top of the controller.
It´s similar but smaller than the flash in the GD32F103:
https://richis-lab.de/STM32_06.htm (https://richis-lab.de/STM32_06.htm)
I assume they put the kind of flash die in the package they have around at this time.
(https://richis-lab.de/images/STM32/15_05.jpg)
"CHICAGO"? :-//
(https://richis-lab.de/images/STM32/15_06.jpg)
POWER! MORE POWER! ;D
:popcorn:
-
I was wondering about this. That means that executes from RAM the same way the GS32F103 does. Now we need some benchmarks !! And a way to unlock the extra SRAM.
Danke Noopy !
-
Has anyone ever succeeded unlocking any RAM in the GD32F10x? Back in the day there was some speculation, but I've never seen a continuation of this.
-
I have been wondering a while about this flash/sram concept that the GD32VF103 seems to use. Starting with the blinky test created by platformio, I modified the code to test the throughput of the processor.
At least for code around ~1024 bytes, there seems to be no penalties, what makes me think that maybe the code is really loaded into SRAM, I mean, the whole code. That could only be tested with a larger function. I saw in one of the threads about the GD32F103 that the flash is loaded into a cache. So you see the load process when a new cache line has to be filled. I do not see this here, yeah, the code is a bit simple. In a x86, similar code exposes the memory architecture thus I tried a similar approach here...
RiscV GD32VF103 Instruction throughput tests:
GPIOC 13 LED, test pin
CPU Clock 108 MHz (default setting). 9.52 ns/clock
Code
static void __attribute__((noinline, naked)) main_loop_15MHz( void )
{
asm volatile(
" lui a5, 0x40011 \n\t" // GPIOC
" addi a3, a5, 16 \n\t"
" lui a4, 0x2 \n\t"
"1: \n\t"
" sw a4, 20(a5) \n\t"
" addi a3, a5, 16 \n\t"
" sw a4, 16(a5) \n\t"
" addi a3, a5, 16 \n\t"
" j 1b \n\t"
);
}
Tek0000.csv
Signal freqnecy 15.49 MHz
High width 47.20 ns - 2 opcodes + jump
Low width 17.68 ns - 2 opcodes
trying to match the jump width
------------------------------
30 ns ~ 3 clocks at 108 Mhz
static void __attribute__((noinline, naked)) main_loop_10MHz( void )
{
asm volatile(
" lui a5, 0x40011 \n\t" // GPIOC
" addi a3, a5, 16 \n\t"
" lui a4, 0x2 \n\t"
"1: \n\t"
" sw a4, 20(a5) \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" sw a4, 16(a5) \n\t"
" addi a3, a5, 16 \n\t"
" j 1b \n\t"
);
}
Match !
Tek0001.csv
Signal freqnecy 10.89 MHz
High width 46.9 ns - 2 opcodes + jump
Low width 45.8 ns - 2 opcodes
The low pulse is consistently 1 ns shorter as the high pulse
The addi opcodes are 32 bit opcodes, it seems that there is no
difference between the width of the opcodes and the execution
time. Using the same target register seems to not impose
any penalties.
Check for chache line size, go for > 64 byte code
-------------------------------------------------
static void __attribute__((noinline, naked)) main_loop( void )
{
asm volatile(
" lui a5, 0x40011 \n\t" // GPIOC
" addi a3, a5, 16 \n\t"
" lui a4, 0x2 \n\t"
"1: \n\t"
" sw a4, 20(a5) \n\t" // low
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" sw a4, 16(a5) \n\t" // high
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" j 1b \n\t"
);
}
Tek0002.csv
Signal freqnecy 4.156 MHz
High width 121.2 ns - 11 opcodes + jump (+2) // 9.32 ns/opcode
Low width 120.7 ns - 13 opcodes = ~ 9.28 ns/opcode
No cache line fill detected
Try longer code > 128 bytes
---------------------------
static void __attribute__((noinline, naked)) main_loop( void )
{
asm volatile(
" lui a5, 0x40011 \n\t" // GPIOC
" addi a3, a5, 16 \n\t"
" lui a4, 0x2 \n\t"
"1: \n\t"
" sw a4, 20(a5) \n\t" // low
" addi a3, a5, 16 \n\t" // 44 times !
" sw a4, 16(a5) \n\t" // high
" addi a3, a5, 16 \n\t" // 42 times
" j 1b \n\t"
);
}
Tek0003.csv
44e - 2f6 = 344 bytes
Signal freqnecy 1.200 MHz
High width 417.6 ns - 43 opcodes + jump (+2) // 9.28 ns/opcode
Low width 415.8 ns - 45 opcodes = ~ 9,24 ns/opcode
Try longer code > 1024 bytes
---------------------------
static void __attribute__((noinline, naked)) main_loop( void )
{
asm volatile(
" lui a5, 0x40011 \n\t" // GPIOC
" addi a3, a5, 16 \n\t"
" lui a4, 0x2 \n\t"
"1: \n\t"
" sw a4, 20(a5) \n\t" // low
" addi a3, a5, 16 \n\t" // ** 172 times !
" sw a4, 16(a5) \n\t" // high
" addi a3, a5, 16 \n\t" // ** 170 times
" j 1b \n\t"
);
}
Tek0004.csv
84e - 2f6 = 1368 bytes
Signal freqnecy 312.2 kHz
High width 1602 ns - 171 opcodes + jump (+2) // 9.28 ns/opcode
Low width 1601 ns - 173 opcodes = ~ 9,25 ns/opcode
The Binky code is then:
/*!
\file main.c
\brief running led
\version 2019-6-5, V1.0.0, firmware for GD32VF103
*/
/*
Copyright (c) 2019, GigaDevice Semiconductor Inc.
Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its contributors
may be used to endorse or promote products derived from this software without
specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE.
*/
#include "gd32vf103.h"
#include "systick.h"
#include <stdio.h>
/* BUILTIN LED OF LONGAN BOARDS IS PIN PC13 */
#define LED_PIN GPIO_PIN_13
#define LED_GPIO_PORT GPIOC
#define LED_GPIO_CLK RCU_GPIOC
static void main_loop( void );
void longan_led_init()
{
/* enable the led clock */
rcu_periph_clock_enable(RCU_GPIOA);
/* configure led GPIO port */
gpio_init(GPIOA, GPIO_MODE_OUT_PP, GPIO_OSPEED_50MHZ, GPIO_PIN_1);
GPIO_BC(GPIOA) = GPIO_PIN_1;
gpio_init(GPIOA, GPIO_MODE_OUT_PP, GPIO_OSPEED_50MHZ, GPIO_PIN_2);
GPIO_BC(GPIOA) = GPIO_PIN_2;
/* enable the led clock */
rcu_periph_clock_enable(LED_GPIO_CLK);
/* configure led GPIO port */
gpio_init(LED_GPIO_PORT, GPIO_MODE_OUT_PP, GPIO_OSPEED_50MHZ, LED_PIN);
GPIO_BC(LED_GPIO_PORT) = LED_PIN;
}
void longan_led_on()
{
GPIO_BOP(LED_GPIO_PORT) = LED_PIN;
}
void longan_led_off()
{
GPIO_BC(LED_GPIO_PORT) = LED_PIN;
}
/*!
\brief main function
\param[in] none
\param[out] none
\retval none
*/
int main(void)
{
longan_led_init();
main_loop();
}
// and here paste one of the main_loop functions
[code]
-
Interesting investigation, thanks!
I've got a few Longan Nano boards (at $4.90 each plus $50 shipping might as well get more than one) but didn't find a chance to play with them yet.
You're never going to detect cache lines by making the code bigger than a cache line -- you have to make it bigger than the entire cache.
However, the datasheet...
https://dl.sipeed.com/LONGAN/Nano/DOC/GD32VF103_Datasheet_Rev1.0.pdf
... says it read program code directly from flash with no wait states.
That's probably what limits it to 108 MHz. I'm sure the rest of it could go faster.
Interesting that it seems every taken branch uses 3 clock cycles i.e. a pipeline flush.
So, no cache, no branch prediction.
Sadly there is no information about instruction timing in the datasheet.
If would be interesting to see if a conditional branch for the loop takes the same time as the Jump. The timing on JALR (e.g. function return) would also be interesting. Are shift all single-cycle regardless of the shift count?
-
May be the wording on my part was poorly selected. You are right, of course.
What the datasheet says, regarding the flash can be ignored. We know it is being serially loaded. The question I wanted answered was if the whole flash gets mirrored or not. And if not how big is the "cache". It seems to be bigger than 8 kBytes. The code crosses now the first 4 kbytes boundary and doesn't seem to expose any loading latency (I extended the function to ~ 3.4 kBytes and crosses the 4 kbytes boundary. Most probably it is loaded completely. That means that there are some "hidden" registers that make the mirror SRAM writable. And some hidden ROM too. It would have been nice to see to which pins the flash was connected to guess on the interface type, the EXTI doesn't support serial memories. Now that I think of it, it doesn't support QPI either, so it is probably just SPI.
-
What the datasheet says, regarding the flash can be ignored. We know it is being serially loaded.
How do we know it is being serially loaded?
The datasheet says there is an AHB bus to the flash. In fact it says there are two AHB ports to the flash, one for the address, one for the data. All the other peripherals, including the main SRAM memory are on a 3rd "system" AHB bus.
Why do you think they are lying?
-
I suggest you read up on "Parallel NOR Flash". For example https://www.cypress.com/file/202491/download (https://www.cypress.com/file/202491/download)
I see the sequential access time there is 9 ns. What's the clock cycle time on the GD32VF103? 9 ns. Interesting.
Note that the main business of GigaDevice is making and selling flash memory. Microcontrollers are somewhat of a side-line. I'm sure they can make flash as well as Cypress can.
-
So, there is 128k of program memory, right? That's 1 M bits. Likely arranged in a 1024x1024 array, with a 1024 bit (128 byte) row buffer. Say it takes 18 ns to read a row into the buffer but then 9 ns to read something else from the same row. And the bus back to the CPU is 32 bits wide.
If you're running code sequentially, or even jumping around in the same 128 bytes then you get 9 ns access.
When you cross or jump to a new row (whether random or sequential) you get a 18 ns access instead of 9 ns.
So your test with 345 instructions and 1376 bytes in the loop is going to cross row boundaries 10 times, plus the jump. So 334 instructions will take 9 ns and 11 instructions will take 18 ns. Total 3204 ns or 9.287 ns per instruction on average.
3204 ns per loop is 1e9/3204 = 312.11kHz.
Is that compatible with what you're seeing?
YES
-
I understand what you mean, but, if you look at the picture Noopy posted, most likely a flash, like in the GD32F103, is in an extra die that only has 10 pins. Meaning, even with a hyperbus or similar you are several clocks away from 32 bits of data.
If they had flash on die then what you say would apply, no discussion. Before Noopy posted the picture I thought we had a flash on die.
Let's say I'm mistaken, I have another idea: the RiscV core used has instructions and cycle counters.
Let's extend the test and use these counters. This is getting very interesting !
Edit:
Something with the counters doesn't seem to work, I read the same values before and after some instructions:
I get 0x00003171 for the cycles counter and 0x000021B0 for the instret counter, both times.
static void __attribute__((noinline, naked)) main_loop( uint32_t *countersptr )
{
asm volatile(
" rdcycle a5 \n\t"
" sw a5, 0(a0) \n\t"
" rdinstret a5 \n\t"
" sw a5, 4(a0) \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" rdcycle a5 \n\t"
" sw a5, 20(a0) \n\t"
" rdinstret a5 \n\t"
" sw a5, 24(a0) \n\t"
" lui a5, 0x40011 \n\t" // GPIOC
" addi a3, a5, 16 \n\t"
" lui a4, 0x2 \n\t"
"1: \n\t"
" sw a4, 20(a5) \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" addi a3, a5, 16 \n\t"
" sw a4, 16(a5) \n\t"
" addi a3, a5, 16 \n\t"
" j 1b \n\t"
);
}
Edit: The simple solution seems to fail. The counters are disabled.
After enabling the counters I get:
There are 35 instructions between both rdcycle and rdinstret.
Cycles before 0x4769, after 0x478e, diff : 37
Intructions retired before 0x32ba, after 0x32de, diff : 36
The last store word doesn't get count.
I think that it executes from some very fast memory without any wait states. (unless they do not count as cycles, what seems improbable given previous tests).
@brucehoult: What do you think ?
-
Hmm .. ok I've found some better pics of GD32F103 with ARM and it really does look like it's got 128k of SRAM to copy the flash into and 20k of SRAM for the program to use.
Nuts!
I guess technically the "Flash Memory Controller" box could contain 128k of SRAM.
The DG32VF103 start up time from reset is 132 ms, and 118.8 ms to wake from 7 uA standby mode. Wake from "deep sleep" 400 uA mode is 6 us. So that's almost 15000 times longer from standby mode. And 60x lower power consumption. Only "backup registers" are retained in standby mode, CPU registers and SRAM contents are lost.
That 118.8 ms to wake is enough time to copy 128k of flash to SRAM at 1.11 MB/sec, 8.8 Mbps. One byte every 900 ns. One bit every 112.5 ns. Even stupidly cheap flash is faster than that. The external SPI flash on the HiFive1 can run at 133 MHz doing 4 bits per cycle (QSPI), or 66 MB/sec.
For comparison, an STM32F103 wakes up from stop 13 uA mode in 5 us, and from standby 2 uA mode in 50 us. So it comes out of the lowest power consumption mode over 2000 times faster.
I seem to recall AVRs have similar wakeup times to the STM chip.
So yeah, ok, call me convinced.
-
Yup, those were some of my points as well. Crazy start up and wake up times, not that great in terms of power consumption either.
But yeah this flash chip+SRAM solution is likely considerably cheaper. They just stack a very low cost flash chip (hence why it's likely so slow) die on their MCU die. It's likely not even QSPI. Integrating flash memory directly on the same die, and being able to run from it at a reasonable speed would be a lot more expensive.
All in all, it seems there aren't any RISC-V-based MCUs on the market yet that can really compete with existing ARM-based MCUs, at least for a number of key factors such as power consumption/efficiency of low-power modes/etc.
That's too bad, since due to the simplicity of RISC-V, there's clear potential to design MCUs that are even lower power (possibly by a large margin) than their ARM "counterparts". But I haven't seen such an MCU yet on the market.
-
I tried your code on the HiFive1 with the following modifications:
Used...
" csrr a5, mcycle \n\t"
" sw a5, 0(a0) \n\t"
" csrr a5, minstret \n\t"
" sw a5, 4(a0) \n\t"
... instead of rdcycle and rdinstret because the FE310-G000 doesn't support those user mode instructions.
Added a "ret" before your infinite loop.
Added a main
int main()
{
uint32_t counts[7];
printf("Starting\n", 13);
for (int i=0; i<5; ++i){
main_loop(counts);
printf("ins=%d cycles=%d\n", counts[6]-counts[1], counts[5]-counts[0]);
}
printf("Done\n");
return 0;
}
The results are:
02:55:57.864 -> core freq at 259004825 Hz
02:56:57.864 -> Starting
02:56:57.864 -> ins=36 cycles=18516
02:56:57.864 -> ins=36 cycles=40
02:56:57.864 -> ins=36 cycles=40
02:56:57.864 -> ins=36 cycles=40
02:56:57.864 -> ins=36 cycles=40
02:56:57.864 -> Done
02:56:57.864 ->
02:56:57.864 -> Progam has exited with code:0x00000000
You can see that on the first execution it takes quite some time to load the code from SPI flash into the instruction cache.
-
Changing the csr reading to...
" csrr a5, mcycle \n\t"
" csrr a6, minstret \n\t"
" sw a5, 0(a0) \n\t"
" sw a6, 4(a0) \n\t"
... drops the cycles from 40 to 37.
-
Now, I'd like to know how the flash gets loaded into SRAM. From the skinny description of the FMC registers, it doesn't look promising, probably some key opens some more registers.
The wait states register doesn't seem to make any difference in the execution time from SRAM, so I don't really know what it means.
-
Hmm .. ok I've found some better pics of GD32F103 with ARM and it really does look like it's got 128k of SRAM to copy the flash into and 20k of SRAM for the program to use.
Nuts!
I guess technically the "Flash Memory Controller" box could contain 128k of SRAM.
The DG32VF103 start up time from reset is 132 ms, and 118.8 ms to wake from 7 uA standby mode. Wake from "deep sleep" 400 uA mode is 6 us. So that's almost 15000 times longer from standby mode. And 60x lower power consumption. Only "backup registers" are retained in standby mode, CPU registers and SRAM contents are lost.
Yes, certainly specs like a Boot-From-Flash design.
There are a few of reasons to do this
* Mask sets and process are much cheaper, so for a development part, this can make sense (easier sign off from bean counters)
* It can allow a Higher MHz operation, as SRAM is faster than FLASH (but needs a lot more die area, so much larger memory could prove an issue )
The way it is spec'd, they could flip to a FLASH part in the future.
Maybe they gauge the market to see if MHz matters more ? - I see ARM family go up to 2048k Flash, which is too large for a on chip SRAM solution.
-
Finally received my Longan Nano boards. These have the "B" variety CPU.
-
Still no supported Mac toolchain :-(
-
Still no supported Mac toolchain :-(
OMG. Thanks for pointing it out!
[attachimg=1]
-
I had trouble building https://github.com/riscv-mcu/riscv-openocd (https://github.com/riscv-mcu/riscv-openocd)
So I cloned "mainline" riscv-openocd and backported GD32VF103 flash support: https://github.com/ZL2WRW/riscv-openocd (https://github.com/ZL2WRW/riscv-openocd)
I've got a pull request in process to include my changes into riscv-openocd: https://github.com/riscv/riscv-openocd/pull/518 (https://github.com/riscv/riscv-openocd/pull/518)
Hopefully this is useful to you.