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

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

Кстати о птичках — я дисплеи обычно заказываю тут.
Они почти все как ваш номер 3. Это не реклама, я с этим магазином никак не связан, но может быть кому-то пригодится.
Месяц назад заказывал себе такой, поиграл с ним и сломал перепаивая его на 16 бит, позавчера заказал размером побольше.
Это он и есть, похоже.
Хм, а зачем вы перепаивали, если это можно регулировать программно? Возможно, я ошибаюсь, но вроде бы пинами там задается только начальный режим. Обратившись по 8-битному интерфейсу к регистру 0x0C, RGB Display Interface Control, можно поменять значение нескольких бит, и выставить 16-бит шину.
На том который достался мне 8 или 16 бит устанавливаются (если верить документации) очень очень очень мелким smd резистором. Вроде нормально перепаял, но дисплей всё равно сдох. Вечерком обратно перепаяю, может я где то накосячил.
Вам достался точно такой же, они не просто на одном и том же контроллере, но и, похоже, вообще не различаются.
Резистором задается начальный режим, насколько я понимаю. То есть интерфейс, по которому вы должны начать свое общение с контроллером дисплея. После, обратившись к регистру настройки интерфейса, вы можете его сменить программно.

Во всяком случае, так я понял даташит.
Спасибо! Попробую реанимировать.
Спасибо, коллега, статья очень полезная — у меня как раз завалялся такой дисплей, а STM32 для меня сейчас — основное направление деятельности. Но у меня есть пара вопросов:

1) Я правильно понимаю, что вы не используете прерывания по завершению передачи DMA и даже не проверяете флаг готовности? Если так, то код на малых частотах может работать некорректно.

2) Вот этот вопрос не только к вам, но также ко многим STM32-падаванам: почему вы отказываетесь использовать STM32F* Standard Peripheral Library, а вместо этого работаете напрямую с регистрами периферии, при этом даже не приблизившись к пределу производительности камня? Читабельность кода падает, а выигрыш в скорости мизерный и не критичный для такого кода. Я замечал подобное уже не раз, но, согласно моим экспериментам, SPL «тормозит» только в отладочной сборке, при этом проверяя аргументы функций на корректность и упрощая отладку. В релизной сборке с оптимизациями SPL обычно максимум в 3 раза медленнее прямого доступа к периферии, но при этом код читать и править куда проще.

Прошу всех STM32шников поучаствовать в обсуждении, но рассуждать объективно, без эмоций (некоторые принимают подобные вопросы как обвинение или вызов).
1) Да, не проверяю, и, разумеется, в случае «боевого» кода так делать нельзя, но этот код демонстрационный и частоты смены кадров заведомо позволяет DMA успеть завершить передачу)

2) Этот вопрос я рассматривал в первой статье, чтобы понимать как работает SPL неплохо бы знать, как внутри устроены контроллеры периферии, поэтому я фокусирую внимание на работе непосредственно с регистрами в своих статьях.
Полностью поддерживаю позицию по SPL, использую её везде и работать с кодом намного легче. Не нужно всё время вспоминать регистры. + В исходниках библиотеки в заголовках расписана последовательность работы с библиотекой и собственно переферией — как инициализировать, как настраивать, и т. д. Не говоря уж о вложенных примерах.
А у меня обычно получается так, что процессор обрастает собственной библиотекой периферии, с одинаковым интерфейсом для разных платформ. При этом я активно использую средства С++.
Ожидается наплыв спроса на брелки-фоторамки )
Брелок я сам не прочь потестить. Даже не столько из-за дисплея (честно, после дисплеев с е-бей вообще не хочется возиться с выковырянными неизвестно откуда дисплейчиками без док на контроллеры и без нормальных разъемов), сколько из-за того что довеском будет Li-Ion, флешка и классный корпус)
Есть большое желание развести плату под СТМку, по размерам соответствующую плате из брелока и сделать мобильный девайс.
В брелках слишком уж мелко всё внутри, как в мобильниках, не подключиться. Можно плату с аккумулятором засунуть вот в такой относительно карманный корпус: iron.snop.ru/ (этот толстый за счет Ethernet'ного magjack'а, но такие же корпуса бывают более тонкие).
Поддерживаю Mini-STM32 — заказывал такой, работает сразу из коробки :-)

Насчет высоких частот и макетки — подозреваю ошибку монтажа.
Схемы на 1-10Мгц на макетке у людей работают, а тут частоты существенно скромнее.
Паразитные емкости в 10pF, пусть даже 100pF — это не то, что может так меандр расколбасить.
Монтажа там, как такового, не было. Просто отладочная воткнутая в макетку, осцил — на соседних пинах.
Это, конечно, было давно — надо бы перепроверить как-нибудь. Но тогда было именно такое впечатление.
К тому же — это не меандр расколбасило, графики в разных масштабах. Это с соседнего пина, который настроен на инпут (высокий импеданс то бишь, без подтяжки) снимался меандр в ~100 мВ, как при довольно неплохой емкостной связи.
Сам-то меандр вполне чистенький.
Ааа… Это болталась дорожка в воздухе… Так оно и на печатке так бы болталась )
Вот выдай на соседнюю линию 0, и тогда будем смотреть какие там помехи :-)
Ну так если это будет какой-нибудь аналоговый вход, то разработчика ждет неприятный сюрприз.
Поэтому я и говорю — с этим нужно считаться. На печатке можно отвести дорожку куда следует)
Но вообще — да, вся эта помехозащищенность — та еще морока, при разводке можно затра замучаться весьма и весьма, пока помехи уберешь.

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