datasheet for the GD32F450 series can be found here – https://www.google.com/search?q=GD32F450VET6+datasheet
it has BOOT0, names that all look familiar… format of the datasheet looks familiar… pricing is off-the-wall insane, and the amount of SRAM: 256 or 512k: they can actually go up to 3Mb of NAND, which is nuts.
I bought several GD32F103C boards, but I found that they were not 100% code compatible with STM32, so I gave up trying to use and suppirt them about 6 months ago.
GD just license the CPU core from ARM and made their own interpretation of the STM32 MCU, but with various changes.
( I recall seeing a big list of minor differences discussed on a Russian language site, ages ago)
BTW
I know that GD chips are used a lot in Russia as they come direct from China and are not subject to any US / EU embargo’s on Russia.
But, you could not build a STM32 compatible board using them.
PS. There are also licensing issues using STM’s HAL and SPL with GD devices
Other than the ones that Roger found a while back, I haven’t actually seen any.
Is the unit price of the GD32 significantly lower than its STM counterpart?
As well as having faster clock speeds, the GD32 parts tend to have larger flash with zero wait states, as GD appears to be a flash fab, so presumably they have the expertise in that field.
https://www.bunniestudios.com/blog/?p=3554
so as it turns out every SD card has an mcu in there
my guess is that it probably isn’t too surprising that some of these mcu on SD cards are after all ARM devices, and for that matter the same SD manufacturers may have the incentive to enhance and make those mcus and sell them alone after all
the main thing about complex semiconductors is the rather high capital costs from design to running a production line
all it takes is to have inadequate demand to lose billions of $
it is ‘impossible’ to design and make just 1 piece, and if you make a million pieces and sell only 10% of that it is literally good luck to recover all that costs
Those devices are fairly impressive in their ability to run stm binaries. But their internal construction is murky. I heard that those devices actually run off of serial ram.
With stm ebk offering, not sure how much appeal the gd equivalent has.
At the end of the day, you can’t run STM binary. You can use most source code, but as soon as anything deals with any peripheral, you have to review the datasheet and what are doing in your code so it still runs.
It’s probably fine for someone wanting to start from scratch developing with their sources, but not a straight transplant from STM to them.
Their speed is still pretty good, and as you said it seems to copy FLASH to RAM on bootup and run from RAM.
I think Roger or Rick may have posted some drystones/whetstone numbers in the relevant thread.
But then you also must consider STM mcus can be easily overclocked. Is an STM overclocked more or less reliable than a GD within their specs?
they can’t run stm binaries,
Sounds like a more accurate statement would be that they can’t run SOME stm binaries,
I have seen stm binaries being uploaded to gd and running just fine there.
Granted I didn’t investigate more but it doesn’t sound right to say That no stm binary can run on gd.
As far as I could tell, if I looped SPI back on its self it worked just fine.
So it could be a timing issue, or perhaps something do to with the DMA controller and SPI
Also, STM MCUs seem to have more flash memory than in their spec, which a lot of people take advantage of…
The F103C8 seems to be a F103CB , i.e has 128k instead of 64k
On the GD devices a F103C8 only has 64k
Performance is faster, as the program memory if zero wIt state, and they also used a “reserverved” bit in the USB PLL to allow USB to work at 96Mhz and 120Mhz, though strangley 120Mhz is faster than its spec max speed of 108Mhz.
So I suspect they found that they could not run the MCU as fast as they had hoped, over an industrial temperature range.
It would have been great if the GD32 ran all STM32 code, and the chips were widely available and used by the companies who make the BluePill etc, but none of these things happened, so the GD32 remains a niche product.
I think the compatibility is not such a big issue, but the availability. I doubt the GD is able to produce the chip in an amount and quality the market could absorb..
[dannyf – Thu Oct 05, 2017 3:20 pm] –
they can’t run stm binaries,
Sounds like a more accurate statement would be that they can’t run SOME stm binaries,
I have seen stm binaries being uploaded to gd and running just fine there.
Granted I didn’t investigate more but it doesn’t sound right to say That no stm binary can run on gd.
Ok let’s put a different way then. Do you think you can take sources written for STM32, and tested in STM32, such as our core (3rd party) or STM HALs or STM SPL, then compile a modestly complex program using several peripherals (not just blinking a led, that’s pretty much useless even if its fun), compile it without ever looking a GD Datasheet or any other GD information while writting the program (because then you would be looking at what works the same and what doesn’t), test and debug it on an STM32 until the program runs as expected, then upload it to a GD32 of the apropiate model, and expect that program to run flawlessly for as long as it would do in the equivalent STM part?
To me, that would amount to “they can run STM binaries”.
If not, then that would amount to “they can run simple STM binaries” or “some STM binaries” depending how extensive the use of hardware other than the CPU before it start to have problems.
And if in most of the cases one have to look at any document from GD or take any source from them, then it doesn’t amount to running any binary, but running binaries crafted specifically for that dual compatibility.
I do not know what’s the case, so it’s an honest question, but from I have read so far, you can’t take a binary that amounts to more than GPIO access and expect it to run fine. Some will fail because small peripheral differences, some because of timing.
The CPU is no doubt compatible since it’s an ARM core, but so is an LPC, or a SAM, or any other Cortex-M3 core of the same revision.
https://olimex.wordpress.com/tag/gd32/
I think you have a fairly unique definition of “they can run STM binaries”. By that definition,
1) STM MCUs cannot run STM binaries;
2) STM MCUs with identical part numbers cannot run STM binaries;
… and the list goes on.
All you need to do is to take a look at GD’s datasheet and see how identical in terms of registers’ memory locations, bit definitions, etc. are high alike. Unless you can prove that GD is lying in its datasheet, you have to conclude that (some? many? most? almost all?) binaries compiled for STM will run on GD. That same statement also says that not all STM binaries will run on.
As a matter of fact, the Olimex article linked to by ag123 went so far to say that:
To our surprise these boards pass all functional tests without any modifications, i.e. all the development tools, JTAGs, etc work with GD32 like they are STM32! Also all software code made for STM32 run the same way on GD32 devices, so you can re-use all STM32 code and libraries for these new devices.
Personally I think they went too far but that shows you the degree of compatability on the binary level.
So I think your statement (GD cannot run STM binaries) is every bit as wrong as Olimex’s statement (GD can run all STM binaries).
The truth is somewhere in between, as others have confirmed here and elsewhere.
as a hobbist, i’m supportive of st’s products and olimex’s products. for olimex i’ve their OLIMEXINO-STM32
https://www.olimex.com/Products/Duino/S … e-hardware
the well prepared guides, app notes and schematics really helped when i get started messing with mcus and stm32 and continues to be useful whenever i want to use the board for a different use case
i’ve been searching ebay and aliexpress, apparently gd32f103 mcu’s or boards floating around on the web aren’t that cheap after all
https://www.aliexpress.com/wholesale?ca … t=gd32f103
they are priced similarly to stm32f103 if you consider you can get a blue pill for $2
and that there are very few dev board listings unlike the blue pill and maple mini clones or if there are the dev boards are expensive
this possibly show hint that it isn’t as available ‘cheaply’ perhaps in volume as stm32 publicly on the markets
It may well be that GigaDevice bought legally more or less the same IPs as ST and figured out that it would be easier to debug if they matched STM32’s memory map… IANAL, but a memory map looks difficult to protect for either patents or copyrights infringement… And thus GD32 are not strictly “clones”, nor are they licensing anything from ST.
They may well have brought some bugs / enhancements to the STM32 architecture as well.
As for support price / documentation, I would not expect too much from them compared to ST.
mcus are unlike other chips in that you need both hardware and software to work. just telling your customers that they can compile their code to a stm32 chip and burn it onto a gd equivalent exposes the customers to tremendous amount of legal risks. gd (and stm) understood that, I think.
individuals users amount to nothing for those guys.
[ag123 – Sat Oct 07, 2017 2:06 am] –
i’ve been searching ebay and aliexpress, apparently gd32f103 mcu’s or boards floating around on the web aren’t that cheap after all
https://www.aliexpress.com/wholesale?ca … t=gd32f103
bear in mind that aliexpress sellers typically overcharge (a LOT) because they have to pay someone to:
A enter the information in the web site. normally they don’t bother, you have to phone or email them, and internet access is so ridiculously laggy and bandwidth-starved that it’s genuinely, genuinely not worth their time to maintain their own proper web site. phone calls and email is tolerable.
B speak and read english as the primary language.
both of these things cost far more money than the “normal” word-of-mouth (or plain email) sales channels. it sounds ridiculous but until you’ve been to a factory in shenzhen after looking at their web site from outside of China and going “what the hell?? why are these people not running a decent website??” and you view the *exact* same page on their own premises and it’s JUST AS BAD…
that’s a pretty good depiction of china in 1842, 
[dannyf – Fri Oct 06, 2017 11:03 pm] –
To me, that would amount to “they can run STM binaries”.I think you have a fairly unique definition of “they can run STM binaries”. By that definition,
1) STM MCUs cannot run STM binaries;
2) STM MCUs with identical part numbers cannot run STM binaries;
… and the list goes on.
I’m sorry but I dont know what part of what I said make you think under my definition STM MCUs can not run STM binaries?
If I develop any code I want in for an STM32F103VET6, debug it, then let’s say I produce 1 thousand boards that are the same, with the same MCU part number, and I can program that binary and they will run the same. After I have that 1000 units of that board I just flash the exact same binary to all of them. Otherwise no one would every be able to produce any comercial product with STM32F1 MCUs.
I can’t say that I would be able in the last stage of production without any additional development and debugging to just use an equivalent GD32 and send those products to the customer. From what I have read from other people tests, they don’t behave exactly the same.
If I have to retest and debug and recompile, then that’s not the same binary.
You can run some binaries, and they will perform mostly the same, but even GD claim different performance at the same clock speed, any tight timing loop may be thrown off by that. Add to that the differences in peripherals, from registers to timing.
I can say that there exists countless source code for a given STM32 part whereby you cannot do the above when compiled and executed on another STM32 part, especially across family.
even for the same part number, I can write a simple piece of code that, when uploaded to different mcus with the same part number, will exhibit different behaviors, if it utilizes the following:
1. internal oscillator;
2. external (non-synchronized) oscillator;
3. unique ID;
4. ADC;
5. different environment;
…
If I develop any code I want in for an STM32F103VET6, debug it, then let’s say I produce 1 thousand boards that are the same, with the same MCU part number, and I can program that binary and they will run the same.
sure. At the same time, you can also write a piece of code where its execution is vastly different on the same MCU part number. Does that make the same part number incompatible with itself?
After I have that 1000 units of that board I just flash the exact same binary to all of them. Otherwise no one would every be able to produce any comercial product with STM32F1 MCUs.
I am pretty sure that you can flash STM binaries onto the equivalent GD chips. Does that make the GD identical to the STM parts?
You are talking about writting a program to purposely run in a single part. Of course you just need to depend on the unique ID, and it will not run anywhere else.
What I am referring to is writting code to purposely run in any MCU of the same model, but not specifically for GD. So you take code, that you developed not to specifically to fail, but you just developed for a certain MCU. Imagine just a comercial product, such as the j-link or the st-link firmwares.
You know if you load that to the target MCU, it just runs fine, in thousands or millions of the target MCU, you can be sure of that because it’s a fact it was developed to be mass used and it is mass used.
So what I say is that such code that was developed and tested for STM, it may or may not work in a GD, you can not be sure of what it will do.
Does that clarify what I was trying to say?
[dannyf – Sun Oct 08, 2017 11:45 am] –
After I have that 1000 units of that board I just flash the exact same binary to all of them. Otherwise no one would every be able to produce any comercial product with STM32F1 MCUs.I am pretty sure that you can flash STM binaries onto the equivalent GD chips. Does that make the GD identical to the STM parts?
Well, the people of this forum have noticed that is not the case. You can try to flash STM binaries onto a GD, but as some of the registers of the peripherals are different, some parts of your code just won’t do what they do on an STM microcontroller…
I think you are saying two different things:
1) you can flash the STM binary onto a GD – you confirmed it, I saw it, and others have done it;
2) some of those STM binaries may not work on GD – you confirmed it, as have others, and I agree with that.
You are talking about writting a program to purposely run in a single part.
No. I can write a generic program – take blinky for example. Develop it on one STM part successfully and it will fail on other STM parts, or even different MCUs of the same STM part.
You know if you load that to the target MCU, it just runs fine, in thousands or millions of the target MCU,
you can be sure of that because it’s a fact it was developed to be mass used and it is mass used.
only because care was taken in the development stage to make sure that’s the case. it is not difficult at all to write code that wouldn’t work from one mcu to another. as a matter of fact, that was routinely done.
So what I say is that such code that was developed and tested for STM, it may or may not work in a GD, you can not be sure of what it will do.
that has been what I have been saying all along. The fact that some STM binaries do not work on GD doesn’t mean ALL STM binaries will not work on GD.
[dannyf – Sun Oct 08, 2017 2:53 pm] – So what I say is that such code that was developed and tested for STM, it may or may not work in a GD, you can not be sure of what it will do.that has been what I have been saying all along. The fact that some STM binaries do not work on GD doesn’t mean ALL STM binaries will not work on GD.
The current impression is that any binary doing something else besides just toggling the pins a bit will probably not work, and that’s quite bad. If you can prove the opposite, this forum will be very interested
really? doesn’t that suggest the whole arduino port to GD is doomed?
on the flip side, that does seem to suggest that GD can run (some) STM binaries. can we agree on that?
If you can prove the opposite, this forum will be very interested
maybe the arduino port to GD, available here, is a good starting point.
http://stm32duino.com/viewtopic.php?f=3 … d32#p33251
