В GNU/Linux обычно используется динамическая линковка библиотек. В Windows приложения все зависимости тащат с собой. В этом и разница. Поэтому в винде может куча версий Qt/GTK существовать, для каждого приложения своя. Если вы соберёте приложение под Linux статистически или вместе с зависимостями положите в контейнер – выйдет то же самое, что и на винде.
Так что вас не устраивает? Вы хотите, чтобы во всех библиотеках и фреймворках всегда поддерживалась идеальная обратная совместимость? Или чтобы каждая утилита тащила с собой вагон своих зависимостей, как в винде? Если да, именно этого вам и хочется – то это и называется контейнеры, не надо нос воротить. Контейнеры – это не виртуалки, производительность там не страдает. Единственный минус – больше весят, но так и на винде приложения столько же весят, если тащат с собой все зависимости.
Только не ищите по принципу "самый дешевый блок на 100w". Возьмите известный и проверенный временем бренд: ugreen, baseus, anker. Они делают качественные блоки и повербанки, за всё время использования не было проблем. Разве что Baseus 140W Gan 5 Pro не особо хорошо работал в режиме отдачи 140 ватт - пришлось взять аналогичный по мощности блок от Ugreen.
Конечно можно! Только сейчас понял, что забыл указать лицензию. Только что сделал коммит, исправил это упущение. Мой проект опубликован под MIT License. Вот только я не особо понимаю, какое именно железо вы хотите сделать, просто развести в KiCAD плату под esp32 + трансивер? Или вы хотите сделать изолированный CAN?
Отличная идея! Дело в том, что мои юзкейсы подразумевали, что esp32-c3 питается от ноутбука через USB, и через тот же порт идёт передача данных. Плюс компонент Console подразумевает работу по Serial. Но ваша идея очень интересная, можно поднять на esp32-c3 telnet сервер, и иметь такую же консоль удаленно. Получится неплохой беспроводной мост для удаленного мониторинга системы с CAN bus.
По просьбе автора посоветую хабру хороший анонимный хостинг с оплатой через Litecoin (LTC). Комиссия в этой криптовалюте очень маленькая. Пользуюсь хостингом уже 2 года. https://app.bitlaunch.io/
Зарядный ток получается чуть больше 1С (емкость аккумулятора 850 мАч), 1А там вполне допустим, слегка больше рекомендуемого 1С. Не ограничиваю источником тока. Нагрева аккумулятора при зарядке замечено не было. Увы, конкретно в этом чипе регулировка зарядного тока не предусмотрена.
Собирал недавно схему питания для простенького проекта на IP5305. Элементарный чип, минимальная обвязка, конфигурация с помощью резисторов. Уровень заряда может через светодиоды сообщать, можно подключать от 1 до 4 светодиодов. Всего 1 дроссель, через него и понижает напряжение для зарядки Li-Ion, и повышает до 5в для питания микроконтроллера. Есть возможность подключения кнопки питания, с помощью которой включается/выключается повышайка. В выключенном состоянии потребление минимальное. Защита от кз присутствует, и не только, можно глянуть в даташите подробнее. Понижайку до 3.3в можно сделать с помощью любого линейного регулятора, тот же AMS1117-3.3, мониторинг напряжения на аккумуляторе - делитель напряжения + ЦАП, встроенный в микроконтроллер. Да, будет чуть подсаживать аккумулятор, но если там около 100кОм в делителе - то не особо критично. Либо просто по светодиодам, котороые подцепить к микрухе. Схема выходит простейшая, можно развести на одном слое и сделать плату хоть лутом/фоторезистом, что я и проделывал. Идеально для простых самоделок. Но если что-то посложнее - я бы уже искал контроллер питания с I2C, чтобы был поумнее.
Фото простой электронной открытки с IP5305 (фоторезист)
Криво, косо, в лучших традициях "успеть сделать за ночь"
Про "светить наружу" - ну это глупости, ясно, что данные не будут передаваться в сыром, незашифрованном виде. Иначе тот же WiFi и все прочие протоколы были бы подвержены перехвату куда больше, ведь радиоволны перехватить куда проще, чем свет. По факту же, легкость перехвата сырого трафика должна компенсироваться стойким шифрованием. А лучше будет потому, что опыт уже есть, и каждый новый протокол содержит меньше дыр (по крайней мере, в идеальном мире должно работать именно так), и не думаю, что возникнут сложности с переносом протоколов аутентификации и прочего с WiFi на LiFi. Так что за безопасность волноваться не стоит. Пока я вижу это так - скорость выше, чем WiFi, проходимость сигнала хуже. Если проходящие мимо оборудования люди будут прерывать сигнал - это минус, если человек не сможет спокойно перемещаться внутри помещения с девайсом - это минус. А для стационарного использования намного дешевле кинуть кабель, чем городить LiFi. Поэтому пока не вижу, в чем LiFi выигрывает. Возможно, там не направленным лучом передаются данные, а рассеянным освещением, или даже в основные источники света встроить хотят? Тогда это отчасти закрывает вопрос, но как обратно телефон передавать будет? Тоже мощных излучатель с широким углом? А на какой длине волны передача? Столько вопросов... Было бы здорово, если бы ответил человек, который разбирается в этой теме. P.S. Ещё кажется интересной идея, когда данные принимаются с помощью света, а передаются с мобильного устройства по радиоканалу. Это позволит использовать мощные основные источники света в помещении для передачи данных, не нужен будет направленный луч, радиодиапазон сильно разгрузится и заметно вырастет скорость на прием. А средний пользователь интернета гораздо больше скачивает, через передает.
Советую ознакомиться https://www.signalintegrityjournal.com/articles/1589-the-myth-of-three-capacitor-values
В GNU/Linux обычно используется динамическая линковка библиотек. В Windows приложения все зависимости тащат с собой. В этом и разница. Поэтому в винде может куча версий Qt/GTK существовать, для каждого приложения своя. Если вы соберёте приложение под Linux статистически или вместе с зависимостями положите в контейнер – выйдет то же самое, что и на винде.
Так что вас не устраивает? Вы хотите, чтобы во всех библиотеках и фреймворках всегда поддерживалась идеальная обратная совместимость? Или чтобы каждая утилита тащила с собой вагон своих зависимостей, как в винде? Если да, именно этого вам и хочется – то это и называется контейнеры, не надо нос воротить. Контейнеры – это не виртуалки, производительность там не страдает. Единственный минус – больше весят, но так и на винде приложения столько же весят, если тащат с собой все зависимости.
Это же пост, а не статья. Нововведение хабра. Посты обычно короткие, в отличие от статей
Только не ищите по принципу "самый дешевый блок на 100w". Возьмите известный и проверенный временем бренд: ugreen, baseus, anker. Они делают качественные блоки и повербанки, за всё время использования не было проблем. Разве что Baseus 140W Gan 5 Pro не особо хорошо работал в режиме отдачи 140 ватт - пришлось взять аналогичный по мощности блок от Ugreen.
Увы, контроллер CAN в esp32 такое не поддерживает. Нужен другой контроллер
Конечно можно! Только сейчас понял, что забыл указать лицензию. Только что сделал коммит, исправил это упущение. Мой проект опубликован под MIT License.
Вот только я не особо понимаю, какое именно железо вы хотите сделать, просто развести в KiCAD плату под esp32 + трансивер? Или вы хотите сделать изолированный CAN?
Спасибо! Интересно, не знал про gs_usb. Выглядит очень хорошо. С cantools знаком, да
Дело в том, что esp32, esp32-s3 – двухъядерные, поэтому FreeRTOS в esp-idf отличается от оригинальной версии от Amazon. Но шутку заценил)
Отличная идея! Дело в том, что мои юзкейсы подразумевали, что esp32-c3 питается от ноутбука через USB, и через тот же порт идёт передача данных. Плюс компонент Console подразумевает работу по Serial. Но ваша идея очень интересная, можно поднять на esp32-c3 telnet сервер, и иметь такую же консоль удаленно. Получится неплохой беспроводной мост для удаленного мониторинга системы с CAN bus.
Что только не придумают люди, лишь бы не ставить линукс :)
В virt-manager прекрасно работает общий буфер обмена, инструкции гуглятся за минуту
По просьбе автора посоветую хабру хороший анонимный хостинг с оплатой через Litecoin (LTC). Комиссия в этой криптовалюте очень маленькая. Пользуюсь хостингом уже 2 года.
https://app.bitlaunch.io/
Это не SoC BL808, случайно? Поделитесь подробностями?
Зарядный ток получается чуть больше 1С (емкость аккумулятора 850 мАч), 1А там вполне допустим, слегка больше рекомендуемого 1С. Не ограничиваю источником тока. Нагрева аккумулятора при зарядке замечено не было. Увы, конкретно в этом чипе регулировка зарядного тока не предусмотрена.
Попробуйте LibreWolf - форк Firefox, нацеленный на приватность. Вот уже 2 года это мой основной браузер.
Собирал недавно схему питания для простенького проекта на IP5305. Элементарный чип, минимальная обвязка, конфигурация с помощью резисторов. Уровень заряда может через светодиоды сообщать, можно подключать от 1 до 4 светодиодов. Всего 1 дроссель, через него и понижает напряжение для зарядки Li-Ion, и повышает до 5в для питания микроконтроллера. Есть возможность подключения кнопки питания, с помощью которой включается/выключается повышайка. В выключенном состоянии потребление минимальное. Защита от кз присутствует, и не только, можно глянуть в даташите подробнее. Понижайку до 3.3в можно сделать с помощью любого линейного регулятора, тот же AMS1117-3.3, мониторинг напряжения на аккумуляторе - делитель напряжения + ЦАП, встроенный в микроконтроллер. Да, будет чуть подсаживать аккумулятор, но если там около 100кОм в делителе - то не особо критично. Либо просто по светодиодам, котороые подцепить к микрухе. Схема выходит простейшая, можно развести на одном слое и сделать плату хоть лутом/фоторезистом, что я и проделывал. Идеально для простых самоделок. Но если что-то посложнее - я бы уже искал контроллер питания с I2C, чтобы был поумнее.
Фото простой электронной открытки с IP5305 (фоторезист)
Есть ещё неплохой аналог - IP5209, эта микруха по I2C ещё и State of Charge умеет отдавать
Какие преимущества по сравнению с KiCAD у LibrePCB?
Анна Каренина уже не та...
Про "светить наружу" - ну это глупости, ясно, что данные не будут передаваться в сыром, незашифрованном виде. Иначе тот же WiFi и все прочие протоколы были бы подвержены перехвату куда больше, ведь радиоволны перехватить куда проще, чем свет. По факту же, легкость перехвата сырого трафика должна компенсироваться стойким шифрованием. А лучше будет потому, что опыт уже есть, и каждый новый протокол содержит меньше дыр (по крайней мере, в идеальном мире должно работать именно так), и не думаю, что возникнут сложности с переносом протоколов аутентификации и прочего с WiFi на LiFi.
Так что за безопасность волноваться не стоит. Пока я вижу это так - скорость выше, чем WiFi, проходимость сигнала хуже. Если проходящие мимо оборудования люди будут прерывать сигнал - это минус, если человек не сможет спокойно перемещаться внутри помещения с девайсом - это минус. А для стационарного использования намного дешевле кинуть кабель, чем городить LiFi. Поэтому пока не вижу, в чем LiFi выигрывает. Возможно, там не направленным лучом передаются данные, а рассеянным освещением, или даже в основные источники света встроить хотят? Тогда это отчасти закрывает вопрос, но как обратно телефон передавать будет? Тоже мощных излучатель с широким углом? А на какой длине волны передача? Столько вопросов... Было бы здорово, если бы ответил человек, который разбирается в этой теме.
P.S. Ещё кажется интересной идея, когда данные принимаются с помощью света, а передаются с мобильного устройства по радиоканалу. Это позволит использовать мощные основные источники света в помещении для передачи данных, не нужен будет направленный луч, радиодиапазон сильно разгрузится и заметно вырастет скорость на прием. А средний пользователь интернета гораздо больше скачивает, через передает.