Pin Toggle Frequency Contest against C. Please Help! :)

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
Damien
Site Admin
Posts: 616
Joined: Mon Dec 09, 2013 5:02 pm

Re: Pin Toggle Frequency Contest against C. Please Help! :)

Post by Damien » Tue Feb 02, 2016 7:10 pm

Note that in my viper version (3b) the loop is dominated by the call to millis. If instead you are allowed to just count for, say, 2000000 toggles and time the result, then it's easier and faster. Eg:

Code: Select all

@micropython.viper
def togglePerformance3c():
    start = pyb.millis()
    odr = ptr16(stm.GPIOA + stm.GPIO_ODR)
    for _ in range(2000000):
        odr[0] ^= 1 << 13 # PA13 = LED_RED
    time = pyb.elapsed_millis(start)
    count = round(2e9 / time)
    print('Counted: {:10,} (viper3) (time={}ms)'.format(count, time))

@micropython.viper
def togglePerformance3d():
    start = pyb.millis()
    bsrrl = ptr16(stm.GPIOA + stm.GPIO_BSRRL)
    bsrrh = ptr16(stm.GPIOA + stm.GPIO_BSRRH)
    for _ in range(2000000):
        bsrrl[0] = 1 << 13
        bsrrh[0] = 1 << 13
    time = pyb.elapsed_millis(start)
    count = round(4e9 / time) # 2 toggles per iteration
    print('Counted: {:10,} (viper4) (time={}ms)'.format(count, time))
Version 3c uses ODR to toggle and takes time to read then write this register. Version 3d uses the BSRR registers and can run faster. Counts are (normalised to time taken):

viper 3c: 2,020,202
viper 3d: 6,700,168

Version 3d is only a factor 2 off Dave's assembler version.

User avatar
Roberthh
Posts: 1635
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Pin Toggle Frequency Contest against C. Please Help! :)

Post by Roberthh » Tue Feb 02, 2016 8:24 pm

Folks, that's a very interesting discussion, especially regarding the special aspects of the stm module and the @micropython.viper function decorator. Unfortunately, the micropython doc does not tell much about it. Is there any place for reading about these language elements?
Why do I ask: I'm still thinking to write a driver for a larger LCD, the one with the 40 pin connector, and controllers like the SSd1963. First test with the pin functions showed, that these are by far too slow. I refuse a little bit to use assembler. The most recent assembly pieces I made were with Z80, when that CPU was famous. So the last sample functions shown here could be a good combination of readability and speed.
Thanks in advance, Robert

mad474
Posts: 60
Joined: Sun Dec 29, 2013 7:48 pm

Re: Pin Toggle Frequency Contest against C. Please Help! :)

Post by mad474 » Tue Feb 02, 2016 8:43 pm

viper 3c: 2,020,202
viper 3d: 6,700,168
Version 3d is only a factor 2 off Dave's assembler version.
Jawohl :D very clever approach.

mad474
Posts: 60
Joined: Sun Dec 29, 2013 7:48 pm

Re: Pin Toggle Frequency Contest against C. Please Help! :)

Post by mad474 » Tue Feb 02, 2016 8:54 pm

... special aspects of the stm module and the @micropython.viper function decorator. Unfortunately, the micropython doc does not tell much about it. Is there any place for reading about these language elements?
I eventually I found something over here
https://www.kickstarter.com/projects/21 ... sts/664832
https://www.kickstarter.com/projects/21 ... sts/665145
(in addition to the MicroPython sources and the STMF4xx-docs).
I guess voluntary doc writers are welcome :twisted:

chuckbook
Posts: 105
Joined: Fri Oct 30, 2015 11:55 pm

Re: Pin Toggle Frequency Contest against C. Please Help! :)

Post by chuckbook » Tue Feb 02, 2016 10:19 pm

Hi folks, I think we have a new MPY ranking :-)
Jokes aside, there is one thing I'm curious about: In https://www.mikrocontroller.net/topic/388161#4450525 a native C version
claims to give a 21MHz frequency output on a STM32F407 MCU at 168 MHz core frequency. This means 8 cycles per loop.
There are 3 memory load/stores involved, one increment, one compare and one branch. According to my knowledge of Cortex M4
instruction set this will require at least 10 cycles (12 cycles if I/O register access is taken into account). So max freq. will be 14MHz.

I'd love to be falsified!

User avatar
dhylands
Posts: 3227
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Pin Toggle Frequency Contest against C. Please Help! :)

Post by dhylands » Tue Feb 02, 2016 10:33 pm

Using the bsrr register, it should be 2 stores, an increment, a compare and a branch.

There is a cbz instruction and I just found the bit encoding for it so I'm going to try that.

chuckbook
Posts: 105
Joined: Fri Oct 30, 2015 11:55 pm

Re: Pin Toggle Frequency Contest against C. Please Help! :)

Post by chuckbook » Tue Feb 02, 2016 10:54 pm

Hi Dave,
what about the timer int flag?

User avatar
dhylands
Posts: 3227
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Pin Toggle Frequency Contest against C. Please Help! :)

Post by dhylands » Wed Feb 03, 2016 5:16 am

Yeah the timer int flag is the compare. Oh - there would be a load to load the run flag.

So 2 stores (2 writes to the BSRR), 1 load of the run flag, one compare/branch to get out of the loop, one unconditional branch at the end of the loop and one register increment (for the counter).

There is presumably an optimal interleaving of the instructions.

chuckbook
Posts: 105
Joined: Fri Oct 30, 2015 11:55 pm

Re: Pin Toggle Frequency Contest against C. Please Help! :)

Post by chuckbook » Wed Feb 03, 2016 12:00 pm

Yes, the cb?? will allow a more balanced pipeline. Without this instruction 14 cycles (12MHz) can be achieved.
I'm still curious about the 21MHz. If that's doable I would like to know.

User avatar
dhylands
Posts: 3227
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Pin Toggle Frequency Contest against C. Please Help! :)

Post by dhylands » Wed Feb 03, 2016 3:34 pm

ok - that jives with with what I saw. I was able to get a counter of 10-11 million using the second asm example. By turning SysTick off I was able to bump the count a bit. I imagine that USB interrupts will be affecting the outcome a bit as well.

Post Reply