Как стать автором
Обновить

Комментарии 10

А почему нельзя было взять какую-нибудь армовскую платку из клонов малины и не заморачиваться с ковырянием планшета?

Сначала все таки мы использовали RPi3 для первого приближения, я об этом упомянул. А планшет демонстрируется (нашему) конечному заказчику, которому надо видеть более приближенный к реальности результат. Кроме того, разница между планшетом и RPi есть, и нам надо было в этом разобраться, раньше или позже.
Кроме того, разница между планшетом и RPi есть

А можно об этом по-подробнее?

Наибольшая разница была в ядре, даже несмотря на то, что для RPi и планшета мы использовали разные версии Android OS — 7.1 и 4.4 соответственно.


Для RPi наиболее ходовыми версиями, которые можно запустить без особых проблем являются (насколько я вычитал тогда) 6.х и 7.х. Там достаточно новое ядро, более 4.х, если не ошибаюсь, и оно использует device tree для объявления устройств. Структура и примеры device tree очень хорошо описаны (вот тут: https://www.raspberrypi.org/documentation/configuration/device-tree.md), и расширенный, по сравнению, со стандартным device tree формат позволяет делать многие вещи еще проще.


В планшете же, ввиду старого ядра, device tree нет. Там код загрузки, который надо было дописать. Не то чтобы проблема, но заодно пришлось прочитать многие, лежащие около исходники. Кроме этого, производители телефонов/плашетов и т.п. если и дают свои исходники, то там всегда есть закрытая часть (хотя у RPi тоже). И она почти всегда плохо описана и требует практических примеров того, как этим пользоваться. У nvidia множество функций с префиксом tegra_, которые делают массу разного и зачастую неизвестного.


Отладка — отдельная проблема… в статье есть о том как она не заработала, причем именно на этой версии устройства с кодовым именем grouper. На других устройствах из линейки nexus многие работают, но не все.


Ну и сообщество RPi с уже отвеченными вопросами в значительно большей вероятности сможет чем-то помочь, по сравнению с поиском ответов о том, какие устройства сидят на определенных шинах tegra3. В итоге, на планшете гораздо чаще приходилось пользоваться осциллографом и i2c декодером, чтобы понять что чего-то в супе не хватает.


Т.е. в целом, одно и то же, но "есть нюансы" :)

А зачем надо было спускаться в ядро? Ведь шиной i2c и GPIO можно управлять и из user mode.
Разработка должна была упроститься, и даже не нужен был бы дебажный UART.
  1. Целевые GPIO заблокированы на уровне SoC. Т.е. надо лезть в включать их в именно в ядре
  2. GPIO по умолчанию не экспортируются, поэтому сначала нужно было бы сделать их экспорт (не знаю, возможно ли это в конфигах, и не уверен, что можно это сделать находясь уже в userspace), а затем дописать дополнительные правила из части selinux. Будет ли это проще?..
  3. Читая про HAL и его специфику решили, что не стоит туда выносить функциональность коммуникации. К тому же, итоговый драйвер имеет более расширенную функциональность.

Но, пожалуй, главное — то, что, в итоге, имея драйвер, а не модуль middleware, проект будет легче модифицировать так, что этот сенсор будет добавлен в HAL Sensors и станет доступен через стандартное API.


Вот тут (https://source.android.com/devices/sensors/) про этот HAL написано, если что

Вообще был смысл вынести в userspace то, что нужно лишь на прототипе. Я правильно понимаю, что «питание переключать и режим измерения» не будет нужно в production?

Сейчас еще (или до сих пор) неизвестно, что именно будет нужно в production. Так что, кто знает, как оно еще обернётся.

Круто. Давно что-то не было подобных статей. Спасибо.

Спасибо :)

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории