Comments 10
А ещё сопрограммы могут быть весьма сложны при отладке. Вплоть до такой степени, что нормальная отладка не только их самих, но и окружающего кода становится невозможной: у меня такое было в KEIL. Сам компилятор (ARMCLANG) генерирует нормальный код, но у отладчика наличие сопрограмм начисто срывает крышу, из-за чего отладка возможна исключительно на уровне дизассемблированного кода. Похоже, KEIL не способен корректно интерпретировать отладочную информацию -- и вряд ли будет способен в будущем; скорей, ARM полностью переведёт разработку в VS Code, фактически свалив заботу об инструментах на "сообщество".
Eclipse CDT замечательно компилирует и отлаживает под ARM стандартным тулчейном.
Там gdb и gcc, т.е. как раз "плечи сообщества". У кейла всё своё.
Увы, по ряду причин мне нужен именно KEIL. Но, если бы я полностью был свободен в выборе, то смотрел бы в сторону VS Code: к Эклипсе в любых её проявлениях у меня стойкая нелюбовь, скажем так. Впрочем, в данном случае это уже вторично.
впервые слышу про это ПО, а какие причины и мотивы использовать именно его? просто любопытно, так как сам пишу под разные arm, но видимо из-за того что не имею дело именно с микроконтроллерами, ни когда не слышал про них.
Это основная среда разработки под микроконтроллеры и классические микропроцессоры (которые ARMv6 и более ранние -- до ядер серии Cortex, в общем) от ARM. У них есть ещё DS-5 на основе Эклипсы, но оно уж очень платное, громоздкое и всё такое прочее, и для микроконтроллеров смысл его использования стремится к нулю (а вот для современных микропроцессоров ARM ничего другого не предлагает -- но за бешеные деньги). Ну а главный конкурент на МК -- IAR, но он не ARMовский.
Практическое руководство по применению седла к корове (так уж оно выглядит, сори)
Но ничего. Ещё несколько стандартов, и приведут это к юзабельному состоянию. Может быть. Если оно ещё кому-то будет нужно)
Половина статьи про UB и проблемы использования. На самом деле все не так плохо, достаточно полностью переделать архитектуру и корутины заработают без боли и страданий)
Я добавлял корутины поверх уже готовой системы тасков и промисов. Тогда уже использовались правильные примитивы синхронизаций типа зависимостей между тасками, асинхронный мьютекс, что-то похожее на семафор и тд.
Так и есть, в большей части это вопрос правильной работы в параллелизме.
Те же Senders/Receivers в C++26 тоже не больший ад, чем просто новый инструмент.
А я сделал асинхронный ввод-вывод на микроконтроллерах без всяких задач и т.д. -- на голом железе, в общем. Но делал больше для того, чтоб самому разобраться, как оно работает и с чем его едят. Для практического использования в KEIL, как я тут выше упоминал, сопрограммы не годятся из-за невозможности отлаживать и их, и код вокруг них штатными средствами. А жаль: используя их, можно делать асинхронщину без сплошных подпрограмм обратного вызова и 100500 мелких функций.
Корутины в C++20: архитектура и практическое применение