<antto>
GD32H737/757/759 <- are these still clones of STM32 chips, or particularly the majority of peripherals?
<antto>
if anyone happens to know
jeeebz has quit [Ping timeout: 264 seconds]
jybz has joined #openocd
marekvrbka is now known as MarekVCodasip
<MarekVCodasip>
You could get a clue by comparing the specifications of STM32 Cortex-M7 chips
<antto>
that's what i'm doing but i'm not super familiar with either of them
<antto>
the numbers don't seem to match
<antto>
there's STM32H750 but no GD32H750
<MarekVCodasip>
They could differ in some trivial way, like GD32 having more flash and such
<MarekVCodasip>
Hence different numbers
<antto>
one thing i checked was the USART and it looks as bad as the one in ST
<antto>
yeah, max cpu freq is higher in the GD thing
<MarekVCodasip>
I would expect these peripherals to be common across the ARM ecosystem
<MarekVCodasip>
As ARM has its CMSIS standard
<MarekVCodasip>
I would focus on STM32 specific peripherals, if those match then it is possibly a clone
<antto>
eh? no, that's very wrong expectation unfortunately
<antto>
each vendor puts their own peripherals
<antto>
thing is, for one i know the ST USART is kinda dumb so i would've prefered if it wasn't cloned
<antto>
but it is
<antto>
i need a fast MCU with FPU for realtime audio, so i was looking for a "safe-bet" with as much MHz as i can get, i was aware of atmel chips with 300MHz (probably not gonna be fast enough but it was the easiest option for me), then ST with like 400-500MHz, and NXP with 600MHz
<antto>
but NXP appear noob-unfriendly, they don't even give you datasheets without an account and even when i installed their chip configuration tools i couldn't figure out wtf's going on
<antto>
i had previously looked at gigadevices but the fastest thing they had were cortex-M4s that wouldn't have cut it
<MarekVCodasip>
I teach with NXP when I return as student tutor at university. I know the pain
<MarekVCodasip>
With NXP tools*
<antto>
yesterday i was looking at allwinner D1 (application processor) and... it's way above my head, and i accidentally went to gigadevices again and i saw they now have this 600MHz cortex-M7F
<Xogium>
fwiw the d1 SUCKS
<Xogium>
I have a friend who's been fighting with it
<antto>
Xogium, why?
<Xogium>
because allwinner ? ;)
<antto>
well i need realtime audio and not a whole OS
<antto>
1GHz sounds like it's definately gonna be powerful enough (as long as it can do floating point math, which i didn't clearly found)
<Xogium>
maybe you can get away with it then... I don't know. I know that using it in linux is a nightmare though. Like the whole boot chain is a disaster
<antto>
also my thing can't take advantage from parallel power so i don't need 16 slow cores, i need 1 fast core
<antto>
oh
<antto>
no one actually sells these gigadevices chips...
<antto>
>:/
Quello has joined #openocd
<Quello>
How to promgram PSOC433 flash by openocd
<PaulFertser>
Quello: hi
<PaulFertser>
Quello: doesn't psoc4 driver support it or what?
<PaulFertser>
Is it some new chip, not psoc4000 series?
<braunr>
antto: are you looking to buy an olimex board by any chance ?
<antto>
why?
<antto>
what olimex board?
<braunr>
because those are exactly the questions i had in mind when i looked at some olimex boards
<braunr>
they started providing two versions of their stm32 boards with those cheap gd32 compatible microcontrollers
<braunr>
on the surface they look compatible, but i haven't tested nor seen anyone do some trustworthy comparison
Quello has quit [Quit: Client closed]
<braunr>
antto: if you find more info on that, i'm interested :)
<antto>
tbh i'm not tied to any vendor, i've so far only used atmel chips, for ST i know they have some poorly designed or weak peripherals like the USART for example
<antto>
but tons of people use their chips, so that's also a thing
<braunr>
hm how are USARTs weak or poorly designed ?
<antto>
i would've prefered if GD didn't clone the poor periphs from ST, but it seems they probably did
<antto>
well the sync mode on their USARTs is.. useless
<braunr>
oh ok
<antto>
and you can find it all the way from very old STM32F0 chips up to their fanciest chips, they simply don't fix/improve it
<antto>
as for olimex, i don't seem to find GD boards on their site
<braunr>
ST seems to implement the cortex-m7 correctly
<braunr>
which is important because, even with at a lower frequency, if the dual issue feature is correctly implemented, it can be much faster than a cortex-m4 at the same freq
<braunr>
ST also handles code and data parallelism at the bus level correctly
slobodan has joined #openocd
<antto>
hm
<antto>
well my guesstimation is that i need roughly at least an equivalent of a cortex-M4F at say 500MHz for this code to run realtime
<antto>
maybe slightly less if i unload some non-audio things from it
<braunr>
also, ST provides a good 16k instruction cache
<braunr>
that makes a huge difference
<braunr>
it's not always 16k, but 16k at most, and my boards here at work use that
<antto>
olimex seem to have only cortex-M4 stuff and i know those aren't that fast
slobodan has quit [Read error: Connection reset by peer]
<antto>
and how come an ARM core can be implemented incorrectly?!
<antto>
i thought the whole point is that the core comes from ARM and should be the same in any vendor's chip
slobodan has joined #openocd
<braunr>
oh no they don't
<braunr>
the spec comes from arm
<braunr>
arm only provides specs and gets royalties
<antto>
and then each vendor puts their own flash/ram and peripherals
<braunr>
no no
<braunr>
they build the cpu
<braunr>
arm provides options in their specs
<braunr>
you can chose to use the least options
<antto>
yes they can make cortex-M7 without FPU and with or without a number of other things
<antto>
but still 600MHz sounded promising
<braunr>
meh
<antto>
even if it runs as "dumb" as my cortex-M4F right now, i think it should be fast enough
<braunr>
if they have a 600 MHz clock and have a shitty pipeline, it doesn't help
<antto>
bleh
<braunr>
that would be a non conforming arm implementation, but still possible
<braunr>
and it wouldn't be the first a chinese company intending to get market shares with cheap replacements with big numbers does it
<braunr>
+time
<antto>
i've seen GD32 (the older ones, not this M7F now) in products like Behringer's synths
<antto>
surely they probably aren't doing intensive work in there
<braunr>
as a musician i know those products a bit
<braunr>
and yeah behringer is ... really meh
<antto>
yeah but they seem to work there ;P~
<braunr>
as usual, if they use simpler versions of some algorithms, maybe they don't need the same power
<braunr>
or really, speed
<antto>
for me ideally Atmel would've made a new M7F with a faster speed, and atmel.start support
<braunr>
i use mostly guitar pedals though, i don't know about synths
<antto>
but so far it doesn't look like so, and their fastest chip is 300MHz and older than their newer chips which are smaller
<braunr>
i'm gonna go eat, so bbl, but yeah, i'm interested in knowing more about those
<antto>
well the Mehringer device i was talking about uses GD32 for MIDI, digitally controlling an analog synth voice and sequencer, probably USB too
<braunr>
maybe i'm speculating completely wrong
<antto>
which can be done on some nice 8bit chip too
<antto>
they slapped GD32 probably because "why not" and it's cheap and plenty of power and debugging is nice...
PsySc0rpi0n has joined #openocd
<antto>
i'd be more happy if they made their own thing instead of cloning existing chips
<antto>
altho maybe it doesn't matter since you can't seem to even buy those chips
<antto>
on the other hand, it seems STM32H7xx are available in many places at the moment
Deneb has joined #openocd
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
cyrozap has joined #openocd
<karlp>
braunr: you should feel pretty comfortable with gigadevices, they're a fairly large manufacturer. I've heard of one of two _very_ niche incompatiilities, but otherwise, as advertised, drop in compatible.
<karlp>
I don't really like the term clone, they're just peripheral compatible, for the periphsthat are listed as compatible,
<karlp>
braunr: whta is this "m7 not implemented correctly" that you're referring to? which part?
<MarekVCodasip>
Thing is, sometimes they are kinda clones as test vectors once leaked from STM
<MarekVCodasip>
They are basically test vector compatible. GD actually did fix a few things in their reimplementations of STM32
<karlp>
there's zero evidence of them being cloned IP.
<karlp>
they have some parts with ~same part numbers and register compatible peripherals, but they have quite a few otehrs that are not the same at all, or are improved or otherwise adjusted
<karlp>
there's maybe six vendors or more making a few compatible parts to try and take the bottom end market, replacing f103s and f030s,
merethan has joined #openocd
<antto>
i think the GD32H7xx is just too new maybe and still not available to buy anywhere
<braunr>
karlp: i'm not referring to anything in particular, just the possibility
<braunr>
karlp: thanks for the info
<antto>
if they just copied the internals i'd be worried, afaik as karlp said they are designed "normally" just made to be very compatible with existing code for ST chips
<antto>
some of them
<karlp>
all of them.
<antto>
but they got RISC-V chips
<antto>
you can't expect to put CMSIS on that
<antto>
or can you
<karlp>
cmsis isn't all that much magic...
<antto>
but it's specific to ARM
<karlp>
yeah, but... it's not all that special...
<antto>
well, i don't know.. and in any case, i don't have an STM32 project that i wanna replace the chip of with a cheaper/different vendor chip
<antto>
i have a project with a too weak processor on it, the most important chunk of it is floating point DSP code that needs much MHz
<karlp>
depending on wha tyou call "cmsis" most of it is just a a common method for accessing core registers, wrapping up assembly inlines.
<antto>
so it's equally foggy and difficult looking for me whether i take an NXP or ST or GD or other chip
<karlp>
the core_cm[0347].h files for instance
<karlp>
there' core_riscv.h files that are ~equivalent for core acess.
<antto>
well the asm shouldn't make sense on risc-v
<karlp>
and unless you're writing operating systems, you don't need them anyway.
<antto>
i'm not but i do have some of the inline asm in my "periph lib" for SAME54
<antto>
and SAMD2x
<antto>
minor things
<antto>
they won't work or make sense on risc-v i'd think
PsySc0rpi0n has quit [Quit: Leaving]
MarekVCodasip has quit [Remote host closed the connection]
<antto>
braunr, i think it's a GD32F350 chip in that Mehringer synth, cortex-M4 at 108MHz, 48 pins
<antto>
M4F even
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
cyrozap has joined #openocd
cyrozap has quit [Remote host closed the connection]
cyrozap has joined #openocd
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
cyrozap has joined #openocd
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
cyrozap has joined #openocd
<braunr>
antto: thanks
<antto>
what for? ;P~
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
cyrozap has joined #openocd
HumanGeek has quit [Ping timeout: 246 seconds]
HumanGeek has joined #openocd
damex has quit [Ping timeout: 240 seconds]
damex has joined #openocd
borneoa___ has quit [Quit: Connection closed for inactivity]
borneoa___ has joined #openocd
wingsorc has joined #openocd
bvernoux has joined #openocd
bvernoux has quit [Remote host closed the connection]
nerozero has quit [Ping timeout: 240 seconds]
merethan has quit [Ping timeout: 258 seconds]
zjason has quit [Read error: Connection reset by peer]
zjason has joined #openocd
slobodan has quit [Ping timeout: 255 seconds]
Deneb has quit [Quit: Leaving]
JakeSays_ has joined #openocd
JakeSays has quit [Ping timeout: 244 seconds]
borneoa___ has quit [Quit: Connection closed for inactivity]