Небольшое уточнение, на плате, видимо, стоит MAX3232esa, а не MAX232esa, как указано на диаграмме: 232 не умеет работать от 3,3 вольт и ей нужны конденсаторы 1 мкф, а не 0,1 как на плате.
В целом хорошая плата для отладки в "настольных" условиях, но вот в промышленное применение она никак не укладывается: интерфейсы никак не защищены: ни супрессоров, ни разрядников. По питанию тоже никаких защит. Даже на USB зажали поставить какую-нибудь USBLC6.
Ещё в качестве потенциальных граблей вижу, кто около microSD нет крупного конденсатора, который бы не помешал, в процессе работы карточка может пожирать серьёзные импульсные токи.
Поставили полноценный DB9 разъём, а развести полноценный RS232 поленились. К чему тогда такой разъём городить, поставили бы 3 пина и всё.
Стоит осциллятор для Ethernet, а для микроконтроллера поставили отдельный обычный кварц... Странное решение.
Но все эти косячки не являются чем-то смертельным, за такую цену эта плата "топ за свои деньги".
И, может, кто-нибудь раскроет великую тайну, зачем на таких платах ставят полноразмерный JTAG? Для полноценной отладки Cortex-ядерных микроконтроллеров достаточно SWD: GND и 4 сигнальных проводов: SWD, SWC, Reset, SWO, причём последние 2 нужны далеко не всегда.
Отличный проект, спасибо, удобно использовать с FNIRSI DPS-150. Только не удалось заставить работать на Android Chrome, это не поддерживается, или я что-то не так делаю? Web Serial же вроде должен работать на Android? Может, какие-то разрешения надо выдать?
Подскажите, а Tailscale работает в условиях блокировок? Недавно попал в неприятную ситуацию, когда Google Remote Desktop попал под блокировки, ничего не спасало (находился в отпуске за границей, пытался достучаться до домашнего ПК в РФ). "Пробился" только через AnyDesk, но их фирменное "Обнаружено коммерческое использование, ждите по 100 секунд каждые 3 минуты", долго терпеть не получается. Теперь думаю об аппаратном решении.
По теме могу порекондовать ознакомиться с этим видеокурсом, с упором на встраиваемые системы, но суть та же. Автор очень подробно показывает, что "под капотом" у механизмов ООП, скрытых компилятором С++.
#29 OOP Part-1: Encapsulation (classes) in C and C++ #30 OOP Part-2: Inheritance in C and C++ #31 OOP Part-3: Polymorphism in C++ #32 OOP Part-4: Polymorphism in C
Не совсем понял, ведь HDQ как раз и работает по одному проводу - по аналогии с 1-wire, только без паразитного питания. Но и это решается: можно либо организовать паразитное питание диодно-конденсаторной цепочкой, либо, как я выше писал, запитать gauge от АКБ через делитель. Микросхема потребляет крайне мало, сопоставимо с саморазрядом Li-Ion батарей, а про кислотные и говорить не приходится.
Интересно понять, почему было принято решение создавать своё решение, а не "прикостылить" готовое.
Здравствуйте. А как Вы реализовывали SoC и SoH ? Или это решение только для ID и температуры?
И почему не использовали давно изобретённый HDQ, который применяется в микросхемах "Fuel Gauge" типа BQ27545 ? Кстати, можно было эту микросхему и использовать, поставив резистивный делитель на батарею, используя только функции измерения температуры, счётчика тока (режим кулономера) и UID.
На мой взгляд, всё пошло в сторону какого-то чрезмерного и ненужного усложнения. Я бы очень хотел иметь очки, которые бы со смартфона передавали указания навигатора: налево, направо и т.п. для прогулок, бега или велосипеда (или даже мотоцикла). Очень часто бывает, что при следовании указаниям навигатора в незнакомом городе то и дело приходится доставать телефон, чтобы посмотреть, куда идти. А при беге удобно было бы смотреть пульс или другие параметры. То есть, тут даже AR не требуется, просто дисплей, подключенный по bluetooth к телефону и всё. Грубо говоря, автомобильный HUD, но в очках. И вот нет такого! Зато создали огромный тяжеленный тренажёр для мышц шеи от Apple... В статье упоминается RayBan в качестве смарт-очков, глянул - это просто очки с видеокамерой для стриминга - никакого "смарт", просто камеру воткнули в очки и всё, вывода информации нет.
Искал серебро, а нашёл золото. На удивление, в интернете мало информации про модель данных "1 источник - много приёмников" для встраиваемых RTOS, в частности для FreeRTOS. А задача-то типовая: пример. АЦП считывает сигнал, который должен быть обработан: а) ПИД-регулятором. б) Записан в лог. в) Выведен на дисплей. То есть, источник данных один, а приёмников много, и они "спят", пока нет новых данных. Я для этого обычно использовал GlobalEvent и TaskNotification - очереди в данном случае избыточны. Но библиотека ETL очень понравилась, спасибо большое за ссылку. Может, ещё что-то хорошее подскажете на эту тему?
Здравствуйте, очень интресная тема. Поскажите, как решали вопрос с частотой дискретизации АЦП? Грубо говоря, когда потребление будет "иголками", которые не будут учтены в силу недостаточной частоты преобразования. При этом ставить слишком большую частоту преобразования АЦП, как правило, тоже не очень хорошая идея - повышенный "жор" энергии. Обычно этот вопрос решается интегрирующими цепочками, но в схеме шунт подключен к АЦП напрямую.
И можно с исходниками ознакомиться? Особенно с частью аналогово-цифрового преобразования в контексте пониженного энергопотребления.
Здравствуйте. Огромное спасибо, очень интересный материал, с интересом поизучал элементную базу.
Подскажите, пожалуйста, в схеме Вашего устройства довольно нестандартное включение основного кварца на 8 МГц, что это даёт?
Ещё интересно, почему номинал подтягивающего резистора USB DP (подключен к РА15 микроконтроллера), который R50, выбран 510 Ом, хотя по стандарту 1,5 кОм?
В схеме измерения внутреннего сопротивления батареи, как мне кажется, диод SS34 на Вашей схеме (в схеме оригинала прибора тоже подобный есть) лучше заменить на полевой транзистор по схеме "идеального диода", чтобы не мешал измерениям.
Инструментальный операционный осилитель U4 не подписан, это AD8541, как в схеме в Proteus? Нет искажений при питании 3,3 вольт?
Для чего используются драйверы I2C шины на транзисторах Q14 и Q15 ?
Зачем шунтированы диодами D1 и D2 светодиоды D4 и D5?
Код не получается скачать, можете, пожалуйста, обновить ссылку?
Первая проблема легко решается отправкой клавиш CAPSLOCK, NUMLOCK, SCROLLOCK - хост, если он в состоянии готовности, в ответ на нажатие присылает пакет, чтобы переключить соответствующий светодиод. Вторая проблема обходится вводом символов по их кодам Unicode (alt + 4-значный код).
Тут небольшая путаница в терминологии: Cmake - это способ управления компилятором. IDE (integrated development environment) - это интегрированная среда разработки, куда помимо инструментов управления компилятором, входят другие полезные вещи, вроде отладчика, терминалов, инструментов работы с репозиториями и т.п.
Я вообще не представляю, как без помощи IDE производить отладку программы?
И да, если мы говорим про Embedded, то Eclipse (и IDE на нём базирующиеся, наподобие STM Cube IDE, ESP-IDF), VSCode + PlatformIO - бесплатны. Очень хороший инструмент VisualGDB для Embedded систем стоит 100 долларов в год (https://visualgdb.com/buy/).
Поскольку это устройство может быть использовано для последующих обвинениях заказчика в некорректной эксплуатации оборудования, то программа очень далека от идеала.
Для начала, ATMEL, а теперь Microchip, не рекомендует использовать ячейку EEPROM с адресом 0 из-за возможной порчи при включении/выключении контроллера. Далее, хорошим тоном будет писать переменную в несколько мест EEPROM, чтобы при единичных ошибках корректировать значение. Неплохо было бы добавить запись счётчика просто по мере работы программы, раз секунд в 10. И ещё запись в EEPROM принято верифицировать после записи.
По схеме тоже много вопросов. Отсутствует конденсатор между RESET микроконтроллера и GND, чтобы обеспечить корректный сброс при запуске, как рекомендует производитель. Выше уже отметили крайнюю уязвимость устройтсва к помехам и повышенному напряжению по линии питания. Ещё, Вы считаете время работы, но при этом ориентируетесь на встроенный RC-генератором микроконтроллера, который точностью частоты не отличается и крайне зависим от температуры кристалла.
Откровенно говоря, лучшим решением было бы взять какую-нибудь готовую мелкую плату (благодаря arduino-экосистеме таких плат пруд-пруди по смешной цене) и прошить её, тогда бы потенциальных проблем с железом было бы заведомо меньше.
К сожалению, этим устройством не пользуюсь, просто по мере прочтения статьи описаны интересные проблемы при разработке ПО, я настроился на ознакомление с исходниками, и их не оказалось.
Выше ответил, устройство подключается к компьютеру через USB - это огромный простор для деятельности. Я не хочу подозревать автора, однако, повторюсь, в прошивку может быть, например, заложена функция логирования всех клавиш. Поскольку устройство позиционируется как элемент безопасности, нужно ко всем звеньям относиться с недоверием.
Очень много: оно же определяется в системе как клавиатура, подключенная к компьютеру. Можно, как минимум, запустить консоль и ввести парочку интересных команд. Можно прикинуться сетевым устройством RNDIS и отправить файлик со всем списком нажатых клавиш в сеть.
Я могу понять нежелание автора делиться исходными файлами, однако с чужой скомпилированной прошивкой сам концепт такого устроства теряет смысл: предлагается хранить свои пароли на устройстве со сторонним программным обеспечением, которое может быть преднамеренно или непреднамеренно скомпрометировано. Смысл в этом? Тут либо полностью открытые исходные коды, либо никак.
Небольшое уточнение, на плате, видимо, стоит MAX3232esa, а не MAX232esa, как указано на диаграмме: 232 не умеет работать от 3,3 вольт и ей нужны конденсаторы 1 мкф, а не 0,1 как на плате.
В целом хорошая плата для отладки в "настольных" условиях, но вот в промышленное применение она никак не укладывается: интерфейсы никак не защищены: ни супрессоров, ни разрядников. По питанию тоже никаких защит. Даже на USB зажали поставить какую-нибудь USBLC6.
Ещё в качестве потенциальных граблей вижу, кто около microSD нет крупного конденсатора, который бы не помешал, в процессе работы карточка может пожирать серьёзные импульсные токи.
Поставили полноценный DB9 разъём, а развести полноценный RS232 поленились. К чему тогда такой разъём городить, поставили бы 3 пина и всё.
Стоит осциллятор для Ethernet, а для микроконтроллера поставили отдельный обычный кварц... Странное решение.
Но все эти косячки не являются чем-то смертельным, за такую цену эта плата "топ за свои деньги".
И, может, кто-нибудь раскроет великую тайну, зачем на таких платах ставят полноразмерный JTAG? Для полноценной отладки Cortex-ядерных микроконтроллеров достаточно SWD: GND и 4 сигнальных проводов: SWD, SWC, Reset, SWO, причём последние 2 нужны далеко не всегда.
Отличный проект, спасибо, удобно использовать с FNIRSI DPS-150. Только не удалось заставить работать на Android Chrome, это не поддерживается, или я что-то не так делаю? Web Serial же вроде должен работать на Android? Может, какие-то разрешения надо выдать?
Подскажите, а Tailscale работает в условиях блокировок? Недавно попал в неприятную ситуацию, когда Google Remote Desktop попал под блокировки, ничего не спасало (находился в отпуске за границей, пытался достучаться до домашнего ПК в РФ). "Пробился" только через AnyDesk, но их фирменное "Обнаружено коммерческое использование, ждите по 100 секунд каждые 3 минуты", долго терпеть не получается. Теперь думаю об аппаратном решении.
По теме могу порекондовать ознакомиться с этим видеокурсом, с упором на встраиваемые системы, но суть та же. Автор очень подробно показывает, что "под капотом" у механизмов ООП, скрытых компилятором С++.
https://www.state-machine.com/video-course
Конкретно лекции:
#29 OOP Part-1: Encapsulation (classes) in C and C++
#30 OOP Part-2: Inheritance in C and C++
#31 OOP Part-3: Polymorphism in C++
#32 OOP Part-4: Polymorphism in C
Понял, спасибо! Интересно было бы взглянуть на схемотехнические решения контроллера заряда, в частности на метод подсчёта заряда.
Не совсем понял, ведь HDQ как раз и работает по одному проводу - по аналогии с 1-wire, только без паразитного питания. Но и это решается: можно либо организовать паразитное питание диодно-конденсаторной цепочкой, либо, как я выше писал, запитать gauge от АКБ через делитель. Микросхема потребляет крайне мало, сопоставимо с саморазрядом Li-Ion батарей, а про кислотные и говорить не приходится.
Интересно понять, почему было принято решение создавать своё решение, а не "прикостылить" готовое.
Здравствуйте. А как Вы реализовывали SoC и SoH ? Или это решение только для ID и температуры?
И почему не использовали давно изобретённый HDQ, который применяется в микросхемах "Fuel Gauge" типа BQ27545 ? Кстати, можно было эту микросхему и использовать, поставив резистивный делитель на батарею, используя только функции измерения температуры, счётчика тока (режим кулономера) и UID.
На мой взгляд, всё пошло в сторону какого-то чрезмерного и ненужного усложнения. Я бы очень хотел иметь очки, которые бы со смартфона передавали указания навигатора: налево, направо и т.п. для прогулок, бега или велосипеда (или даже мотоцикла). Очень часто бывает, что при следовании указаниям навигатора в незнакомом городе то и дело приходится доставать телефон, чтобы посмотреть, куда идти. А при беге удобно было бы смотреть пульс или другие параметры. То есть, тут даже AR не требуется, просто дисплей, подключенный по bluetooth к телефону и всё. Грубо говоря, автомобильный HUD, но в очках. И вот нет такого! Зато создали огромный тяжеленный тренажёр для мышц шеи от Apple... В статье упоминается RayBan в качестве смарт-очков, глянул - это просто очки с видеокамерой для стриминга - никакого "смарт", просто камеру воткнули в очки и всё, вывода информации нет.
Искал серебро, а нашёл золото. На удивление, в интернете мало информации про модель данных "1 источник - много приёмников" для встраиваемых RTOS, в частности для FreeRTOS. А задача-то типовая: пример. АЦП считывает сигнал, который должен быть обработан: а) ПИД-регулятором. б) Записан в лог. в) Выведен на дисплей. То есть, источник данных один, а приёмников много, и они "спят", пока нет новых данных. Я для этого обычно использовал GlobalEvent и TaskNotification - очереди в данном случае избыточны. Но библиотека ETL очень понравилась, спасибо большое за ссылку. Может, ещё что-то хорошее подскажете на эту тему?
Здравствуйте, очень интресная тема. Поскажите, как решали вопрос с частотой дискретизации АЦП? Грубо говоря, когда потребление будет "иголками", которые не будут учтены в силу недостаточной частоты преобразования. При этом ставить слишком большую частоту преобразования АЦП, как правило, тоже не очень хорошая идея - повышенный "жор" энергии. Обычно этот вопрос решается интегрирующими цепочками, но в схеме шунт подключен к АЦП напрямую.
И можно с исходниками ознакомиться? Особенно с частью аналогово-цифрового преобразования в контексте пониженного энергопотребления.
Здравствуйте. Огромное спасибо, очень интересный материал, с интересом поизучал элементную базу.
Подскажите, пожалуйста, в схеме Вашего устройства довольно нестандартное включение основного кварца на 8 МГц, что это даёт?
Ещё интересно, почему номинал подтягивающего резистора USB DP (подключен к РА15 микроконтроллера), который R50, выбран 510 Ом, хотя по стандарту 1,5 кОм?
В схеме измерения внутреннего сопротивления батареи, как мне кажется, диод SS34 на Вашей схеме (в схеме оригинала прибора тоже подобный есть) лучше заменить на полевой транзистор по схеме "идеального диода", чтобы не мешал измерениям.
Инструментальный операционный осилитель U4 не подписан, это AD8541, как в схеме в Proteus? Нет искажений при питании 3,3 вольт?
Для чего используются драйверы I2C шины на транзисторах Q14 и Q15 ?
Зачем шунтированы диодами D1 и D2 светодиоды D4 и D5?
Код не получается скачать, можете, пожалуйста, обновить ссылку?
Спасибо!
Первая проблема легко решается отправкой клавиш CAPSLOCK, NUMLOCK, SCROLLOCK - хост, если он в состоянии готовности, в ответ на нажатие присылает пакет, чтобы переключить соответствующий светодиод. Вторая проблема обходится вводом символов по их кодам Unicode (alt + 4-значный код).
Тут небольшая путаница в терминологии: Cmake - это способ управления компилятором. IDE (integrated development environment) - это интегрированная среда разработки, куда помимо инструментов управления компилятором, входят другие полезные вещи, вроде отладчика, терминалов, инструментов работы с репозиториями и т.п.
Я вообще не представляю, как без помощи IDE производить отладку программы?
И да, если мы говорим про Embedded, то Eclipse (и IDE на нём базирующиеся, наподобие STM Cube IDE, ESP-IDF), VSCode + PlatformIO - бесплатны. Очень хороший инструмент VisualGDB для Embedded систем стоит 100 долларов в год (https://visualgdb.com/buy/).
Поскольку это устройство может быть использовано для последующих обвинениях заказчика в некорректной эксплуатации оборудования, то программа очень далека от идеала.
Для начала, ATMEL, а теперь Microchip, не рекомендует использовать ячейку EEPROM с адресом 0 из-за возможной порчи при включении/выключении контроллера. Далее, хорошим тоном будет писать переменную в несколько мест EEPROM, чтобы при единичных ошибках корректировать значение. Неплохо было бы добавить запись счётчика просто по мере работы программы, раз секунд в 10. И ещё запись в EEPROM принято верифицировать после записи.
По схеме тоже много вопросов. Отсутствует конденсатор между RESET микроконтроллера и GND, чтобы обеспечить корректный сброс при запуске, как рекомендует производитель. Выше уже отметили крайнюю уязвимость устройтсва к помехам и повышенному напряжению по линии питания. Ещё, Вы считаете время работы, но при этом ориентируетесь на встроенный RC-генератором микроконтроллера, который точностью частоты не отличается и крайне зависим от температуры кристалла.
Откровенно говоря, лучшим решением было бы взять какую-нибудь готовую мелкую плату (благодаря arduino-экосистеме таких плат пруд-пруди по смешной цене) и прошить её, тогда бы потенциальных проблем с железом было бы заведомо меньше.
К сожалению, этим устройством не пользуюсь, просто по мере прочтения статьи описаны интересные проблемы при разработке ПО, я настроился на ознакомление с исходниками, и их не оказалось.
Выше ответил, устройство подключается к компьютеру через USB - это огромный простор для деятельности. Я не хочу подозревать автора, однако, повторюсь, в прошивку может быть, например, заложена функция логирования всех клавиш. Поскольку устройство позиционируется как элемент безопасности, нужно ко всем звеньям относиться с недоверием.
Очень много: оно же определяется в системе как клавиатура, подключенная к компьютеру. Можно, как минимум, запустить консоль и ввести парочку интересных команд. Можно прикинуться сетевым устройством RNDIS и отправить файлик со всем списком нажатых клавиш в сеть.
Я могу понять нежелание автора делиться исходными файлами, однако с чужой скомпилированной прошивкой сам концепт такого устроства теряет смысл: предлагается хранить свои пароли на устройстве со сторонним программным обеспечением, которое может быть преднамеренно или непреднамеренно скомпрометировано. Смысл в этом? Тут либо полностью открытые исходные коды, либо никак.
Если скачать Eclipse у Espressif (он называется ESP IDF), там всё это можно сделать в полуавтоматическом режиме. Ссылка на документацию по этому поводу: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/get-started/windows-setup.html