Greetings,

Maybe this has been discussed somewhere else but I could not find the thread(s) dealing with it.

Is there a reason why the hardware FPU is disabled and the software FPU used instead?
The F303 (STM or GD) is a Cortex-M4(Which has a FPU), and not a Cortex-M3 like the F103's(Which does not).

Also, what is the reason for bit-banging I2C and SPI?  Does the GD32F303 have problems with the hardware versions?

Thanks,
GB
AE7OO

Some chips don't have FPU, and we verified that there is good timing
margin without it, so it's disabled in all builds. The code is all
interrupt driven and either you meet timing deadlines or you don't, so
speeding up code will not improve performance.

I"m hoping that when you say some chips don't have an FPU, you mean that
some people are using a Cortex-M3(F10(1|3)) and not that some of the
GD32F303's don't have one.
Because if it is the latter, I'll be avoiding all GD devices. It's bad
enough that they are reusing part suffixes when they don't seem to be
compatible, but it also looks like they are claiming that their silicon is
perfect as I can not find any errata for any of their F3 series.

The reason I was asking is that it looks like I'll be without work until
the US opens up more and my various friends(aka Salesman LOL) can find me
some.
So I've got plenty of time on my hands and so I thought I would rewrite the
software from scratch more or less. And did not want to be banging my head
on a wall over a bug when the hardware was at fault. Been there, done that
and did not want the T-shirt.
While I understand the concepts of how a VNA works, this would allow me to
get a much greater understanding at a deeper depth.

If I get any of this done(who knows, I might get lucky and have work sent
my way today), I'll release it on GitHub under the GPL, since my favorite
RTOS(ChibiOS) is licensed the same.

Thanks again,
GB
AE7OO

On Mon, Jan 25, 2021 at 10:51 PM OwO <OwOwOwOwO123@outlook.com> wrote:

> Some chips don't have FPU, and we verified that there is good timing
> margin without it, so it's disabled in all builds. The code is all
> interrupt driven and either you meet timing deadlines or you don't, so
> speeding up code will not improve performance.
>
>
>
>
>
>

--
GB Clark II
gclarkii@gmail.com

On 1/26/21 5:53 AM, GB Clark wrote:
> I"m hoping that when you say some chips don't have an FPU, you mean
> that some people are using a Cortex-M3(F10(1|3)) and not that some of
> the GD32F303's don't have one.
> Because if it is the latter, I'll be avoiding all GD devices.  It's
> bad enough that they are reusing part suffixes when they don't seem to
> be compatible, but it also looks like they are claiming that their
> silicon is perfect as I can not find any errata for any of their F3
> series.
>
> The reason I was asking is that it looks like I'll be without work
> until the US opens up more and my various friends(aka Salesman LOL)
> can find me some.
> So I've got plenty of time on my hands and so I thought I would
> rewrite the software from scratch more or less.  And did not want to
> be banging my head on a wall over a bug when the hardware was at
> fault.  Been there, done that and did not want the T-shirt.
> While I understand the concepts of how a VNA works, this would allow
> me to get a much greater understanding at a deeper depth.
>
> If I get any of this done(who knows, I might get lucky and have work
> sent my way today), I'll release it on GitHub under the GPL, since my
> favorite RTOS(ChibiOS) is licensed the same.
>
> Thanks again,
> GB
> AE7OO
>
> On Mon, Jan 25, 2021 at 10:51 PM OwO <OwOwOwOwO123@outlook.com
> <mailto:OwOwOwOwO123@outlook.com>> wrote:
>
> Some chips don't have FPU, and we verified that there is good timing
> margin without it, so it's disabled in all builds. The code is all
> interrupt driven and either you meet timing deadlines or you
> don't, so
> speeding up code will not improve performance.
>

One thing to watch with FPUs is how they are managed with respect to
interrupts, especially in the underlying OS.  Some FPUs are "parallel"
to the main CPU, often they are asynchronous, and when an interrupt
comes in, the state may not be well defined if it's in the middle of an
operation.  The other thing I've been bitten by is when the OS provided
ISR mechanism doesn't save the state of all registers (especially the
FPU registers), or when it "borrows" FPU registers to save state (rather
than, say pushing on the stack).