Пользовался платами с али, про которые в комментах тут писали. Интерфейсы CANable, SocketCAN, CANtact, UART-CAN - всё открытые прошивки. С гальваноразвязкой тоже есть. В линуксе работают из коробки. can-utils и python-can заводил.
Но был нюанс: не удавалось сбросить буфер передачи. Когда пакет никто в сети не подтверждает, некоторые прошивки успокаиваются через 2-5 секунд. А некоторые прошивки уходят в бесконечный повтор, и только отключение от USB помогает.
Плата SYS TEC USB-CANmodul1 нормально отрабатывает отвал от кан-шины? А другие? Может, у кого есть опыт?
У опытных товарищей особого снобизма не наблюдаю. Понятно, что транслируемые, компилируемые и байт-кодные языки - каждый для своих задач удобен.
Я сам недолюбливаю javascript по другой причине. Не сам язык, а его использование. Потому что де-факто это стандарт для "фронтовиков", ну и для браузеров. При этом он способен превратить кБ веб-страницы в ГБ ОЗУ. И опустит производительность проца с ГГц до кГц.
И приходится часто обновлять вполне годное железо, особенно мобильное. Патамущта сайты разбухли. Даже в самую простецкую веб-страницу, включая зависимости, наваливается МБ говнокода. Который жрёт ГБ памяти при выполнении. А информации по факту там на кБ от силы.
ActionScript, который Flash-анимация, когда-то пытался ужать этот объём, но не сраслось. Стандартизация - это хорошо, но не за счёт таких ресурсов.
Хром поиском по странице выдаёт "self" 649 штук. С точкой "self." и с запятой "self," чуть поменьше, но их тоже больше 600 штук.
Для замшелого Сишника странность в том, что у питона область видимости переменной нужно задавать явно. Для глобальных переменных - один раз на функцию. А для свойств текущего объекта - каждый раз при упоминании этого свойства. Поэтому код становится похож на ООП, написанный на ассемблере Си без плюсов - нужно всегда явно указывать тот самый this/self.
Я бы сразу горячюю клавишу для ввода "self." назначил. Как в ZX-Spectrum)
Потери зависят от разности напряжений ячеек. Если разность 4%, то и потери порядка 4%. Мы же не разряжаем конденсаторы до 0 V.
А раз балансир стремится выровнять напряжения, процент потерь на Rdson стремится к 0.
Точно также многокаскадные схемы накачки заряда, или умножения напряжения работают: если не позволять выходному напряжению сильно проседать, то кпд не самый плохой выходит.
Ёмкостный с частотой переключения 1 МГц будет содержать такие же конденсаторы, тех же размеров, что на плате с ETA3000. Только дросселя не будет.
При большом разбалансе, конечно, ёмкостный будет жрать энергию [разность напряжений] x [ток баланса].
Ради интереса, сравните ток собственного потребления для емкостного балансира с алиэкспресс, на который Вы дали ссылку, и потребление балансира на eta3000.
Эти решения для разных целей используются. ETA3000 хорошо балансирует 2 соседние ячейки, но не справится с батарей длиннее, чем 4-5S. Зато простая, монолитная, и, соответственно, мало жрёт.
Ёмкостное решение сделано на дискретных элементах и отдельных драйверах затворов, поэтому жрёт довольно много. Зато умеет перекачивать энергию из любой ячейки в любую, пока они все точно не сравняются. Для большой батареи 8-12S с 10 кг лития за $100500 это решение я считаю лучше.
Индуктивный балансир, умеющий перекачивать из любой банки в любую, наверное, тоже можно сделать. И он будет более эффективным. Но по схемотехнике будет ещё сложнее.
я как-то найти простой, дешевый и народный контроллер заряда вроде TP4056 только помощнее и на 2S / 3S, перерыл весь Ali и... как-то ничего подходящего не нашел. Одни BMS. Я чего-то не понимаю?
Для заряда более ёмких батарей используют обычные импульсные преобразователи напряжения. Главное, чтобы они штатно умели работать в режиме более-менее точного ограничения тока. Или добавляют дополнительную обратную связь по току к "неумеющему" DCDC.
Например, зарядное устройство для самоката, пылесоса и прочей мощной техники - это обычный обратноходовый трансформаторный ACDC. Не все ACDC могут работать в режиме стабилизации тока, но очень многие. Ну и выходное напряжение в режиме CV, наверное, чуть точнее выставлено.
Или вот недавно юзал микросхему SCM1316 в качестве DCDC на 5А 5..24V. У неё по описанию есть режимы и CV, и CC.
А можно поконкретнее, из-за чего глаз дёрнулся, и почему электролиты такие мерзкие?
У меня "глаз дёргается" при виде любого ОУ общего назначения в цепи, где предполагается динамический микрофон на входе. Либо ultra low noise opamp, либо каскад на малошумящих BJT, JFET. Иначе получается та же китайщина, что вот тут.
Встречался со схемами с реально богомерзкой керамикой X7R/X5R большой ёмкости в аудио цепях. Действительно, на слух искажения адские, т.к. ёмкость жутко нелинейна. Но электролиты алюминиевые, танталовые, и керамика при определённых условиях - вполне ничего себе. Ну, для алюминия запас ёмкости на высыхание лучше добавить.
Ясен перец, плёночные лучше. Но их тоже везде пихать не стоит, если они улучшат КНИ с 0,0010% до 0,0011%.
я удивляюсь, как их до сих пор на WiFi или BT какой-нибудь не перевели, чтобы уж совсем без разъемов
Музыкантам нужны интерфейсы с низкой задержкой. Только хардкор, только жесточайший реалтайм.
Радио-связью, конечно пользуются. На большинстве сцен уже давно никто провода от микрофонов не тянет. Но это работает не в ISM-диапазонах, которые забиты всяким г. И работает не через стандартные цифровые протоколы связи из-за задержек. Поэтому и ценник на такие устройства - $500-$2000 за один канал. То, что дешевле - ну может для пьяных посиделок в караоке-баре и подойдёт.
куча готовых микшеров за пару тысяч рублей
Да, для каких-то задач они подходят. Инструментальный вход, или микрофон с фантомным питанием более-менее работают. А вот для динамического микрофона вход слишком шумный. И есть нюансы с качеством разъёмов, с защитой от внешних помех (тех же радио-каналов, особенно GSM), и куча других
Но, как говорил знаменитый В.И., есть один нюанс. Си уже пол-сотни лет в обед, и ни про какой ООП ни тогда, ни сейчас речи не было. Для этого сделан обратно совместимый ++. Но в питоне-то в принципе всё есть объект. Поэтому неизменный self там выглядит странно.
Вероятно, у разработчиков питона всё-таки была какая-то причина так сделать. Пришлось идти на компромисс. Хотели с одной стороны обеспечить полный волюнтаризьм в динамическом добавлении свойств и методов, как в транслируемых языках. С другой стороны питон весьма шустрый в скомпилированном виде, пускай и в байт-коде. По скорости выполнения классика типа JavaScript и TCL даже рядом не стоят.
Тогда DCDC не включится. Для первоначального запуска ему нужно напряжение на входе EN выше, чем GND схемы. Как минимум на пороговые 1,2V + падение на VD5.
Делитель R18+R22 с трудом это обеспечивает. Но лучше всё-таки замкнуть или уменьшить R18.
Включаем и на выходе появляется напряжение +8.6 В, вместо +15 В.
Получается, отключение питания Vsmps не до конца работает. R19 лишний - он приоткрывает VT2.
Ещё вижу проблему в том, что выходы HC4094 могут находиться в неопределённом состоянии, пока контроллер не прошит, или ещё не загрузился. Ей бы на ногу OE подать сигнал разрешения, когда всё запустится. Тогда она станет полноценным расширителем портов.
Преобразователь в -15V вполне себе отключается цепью CTRL-15B. Нет смысла нагружать VT2 лишним током. А на +15V всё равно при включении Vsmps уже появятся 4..5V, поэтому нет смысла его отключать с помощью CTRL+15B.
Почитал доки на экраны - удивился адской потребляемой мощности. И заметил, что у них ограничен допустимый стартовый ток. А это 99% значит, что нужен софт-старт преобразователей. Возможно даже сильно софт-.
встроенным загрузчиком. Через USB, или другие интерфейсы, которые используется для связи с внешним миром. Не, все, правда. Жаль, что через голый RS485 это не работает, например.
иметь часть прошивки - загрузчик, всегда защищённую от записи. В самом STLink так сделано, например. А если стоит защита от чтения, у большинства стм защита записи первых килобайт флеши автоматом ставится.
на время обновления защиту можно и снять. Но если нет запасных загрузочных интерфейсов, есть опасность "окирпичить" плату где-то далеко у заказчика.
отладить прошивку так, чтобы не надо было обновлять. Для серийных устройств этот вариант лучше, чем потом ездить и "кирпичи" собирать.
Я сам делаю последовательную запись, чтобы не стирать каждый раз. Обязательно использую 2 страницы, чтобы в случае чего при стирании не остаться вообще без данных. Все записи нумеруются, чтобы потом найти последнюю. Контрольная сумма - тоже обязательно. Проверку флагов ошибок после записи и стирания - тоже делаю.
Второй момент: не понял, зачем запрещать прерывания. Во время записи или стирания стм не может читать флешу, соответственно, не может выполнять оттуда код. Поскольку стирание - процесс не быстрый, даже приходится реалтаймовые обработчики прерываний выносить в ОЗУ.
3-й момент: для страниц с кодом обязательно нужно включать защиту от записи. На нескольких чипах встречал порчу кода, когда где-то в прошивке используется запись во флешу. Может, конечно, это и от общей криворукости происходит, но защита не повредит.
Сам по себе может быть питон и не плох. Он другой, не для промозглых железячников. Во всякие краткие записи, которые по факту разворачиваются в циклы, я только-только въезжаю. Каким-то умным словом это называется) а ещё и глубже есть
По началу в питоне подкупало то, что много библиотек есть. Я для своих железяк быстро пишу ответный софт для тестов - хватает. Но глючит это всё - отпад, отвал башки, иопанный сферический конь... Но в прод, слава хабру, я вывожу мою вылизанную прошивку мк. И не важно, каким г-ном я измазался, пока тестировал.
Первое, что приходит в голову, когда слышишь эту трёхбуквенную аббревиатуру
Не у всех) Возможно, кто-то даже вспомнит/найдёт весь этот стих
Эх, достать-бы где РПГ, Да принять для куражу ЛСД... Я разнес бы все к таким ЕБН, Что позавидует сама ООП.
И вроде трёхбуквенных аббревиатур всего-то 33³, но совпадения встречаются часто) У меня когда-то была подруга по имени Ира. Характер чётко совпадал с IRA)
Ну это я так, для разрядки холивара между поклонниками разных ЯП
Да, ещё с SocketCAN помогает
Но это тоже с sudo. Пользователю быстрее USB переткнуть)
По Рис. 8 кажется, что ток через внутренние витки значительно больше, чем через внешние. Ток через выводы катушки разный? В чём подвох?
Наверное, говорят проще - "магнитная индукция", или сложнее "плотность потока индукции"
Пользовался платами с али, про которые в комментах тут писали. Интерфейсы CANable, SocketCAN, CANtact, UART-CAN - всё открытые прошивки. С гальваноразвязкой тоже есть. В линуксе работают из коробки. can-utils и python-can заводил.
Но был нюанс: не удавалось сбросить буфер передачи. Когда пакет никто в сети не подтверждает, некоторые прошивки успокаиваются через 2-5 секунд. А некоторые прошивки уходят в бесконечный повтор, и только отключение от USB помогает.
Плата SYS TEC USB-CANmodul1 нормально отрабатывает отвал от кан-шины? А другие? Может, у кого есть опыт?
У опытных товарищей особого снобизма не наблюдаю. Понятно, что транслируемые, компилируемые и байт-кодные языки - каждый для своих задач удобен.
Я сам недолюбливаю javascript по другой причине. Не сам язык, а его использование. Потому что де-факто это стандарт для "фронтовиков", ну и для браузеров. При этом он способен превратить кБ веб-страницы в ГБ ОЗУ. И опустит производительность проца с ГГц до кГц.
И приходится часто обновлять вполне годное железо, особенно мобильное. Патамущта сайты разбухли. Даже в самую простецкую веб-страницу, включая зависимости, наваливается МБ говнокода. Который жрёт ГБ памяти при выполнении. А информации по факту там на кБ от силы.
ActionScript, который Flash-анимация, когда-то пытался ужать этот объём, но не сраслось. Стандартизация - это хорошо, но не за счёт таких ресурсов.
Извини, наболело)
Хром поиском по странице выдаёт "self" 649 штук. С точкой "self." и с запятой "self," чуть поменьше, но их тоже больше 600 штук.
Для замшелого Сишника странность в том, что у питона область видимости переменной нужно задавать явно. Для глобальных переменных - один раз на функцию. А для свойств текущего объекта - каждый раз при упоминании этого свойства. Поэтому код становится похож на ООП, написанный на
ассемблереСи без плюсов - нужно всегда явно указывать тот самый this/self.Потери зависят от разности напряжений ячеек. Если разность 4%, то и потери порядка 4%. Мы же не разряжаем конденсаторы до 0 V.
А раз балансир стремится выровнять напряжения, процент потерь на Rdson стремится к 0.
Точно также многокаскадные схемы накачки заряда, или умножения напряжения работают: если не позволять выходному напряжению сильно проседать, то кпд не самый плохой выходит.
Пример ёмкостного балансира в этой статье примерно так и делает. По 4 ключа на ячейку стоит. По 1 двухканальному драйверу затвора. И общий генератор.
Пол-такта каждая ячейка заряжает свой кондёр. Пол-такта эти все кондёры соединяются вместе.
Схему я не нашёл, по фотографиям удалось восстанавить.
Если к этому добавить мк, то вполне можно за каждой ячейкой следить, и в сон автоматом уходить.
Ёмкостный с частотой переключения 1 МГц будет содержать такие же конденсаторы, тех же размеров, что на плате с ETA3000. Только дросселя не будет.
При большом разбалансе, конечно, ёмкостный будет жрать энергию
[разность напряжений] x [ток баланса].
Эти решения для разных целей используются. ETA3000 хорошо балансирует 2 соседние ячейки, но не справится с батарей длиннее, чем 4-5S. Зато простая, монолитная, и, соответственно, мало жрёт.
Ёмкостное решение сделано на дискретных элементах и отдельных драйверах затворов, поэтому жрёт довольно много. Зато умеет перекачивать энергию из любой ячейки в любую, пока они все точно не сравняются. Для большой батареи 8-12S с 10 кг лития за $100500 это решение я считаю лучше.
Индуктивный балансир, умеющий перекачивать из любой банки в любую, наверное, тоже можно сделать. И он будет более эффективным. Но по схемотехнике будет ещё сложнее.
Для заряда более ёмких батарей используют обычные импульсные преобразователи напряжения. Главное, чтобы они штатно умели работать в режиме более-менее точного ограничения тока. Или добавляют дополнительную обратную связь по току к "неумеющему" DCDC.
Например, зарядное устройство для самоката, пылесоса и прочей мощной техники - это обычный обратноходовый трансформаторный ACDC. Не все ACDC могут работать в режиме стабилизации тока, но очень многие. Ну и выходное напряжение в режиме CV, наверное, чуть точнее выставлено.
Или вот недавно юзал микросхему SCM1316 в качестве DCDC на 5А 5..24V. У неё по описанию есть режимы и CV, и CC.
А можно поконкретнее, из-за чего глаз дёрнулся, и почему электролиты такие мерзкие?
У меня "глаз дёргается" при виде любого ОУ общего назначения в цепи, где предполагается динамический микрофон на входе. Либо ultra low noise opamp, либо каскад на малошумящих BJT, JFET. Иначе получается та же китайщина, что вот тут.
Встречался со схемами с реально богомерзкой керамикой X7R/X5R большой ёмкости в аудио цепях. Действительно, на слух искажения адские, т.к. ёмкость жутко нелинейна. Но электролиты алюминиевые, танталовые, и керамика при определённых условиях - вполне ничего себе. Ну, для алюминия запас ёмкости на высыхание лучше добавить.
Ясен перец, плёночные лучше. Но их тоже везде пихать не стоит, если они улучшат КНИ с 0,0010% до 0,0011%.
Музыкантам нужны интерфейсы с низкой задержкой. Только хардкор, только жесточайший реалтайм.
Радио-связью, конечно пользуются. На большинстве сцен уже давно никто провода от микрофонов не тянет. Но это работает не в ISM-диапазонах, которые забиты всяким г. И работает не через стандартные цифровые протоколы связи из-за задержек. Поэтому и ценник на такие устройства - $500-$2000 за один канал. То, что дешевле - ну может для пьяных посиделок в караоке-баре и подойдёт.
Да, для каких-то задач они подходят. Инструментальный вход, или микрофон с фантомным питанием более-менее работают. А вот для динамического микрофона вход слишком шумный. И есть нюансы с качеством разъёмов, с защитой от внешних помех (тех же радио-каналов, особенно GSM), и куча других
В 13.3 такое было:
Но я не понял, это ограничение стартового тока DCDC-преобразователей, или панель реально этот ток ест на старте.
Да, я про любой С-подобный синтаксис.
Но, как говорил знаменитый В.И., есть один нюанс. Си уже пол-сотни лет в обед, и ни про какой ООП ни тогда, ни сейчас речи не было. Для этого сделан обратно совместимый ++. Но в питоне-то в принципе всё есть объект. Поэтому неизменный self там выглядит странно.
Вероятно, у разработчиков питона всё-таки была какая-то причина так сделать. Пришлось идти на компромисс. Хотели с одной стороны обеспечить полный волюнтаризьм в динамическом добавлении свойств и методов, как в транслируемых языках. С другой стороны питон весьма шустрый в скомпилированном виде, пускай и в байт-коде. По скорости выполнения классика типа JavaScript и TCL даже рядом не стоят.
Да любой. Вот из одной стандартной библиотеки:
https://github.com/python/cpython/blob/main/Lib/zipfile/__init__.py
2330 строк.
Слов "return" - 116. Слов "def" - 123. Примерно столько функций, но часть не ООПэшная.
А слов "self" - 649.
И эти люди мне
запрещают ковыряться в носув пример ставят ";" ...Тогда DCDC не включится. Для первоначального запуска ему нужно напряжение на входе EN выше, чем GND схемы. Как минимум на пороговые 1,2V + падение на VD5.
Делитель R18+R22 с трудом это обеспечивает. Но лучше всё-таки замкнуть или уменьшить R18.
Бюджетно и со вкусом!
Получается, отключение питания Vsmps не до конца работает. R19 лишний - он приоткрывает VT2.
Ещё вижу проблему в том, что выходы HC4094 могут находиться в неопределённом состоянии, пока контроллер не прошит, или ещё не загрузился. Ей бы на ногу OE подать сигнал разрешения, когда всё запустится. Тогда она станет полноценным расширителем портов.
Преобразователь в -15V вполне себе отключается цепью CTRL-15B. Нет смысла нагружать VT2 лишним током. А на +15V всё равно при включении Vsmps уже появятся 4..5V, поэтому нет смысла его отключать с помощью CTRL+15B.
Почитал доки на экраны - удивился адской потребляемой мощности. И заметил, что у них ограничен допустимый стартовый ток. А это 99% значит, что нужен софт-старт преобразователей. Возможно даже сильно софт-.
Есть несколько вариантов:
встроенным загрузчиком. Через USB, или другие интерфейсы, которые используется для связи с внешним миром. Не, все, правда. Жаль, что через голый RS485 это не работает, например.
иметь часть прошивки - загрузчик, всегда защищённую от записи. В самом STLink так сделано, например. А если стоит защита от чтения, у большинства стм защита записи первых килобайт флеши автоматом ставится.
на время обновления защиту можно и снять. Но если нет запасных загрузочных интерфейсов, есть опасность "окирпичить" плату где-то далеко у заказчика.
отладить прошивку так, чтобы не надо было обновлять. Для серийных устройств этот вариант лучше, чем потом ездить и "кирпичи" собирать.
Недавно 2-й вариант осилил для CAN-шины.
Я сам делаю последовательную запись, чтобы не стирать каждый раз. Обязательно использую 2 страницы, чтобы в случае чего при стирании не остаться вообще без данных. Все записи нумеруются, чтобы потом найти последнюю. Контрольная сумма - тоже обязательно. Проверку флагов ошибок после записи и стирания - тоже делаю.
Второй момент: не понял, зачем запрещать прерывания. Во время записи или стирания стм не может читать флешу, соответственно, не может выполнять оттуда код. Поскольку стирание - процесс не быстрый, даже приходится реалтаймовые обработчики прерываний выносить в ОЗУ.
3-й момент: для страниц с кодом обязательно нужно включать защиту от записи. На нескольких чипах встречал порчу кода, когда где-то в прошивке используется запись во флешу. Может, конечно, это и от общей криворукости происходит, но защита не повредит.
Сам по себе может быть питон и не плох. Он другой, не для промозглых железячников. Во всякие краткие записи, которые по факту разворачиваются в циклы, я только-только въезжаю. Каким-то умным словом это называется) а ещё и глубже есть
По началу в питоне подкупало то, что много библиотек есть. Я для своих железяк быстро пишу ответный софт для тестов - хватает. Но глючит это всё - отпад, отвал башки, иопанный сферический конь... Но в прод, слава хабру, я вывожу мою вылизанную прошивку мк. И не важно, каким г-ном я измазался, пока тестировал.
Не у всех) Возможно, кто-то даже вспомнит/найдёт весь этот стих
И вроде трёхбуквенных аббревиатур всего-то 33³, но совпадения встречаются часто) У меня когда-то была подруга по имени Ира. Характер чётко совпадал с IRA)
Ну это я так, для разрядки холивара между поклонниками разных ЯП