Исправление KivApple, (текущая версия) :
Новая информация: тормозит таки математика.
#define BYTE_SWAP(x) ((uint16_t)((((uint16_t)x << 8) | ((uint16_t)x >> 8))))
...
accel_x = ((int16_t)BYTE_SWAP(mpu6050_response[0])) / 8192.0;
accel_y = ((int16_t)BYTE_SWAP(mpu6050_response[1])) / 8192.0;
accel_z = ((int16_t)BYTE_SWAP(mpu6050_response[2])) / 8192.0;
temperature = ((int16_t)BYTE_SWAP(mpu6050_response[3])) / 340.0 + 36.53;
gyro_x = ((int16_t)BYTE_SWAP(mpu6050_response[4])) / 32.768 * M_PI / 180.0;
gyro_y = ((int16_t)BYTE_SWAP(mpu6050_response[5])) / 32.768 * M_PI / 180.0;
gyro_z = ((int16_t)BYTE_SWAP(mpu6050_response[6])) / 32.768 * M_PI / 180.0;
Вот этот код. Все переменные типа float. На AVR на таком же (по смыслу, писал этот код с нуля) коде тормозов не было (он отрабатывал за примерно 1 мс). Интересно, что если убрать либо преобразования, либо чтения по I2C, то скорость становится нормальной. Тормоза именно когда математика обрабатывает реальные данные, а не нули. Я проверял ассемблерный листинг - оптимизатор ничего не выкидывает, когда я убираю куски, так что замеры нормальные.
А ещё МК перезагружается при попытке использовать %f в snprintf. Это кажется мне несколько странным, но snprintf мне уже не нужен, так что это не так уж критично. Но вообще это не нормально. Почему 16-битный МК тормозит на float-арифметики, которую спокойно переваривает 8-битный? Да ладно бы немного тормозил, так разница практически в 10 раз.
Исправление KivApple, :
Новая информация: тормозит таки математика.
#define BYTE_SWAP(x) ((uint16_t)((((uint16_t)x << 8) | ((uint16_t)x >> 8))))
...
accel_x = ((int16_t)BYTE_SWAP(mpu6050_response[0])) / 8192.0;
accel_y = ((int16_t)BYTE_SWAP(mpu6050_response[1])) / 8192.0;
accel_z = ((int16_t)BYTE_SWAP(mpu6050_response[2])) / 8192.0;
temperature = ((int16_t)BYTE_SWAP(mpu6050_response[3])) / 340.0 + 36.53;
gyro_x = ((int16_t)BYTE_SWAP(mpu6050_response[4])) / 32.768 * M_PI / 180.0;
gyro_y = ((int16_t)BYTE_SWAP(mpu6050_response[5])) / 32.768 * M_PI / 180.0;
gyro_z = ((int16_t)BYTE_SWAP(mpu6050_response[6])) / 32.768 * M_PI / 180.0;
Вот этот код. Все переменные типа float. На AVR на таком же (по смыслу, писал этот код с нуля) коде тормозов не было (он отрабатывал за примерно 1 мс). Интересно, что если убрать либо преобразования, либо чтения по I2C, то скорость становится нормальной. Тормоза именно когда математика обрабатывает реальные данные, а не нули. Я проверял ассемблерный листинг - оптимизатор ничего не выкидывает, когда я убираю куски, так что замеры нормальные.
Исходная версия KivApple, :
Новая информация: тормозит таки математика.
#define BYTE_SWAP(x) ((uint16_t)((((uint16_t)x << 8) | ((uint16_t)x >> 8))))
...
accel_x = ((int16_t)BYTE_SWAP(mpu6050_response[0])) / 8192.0;
accel_y = ((int16_t)BYTE_SWAP(mpu6050_response[1])) / 8192.0;
accel_z = ((int16_t)BYTE_SWAP(mpu6050_response[2])) / 8192.0;
temperature = ((int16_t)BYTE_SWAP(mpu6050_response[3])) / 340.0 + 36.53;
gyro_x = ((int16_t)BYTE_SWAP(mpu6050_response[4])) / 32.768 * M_PI / 180.0;
gyro_y = ((int16_t)BYTE_SWAP(mpu6050_response[5])) / 32.768 * M_PI / 180.0;
gyro_z = ((int16_t)BYTE_SWAP(mpu6050_response[6])) / 32.768 * M_PI / 180.0;
Вот этот код. Все переменные типа float. На AVR на таком же (по смыслу, писал этот код с нуля) коде тормозов не было (он отрабатывал за примерно 1 мс). Интересно, что если убрать либо преобразования, либо чтения по I2C, то скорость становится нормальной. Тормоза именно когда математика обрабатывает реальные данные, а не нули. Я проверял ассемблерный листинг - оптимизатор ничего не выкидывает.