Здравствуйте, уважаемые коллеги.

Второй день уже сижу и думаю. Имеется акселерометр ADXL362 (рабочая партия), подключенный через SPI к микроконтроллеру.
И с него считываются данные ускорений по осям X Y Z (регистры 0х08, 0х09, 0х0А). Точнее должны считываться. Потому что приходит информация только о значении по оси Х.

Читаю и по очереди и списком. Раньше всё работало. Подскажите, что это может быть.

Если вопрос не в этой ветке, переадресуйте.

Сам себе отвечаю.

На сайте AD нашёл.


/* Bit values in POWER_CTL (8 bits allocated) */
#define XL362_STANDBY 0x00
#define XL362_MEASURE_1D 0x01 !!!!!
#define XL362_MEASURE_3D 0x02
#define XL362_AUTO_SLEEP 0x04
#define XL362_SLEEP 0x08


А в даташите этого нет...

Как это нет? А это:
Нажмите для просмотра прикрепленного файла

(Страница 34 ДШ).

Я вот другого не пойму. На стр. 36 есть пример Autonomous Motion Switch. И рекомендуется, среди прочего:

что предполагает Sample rate 6 Гц, как в режиме Wake-up. Но, с одной стороны, в этом режиме inactivity timer не работает, а с другой - при Sample rate по умолчанию - 100Гц (в режиме measurement) для 5 сек паузы нужно писать число 5000. Опечатка?

Странно, но не удаётся отобразить прерывания на выводы INT1 и INT2. Более того, при попытке записывать INTMAP2 после перевода устройства в measurement mode устанавливается бит ошибки ERR_USER_REGS и акселерометр "виснет" - содержимое регистров не обновляется. Сами пины при этом никуда даже не подключены.
Кто-нибудь сталкивался?

Значит, веду репортаж.
Обнаружилась ещё одна "опечатка" (ох, и нервов же потрачено!):
вопреки рекомендациям из ДШ, для конфигурации устройства в качестве Autonomous Motion Switch, необходимо в регистре POWER_CTL устанавливать бит AUTOSLEEP, а не WAKEUP (и ни в коем случае не оба сразу), соответственно, записывая значение 0х06 вместо 0x0A. Иначе акселерометр не реагирует на движение и продолжает работать с частотой 6Гц.
Вот такой нюанс. Я полагал, что режим Sleep и Standby - это одно и то же и из него можно выйти только по сбросу. Что такое WAKEUP без AUTOSLEEP (или с AUTOSLEEP) - ума не приложу. Ведь только из AUTOSLEEP возможно "пробуждение" в нормальный режим.

А что, "это" ?

В даташите стоит "Reserved", а у ТС #define XL362_MEASURE_1D 0x01

Я так подозреваю, что они хотели сделать 1D-режим, но не получилось, не заработал, и в даташите обозвали Reserved.

Возможно, ну и что? К проблемам автора это какое имеет отношение? Если он подключал акселерометр по даташиту, то и работать он должен был в соответствии с даташитом. А как ему помогло то, что он раскопал в каких-то апнотах - осталось непонятным.

Кому непонятным? Очень даже понятным. Он, по видимому случайно, включил этот самый 1D-режим недокументированный, и у него пошли выборки только по оси X, а каналы Y и Z отключились. А теперь, спасибо ему, мы все знаем об интересном полунедокументированном режиме (скорее всего, экономящем питание, если не нужны все 3 оси, а хватает одной, неплохо бы проверить)

В том-то и дело: непонятно, как это произошло. Ведь раньше, по утверждению автора, всё работало. И логично было бы сверять установки с даташитом, а не искать какие-то объяснения отказу устройства работать в нештатном режиме.
Другое дело, что раньше, возможно, этот режим 1D поддерживался и автор ожидал от новой партии аналогичного поведения. Но он об этом ничего не написал, а наоборот, высказался в том духе, что:

То есть, логично предположить, что и раньше "всё" - это значило "все три координаты".
В общем, неясно, чего искал автор.
А режим я проверю, благо плата на столе. Но с экономией питания разработчики и так перестарались, ИМХО. Вот если бы FIFO можно было бы заполнять одной или двумя координатами да ещё выбирать 8-битный режим, это была бы экономия.

Ну тут уж да, как именно это произошло на физическом уровне, это мы не узнаем (да и автор, тоже вряд ли ). Например, случайно цифру не ту нажал и не заметил, когда что-то исправлял... Но ясно то, что по какой то нелепой случайности в регистр занеслось значение Reserved, а раньше было правильное. И оно показало, что на самом деле режим 1D есть и работает. Вопрос на сколько нормально он работает, и почему не описан в ДШ, но описан в апноте...

Мне лично неясен мотив поисков, ведь всего-то нужно было проверить цифирьки...
Указанный дефайн присутствует в коде неизвестного автора, датируемом 2011 годом:


В хедере ADXL362.h автора DNechita (Dan.Nechita@analog.com) от 2012г. режим 1D уже не упоминается.
Я попробовал, действительно в этом случае обновляется только регистр координаты Х. Уменьшается ли потребление - пока не проверял.
Полезна ли эта информация? Сомневаюсь. Не зря, видно, Девицы отказались от этой опции, ведь она, по крайней мере, не помешала бы.
Видимо, с ней есть проблемы. Девайс и так получился уж очень трепетным.

Вот с регистрами INTMAP настоящие чудеса. Если записывать их до включения измерений так:

то регистры не прописываются и акселерометр не работает. Вообще. То же самое, если писать только второй.
Если писать только первый:

то он получает нужное значение (можно проверить чтением), акселерометр работает, но пин остаётся в третьем состоянии.
Если же писать второй (или оба) после включения режима измерений, то возникает ошибка, как я писал выше, и акселерометр - мёртв.
Запись первого после включения измерений проходит, опять же, успешно, но никак не проявляется.
Монтаж проверил уже пятьдесят раз. Перепаивать вручную очень пока не хочется.
Жаль, что автор пропал. Интересно, не было ли у него чего похожего...

Ну это как сказать... Много чего недокументированного оказывается полезным в реальной работе По секрету скажу, что, к примеру, работа эмуляторов TI XDS510 старых, ISA и PCI, до сих пор базируется на недокументированных возможностях Windows. И работает до сих пор во всех ОС

Так что, если этот режим работает, то и может быть полезен кому нибудь... Он ведь явно был в "preliminary data sheet Rev 12b".

По поводу INTMAP, это пожалуй в техподдержку обращаться надо, подробно описав вопрос и приложив примеры.

Но ведь наверняка убрали не без причины. Казалось бы, лишний плюс...

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

Проверил, наконец, другой экземпляр. Как и следовало ожидать, всё в порядке. Проблема с прерываниями, похоже, крылась в "сопле" между выводами 9 и 10 под корпусом чипа.
10-й это "Reserved" как-бы... Эх, ну почему для макетирования не выпускать микросхемы в нормальных корпусах?! Ох, уж эта погоня за размером!
Ладно бы, но дайте альтернативу, а то ведь без breakout board под каждый элемент - уже никуда...

Спасибо за подробные ответы. Позвольте ещё два вопроса.

Сразу извиняюсь за кросспостинг.

1) В процессе работы (после сильной тряски) акселерометр стал выдавать 0xFF. В нормальное состояние работы удалось вернуть опять только сильным встряхиванием. Это действительно в датчике что-то западает?

2) Значения акселерометра откалиброваны при 2.0 вольтах. Работает он (как ни странно) на 3.3 В для обеспечения совместимости с микроконтроллером. Соответственно сдвинуты уровень нуля и шкала. Ввиду отсутствия требуемого оборудования, настройку производил просто:
определял максимальные по модулю значения в положении к нормали силы тяжести "+" и положении "-". И вычислял среднее смещение. Допустим было +37 (для +1g) и -29 (для -1g). Смещал на 4. Получал +33 и -33. И относительно этого получал значения. Возможно ли получить точное смещение уровня нуля, поставив датчик перпендикулярно?

А я против самоизвинений. Как и нарушения правил.
Это вряд ли. Судя по документации, акселероментр способен испытывать значительные перегрузки без ущерба для работоспособности. Откуда читались данные - из FIFO? Может, просто режим был выбран триггерный и буфер был целиком заполнен?
А чего тут странного? В даташите указано, что это вполне в рамках нормального.
И даже график приведен, как меняется чувствительность от напряжения питания.

Вопрос, что считать точным. Не надо забывать и о шуме. Усредняйте - и получите.