Blue Pill running slow

Post here first, or if you can't find a relevant section!
IanNoob
Posts: 15
Joined: Wed Oct 07, 2020 5:35 pm

Re: Blue Pill running slow

Post by IanNoob »

Thanks fpiSTM, but I have no idea what you mean.

How would HAL, LL or CMSIS look if I used them in the Arduino IDE? Or would they only work in the STMCubeProgrammer?

Ian

GonzoG
Posts: 80
Joined: Wed Jan 15, 2020 11:30 am
Answers: 5

Re: Blue Pill running slow

Post by GonzoG »

IanNoob wrote:
Fri Oct 16, 2020 5:07 pm

I found (using an oscilloscope) that the reaction time to a repeating pulse from a Nano is very 'juddery' and varies between:
1.7uS to 3.8uS using Method A (digitalRead) and
1.0uS to 2.6uS using Method B (digitalReadFast)

Is this what you would expect? Am I doing something fundamentally flawed?
Have you set optimization to "fastest -O3" in Arduino IDE (menu Tools -> optimize) ?? Because this ~1.5x difference I get with standard (-Os) optimization (smallest).

I got up to 20M reads/s using digitalReadFast.

Reading single port using registers (GPIOx->IDR) isn't much faster - about 22M.

User avatar
fpiSTM
Posts: 848
Joined: Wed Dec 11, 2019 7:11 pm
Answers: 33
Location: Le Mans
Contact:

Re: Blue Pill running slow

Post by fpiSTM »


IanNoob
Posts: 15
Joined: Wed Oct 07, 2020 5:35 pm

Re: Blue Pill running slow

Post by IanNoob »

Thanks GonzoG. I just tried that - no change. Well - this time I got:
1.5uS to 4.1uS using Method A (digitalRead) and
1.0uS to 2.7uS using Method B (digitalReadFast)

so a little better than 500k reads/s the same as with optimization on "Smallest -Os (default)"

I jusrt re-tried the digitalWrite version of the same sketch and got pulses of about 60nS, with no difference between optimization settings.

I'm baffled.

Ian

IanNoob
Posts: 15
Joined: Wed Oct 07, 2020 5:35 pm

Re: Blue Pill running slow

Post by IanNoob »

Thanks again fpiSTM. That is a really clear and useful link. As far as I can tell the code given is understood by STM32CubeMX and not by Arduino IDE, is that right?

I have tried some of the code snippets given but they just get rejected by the IDE with error messages.

I am comfortable with register level programming but don't particularly want to move back and forth between programming environments.

Ian

GonzoG
Posts: 80
Joined: Wed Jan 15, 2020 11:30 am
Answers: 5

Re: Blue Pill running slow

Post by GonzoG »

I wrote simple program for testing digital IO speed.
For read tests it's using 2 different pins (PA1 and PB1).
This it what I get (-O3 fastest optimization):

Code: Select all

Port I/O speed test. Arduino digitalRead/Write / digitalReadFast/WriteFast / STM32 register 
********* Write test: *********
 digitalWrite: 1853696us    1op time: 0.93   op/s: 1.08M/s
 digitalWriteFast: 61495us    1op time: 0.03   op/s: 32.52M/s
 GPIOx->ODR: 255674us    1op time: 0.13   op/s: 7.82M/s
********* Read test: *********
 digitalRead: 1838335us    1op time: 0.92 ops/s: 1.09 M/s
 digitalReadFast: 100618us    1op time: 0.05 ops/s: 19.88 M/s
 GPIOx->IDR: 90834us    1op time: 0.05 ops/s: 22.02 M/s
Attachments
IO_speed_test.zip
(1.47 KiB) Downloaded 24 times

IanNoob
Posts: 15
Joined: Wed Oct 07, 2020 5:35 pm

Re: Blue Pill running slow

Post by IanNoob »

That is fantastic GonzoG. It works and I agree with your timings (approximately).

Now I need to do some serious studying to see what is different between yours and mine.

Thanks again.

Ian

IanNoob
Posts: 15
Joined: Wed Oct 07, 2020 5:35 pm

Re: Blue Pill running slow

Post by IanNoob »

Very despondent. I studied GonzoG's code until I understood what was going on, then, using his/her sketch and all the #defines etc I inserted my own code and watched it on a 'scope.

Same problem. digitalWriteFast works a dream producing a pulse train of about 18 pulses in a microsecond, suggesting a clock frequency of 72MHz before loop() and other overheads. Spot on.

digitalReadFast is another issue. Using this code within GonzoG's sketch:

Code: Select all

   if (dRF(PIN3r) == HIGH) {                  // Method A. . Pin 3r is PB3
   dWF(PIN0w,1);
  } else {
      dWF(PIN0w,0);
  }
           
 /* if ( GPIOB->IDR & 0b0000000000001000)  {   // Method B  
      dWF(PIN0w,1);
  } else {
      dWF(PIN0w,0);
  }  
*/
and triggering using a square wave from a Nano, then again using a button, I got VERY erratic and slow responses:
[img]C:\Documents\FTL\Quickest small.jpg[/img]
[img]C:\Documents\FTL\Slowest small.jpg[/img]

The red trace is the trigger pulse, the blue one is the Pill's response. The fastest is about 50uS, the slowest is about 550uS - half a millisecond!

Since the IO is working, what else can be going wrong?

Ian

GonzoG
Posts: 80
Joined: Wed Jan 15, 2020 11:30 am
Answers: 5

Re: Blue Pill running slow

Post by GonzoG »

I don't have oscilloscope, so I used 2 pills (black F411 and blue F103) to do a "ping test" and got about 2-3us response time.

ps. IanNoob, to add images from hdd, you need to add them as attachments.

IanNoob
Posts: 15
Joined: Wed Oct 07, 2020 5:35 pm

Re: Blue Pill running slow

Post by IanNoob »

Well, I cracked it – sort of.
I spent the last week dissecting GonzoG’s code and watching it on the ‘scope. The two fast Read commands show the same waveform and time – about 55nS.
I also worked out how to do this in assembler – and got the same timings and waveform as GonzoG did with C!

I then worked out how to combine Read and Write which is what I wanted, the first stage in a fast ‘stopwatch’.

I wanted to show several ‘scope traces to illustrate some points but the forum wouldn’t accept them as they were too big, then I shrank them and it wouldn’t accept them as there were too many…

So here is one montage of two traces recorded in ‘persistence’ mode – where successive traces are overlaid on each other.

Both show asm pulses from a 5V 16MHz Nano taking 2 clock cycles (125nS) in red.
The blue trace shows the response from a Blue Pill running at default speed (72MHz) which is reading the input from the Nano and responding with a minimal 2 command pulse.
The scatter of the responses is due to the fact that the Pill is getting an input at random timing and is responding according to the ‘railway journey conundrum’.

The top trace is using a stripped down version of GonzoG’s software, the second trace is my first asm. Third is neater trace but with 2 branches in he asm..

What puzzles me is that some of the responses in the top trace are faster while others are significantly slower than those in the lower trace.

Any ideas?
Combined traces single.png
Combined traces single.png (88.87 KiB) Viewed 327 times

Post Reply

Return to “General discussion”