Measuring 30b CPU speed reduction

[Marcus von Cube]

(08-14-2015 01:10 PM)Csaba Tizedes Wrote:  

(08-12-2015 04:55 PM)Marcus von Cube Wrote:  The RC oscillator runs...

OK, all of above posts are really interesting, but only one thing is missing: give me a number for 30b: from 100% to what percentage reduced the program running speed after 1 sec?! Thnx!

Csaba

The exact figures must come from the authors of the 30b firmware but from what I have understood, the ratio should be some 38 MHz / 2 MHz. So the speed reduction factor is around 19.

[Csaba Tizedes]

(08-14-2015 09:37 PM)Marcus von Cube Wrote:  The exact figures must come from the authors of the 30b firmware but from what I have understood, the ratio should be some 38 MHz / 2 MHz. So the speed reduction factor is around 19.

Thank you - but I think these values are not right OR I'm totally wrong.
Check the attached pdf file. You can find the whole measurement from 0 sec to 60 secs. As you can see the data points are fits well to two lines and the intersection is approx. at 2 sec (not 1 sec) - I'm a mechanical engineer and I'm experienced to measuring something and I was very careful during this measurement.

The values of the two slope is the speed of counting (count/sec dimension). You can see the change at 2 sec and the ratio is only 3.27 (the original ratio is based on that the change of CPU speed is occured at 1 sec)

What is your opinion?

Csaba

[Marcus von Cube]

Interesting graph!

Your measurements look reasonable. So either the full speed of 38MHz is not used in the firmware or the slow mode clock is not generated by the 2 MHz RC oscillator. I don't think that the flash wait state has such an impact. My deduction comes form my knowledge of the hardware but I have no access to the original firmware code. Only Cyrille or Tim can solve the mystery for us.

[cyrille de brébisson]

Hello,

OK, I had a look in the 30b source code and what it does is that it counts the number of executed program steps and once it reaches 16384, it drops the CPU speed to 10Mhz.
So in theory you should get a 3.6* speed ratio, but since the speed to executed instructions is not linear (as discussed earlier), you get a little bit more speed than that.
I do not remember why 10Mhz was chosen at the time, but that is what it does.

The solver and IRR calculations also do something similar, but after 200 iterations.

Cyrille

[peacecalc]

If you divide the slopes csaba had measured (2680/820) you get as a ratio 3.27, near by 3.6 from cyrille. That this takes place after 2 sec instead of 1 sec (predicted in the manual) is maybe a effect liable of counting the executed program steps.