Yes - thanks for responding.
I think I figured it out The short versions is this.
Like you said --- the Mini is 16MHz and the ProMini is 8Mhz. My code interacts with SPI and the radiohead library which probably uses interrupts. The 16MHz Mini can manage the timing much better than the 8MHz ProMini so I'm seeing a much bigger performance hit than just 2x.
Iif you are interested in the longer story, here it is:
Here was my puzzle. When I ran identical code, on both devices I saw this:
Yellow Trace is the ProMini - Blue Trace is the Mini.
So .... the Mini is going ~8 times faster. Why??
I used a simple timing loop:
void setup() {
Serial.begin(115200);
pinMode(3, OUTPUT);
}
int t1;
int t2;
void loop(){
t1 = millis();
for(long i=0;i<10000;i++){
digitalWrite(3, HIGH);
digitalWrite(3, LOW);
}
t2 = millis();
Serial.println(t2-t1);
}
and yes, you are right, for this code, my ProMinis are running at 1/2 the rate of my Minis.
ProMini prints: 182
Mini prints: 91
My larger program (~700 lines) uses both SPI to run a DotStar led strip (from adafruit) and code from the RadioHead library with a 433MHz radio unit (SYN470R).
So, I expanded the timing snippet to include these two libraries so it can receive rf packets and send SPI commands. For testing, my transmitter sends a packet each 1000 ms.
void loop(){
counter++;
setStripSolid(blu);
digitalWrite(3, HIGH);
setStripSolid(red);
digitalWrite(3, LOW);
if ( (counter%100)== 0){
Serial.print(millis()-t1);
Serial.print("\t");
t1 = millis();
}
read_rf_commands();
}
Using SPI AND checking for RF packets:
Pro Mini:
645 651 rf[:5] cmd:4406316117
615 rf[:5] cmd:44063164250
633 645 rf[:5] cmd:44063168225
643 rf[:5] cmd:44063172201
616 601 rf[:5] cmd:44063176177
Mini:
91 90 91 90 90 90 90 90 89 90 90 rf[:5] cmd:440664981
92 90 90 90 90 91 90 90 90 90 90 rf[:5] cmd:440665357
91 90 91 90 89 89 89 90 90 90 90 rf[:5] cmd:440665733
92 90 90 90 90 90 90 90 89 90 89 rf[:5] cmd:44066619
92 90 90 90 90 90 91 90 90 90 90 rf[:5] cmd:4406664241
So mini runs 90ms loops and the ProMini takes ~630ms. Faster, but not exactly 8x - only about 630/90 = 7 times faster with this code. Hmm, maybe not simply a prescaling issue.
Then I commented out the SPI commands:
// setStripSolid(blu);
// setStripSolid(red);
and changed
if ( (counter%100)== 0){
to
if ( (counter%1000)== 0){
to get better timing resolution.
ProMini
434 426 rf[:5] cmd:440753873
430 666 rf[:5] cmd:440754249
440 424 rf[:5] cmd:440754625
444 453 442 rf[:5] cmd:44075501
453 440 rf[:5] cmd:4407553233
435 434 rf[:5] cmd:4407557209
446 443 rf[:5] cmd:4407561185
Mini:
61 59 59 59 59 58 59 58 59 58 58 59 59 58 59 58 60 rf[:5] cmd:440731449
93 61 62 61 62 61 60 61 61 61 60 62 60 60 62 61 rf[:5] cmd:44073147241
63 61 62 61 62 61 60 61 61 61 60 62 60 61 61 61 rf[:5] cmd:44073151217
63 58 59 58 59 59 58 59 59 59 59 58 58 60 58 60 59 rf[:5] cmd:44073155193
Still Mini is running 430/60 or a bit more than 7x faster than the ProMini.
Then I restored the setStripSolid calls and just commented out the read_rf_commands();
Exactly 206ms for the ProMini and 69 for the Mini --- so just 3x faster.
So it looks like interacting with SPI and the interrupts that the radiohead library might be using slows the ProMini down much more than the 50% that one might expect when comparing 8MHz device vs the 16MHz Mini.
I looked on the boards and the microcontroller ICs are different:
ProMini - Atmel 328PB
Mini - Atmel 328P
The 328PB (ProMini) has additional features as described in:
[https://www.pololu.com/file/0J1464/Atmel-42559-Differences-between-ATmega328P-and-ATmega328PB_ApplicationNote_AT15007.pdf](https://328P vs 328PB)
But the 328PB it is supposed to be able to do everything that the 328P does:
from the dataSheet:
The ATmega328PB is not a drop-in replacement for ATmega328 variants, but a
new device. However, the functions are backward compatible with the
existing ATmega328 functions. Existing code for these devices will work in
the new devices without changing existing configuration or enabling new
functions. The code that is available for your existing ATmega328 variants
will continue to work on the new ATmega328PB device.
So maybe what I'm seeing has more to do with 8MHz vs 16MHz than processor capability.
