Arduino.ru

1. Вы неправильно понимаете: в многобайтовой переменной первым идет младший байт (так же, как и на Intel).

2. Давайте отделять мух от котлет, если хотите разбираться в приведении типа, забудьте об акселерометре и используйте обычные массивы. Если хотите разбираться с акселерометром, так и пишите (и, думаю, тему надо было создавать в аппаратном разделе).

Да кстати, я совсем забыл, что существуют такие системы, как little/big endian. Тогда ясно.

Насчет акселерометра - вообще не суть, это я для примера привел. На его месте вполне могло быть другое устройство, ну или просто побайтная передача данных.

Хорошо, значит, указатель ссылается на младший байт. Значит, нужно просто менять местами эти байты, чтобы отображались корректные данные? Сейчас попробую.

Но тогда вопрос - почему работает такая запись:

int16_t  _data[7];
for(uint8_t i = 0; i < 7; i++)
    _data[i] = Wire.read() << 8 | Wire.read();

Ведь считываемые регистры данных расположены в порядке от старшего к младшему, и получается, что первый прочитанный байт смещается влево...

Возьмем тупо целое число 0x1234 и запишем его в массив data[0]=0x1234; Элемент data[0] занимает в памяти 2 байта. В памяти число 0x1234 запишется как 0x34, затем 0x12.
Это понятно?

Да, сначала записывается младший байт, а затем старший, с большей "разрядностью". Но как это изменит то, что "смещаемые" влево, казалось бы, старшие байты вдруг оказываются младшими?

Нужно отделять мух от котлет. Разделяй этот процесс на части. Т.е. сначала мы формируем целое значение, считывал данные по байтам. Первое чтение Wire.read() дает нам старший байт, второе - младший. Сначала собираем целое значение. Предположим мы считали сначала 0x12, затем 0x34. Собираем целое и получаем 0x1234. Далее его записываем в data[0], но это я уже писал выше.
Поскольку ты еще учишься, не морочь себе голову и не смешивай два процесса, формирование целого и запись его в память.

Спасибо, так и сделал, сейчас все работает корректно. Но все-таки я не понимаю - почему первый вызов Wire.read(), смещенный влево, оказывается вдруг младшим байтом? Или это все же второй вызов?

Есть многобайтные переменные, которые в разных устройствах хранятся по-разному. К примеру, тот же MPU9250 имеет встроенный магнитометр, у которого хранение байтов - прямо противоположное, т.е. сначала записывается младший, а за ним старший байт. Ну и, все-таки хотелось бы разобраться, как записывать данные "побайтово" в многобайтные переменные, даже если формат записи в регистрах устройства такой же, как и в памяти контроллера.

Потому что так написано в даташите. Сначала в регистрах идет старший байт, за ним - младший. Вот я и думаю, почему первый вызов Wire.read(), который, казалось бы, должен считать старший байт и сместить его влево, почему-то считывает младший байт?

Famouspilot, в регистре не может быть "сначала" и "потом".

Внутри регистра нет адресации. 

Порядок может быть (и есть) в памяти, где:

1. Существует адресация.

2. Длина минимально адресуемого элемента меньше длины рассматриваемого объекта.

Так что весьма маловероятно, что в дэйташите может быть написанео нечто, напоминающее Ваше утверждение.

Да, прошу прощения, под "регистрами" я имел в виду регистры ведомого I2C устройства.

Ну да, для ведомого устройства такая организация достаточно характерна. Мне даже довелось иметь дело с устройством, минимально адресуемый элемент которого имел длину 2 бита (т.е. на байт приходилось 4 последовательных адреса).

Не побоюсь спросить, что это за интересное устройство было?

Вообще-то не I2C.

Микросхема управляемого фильтра max261. Там режим фильтра задается 32 разрядами. Протокола обмена нет, есть, как и положено, 3 параллельных шины: данных, адреса и управления. Вот по количеству расходуемых контактов и была проведена оптимизация.

Шина управления, в общем-то, без вариантов: для мультиплексирования адреса слишком короткий сам адрес.

А вот сумму шины данных и шины адреса можно попробовать пооптимизировать. Очевидно, для 32 разрядов можно:

- 32 данных, 0 адреса, всего: 32,

- 16 данных, 1 адреса, всего: 17,

- 8 данных, 2 адреса, всего: 10,

- 4 данных, 3 адреса, всего: 7,

- 2 данных, 4 адреса, всего: 6,

- 1 данных, 5 адреса, всего: 6.

Т.е. по общему количеству контактов два равноправных варианта, но первый из них вдвое эффективнее с точки зрения времени необходимого для установки режима работы.

Я пытался помочь, но дальше без меня. Еще раз говорю, автор, определись с задачей и не смешивай всё в одну кучу.

Вот преобразование к 16-ти битам из rawdata. Взято из Вашей, ишаком долбаной, библиотеки от акселерометра.

Перестаньте размножать людям мозг своей тупостью.

void MPU9250::readAccelData(int16_t * destination)
{
  uint8_t rawData[6];  // x/y/z accel register data stored here
  // Read the six raw data registers into data array
  readBytes(MPU9250_ADDRESS, ACCEL_XOUT_H, 6, &rawData[0]);

  // Turn the MSB and LSB into a signed 16-bit value
  destination[0] = ((int16_t)rawData[0] << 8) | rawData[1] ;
  destination[1] = ((int16_t)rawData[2] << 8) | rawData[3] ;
  destination[2] = ((int16_t)rawData[4] << 8) | rawData[5] ;
}

В регистрах данные лежат в ИНВЕРСНОМ, Вашу ять, порядке. Старший байт, потом младший.

Чтобы получтить целое, 16-ти битное, нужно их поменять местам. Что и сделано в библиотеке.

=================

Каждое ...удло считает своим долгом объявить, что компилятор, контроллер, стандарт языка, китайцы-призводители и Господь Б..г - ошибаются!

Нет мля, ошибка - она в ДНК!

Да, спасибо, в моей *Ишаком долбаной* библиотеке проблемы подобного рода исправлены. А тупость... Ну знаете ли, все когда-то начинали задавать тупые вопросы. Я еще не такой ТСарь и Б-г программирования, как Вы.