Авторизация
Зарегистрироваться

TOF050C + OLED = дальномер

Не так давно на Aliexpress появились модули лазерных дальномеров, основанные на датчиках VL6180X (или подобных) от фирмы STM. Причем их стоимость на удивление низкая. Например, модуль TOF050C за 2.1 USD, не считая пересылки. Измерять расстояния особой потребности нет, но на работе понадобился источник коротких световых импульсов для проверки фотоприемников, для чего данный датчик идеально подошел. Чтобы он не светил зря, я решил задействовать и его основную функцию – измерение расстояния. Просто в ознакомительных целях.



По меркам человека из прошлого века, такой датчик – это просто фантастика. Внутри маленькой микросхемы расположен лазер, фотоприемник, а также схема измерения микроскопических интервалов времени, за которые свет успевает дойти до препятствия и вернуться обратно. Датчик способен измерять даже такое малое расстояние, как 10 мм, которое свет проходит туда-обратно за время примерно 67 пикосекунд!


Данная технология измерения расстояния называется FlightSense, более подробно о ней можно почитать на сайте STM.


В качестве излучателя в датчике используется VCSEL-лазер. Расшифровывается как «Vertical-Cavity Surface-Emitting Laser», или «поверхностно-излучающий лазер с вертикальным резонатором». Произносится как «Vixel». В отличие от обычных полупроводниковых лазеров, где излучает торец кристалла, тут излучение происходит в направлении, перпендикулярном поверхности кристалла. VCSEL-лазеры имеют целый ряд полезных свойств, в частности, у них очень низкий порог генерации по току. Что позволяет их использовать в датчиках мобильных устройств, где вопрос экономии энергии стоит очень остро.

Лазер датчика работает в ИК-диапазоне, длина волны 850 nm. Лазер излучает очень короткие импульсы. Длительность импульса примерно 3.3 нс, период повторения импульсов – 10 нс.

В качестве приемника излучения в датчике используется массив SPAD-фотодиодов. Это «Single Photon Avalanche Diode», или «однофотонные лавинные фотодиоды». Они способны регистрировать одиночные фотоны, выдавая на выходе электрический импульс. Для питания таких фотодиодов требуется довольно высокое напряжение. В описании датчика говорится про 14 В, для чего внутри имеется умножитель напряжения.

Дополнительно VL6180X имеет датчик окружающего света (ALS, Ambient Light Sensor). Он может быть использован для измерения освещенности в широком диапазоне, в том числе, при очень низкой освещенности (порядка 1 lux). Максимум спектральной чувствительности датчика лежит на длине волны 550 nm. На рисунке из datasheet показаны диаграммы направленности излучателя, приемника и датчика ALS.


Чтобы сделать из датчика полноценный дальномер, нужен процессор, который будет считывать показания датчика, и нужен дисплей, куда процессор будет выводить результат. В качестве процессора я выбрал ATmega88, так как макетная плата с ним лежала ближе всего. В качестве дисплея сначала планировал применить LCD, но захотелось чего-то более компактного, поэтому выбрал OLED-дисплей с разрешением 128 х 32 точки и диагональю 0.91 дюйма. Дисплей был куплен на Aliexpress (старая ссылка уже не работает, но аналогичные дисплеи есть по другим ссылкам), обошелся примерно 1.6$ вместе с доставкой.



Занятие электроникой в настоящее время довольно сильно изменило свою форму. Сейчас редко приходится проектировать схемы целиком из «элементарных» компонентов, таких как резисторы, конденсаторы, транзисторы, диоды. Сначала появились микросхемы и заменили собой значительные фрагменты схем, а теперь получили распространение готовые модули, которые просто надо соединить между собой. Получается некое подобие детского конструктора из кубиков.

Как правило, сейчас каждый модуль имеет цифровой интерфейс и подключается к микроконтроллеру. Появляется дополнительная задача программной поддержки модулей. Но и тут действует тот же принцип строительства из кубиков – существует большое количество готовых библиотек. В чем сильно помогла платформа «Arduino». Ее многие ругают, но совершенно напрасно. Она резко снизила планку вхождения в электронику и программирование, приобщив к этому занятию множество людей. А с претензиями по поводу надежности можно поспорить. Схемы и платы там вполне обычные, сделаны хорошо. А программное обеспечение – это еще вопрос, что надежнее, самодельная программа, написанная и протестированная одним человеком, или библиотека, которой пользуются тысячи людей, каждый из которых жадно ищет ошибку, чтобы первому о ней объявить. Сам я эту платформу не использую, но лишь потому, что вошел в мир электроники и микроконтроллеров намного раньше, чем она появилась.

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

Даже собирая систему из кубиков, не всё так просто и гладко. Хоть задача сводится в основном к организации питания кубиков и согласования их между собой, тут тоже хватает подводных камней. В данном случае требуется соединить микроконтроллер с дисплеем и датчиком, а также запитать всё это.

Выбранный OLED-дисплей построен на базе контроллера SSD1306. Кристалл этой микросхемы имеет огромное количество выводов (целых 281) и расположен на стекле дисплея. Основная часть выводов соединена с матрицей светодиодов. У контроллера 128 выводов предназначено для управления столбцами, и 64 вывода для управления строками (из которых тут задействована только половина, так как разрешение дисплея 128 х 32 точек).

Внутри контроллера имеется видеопамять, каждой бит которой соответствует точке на экране. Чтобы зажечь точку, надо записать единичку в нужный бит по нужному адресу. Общий объем видеопамяти – 1024 байта (8192 бит).

Кроме видеопамяти внутри контроллера имеются регистры конфигурации. Они позволяют управлять его работой. Чтобы дисплей заработал, после включения питания надо провести инициализацию – записать в нужные регистры нужные коды.

Контроллер поддерживает 5 видов последовательных и параллельных интерфейсов, мой вариант дисплея имеет последовательный интерфейс SPI. Существует еще вариант с управлением по шине I2C. Вариант с SPI позволяет быстрее передавать данные, но требует для подключение большего количества проводов (и выводов микроконтроллера). Для данного проекта скорость обновления экрана не особо важна, можно было применить любой вариант. Выбрал тот, который был под рукой.

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

На плате дисплея расположена вся необходимая «обвязка» контроллера SSD1306. Это блокировочные конденсаторы, «летающие» конденсаторы для встроенного умножителя напряжения, опорный резистор для задания тока через светодиоды пикселей. Принципиальная схема нашлась на страничке продавца.


Контроллер SSD1306 питается напряжением 3.3 В, для этого на плате установлен отдельный стабилизатор XC6206P-33 (маркировка 662K). На контакт VCC разъема платы можно подавать 5 В. Но сигналы цифрового интерфейса идут напрямую на контроллер, соответственно, имеют логические уровни 3.3 В.

Поскольку здесь возможна только запись данных, то все логические сигналы являются входными. Иногда логические микросхемы могут иметь логические входы, «толерантные» к напряжению, превышающему напряжение питания самой микросхемы. Примером могут служить некоторые входы микроконтроллеров STM32 или входы логики серии 74LVC. Для SSD1306 это не так, входы имеют обычные защитные диоды, подключенные к питанию. Если на логический вход подать сигнал с уровнем 5 В, то микросхема начинает питаться от этого сигнала через защитный диод. На выводе питания появляется напряжение, которое ниже входного примерно на 0.65 В, что является типичным прямым падением на кремниевом диоде. Поэтому подавать на дисплей логические сигналы с уровнями 5 В нельзя. Как тогда быть в системах с напряжением питания 5 В? Можно применить резисторные делители. Но надо учитывать, что они могут ограничить максимальную скорость передачи данных из-за паразитных емкостей. Для устройств с жесткими требованиями к потребляемому току делители тоже могут не подойти – при высоком логическом уровне они постоянно потребляют ток. Еще один вариант – использовать выходы с открытым стоком. Но в микроконтроллерах AVR нет возможности реализовать выходы с открытым стоком для аппаратного SPI. Самое надежное решение – применить преобразователи уровней на МОП-транзисторах или в виде интегральной микросхемы.

А что же с питанием датчика TOF050C? Микросхема датчика питается напряжением 2.8 В, для чего на плате модуля установлен стабилизатор напряжения. В результате модуль можно питать напряжением 5 В или 3.3 В, этого будет достаточно для работы LDO-стабилизатора на 2.8 В. На плате модуля есть и другая «обвязка», принципиальная схема нашлась на страничке продавца.


Модуль имеет интерфейс I2C, линии SDA и SCL со стороны микросхемы датчика подтянуты резисторами к питанию 2.8 В. Затем эти линии проходят через преобразователи уровня, выполненные на сборке полевых транзисторов 2N7002DW (маркировка K72), и только потом поступают на разъем модуля. Со стороны разъема они подтянуты резисторами к входному питанию. Таким образом, уровень логической единицы этих сигналов будет равен напряжению питания модуля и может быть как 3.3 В, так и 5 В.

Кроме сигналов SDA и SCL микросхема датчика имеет еще два логических сигнала: INT и SHUT. Они поступают на выводы модуля прямо с выводов микросхемы и преобразователей уровней не имеют. Для этих сигналов уровень логической единицы равен напряжению питания микросхемы, т.е. 2.8 В. На плате модуля они подтянуты резисторами к этому напряжению. Сигнал INT формирует микросхема при окончании цикла измерения. Сигнал SHUT по умолчанию работает как вход сброса. Уровень сигнала INT (2.8 В) с трудом вписывается в допустимый диапазон для логической единицы на входе микроконтроллера с напряжением питания 5 В. Поэтому здесь требуется преобразователь уровня. Входом сброса, в принципе, можно управлять с помощью выхода с открытым стоком, подтягивающий резистор уже есть на плате модуля.

Как видим, при питании микроконтроллера напряжением 5 В возникает масса проблем. Это заставило пересмотреть выбор напряжения питания. У дисплея в сумме 5 сигналов (SCK, SDA, RES, DC, CS), это требует 10 резисторов делителей, что довольно громоздко. Еще нужен преобразователь уровня для сигнала INT датчика расстояния. От всего этого можно отказаться, если перевести питание микроконтроллера на 3.3 В. Правда, при этом потребуется небольшая переделка дисплея: нужно выпаять микросхему стабилизатора 3.3 В и установить вместо нее перемычку. Это несложно, но «из коробки» использовать модули, как ни странно, не получается.

Первым делом решил разобраться с дисплеем. В Интернете можно найти библиотеки для работы с ним. Если бы мне нужно было побыстрее сделать проект, взял бы все готовое. Но это неинтересно, хочется написать код самостоятельно, лишь иногда подсматривая в чужие исходники. В готовых библиотеках всегда что-то не так, как хотелось бы, да и при использовании готового сложно получить представление о всех возможностях железа.

Самой таинственной операцией является процесс инициализации дисплея. Он выглядит как какое-то заклинание – по определенным адресам записываются определенные коды. Разобраться в этих кодах не так просто. Казалось бы, достаточно прочитать datasheet на контроллер дисплея. Но там не будет конкретики, касающейся именно этого дисплея. Потому что контроллер универсальный, и он может быть использован по-разному. Существуют datasheet на дисплеи с этим котроллером (например, вот), но не факт, что они в полной мере соответствуют имеющемуся дисплею от непонятного производителя. Самое смешное, что даже в datasheet нет толкования отдельных загружаемых в регистры значений – всё те же магические числа, взявшиеся неизвестно откуда.

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

Во-первых, код инициализации будет зависеть от размеров дисплея. Обычно он отличается кодом в двух регистрах:

Set Multiplex Ratio (A8h) = 1Fh для 128 х 32, 3Fh для 128 х 64
Set COM Pins Hardware Configuration (DAh) = 02h для 128 х 32, 12h для 128 х 64

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

Set Segment Re-map (A0h/A1h) – зеркалит/не реркалит по горизонтали
Set COM Output Scan Direction (C0h/C8h) – зеркалит/не зеркалит по вертикали

Еще можно менять значение контраста изображения, хотя чаще всего обходятся значением по умолчанию.

Есть два регистра, значения в которых зависят от выбранного способа питания OLED-матрицы: внешнее, или с использованием встроенного преобразователя. В данном модуле дисплея используется встроенный преобразователь.

Set Pre-charge Period (D9h) = 22h – внешнее питание, F1h – внутренний преобразователь
Charge Pump Setting (8Dh) = 10h – внешнее питание, 14h – внутренний преобразователь

Встречал в Интернете обсуждение минимизации помех индикатора с помощью регистра Set Pre-charge Period. Но пришли к выводу, что на уровень помех он не влияет. По моим наблюдениям – тоже. Надо отметить, что потребляемый OLED-дисплеем ток носит импульсный характер и зависит от выводимой картинки. Помех получается больше, чем от LCD-дисплеев, в некоторых применениях это может быть критично. Максимальный потребляемый ток этого дисплея составил 24 мА.

Самый загадочный регистр – это Set VCOMH Deselect Level (DBh). Его значения могут быть 00h, 10h, 20h, 30h, 40h, 50h, 60h, 70h. Он управляет напряжением V_COMH, которое выведено наружу (на плате модуля установлен блокировочный конденсатор), и которое можно измерить. В datasheet приведены 3 варианта кодов, но в библиотеках обычно туда загружают другой код (40h). Попробовал менять это значение – при коде 40h напряжение V_COMH максимально, дальнейшее увеличение кода ни на что не влияет.
В документе AN001 «OLED Driver Basic Register Setup» от фирмы Osram есть интересная табличка, где описаны симптомы неправильного программирования регистров контроллера OLED. Про напряжение V_COMH сказано, что при слишком низком могут быть артефакты взаимного влияния пикселей (cross-talk), а при слишком высоком может пострадать надежность дисплея.


Когда дисплей подключен и инициализирован, на него можно выводить желаемую информацию. Для этого я написал небольшой набор функций и адаптировал несколько шрифтов, которые ранее использовал для LCD. Дисплей оказался настолько маленьким, что для отладки функций вывода пришлось использовать микроскоп. Чаще всего возникают «краевые» ошибки, когда не хватает одного пикселя или появляется один лишний. Рассмотреть отдельный пиксель здесь довольно затруднительно.



При написании функций вывода на дисплей всплыла очень неприятная особенность контроллера. Дело в том, что при использовании последовательного интерфейса контроллер не позволяет читать данные из видеопамяти. Поэтому невозможно делать обновление изображения по принципу «чтение-модификация-запись». Контроллер поддерживает разные режимы адресации видеопамяти, которые можно задавать при инициализации дисплея. Но всегда адресация по вертикали делается с точностью до байта (здесь это называется Page). Если выводим что-то на дисплей, что по высоте занимает меньше байта, то перезаписывается весь байт. Например, если выводим строчку текста, которая затрагивает по вертикали только часть байта, оставшуюся часть нельзя использовать для вывода следующей строчки – будет стерта нижняя часть предыдущей. Приходится распределять экран таким образом, чтобы отдельные объекты размещались в отдельных байтах. Это накладывает существенные ограничения на дизайн интерфейса.

Конечно, такую проблему легко решить – в памяти микроконтроллера надо выделить буфер, равный по размеру видеопамяти. Сначала рисовать там, а потом копировать буфер в память дисплея (весь, или только изменившиеся байты). Но для младших микроконтроллеров это не всегда возможно из-за недостатка ОЗУ. Для ATmega88 и дисплея 128 х 32 буфер использовать можно, но уже для дисплея 128 х 64 это станет невозможным, так как буфер займет всё ОЗУ микроконтроллера.

Обидно, что данную проблему можно было очень легко обойти на этапе проектирования ASIC контроллера дисплея. Достаточно было для адресации по вертикали использовать не байты (Page), а строки. Т.е. границы блока, подлежащего обновлению, задавать с точностью до пикселя. Передаваться будут целые байты, как обычно, но те биты, которые лежат за границей блока, будут маскироваться и не будут записываться в видеопамять. В итоге видеопамять за пределами блока никогда не будет испорчена, даже если границы блока проходят внутри байта. Но, увы, здесь этого нет.

Для данного проекта, когда надо выводить фактически только одну строку, такой изъян адресации помешал не сильно. Но если потребуется выводить что-то более сложное, надо либо брать процессор с ОЗУ побольше, либо придумывать какие-то хитрости с обновлением дисплея.

В целом OLED-дисплей понравился, он дает контрастную картинку с очень хорошими углами обзора. Дисплей с диагональю побольше выглядит еще лучше, надо будет в будущем сделать на нем какой-нибудь проект. Единственный вопрос – это срок службы таких дисплеев. Но и тут всё не так плохо, если судить по имеющимся тестам. Да и не все устройства должны работать круглосуточно.

Подключение датчика TOF050C при питании процессора 3.3 В не вызывает проблем. Логический уровень выхода INT согласуется непосредственно. Вход SHUT тоже можно подключить к процессору напрямую – превышение 3.3 В над 2.8 В недостаточно для открывания защитных диодов. Но я решил на всякий случай использовать выход с открытым стоком – так правильней.

Инициализация микросхемы VL6180X – это вообще сущий ад. Ради единичного и не слишком важного проекта изучать 87-страничный datasheet не совсем уместно. Кроме datasheet, есть еще User manual UM1983 «VL6180X proximity, gesture and ambient light sensing (ALS) module », DT0035, DT0037 и другие документы. А еще есть Application note AN4545 «VL6180X basic ranging application note» где приведена готовая таблица магических заклинаний, которые надо по I2C передать внутрь микросхемы, чтобы она ожила. К счастью, магия сработала, подробно разбираться с вопросом не пришлось. Это ведь не OLED-дисплей, который может быть полезен и для других проектов. Датчик расстояния вряд ли придется еще когда-либо использовать, глубокие знания тут скорее окажутся бесполезными. Как бы то ни было, макет с датчиком и дисплеем ожил и начал показывать расстояние.


Некоторые странности при работе датчика все-таки были обнаружены. При отладке питал конструкцию от лабораторного БП. Когда ее подключал к включенному заранее БП, все работало нормально. Но когда сначала подключал, а потом включал БП, то из датчика постоянно стал считываться код FFh. Чтобы разобраться, в чем дело, считал значение регистра STATUS. При ошибке считался код 11h (17), что означает ошибку «VCSEL Continuity Test». В норме STATUS читается как 03h. Вероятно, из-за медленного нарастания напряжения питания перестал срабатывать внутренний сброс микросхемы VL6180X. Пришлось задействовать сигнал SHUT, который по умолчанию выполняет функцию сброса микросхемы. Чего в начале я делать не хотел, думал вообще обойтись подключением только двух сигналов – SDA и SCL.

Шина I2C на скорости 400 кГц нормально не заработала, при чтении возникали ошибки. Но на скорости 200 кГц все работало нормально, так и оставил.

При переходе из однократного режима в циклический изредка были зависания датчика, тогда показания замирали. Похоже, по какой-то причине переставал приходить сигнал прерывания. Для защиты от такой ситуации добавил таймер на 100 мс: если прерывание за это время не поступило, вызывается инициализация модуля. Больше зависаний не видел.

Для калибровки показаний датчика служит значение Offset. Процедура калибровки описана в datasheet. Заводское значение Offset записано в энергонезависимой памяти (NVM) и считывается после включения питания. Если я делаю свою калибровку, то, по идее, я могу перезаписать значение в NVM своим значением. Можно ли это сделать, и как – я так и не понял. Плюнул и сохраняю Offset в EEPROM микроконтроллера.

После устранения найденных шероховатостей, можно рисовать окончательную принципиальную схему. У меня она получилась такой:


Питание устройства задумывалось от внешнего БП через разъем. Можно было, конечно, поставить аккумулятор, но мне автономность не нужна. Показания дальномера планировалось не только выводить на дисплей, но и считывать на компьютер через разъем USB. А раз так, то желательно предусмотреть питание и от него. На моей схеме питание от двух источников суммируется через сдвоенный диод VD1. При питании от USB диод шунтируется транзистором VT1 для уменьшения падения напряжения. Эта мера не сильно нужна при питании 3.3 В, для стабилизатора хватит входного напряжения и с учетом падения на диоде. Но данное решение осталось от первоначальной задумки питать процессор напряжением 5 В, решил транзистор оставить.

Теперь надо выбрать корпус и разработать конструктив. В качестве корпуса взял давно купленный на Aliexpress алюминиевый профиль. Плата задвигается в него на салазках, никакого крепления не требуется. Размеры платы получились 57 х 40.5 мм. Плату изготовил с помощью ЛУТ. Плата получилась почти односторонней, вторая сторона залита земляным полигоном, и на ней есть лишь две дорожки питания и одна дорожка для подключения кнопки.


Датчик крепится к передней панели винтами и подключается к плате через разъем. В плату датчика впаяны прямые штырьки PLS. Ответная часть – разъем PBS, который размещается в вырезе платы и припаивается к площадкам на SMD-манер. На фотографии платы в районе этого разъема видны перемычки. Дело в том, что первоначально вырез в плате не планировался, а разъем должен был лежать на поверхности платы. При этом датчик должен был установлен немного выше середины передней панели. Но чувство прекрасного взяло верх, датчик был врезан точно в центр передней панели, а разъем пришлось опустить, сделав вырез. При этом дорожки, которые проходили снизу платы на месте выреза, пришлось восстановить перемычками. Но это внутри, а снаружи все красиво и симметрично.

На задней панели расположен разъем питания, разъем USB и одна кнопка. Для кнопки придумал функцию – переключение абсолютных и относительных измерений. При включении относительных на экране загорается надпись «REL».

Дисплей вставляется в разъем сверху, дополнительно он опирается на две пластиковые стойки с резьбой М2. При разработке платы надо учитывать тот факт, что физический центр активной области дисплея не совпадает с центром платы модуля.


Собранная плата сразу заработала, ведь прошивка была заранее отлажена на макете. Датчик нормально показывает расстояния до 170 – 180 мм, хоть в datasheet гарантируют только до 100 мм. Расстояние представлено однобайтным числом, т.е. может быть от 0 до 255 мм с дискретностью 1 мм. В документе User manual UM1876 «Getting started with VL6180X proximity, gesture, ambient light sensor software expansion for STM32Cube» описана возможность увеличения шкалы расстояний датчика ценой уменьшения разрешающей способности, чего нет в datasheet. Можно включить масштабирование шкалы в заданное число раз: 1, 2 или 3. Но за ненадобностью эту возможность я не проверял.


Для компьютера написал простейшее приложение, которое позволяет выводить показания датчика, а также проводить его калибровку. Калибровка сохраняется в EEPROM микроконтроллера и используется в дальнейшей автономной работе.


Откалибровал датчик по методике, изложенной в datasheet. Там требуется на расстоянии 50 мм расположить поверхность с коэффициентом отражения 88%. На практике коэффициент отражения поверхности влияет слабо, это требование можно не соблюдать. Если показания находятся в пределах ±3 мм, то считается, что калибровка не требуется. В других случаях надо обнулить Offset, провести 10 измерений расстояния, найти среднее значение, и по нему вычислить новое значение Offset.


Осталось вырезать окно для индикатора в профиле и изготовить стекло. Но сначала надо это стекло выбрать. Цвет свечения индикатора – холодный белый, сильно отдающий синевой. Хочется иметь более приятный цвет свечения, чего можно добиться с помощью светофильтра. Больше всего понравилось красное оргстекло, оно дает янтарный цвет свечения, который называется красивым словом Amber. Но это стекло слишком прозрачное, пришлось взять более темное стекло.


Вот так выглядит устройство в сборе:


Что можно сказать в качестве вывода? Модуль дальномера TOF050C работает, и работает неплохо. Но какого-то практического применения для него я не вижу. Как уже было сказано выше, это устройство делалось просто как источник коротких световых импульсов для проверки фотоприемников на работе. Измерение расстояния – это всего лишь приятный бонус.


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


Надо сказать, что проектировать интерфейс на графическом дисплее крайне трудоемко и неудобно. Если делать это сразу на микроконтроллере, то требуется большое количество перепрошивок при отладке, чтобы увидеть, как будет смотреться тот или иной вариант экрана. Для упрощения разработки надо на компьютере написать эмулятор такого дисплея, чтобы с комфортом разрабатывать интерфейс, а потом просто перенести весть текст на Си, вместе с массивами картинок и шрифтами в микроконтроллер. Но это тоже кусок работы, требующий времени. На что именно надо в первую очередь тратить свое время – это тоже вопрос, и на его решение тоже уходит время.
Добавить в избранное +157 +224
свернуть развернуть
Комментарии (197)
RSS
+
avatar
  • nochkin
  • 22 октября 2024, 02:13
+2
Спасибо за обзор.
Как забавно. Как раз заказал себе такой датчик (и ещё VL53L0X за компанию) буквально пару дней назад, а тут муська уже всё об этом знает. Я на них вышел через VCNL4200, который не нашёл по доступной мне цене в варианте с платой.
Если кто знает похожие датчики с сенсором окружающего освещения и измерения расстояния до 2 метров по i2c, то буду признателен.

Кстати, по поводу «проектировать интерфейс на графическом дисплее крайне трудоемко и неудобно», то есть LVGL. Но, справедливости ради, там и МК нужен потолще. Зато можно на PC смотреть результат.
+
avatar
  • Leoniv
  • 22 октября 2024, 02:33
+5
По датчикам на 2 м ничего не могу сказать.

Не оставляет вопрос, а зачем в датчик расстояния встроили датчик освещенности? Какая связь?

По поводу LVGL — это что-то слишком сложное. Моя врожденная особенность — работать с самыми простыми микроконтроллерами. Пытался работать с STM32, но за 10 лет так и не смог к ним привыкнуть — не помещаются в мозг.
+
avatar
  • nochkin
  • 22 октября 2024, 04:01
0
Хороший вопрос. Возможно что уже сенсор для освещения есть для приёма отражённого света и вопрос только в микрокоде датчика.
У меня с проектом так получилось, что мне для реализации надо как раз оба датчика и было бы приятно обойтись одним модулем. Но я уже сдался и буду запихивать два модуля. Недавно сделал заказ и жду по почте.

LVGL для начала мне показалась немного громоздкой, но потом распробовал. Но я вообще халявщик и мне в этом плане повезло — у меня ESP32, RP2040, Cortex M7.
+
avatar
  • Leoniv
  • 22 октября 2024, 12:15
0
Так а зачем конкретно Вам датчик освещенности? Здесь он работает в видимом диапазоне, а дальномер — в ИК. Между ними, вроде, вообще никакой связи быть не может.
+
avatar
  • nochkin
  • 23 октября 2024, 03:45
+1
В смысле зачем? Мне надо знать когда стемнело. Потенциально фоторезистора должно хватить, но я просто не хотел заморачиваться с ADC если есть такая возможность.
+
avatar
  • Leoniv
  • 23 октября 2024, 10:57
-1
Это понятно, но хотел узнать, зачем именно надо знать, когда стемнело?
+
avatar
  • nochkin
  • 23 октября 2024, 20:20
0
Прошу прощения, не сразу понял. Подсветку делаю. Надо что бы срабатывала когда только темно и есть кто-то рядом.
+
avatar
  • Leoniv
  • 23 октября 2024, 20:49
-1
Спасибо, теперь понятно.
+
avatar
  • Zolg
  • 22 октября 2024, 10:07
+2
Подозреваю, что по конструкторской задумке датчиком предполагается измерять расстояние до уха пользователя смартфона. Ну и заодно освещенность, чтоб два окна в корпусе онного не делать
+
avatar
  • Leoniv
  • 22 октября 2024, 12:16
0
Чтобы не пилить два окна — вот это вполне возможное объяснение. А задачи у датчиков совсем разные и не пересекаются.
+
avatar
  • boyscout
  • 22 октября 2024, 14:20
0
Как предположение. Для сравнения яркости разных источников света (светильников например) требуется контролировать расстояние до них для корректности измерений.
+
avatar
  • Zolg
  • 22 октября 2024, 15:17
+3
Задачи у датчиков пересекаются в том, что и тот и другой могут применяться в смартфоне и при этом находиться плюс-минус рядом. Один корпус (к тому же с единой шиной) разместить-развести на плате смартфона проще (и дешевле). Да и сама комбинированная корпусировка скорее всего дешевле, чем два корпуса по отдельности. При прочих равных производитель смартфонов вероятнее отдаст предпочтение более дешевому (как в закупке, так и в применении) чипу.
Вот и сделали такой комбайн под них. Модули для диайвай лишь побочное следствие дешевизны массового продукта.
Была бы возможность упихивать в тот же корпус mems-динамик — может быть впихнули бы и его.
+
avatar
  • Johnmat
  • 22 октября 2024, 13:14
+1
UL53LDK
2 метра. I2c.
Подключается за 5 минут без бубнов.
+
avatar
  • Leoniv
  • 22 октября 2024, 13:45
+1
Подключается за 5 минут без бубнов.
Если повезет. А вообще у датчика очень сложный API, так сходу и не разобрался, где там описание на уровне регисторов. В datasheet этого нет, есть user manual UM2039, но и там нет полного описания.
+
avatar
  • Johnmat
  • 22 октября 2024, 14:02
0
Какой api какая сложность с i2c?
В еспхоум две строчки описание. Внутрь лезть нет никакой необходимости.
+
avatar
  • Leoniv
  • 22 октября 2024, 14:24
+2
Внутрь лезть нет никакой необходимости.
Это под вопросом. Мне пришлось разбираться с регистрами.
+
avatar
  • Johnmat
  • 22 октября 2024, 15:22
+1
Есть библиотеки. Для любой среды разработки. Все как часы.
Разве что лоу левел нужно, ассемблер там, место там сэкономить… но это уже узкая специализация.
+
avatar
  • aliex
  • 22 октября 2024, 15:39
+8
Забейте, тут разница восприятия. Одни хотят полного контроля и понимания, что происходит, другие — абстрактного описания, достаточного для решения конкретной задачи. Грубо говоря, одни из ассемблера пришли, другие — из джавы. И тем, и другим альтернативный лагерь кажется безумным (а в крайностях — таковым и является, собственно).
+
avatar
0
еще есть третий вариант: типичное несуществование «полной» документации на все и вся.

да и зачем оно нужно, если применяешь по назначению и именно этот вариант задокументирован.

более того, вся внутренняя кухня регистров и всего прочего скорее всего изначально не должна торчать наружу и может произвольным образом меняться в следующих ревизиях микросхем (или в зависимости от производителя).
а вот интерфейс общий, им и надо пользоваться.
+
avatar
  • aliex
  • 22 октября 2024, 16:09
0
Ну да. Но это, опять же, более высокоуровневый подход, не всем с ним комфортно, хотя со сложными системами альтернатив, по большому счёту, и нет. Судя по тому, что автор пишет «Пытался работать с STM32, но за 10 лет так и не смог к ним привыкнуть — не помещаются в мозг. » — у него более «олдскульные» привычки.
+
avatar
  • Leoniv
  • 22 октября 2024, 16:21
+2
Без копания в мелочах у меня почему-то ничего не работает, так как хочется.
+
avatar
  • aliex
  • 22 октября 2024, 16:28
+1
Это другой подход. Я переехал более-менее (заняло кучу времени), но я не с эмбеда начинал, а на десктопе с ассемблера.

Тут ключевое — хотеть то, что заведомо поддерживается нижележащим уровнем, а если не выходит — тупо менять этот самый уровень, а не пытаться выжать всё. И смотреть на стоимость не в тиках процессора и байтах памяти, а в долларах и часах разработки.

По моему мнению — всё равно все там будем, сложность-то растёт.
+
avatar
  • Leoniv
  • 22 октября 2024, 16:55
0
У каждого поколения свои методы работы. «Все там будем» — это и спасет. На наше место придут другие, они не будут начинать с таких мелочей.
+
avatar
  • aliex
  • 22 октября 2024, 17:06
0
Ну… я за время работы пару раз привычки успел сменить, и раз надеюсь ещё лет десять хотя бы побарахтаться в разработке — то ещё минимум разок придётся. Вон, нас уже помаленьку гоняют на использование ИИ для генерации кода, например. На удивление — джунов заменяет вполне прилично, я так понимаю — года за три станет нормой.
+
avatar
  • Leoniv
  • 22 октября 2024, 17:46
-1
Менять привычки — это же неприятно… Если не участвовать в бешеной гонке за деньгами, то можно и избежать.
+
avatar
+1
А почему гоняют за использование ИИ, если он вполне прилично заменяет джунов?
Потому что я сейчас как раз захожу в разработку с позиции джуна на пару с ИИ.
И этот ИИ для меня пока что лучший ментор
+
avatar
  • aliex
  • 22 октября 2024, 20:46
0
Из того, что я знаю — основное — это то, что ИИ — это, по умолчанию, слитая «дяде» корпоративная информация, поэтому разрешён он там, где это предусмотрено менеджментом, заключены соответствующие соглашения с вендором ИИ, обычены сотрудники — что ему можно скармливать, что нет, и так далее. Может ещё что-то, тут у всех по-разному.

ИИ как ментор — э… не знаю, может быть и работает. Но вообще я не очень представляю, как это. Задача ментора — объяснить, почему выбрана такая-то архитектура кода, как ещё можно сделать и тому подобное. Неужто уже и это умудрились на ИИ перетащить?
+
avatar
+1
Да, ИИ нормально объясняет почем это так сделано, как это работает, почему это не работает и как сделать лучше. Или предложит вариант как сделать с ноля, если вообще ничего не понятно. Потом можно все поправить, задавая корректирующие сообщения «переделай это с паттерном ХХХХ» и т. д.
На уровне джуна он вроде норм, а на уровне мидла и выше начинает проседать. Ну это пока. И у ИИ есть правила конфиденциальности — тот же copilot используют многие и норм.
+
avatar
  • aliex
  • 22 октября 2024, 21:49
0
Ага, подрос-таки, судя по всему. Насч'т правил конфиденциальности — компании не устраивают, они свои договорі заключают.
+
avatar
+1
Одно это то, что подрос.
Второе насколько он еще вырастет.
Потому что даже сейчас — я бэк, и на данном уровне ИИ позволяет мне писать фронт к моему бэку и фронт даже худо-бедно работает и я даже чуть понимаю что к чему.
То есть может на мобилке он работает криво, но на компе нормально.
При этом он будет развиваться.
+
avatar
  • Leoniv
  • 22 октября 2024, 16:22
+1
Ну я по собственному опыту. Много раз ничинал с шапкозакидательства, типа, возьму готовую библиотеку. И каждый раз что-то не устраивало.
+
avatar
  • avihome
  • 23 октября 2024, 09:32
0
Обычное дело :) Если твои хотелки не совпадают с таковыми у разработчика библиотеки, то обычно проще все самому сделать, чем бороться с этой. Но некоторые выбирают вариант «приспособиться» и так получается дешевле.
+
avatar
  • Leoniv
  • 23 октября 2024, 10:58
-1
«Дешевле» для хобби не аргумент.
+
avatar
  • avihome
  • 23 октября 2024, 11:27
0
Для хобби, да :) Ну и для хобби тоже бывают этапы, когда учишься, хочешь что-то понять, когда этот элемент не главный, бывает проще «приспособится». Мне ваша позиция понятна, сам так часто делаю.
+
avatar
  • Leoniv
  • 23 октября 2024, 11:37
-1
Да, я понимаю, что для эффективности надо пользоваться чужими наработками. Но для этого приходится наступать себе на горло. В чужом не нравится всё, начиная от форматирования текста исходников. У меня, возможно, не лучше, но по-другому, привычнее. В готовых библиотеках всё не так. Например, когда-то пытался использовать SPL для STM32. Когда посмотрел их код, то появилось ощущение, что начинаю лепить свою программу из дерьма.
+
avatar
  • Johnmat
  • 23 октября 2024, 11:14
+4
Ну смотрите. Этот конкретный датчик. Что вы от него хотите?
1. Расстояние.
2. Ээээээ да больше нафиг ничего не нужно

В используете аттини с 128 байтами памяти? Нет?

Теперь вопрос. Зачем апи ассемблер коды и прочая фигня если оно за минимальное время показывает вам расстояние?

Зы. Если что я старпер и писал на все ассемблерах начиная с 4040 8080 ес эвм и заканчивая 586 всему свое предназначение.
+
avatar
  • Leoniv
  • 23 октября 2024, 11:22
-1
В том-то и дело, что я не хочу от него расстояние. Для чего делался этот проект, я написал. Мне надо получить импульсы света с определенной периодичностью. Вот этой периодичностью и пришлось управлять через регистры. А измерение расстояния — тут всего лишь бонус. Но и как Вы описали, не всегда получается с готовой библиотекой. В моей практике всегда что-то было не так. Можно, конечно, смириться. Но хобби оно и есть для того, чтобы с чем-то разбираться, а не тупо написать 2 строчки — и всё.
+
avatar
  • aliex
  • 23 октября 2024, 11:41
+1
Ага, вот теперь всё ясно. То есть вы используете устройство не по назначению и для этого лезете туда, куда, по-хорошему, не должны. А если делать то, для чего компонент предназначен — то будет пять строк, как выше и говорили.
+
avatar
  • Leoniv
  • 23 октября 2024, 11:56
-1
Да, вполне возможно, что будет пять строк. Но опять же, по собственному опыту — всегда в библиотеках попадались какие-то шероховатости. Приходится выбирать: потратить усилие воли на то, чтобы закрыть на них глаза, или потратить усилие на исправление.
+
avatar
  • Archie
  • 22 октября 2024, 02:16
0
пришлось использовать микроскоп
А зачем МБС в чёрный цвет покрасили? :-)
+
avatar
  • Leoniv
  • 22 октября 2024, 02:26
+1
Это был изначально ОГМЭ-П2 в сильно страшном состоянии.
+
avatar
0
А программное обеспечение – это еще вопрос, что надежнее, самодельная программа, написанная и протестированная одним человеком, или библиотека, которой пользуются тысячи людей, каждый из которых жадно ищет ошибку, чтобы первому о ней объявить.
Ну, тут ответ очевиден :)

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

Что касается контроллеров дисплея, так сделаны многие — без оптимизации на слабые микроконтроллеры. Хотя, казалось бы, чуть-чуть еще доработать и стало бы лучше. В этом плане подключение через 8-битный интерфейс удобней (и быстрей), но требует много проводов и свободный порт МК.

Кстати, при питании 3.3 В у AVR максимальная частота ниже.

Для упрощения разработки надо на компьютере написать эмулятор такого дисплея, чтобы с комфортом разрабатывать интерфейс
Это, прямо, оверкил. Сейчас тоже занимаюсь устройством с графическим дисплеем, и для себя пришел к выводу, что самый простой способ проектирования UI — рисование на ПК картинок в фотошопе. Можно подобрать нужные шрифты, использовать слои, графические фигуры, битмапы, и т.д., и, в результате, получается набор объектов с точными пиксельными координатами, которые уже легко перенести в код.

Вы пишете, что используете ЛУТ для двухсторонних плат. Я так понимаю, это в домашних условиях делается? А как совмещаете рисунок дорожек? И производите ли какую-либо металлизацию отверстий? Например, у вас «мама» для дисплея запаяна со стороны дорожек. Без металлизации это сделать достаточно сложно.
+
avatar
  • Leoniv
  • 22 октября 2024, 03:19
+8
Но код там, в большинстве своем, к сожалению, ужасен.
Поэтому по возможности переписываю всё сам.

рисование на ПК картинок в фотошопе
Картинки я, конечно, тоже рисую. Но чаще в векторном редакторе, так мне удобней. Допустим, экран, что на последнем фото, был разработан именно таким образом.

Но хочется пойти дальше — не только рисовать статические картинки, но и моделировать рисование в real-time каких-то графических объектов, навигацию в меню, вывод сообщений и прочее. Причем код можно полностью переносить на микроконтроллер. На компьютере будет только дополнительная «прослойка», заменяющая собой микросхему контроллера дисплея. Мысль написать такой эмелятор возникла давно, и я обязательно это сделаю, работы там не так много. Забавно, но на днях, когда искал информацию по OLED, на Github прочитал точно такую же мысль — человек хочет написать такой же эмулятор. Так что мое желание не такое уж безумное.

По платам — да, двухсторонние делаю сам. Печатаю обе стороны на журнальных страницах, затем на просвет совмещаю и скрепляю степлером. В получившийся конвертик вкладываю плату и утюжу. Переходные металлизирую с помощью заклепок из медного провода. Но если надо сверху впаять разъем, тогда сложнее — приходится в отверстия впаивать тоненькие проволочки. Но таких мест на платах как правило мало. Про изготовление плат (и прочего) я когда-то полдробно писал в ЖЖ, можно поискать по тегу lut или по другим тегам.
+
avatar
  • 00svd00
  • 22 октября 2024, 03:35
+3
Вероятно, вам может помочь этот проект
wokwi.com/
Эмулятор дуин, еспшек и стмок. Экраны вроде как тоже эмулирует(по крайней мере в примерах есть)
+
avatar
  • Leoniv
  • 22 октября 2024, 12:13
0
Нет, мне не нужен эмулятор микроконтроллера. Нужен чисто графики, и лучше свой, чтобы была возможность править под текущие потребности. Это не проблема, напишу.
+
avatar
  • deBocsh
  • 23 октября 2024, 17:36
0
Нет возможности сейчас посмотреть, но у Mikroe кажется была среда разработки экранов. Не помню совсем работала ли она стендалон или только внутри их среды. Но можно пользоваться и их средой, есть Паскаль, С и Бейзик, библиотек огромное количество, есть внятные. Посмотри, Леонид, может понравится: mikroe.com
Если не смущает пиратский флаг, то на торрентс ру был 21 года.
+
avatar
  • Leoniv
  • 23 октября 2024, 19:47
-1
Спасибо, но мне проще написать свое, чем разобраться с чужим.
+
avatar
  • noob
  • 22 октября 2024, 10:30
0
Корень проблемы — медленная заливка прошивки в МК / медленное переключение IDE в режим отладки. Если это решить — надобность в эмуляторе дисплея отпадает.
+
avatar
  • CuMr
  • 22 октября 2024, 14:05
0
Я для себя «внезапно» открыл жлинк-в9. полметра прошивки заливает и проверяет за 6 секунд вместо больше чем минута стлинком
+
avatar
  • noob
  • 22 октября 2024, 14:26
0
У меня Jetlink Ulta 4, но даже это не спасает с большинством IDE. Например IAR и вся компашка производных от Eclipse те еще тормоза. За секунду-две управляются только Rowley CrossWorks и Segger Embedded Studio, но к ним надо привыкнуть из-за иерархических конфигов проекта.
+
avatar
+1
Корень проблемы — медленная заливка прошивки в МК / медленное переключение IDE в режим отладки. Если это решить — надобность в эмуляторе дисплея отпадает.
Видимо, вы не работали с большими проектами на ПК, где сборка может занимать минуты и даже часы. То есть, внес изменения, поставил собираться и переключаешься на другую задачу. 30-секундая загрузка в МК покажется идеалом в сравнении с этим.

Это, кстати, учит сразу писать более качественный код и проводить часть отладки непосредственно «в голове», рассматривая исходник.
+
avatar
  • noob
  • 22 октября 2024, 16:41
0
Видимо, вы не работали с большими проектами на ПК, где сборка может занимать минуты и даже часы. То есть, внес изменения, поставил собираться и переключаешься на другую задачу. 30-секундая загрузка в МК покажется идеалом в сравнении с этим.
Большие проекты отлаживают помодульно, с юнит тестами. Для МК только один раз о таком слышал в какой-то крупной компании. Да и то оно вылазило боком — не трогай старый код, а то опять заново всё тестировать придется.
Это, кстати, учит сразу писать более качественный код и проводить часть отладки непосредственно «в голове», рассматривая исходник.
Ничего это не учит. Провоцирует не запускать пошаговую отладку лишний раз. Знаю много таких «разработчиков», которые проблемы вылавливают исключительно по внешним ее проявлениям.
+
avatar
  • aliex
  • 22 октября 2024, 17:01
0
На десктопе пошаговая отладка была актуальна в древности, когда был один поток и минимум сети и прочей асинхронки. Сейчас — если можешь что-то пошагово отладить — считай, повезло. А так — логи и интеграционные тесты.

Ну и юниттесты — это самый минимум, все реальные нюансы выплывают в интеграции. Ну да на МК свои проблемы, начиная как раз с того, что абстракции не догоняют сложность проектов.
+
avatar
  • noob
  • 22 октября 2024, 17:14
0
На десктопе проблемы из-за слишком большого наслоения абстракций.
+
avatar
  • aliex
  • 22 октября 2024, 17:25
0
Местами да, но в основном — из-за сложности задач, асинхронного окружения и высоких требований пользователя. Который сожрёт из-за того, что прокрутка не плавная или отзывчивость не идеальная или в каких-то случаях что-то отрисовалось не так.
+
avatar
  • noob
  • 22 октября 2024, 18:39
0
Местами да, но в основном — из-за сложности задач, асинхронного окружения и высоких требований пользователя. Который сожрёт из-за того, что прокрутка не плавная или отзывчивость не идеальная или в каких-то случаях что-то отрисовалось не так.
Звучит наивно, но я считаю что этими задачами должна заниматься ОС. Именно поэтому я не лезу в десктопное программирование. Программист должен решать прикладные задачи, а не бороться с несовершенством системы.
+
avatar
  • aliex
  • 22 октября 2024, 19:15
0
Ну, я сам не то чтобы десктопным занимаюсь сейчас (медицина, и там всё тоже страшно, но по другим причинам), но из последнего, что я видел/делал — проблема не в несовершенстве ОС, а в том, что сама модель взаимодействия слишком сложной стала. Сам лэйаут простым уже не бывает, должен адекватно работать и выглядеть на широком диапазоне разрешений (в т. ч. когда оно на лету меняется), адекватно поддерживать тач и так далее. А если идём чуть глубже — то каждое первое приложение — коллаборативное, то есть в любой момент может прилететь куча каких-то обновлений, или, наоборот, сеть отвалиться — и это только если мы всё ещё о банальных формочках говорим, то есть сложностей самой бизнес-логики вообще не коснулись. Плюс криптография везде, это отдельная специфика. Плюс обычно стараются поддерживать кроссплатформенность винда/мак, плюс очень хочется переиспользовать бизнес-логику для мобильных. В общем, простого софта сейчас нет.
+
avatar
  • Leoniv
  • 22 октября 2024, 19:52
-1
Любопытно, откуда берется большое количество очень умных людей, которые способны такой сложный софт двигать? Софт усложняется, а количество умных, по идее, величина постоянная.
+
avatar
  • aliex
  • 22 октября 2024, 20:04
0
Ну так для этого и нужны всякие уровни абстракции, принципы написания софта и прочая инкапсуляция, чтобы всё это — по кусочкам и с потерями производительности — но таки тянули команды вполне себе обычных людей.
+
avatar
  • Leoniv
  • 22 октября 2024, 20:15
-1
Мне это трудно представить. Все эти абстракции — гораздо более непонятная вещь, чем ассемблерный код.
+
avatar
  • CuMr
  • 23 октября 2024, 00:59
+1
Если коротко, ардуина — это и есть уровень абстракции. Не нужно вникать что там под капотом pinMode, pinWrite и прочих, просто использовать.
+
avatar
0
Их много-то и не надо :))) проект поднял, экосистему вокруг для поддержки сделал — и свободен для следующих свершений.
+
avatar
  • Leoniv
  • 23 октября 2024, 19:49
-1
Так понимаю, создавать экосистемы на этой планете может кто-то с уровнем «бог».
+
avatar
+1
Я прям загордился :))))
+
avatar
+2
На компьютере будет только дополнительная «прослойка», заменяющая собой микросхему контроллера дисплея.
На самом деле, не очень понятно, как это будет работать. МК редко когда работает без внешних устройств — например, он считывает напряжение с АЦП, обрабатывает и выводит на экран. Если считанное значение попадает в какой-то диапазон, включается какая-то логическая ветка кода (индикация перенапряжения, например). Каким образом это всё будет работать на компьютере? Там ведь нет внешних устройств.
моделировать рисование в real-time каких-то графических объектов, навигацию в меню, вывод сообщений и прочее
Моя практика показала, что это не нужно. Если мы не делаем какую-то супер-графическую систему, где на экране много анимации, то картинка почти всегда стабильна. Значит, достаточно отрисовать несколько статических макетов — главный экран, меню, настройки и т.д. Можно пойти чуть дальше, отрисовать макеты в фигме и сделать даже небольшую навигацию между ними, но мне оказалось это тоже не нужно, т.к. макеты прекрасно позволили осуществить компоновку экранов, а большего и не нужно.
По платам — да, двухсторонние делаю сам.
Я не освоил домашнюю технологию двухсторонних плат. С ЛУТом у меня как-то сразу не заладилось (выход годного был очень низкий), возможно, имеющийся принтер для него не подходит. В итоге, перешел на фоторезист. Для экспозиции использую фотополимерный 3д-принтер (разрешение 50 мкм/пиксель), платы получаются точными и весьма качественными, но вот хорошо совместить две стороны — та еще проблема. Поэтому пока что от двухсторонних отказался — делаю перемычками.

Ваш вариант со степлером и конвертиком — интересный, надо будет попробовать. Только с утюгом у меня тоже плохо получалось :) С ламинатором намного лучше, надо будет подумать, как заменить степлер скотчем, чтобы можно было прогонять через ламинатор.
+
avatar
  • Leoniv
  • 22 октября 2024, 13:08
+3
Каким образом это всё будет работать на компьютере? Там ведь нет внешних устройств.
Я же не всю программу микроконтроллера предлагаю запускать на компьютере. А только те фрагменты, которые связаны с графикой. Меню, напрмиер. В любом случае, события можно имитировать нажатием кнопок клавиатуры.

достаточно отрисовать несколько статических макетов
Когда графика задается в виде картинок — то да. Но иногда для экономии памяти лучше нарисовать графический объект в real-time с помощью примитивов. Вот такие функции рисования можно полностью отлаживать на компьютере.

Да и вообще, не о чем тут спорить. Написать все это на компьютере не сложнее, чем написать библиотеку для дисплея на МК. Сделаю, пусть будет.

С ЛУТом у меня как-то сразу не заладилось (выход годного был очень низкий), возможно, имеющийся принтер для него не подходит.
Очень сильно влияет тонер. Если бы у меня вдруг не оказалось фирменного картриджа для HP LJ-1200, то ЛУТ мог бы пройти стороной. То, чем обычно картриджи перезаправляют, не годится категорически (хотя, возможно, просто не везло). Когда закончился фирменный, мне заправляли порошком, ссыпанным в виде остатков из фирменных картриджей. Когда закончилось и это, случилась остановка в ЛУТ, никак не мог подобрать тонер. Но оказалось, что прекрасно подходит китайский картридж (взял Cactus). Не отличается от фирменного, но сильно отличается от перезаправленного.

Еще влияет бумага. Если делать односторонние платы, то идеально переносит рисунок термотрансферная. Но сложить из нее конвертик не получается, тонер не держится. Пришлось вернуться к страницам журнала «Stereo & Video». Вот бы найти бумагу — нечто среднее между мелованной и термотрансферной!
+
avatar
0
А только те фрагменты, которые связаны с графикой. Меню, напрмиер. В любом случае, события можно имитировать нажатием кнопок клавиатуры.
Получится костыльно — в имитации событий может быть ошибка, которая может привести к ошибке отображения. Недавно как раз столкнулся с похожей, когда переводил логику с реакции на нажатие энкодера на реакцию на отпускание. Да и что там отлаживать-то? ) Отобразить пять пунктов и сделать курсором выделение… Понимаю, если вы хотите полноценный оконный менеджер написать с наложением и заделом на мультизадачность, тогда да, скорее всего, отладки много будет. Но для мелких МК это не нужно.
Но иногда для экономии памяти лучше нарисовать графический объект в real-time с помощью примитивов.
Я именно так и делаю. У меня атмега на 32 КБ ПЗУ и экран на 112.5 КБ, я не могу позволить себе хранить в памяти графику такого разрешения, поэтому все рисуется примитивами. И это очень удобно макетировать в графическом редакторе — я там рисую такие же примитивы, после чего снимаю их пиксельные координаты и переношу в код. Реализация и отладка UI занимает меньше времени, чем само макетирование :) Но я ни разу не дизайнер.

Кстати, по поводу отладки — самым трудоемким процессом было написать ассемблерный код вывода символа из шрифта так, чтобы он подавал новый байт в регистр SPI ровно через 18 тактов.
Сделаю, пусть будет.
Сделайте, конечно, если хочется. Удовольствие от занятия любимым делом намного важнее практического смысла.
то идеально переносит рисунок термотрансферная. Но сложить из нее конвертик не получается, тонер не держится.
Да, пришел к точно такому же выводу! Правда, у меня и на односторонних платах бывало, что осыпался :)
Вот бы найти бумагу — нечто среднее между мелованной и термотрансферной!
Я пробовал много разной — от обычной А4, до тетрадной, газетной и даже фотобумаги для струйников. Последнюю несколько стремно совать в принтер, т.к. есть полимерные, которые от температуры плавятся и могут принтер испортить. Однажды попался мне листик такой, что была практически идеальной — печаталось всё нормально, а потом в воде за 10 минут размокала как втулка от туалетной бумаги Zewa в хорошие времена. И просто пальцем стиралась. Но потом не смог найти её — покупал в магазине аналогичную, но она уже была «по новой технологии» на каком-то полимере. А дальше попробовал фоторезист, понравилось, на нем и остановился.
Очень сильно влияет тонер.
Читал об этом. Но у меня китайский принтер pantum, скорее всего, он вообще плохо подходит для ЛУТ, т.к. печатает весьма тонко, для ЛУТ надо жирнее. Надо было brother покупать, вроде там честная настройка плотности в драйверах, которая влияет на напряжение. Мне кажется, у меня это лишь программная опция. Но сейчас платы делаю настолько редко, что не повод менять.
+
avatar
  • Leoniv
  • 22 октября 2024, 17:43
0
очень удобно макетировать в графическом редакторе — я там рисую такие же примитивы, после чего снимаю их пиксельные координаты и переношу в код
Нарисовать на компьютере с помощью таких же функций вывода на дисплей, как будут в МК — выйдет намного быстрее, чем рисовать в графическом редакторе, а потом переносить в код.

Ну или, допустим, хотим подправить шрифт. Как быстро посмотреть, что получилось? Рисовать попиксельно в графическом редакторе символы — то еще занятие.

и даже фотобумаги для струйников
Глянцевая фотобумага для струйников — почти идеал. Лучше всего подошла Epson, но она страшно дорогая. С более дешевыми есть проблема — глянец плохо отмывается из мелких зазоров между дорожками. И еще одна проблема — тот картридж, который использовал с бумагой для струйника, очень скоро стал плохо печататать.

сейчас платы делаю настолько редко, что не повод менять
Да, хочется полностью уйти от этой грязной работы. И дело шло к тому некоторое время назад.
+
avatar
+1
Нарисовать на компьютере с помощью таких же функций вывода на дисплей, как будут в МК — выйдет намного быстрее, чем рисовать в графическом редакторе, а потом переносить в код.
Ровно наоборот. UI сначала скомпоновать надо, убедиться, что всё влезает. Это намного удобней в редакторе, чем в любом коде. Ну и попиксельные перемещения, выравнивания и т.д. в редакторе проще. Поэтому перед любой разработкой сначала делают макеты, даже если разработка идет на ПК, где, казалось бы, ничего не мешает сразу видеть результат.
Да, хочется полностью уйти от этой грязной работы. И дело шло к тому некоторое время назад.
Меня в заказе готовых плат всегда смущало время. Если я нарисовал схему и плату, то хочу получить её в руках максимально быстро, а не ждать пару недель. Но качество готовых несравнимо с домашним, это очевидно.
+
avatar
  • Leoniv
  • 22 октября 2024, 19:22
0
Спорить смысла нет. Редактор-редактором, а все равно потом приходится кучу раз перепрошивать МК, внося какие-то правки. Вот это и хочу ускорить. Попробую, тогда расскажу.
+
avatar
  • remarker
  • 22 октября 2024, 06:06
+3
«Длительность импульса примерно 3.3 нс»

«Датчик способен измерять даже такое малое расстояние, как 10 мм, которое свет проходит туда-обратно за время примерно 67 пикосекунд!»

Вот точно фантастика. Интересно, какие фронты у импульса лазера?
+
avatar
  • noob
  • 22 октября 2024, 10:34
+1
Посмотрите TDC GP21/22. ЕМНИП там 12пс разрешение. И китайцы ее уже давно склонировали, не обязательно брать оригинал.
+
avatar
  • Leoniv
  • 22 октября 2024, 12:54
+2
Что-то похожее делал на FPGA. Есть неплохая книга по данному вопросу: Stephan Henzler «Time to digital converters».

+
avatar
  • Leoniv
  • 22 октября 2024, 12:06
+3
Это трудно измерить. Но у лазерных диодов, особенно таких маломощных, очень низкая паразитная емкость, поэтому они легко модулируются гигагерцовыми частотами в системах связи. Тут главное, чтобы была повторяемость формы импульса, длительность фронта можно учесть калибровкой.
+
avatar
+1
Офигенно. Как человек, написавший кучу библиотек для работы с OLED дисплеями, скажу что разобрались в регистрах очень хорошо.
Дисплеи реально классные в плане удобства чтения, количества выводов и потребления

На всякий случай — готовых дальномеров с кучей фий и алюм корпусом и низкой ценой полно на али.
+
avatar
  • Leoniv
  • 22 октября 2024, 12:32
+1
О, классно, тогда спрошу. А что физически означает «VCOMH Deselect Level»? Почему Deselect? Про «Pre-charge Period» более-менее понятно, в документе от Osram про это есть.

Что касается дисплеев — да, они выглядят классно. Единственное, что меня смущает — это уровень помех. Например, для большого дисплея, что на последнем фото, на питании наблюдаю пульсации 300 мВ. Боюсь, что избавиться от помех будет очень трудно, как в случае динамической индикации на обычных LED. Есть отрицательный опыт, избавиться не удалось никак (речь идет о микровольтовых уровнях). Боюсь, чтобы не пришлось переходить на LCD, там с этим намного лучше (подсветка, естественно, не должна питаться импульсно).

По дальномеру — у меня же написано, для чего он делался. Как дальномер его никто не собирается использовать.
+
avatar
0
К сожалению, большинство данных параметров не используеются в китайских OLED :)
VCOMH отвечает за контраст, емнип, и точно также редко на что-то влияет в контексте данных экранчиков — у них для него обычно четко определенное значение и все.
+
avatar
  • Leoniv
  • 22 октября 2024, 15:19
+1
Этот параметр напряжение меняет, это видно на конденсаторе. Но что это напряжение означает физически? Предположение — что это уровень напряжения, который поддерживается на шинах строк, которые в данный момент выключены. Тогда чтобы на выключенном светодиоде было нулевое напряжение, VCOMH должно быть равно рабочему напряжению светодиода (которое меньше VCC). При слишком высоком VCOMH светодиоды будут иметь обратное смещение и потребуется более длительный Precharge. При слишком низком в теории могут засвечиваться выключенные пиксели. Но что-то не могу найти четкого объяснения в литературе. Есть книга «OLED Display Fundamentals and Applications», судя по оглавлению, там это может быть, но скачать пока не удалось.

+
avatar
+1
При слишком низком в теории могут засвечиваться выключенные пиксели.
Так вот и ответ напрашивается — это напряжение должно быть таким, чтобы не зажигать выключенные диоды, но и чтобы повышение напряжение до рабочего происходило относительно быстро (т.к. диоды питаются постоянным током, значит, du/dt константа). По сути, в некотором диапазоне изменение параметра не будет оказывать заметного влияния на отображение.

А для чего вам так глубоко с этим разбираться? Возьмите код из наиболее авторитетного примера, скорее всего, там будет подходящее значение.
+
avatar
+2
А для чего вам так глубоко с этим разбираться? Возьмите код из наиболее авторитетного примера, скорее всего, там будет подходящее значение.
Потому что только так становятся профессионалами.
+
avatar
0
Лучше и не сказать.
+
avatar
+5
К сожалению, невозможно стать профессионалом во всем — банально не хватит времени. Мы живем в век технологий, вокруг уже все с микропроцессорным управлением. Если пытаться досконально разобраться с каждым отдельным устройством/модулем, никакой жизни не хватит. Я по собственному опыту говорю, мне тоже нравится знать всё до последней мелочи. Но приходится от этого уходить, ибо время, потраченное на глубокое изучение очередной особо не нужной фичи можно было потратить на что-то более важное и полезное. Поэтому сейчас стараюсь решать только те, проблемы, что действительно имеют значение.
+
avatar
  • aliex
  • 22 октября 2024, 17:08
0
Именно так. Есть иногда ниши для совсем узких спецов, но, во-первых, как-то скучно, во-вторых — слишком большой риск потом в поезд не впрыгнуть, если ниша исчезнет. Да и мало такого.
+
avatar
  • Leoniv
  • 22 октября 2024, 17:47
+2
Да какой там поезд… Мы тащимся пешком с узелком на палочке. :)
+
avatar
0
К сожалению, невозможно стать профессионалом во всем — банально не хватит времени.
Я такое каждый день слышу. А потом они же удивляются почему жигули не иномарка и что мешает сделать как у vw.
+
avatar
+1
А причем тут профессиональная деятельность? Там у каждого своя узкая роль, в которой он должен разбираться отлично. А здесь речь про самоделки — ну, вот как улучшится обозреваемая конструкция, если автор досконально разберется в значении этого напряжения?
+
avatar
  • Leoniv
  • 22 октября 2024, 15:54
+1
чтобы повышение напряжение до рабочего происходило относительно быстро (т.к. диоды питаются постоянным током, значит, du/dt константа)
Для ускорения этого процесса и делают специальную фазу Pre-charge. Только после этого переходят в режим constant-current.
+
avatar
+1
Книга у вас в личке.

Если накопаете что-то инетерсное про это — поделитесь пож.
+
avatar
  • Leoniv
  • 22 октября 2024, 16:19
+1
Большое спасибо! Попробую найти в ней ответ.
+
avatar
  • Leoniv
  • 22 октября 2024, 16:47
+3
К сожалению, в книге управление PMOLED рассмотрено очень кратко, там больше про AMOLED.

Мое предположение, что VCOMH — это вот это:

+
avatar
+1
вот еще хорошие статьи по этим дисплеям:
habr.com/ru/articles/741164/
microsin.net/adminstuff/hardware/ssd1306-oled-controller.html
+
avatar
  • Leoniv
  • 22 октября 2024, 13:58
+1
Регистры конфигурации перечислены, но что есть что, и зачем — ни слова.

Но вот это:

Для отладки сложной графики типа меню или экранная клавиатура вам точно понадобится PC утилита имитатор экранчика для отрисовки графики на конве 64x128. Это поможет сократить количество итераций пере прошивки микроконтроллера. Причем эту утилиту надо писать на том же языке, что и прошивку микроконтроллера чтобы бесшовно переносить софт на разные платформы.
— полностью поддерживаю!
+
avatar
0
Экранная клавиатура на 64х128? Это интересно )
+
avatar
  • Leoniv
  • 22 октября 2024, 15:58
+1
А почему нет? Часто в измерительных приборах вдоль края экрана расположен ряд кнопок для выбора пункта меню. Их можно заменить экранными. Вот только я не люблю нажимать на экран, лучше на кнопки, поэтому вряд ли так буду делать.
+
avatar
0
Непонятно, что можно уместить на таком маленьком экране.
+
avatar
  • Leoniv
  • 22 октября 2024, 19:20
+1
На последнем фото как раз экран 128х64, там видно, что можно уместить. У меня много приборов с LCD такого разрешения, вполне хватает.

+
avatar
0
Да, небольшой интерфейс разместить можно. У меня именно по экранной клавиатуре вопрос — ведь дисплей позволяет максимум порядка 20 символов в строку вывести, если узких. Это позволит назвать три кнопки?

Ну, и, скорее всего, изначально под «экранной клавиатурой» подразумевалась клавиатура, нарисованная на экране, позволяющая вводить текст. Вот такой на маленьком экране будет очень тесно.
+
avatar
  • Leoniv
  • 23 октября 2024, 10:56
0
Текст вводить обычно нужды нет. А вот нажать на строку с значением, чтобы ее выбрать — можно. Обычно в столбик с края экрана выводятся опции, которые можно выбрать нажатием. Но я не люблю нажатия без тактильного отклика, поэтому тачскрины не использую.
+
avatar
0
Текст вводить обычно нужды нет.
Ну, не скажите. Сейчас делаю проект зарядного устройства, и там есть разные профили зарядки. Если сделать возможность редактирования профиля непосредственно с устройства, нужно как-то задавать его имя. Вот тут и нужен ввод текста. Но я пока не пришел к пониманию, нужно ли это, или будет достаточно ограничиться «предустановленными» профилями. Тем более, что свободного места в МК уже остается не так много.
поэтому тачскрины не использую.
Вот и я не думаю, что автор изначального поста имел в виду под экранной клавиатурой то, что озвучили вы, ведь это еще потребует подключение и настройку тачскрина. Не уверен, что такие маленькие дисплеи идут с ним по умолчанию.
+
avatar
  • Leoniv
  • 23 октября 2024, 14:05
+2
Такие сложности в проекты лучше не закладывать. Как показывает практика, ни сам, ни другие этим потом не пользуются. Главное качество хорошего проекта — простота.
+
avatar
+1
Главное качество хорошего проекта — разумная функциональность, когда есть все нужные функции и нет ненужных. А какие нужны — далеко не всегда на этапе проектирования понятно, пока нет опыта реального использования.
+
avatar
  • aliex
  • 23 октября 2024, 16:42
0
Но тогда речь фактически идёт о прототипе, а в нём можно обойтись какими-нибудь крайней простыми средствами, даже если они не особо удобны.
+
avatar
  • aliex
  • 23 октября 2024, 14:17
+2
Я бы при возможности не с экранной клавиатурой возился, а вообще сделал, как в паяльниках всяких, когда по USB он виден как мелкий диск, на котором лежит файл с настройками. Полагаю, что готовых модулей такого рода хватает (уже в описании кучи устройств попадался такой подход), так что если железо позволяет — должно быть несложно.
+
avatar
0
когда по USB он виден как мелкий диск, на котором лежит файл с настройками.
Как вариант, да. Но лучше, чтобы и само устройство позволяло все свои параметры настраивать. Тогда при возможности открываем на компе, делаем все быстро, удобно и привычно. А если устройство эксплуатируется автономно, то настраиваем чего его интерфейс, менее удобно и дольше, но не надо тащить к компу.
+
avatar
  • aliex
  • 23 октября 2024, 16:34
0
Если это продукт на продажу — да. Для хоббийного — слишком много возни, как мне кажется, тут одного пути хватит. Что до автономности — с OTG-переходником этот файл так же спокойно будет редактироваться на смартфоне.
+
avatar
  • Leoniv
  • 23 октября 2024, 19:45
0
Это если смартфон есть.
+
avatar
  • aliex
  • 23 октября 2024, 19:52
0
Разумеется. Но процент людей, у которых его нет, крайне мал. А среди тех, кому актуальны зарядки с кастомными профилями — полагаю, стремится к нулю.
+
avatar
  • Leoniv
  • 23 октября 2024, 19:39
0
Если есть подключение к USB, то гораздо проще и удобней сделать свою утилиту настройки. Но у полностью автономных приборов есть своя прелесть.
+
avatar
  • aliex
  • 23 октября 2024, 19:50
+2
Своя утилита настройки — это значит, что её надо таскать с собой. Текстовый файл на диске редактируется на любом компьютере/смартфоне/планшете.
+
avatar
  • Leoniv
  • 23 октября 2024, 19:59
0
Куда таскать? Прибор всю жизнь стоит на своем месте, компьютер — тоже.
+
avatar
  • aliex
  • 23 октября 2024, 20:05
+1
Возможно, мы о разном говорим? Я — о зарядном, которое делает
kdekaluga, и он ничего не говорил о том, будет ли оно стоять всю жизнь на месте.

Вам я ничего предлагать не стал бы — слишком разные понятия о правильном и прекрасном.
+
avatar
0
Я делаю узкоспециализированную зарядку, которую дополняю широкими возможностями :) Понимаю, что это мало что поясняет, но если всё сложится и я завершу проект, то напишу обзор и всё выложу.

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

И тут остается лишь понять, какие именно настройки вообще надо менять, а какие можно просто «захардкодить», т.к. их изменение может лишь навредить функциональности.

А если уж говорить про способ удаленного управления, то самый удобный — это WiFi и настройка через браузер. Не надо ничего физически подключать, не надо ничего устанавливать на телефон. Но это надо было планировать с самого начала, т.к. нужен другой контроллер, с которым есть свои (другие) сложности.
+
avatar
  • Leoniv
  • 24 октября 2024, 17:50
0
Тут не может быть никаких возражений. Для каждого устройства свой оптимальный способ изменения настроек. И уж тем более, никто не может навязывать автору, как делать. Советы дать могут, но прислушиваться, или нет — личное дело каждого.

По поводу Wi-Fi — у меня нет ни одного устройства с ним (в компьютере его нет), поэтому себе такое управление никогда не делаю. Что касается утилиты на компьютере, я, честно говоря, не понял, что советовалось взамен. По-моему, чтобы с компьютера делать нстройки, надо иметь на компьютере какую-то программу. С GUI или через команджную строку или файл — это другой вопрос. Удобнее всего с GUI. На работе есть много фирменных приборов, всегда для настройки идет утилита под Windows. Я по-другому и не мыслю. Еще идет в комплекте DLL, через которую можно управлять приборами из Матлаб. Я тоже такие DLL к своим приборам делаю.
+
avatar
0
Что касается утилиты на компьютере, я, честно говоря, не понял, что советовалось взамен.
Текстовое управление через терминал (если что, терминал идет есть прямо в ОС). Типа того же SCPI:
MEA:VOLT:A?
Тогда устройство можно будет настроить без ПО на компьютере, отправляя нужные команды вручную. Это проще в реализации, чем эмуляция хранилища с файлом настроек.
На работе есть много фирменных приборов, всегда для настройки идет утилита под Windows. Я по-другому и не мыслю.
Это некий стереотип, заложившийся во времена, когда windows была, по сути, единственной альтернативой. Как и «толстые» десктопные приложения.

Сейчас происходит сдвиг на «облачность», «тонкие клиенты». Хорошо это или плохо, вопрос отдельный, который можно обсуждать бесконечно. Но факт остается фактом — для рядового пользователя гораздо проще открыть браузер и настроить устройство через смартфон, чем искать винду и ставить приложение. И еще проще, если эта настройка доступна через интернет, а не только в локальной сети. Но это уже совсем другой уровень.
+
avatar
  • Leoniv
  • 24 октября 2024, 19:36
0
Да, через терминал можно. Но это дико неудобно, надо иметь перед глазами бумажку с названиями параметров. Это большой шаг назад по сравнению с утилитами с GUI.

Мне не доводилось касаться того мира, где кто-то настраивает какие-то приборы через смартфон или через интернет. Что я вижу вокруг — у всех компьютер, у всех Windows.
+
avatar
0
Вы также можете написать гуевое приложение, которое будет отправлять эти же команды, таким образом вы вообще изменений не заметите, зато появится возможность управлять устройством без приложения. Понятно, что вы этого делать не будете, т.к. я еще не встречал ситуации, где бы вы изменили свое мнение после слов других людей, но просто представьте — бывают ситуации, когда приложения нет и быть не может. В таком случае ваше устройство удаленное управление полностью потеряет. А если бы был текстовый терминал — оно бы осталось. А бумажку перед глазами можно заменить on-line справкой, которую выдает это же устройство по, например, команде "?".
Мне не доводилось касаться того мира,
А он есть :) Удаленное управление через телеграм-бота сейчас вообще сильно популярно, т.к. позволяет управлять из любой точки мира, но не требует сервера с белым IP :)
+
avatar
  • Leoniv
  • 25 октября 2024, 15:55
0
Чтобы поменять свое мнение, нужны какие-то основания. Пока все сказанное для меня выглядит как какие-то фантазии. Никогда с таким не сталкивался, надеюсь, что и не придется.
+
avatar
  • aliex
  • 30 ноября 2024, 00:19
0
Нет. Предлагалось так:
При подключении устройство эмулирует флешку на 2 кб, допустим, на которой лежит текстовый файл с настройками. Соответственно, открываем блокноте или аналоге, правим, сохраняем обратно.

Однозначно годится не для всех случаев, зато там, где годится — не требует никакого специального софта, даже терминала, плюс заодно даёт возможность бэкапить/восстанавливать настройки. Никак не могу вспомнить, где такое встречал, а вот прошивку, реализованную таким макаром, видел не раз. В любом случае реализаций этой штуки полно, и они достаточно мелкие, чтобы даже жить в бутлоадере.
+
avatar
  • CuMr
  • 24 октября 2024, 21:29
+1
По поводу Wi-Fi — у меня нет ни одного устройства с ним (в компьютере его нет), поэтому себе такое управление никогда не делаю.
копеечная есп8266/есп32 и с одной стороны точка доступа с интерфейсом в браузере, с другой что угодно, но чаще всего уарт. и никаких проблем с интерфейсом настроек.
+
avatar
  • Leoniv
  • 24 октября 2024, 23:22
0
У меня нет Wi-Fi ни в одном устройстве, не с чем коннектиться будет.
+
avatar
  • CuMr
  • 25 октября 2024, 16:26
0
купить самый дешевый смартфон или планшет и будет универсальный пульт для настройки всего
+
avatar
  • Leoniv
  • 25 октября 2024, 16:29
0
Спасибо, не хочу.
+
avatar
0
удобней сделать свою утилиту настройки
Утилита настройки — один из самых печальных вариантов. Во-первых, нужен компьютер, а, во-вторых, надо запускать условно «левое» (часто неподписанное) приложение. Я, например, крайне негативно отношусь к такому у себя на ПК, т.к. не известно, что в этом приложении может находиться внутри. Приходится поднимать виртуалку, пробрасывать устройство и т.д. Это, конечно, осуществимо, но весьма неудобно. А собрать самому приложение из исходников не факт, что получится, емнип, вы, например, пишете на Delphi, которого у меня уже лет 20 как нет.

Поэтому, если уж есть подключение к USB и очень хочется сделать настройку через комп — лучше это осуществлять в терминале текстовыми командами. И SCPI вам приветливо машет ручкой. Это, кстати, не отменяет возможности написать и утилиту, которая может подавать в порт точно такие же команды. Вин-вин.

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

Ну, а вернувшись к вопросу — моя позиция здесь такова, что если в устройстве есть настройки, которые надо менять, надо дать возможность делать это напрямую с устройства. Без компьютера, телефона или отдельного блока управления. Это, в любом случае, практичней.
+
avatar
  • Leoniv
  • 24 октября 2024, 17:01
0
Я пишу не на Delphi, а на C++Builder. Но это не важно. Если бы я продавал свои изделия, тогда надо было бы думать о других пользователях. А так надо думать только о том, как самому проще. Возможность всё задавать прямо с устройства — это прекрасно, полностью поддерживаю. Но написать местный GUI гораздо сложнее, чем на компьютере.
+
avatar
0
А передача данных между устройством и ПК? Протокол? Или у вас есть собственный «стандартный» механизм, позволяющий подключать его в любой проект за пару минут?

Просто, чтобы понимать, о каких масштабах мы говорим — допустим, у вас есть пара числовых 16-битных параметров, пара 8-ми битных, штук 5 битовых флагов. Сколько времени займет создание самого интерфейса на ПК, передача этого через последовательный порт и код обработки на МК?
+
avatar
  • Leoniv
  • 24 октября 2024, 17:56
0
Когда-то я сделал протокол, который назвал Wake. Его и использую. Он, кстати, портирован под многие среди и ситемы, но я сижу под Windows. Для каждого микроконтроллера, с которыми работаю, есть реализация этого протокола как на C, так и на C++. Из программы это выглядит так:

//передача в компьютер:
            WakePort->AddByte(b);
            WakePort->AddWord(w);
            WakePort->StartTx(Command);

//чтение и ответ:
            uint8_t a = WakePort->GetByte();
            uint32_t b = WakePort->GetDWord();
            WakePort->AddByte(ERR_NO);
            WakePort->StartTx(Command);
+
avatar
0
Да, это быстрей, чем делать UI на устройстве. Но не прямо «в разы». На устройстве главное начать, а дальше добавление новых настроек идет уже быстро.
+
avatar
  • Leoniv
  • 24 октября 2024, 19:12
0
Главная проблема на устройстве — это нехватка кнопок. Когда-то было модным все делать с помощью одного энкодера с нажатием. Я тоже поддался этой моде. В итоге эргономика устройств получилась ниже плинтуса. У меня меред глазами наглядный пример — два самодельных блока питания: PSL-3604 и PSL-2402. У последнего на 3 кнопки на панели меньше. В результате настолько неудобно, что прикасаться к нему не хочется!
+
avatar
0
PSL-3604 и PSL-2402. У последнего на 3 кнопки на панели меньше. В результате настолько неудобно, что прикасаться к нему не хочется!
А зачем он вам вообще, если первый полностью перекрывает его диапазон (если я правильно расшифровал названия)? Понятно, что вы к нему не прикасаетесь, дело не только в кнопках :)
Я тоже поддался этой моде.
Для БП, конечно, одного энкодера мало, но двух — уже достаточно. Плюс еще кнопка вкл/выкл выхода. Но для других устройств и одного вполне. Например, паяльник Т12.
+
avatar
  • Leoniv
  • 25 октября 2024, 15:56
0
Бывает, нужно сразу несколько БП.
+
avatar
  • noob
  • 24 октября 2024, 20:10
0
Если взять контроллер пожирнее то через терминал вполне можно «нарисовать» и меню и поля ввода. Кстати, недавно на глаза попалась turbovision на гитхабе. Выглядит интересно, но неясно удастся ли ее впихнуть в МК.
+
avatar
  • Leoniv
  • 24 октября 2024, 20:27
0
Только непонятно, зачем.
+
avatar
  • noob
  • 24 октября 2024, 21:17
0
Чтоб софт на комп не ставить.
+
avatar
  • Leoniv
  • 24 октября 2024, 23:20
0
Ну если это такая проблема и готовы ради этого жертвовать удобством ввода, тогда я ничего не понимаю в этом мире.
+
avatar
  • Kabron
  • 22 октября 2024, 08:38
+1
Вот ссылочки по теме.
Эти датчики могут больше.
www.youtube.com/shorts/b18ghRCWawo
www.youtube.com/shorts/_ZjAZ7eieNM
www.youtube.com/shorts/mBebfzSqTqA
+
avatar
  • magner
  • 22 октября 2024, 09:35
+1
Для облегчения создания интерфейсов есть такой проект lopaka.app/sandbox.
+
avatar
  • Leoniv
  • 22 октября 2024, 12:39
0
Всяких утилит подобного рода хватает. Но у меня главная мысль — чтобы на компьютере писать на Си код, который потом будет без изменений использован на микроконтроллере. Требуется не готовое приложение для компьютера, а просто набор функций, эмулирующих нужный дисплей на экране монитора. За компьютером работаем не в приложении, а в компиляторе C/C++.
+
avatar
  • Blex
  • 22 октября 2024, 09:48
+8
Какой приятный и добротный обзор. Leoniv, пишите почаще.
+
avatar
  • Leoniv
  • 22 октября 2024, 12:34
+6
Спасибо!
+
avatar
+1
отличный обзор. Написано ясно и хорошо оформлено. И внешний вид прибора отличный. Вопрос — чем в корпусе по форме вырезали? Ну, например, под usb разьем. Смешно, но часто бывает на корпус и потом на его внешний вид тратишь времени больше, чем на остальное. И не всегда результат выглядит как мне хочется
+
avatar
  • Leoniv
  • 22 октября 2024, 15:06
+3
Спасибо. Отверстия в панелях вырезал фрезеровкой, примерно так:

+
avatar
0
это у вас дома такая? Можете подробнее написать? У меня сейчас малина 3 и на ней сзади куча портов ввода-вывода. Надо в металлическом корпусе вырезать под это дело фигурные отверстия. Сижу голову чешу, как это красиво сделать
+
avatar
  • Leoniv
  • 22 октября 2024, 15:25
+6
Да, дома. Настольный вертикальный фрезерный.

+
avatar
0
понял, знаю такой
+
avatar
+1
А что за координатные тиски? Давно хочу себе, но у тех, что видел в продаже часто отзывы плохие, что люфтят сильно.
+
avatar
  • 00svd00
  • 22 октября 2024, 16:06
0
Они и есть плохие, у них губки не параллельные, чисто конструктивно, но в комплект китайцы кладут именно такие. Под этот станочек неплохим вариантом могут быть китайские QGG73
Ну или поискать станочные тиски похожего плана на барахолках.
+
avatar
  • Leoniv
  • 22 октября 2024, 16:13
+2
Лучше тиски такой конструкции, но всё это дорого с пересылкой.

+
avatar
  • 00svd00
  • 22 октября 2024, 16:25
0
Есть у меня такие QKG-38, не понравились. Очень неудобно выставлять, всё время падает вниз внутренняя часть с зацепом(ощущение что не хватает какой-то пружины, которая удерживает)
Брал вроде бы тут
У них кстати цены как будто чуток попроще алика
+
avatar
  • Leoniv
  • 22 октября 2024, 16:40
0
Пользоваться менее удобно, зато они заготовку не поднимают при зажатии. Можно обойтись без постукивания и без хитростей со стальными пластинами и роликами.
+
avatar
  • 00svd00
  • 22 октября 2024, 16:47
0
Не соглашусь. С точки зрения базовой логики вы правы, у тех что на вашей картинке вектор силы направлен под углом вниз, так что у них такое конструктивно исключено, но мои тоже не подымают. Вот только что индикатором проверил — при зажатии даже на сотку не дёрнулся.
+
avatar
  • Leoniv
  • 22 октября 2024, 17:25
0
Если зажимать что-то тонкое (до 10 мм), то это незаметно. Но вот зажал 40 мм, у задней губки поднятия нет, а у передней 3 сотки.

+
avatar
  • 00svd00
  • 22 октября 2024, 17:39
0
Не знаю. Может у меня тиски посвежее, может я в китайскую лотерею выиграл. Там сама губка мёртво стоит по вертикали, даже если её дёргать под индикатором в расслабленном состоянии. Даже если деталь не по центру зажимать
+
avatar
  • Leoniv
  • 22 октября 2024, 17:50
0
У губки всегда будет люфт. У меня он по индикатору те же 3 сотки. Если пытаться делать меньше, тиски ходить начинают с заметным усилием, что некомфортно.
+
avatar
  • 00svd00
  • 22 октября 2024, 18:23
0
Я это головой понимаю, но индикатором его нащупать не могу)
+
avatar
  • Leoniv
  • 22 октября 2024, 19:23
0
Значит повезло :)
+
avatar
0
Спасибо, в избранное добавил, пока не решился купить :) Наверное, я неправильно вопрос сформировал — меня интересует, прежде всего, координатный столик.
+
avatar
  • 00svd00
  • 22 октября 2024, 18:53
0
Дык это. В комплекте с фрезером)
+
avatar
  • Leoniv
  • 22 октября 2024, 19:28
+1
Координатный стол можно купить и отдельно. Только такие тяжелые вещи не факт что дешевле покупать на Ali. Для начала лучше поискать поближе. Бывают еще б/у, их надо искать на directlot.ru.
+
avatar
  • Leoniv
  • 22 октября 2024, 16:06
0
На этом фото действительно плохие тиски, которые обычно используют только на сверлильных станках. Теперь у меня стоят нормальные лекальные тиски.

+
avatar
  • 00svd00
  • 22 октября 2024, 16:13
0
А цифровые линейки не хотите поставить? Достаточно простая доработка, но на этом станке(с его дурацкой ценой деления на нониусе) — очень упрощают жизнь
+
avatar
  • Leoniv
  • 22 октября 2024, 16:16
0
Цена деления здесь 0.02 мм, вполне удобная. Оборот 1.5 мм, конечно, не совсем удобен, но уже привык. Цифровые линейки хочу поставить, одна из них уже полгода как куплена, но все руки не доходят заняться.
+
avatar
  • 00svd00
  • 22 октября 2024, 16:31
+3
Оборот 1.5 мм, конечно, не совсем удобен
У меня мозг откис и в нирвану ушёл по двум координатам перемещения в уме перемножать то с к-том 2(когда иду по мелким делениям), то 1,5(когда целыми оборотами). Я сдался и поставил)
Самые дешёвые, питание снимаю с бортовой сети вместо батареек, отлично работают. И да, по вертикальной оси перемещение передаёт тупо печатная деталь. Жёсткости вполне хватает
+
avatar
  • Leoniv
  • 22 октября 2024, 16:52
+2
Да, тут безграничный простор для творчества. Можно свести все показания на один дисплей, добавить всякие удобства. Вот только время на всё это надо. Поскольку станком пользуюсь не очень часто, то совершенно непонятно, в итоге получится выигрыш или проигрыш.
+
avatar
  • 00svd00
  • 22 октября 2024, 17:10
0
Есть такой момент. Аналогично фрезер оказался самым редкоупотребимым приобретением и большую часть времени если и работает — то как координатно-сверлильный. Но до доработок пользоваться я им нормально вообще не мог, а так хоть какой толк появился) Времени на допил ушло 1 вечер, хотя если нет 3D принтера — можно с некоторыми деталями конечно заковыряться.
+
avatar
  • kiv69
  • 29 ноября 2024, 11:00
0
Я бы не удержался, оснастил бы такой станочек ЧПУ.
Тогда бы и платы ЛУТом делать не пришлось бы
+
avatar
  • Leoniv
  • 29 ноября 2024, 11:09
0
На это нужны деньги, а их сейчас нет.
Делать платы фрезеровкой по-моему хуже, чем ЛУТ. Долго, шумно, пыльно.
+
avatar
+1
Вы ли это, который совсем недавно писал обзор на блок-розетку «привет ссср»? Слушайте, однако, как инетерсно уживаются таланты в людях. А тут такая серьезнейшая работа и устройство…
+
avatar
  • Leoniv
  • 23 октября 2024, 10:46
0
По-моему, про розетку тоже было хорошо написано.
+
avatar
0
Отлично было написано. Просто предмет обзора там и тут, разница космос.
+
avatar
+1
Увидев oled, которые уже сошли на нет, сразу же появились догадки и насчет МК, и о да, опять воспоминание про начало 2000х… В этом настоящем, даже в рф рознице здесь и сейчас, скажем для такой поделки сh32v003 20р.
+
avatar
  • CuMr
  • 23 октября 2024, 01:01
0
Сейчас начнет ныть что это ведь даже не арм в виде стм32, а какой то еще там риск, да еще и от китайцев… Это все чудовищно сложно.
+
avatar
  • Leoniv
  • 23 октября 2024, 10:51
0
Именно так. Это очень сложно. Вот почему комментаторы никак не могут понять, что у разных людей разные умственные способности? Если один может разобраться с STM32 за 5 минут, другой не сможет и за жизнь.
+
avatar
  • redcap
  • 23 октября 2024, 20:39
+2
Если один может разобраться с STM32 за 5 минут, другой не сможет и за жизнь.
А третий хоть и может, но точно не будет :)
+
avatar
+1
Цена впечатляет. Можно хоть на каждый светодиод по такому ставить. Но вопрос в другом — стоит ли тратить время на изучение малоизвестного и, возможно, глючного котроллера, по которому намного меньше документации и вряд ли есть хоть какое-то вразумительное сообщество? Если вы столкнетесь с проблемой в разработке, сможете ли вы её решить и как быстро? А учитывая, что для самоделок цена комплектующих никогда не была на первом месте, я не вижу пока что ни одной реальной причины его пробовать.
+
avatar
  • CuMr
  • 23 октября 2024, 03:25
0
для мигалки светиками не нужно ни сообщество, ни что то еще. хоть более-менее вменяемый даташит и тулчейн (а это есть).
впрочем, WCH это не касается, т.к. его уже в pio затянули.
+
avatar
  • aliex
  • 23 октября 2024, 08:18
0
Хм, PIO — это PlatformIO имеется в виду, я так понимаю? Оно вообще как — настолько хорошее, насколько они хвалятся? Или очередной жираф со щупальцами?
+
avatar
+1
Оно вообще как — настолько хорошее, насколько они хвалятся?
По сути, это оболочка-плагин для vscode, включающая в себя тулчейны под разные платформы. Сам по себе vscode — весьма неплохой редактор. Для С++ там ставится соответствующий плагин, который работает где-то на 3.5 из 5, но всяко лучше IDE от ардуино первой версии (возможно, и второй тоже, но тут с уверенностью не буду говорить, т.к. во вторую особо не тыкал). Pio выкачивает нужный тулчейн и подключает его к вашему проекту, позволяя собирать и загружать его в МК по нажатию одной клавиши.

В целом, получается неплохо, я сейчас свой проект именно на pio делаю. Ложку дегтя добавляет только вот это, невольно задумываешься, как бы какой закладки не оказалось.
+
avatar
  • aliex
  • 23 октября 2024, 14:11
0
Ну совсем разрекламировали :-)

Если серьёзно — это не особо стыкуется с тем, что у них написано (а там заявлено, что это, прежде всего, универсальная тулза, которая умеет не только тулчейны ставить, но и прочие зависимости тащить, и подключается к разным IDE.
+
avatar
0
Про другие IDE не знаю, пользуюсь vscode.
и прочие зависимости тащить
Ну, по сути, да. То есть, может фреймворк ардуино, например, выкачать, может что-то еще. Но я для avr использую «голый» компилятор, поэтому для меня основное — тулчейн.
+
avatar
  • kiv69
  • 29 ноября 2024, 11:09
0
По правде, PlatformIO сильно недружелюбно к пользователю, если он к подобному софту редко обращается.
Вплоть до того, что то, что собиралось в нём же год назад, сегодня собираться не захочет.
Лично я такой софт считаю кривым.
Но есть фанаты, как есть и такие, которые торопятся ставить любое обновление.
Работает — не трогай. Но это точно не про PlatformIO
+
avatar
0
Мигалку диодами я и на attiny13 сделаю, несколько штук у меня еще есть. Вы вообще информацию по этим контроллерам пробовали искать, или это был комментарий ради комментария? В первом же (и, можно считать, единственном) посте:
мудрые китайцы не зря положили в комплект эту коробочку. Мне удалось достаточно быстро, чисто программными методами убить контроллер и я очень порадовался тому, что есть запасные.
Чисто программными методами убить контроллер? Серьезно? То есть, завтра может пройти глюк по питанию или сильная помеха, контроллер даст сбой, перейдет в невалидное состояние и убьет себя? Лично я на таком железе на данный момент делать ничего не хочу.
впрочем, WCH это не касается, т.к. его уже в pio затянули.
От этого сообщество моментально не появится, и проблемы решаться не станут.
+
avatar
  • Leoniv
  • 23 октября 2024, 10:50
0
Цена контроллера имеет значение, если речь идет о серии в тысячи штук. А для одного изделия — всё равно. А изучать новый контроллер — это время, которое никогда не окупится с таким потреблением. Сегодня действительно ATmega стали дорожать. Поэтому для некоторых проектов перехожу на STM32F030. Но сложный контроллер, нет никакого кайфа от применения. Декодер ИК ДУ переносил с ATmega на него 4 дня с большими нервами!
+
avatar
  • ACE
  • 23 октября 2024, 01:37
+1
А все такие сенсоры не способны измерять расстояние до поверхности воды? VL53L0X не может.
+
avatar
  • Leoniv
  • 23 октября 2024, 10:52
0
Не приходило в голову попробовать. Сейчас этого приборчика нет под рукой.
+
avatar
  • marges
  • 23 октября 2024, 16:16
0
а почему именно лазером измерять, а не ультразвуком?
+
avatar
  • ACE
  • 23 октября 2024, 18:27
0
Ультразвук плох на коротких дистанциях, если бак с водой меньше метра высоты. УЗ сложнее защитить от влаги. Точность, скорее всего, тоже меньше, хотя это уже не главное.
+
avatar
  • marges
  • 23 октября 2024, 21:05
0
Для защиты те датчики, которые в парктрониках авто используются, они вроде защищены.
+
avatar
  • Zelenyj
  • 24 октября 2024, 21:52
0
УЗ луч не может быть узким. И нужна изоляция приемника и передатчика, хоть какое-то их разнесение. В идеальных условиях меряет от нескольких см до нескольких метров. Если отражение пож углом, может не увидеть отражения или намерить сильно больше. Не все обьекты видит, не от всего хорошее отражение. Специфично…
+
avatar
  • marges
  • 23 октября 2024, 16:15
0
а как плату лудили? и на чем печатали? чет не получается у меня такой красоты добиться (
+
avatar
  • Leoniv
  • 23 октября 2024, 19:43
0
Печатал на HP LJ-1200. Лудил обычным паяльником с раствором канифоли.
+
avatar
  • marges
  • 23 октября 2024, 21:04
0
Не, имею ввиду материал.
Журнал, фотобумага, подводка от самоклейки?
+
avatar
  • Leoniv
  • 23 октября 2024, 22:21
+1
Журнал.
+
avatar
  • pavel-7
  • 24 октября 2024, 09:50
0
Спасибо за детальный обзор!
Возник такой вопрос: можно ли данный датчик использовать для измерения скоростей небольших предметов на расстояниях от 0 до 2 м? Не просто измерить начальное положение и конечное и получить серднюю скорость на 2м, а именно снять массив временных меток + расстояния измереннные датчиком? Какого времени между двумя измерениями можно достичь?
+
avatar
  • Leoniv
  • 24 октября 2024, 12:54
0
Минимальный интервал между измерениями 10 мс, само измерение тоже порядка 10 мс. Этот датчик плохо подходит для измерения скорости. Для этого существуют другие микросхемы.
+
avatar
  • pavel-7
  • 24 октября 2024, 12:58
0
Сапсибо! А можете подсказать откуда информация про 10 мс?
+
avatar
  • Leoniv
  • 24 октября 2024, 15:04
0
+
avatar
  • pavel-7
  • 24 октября 2024, 15:09
0
Благодарю!

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.