Slow speed on Duo (Arduino)?

Duo
1

Am I doing something wrong? I seem to get pretty low speeds when using the 700mhz core in the Arduino IDE.

/*                Results
   -----------------------------------------
  |         Board           |     Time      |
  |-----------------------------------------|
  | ESP32 Dev (240mhz)      |      183      |
  | Nano Connect (150mhz)   |      334      |
  | Raspi Pico (150mhz)     |      335      |
  | Raspi Pico W (150mhz)   |      335      |
  | Nano Connect (133mhz)   |      377      |
  | Raspi Pico (133mhz)     |      378      |
  | Raspi Pico W (133mhz)   |      378      |
  | Nano Every (16mhz)      |     7412      |
  | Milkv Duo 64 (700mhz)   |     8073      |
   -----------------------------------------
*/

#include <Arduino.h>

unsigned long startTime = 0;
unsigned long endTime = 0;
unsigned long elapsedTime = 0;
unsigned long fibonacciValue = 0;

void setup() {
  Serial.begin(115200);
}

void loop() {
  startTime = 0;
  endTime = 0;
  elapsedTime = 0;
  startTime = micros();
  yourFunction();
  endTime = micros();
  elapsedTime = endTime - startTime;
  Serial.print("Elapsed Time (microseconds): ");
  Serial.println(elapsedTime);
  delay(10000);
}

void yourFunction() {
  for (volatile int i = 0; i < 20; ++i) {
    fibonacciValue = 0;
    fibonacciValue = fibonacci(10);
  }
}

unsigned long fibonacci(int n) {
  if (n <= 1) {
    return n;
  } else {
    return fibonacci(n - 1) + fibonacci(n - 2);
  }
}
2

Likewise,

I used the GPIO toggle arduino sketch (removed the delays) and it can only manage a frequncy if about 14Khz

Is there something secret to make it run at a better speed?

3

One of the reason maybe that by default the I-Cache is disabled.

See chapter 16.3 of https://occ-intl-prod.oss-ap-southeast-1.aliyuncs.com/resource/XuanTie-OpenC906-UserManual.pdf for how to enable it in assembly. I don’t know how to do it in Arduino IDE.

1 Like
4

It’s also possible that micros() doesn’t have the resolution you would expect. Could you run yourFunction like 100 times, and then divide the timing result by 100 to see if this makes a difference?

5

Arduino Code to enable D and I Cache… just for fun. I didn’t benchmark it yet as I need to attach a serial port :smiley: - and that is tomorrows job

It impacted my blinky - more details follow.

void setup() {
    Serial.begin(115200);
    Serial.println("Starting");

#if 1
  asm volatile(
          "li x3, 0x33\r\n"
          "csrc 0x7c2, x3\r\n"
          "li x3, 0x11\r\n"
          "csrs 0x7c2, x3\r\n"
          "li x3, 0x1\r\n"
          "csrs 0x7c1, x3\r\n"

          "li x3, 0x33\r\n"
          "csrc 0x7c2, x3\r\n"
          "li x3, 0x12\r\n"
          "csrs 0x7c2, x3\r\n"
          "li x3, 0x2\r\n"
          "csrs 0x7c1, x3\r\n"
  );
#endif
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);
}
6

With D and I cache enabled, GPIO went from 14Khz to 500Khz

its still slow… what is the limit of the internal bus?

EDIT:

@niek - I cant reply more as the forum only allows 3 replies from noobies :smiley:
@Mando_Rick Question for you… did the new Arduino cache code work for you?

7

Did you try my suggestion and see if it makes a difference?

8 
#define TEST_PIN 20  

void setup() {
  pinMode(TEST_PIN, OUTPUT);
  asm volatile(
        "li x3, 0x33\r\n"
        "csrc 0x7c2, x3\r\n"
        "li x3, 0x11\r\n"
        "csrs 0x7c2, x3\r\n"
        "li x3, 0x1\r\n"
        "csrs 0x7c1, x3\r\n"

        "li x3, 0x33\r\n"
        "csrc 0x7c2, x3\r\n"
        "li x3, 0x12\r\n"
        "csrs 0x7c2, x3\r\n"
        "li x3, 0x2\r\n"
        "csrs 0x7c1, x3\r\n"
  );
}

void loop() {
  digitalWrite(TEST_PIN, HIGH);   
  digitalWrite(TEST_PIN, LOW);  
  
}

Allows me to measure a pulsetrain on pin 20 of 700 kHz. A bit more than 500 kHz. but still remarkably little considering it is a 700 MHz clock - if I understood it correctly:

IMG_20240701_211408850
IMG_20240701_2114088501920Ă—1440 235 KB

Do you have any idea how to make it work faster, the little dude?

1 Like
9

Oh. I wasn’t aware that there was a cap on replies. That is weird. Anyway. If you want to talk to me, you can reach me at morten at winkler dot 🇩 🇰

I want MORE speed out of the little core

10

Shame, I wanted to see where this was headed, thx for the interesting replies.

11

Still working on it … I would like to see an ideal 2 or so Mhz (the more the merrier)
My next test would be using the low level RTOS software to see if I can manipulate the register directly… (from the Arduino code, it doesnt that over 4+ function layers.

1 Like
12

On my Duo-S, with code in rust, according to my cheap 24Mhz logic analyzer, the absolute fastest I could achieve is 6.0Mhz.

The code for the loop is the following:

    loop {
        unsafe {
            gpio1.dr().write(|w| w.bits(1 << 14));
            gpio1.dr().write(|w| w.bits(0));
        }
    }
4 Likes
13

I get 2.9Mhz on the below code… It toggles pin 20 (GP15) - I needed to add the NOP before the toggles happened (ADDI instruction)


#define GPIO2 0x03022000
#define GPIO0 0x03020000


#define GPIO_SWPORT_DR 0x000
#define GPIO_SWPORT_DDR 0x004
#define PIN 15

// the setup function runs once when you press reset or power the board
void setup() {
  // initialize digital pin LED_BUILTIN as an output.
  *(uint32_t*)(GPIO0|GPIO_SWPORT_DDR) = 1 << PIN;
 
  asm volatile(
        "li x3, 0x33\r\n"
        "csrc 0x7c2, x3\r\n"
        "li x3, 0x11\r\n"
        "csrs 0x7c2, x3\r\n"
        "li x3, 0x1\r\n"
        "csrs 0x7c1, x3\r\n"

        "li x3, 0x33\r\n"
        "csrc 0x7c2, x3\r\n"
        "li x3, 0x12\r\n"
        "csrs 0x7c2, x3\r\n"
        "li x3, 0x2\r\n"
        "csrs 0x7c1, x3\r\n"
  );
}

// the loop function runs over and over again forever
void loop() {
    *(uint32_t*)(GPIO0|GPIO_SWPORT_DR) = 1 << PIN;
    asm volatile (
       "ADDI x0, x1, 0\r\n"
    );
    
    *(uint32_t*)(GPIO0|GPIO_SWPORT_DR) = 0;
    asm volatile (
       "ADDI x0, x1, 0\r\n"
    );
}

RigolDS0
RigolDS01024Ă—630 62 KB

2 Likes
14

Has anyone done some benchmark using the RTOS of the SDK, so that we have something to compare to?

1 Like
15

Hi
What is the size of the caches, and can we expand them?

1 Like
16

I have done the same on RTOS - Here are the results

image
image822Ă—296 15.2 KB

1 Like
17

Has anyone gotten any additional answers on why the small core is so slow? I set up my own arduino GPIO toggle sketch and found the best I could get is 500KHz toggling. I found this thread while looking for answers.

I’m working on a project that does bit banging to simulate some hardware. It works on the Pi Pico which is much slower, and I was really excited to port it to the MilkV Duo because I could run Linux on the big core and have a lot more RAM for buffering.

I’m really struggling to understand the results others in this thread have had. Pure assembly only getting 3MHz toggle on a 700MHz RISC-V core? It makes no sense to me.

Is there something slow in the internal peripheral bus that is causing this slowdown, or is the big core somehow taking priority?

Has anyone tried a toggle on the big core to see how fast it can go? If the big core can achieve reasonable speeds then I could probably get away with running my code on the big core. I could make due without Linux and still be ahead of the RPi Pico with the extra RAM, which is more important to me.

I’m really curious about what is going on here.

Cheers!

2 Likes
18

No definitive answer as far as I can tell

1 Like
19

I’ve been looking at other threads I could find related to this, like interrupt latency on the little core. It almost seems as if the clock on the little core is not actually being configured correctly.

2 Likes
20

I am pretty disappointed of the performance as well, I was really hoping for more. Besides the cache, the actual frequency of the cores is also a problem, as stated before on the forum.
I’ve looked at the fsbl code, depending on the device/package, the frequencies are quite different.
The selection is made here, the CV180x is QFN68 (not sure what QFN88 is, I’ve only seen it for CV181x chips), from my guess “ND” stands for normal drive and “OD” for overdrive. So the frequency is actually 594MHz as seen here.
Same story for the Duo 256M, but at least the frequency configuration depends on a compiler flag and not the package of the IC (here).

I am tempted to try to run bare metal on the main core as others have done, maybe directly from SRAM to avoid SDRAM latency, but not sure if it’s worth it.

2 Likes