Measuring processing time

Projects Programming
1

Hi,
again I found a curious effect during testing with SoftwareSerial on an ATtiny84.
I wanted to check processing time of divisions with 16bit and 32bit values with following sketch:

#include <SoftwareSerial.h>

SoftwareSerial mySerial(5, 6);  // RX, TX

uint32_t baudrt, t0, t1;
uint16_t lcnt = 0;
uint8_t val8;
uint16_t val16, val16_z;
uint32_t val32, val32_z;
int32_t valm32;
int16_t valm16;

void setup() {
  // put your setup code here, to run once:
  baudrt = 38400;
  mySerial.begin(baudrt);
  delay(50);
  mySerial.println();
  mySerial.print("Baudrate=");
  mySerial.println(baudrt);

  val16 = 2233;
  val32 = 1234567890;

  t0 = micros();
  for (int i = 0; i < 10000; i++) {
    val16_z = val16 / 10;
    val16++;
  }
  t1 = micros();
  mySerial.print("16bit Division, 10000 mal, dauern ");
  mySerial.println(t1 - t0);

  t0 = micros();
  for (int i = 0; i < 10000; i++) {
    val32_z = val32 / 10;
    val32++;
  }
  t1 = micros();
  mySerial.print("32bit Division, 10000 mal, dauern ");
  mySerial.println(t1 - t0);

}

void loop() {
  // put your main code here, to run repeatedly:

}

The increments within the loops were intended to avoid optimizations of the compiler to reduce processing times.

The results on the Serial Monitor are usec:

Baudrate=38400
16bit Division, 10000 mal, dauern 4
32bit Division, 10000 mal, dauern 44

This means that 1 16bit division takes 0.4 nsec on an ATtiny84 with 16 MHz external clock. The clock period is 62 nsec.

Here I have fantastic controller :slight_smile: But what is wrong?

2

I’d be more interested in the effects of running Ss at anything over 9600 (or maybe 19200 at a pinch).

SS is software-bound to meet the timing requirements, so the combined effect is on both the program and serial comms.

SS is a convenient workaround for small processors, the ONLY solution to reliable code and comms in this case is a second hardware UART, or a tightly written software serial module on a much faster cpu.

3

Since the contents of the loop has no side effects, the loop was optimized away. Making some of the variables 'volatile' eliminates much of the optimization and get a more realistic result:

volatile uint16_t val16, val16_z;
volatile uint32_t val32, val32_z;

16bit Division, 10000 mal, dauern 141712
32bit Division, 10000 mal, dauern 418616

So: uint16_t division took 14.2 microseconds each and uint32_t took 41.9 microseconds each.

4

As mentioned in your other thread concerning the abs() function, with the ATTiny core a default Software Serial is already built so you don't need to include the "standard" one unless you have special pin requirements.
The pins are fixed at TX: PA1 and RX: PA2. The actual Arduino pin numbers depend on which build option (clockwise/anti-clockwise) you select.

5

The optimizations within the compiler are really very smart when it can detect that the loop has no side effects.
Thank you, the tip with "volatile" is helpfull and I will use it in future.

6

Yes I have special pin requirements. Therefore I selected SoftwareSerial in a first step. But now I am working on a further serial link because SoftwareSerial occupies timer 1 which I need in my application.

7

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.