Если надумаете освоить stm32, есть готовый проект https://github.com/candle-usb/candleLight_fw Там вроде и по железу готовые есть проекты, но я себе свой собрал, с изолированным каном. Удобство этого в том, что в ядре линукса есть поддержка этого драйвера (gs_usb). Просто подключаете к ноуту, компьютеру, малине или чему удобно по usb, ifconfig и готово. Для простых задач есть cantools, а если его не хватает Savvycan. Ну и бонусом там всякие вещи, типа записи лога и последующего проигрывания его в виртуальный кан.
Если вам удобнее использовать esp32-c3, возможно есть готовая реализация gs_usb для этой платформы.
Не знаю как лучше и правильно, поскольку других ответов нет, поделюсь как я делал: у меня сборка на отдельном удаленном "сервере". Когда я хотел попробовать изменения, просто коммитил в git. В yocto код приложения забирался с git-а и собирался. Т.е. локально тулчейн я не использовал. Код на С, поэтому просто проверить, что оно собирается без ошибок я могу при помощи того же gcc под x86.
Насколько помню, в yocto приложения собираются в пакеты. Там, если не путаю, по-умолчанию rpm, но можно и deb использовать или opkg. В моем случае, целевая система была сильно минималистичная и приложение не сложное. Я просто по ssh забирал бинарник приложения из каталога сборки yocta на целевую систему.
Так используйте меньше потоков. Условно, если у вас каждый поток сборки использует 1гб памяти, а собираете вы в 20 потоков, то 20Гб оно и съест :) Система сборки первый раз собирает и тулчейн и ядро и все что там у вас есть. Последующие сборки будут собирать только то, что изменилось.
Вы же можете создать отдельную группу только для 1 пользователя. Такой вариант позволяет выдать только нужные привелегии. В данном случае, на запись в устройство. В случае со скриптом, у вас через sudo выполняется всё, что там написано.
Был почти уверен, что в ядре должен быть готовый драйвер для управления сервой. Как ни странно, готового драйвера нет. Я нашел пример https://github.com/maciejjo/pwm-servo но судя по его давности (7 лет), в mainline его не приняли.
Если надо управлять сервой, мне кажется вполне нормально написать свой драйвер. Параметры pwm ему через dts указывать, а в условное устройство "/dev/servo0" писать просто нужный угол. Странно, что готового нет.
Не совсем понял, зачем вы пользователя и sudo заводите. Только из-за того, что права на pwmchip0 надо? Это обычно не так решают. Через udev делаете правило, чтоб на pwmchip* (или конкретно pwmchip0 ) назначалась группа "pwmgroup" и устанавливались права разрешающие группе писать. А нужного пользователя просто в эту группу добавляете. И не нужно sudo. Для простых задача не нужен даже питон, можно через sysfs писать прямо из шелла.
Я с dropbox использовал encfs. В папке dropbox находится контейнер, а когда нужны данные, он монтируется куда-то вне этой папки. Было очень удобно, что под андроид было приложение, которое умело работать с контейнерами encfs из dropbox. Но, к сожалению, приложение это забросили, а dropbox сменил api видимо и перестало работать.
Я думаю вы и описанный выше truecrypt можете так же использовать - зашифрованный контейнер в папке я.диска, а монтируете вы его куда-то вне этой папки.
Под OBD протоколом я подразумевал стандартный протокол по CAN который есть во всех современных автомобилях. Вот тут подробности https://en.wikipedia.org/wiki/OBD-II_PIDs Работает это по схеме "запрос-ответ". Мой форд отвечает с некоторой задержкой и частота в результате получается около 10Гц. В каждом запросе только один параметр, в итоге чем больше параметров тем ниже частота. У меня вроде было около 10Гц при запросе 3 параметров (обороты, дроссель, температура). Если вопрос принципиальный, могу проверить. Но ограничено там всё именно блоком управления, он с задержкой отвечает.
Если нужно получать быстрее, надо смотреть на сообщения на шине конкретного производителя. У того же форда на шине около 2000 сообщений в секунду летит. Но никакого доступного описания нет, надо самостоятельно искать ID и разбирать пакеты.
То, что вы подразумеваете под OBD без CAN-шины, это скорее всего как раз обмен по K-Line. Я экспериментировал с этим на мотоцикле (honda cb-600). Структура обмена там достаточно типовая, похожа на KWP2000. Работает тоже по схеме "запрос-ответ" и есть установленные протоколом задержки между посылками. В итоге частота тоже была небольшая, до 10Гц суммарно. Только описания что где лежит нормального нет и пришлось лог. анализатором смотреть обмен и вычислять параметры.
OBD это же OnBoard Diagnostic, оно для других целей, поэтому и больших скоростей обмена там нет.
У того же Абита, например, протокол по CAN построен иначе. Это блок специально для спорта и ничего запрашивать там не нужно. Блок сам шлет все параметры с заданной частотой. Те же обороты, например, идут с частотой 100Гц.
>Modbus-устройства Wiren Board работают в диапазоне напряжений от 9 до 28 В, а пиковая потребляемая мощность — 4 Вт. Поэтому в требованиях прописали выход 12.5 В с током до 400 мА.
А USB порт компьютера способен столько питания отдать? 12.5в на 0.4А это 5вт. Без учета потерь в dc/dc это 1А по 5В линии. Стандарт, насколько помню, 0.5А
Не очень понял анимацию с расставлением кнопок во fusion. В каком cad разводили плату? Там нет экспорта в 3д? Я кикадом пользуюсь и 3д модели добавляю сразу туда. Если планируется корпус, то всё, что торчит на плате должно быть с 3д моделью. Потом просто экспорт в step готовой платы со всеми разъемами и компонентами.
По поводу модема торчащего - я использовал quectel ep-06. Он под разъем pci-e, но там только usb используется. Мне было немного лень разводить его питание + симкарту, поэтому я его использовал вместе с платой-адаптером в usb.
К нему при этом, можно еще и удаленно по tcp подключаться :) Т.е. к целевому МК подключается условная "малина" по swd, а к ней по сети с рабочего места. И отладка, как будто МК подключен напрямую (ну по медленнее конечно).
VSCode как редактор удобный. Отладчик там, который плагином, мне не понравился.
Я использую jlink для подключения по swd, а для отладки Ozone. Запускается прямо из vscode. Отличный отладчик, очень удобно. Ну и все остальные преимущества jlink - RTT, SystemView, при необходимости прошивка флешек по spi и прочее. Вместо openocd использую или прошивку из Ozone или при помощи драйвера jlink (их утилита консольная умеет работать в "пакетном режиме", с параметрами из командной строки).
У такого подхода, когда вместо комбайна IDE используется связка из нескольких инструментов, есть свой большой плюс - любой инструмент можно заменить. Не нравится vscode? Можно хоть vi использовать. Нужна другая версия компилятора? Без проблем. Для многих платформ есть toolchain со сборкой через makefile. Соответственно для того, чтобы попрограммировать под esp32, nfr52, avr или что-то ещё, не нужно менять удобную и привычную среду написания кода.
То же иногда смотрю в сторону сделать свою плату но пугает ddr и замороченная схема питания. И отсутствие самих МК и документации от производителя. У STM с документацией обычно хорошо и схемы их плат есть, но stm32mp1 в более-менее свободной продаже (lcsc и т.д.) не встречал.
У китайцев бывают миниатюрные модули МК+ddr+питальник. Видел и с allwiner-рами и с stm32, под запайку в свою плату. Но ценник какой-то неадекватный. Видимо не очень популярное решение.
У allwiner-а (и вроде ещё у кого-то) встречал вообще в выводном корпусе. У кого-то видел даже МК с ram внутри корпуса. 64Мб, но мне бы скорее всего хватило. Только datasheet на десяток страниц, никакого hardware integrating manual и не купить.
Не сразу понял, что вы делаете таймером. Его же можно в режиме захвата настроить и сразу получать длительность импульса. Не уверен, но вполне возможно его можно настроить на прерывание по заданной длине импульса. А МК отправить в сон.
Для таких поделок есть stm32g030j6 Он в soic-8, как ne555. Под него просто разводить плату под лут. А если ещё взять реле поменьше, то вся конструкция получится размером с одно ваше реле :)
Не проще взять внешний АЦП и использовать его вместо ардуины? В ядре есть поддержка разных АЦП, можно выбрать что-то простое. Вся работа с АЦП будет сведена к чтению из "файла" значений. Ну можно и на питоне конечно, если у вас много батарей :)
Можно АЦП с функцией оповещения о изменении уровня и просто по прерыванию с gpio реагировать. На вскидку не подскажу конкретной модели, но не думаю, что это редкость. Кстати, возможно в ядре есть уже готовый драйвер, который за значением АЦП следит.
Если вас интересует только превышение конкретного уровня напряжения (выше-ниже), а не его значение, можно и без АЦП вообще обойтись, решив задачу вообще пассивными элементами. Просто получая на gpio 1 или 0.
Если надумаете освоить stm32, есть готовый проект https://github.com/candle-usb/candleLight_fw Там вроде и по железу готовые есть проекты, но я себе свой собрал, с изолированным каном. Удобство этого в том, что в ядре линукса есть поддержка этого драйвера (gs_usb). Просто подключаете к ноуту, компьютеру, малине или чему удобно по usb, ifconfig и готово. Для простых задач есть cantools, а если его не хватает Savvycan. Ну и бонусом там всякие вещи, типа записи лога и последующего проигрывания его в виртуальный кан.
Если вам удобнее использовать esp32-c3, возможно есть готовая реализация gs_usb для этой платформы.
А зачем вы читаете структуру циклом по 4 байта?
my_struct = *struct_in_flash_ptr;
Структура должна бы выровнена на 4. Но без выравнивания и ваш вариант не сработает скорее всего.
И самое интересное в этой задаче, это не сама по себе запись и чтение, это в RM описано, а именно алгоритм выравнивания износа.
Не знаю как лучше и правильно, поскольку других ответов нет, поделюсь как я делал: у меня сборка на отдельном удаленном "сервере". Когда я хотел попробовать изменения, просто коммитил в git. В yocto код приложения забирался с git-а и собирался. Т.е. локально тулчейн я не использовал. Код на С, поэтому просто проверить, что оно собирается без ошибок я могу при помощи того же gcc под x86.
Насколько помню, в yocto приложения собираются в пакеты. Там, если не путаю, по-умолчанию rpm, но можно и deb использовать или opkg. В моем случае, целевая система была сильно минималистичная и приложение не сложное. Я просто по ssh забирал бинарник приложения из каталога сборки yocta на целевую систему.
Так используйте меньше потоков. Условно, если у вас каждый поток сборки использует 1гб памяти, а собираете вы в 20 потоков, то 20Гб оно и съест :) Система сборки первый раз собирает и тулчейн и ядро и все что там у вас есть. Последующие сборки будут собирать только то, что изменилось.
Про yocto есть неплохая и чуть более подробная серия видео от digi key
https://youtu.be/9vsu67uMcko?si=tFOh0GRz6Wb_3VBb
Там вроде первые пару видео про buildroot, а дальше несколько видео по yocto.
А зачем нужен "Etcher для linux", если есть чудесный dd?
Вы же можете создать отдельную группу только для 1 пользователя. Такой вариант позволяет выдать только нужные привелегии. В данном случае, на запись в устройство. В случае со скриптом, у вас через sudo выполняется всё, что там написано.
Я не настаиваю, если что :)
Был почти уверен, что в ядре должен быть готовый драйвер для управления сервой. Как ни странно, готового драйвера нет. Я нашел пример https://github.com/maciejjo/pwm-servo но судя по его давности (7 лет), в mainline его не приняли.
Если надо управлять сервой, мне кажется вполне нормально написать свой драйвер. Параметры pwm ему через dts указывать, а в условное устройство "/dev/servo0" писать просто нужный угол. Странно, что готового нет.
Не совсем понял, зачем вы пользователя и sudo заводите. Только из-за того, что права на pwmchip0 надо? Это обычно не так решают. Через udev делаете правило, чтоб на pwmchip* (или конкретно pwmchip0 ) назначалась группа "pwmgroup" и устанавливались права разрешающие группе писать. А нужного пользователя просто в эту группу добавляете. И не нужно sudo. Для простых задача не нужен даже питон, можно через sysfs писать прямо из шелла.
Я с dropbox использовал encfs. В папке dropbox находится контейнер, а когда нужны данные, он монтируется куда-то вне этой папки. Было очень удобно, что под андроид было приложение, которое умело работать с контейнерами encfs из dropbox. Но, к сожалению, приложение это забросили, а dropbox сменил api видимо и перестало работать.
Я думаю вы и описанный выше truecrypt можете так же использовать - зашифрованный контейнер в папке я.диска, а монтируете вы его куда-то вне этой папки.
На 2:20 на переключении газ не отпускали, или это пропуск получения данных?
Под OBD протоколом я подразумевал стандартный протокол по CAN который есть во всех современных автомобилях. Вот тут подробности https://en.wikipedia.org/wiki/OBD-II_PIDs Работает это по схеме "запрос-ответ". Мой форд отвечает с некоторой задержкой и частота в результате получается около 10Гц. В каждом запросе только один параметр, в итоге чем больше параметров тем ниже частота. У меня вроде было около 10Гц при запросе 3 параметров (обороты, дроссель, температура). Если вопрос принципиальный, могу проверить. Но ограничено там всё именно блоком управления, он с задержкой отвечает.
Если нужно получать быстрее, надо смотреть на сообщения на шине конкретного производителя. У того же форда на шине около 2000 сообщений в секунду летит. Но никакого доступного описания нет, надо самостоятельно искать ID и разбирать пакеты.
То, что вы подразумеваете под OBD без CAN-шины, это скорее всего как раз обмен по K-Line. Я экспериментировал с этим на мотоцикле (honda cb-600). Структура обмена там достаточно типовая, похожа на KWP2000. Работает тоже по схеме "запрос-ответ" и есть установленные протоколом задержки между посылками. В итоге частота тоже была небольшая, до 10Гц суммарно. Только описания что где лежит нормального нет и пришлось лог. анализатором смотреть обмен и вычислять параметры.
OBD это же OnBoard Diagnostic, оно для других целей, поэтому и больших скоростей обмена там нет.
У того же Абита, например, протокол по CAN построен иначе. Это блок специально для спорта и ничего запрашивать там не нужно. Блок сам шлет все параметры с заданной частотой. Те же обороты, например, идут с частотой 100Гц.
>Modbus-устройства Wiren Board работают в диапазоне напряжений от 9 до 28 В, а пиковая потребляемая мощность — 4 Вт. Поэтому в требованиях прописали выход 12.5 В с током до 400 мА.
А USB порт компьютера способен столько питания отдать? 12.5в на 0.4А это 5вт. Без учета потерь в dc/dc это 1А по 5В линии. Стандарт, насколько помню, 0.5А
Не очень понял анимацию с расставлением кнопок во fusion. В каком cad разводили плату? Там нет экспорта в 3д? Я кикадом пользуюсь и 3д модели добавляю сразу туда. Если планируется корпус, то всё, что торчит на плате должно быть с 3д моделью. Потом просто экспорт в step готовой платы со всеми разъемами и компонентами.
По поводу модема торчащего - я использовал quectel ep-06. Он под разъем pci-e, но там только usb используется. Мне было немного лень разводить его питание + симкарту, поэтому я его использовал вместе с платой-адаптером в usb.
К нему при этом, можно еще и удаленно по tcp подключаться :) Т.е. к целевому МК подключается условная "малина" по swd, а к ней по сети с рабочего места. И отладка, как будто МК подключен напрямую (ну по медленнее конечно).
VSCode как редактор удобный. Отладчик там, который плагином, мне не понравился.
Я использую jlink для подключения по swd, а для отладки Ozone. Запускается прямо из vscode. Отличный отладчик, очень удобно. Ну и все остальные преимущества jlink - RTT, SystemView, при необходимости прошивка флешек по spi и прочее. Вместо openocd использую или прошивку из Ozone или при помощи драйвера jlink (их утилита консольная умеет работать в "пакетном режиме", с параметрами из командной строки).
У такого подхода, когда вместо комбайна IDE используется связка из нескольких инструментов, есть свой большой плюс - любой инструмент можно заменить. Не нравится vscode? Можно хоть vi использовать. Нужна другая версия компилятора? Без проблем. Для многих платформ есть toolchain со сборкой через makefile. Соответственно для того, чтобы попрограммировать под esp32, nfr52, avr или что-то ещё, не нужно менять удобную и привычную среду написания кода.
Спасибо, за статью и за ссылку на статью :)
То же иногда смотрю в сторону сделать свою плату но пугает ddr и замороченная схема питания. И отсутствие самих МК и документации от производителя. У STM с документацией обычно хорошо и схемы их плат есть, но stm32mp1 в более-менее свободной продаже (lcsc и т.д.) не встречал.
У китайцев бывают миниатюрные модули МК+ddr+питальник. Видел и с allwiner-рами и с stm32, под запайку в свою плату. Но ценник какой-то неадекватный. Видимо не очень популярное решение.
У allwiner-а (и вроде ещё у кого-то) встречал вообще в выводном корпусе. У кого-то видел даже МК с ram внутри корпуса. 64Мб, но мне бы скорее всего хватило. Только datasheet на десяток страниц, никакого hardware integrating manual и не купить.
Не сразу понял, что вы делаете таймером. Его же можно в режиме захвата настроить и сразу получать длительность импульса. Не уверен, но вполне возможно его можно настроить на прерывание по заданной длине импульса. А МК отправить в сон.
Для таких поделок есть stm32g030j6 Он в soic-8, как ne555. Под него просто разводить плату под лут. А если ещё взять реле поменьше, то вся конструкция получится размером с одно ваше реле :)
Вероятно подойдет вам ADS1115. Есть на али готовые платы, есть выход с компаратора, есть драйвер в ядре.
Не проще взять внешний АЦП и использовать его вместо ардуины? В ядре есть поддержка разных АЦП, можно выбрать что-то простое. Вся работа с АЦП будет сведена к чтению из "файла" значений. Ну можно и на питоне конечно, если у вас много батарей :)
Можно АЦП с функцией оповещения о изменении уровня и просто по прерыванию с gpio реагировать. На вскидку не подскажу конкретной модели, но не думаю, что это редкость. Кстати, возможно в ядре есть уже готовый драйвер, который за значением АЦП следит.
Если вас интересует только превышение конкретного уровня напряжения (выше-ниже), а не его значение, можно и без АЦП вообще обойтись, решив задачу вообще пассивными элементами. Просто получая на gpio 1 или 0.
У вас в описании указан драйвер led Holtek ht1632c. На плате его не видно, зато видно кучку элементов похожих на транзисторы. Отказались от него?
Вообще, если бы показали принципиальную схему устройства, возможно это сняло бы столько вопросов про 6 слоев.