Сложнее. Там на стороне ардуины предполагается поднимать USB Host. Возможно, для одного отдельно взятого телефона это получится сделать, но универсальный хост, который будет работать со всем зоопарком устройств — задача нетривиальная.
И да, это при условии, что гугл не грохнул этот «Open Accessory» — в массы оно явно не пошло…
враппер над «тредами», «семафорами», «мьютексами» и тп. если это уже было сделано в boost а также в стандартной библиотеке начиная с C++11
Очевидно, треды и средства их синхронизации должны взаимодействовать с ядром ОС. Т.е. надо писать порт STL на конкретную операционку. Пока, к сожалению, таких супергероев не видно…
С привидениями нет проблем
Да нету никаких проблем с приведениями типов. Если никогда не ошибаться. А если в макрос, внутри которого cast на cast'е, передать что-то не то, компилятор это тихо сожрёт без каких-то варнингов.
Как жить без std::string и std::vector?
Продумать и описать протоколы, по которым идёт взаимодействие с внешним миром, статически выделить необходимые буферы (хоть сишные, хоть std::array), и жить…
Посмотрите в сторону использования библиотеки boost
В описываемом случае (контроллер относительно мелкий, malloc по каким-то соображениям не используется) лучше смотреть куда-то в район etlcpp.com. Бустом, правда, я никогда не пользовался — посмотрел, испугался, и закрыл.
Для Cortex M4 «все» операционки используют 3 прерывания, прерывания System tick timer, System Service call via SWI instruction, Pendable request for system service, которые собственно в основном для ОСРВ и были придуманы.
Для работы используются два — для переключения задач (обычно — PendSV_Handler) и для системного таймера (и тот только в обычном, не tickless, режиме).
SWI + SVC_Handler — это такой фриртосный костылик для запуска самой первой задачи.
«Работать в команде» и «разные архитектуры» — это не про то. Командно переносить проект между архитектурами можно вместе с операционкой.
Тут про «переносить код на разные ос». И сейчас оно больше напоминает картинку «есть 14 конкурирующих стандартов»…
Их обилие связано, в первую очередь, с тем, что фриртос запускается на очень большом зоопарке архитектур и на ооооочень большом зоопарке (музее?) компиляторов.
И там не пахнет не то чтоб плюсами, там банальных инлайн-функций вместо всех этих макросов нету…
Авторов FreeRTOS с таким подходом понять можно. Простить — сложнее :-)
В общем, моё мнение — эту обёртку можно использовать в каких-то особо странных случаях («мне нужно только freertos, потому что у неё сертификат, но самой freertos я видеть не хочу»). Иначе, если не хочется видеть фриртос — ей можно просто не пользоваться, благо альтернативы есть…
Занятно, что список требований к ОС («никаких макросов», «никаких приведений типов») сильно совпадает с моими личными претензиями к FreeRTOS.
И все эти наслоения макросов из кишков фриртос никуда не деваются. И если использование операционки с этой прослойкой, действительно, должно упроститься, при отладке, если туда понадобится-таки лезть, мы опять упрёмся в void*, который надо привести к нужному типу, достать оттуда ещё один указатель, ещё раз привести…
Я уж было решил, что вот оно — счастье, меня сейчас быстренько научат правильно писать драйвер модема.
Но нет же. Отправляем команду, и ждём ровно один ответ («OK», как правило). Если в этот момент нежданно-негаданно прилетит URC, она улетит в /dev/null.
Спасибо большое, такое г. я и сам понаписать могу.
Я недостаточно чётко сформулировал вывод. Там ключевое «якобы не работает». Потому что буфер там должен быть, а сделать буфер (хоть отдельной логикой, хоть на транзисторе), который будет работать от 5 вольт, но не будет работать от трёх — надо отдельно постараться.
Шилд «абстрактный в вакууме»?
Если посмотреть документацию на модем (хоть симком, на котором любят делать у нас и в Китае, хоть квиктел, который продают на arduino.cc), напряжение на ногах модема не должно быть выше 2.8… 3 вольт.
Т.е. там ДОЛЖНЫ быть преобразователи уровня.
Оригинальная плата использует полноценные буферы, подключенные к ардуинным 3.3 вольтам (и, к слову, они превышают максимальные 3.1 вольта для квиктела). Трёхвольтовые сигналы от основного контроллера для этой схемы — как родные.
Какой китаец так умудрился сделать преобразователь, что он якобы не работает с трёхвольтовыми сигналами, надо разбираться
Вот я задачу интереснее и полезнее придумал: датчик объема оставшегося топлива для бензобака придумать
Гуглом Вы принципиально не пользуетесь? Запрос «датчик уровня топлива» выдаёт кучу искомых устройств.
Да, они большей частью под грузовики (питание 24 вольта и немаленькие габариты), т.к. проблема воровства солярки актуальна в первую очередь для грузовых автопарков.
Но допилить такой датчик будет на порядок дешевле, чем сделать нечто подобное самому (и на порядок дороже, чем починить родной показометр).
А Вы сами пробовали читать документацию нордика? Очень интересное чтиво, рекомендую.
В частности, там написано про ремап. Все ноги, за исключением радио и аналога, можно назначить КУДА УГОДНО.
Вы не пробовали посмотреть, как устроен в этом месте https://gnu-mcu-eclipse.github.io/?
Тот же набор в виде OpenOCD (или Segger JLink, по желанию) + GDB, и всё "само" работает.
До этой глубокой мысли авторы FreeRTOS дошли в позапрошлом году. До 9-й версии все объекты freertos'а (задачи, очереди, семафоры и т.д.) выделялись malloc'ом. Сейчас хотя бы выбор появился…
Правда, справедливости ради, можно спроектировать систему так, чтобы маллок вызывался только при старте, а дальше всё работало «в статике».
Я понимаю, что L298 — драйвер ШД. Но он не умеет ограничивать ток (можно навернуть это снаружи, повесив токоизмерительные резисторы, компараторы и капельку логики), а включать ШД от термопринтера без ограничения тока в 12 вольт чревато его убийством (померяйте сопротивление обмоток).
Тут нет опечатки? А смысл? Избежать мифической ошибки компилятора?
И да, это при условии, что гугл не грохнул этот «Open Accessory» — в массы оно явно не пошло…
Очевидно, треды и средства их синхронизации должны взаимодействовать с ядром ОС. Т.е. надо писать порт STL на конкретную операционку. Пока, к сожалению, таких супергероев не видно…
Да нету никаких проблем с приведениями типов. Если никогда не ошибаться. А если в макрос, внутри которого cast на cast'е, передать что-то не то, компилятор это тихо сожрёт без каких-то варнингов.
Продумать и описать протоколы, по которым идёт взаимодействие с внешним миром, статически выделить необходимые буферы (хоть сишные, хоть std::array), и жить…
В описываемом случае (контроллер относительно мелкий, malloc по каким-то соображениям не используется) лучше смотреть куда-то в район etlcpp.com. Бустом, правда, я никогда не пользовался — посмотрел, испугался, и закрыл.
Для работы используются два — для переключения задач (обычно — PendSV_Handler) и для системного таймера (и тот только в обычном, не tickless, режиме).
SWI + SVC_Handler — это такой фриртосный костылик для запуска самой первой задачи.
Тут про «переносить код на разные ос». И сейчас оно больше напоминает картинку «есть 14 конкурирующих стандартов»…
А можно раскрыть тему: ЗАЧЕМ?!
И там не пахнет не то чтоб плюсами, там банальных инлайн-функций вместо всех этих макросов нету…
Авторов FreeRTOS с таким подходом понять можно. Простить — сложнее :-)
В общем, моё мнение — эту обёртку можно использовать в каких-то особо странных случаях («мне нужно только freertos, потому что у неё сертификат, но самой freertos я видеть не хочу»). Иначе, если не хочется видеть фриртос — ей можно просто не пользоваться, благо альтернативы есть…
И все эти наслоения макросов из кишков фриртос никуда не деваются. И если использование операционки с этой прослойкой, действительно, должно упроститься, при отладке, если туда понадобится-таки лезть, мы опять упрёмся в void*, который надо привести к нужному типу, достать оттуда ещё один указатель, ещё раз привести…
Я уж было решил, что вот оно — счастье, меня сейчас быстренько научат правильно писать драйвер модема.
Но нет же. Отправляем команду, и ждём ровно один ответ («OK», как правило). Если в этот момент нежданно-негаданно прилетит URC, она улетит в /dev/null.
Спасибо большое, такое г. я и сам понаписать могу.
Если посмотреть документацию на модем (хоть симком, на котором любят делать у нас и в Китае, хоть квиктел, который продают на arduino.cc), напряжение на ногах модема не должно быть выше 2.8… 3 вольт.
Т.е. там ДОЛЖНЫ быть преобразователи уровня.
Оригинальная плата использует полноценные буферы, подключенные к ардуинным 3.3 вольтам (и, к слову, они превышают максимальные 3.1 вольта для квиктела). Трёхвольтовые сигналы от основного контроллера для этой схемы — как родные.
Какой китаец так умудрился сделать преобразователь, что он якобы не работает с трёхвольтовыми сигналами, надо разбираться
За час переписать read()/write() adafruit'овской библиотеки?
Или за день раскурить даташит bme и построить очередной велосипед?
Гуглом Вы принципиально не пользуетесь? Запрос «датчик уровня топлива» выдаёт кучу искомых устройств.
Да, они большей частью под грузовики (питание 24 вольта и немаленькие габариты), т.к. проблема воровства солярки актуальна в первую очередь для грузовых автопарков.
Но допилить такой датчик будет на порядок дешевле, чем сделать нечто подобное самому (и на порядок дороже, чем починить родной показометр).
Достаточно сломать стрелочку с номером 2, и всё — кирпич готов.
Т.е. хочу сказать, что нормальный надёжный загрузчик — это чуть сложнее готового примера. Ну и тем более, он получается совсем не совместимым с ардуино-скетчем, который в статье так хвалят.
В частности, там написано про ремап. Все ноги, за исключением радио и аналога, можно назначить КУДА УГОДНО.
Вы не пробовали посмотреть, как устроен в этом месте https://gnu-mcu-eclipse.github.io/?
Тот же набор в виде OpenOCD (или Segger JLink, по желанию) + GDB, и всё "само" работает.
Правда, справедливости ради, можно спроектировать систему так, чтобы маллок вызывался только при старте, а дальше всё работало «в статике».