You are reading a single comment by @FransM and its replies. Click here to read the full conversation.
  • I don't think I/O will be the bottleneck. This is bit-banged SPI so the clock is generated by software. Of course it could be that the chip introduces additional latency when writing to a GPIO pin, but generally that is pretty fast, just sending a bit to an output pin.

    Wrt the test:
    I'm using chromium (version 83) on ubuntu 18.04.04.
    I cannot paste in the left pane of the IDE, only in the right pane.
    Should I use a different browser?

    For the test: as I only updated spiFlashWrite I don't expect any gains as executing from flash is only read, but let me try.

    Copying all but the last three lines to the right pane and selecting execute from ram gives me 7.4944 seconds.
    Running the last thee lines give me 8.9745 so no gain.

    Let's try to also unroll the loop for spiFlashReadWrite
    text size in the lst file before is 0x0005d1e4 bytes
    after unrolling it is 0x0005d2d4
    difference is F0 == 220 decimal

    rerunning the exe now gives me 8.7609, 2nd run gives 8.7582

    Observations/tentative conclusions

    1. My execution time when running from RAM is slightly longer (about 0.05 sec so < 1%
    2. When running from flash is 8.97; substantially longer than your 8.79 (unless you accidently swapped digits when typing the comment of course). A reason for this could be that I compiled with gcc 9 (as mentioned in another post).
    3. With the spiFlashReadWrite loop unrolled I get a gain of 0.21 seconds (8.97-8.76). That would mean 2.3%. However the RAM run needed 7.49 seconds, so the original code for me used 8.97-7.49 = 1.48 seconds more when executing from flash compared when executing from RAM whereas the new code takes 8.76-7.49 = 1.27 seconds. So the I/O based speedup is about 14% ((0.21/1.48) * 100%)

    While looking at the code I noticed that some more optimization opportunities. I'll look into those as well and report back.

About

Avatar for FransM @FransM started