Попробовал найти какую-нибудь информацию про эту команду на сайте Мегафона — там ничего.
Гугл находит только какие-то старые стати на сайтах разной степени сомнительности.
Так что не факт что это работает.
Если решите брать Dell — не покупайте их usb3.1 док станцию (TB16)
Её так и не смогли довести до состояния, чтобы в ней нормально работал USB. И соответственно вся периферия в док станции (Ethernet, звук) и всё USB устройства подключенные через неё работают совершенно не стабильно.
Типичная ситуация — подключил любое USB устройство к доку — все остальные USB устройства перестали работать. Иногда отваливается просто так.
Одинаково глючно работает и на Windows и на Linux.
Обновления прошивки периодически приходят, но лучше не становится.
Случай не единичный — у всех коллег, у кого эти док станции, тоже проблемы с ней.
Замена дока не помогает.
Понравилась фраза из какого-то обсуждения про этот док:
I am considering using the TB16 as a doorstop; it's more stable that way.
Многие проблемы с форматированием кода решаются прогоном получившегося патча/файла через скрипт checkpatch.pl (есть в исходниках ядра linux, исходниках u-boot)
Он укажет на плохое форматирование / использование устаревших функций / некоторые проблемы с патчем итд.
Перед отправкой патчей в апстрим весьма полезная штука.
Кстати, а Android клиент в пресобраном виде где-то выкладывают?
А то заглянул на официальный сайт — там только ссылка на плей маркет.
Возможно я не там ищу?
LS013B7DH06 — трансфлективный, цветной, низкопотребляющий. Похож на тот, что в новых часах pebble time стоит, только от sharp-а.
про 16 бит у меня написано, да и не ставилась цель рассказывать про битность
Просто если организовывать обмен на прерываниях, то можно сократить количество прерываний аж в два раза. Если просто в цикле ожидать, то да, смысла нет.
DMA и прерывания вы не сможете удобно и эффективно использовать при передаче «солянки» из данных и команд
Не вижу никаких проблем. Сначала пишем команду с данными в буфер, потом пересылаем буфер с помощью DMA/прерываний. Собственно, я так и сделал.
Немного позанудствую:
1) Вы везде пишете STM32, но упоминание конкретной линейки я не нашёл. Это стоит добавить, так как в разных линейках может встречаться (и встречается) разная реализация ip-ядер одних и тех же интерфейсов.
Всё дальнейшее справедливо для линейки STM32L1**
2) Вы везде упоминаете про быстродействие. Тогда уже стоит упомянуть, что контроллер SPI может может пережёвывать данные по 16 бит за раз. (смотрите бит SPI_CR1_DFF)
К тому же вместо бессмысленного ожидания лучше использовать прерывания или DMA. PS: недавно как раз подключал дисплей к STM32L151 по SPI. Код писал на прерываниях — всё заработало без проблем с первого раза. По-моему в reference manual всё достаточно хорошо про работу SPI расписано.
Гугл находит только какие-то старые стати на сайтах разной степени сомнительности.
Так что не факт что это работает.
Её так и не смогли довести до состояния, чтобы в ней нормально работал USB. И соответственно вся периферия в док станции (Ethernet, звук) и всё USB устройства подключенные через неё работают совершенно не стабильно.
Типичная ситуация — подключил любое USB устройство к доку — все остальные USB устройства перестали работать. Иногда отваливается просто так.
Одинаково глючно работает и на Windows и на Linux.
Обновления прошивки периодически приходят, но лучше не становится.
Случай не единичный — у всех коллег, у кого эти док станции, тоже проблемы с ней.
Замена дока не помогает.
Понравилась фраза из какого-то обсуждения про этот док:
I am considering using the TB16 as a doorstop; it's more stable that way.
Он укажет на плохое форматирование / использование устаревших функций / некоторые проблемы с патчем итд.
Перед отправкой патчей в апстрим весьма полезная штука.
А то заглянул на официальный сайт — там только ссылка на плей маркет.
Возможно я не там ищу?
LS013B7DH06 — трансфлективный, цветной, низкопотребляющий. Похож на тот, что в новых часах pebble time стоит, только от sharp-а.
Просто если организовывать обмен на прерываниях, то можно сократить количество прерываний аж в два раза. Если просто в цикле ожидать, то да, смысла нет.
Не вижу никаких проблем. Сначала пишем команду с данными в буфер, потом пересылаем буфер с помощью DMA/прерываний. Собственно, я так и сделал.
1) Вы везде пишете STM32, но упоминание конкретной линейки я не нашёл. Это стоит добавить, так как в разных линейках может встречаться (и встречается) разная реализация ip-ядер одних и тех же интерфейсов.
Всё дальнейшее справедливо для линейки STM32L1**
2) Вы везде упоминаете про быстродействие. Тогда уже стоит упомянуть, что контроллер SPI может может пережёвывать данные по 16 бит за раз. (смотрите бит SPI_CR1_DFF)
К тому же вместо бессмысленного ожидания лучше использовать прерывания или DMA.
PS: недавно как раз подключал дисплей к STM32L151 по SPI. Код писал на прерываниях — всё заработало без проблем с первого раза. По-моему в reference manual всё достаточно хорошо про работу SPI расписано.
Вот цитата из их характеристик:
Дисплей — думаю что-то из e-paper.
теперь ещё и третья.
Хотя, конечно, хотелось бы увидеть разборку прибора.