RLP bitbang throughput?

Has anyone done any RLP bitbanging benchmarking?

I tried flipping a pin as fast as I could in RLP, but I could only get around 200khz which seems very low, I was expecting something like a few Mhz. Or maybe I’m doing smth wrong…? Here’s the code I’m using:


int state=0;
int pin=9;
for (i=0;i<loops;i++)
{
    state = !state;
    RLPext->GPIO.WritePin(pin, state);
}

FWIW, I’m using a logic analyzer to read the output. Also, the clock produced from this code is not constant/precise, it oscillates a lot around 200khz.

I see that oscillation you are talking about too, in my rs485 project. I think there are several higher interrupts (maybe for screenupdate) that you can’t disable.

The speedloss is due to the not optimising compiler. Try to compile a list file and you’ll see how many instructions are needed for your loop.

You can make it much faster and write to the registers directly…and use assembly and make it super fast! A 72Mhz processor toggling a pin…think about it :slight_smile:

I’m really interested into the results if you can optimize it, I will need soon to produce such high level code to control high speed steper motors :wink:

The only optimization I tried was to compile with -g0 and -Os, that reduced the elf file almost to half.
The uncontrollable interrupts would explain the irregular signal I’m seeing… but even if I did assembly, wouldn’t those interrupts still kick in? Or maybe those interrupts are being setup by the RLPext->GPIO.WritePin() calls…?

Do I really have to go to assembly to see the khz to mhz change in speed?
If so are there any good resources on ARM assembly and how to integrate it in incline C for RLP? It’s been long since I coded motorola 68k assembly … I’m really just looking for being able to play with an IO (pin# passed in from C#) and have complete control over the bitbanging as well as producing very deterministic/precise output.

No, try this…it should be surprisingly fast!

while(1)
{
FIOxSET = (1<<yourbit); //the x is the port number so FIO1SET for port 1
FIOxCLR = (1<<yourbit);
}

Interrupts will idd still kick in. Using direct register access like Gus proposes is your best option. You will benifit from speed and better code readability. Assembler is your last savier when you’re working near the limits.

It’s always good to see the asm listing that the compiler produces from your c code. F.e: counting from 10 to 0 can be faster then counting from 0 to 10.

I tried the code that Gus suggested and here’s the output I get.
It looks like now I am up to 4.8Mhz, but still a highly irregular waveform…
Are the mysterious interrupts are responsible for this?
I haven’t tried assembler yet but I’m guessing the result is the same.

I told you it will be very fast. You can try to disable interrupts and it will be very stable