0

At the moment I test the sha256 performance of mbedTLS on a stm32f7 nucleo board. I measure the elapsed cycles of the stm32 board with the cycle counter register. The formula of measurement looks something like this:

DWT->CYCCNT = 0;
uint32_t dwtStart = DWT->CYCCNT;
//uncomment for mbed calculation mbedtls_sha256();
//uncomment for atecc508a calculation atecc508a_sha256();
uint32_t dwtStop = DWT->CYCCNT;
double dStart = (double) dwtStart;
double dStop = (double) dwtStop;
// SystemCoreClock is a constant = 216000000
double result_in_milliseconds = (dStop-Start)/SystemCoreClock * 1000;

I've testet the sha command on a on a microchip atecc508a which performs hardware hashing and it takes about 18ms to hash 32 Byte of data.

With the mbedTLS in only takes about 0.05ms to hash 32 Byte of data in software.

I know that I have to keep in mind, that a communication via i2c takes additional time for an operation, but are these results even legit? Could there be such a discrepancy between those two operations?

Both operations return the corresponding hash to a certain input of 32 Bytes.

Would be really thankful, if someone could answer my question.

Habebit
  • 957
  • 6
  • 23
  • 1
    As an embedded developer, there's absolutely no point in doing that computation as `double`s, even on your honking big F7. – unwind Feb 21 '19 at 14:24
  • Also, that is 10,800 clock cycles, which is not totally unreasonable but I'm not familiar enough with the algorithm to say for sure. – unwind Feb 21 '19 at 14:37
  • @unwind You are absolutly right! I've rounded the results for better readability next time I will provide the correct values. My mistake. – Habebit Feb 21 '19 at 15:09

1 Answers1

4

At standard I2C speed (100kbit/s) you can transfer

0.018*100000 = 1800 bit = 225 byte

in 18ms (including overhead). This is not a whole lot, so yes, it seems reasonable that most of the time is used up by the i2c communication.

Ctx
  • 18,090
  • 24
  • 36
  • 51