Интересно, спасибо. Попробовал повторить на локальной виртуалке с проброшенным GPU. Прокси не стал ставить, в локалке и так нормально работает. ОС Debian GNU/Linux 12 (bookworm). Модели очень долго качались, особенно чат и ocr. Казалось все повисло, ничего не менялось, но после часа ожидания процесс все таки двигался. Уже хотел скачанные модели из ollama перекинуть, но не успел за это время найти как это сделать. Надо будет попробовать добавить/заменить модели. Например Qwen 7b/14b поставить, они чуть лучше дают результат. Еще раз спасибо, пишите еще)
Пользовался МК-90 после МК-85 в студенческое время (и МК-52 в школьное). Полезные девайсы. Правда потом удалось запустить маткад на Поиске. После этого курсовые и лабораторные с комплексными числами считались уже там.
Попробовал, занимательно. Работает и удаленная отладка, и вывод через последовательный порт. Правда есть некоторые тормоза, связанные с подгрузкой всего по SSH. И почему-то домашняя страничка PlatformIO - PIO Home открывается пустой, соответственно открыть проект можно только достаточно длинным путем, типа PlatformIO - Get Started и тд
Мне обычного радиатора не хватало. Странно. Согласен насчет возможных подключений, но есть еще пара соображений, тоже очень частных. Первое - это быстрая замена в случае выхода из строя. Если завязаны хотя бы минимальные системы жизнеобеспечения (во загнул), то это важно. У меня обогрев, поддержание разных температур в доме в зависимости от наличия людей. В этом случае, как мне кажется, заменить Orange проще на что-то близкое, его полно. Настройка же новой приставки, если особенно там что-то через ИК, светодиод и тд, займет больше времени. Второе - хочется постепенно уменьшить использование wifi в HA. Потому что для этого обязательна работоспособность роутера или точки доступа, к которой все цепляются, и wifi критичен к количеству устройств, подключенных к роутеру в одну сеть. Например на китайском модеме с симкой почему-то стоит ограничение в 10 штук. Все решается, конечно. Но есть другие варианты - провод, где возможно; BLE, ZigBee и тд с подключением маршрутизатора прямо к серверу HA. Хочу важные устройства перевести на эти технологии, и что-то будет на wifi.
У меня тоже на Orange Pi. Сейчас на Lite, но уже подготовлен на замену Pi3 LTS. Есть сложности с пассивным охлаждением, большие, совсем не родные радиаторы) И если на Pi Lite при большой загрузке (компиляции ESPHome) иногда процессор перегревался и вис, то на Pi3 LTS с таким же радиатором уже все хорошо. И хотя я с вами согласен, но у Orange Pi есть одно преимущество - гребенки входов и выходов, а на устройствах типа X96 их еще надо поискать, хотя можно обойтись и без них, дело вкуса. У меня один pin используется напрямую в HA для перезапуска по питанию модема, мало ли что с ним случится. Еще хочу в ближайшее время задействовать UART для подключения Zigbee.
Отличный вариант максимального использования микроконтроллера в плане подключения устройств.
Однако хотелось бы спросить, оценивалась ли в эффективность данного решения в экономическом плане? Я имею в виду добавление некоторого количества дискретных компонентов и увеличения размеров печатной платы (при массовом изготовлении) по сравнению с переходом на контроллер с большим количеством ног/портов?
Или это просто проект использования того контроллера, который был в наличии под образовавшиеся потребности?
Спасибо за информацию, в хозяйстве пригодится)
Я такой вариант не рассматривал, так как был уверен что микросхемы у меня все равно нет, а транзисторы купить точно дешевле.
Там даже переменный резистор стоит, однако не хватило. Насколько я мог найти информацию в интернете, бывают платы с распаянным регулятором напряжения, который повышает напряжение с 3.3 до 6В, а оно уже идет на регулятор контраста. В моем случае его не было (место под U3 и пассивные компоненты рядом):
При повторе установки пришлось заменить адреса репозитариев (editor /etc/apt/sources.list):
## Debian Lenny base:
deb http://archive.debian.org/debian/ lenny main non-free contrib
deb-src http://archive.debian.org/debian/ lenny main non-free contrib
## Debian Lenny updates:
deb http://archive.debian.org/debian/ lenny-updates main non-free contrib
deb-src http://archive.debian.org/debian/ lenny-updates main non-free contrib
## Debian Lenny Security updates:
deb http://archive.debian.org/debian-security/ lenny/updates main contrib non-free
deb-src http://archive.debian.org/debian-security/ lenny/updates main contrib non-free
## Debian Volatile updates:
deb http://archive.debian.org/debian-volatile lenny/volatile main contrib non-free
deb-src http://archive.debian.org/debian-volatile lenny/volatile main contrib non-free
## Debian Lenny Backports
deb http://archive.debian.org/debian-backports lenny-backports main contrib non-free
deb-src http://archive.debian.org/debian-backports lenny-backports main contrib non-free
Согласен. Да и это наверное не совсем костыли. Это скорее нестандартное использование, выявление скрытых возможностей.
Костыли — это когда например что-то глючит, и наугад ставим задержки чтобы "устаканились" переходные процессы. Или вводим какую-нибудь глобальную переменную, в одном месте в нее заносим что-то, а далеко в другом — проверяем.
А у нас просто оптимизация в рамках заданных аппаратных средств.
Интересно, спасибо. Попробовал повторить на локальной виртуалке с проброшенным GPU. Прокси не стал ставить, в локалке и так нормально работает. ОС Debian GNU/Linux 12 (bookworm). Модели очень долго качались, особенно чат и ocr. Казалось все повисло, ничего не менялось, но после часа ожидания процесс все таки двигался.
Уже хотел скачанные модели из ollama перекинуть, но не успел за это время найти как это сделать.
Надо будет попробовать добавить/заменить модели. Например Qwen 7b/14b поставить, они чуть лучше дают результат.
Еще раз спасибо, пишите еще)
Пользовался МК-90 после МК-85 в студенческое время (и МК-52 в школьное). Полезные девайсы. Правда потом удалось запустить маткад на Поиске. После этого курсовые и лабораторные с комплексными числами считались уже там.
Мультимедиа приставка X96Air на SoC Amlogic S905X3
Orange Pi3 LTS
Попробовал, занимательно. Работает и удаленная отладка, и вывод через последовательный порт. Правда есть некоторые тормоза, связанные с подгрузкой всего по SSH. И почему-то домашняя страничка PlatformIO - PIO Home открывается пустой, соответственно открыть проект можно только достаточно длинным путем, типа PlatformIO - Get Started и тд
Сорри, ответил не в ветке, а ниже
https://habr.com/ru/post/715108/comments/#comment_25199748
Мне обычного радиатора не хватало. Странно.
Согласен насчет возможных подключений, но есть еще пара соображений, тоже очень частных.
Первое - это быстрая замена в случае выхода из строя. Если завязаны хотя бы минимальные системы жизнеобеспечения (во загнул), то это важно. У меня обогрев, поддержание разных температур в доме в зависимости от наличия людей. В этом случае, как мне кажется, заменить Orange проще на что-то близкое, его полно. Настройка же новой приставки, если особенно там что-то через ИК, светодиод и тд, займет больше времени.
Второе - хочется постепенно уменьшить использование wifi в HA. Потому что для этого обязательна работоспособность роутера или точки доступа, к которой все цепляются, и wifi критичен к количеству устройств, подключенных к роутеру в одну сеть. Например на китайском модеме с симкой почему-то стоит ограничение в 10 штук. Все решается, конечно. Но есть другие варианты - провод, где возможно; BLE, ZigBee и тд с подключением маршрутизатора прямо к серверу HA. Хочу важные устройства перевести на эти технологии, и что-то будет на wifi.
У меня тоже на Orange Pi. Сейчас на Lite, но уже подготовлен на замену Pi3 LTS. Есть сложности с пассивным охлаждением, большие, совсем не родные радиаторы) И если на Pi Lite при большой загрузке (компиляции ESPHome) иногда процессор перегревался и вис, то на Pi3 LTS с таким же радиатором уже все хорошо.
И хотя я с вами согласен, но у Orange Pi есть одно преимущество - гребенки входов и выходов, а на устройствах типа X96 их еще надо поискать, хотя можно обойтись и без них, дело вкуса. У меня один pin используется напрямую в HA для перезапуска по питанию модема, мало ли что с ним случится. Еще хочу в ближайшее время задействовать UART для подключения Zigbee.
Однако хотелось бы спросить, оценивалась ли в эффективность данного решения в экономическом плане? Я имею в виду добавление некоторого количества дискретных компонентов и увеличения размеров печатной платы (при массовом изготовлении) по сравнению с переходом на контроллер с большим количеством ног/портов?
Или это просто проект использования того контроллера, который был в наличии под образовавшиеся потребности?
У меня UART был занят консолью, второго не нашел, возможно не разведен, а I2C в наличии и свободна.
Я такой вариант не рассматривал, так как был уверен что микросхемы у меня все равно нет, а транзисторы купить точно дешевле.
## Debian Lenny base:
deb http://archive.debian.org/debian/ lenny main non-free contrib
deb-src http://archive.debian.org/debian/ lenny main non-free contrib
## Debian Lenny updates:
deb http://archive.debian.org/debian/ lenny-updates main non-free contrib
deb-src http://archive.debian.org/debian/ lenny-updates main non-free contrib
## Debian Lenny Security updates:
deb http://archive.debian.org/debian-security/ lenny/updates main contrib non-free
deb-src http://archive.debian.org/debian-security/ lenny/updates main contrib non-free
## Debian Volatile updates:
deb http://archive.debian.org/debian-volatile lenny/volatile main contrib non-free
deb-src http://archive.debian.org/debian-volatile lenny/volatile main contrib non-free
## Debian Lenny Backports
deb http://archive.debian.org/debian-backports lenny-backports main contrib non-free
deb-src http://archive.debian.org/debian-backports lenny-backports main contrib non-free
После этого:
Костыли — это когда например что-то глючит, и наугад ставим задержки чтобы "устаканились" переходные процессы. Или вводим какую-нибудь глобальную переменную, в одном месте в нее заносим что-то, а далеко в другом — проверяем.
А у нас просто оптимизация в рамках заданных аппаратных средств.