DSO150/RiscV: Blaming the innocent

While redoing the DSO150 on top of lnArduino i'm cleaning up a lot of stuff i just used  "as-is" previously.

In particular, i rewrote the ILI9341 driver to be fast while still being portable to some extend.

NB: It's a 8 bits parallel ILI9341 , not your vanilla SPI connected ILI9341.

The new code worked fine on the GD32F303  (Arm) based unit but i ran into problems when used on the risc-v powered board (GD32VF103).

Same DSO board, the two mcus have the  same hw components internally, just the core is different .

I had strong doubt about the "lazy" write of the riscV chip. 

If that happens, it means that when you write something, it is actually written a bit later. That's problematic when you are driving LCD signals.

Adding fence/fence.i everywhere seemed to fix the obvious problem.

But wait a sec,  adding  plain nops works also.

So either delayed write issue or timing issue.

Ok, we'll add the fence/nop and look into that later.

Ah, the screen goes blank after a while. So not even completely fixed.

Ok we'll drop that topic for the moment, let's check if the changes to make it almost work on the riscv broke things for arm.

It still works on the Arm. Good.

Wait a minute.... The Riscv version is running at 108 Mhz, the Arm version is running at 96 Mhz.

Arm @72 Mhz : works fine forever

Arm @96 Mhz : works fine forever

Arm @108 Mhz : works for a bit then white screen.

Ah.

So it means that at 96 Mhz, we are borderline as far as the screen is concerned, and when going above the signals are too fast and eventually the screen will crash.

What  bothers me is i still dont know if the riscV delayed write is something to worry about. And it still goes white after a while even with a fence + a nope

It will be for later.

NB: It will work fine with a STM32F1 @ 108 Mhz because the STM32 has 2 wait states on the flash.

The GD32 does not.